Application Development Meanderings

dotty scala3 adoption report: easy so far I decided to use dotty (aka Scala 3) for a small machine learning (NLU) project to get a feel for new features and ecosystem components. I try to keep my code simple to write and understand. I tend to avoid the use of advanced type features, and I am Ok if I avoid “purist” FP thinking. I don’t mind a little boilerplate. Here’s some feedback. More to come when the project is complete: Adoption: Easy. I read some dotty slides for an hour. Then I read the dotty doc site for another hour. So far, the dotty features I have chosen have been easy to adopt, e.g., implicits with the new syntax via given. Dotty is an experimental compiler, and I found a bug! The dotty team fixed it within a few days–thanks! New features: I am using a few, new features including: implicit functions (they immediately added value) objectless toplevel code extension methods ADTs via enums union/intersection types exports The features were eas...

when is FP a good idea? an easy, functional web client using dotty, zio, sttp, circe, aws I often need a REST’ish web client to connect to a service and push/pull processing results from my ML algorithm. Usually, there are java facades available for a service, but they are quite laborious to use and lack scala idioms. While there may be scala facades, they may not use the effect and HTTP client library that I want to use in the rest of my application. There are other scala, web client libraries like http4s (a large list is here ) but they do not cover the specific domain of interest. Fortunately, I found it easy in one project to create a simple client library using dotty/scala3 to combine a few standalone libraries that met my needs. This blog post covers my design. At the end, I ask whether the functional features in my web client application layer are worth using vs. using a traditional approach. The short answer is that it depends (yes, I am a consultant). Wha...

react hooks: closer to a reactive library With the introduction of react hooks , the library is closer to a reactive library, perhaps closer to the original intent of react. I use react hooks via my library scalajs-reaction . One of the problems with react today is that it sometimes hard to reason about, hook functions (the new component hotness instead of classes) are not pure functions. State, ref, and other types of hooks mutate state underneath in the react “fiber” sub-system. Hooks is closer to the more ideal approach. In the ideal approach, a little bit of the DOM is updated when the data dependencies that create that part of the DOM change. For example, if a text object changes, then a div or p should change in the DOM. You can do this with hooks, but it looks like (taken from the react hooks website): function Example ( { suffix } ) { const [ count , setCount ] = useState ( 0 ) ; return ( < div > < p > You clicked {...

seems complicated but shouldn't be People wonder why some things seem complicated, for example, in react. React is fairly unprincipled in its use of effects, but it works for most people and it helps build better UI. The new react hooks use functions instead of classes to define components. That’s good. But as DanA points out, functions are different than classes and the differences can be subtle. Since the concept and language of effects has not been around react for long, and the language is still evolving, you get into fairly big piles of goo when it comes time to explain things around effects. Here’s an example article of where the language of effects, say as leveraged from category theory, might help be more precise: https://overreacted.io/a-complete-guide-to-useeffect/ Having said that, it is true that category theory vocabulary sounds scary and Dan was probably right in not using that language and instead used examples to illustrative his point, but ...

copying scala.js linker artifacts after linking There have been a few requests for a plugin to copy the scala.js linker artifacts to another location after the linker has run. While you could set the output path for the artifact to a different location, you may want to have the artifacts generated into the standard location then copy it to somewhere else to provide better compatibility with existing tooling. Ad-hoc Approach Here’s one way to add a copy process to a specific sub-project: def copyTask ( odir : String ) = { lazy val copyJSOutput = taskKey [ Unit ] ( "copy scala.js linker outputs to another location" ) Seq ( copyJSOutput : = { println ( s "Copying artifact ${scalaJSLinkedFile.in(Compile).value.path} to [${odir}]" ) val src = file ( scalaJSLinkedFile . in ( Compile ) . value . path ) IO . copy ( Seq ( ( src , file ( odir ) / src . name ) , ( file ( src . getCanonicalP...

user experience, scala.js, cats-effect, IO This is not a complicated snippet but I wanted to ensure I remembered it. When creating a UI, say react for browsers, you will run into the “fetch” data problem. When you fetch data, you typically have a component that performs the fetch and acts as a cache for the result. The fetch component renders a child and passes along the data that was fetched (or the fetch state, etc.). Even with the upcoming react suspense mechanism that will make this a smoother user experience, you may have a flash of a “loading” indicator that shows for a moment before the content is fetched from the server. If the flash is too fast, it is visually disruptive. A shimmer mechanism for the UI my also not be the answer. Similarly, if the fetch request takes too long, you will want it to time-out and show an error message that the data could not be fetched or whatever is appropriate for feedback in your application. Generally, I use cats-effect...

programming languages, not sure javascript's ES* all make sense Well I was just thinking the other day about javascript and its pros and cons. Its clearly an interpreted language with a simple syntax. That makes it easy to learn. However, there have been alot of changes using the ES* process. Each version adds some new functionality, sometimes a little sometimes alot. Sometimes just enhancing a few APIs sometimes making large changes, such as adding module systems. I was doing some work in scala.js the other day, along with nodejs+express+mssql+typescript for the backend. I could have written the backend in scala.jvm but there was no compelling reason to do that as there was some json manipulation and I find js to be easier to use when json is involved. You can avoid alot of encoders/decoder type coding when using scala.js and that just makes it much easier (whether you are in scala.js or typescript). But I did notice that even with instant node+express rel...