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 reload using “nodemon” (restarts node after a source code change) that this felt bumpy. While my server does not maintain any state so its not a big deal, it did feel that I should just be able to reload a single js function in its module and have my “dev” server continue running without full restart. The granularity of restart is at the application module level and the granularity of development (source code) change is at the module level. A change in the source file causes typescript (in watch mode) to recompile the module source, which it can do incrementally against the entire project, output javascript, which nodemon then notices and restarts node with the new code. Like any statically typed language though, tsc must create a graph of compilations based on dependencies.

Huh?

If javascript is so dynamic, everything in the tooling chain assumes its not, actually. I can’t have changes at the granularity of a class or function, especially if I maintained state in a running application, that would cause object chaos. In other words, the dynamic nature of javascript seems to be a gateway to more structured layers on top vs a “mode” in itself. Part of this is due to the static language on top of javascript and part of it is due to the “application framework” express itself.

It kind of feels like the entire javascript ecosystems is stifling javascript’s dynamic nature. I admit that I know this, which is why if I am going to subdue its true nature, I’ll use scala.js because it a very strongly typed programming language with more sensible module and language feature support–I’ll go all the way.

But it just reminds me that while I understand the trade-offs that everyone is making with the javascript ES* releases, it feels like it is going in the wrong direction. Classes without generic functions (and hence no dynamic dispatch) and modules systems that are really just placeholders for static file importing in some tool (yes, to work in browsers that kind of make senses static-file wise)–feels like its missing an opportunity to do better to allow interactive use in development and at runtime. After all, nodemon is really just a poor substitute for a dynamic development environment.

In other words, other non-language related components, an editor, a process monitor/restarter, can make up for whether a language supports these features or not. The more “jobs” you want the language to support, the large and more complex the language, and vice-versa. The language can be shrunk/expanded based on the target environment it will run in (for dev or prod) and the resources and capabilities of that environment. Since a full solution is more than just a programming language, you can never evaluate a programming language separate from the range of target environment it will run in. It’s like a balloon, squeeze in one place and the other part of the balloon becomes larger.

That’s also why many of the conversations about the best programming languages are a waste of time. Without evaluating the programming language with the environment, including the people/human part–all three dimensions–it is not a useful conversation because it will miss important factors that go into the outcome. It’s really quite easy to figure out. For example, some people talk about small teams with “super tools” can be highly productive, more so than large teams. And that can be true with the right combination programming language, dev/prod target environments and people. In this case, something like lisp, which supports a dynamic development and deployment environment, could be very useful and appropriate. But in other situations that may not be best answer. What confuses some people, I think, is that the boundaries between these segments can greatly overlap giving you multiple options.

So when I comment out loud about javascript’s direction my comments may only make sense in some of those segments but not all. For small projects of 1-2 people with short schedules, unless I already know the target environment extremely well, I may want to have all the resources and capabilities I need accessible from within my highly-productive programming language. Other times, I may not because someone else is handling that aspect and I do not have to worry about that concern.

Makes me scratch my head a bit…but not too hard.