7 ms·

The End of Dynamic Languages

60 points by Scarbutt 8y ago

bjoli 8y ago
You can pry scheme from my cold dead hands. I don't mind ocaml, in fact I'd probably chose to write most kinds of software in it, but scheme is what I write to keep my soul. It is what I write to rediscover that programming is fun. 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).
- sevensor 8y ago
  Do you miss the parentheses when you're working in ocaml? I'm not a huge lisper / ocaml-er, so maybe it's just that I have trouble seeing the expressions when they're not neatly wrapped in parentheses. But for that reason I tend to prefer the lisp syntax.
  - bjoli 8y ago
    Of course. Lisp syntax is best syntax :)
mathw 8y ago
That is exactly how I always feel when working in Clojure. Constant "what is this? What's in it?" 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.
- coldtea 8y ago
  >this just doesn't feel very efficient 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.
  - agumonkey 8y ago
    It's always a matter of system theory. You can have the fastest native code ever, if your system is suboptimal then it's almost moot. That's why people prototype in python or whatever (lisp and smalltalk decades ago), because they can design the system right and then tighten the organs with native code.
- iceninenines 8y ago
  Gradual typing is the usual workaround for making dynamic langs more like static ones.
- phyrex 8y ago
  > Sadly the language has nothing to help me 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.
- serpi 8y ago
  At this point you introduce schema.core and gradual typing. No need to blame the language when there is a solution for this.
  - bsaul 8y ago
    At which point do you consider it OK to NOT use typing for a library, or any piece of code that another programmer is going to have to use or maintain ? 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..
    - Skinney 8y ago
      Pretty much always. I mean, as a frontend developer I'm dealing with an untyped api all the time: the backend. We've written pretty huge software using many untyped services, and we're doing fine.
  - lkitching 8y ago
    Who is using gradual typing in a clojure codebase? I've never seen any usages of core.typed in the wild. Using schema is more common although its future seems uncertain in the wake of spec. In my experience schemas require just as much effort as specifying types without the benefit of automatic checking or the usual IDE integrations like navigation or autocompletion. As a result they're rarely used widely enough to be useful.
- F-0X 8y ago
  This is how I feel generally when working with codebases which make copious usage of type inference. 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.
LordHeini 8y ago
This is so true Moving back from a Scala application to Ruby feels like having an arm and a leg chopped off. 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 ;)
- deleted 8y ago
  [deleted]
- 0815test 8y ago
  Rust does NOT guarantee code to be free of deadlocks
skywhopper 8y ago
TLDR: After programming in Scala and Haskell for a while, the author has become increasingly nervous and uncertain when programming in dynamic languages like Ruby and Clojure. The author takes his own personal experience with this unpleasant sensation to mean that the era of languages like Ruby, Python, and JavaScript is ending and soon we’ll all be programming happily in Haskell... wait what? 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.
- HelloNurse 8y ago
  Also, balanced software architectures designed by balanced people will continue to "alternate hard and soft layers", as the traditional precept says, in the form of convenient and easy to learn DSLs and dynamic language scripting layered above a dependable and unchanging (and therefore usually compiled and high performance) application core. 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.
- pepper_sauce 8y ago
  They also figured out how to solve their own problem with the issue. Use the REPL!
ktpsns 8y ago
> But HTML is the perfect DSL for writing HTML—why replace it for another DSL with your own set of rules and restrictions, and lose the decades of tooling and know-how of every designer on the face of the planet? 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.
- naasking 8y ago
  I believe the author is pointing out that HTML itself is the clearest, most compatible expression of an HTML document possible.
- pepper_sauce 8y ago
  I agree. If HTML was fit for purpose, why is it almost always paired with a (language/framework specific) templating engine?
bamboozled 8y ago
I've worked in a Scala shop, it was probably the lowest performing team of developers I've ever worked with coupled with the highest amounts of bragging, theoretic talk, elitism and winging about other languages, especially dynamic langues. Is this a common theme across all Scala / Haskell communities or something ? 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.
- kod 8y ago
  I've worked in a scala shop, it was the highest performing team of developers I've ever worked with, coupled with the highest amounts of wanting to get shit done. 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.
  - mcv 8y ago
    It's almost as if it's not so much the language and the ecosystem, but the developers and their attitude that makes the difference. It's so tempting to hope that the right language will make everything better, but it never does.
- apta 8y ago
  > Is this a common theme across all Scala / Haskell communities or something ? 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 http://august.nagro.us/small-java.html
lbj 8y ago
Great critique after using Clojure for 5 minutes
mcv 8y ago
Much of this article sounds familiar and plausible to me, and yet my current project seems to prove it all wrong. 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.
iLemming 8y ago
Gimme a general purpose language that has a REPL. Not that crippled, useless garbage that most non-lisp languages have (typed or whatever). 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.
- JadeNB 8y ago
  I think it's harder to find a modern language without a REPL than one with it.
kgwxd 8y ago
How is the word "spec" not anywhere in that article? And HTML isn't statically typed anyway, so, while using Hiccup does introduce a bit of complexity, static typing isn't going to solve that, however, spec can bring back a lot of the functionality HTML-aware editors give. Edit: Oh, 2015. Should be in the title.
agumonkey 8y ago
There's a slight bias here: static structures don't help discovering. 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.
- platistocrates 8y ago
  "Try writing java without an IDE." But why would I ever want to?
  - anta40 8y ago
    Because "real programmers" only use vim/emacs and a bunch of UNIX text-based tools :p
  - agumonkey 8y ago
    It's not a why, it's a matter of fair comparison, when you have code analysis / completion in a repl you don't spend much time guessing. If you get a Request object, how do you know what is in it ? the IDE is telling you, not the language.
    - lkitching 8y ago
      But the IDE's ability to tell you depends on the language. IDE features for dynamic languages are worse because the static structure of the code is not available, so usually devolves into basic string matching. In the case of C#, the language and IDE support are developed together, and new features like async, linq etc are not considered done until the tooling (IDE, debugger etc.) supports them. It's unfair to dismiss the tooling for such languages when they were explicitly designed with them in mind.
      - 8y ago
cryptonector 8y ago
I am a maintainer of a dynamic DSL (jq), but I agree, I'm tired of dynamically-typed programming languages. Dynamic typing is an endless source of run-time errors.
drugme 8y ago
Working in Ruby is fine if you’re just adding a feature on top of the pile of features. All you have to do is add some unit tests, make sure the old ones pass, and run away. But anything else is impossibly difficult. 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.

60 points by Scarbutt 8y ago

You can pry scheme from my cold dead hands. I don't mind ocaml, in fact I'd probably chose to write most kinds of software in it, but scheme is what I write to keep my soul. It is what I write to rediscover that programming is fun. 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).

sevensor 8y ago
Do you miss the parentheses when you're working in ocaml? I'm not a huge lisper / ocaml-er, so maybe it's just that I have trouble seeing the expressions when they're not neatly wrapped in parentheses. But for that reason I tend to prefer the lisp syntax.
- bjoli 8y ago
  Of course. Lisp syntax is best syntax :)

mathw 8y ago

That is exactly how I always feel when working in Clojure. Constant "what is this? What's in it?" 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.

coldtea 8y ago
>this just doesn't feel very efficient 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.
- agumonkey 8y ago
  It's always a matter of system theory. You can have the fastest native code ever, if your system is suboptimal then it's almost moot. That's why people prototype in python or whatever (lisp and smalltalk decades ago), because they can design the system right and then tighten the organs with native code.
iceninenines 8y ago
Gradual typing is the usual workaround for making dynamic langs more like static ones.
phyrex 8y ago
> Sadly the language has nothing to help me 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.
serpi 8y ago
At this point you introduce schema.core and gradual typing. No need to blame the language when there is a solution for this.
- bsaul 8y ago
  At which point do you consider it OK to NOT use typing for a library, or any piece of code that another programmer is going to have to use or maintain ? 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..
  - Skinney 8y ago
    Pretty much always. I mean, as a frontend developer I'm dealing with an untyped api all the time: the backend. We've written pretty huge software using many untyped services, and we're doing fine.
- lkitching 8y ago
  Who is using gradual typing in a clojure codebase? I've never seen any usages of core.typed in the wild. Using schema is more common although its future seems uncertain in the wake of spec. In my experience schemas require just as much effort as specifying types without the benefit of automatic checking or the usual IDE integrations like navigation or autocompletion. As a result they're rarely used widely enough to be useful.
F-0X 8y ago
This is how I feel generally when working with codebases which make copious usage of type inference. 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.

LordHeini 8y ago

This is so true Moving back from a Scala application to Ruby feels like having an arm and a leg chopped off. 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 ;)

deleted 8y ago
[deleted]
0815test 8y ago
Rust does NOT guarantee code to be free of deadlocks

skywhopper 8y ago

TLDR: After programming in Scala and Haskell for a while, the author has become increasingly nervous and uncertain when programming in dynamic languages like Ruby and Clojure. The author takes his own personal experience with this unpleasant sensation to mean that the era of languages like Ruby, Python, and JavaScript is ending and soon we’ll all be programming happily in Haskell... wait what? 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.

HelloNurse 8y ago
Also, balanced software architectures designed by balanced people will continue to "alternate hard and soft layers", as the traditional precept says, in the form of convenient and easy to learn DSLs and dynamic language scripting layered above a dependable and unchanging (and therefore usually compiled and high performance) application core. 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.
pepper_sauce 8y ago
They also figured out how to solve their own problem with the issue. Use the REPL!

ktpsns 8y ago

> But HTML is the perfect DSL for writing HTML—why replace it for another DSL with your own set of rules and restrictions, and lose the decades of tooling and know-how of every designer on the face of the planet? 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.

naasking 8y ago
I believe the author is pointing out that HTML itself is the clearest, most compatible expression of an HTML document possible.
pepper_sauce 8y ago
I agree. If HTML was fit for purpose, why is it almost always paired with a (language/framework specific) templating engine?

bamboozled 8y ago

I've worked in a Scala shop, it was probably the lowest performing team of developers I've ever worked with coupled with the highest amounts of bragging, theoretic talk, elitism and winging about other languages, especially dynamic langues. Is this a common theme across all Scala / Haskell communities or something ? 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.

kod 8y ago
I've worked in a scala shop, it was the highest performing team of developers I've ever worked with, coupled with the highest amounts of wanting to get shit done. 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.
- mcv 8y ago
  It's almost as if it's not so much the language and the ecosystem, but the developers and their attitude that makes the difference. It's so tempting to hope that the right language will make everything better, but it never does.
apta 8y ago
> Is this a common theme across all Scala / Haskell communities or something ? 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 http://august.nagro.us/small-java.html

lbj 8y ago

Great critique after using Clojure for 5 minutes

mcv 8y ago

Much of this article sounds familiar and plausible to me, and yet my current project seems to prove it all wrong. 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.

iLemming 8y ago

Gimme a general purpose language that has a REPL. Not that crippled, useless garbage that most non-lisp languages have (typed or whatever). 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.

JadeNB 8y ago
I think it's harder to find a modern language without a REPL than one with it.

kgwxd 8y ago

How is the word "spec" not anywhere in that article? And HTML isn't statically typed anyway, so, while using Hiccup does introduce a bit of complexity, static typing isn't going to solve that, however, spec can bring back a lot of the functionality HTML-aware editors give. Edit: Oh, 2015. Should be in the title.

agumonkey 8y ago

There's a slight bias here: static structures don't help discovering. 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.

platistocrates 8y ago
"Try writing java without an IDE." But why would I ever want to?
- anta40 8y ago
  Because "real programmers" only use vim/emacs and a bunch of UNIX text-based tools :p
- agumonkey 8y ago
  It's not a why, it's a matter of fair comparison, when you have code analysis / completion in a repl you don't spend much time guessing. If you get a Request object, how do you know what is in it ? the IDE is telling you, not the language.
  - lkitching 8y ago
    But the IDE's ability to tell you depends on the language. IDE features for dynamic languages are worse because the static structure of the code is not available, so usually devolves into basic string matching. In the case of C#, the language and IDE support are developed together, and new features like async, linq etc are not considered done until the tooling (IDE, debugger etc.) supports them. It's unfair to dismiss the tooling for such languages when they were explicitly designed with them in mind.
    - 8y ago

cryptonector 8y ago

I am a maintainer of a dynamic DSL (jq), but I agree, I'm tired of dynamically-typed programming languages. Dynamic typing is an endless source of run-time errors.

drugme 8y ago

Working in Ruby is fine if you’re just adding a feature on top of the pile of features. All you have to do is add some unit tests, make sure the old ones pass, and run away. But anything else is impossibly difficult. 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.