HN Theater @HNTheaterMonth

This talk goes into detail how Clojure plays out in larger teams, particularly how they worked to maintain REPLability for a huge monolith: https://www.youtube.com/watch?v=BThkk5zv0DE

That said, I think a lot of the preoccupation with rewrites is just premature optimization. Just a while ago I noticed some open source Clojure code of a startup acquired by FB got rewritten in Haskell. Was very glad to see founders don't seem to be working on this new code-base. Probably moved on to do higher value things.

⬐ truculent

FWIW I think this is the startup code referenced: https://github.com/wit-ai/duckling_old

⬐ auganov

Yep, that's the one

Of course there are always tradeoffs to make when choosing a language, especially if you expect "enterprise" scale. Others will choose (and have chosen) a dynamic language, even if you don't; many dynamic languages can scale to mega sized systems just fine. (Here's an interesting talk from a while ago from a startup thinking about building for a scale beyond what startups normally deal with, and how Clojure was a nice fit for them: https://www.youtube.com/watch?v=BThkk5zv0DE)

Changing languages also has a bunch of tradeoffs, but in mega sized software you ought to have already solved the modularity problem that lets you get that big in the first place. Being well modularized, you should be able to introduce a new language without too much impact on the rest of the systems. I used to be pretty pessimistic that more interesting languages could never be introduced to BigCo and survive, but seeing the evolution of JavaScript and Java play out, plus what's going on in mobile with Objective C + Swift and Java + Kotlin, and BigCo developers adapting to all this new syntax (both JS's and Java's latest versions are very much completely new languages compared to what the codebases started in) I'm more optimistic that developers can in fact be taught something new. The real difficulties are political, and only one minor component of that is being able to reassure that learning is fairly easy and possible.

⬐ watwut

None of what you wrote make dynamic language better for that particular task or easier to use for such task. It just makes it possible if you put in additional effort.

Of course big companies use all kind of languages, what they don't do is using it for enterprise bussines project. Javascript or kotlin being used for something else in same company is irrelevant.

The issue is not even syntax, that is why it is no problem to update Java. The tooling around it still works the same, ecosystem works the same. The issue is any programmers ability to figure out someone else's code - meaning importance to compilation errors being visible at compilation time, trustworthy "find all callers" etc.

Of course developers can learn something new. That does not mean that the new thing is suitable for task they are working on.

Also, framing everyone who disagree with you as incompetent is awfully dishonest tactic. Suitable for toxic corporations (and toxic startups) for sure, but not something that should work in any kind of rational workplace.

⬐ Jach

I'm not making the argument that dynamic languages are better for any particular task; I assume it, but that's a separate issue. Your comment says you would not use a dynamic language for a "large project expected to live long nor the kind of projects that is currently done in "enterprise"" on the basis that by switching to dynamic languages you save on some pattern cruft. My comment is agreeing, there are other tradeoffs to consider, I wouldn't necessarily expect anyone to switch languages just on syntax. The second half of my comment was considering another tradeoff, which is "do developers need to learn something new? can they? will they?" and more importantly for management "do we need to allocate more time for onboarding?" and the related "does this shrink our hiring pool and by how much?" Even if weighing those favor choosing (or moving to) a particular dynamic language, of course that might not be enough to change! Tooling is a factor as you point out, but there are even more tradeoffs to consider.

Big companies do in fact use dynamic languages for big enterprise business projects. I work for one, we (among many, many other big companies -- though I'm not sure what your cutoff point for big company is, we're not one of the two Trillion Dollar Behemoths if revenue is a factor) use JavaScript extensively, if not exclusively. It's not "for something else", the business depends on JS. Take away the mobile apps, ok we can live, take away the JS, um, what's going to talk to our equally important server and database code? (Not to mention do all the important things that are only implemented in JS rather than the backend?)

> Also, framing everyone who disagree with you as incompetent is awfully dishonest tactic. Suitable for toxic corporations (and toxic startups) for sure, but not something that should work in any kind of rational workplace.

Ok? I don't disagree and don't think I've ever framed people that way unless it was a joking reference to Linus Torvalds' git introduction 10 years ago for a Google presentation where he defined those that disagree with him for the duration of the talk as stupid and ugly. I'm not sure if you're on a tangent or something in my comment (or the video I linked?) gave that impression.

⬐ watwut

Then why pick the "developers have to learn something new" as tradeoff to discuss? That is odd choice as I don't recall unwillingness to learn language to be issue, ever. Nor was bigger issue to find programmer for language that is not obscure.

I did not meant project by big company. I mean large project of the kind people call enterprise, regardless of whether it is done by big company or small contracting company with freedom to choose tech (pretty common here).

Yes mobile and quick responsive frontend in js are necessary, but they are also more expensive and time consuming to produce larger project. It is harder to maintain in them and harder to do more complicated business processes in them. Refactoring messy javascript is much harder then refactoring messy static code.

Hence, popularity and all that hope towards typescript and flow and what not.

⬐ Jach

I picked it because it's relevant to my own experience and what I see in broader tech, maybe your part of the ecosystem is better? (If memory serves the "stack overflow crowd", the people who answer the surveys each year, are better at self-learning, but they're also much younger so there's a forcing element, and I still think represent a minority anyway.) I see that people have little interest in learning new things (whether it's languages, tools, concepts, or history) unless there's a strong incentive to do so, and even then there's resistance to change. Additionally the issue of finding programmers always seems to come up where I look -- I don't think Clojure is any more obscure than Go, yet in the video I linked they still had to onboard 50% of new hires in the language. For some companies that alone might be considered too much cost for the benefit.

If a big company example isn't needed, you might be interested to know that https://www.ptc.com/en/products/cad/elements-direct/modeling exists -- I read somewhere it's made of several million lines of Common Lisp and has been developed over decades.

Agreed that JS refactoring is often harder, though I don't think it's bad enough to say it's "much harder" than e.g. Java, and I'd prefer refactoring a large JS project to trying to refactor a large C++ project. Still, the bar for dynamic languages that JS sets is pretty darn low. Python, Clojure, and especially Common Lisp all do much better on the refactorability metric along with other metrics that people who prefer static typing usually care a lot about (e.g. warnings/errors about trivial misuse before runtime).

We use lots of Clojure at Amperity - https://www.youtube.com/watch?v=BThkk5zv0DE&t=1s