The End of Dynamic Languages
elbenshira.com
elbenshira.com
The gradual typing systems that are out there are usually enough when I want a typed module, but the tooling could improve (like, you know, getting type hints when calling a typed function from untyped code).
I witnessed many times where a solution could've been solved much more efficiently using a simple Ruby or Python service of no more than a few hundred lines but the suggestion was scoffed at.
Side note, the ecosystem around Scala seemed horrible, SBT is filth and it seems to lack good libraries for most basic tasks. For something of such advertised greatness it seems there is a lot to dislike about Scala, including dragging around a JVM.
The ecosystem around scala is great, you get to use any jvm library using a relatively sane ML derived language that is safer than most other alternatives.
It's so tempting to hope that the right language will make everything better, but it never does.
I worked at an employer who used Scala for their main product. It was a pragmatic style though (mainly a Java++ if you will). So, not all Scala places are like that.
That being said, I would probably not use Scala for the same product they were building today. Kotlin is much more pragmatic, better standard library, better IDE support, and better interoperability with Java. SBT is slow and sluggish, not excusable really. But the JVM is a superior platform for building almost anything today, especially after project Jigsaw where you can ship a stripped down version of it if you choose: http://august.nagro.us/small-java.html
You can't just say "it's a map". Sure, it's a map, but there's data in there I want so can you at least tell me what keys it's supposed to contain? Sadly the language has nothing to help me make up for the lack of documentation other than inspecting values at runtime inside a half-constructed program and this just doesn't feel very efficient compared to returning a defined data structure with specified properties.
And yet people could run circles around static typing programmers using Lisp, Smalltalk and other dynamic languages to build programs faster and iterate on them quicker.
Except if you mean "doesn't feel very robust", which I'd somewhat agree.
Except that is the whole point of spec. Yes, it’s not available for all libraries, but can always add it when you need it, and you don’t need it that often.
I think basically never ( even for throwaway code, because they often end up being reused). So i’d much prefer a language for which static typing is not an afterthought..
I hate it, and think it is simply counter-productive in most cases. Though most other developers scoff and this and can't understand why I'm happy to write "unnecessary types".
I long for a language where types are mandatory and on the left. But not Java <10.
However if you like safe compiled languages i can only recommend to have a look at Rust.
Having a compiler that guarantees code to be free of deadlocks and such at compile time is just incredible.
And it is not even that hard to learn compared to Scala.
Scala is a really great language. But its open syntax, which ranges from c like imperative with curly braces to points free style can be hard to grasp. Not speaking of obscure compiler messages when a library using a weird dsl is missing some implicits.
Rust being more opinionated and having less stuff shoved into it while having all the stuff you need is really great.
The borrow checker has like half the rules of the "this" keyword in JavaScript ;)
Meanwhile the world continues on as it ever has: individual languages go through their life cycles and change and grow and fade and they each have their own strengths and weaknesses and fans and detractors, and through it all Haskell continues not to catch on.
In related news, people will continue to choose the right tools for the job, for example by preferring functional languages only when managing I/O and state is trivial enough.
What makes Clojure awesome - it's the REPL. Everything else is secondary.
And any criticism of Clojure just falls apart once you get to the power of the REPL. That alone could make you undeniably productive.
- Make it work - Make it right - Make it fast. In that order!
And Clojure is a language designed to build programs in that order.
I actually spend way more time finding out what java objects can do than clojure. The only reason java programmers don't feel this is because someone wrote code to check/suggest what they just wrote. Try writing java without an IDE.
ps: and I'd add that simple set of immutable structures plus functional idioms filters a lot of ambiguity from programming too. The other day I had to read java sax attribute API. It was not obvious and a complete waste of time all that for a list of pairs.
But why would I ever want to?
If you get a Request object, how do you know what is in it ? the IDE is telling you, not the language.
I'm even pretty sure that until a decade ago, Emacs had a more grammatical understanding of source code than Visual Studio.
maybe I don't expect as much as you do then.. I always felt a lot happier in a repl than in an IDE but I have to admit too that I didn't use IDEs a lot recently. (my last bits were scala and java graph moocs under eclipse and I was as angry as I used to be previously).
Why?
The availability of powerful IDEs is one of the biggest selling points of Java, arguably topped only by portability and the large ecosystem of libraries. The fact is, if you're writing Java, you will almost certainly be using tools that help you write correct code more quickly.
And the nature of Java is what makes that possible. The IDE knows what your data means, and it knows if you're trying to do something that isn't allowed. That's the entire point of the article: Java forces you to declare what you're trying to do, the IDE holds your hand through that, and the compiler enforces it.
OTOH, they support tooling that can, used properly, though that tooling itself increases the surface and scope that needs to be learned and accessible in using the language. (And often is less helpful than it should be, because if it often takes more what is necessary for code to function to make discovery useful, but that involved the kind of documentation lots of people avoid.)
And again, the point is not that dynamic => uncertainty it's that static != certainty. It's static + man hours that reduce some uncertainty.
ps: remember the stubs of code in the Eclipse/UML era... that was tooling too. We got to be a little more precise.
Edit: Oh, 2015. Should be in the title.
We're doing mostly javascript. A complex web application that displays massive amounts of complex, related data with all sorts of ways to search through it and visualise it in different ways. Fun stuff.
All javascript, so dynamic and untyped, but that doesn't matter; we're churning out new features at an amazing pace.
Still, quite often I'm wondering what kind of object I've got in my hands. Is this an Element, is it just the id of that Element, or is it something wrapped around the Element? No idea. So we quickly switch to typescript and move on. Problem is, we still haven't described our data structures, all our types are still `any`, and I still don't know what I've got in my hands. Doesn't matter, though, we're still churning out new features at a pace I've never seen before.
We switch to a graph data base, and we get our data in a completely different format, still without any description of its structure. It's not slowing us down from writing new features or refactoring our code at an amazing pace.
Alright, so someone writes up some actual classes. Only the Element type has just an id and an `element` field that contains an untyped object with all the actual data. I still have no idea what I've got in my hands, but it doesn't matter, we're still churning out new features, new designs and new visualisations at amazing speed.
So I'm not so sure that not knowing what my data looks like, actually slows down our development. We're doing fun stuff and that's what's making us productive. I would absolutely like to have all our data described by classes, and have our classes designed a bit more sensibly, and I'm sure I'm going to do that some day, as soon as I'm out of cool new features to write.
We're violating all the best practices I've always adhered to. I think we've got two whole unit tests in this project. And yet everything works, there aren't any serious bugs as far as I can tell, everybody loves what we're doing, and we're working at an unbelievable speed. So now I'm doubting everything I've always known.
HTML (as understood in XHTML) describes a certain type of tree structure. Creating this tree structure in just another DSL is perfectly fine, because it will produce HTML in the end. I don't understand the authors issue here.
No, not "impossibly difficult". Just not as effortless as you'd like it do be. Which fortunately makes it easy to discount the the rest of the article for what it is - needlessly charged hyperbole and (gross) oversimplification of what should be viewed as a substantially more complex set of tradeoffs.
Or that is to say: a rant.