Hacker News Reader

Comment by moomin | Hacker News Reader

Okay, here's my take on the implicit narrative here: Clojure is done. It will continue to improve, people will continue to use it and build cool things with it, but maintainers are burnt out, mostly because there aren't enough of them and partly because of the passive-aggressive relationship Cognitect has with the community.

There's a whole bunch of languages with small dedicated communities doing interesting stuff. D and Julia occur to me off the top of my head. It's not "failure" that Clojure doesn't really challenge Kotlin or Scala for mindshare. It's nonetheless disappointing for people like me who used to be really excited by Clojure's potential.

Could it have been different? I don't know. The powers that be could definitely have been more committed to growing the base, but it never seems to have interested them. Would it have made a difference? I honestly don't know.

View on HN

This sentiment is in direct conflict with all of the data in the survey, which shows increasing use and importance of that use. I know of more than one company that has bet big on Clojure in the last year and is succeeding where they have failed with other stacks at business-changing levels. I know of companies with 100s of Clojure devs. Download stats continue to trend up. Etc.

The core team is rocking right now and feel like we are on the tail of lifting spec to the next level (and out of alpha), and interested in finding ways to work better with the community. Some many great ideas in the hopper for REBL and other things too. 2019 is going to be a great year for Clojure.

Download stats mean nothing. The truth about Clojure adoption can be found by typing "title:Clojure" into Indeed.com. Search for United Kingdom and you'll find 4 Clojure jobs, 3 of which are in London.

Using "title:" you meaninglessly narrowed your search. There are postings like "Software engineer" with body saying "Developing with JS, and Clojure" which won't appear in your results.

Number of "Clojure" results is 109, compared with 98 for "Haskell", for instance (in London, according to indeed.co.uk). So both are not scoring big, certainly, but those numbers are nevertheless better than 3-4 years ago.

In my experience (in Sweden), most of those results are "false positives". Companies/recruiters like to look for passionate programmers, so they put smaller languages like Clojure in their ads, even though the job itself has nothing to do with it.

True, except they don't include languages just for being smaller (we don't see Befunge, or Unlambda there), but those associated with smartness, and passion for learning. In context of the discussion (dead/alive state), I wouldn't count this as a bad thing. There's no arguing that finding FP job is hundreds (or thousands, depending on city/country) times harder than OOP job. It doesn't mean all functional langs are dead.

I agree with what you're saying, my post was mainly trying to point out that there might appear to be more Clojure jobs than there actually are. For the past couple of months, I've been looking for Clojure jobs (after my company in one fell swoop decided that Clojure was out, and we were no longer allowed to use it for new projects), and though there are quite a few matches when searching just for "Clojure" on job boards, most of those have nothing to do with Clojure. Out of 50-100 matches, maybe 2-4 of those were actual Clojure jobs. Granted, this is in Stockholm, but the situation was pretty much the same a couple of years ago, and things don't seem to have improved. I love Clojure, it's probably my favorite programming language, but I finally decided on a more normal C#/Java/JS position for my new job.

Well, I have already agreed FP jobs aren't plenty :-) Business executives mostly prefer to stick to beaten paths, and it's understandable. I just don't see a tragedy here. OCaml was born in 1996, if I'm not mistaken, so it's a decade older than Clojure. Despite never reaching the industry mainstream, it never stopped being developed, it is used in real projects, so I guess we can agree it's very much alive. Clojure in my very subjective opinion is doing a bit better than that due to ability to augment software written in Java. So while I don't believe it will conquer the world anytime soon, I also believe it's not going to disappear anytime soon.

>Clojure in my very subjective opinion is doing a bit better than that due to ability to augment software written in Java.

OCaml can embed or be embedded in native applications, but that's not the point.

I think that the main problem with Clojure is the lack of types.

Just look at how much Scala is more popular than Clojure, although it's also a strange functional language derived from OCaml/SML.

There is a common opinion that types are a necessity, even ruby, racket and python are adding them. Clojure people are just trying to substitute types with a runtime evaluated contracts/Hoare triplets, which is not an adequate substitution.

> swoop decided that Clojure was out, and we were no longer allowed to use it for new projects)

Can you share (some of) the reasons for that decision?

What had kept happening was that services written by my team (mostly doing Clojure for backend development) were taken over by other teams that either weren't interested in learning Clojure, or weren't allowed by management to do Clojure development (for whatever reason), so each time this happened our original service would be rewritten in Java or Node.

...of course, for the other team to be able to do this, they still needed to learn some Clojure in order to understand our code, but even in the cases where they actually liked doing Clojure, they were still forced to do the rewrite. The company was/is expanding very rapidly, so part of me can understand the decision to narrow it down to fewer "allowed" languages, to allow services/responsibilities/teams to move around more freely.

But it was one of the main reasons I decided to leave the company. I had joined after years hoping for Clojure to be my main professional programming language (for a substantial part of my career, at least), and I left a somewhat more bitter developer, but at the same time feeling a bit more free and relaxed - there are sooo many opportunities to pick from, now what I'm a bit more open when it comes to the tech!

I'll offer a different take: Clojure is settled. It found its niche: a small/medium group of experienced professionals who like its practicality and power. There's a comment somewhere else in this section that Clojure devs are more experienced on average than JVM devs. I'd like to add another stat from the State of JS survey[0] that went out a while back. Developers who used ClojureScript had the highest salaries and most years of experience when compared to other compile-to-js languages.

This narrative makes intuitive sense to me. Clojure is not the most beginner friendly language. It goes harder on functional programming concepts than the popular scripting languages, which is a bit of a learning curve. The cultural tendency to prefer smaller scoped libraries to broader frameworks means puts more cognitive load on the developer, who has to decide which libraries to use and how to wire them up. But this is a positive attribute for a more experienced developer, who might have strong opinions on how an application should be structured.

[0] https://2018.stateofjs.com/

> Clojure is settled. It found its niche: a small/medium group of experienced professionals who like its practicality and power.

Agreed. I'll add though that the problems with Clojure are soft ones. Here's my summation:

* it's business- and Java-friendly. Enterprise-focused.

* it's quite beautiful, though steeped in Java-isms

* its license is GPL-incompatible

* it's not a community-focused language and project; it's Cognitect's [edit: Rich's] project which they're graciously sharing with us.

That last one (IMO, the last two items) is a problem. For example:

* docstrings. Real improvements from the community?

* Lein? The clear winner, and yet for the longest time there was no mention of it in the getting-started guide on clojure.org, and then Boot was created. And then clj. NIH?

* It took ages until they began accepting PR's for their docs.

* I don't know the status of improving error messages. They've been complained about for years.

Clojure is Cognitect's [edit: Rich's] industrial-strength enterprise-ready Java-replacement and they sell consulting services for that. That's what Clojure is for and it's very good at that. It's also a seductively beautiful language, but if you're expecting a community-driven project with grassroots adoption and support, you're going to be disappointed.

Just a clarification, Clojure copyrights etc are owned by Rich Hickey, not Cognitect. Cognitect pays for all of the core development team salary, infrastructure, etc.

docstrings - we apply many docstring fixes in every release.

NIH - are we literally never supposed to try to make anything new? Doesn't this non-argument apply to literally the creation of every language, library, and tool? This is silly. clj has different (quite clear) goals than Lein or Boot and both doesn't do things they do (like builds) and does things they do not (like git deps).

We have been accepting PRs for docs on the site for 3 years. Who cares how long it took before we started doing that if we're doing it now? Wouldn't it be more productive to praise for what you like than crap on how someone used to do something you didn't like?

Isn't it a good thing that Clojure is such as productive tool that it can support a consulting company that can afford to pay decent salaries so the core team can continue working full time on Clojure making it even better? This is a good thing. I suppose we can also ignore the hundreds of tickets, patches, and contributors to the language, many of whom have nothing to do with Cognitect or their consulting, as that's more convenient for this line of reasoning.

Do you think Clojure would be in a better place today if it did not have this support from a company willing to champion it? How often has that been a successful strategy for languages?

> Wouldn't it be more productive to praise for what you like than crap on how someone used to do something you didn't like?

My apologies; I don't mean to insult. Thanks for the reply. My point is that it says something about what the core team thinks is important. Glad to hear that the team has been accepting doc PR's for years now.

> Isn't it a good thing that Clojure is such as productive tool that it can support a consulting company that can afford to pay decent salaries so the core team can continue working full time on Clojure making it even better?

I think we're arguing at cross-purposes. Certainly Clojure is a productive environment. But I'm interested in community-focused projects. These projects often have less corporate adoption than projects like Clojure. I was disappointed with Clojure, but not because it lacked a company championing it (it has one), not because it lacked corporate adoption (it doesn't), and not because there's anything in particular wrong with the language (I think it's an excellent language) -- by those metrics Clojure is certainly successful.

I'm amazed when people complain that they can't get their boss on board with introducing Clojure into their enterprise Java project. That appears to me to be exactly the market Clojure is targeting and succeeding in, when employed there.

From inside the core team, I feel entirely community-focused. I spent a good chunk of last year working on improving many aspects of error messages, the top community complaint in surveys. Currently I'm spending time working on spec and trying to guide external (community!) work on clj for Windows, also two things highly mentioned in the survey. I spent all day today answering dozens of questions in HN, reddit, slack, mailing lists, jira issues, github issues, etc. Not even sure how it's possible to be more focused on the community than I am.

Clojure on the JVM with Clojure libraries is one thing. Clojure with Java interop is quite another. Though a fine Lisp in itself, Clojure's identity is somewhat schizophrenic, hosted as it is on a platform designed for mutable OOP. This is the main reason most Java shops would never touch Clojure.

I personally believe that it is this sort of attitude that is driving some people away from Clojure. You could have easily structured your comment to be constructive instead of being defensive. The issue is not so much that people don't like how Clojure is managed, it is more so the lack of transparency and the (rather unprofessional) way that Cognitect (Rich) handles criticism and input from the community.

I get it. Clojure is Rich's gift to the world and he will do with it as he see's fit. That's all well and good but make that clear so that people thinking about checking out Clojure know it up front.

I don't get how you go from my comment to that. I literally talk to people all day long, every day, about what we should be doing in Clojure. The idea that this is "Rich's gift" and we're not taking input from others is just wrong.

http://insideclojure.org now has weekly journals detailing everything we're doing in Clojure dev if you're interested.

"clj has different (quite clear) goals than Lein or Boot and both doesn't do things they do (like builds) and does things they do not (like git deps)."

I think the build tool is the part of the tool chain where you most want a single project to rally behind. You want everyone building artifacts and expressing dependencies the same way.

Unless they all work the same at that level?

> it's quite beautiful, though steeped in Java-isms

Trying to understand what you mean here. I write a lot of ClojureScript as well as Clojure and I'm not seeing Java influences in there at all.

Could you expand upon your comment a little more?

Clojure is not the most beginner friendly language.

I really disagree here. My first job out of college was at a Clojure shop and it has been the easiest language I've ever learned. There is a small hurdle of switching to lisp syntax when all you've ever used is C style languages, but that's about it. I also find frameworks more effort to learn than pulling in a small library that does the one thing I need.

I can really only speak from my personal experience here. I learned Clojure on my own time in college, and it took some time for me to understand how to deal with things like immutability, laziness, and pure functions. After I did finally 'get' it, I was unable to convince any of my classmates that the initial effort was worth it. I love the language and its opinions, but JavaScript (another language I learned on my own time) was probably 10x easier.

"I learned Clojure on my own time in college, and it took some time for me to understand how to deal with things like immutability, laziness, and pure functions."

I suspect much of that time was spent "unlearning" habits from procedural languages.

I know Carnegie Mellon now teaches functional programming as the introductory course, and only introduces advanced topics like "mutability" later. I think that sequence makes it easier for beginners to reason about what their program is going to do and experience less frustration.

One thing that makes Clojure hard for beginners is the tooling.

For example, consider how a beginner can write Ruby and Python in notepad.exe while a lisp would be insufferable (and a common, awful first experience for that reason). Also, some of its best features, like cider/nrepl and Paredit, are hidden behind yet more tooling and keyboard shortcuts.

It's certainly a filter.

>>It's certainly a filter.

Absence of that filter is the reason almost all of the programming crowd today is locked into advanced beginner mode all life.

Is there one single beginner that starts their programming journey with notepad.exe? I've never seen a single one, and I see hundreds of them each year.

Notepad++? Textmate? Look at the first paragraph of the first chapter of Chris Pine’s Learn to Program.

Now that you've gotten everything setup, let's write a program! Open up your favorite text editor and type in the following:

puts 1+2 Save your program (yes, that's a program!) as calc.rb (the .rb is what we usually put at the end of programs written in Ruby). Now run your program by typing ruby calc.rb into your command line. It should have put a 3 on your screen. See, programming isn't so hard, now is it?

Why not just start at the REPL or with a Notebook? Having an interactive environment seems like it would be easier to learn the language. Then they can move to a code editor when they're ready for writing more complex programs.

It's this sort of thing that probably drives the likes of Alan Kay crazy when even learning a language isn't interactive by default.

I agree, but there is also something conceptually useful in learning early that a program is code saved in a text container that is then either compiled or interpreted.

The clojure equivalent isn't much worse:

   (println (+ 1 2))

Then

    clojure calc.clj

There’s mine? I used Notepad to create my first Windows .bat file (in fact, it was rather a juvenile piece of malware that opened notepad.exe thousands of times), which was the first programming I ever did. I later went on to use Notepad to modify files for a desktop game and write my first PHP and Ruby scripts. Now I write software professionally (including, but not limited to, Clojure) using a Mac :)

I did!

I used notepad when I first started learning PHP.

I don't see how that's implicit in the article at all.

Also, I don't see why we need to keep pitting languages against one another like this. Sure, there is a market, but can't we be happy that there is a diverse offering pushing language design forward? Not every language needs to become Java in terms of adoption.

In my last job I had two realms of development. The first was strictly based on what the company had been doing for years, what we expect new hires to know and what we touted as our language of choice. Embedded world that was C.

The second realm was languages that I picked purely because they filled a niche better than anything else. Often these were side projects, or tooling, or things that I could sell based on how quickly and efficiently I could get up and running with X language that would save us money even if we eventually had to replace it if no one learned it.

I used F# for big data processing because I am an FP guy and they wanted .Net and I could do data manipulation like nobody's business. I used tcl/tk because I needed a super quick and dirty UI for tooling that I could quickly update to add new features. I used Racket when meta programming would hugely benefit me.

The problem is that for a lot of our jobs we are stuck with realm 1, the things we can't change. This is the area where we end up pitting languages against each other because they end up used way more than realm 2. You have to push really hard and hope someone listens but more often than not you just keep on doing what you're doing.

I worked on a huge JVM based project and even though no one in the company knew Java there was just no selling upper management on using Clojure. FP would have reduced complexity, meta programming and dynamic code generation would have made it much more robust without a lot of effort, but it was just too foreign (or at least not advertised as being used in places well enough), too new, and when you Googled it the "major" issues developers had scared everyone.

> I worked on a huge JVM based project and even though no one in the company knew Java there was just no selling upper management on using Clojure.

Just tell management you're using a Java library called Clojure, they'll never know the difference ;)

What major issues?

Yes, but some developers only think in terms of maximizing their earning potential in the short term.

There are literally 10-100 times more clojure jobs in every market I’ve searched than Julia or D jobs. The ecosystem continues to evolve in new and exciting ways, and third party developer tooling and integrations keep expanding. HN has been bullish on D for at least 10 years going and yet all the _new_ systems programming roles in my city are C++ and a bit of Rust.

"title:Clojure"/United Kingdom at Indeed.co.uk produces 4 Clojure jobs. Go figure.

I’ve been a software engineer and a backend engineer but I’ve bever been a “clojure engineer”. Why needlessly require the language in the title? Any reference to it anywhere in the body is unambiguously referring to the same programming language.

Anyway, using LinkedIn, roughly 70 results in Boston, 30 in Denver, 130 in San Francisco. 867 across the US. I worked for three years with clojure and just chose between two new job offers after a short search, also in clojure. I’m seeing the language get use in microservices in larger, more established orgs that may already have a jvm docker image that their devops supports.

Alternatively you could just not badly interpret gossip and turn it into unfounded broad pronouncements.

You are the guy who manages to turn the rumor that Clarice in accounting is home sick with a cold into Clarice is dying of cancer.

Curious, can see for it for Julia but what interesting stuff is D doing?

Being a systems programming language with a GC, following the footsteps of Algol68 RS, Mesa/Cedar, Oberon, Oberon-2, Component Pascal, Active Oberon, Sing#, M#,...

Coupled with powerful meta-programming capabilities, while having quite fast compilation times.

They just suffer from being a tiny community, so everything kind of improves slowly.

And Go and Rust stealing their thunder in terms of mind share.

While on the other extreme, Java and .NET keep improving their tooling and features for AOT compilation and low level programming, with OS platforms to go along.

It is not easy to find that sweet spot that makes a language take off.

Ruby was unknown for almost a decade until Rails came along, for example.

Be careful, Clojure people might call you entitled and let you know that Cognitect/Rich Hickey is developing Clojure after their own needs, not yours.

What your need that is not addressed by Clojure because it is developed after Rich’s needs?

The trend of programming languages is to move toward static typing. Not as an afterthought, with gradual typing or retrofitted years later into an unwilling compiler, but languages designed from day one with static typing, parametric polymorphism, and type inference.

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

> 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?

https://github.com/stathissideris/spec-provider

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."

Reply on news.ycombinator.com