> Clojure's life time was limited from day one

Clojure is a Lisp. When the evidence and pragmatism of static type systems become scientifically proven facts I'm sure someone will figure out a way to extend the language without turning it into a disaster. Right now Clojure makes sense and it is way more productive to use it than any statically typed language.

This 100x! I don't understand how people can work on a complex codebase without a strong static type system. I've tried it once, and still remember the lack of confidence after every non-trivial refactoring.

I've worked on multiple large Java codebases, and on semi-large Clojure code bases. The Java ones compiled great but were full of bugs obscured by 100s of useless classes with bespoke interfaces. I found the Clojure code bases to be far more tractable because the language leads to better opportunities for abstraction and more concise code with way less incidental complexity. I think spec can add another layer of description where it's useful (and is not required where it's not).

That's anecdotal, and probably more a consequence of the seniority of the engineers who wrote these two code bases than the nature of the type systems.

My point about static type systems is broader and actually backed by science and mathematics. And also, just observing the trend and seeing where the wind blows.

Oh, do tell? Please point me at the scientific and mathematical evidence. I would be interested to see it.

You'll never get it because there isn't any. Static vs dynamic typing is largely a matter of preference despite all the hooting from the recent static typing fad. I truly wish this "apparent truism" would go away, since it commonly turns to people flaming dynamic languages as somehow inherently lesser than those with big fancy type checkers.

Indeed. I’ve googled for this research, and there isn’t much of it - just something that “everybody knows”.

The best, recent thing I found was a study done about 5 years ago or so (I think) by a fellow at UC Davis, and the data were pretty weak. Functional programming, and the requisite memory management, had at least as big an effect as static typing.

At this point some Haskell snob steps in and say “sound typing”... :-)

http://web.cs.ucdavis.edu/~filkov/papers/lang_github.pdf

Google the Curry Howard isomorphism.

In a nutshell, you can mathematically prove a certain degree of soundness of your code when you have type annotations.

There is no such thing in dynamically typed languages.

I guess that's why all those statically typed programs don't have any bugs and don't need any tests.

Being "sound" just means you can prove things are consistent with the assumptions you can encode in it. If there are things you can't encode in the types, or if your assumptions are wrong (misapprehension being one of the main problems in software), or if your requirements change, soundness is not going to save you.

Static types and proofs are valuable. Programs like compilers have fixed inputs and outputs and are excellent places to lean on things you can prove. But most of the programs I've worked on are not like compilers. They run for years, the requirements change, they have to deal with dirty data, talk to other messy systems, etc. And I'm not saying that dynamic types are perfect either.

My point is simply that static types are not a magical end goal of programming. They are a tool with tradeoffs.

> I guess that's why all those statically typed programs don't have any bugs and don't need any tests.

This is both a straw man and a fallacy. Nicely done.

Also something I never claimed.

You are basically saying that since you can't prove a program can be 100% demonstrated to be correct, there's no point in trying to approach this goal, therefore dynamically typed languages are good enough.

With your reasoning, we wouldn't be using safety belts because they can't guarantee you'll survive a car crash 100%.

Sure, static types have trade offs, but they are a clear improvement on all dimensions over dynamic types, which is why we see dynamic languages converging toward static typing and never the other way around.

In ten years from now, we'll look at dynamically typed languages as "It looked cool at the time, but we know better now". A bit like we look at FORTRAN and COBOL today.

> Sure, static types have trade offs, but they are a clear improvement on all dimensions over dynamic types

That has not been my experience and I don't think there is much objective proof of this. Most of the (admittedly not great) studies I've seen show dynamic languages as comparing favorably or better in bug counts for example.

Some of the things we're working on in the next version of spec are is head-on the notion of how to define expressive contracts for functions and allow those to meaningfully evolve in compatible ways over time as program requirements change.

I look at FORTRAN as a great language for its domain, so maybe you're right. :)

> Sure, static types have trade offs, but they are a clear improvement on all dimensions over dynamic types

This statement seems self-contradictory.

Google Godel's incompleteness theorem.

In a nutshell, if you can mathematically prove a certain degree of soundness of your code, you have not done anything to show your code does what it is supposed to do.

Basically, you could be doing wasted work to satisfy your compiler, and have made zero progress in solving your problem, because that's not what the type system does.

Dynamical languages focuses on solving problems of human beings. The human beings' requirements are often inherently arbitrary, logically unsound, or even self-contradictory. Shoehorning a type system in there often serves to make solving human's problem harder. Consequently, in practice, most popular programming languages are dynamic. The current craze with types is just a fad, in my opinion.

> Dynamical languages focuses on solving problems of human beings

> Shoehorning a type system in there often serves to make solving human's problem harder.

For the first pass author maybe. Subsequent readings and modifications of the code by other authors are much, much harder without "annotated" code (be that types or schema like spec)

Having worked on many codebases of all sizes, hand written by an ever changing population of developers (contractors, interns, consulting companies, etc.) I don't look at such annotation as the holy grail of developer-to-developer communication (in this respect, I find them quite less powerful than tests), nor as the philosophical stone of coping with changing requirements.

Because python or Javascript aren't a thing?

This is a similar straw man to someone claiming the trend of cars is clearly going electric and you saying "I doubt it, look at all these gas propelled cars we have today".

Python and Javascript are going to be around for a while, sure, but 1) they are also moving toward static type safety and 2) fewer and fewer projects will be started in these languages because statically typed alternatives are a better choice across the board.

Define strawman:

"an intentionally misrepresented proposition that is set up because it is easier to defeat than an opponent's real argument."

The parent poster stated that clojures days were numbered because in his opinion statically typed languages were becoming increasingly popular and Clojure didn't follow this trend.

I specifically mentioned JavaScript and python because people have been extolling the virtues of static typing literally before either shipped, while both rose to prominence, and became wildly popular. I'm arguing that neither posters personal preference nor even a correctly assessed trend in computer language design is by itself a useful tool to predict the future success of a given language.

This especially rings false when the same prediction is made several decades in a row.

I wont even address your analogy because analogies are like buttholes. Everyone has one and yours stink.

The largest recent change in Python is adding support for type annotations [1].

TypeScript is now the #7 language on GitHub.

Matz has said that a major goal of Ruby 3.0 is optional static types [3].

Facebook has reportedly ported large amounts of their PHP code to Hack, which adds static types to PHP.

[1]: https://docs.python.org/3/library/typing.html

[2]: https://octoverse.github.com/projects#languages

[3]: https://blog.heroku.com/ruby-3-by-3

The poster above mine said that languages that didn't ship out of the box with mandatory typing had a limited lifespan.

Indeed grafting types onto python, ruby, and even php seems more likely than people stopping using.

Given the huge uptake on Typescript, I don't think using JS as an example makes sense.

Static typing helps. It doesn't have to be Java-esque. F# & friends have really nice static type systems where you don't need to declare types for most things - they're automatically inferred.

Seems like javascript is destined to be here for the long haul despite the presence of typescript. In fact static type proponents have been predicting the death of dynamic type languages since this gulf became apparent. Thus far reports of one camps deaths have been greatly exaggerated by the other.

No one is arguing that dynamically typed languages are all going to die out (though CoffeeScript and Perl certainly aren't doing well). Languages almost never die. People are still writing COBOL.

But the relative share of programmers writing code in statically typed languages appears to be increasing. When the web got big, there was a very rapid growth in dynamically typed scripting languages: Perl, Python, Ruby, etc. Then, when client side web development became a thing, JS got huge and then CoffeeScript.

In the past decade or so as developers have moved to writing larger more performance-intensive client-side applications (read: mobile with touch UIs running at 60 FPS), there is now a turn back towards static typing: TypeScript, Kotlin, Swift, etc.

Also, the sophistication of static type systems is increasing. Generics are now a given, control over variance is increasingly common, as is static control over null references.

This doesn't mean the graph will go towards static types forever, but it certainly appears to be right now.

Pendulums swing....

That's a false analogy.

CD's are not going to become popular again to listen to music because "pendulums swing".

When a trend is clearly going toward increased comfort or clear progress, there is only one direction that the trend is going.

I argue that statically typed languages are headed in that direction and that in ten, twenty years from now, dynamically typed languages will be looked at as "something that seemed like a good idea at the time".

"Increased comfort" and "clear progress" are subjective measures about which people may disagree (to whit, I disagree).

I argue that in ten or twenty years from now, we will have great tools in dynamic languages to express constraints when needed, without requiring proofs.

These are opinions, not facts.

Is there anything to capture (dev-)runtime data & generate specs from that as a starting point?

super. thanks

the poster I originally applied to was arguing exactly that dynamically typed languages were going to die out.

"Clojure's life time was limited from day one because it's simply going against the trend."