Apparently, now even #Microsoft Office is being rewritten in #JavaScript, (for the browser).
I'm not sure I want to know their reasons for not going the #WebAssembly route, because it seems that as we get more statically typed languages that elevate the paint points of 'types everywhere' via type inference, we also get even the last remaining holdouts to give in to JavaScript nonetheless, as we get more distasteful of #Electron, we get even more of it and our future looks even bleaker.
@MatejLach Oh, wait, that was probably the thing you didn't want to know. Sorry.
METAL VM is no longer a dystopian fantasy.
https://www.destroyallsoftware.com/talks/the-birth-and-death-of-javascript
The problem with large apps in dynamic languages is that unless they're well documented, (never happens), you're going to spend an enormous amount of energy on just trying to pass an argument of the right type everywhere and consistently, reducing your mental capacity for solving the problem you've meant to actually solve.
I noticed this trend where even Python or JavaScript libraries provide nothing more than API docs.
This works in the static world, precisely because I can see the expected type from the signature and learn more about how to construct it etc. by following that trail.
This makes API only docs for JS, or Pthon, libraries almost as good as no docs and as more stuff gets the JavaScript treatment, it'll become more and more common.
Beyond programmer frustration, it essentially threatens to eliminate free software, you know the one where you can actually modify the code, and give raise to the 'code dump movement', where we'll have lots and lots of code, but that nobody quite knows what to do with.
@MatejLach if you don't have a good repl with good tracing tools you're basically hosed in this situation. dynamicity *requires* observability; there is no way around this. I wish other languages would learn the lessons of Erlang.
@MatejLach But then with strictly typed languages you might find reading untyped IPC responses (e.g. JSON) a pain.
When faced with I have implemented my own dynamic language to deal with it (and other stuff).
Though JSON did come from JavaScript which is dynamic, and languages like Rust and Go have found a nice way to deal with it.
@alcinnz Sure, I am not saying dynamic languages don't have a place, or offer an advantage in a particular situation. My problem is specifically with people rewriting programs in JavaScript that are clearly not, and historically were not, a great fit for dynamic languages and the associated dark patterns in libraries and documentation, which make this even more annoying.
I've worked in some pretty big apps (size of ERP systems) in both Smalltalk and Python and never had that particular problem.
However, in both cases, the systems had well documented and consistent underlying models, which probably helped.
In the Python case, the biggest help would have been breaking it up into smaller modules, not switching to another language.
@bhaugen True, my problem is specifically with poorly documented code, whose only documentation is auto-generated API reference and how this somewhat works for static typed languages, because the types provide additional form of documentation. This isn't true for dynamic languages, so the same trend here is more problematic.
@MatejLach it’s typescript and IE11 until 2025
@MatejLach My guess is that Microsoft has discovered that web coders are cheaper and more readily available than application programmers.