[bitwize]

Lisp and Smalltalk actually suffer from the same problem: late-binding sucks. When I was in college a professor once pointed out to me that he didn't know of an LL(1) parser for Smalltalk. There's a reason for that: Smalltalk's syntax is late-bound! It's almost like Forth's syntax: the reader consumes words and decides what to do with them on the spot, whether they represent variables, operators, constants, or parts of a message send and once it has a subject, verb, and objects, dispatches the message also on the spot.

This plays havoc with your ability to do static analysis, and languages that hinder static analysis should not be used in real-world systems. If the earliest you find out about errors is in a running system, it's far too late and you are hosed.

This is why the Lisp and Smalltalk Evangelism Strikeforces have been met with decades of failure, while the Rust Evanglism Strikeforce is getting on with a massive project of digital tikkun olam.

[goatlover]

> This is why the Lisp and Smalltalk Evangelism Strikeforces have been met with decades of failure, while the Rust Evanglism Strikeforce is getting on with a massive project of digital tikkun olam.

If that were true, then Javascript, Python, Ruby, PHP, etc would also have failed. Smalltalk and Lisp failed to become popular in the modern world for reasons having nothing to do with late binding.

How about wait until Rust is at least as widely used as Ruby before going on about how much of a failure Smalltalk and Lisp are. Let's see if Rust stays around as long as Smalltalk & Lisp have, or whether it has that kind of influence on other languages.

[big_spammer]

There are alternatives that make static analysis look like the suboptimal approach.

https://pointersgonewild.com/2015/09/24/basic-block-versioni...

[maemre]

Static analysis is not just about inferring types and hot paths for optimization. For that kind of stuff, a dynamic analysis is most of the time way better (lots of JIT compilers with speculative optimizations prove this point). There is another goal where static analysis shines: verification. If I'm writing a somewhat critical application, I want to make sure that it behaves according to my intent in all cases. For example, if I'm writing an airplane sofware, I want to make sure that it will at least never invoke any undefined behavior (this is done in ASTREE project). Static analysis is a powerful tool to give such guarantees in many cases.

Some highly dynamic language features make analysis really imprecise or really hard (in terms of computation cost). There has been quite a lot of work on making static analyses that can handle such language features (for example control flow analysis helps analyzing code that uses dynamic dispatch or closures a lot but cost of the analysis is exponential in terms of the precision level most of the time). Sometimes people tackle analyzing highly dynamic languages like JavaScript but at a huge time cost in certain cases [1]. I'd prefer using a language designed with static analysis in mind if I were to prove certain properties about my code.

[1]: http://www.cs.ucsb.edu/~benh/research/papers/dewey15parallel...

[pron]

Right, but an important point here is "some highly dynamic language features make analysis really imprecise or really hard". Not all "late bindings" are born equal. JavaScript's dispatch is very different from Java's from a static analysis perspective, the latter being almost indistinguishable from pattern matching.

[maemre]

I totally agree with that. When I mentioned dynamic dispatch, I had something like Scheme or JavaScript in my mind. Dynamic dispatch in those languages require a more subtle analysis to obtain precise results. I wish I could edit my parent comment to clarify my example.

To clarify my position (hence my parent comment's point) on this general matter, I'm OK with any language feature that is amenable to static analysis in a practical amount of time. This puts me closer to PL conservatives in Steve Yegge's spectrum.

[zimablue]

I think the standard counterargument is that if unit testing is ubiquitous, we're already admitting static analysis is at best very incomplete.

[pron]

I think some guys actually proved that in the 1930s. But so what? Program analysis and testing complement one another.

[rpdillon]

I wouldn't be so sure. ACL2 is written in LISP. http://www.cs.utexas.edu/users/moore/acl2/

[gnaritas]

> Lisp and Smalltalk actually suffer from the same problem: late-binding sucks.

That's a feature, not a bug. Late binding rocks.

> This plays havoc with your ability to do static analysis, and languages that hinder static analysis should not be used in real-world systems.

The real world is full of late bound languages; much of the internet runs off late bound languages including this site. There's a million Rails and Python apps out there, so basically this "opinion" of yours is not bound to reality.

All of biology is late-bound, cells communicate via message passing, so the oldest and most complex real world systems we know of are late bound. To dismiss late binding is naive at best.

[shawk]

> That's a feature, not a bug. Late binding rocks.

So much that you can see ripples everywhere of late binding languages being slowly (not saying the transition is complete) replaced by static languages. Even the one true bastion of late binders, web development, is seeing massively increasing adoptions of languages like Typescript on the frontend, and languages like Go on the backend (see adoption at Youtube, Dropbox and so on).

Outside of web development, and simple trivial admin scripts, the other major source of late bound software was.. Apple Objective C. Which is getting replaced by Swift, a language that heavily favors static typing and functional paradigms.

> There's a million Rails and Python apps out there, so basically this "opinion" of yours is not bound to reality.

There's a million of trivial CRUD apps that don't do much of worth and whose death the world would not really mind either. DHH, rails's author, didn't mind restarting his basecamp servers 400 times a day because of a memory leak. These people are not software engineers. They're cave men using glue other people made to tie together rocks to build stonewalls. Which will then fall as soon as the weather stops being nice. Security, reliability, performance, what do they know about any of these things? But hey, you can do cute things like 3.days.from_now, what a great framework!

[armitron]

You're all over the place here and your arguments make no sense whatsoever when examined.

First, you conflate mass-appeal with some sort of objective "better" criterion which is of course bonkers. To use one of your own examples against you, there are hundreds of thousands of Java monkeys out there that are using glue other people made to tie together rocks to build stonewalls. Which do fail as soon as the weather stops being nice. Security (you should look into Java deserialization bugs), reliability, performance what do they know about any of these things?

Second, you conflate late-binding as present in Lisp and Smalltalk with late-binding present in other dynamic languages. The two are not equivalent, a perfect example of the whole is greater than the sum of its parts.

Lisp and Smalltalk will never become popular (read my previous comment), but that does not mean that they do not sit on an apex and still have a lot to give. To anyone interested in the "craft of programming", "the Art", there is nothing better period. Here are some references for you, from the masters themselves:

[1] https://www.infoq.com/presentations/We-Really-Dont-Know-How-...

[2] https://www.youtube.com/watch?v=YyIQKBzIuBY

[3] https://www.youtube.com/watch?v=FvmTSpJU-Xc

[goatlover]

There's tons of R and Python code in scientific computing that's not being replaced by static languages. Anyway, dynamic languages have been around since the 60s. This debate is very old. Trends in one direction or another swing back and forth. If you're going to mention Go, Swift or Rust, what about Elixir or Julia? They're new languages, too.

[gnaritas]

We get it, you're a static typing fan, this debate is as old as the hills, but late bound dynamic languages are not going anywhere, are not being replaced, and will continue be popular and make money because what you don't seem to get is that we don't all agree static typing is the golden hammer you seem to think it is. Yes, those people are software engineers despite your unwarranted superiority. And Rust... please, in time maybe but right now it's hardly used and can not remotely be called a popular language, not in comparison with the popular dynamic languages which dwarf it in usage by orders of magnitude.

[kazinator]

We need only enough static analysis to reliably go from machine language on a silicon CPU to robust late binding. After/above that, fuck it.