scala, kotlin, javascript, swift, dart, ...

scala, kotlin, javascript, swift, dart, ...

This is a short note on programming languages (PL).

In general, I do not really care about the PL as long as it is reasonably succinct and capable to solve the problem at hand. Ideally, one PL can be used to solve different problems to amortize the cost of learning a PL over multiple projects.

Lately, everyone has defined their own programming language associated with their “platform.” Apple has Swift, google has dart (but uses java/js for other frameworks/platforms), Microsoft has C#, Sun had java, jetbrains has Kotlin. Some companies push their language as multi-platform, like Sun did, others evolve their PL to be multi-platform.

The whole PL situation is a mess. Each language is much like the other. More or less C-like with some PLs having a few more clever features than others. A company defines their own PL to control their destiny and ensure they are not dependent on another organization to evolve their platform. That makes sense strategically.

A company looking after their own interests increases the burden on the programmer. Since many PLs are similar, dart and swift are like javascript, the burden is not overly large but it does exist.

Kotlin has become popular lately for android programming. It’s a better java. Some consider a cut down version of scala. I used it for some android work and it was Ok. Adding functional programming (FP) patterns using the arrow library made it as messy, actually in my opinion, more messy, then the FP libraries of scala (and both kotlin and scala are more messy than haskell). In fact, once FP was thrown in, I felt that all the arguments against scala applied to Kotlin. And if we make it even weirder, I thought intellij’s sluggishness was noticeable and bad, a common complaint against scala and intellij together as well.

It is my opinion then that the plethora of PL is driven by corporate need and somewhat by programmer value vs programmer value first. No single PL is perfect, but many of the ones created today are just another copy-cat, so they add little value. The experience of using the language in editors can be similar as well, sometimes negative, sometimes “less-negative.”

After working with Kotlin my initial thought s that java will absorb some of its noticeable features in a few years. Perhaps kotlin will evolve just as scala is evolving. Kotline is multi-platform, more than just JVM, but that may not be enough to save it from being eaten by an evolving java.

A PL is just one dimension of a set of features that make some platforms take-off and others languish. UI frameworks have a similar pattern. I am aghast the android UI (java based). I’ve never seen such poor thinking in a UI library even if it is 15 years old, as it copies ideas from some of the original java swing libraries. The layers on top that have been designed merely added excessive complexity. Flutter is a breath of fresh air and fortunately copies the “layout/diff” approach to building UIs. Of course, some of this links back to WPF (but not exactly). They could easily evolve the android library and not create a total break that flutter represents.

It’s all a mess. I know that computer science is an ever evolving area, but you would think with all the smart people in the world working on these topics, it would be better already.

Comments

Post a Comment

Popular posts from this blog

zio environment and modules pattern: zio, scala.js, react, query management

zio environment and modules pattern: zio, scala.js, react, query management This blog covers a zio-based fetch design for scala.js, react web applications. It heavily uses the zio “environment” feature to help motivate a point of view on the modules pattern in effect systems. At the end, I summarize some thoughts on ergonomics and complexity. This blog assumes a basic knowledge of zio and react. scala.js is just like scala so you mostly already know scala.js. This blog is a follow-on to previous blogs: https://appddeevvmeanderings.blogspot.com/2019/10/scalajs-react-fetcher-hook_48.html and https://appddeevvmeanderings.blogspot.com/2019/11/scalajs-and-react-suspense.html . I have been keeping an eye on and culling ideas from typscript/javascript fetching libraries that address query management concerns. The formulation below incorporates some of those concerns but does not try to comprehensively duplicate well established javascript libraries. I only care about
Read more

quick note on scala.js, react hooks, monix, auth

quick note on scala.js, react hooks, monix, auth Reactjs hooks finally came out of preview in a recent version of React. scalajs-reaction has had support for hooks since they were in preview. React hooks seem like the hot new thing but for me the question is, do hooks help improve your code by improving maintainability, time to market, TCO, etc.? Let’s take a look using authentication as an example and employ monix , a reactive observable framework that also builds on cats . We will assume we are building a SPA. Does it improve your code and make your application & development experience better? Auth Auth processing can be complex. Many react auth examples you find in blogs like to show how to use “react-routing” and “auth” as a switch that determines which routes are protected or unprotected. Protected routes show application specific data. Unprotected routes show login content . Based on storing a “User” object in the browser session/local storage, th
Read more

attributes with react and typescript.md

If you use typescript with react you may wonder what the right signature is for your “properties” interface. Obviously, your component will have few to many specific properties that reflect your domain. However, you may wish to also provide for the ability to add other attributes, such as those valid for a div property. In other words, you want to extend your props interface with that of the properties from a div element. How do you do that? There are really two issues: How do you extend your props interfaces How do you filter the props once you receive them to just those that apply. Extend Your Prop Interface or Use Sum Types It’s not uncommon to see interface Props { className ? : string yourProp ? : number } with the idea of using it in class MyComponent extends React.Component<Props, any> somewhere. If your component will have an outer div, you may also pass in a react element so that its configurable. But let’s say your outer element is a div and you wan
Read more