Hacker News Reader

I agree, strong barriers between layers are important. Right now the best way to build them is by using different languages or runtimes - it’s hard to mix layers if they require explicit network or shell calls.

If everything was in lisp the layers are naturally blurred.

Racket is a Lisp that makes these layers somewhat explicit.

Good SW engineering practice helps. Code review, collaborative design, etc.

There are perhaps languages out there which are better than Lisp for maintenance in some respect, but it's none of the mainstream ones. Lisp code is not particularly harder or easier to maintain; most of that depends on the original author(s) as with any codebase.

It's the reason Aaron Swartz gave for rewriting reddit in python:

>The others knew Lisp (they wrote their whole site in it) and they knew Python (they rewrote their whole site in it) and yet they decided liked Python better for this project. The Python version had less code that ran faster and was far easier to read and maintain.

http://www.aaronsw.com/weblog/rewritingreddit

I suspect the problem is that LISP is too powerful. Language power is inversely related to maintainability/readability, as per the greatly underrated rule of least power: https://en.wikipedia.org/wiki/Rule_of_least_power

This. I find Lisp optimal for the small band of coder heroes scenario. They must align on cs philosophy, and taste. Grow the team, or have divergent approaches: the efficacy of Lisp quickly disappears and problems appear.

Is that hearsay, experience or a guess?

There have been a few projects with 10 to 100+ Lisp programmers. What was their experience?

Well, at some point we have to face reality. There have been hundreds if not thousands of successful projects with teams of hundreds if not thousands of developers working on them, at the same time or over time. These projects have been generally in Cobol (ok, we can chalk that up to brute forcing a tech from they didn't know any better), C, C++, Java, C#.

There seems to be a connection between scaling a project regarding developer numbers and programming language "power". Having a smaller, shared vocabulary seems to greatly outweigh programming language "power" as the number of programmers goes up greatly.

Lisp had 60 years to prove its human scaling capabilities. So far it hasn't convinced.

> Lisp had 60 years to prove its human scaling capabilities. So far it hasn't convinced.

It can take more than you might expect to "convince".

> In 1601, an English sea captain did a controlled experiment to test whether lemon juice could prevent scurvy. He had four ships, three control and one experimental. The experimental group got three teaspoons of lemon juice a day while the control group received none. No one in the experimental group developed scurvy while 110 out of 278 in the control group died of scurvy. Nevertheless, citrus juice was not fully adopted to prevent scurvy until 1865.

( https://www.johndcook.com/blog/2008/03/25/innovation-ii/ )

I know about that the whole lime - lemon thing. Two things:

1. That was before the scientific age. They didn't know about vitamin C at the time, they couldn't even see it, even if they'd somehow believe in it.

2. There is no scientific proof, 0, none, that Lisp is superior. And it's almost impossible to prove it, since it requires controlled studies at a large scale - good luck with taking away hundreds of productive programmers for that study :) All we have is hearsay and personal opinions.

And all managed languages that still provide halfway solutions for what was the Interlisp-D/Lisp Machines developer experience.

I love how I'm being downvoted for saying that there's no scientific proof that Lisp is superior. Come on, show it, I want to see it. I want to see thorough, statistically representative studies that show Lisp's superiority :)

"How the strengths of Lisp-family languages facilitate building complex and flexible bioinformatics applications."

https://www.ncbi.nlm.nih.gov/pubmed/28040748

-- US National Library of Medicine National Institutes of Health

"Clasp: Common Lisp using LLVM and C++ for Designing Molecules"

https://www.youtube.com/watch?v=0rSMt1pAlbE

-- GoogleTechTalks

That's nowhere near something like medical clinical trials, though.

Think of studies where you:

a) have statistically representative sample size (100+ developers)

b) actual numbers and compare them (the average development time needed for the Java/C++/etc. applications was Y and the average development time needed for Lisp applications was Y - Z, where Z > 0, etc.; the average execution time for Java/C++/etc. applications, etc., you get the idea)

Computer Science studies are still in their infancy.

All this Lisp hype is just hype and gut feelings.

There's Lisp as an Alternative to Java: http://www.flownet.com/gat/papers/lisp-java.pdf

> I know about that the whole lime - lemon thing.

Be careful; my quote has nothing to do with the confusion between lemons and limes that occurred hundreds of years later. The Navy instituted a lime juice ration in 1799. They switched out lemons ("limes") for what we would call limes in 1865, setting themselves up for the reintroduction of scurvy. But James Lancaster performed his experiment (and reported his result of 100% scurvy prevention to Naval authorities) in 1601.

And even in 1911, Scott's expedition suffered from scurvy, mainly because they misunderstood its cause! http://idlewords.com/2010/03/scott_and_scurvy.htm

Sooo...what would be the "programmer scurvy" Lisp (and especially Lisp) could help to prevent?

I have heard that the British knew what caused scurvey, and how to treat it with citrus, but they kept it a closely guarded secret to keep an advantage vis-a-vis other countries navies.

That is more or less correct, but it's a very weird situation. Scurvy had been known -- along with effective cures -- for thousands of years. The method of curing scurvy hasn't been secret since -- at the latest -- the Ebers papyrus of ~1500 BC, which correctly prescribed feeding the patient an onion. And in fact cures were widely known throughout the world since that time, including in Europe. Note again that James Lancaster had heard that lemons were effective against scurvy, 200 years before the Navy got around to requiring them.

From https://tudorblog.com/2012/06/16/voyage-of-the-scurvy/ :

> from about 1500 to 1800 two million sailors are estimated to have died from scurvy on expeditions to Asia, Africa and the New World.

> Why no cure? In Tudor England an effective treatment, scurvy grass (a corruption of cress), was commonly recommended; at the same time the Portuguese knew a cure, and so did the Spanish and the Dutch. For unknown reasons such wisdom was applied inconsistently (even by Britain’s Royal Navy after the Napoleonic Wars) until the identification of vitamin C in the 20th century.

It looks more like a case of the people making the decisions being unfortunately disconnected from the people who knew what scurvy was and how to deal with it. (And wilfully ignoring those who tried to point it out to them.)

> There seems to be a connection between scaling a project regarding developer numbers and programming language "power". Having a smaller, shared vocabulary seems to greatly outweigh programming language "power" as the number of programmers goes up greatly.

That goes against evidence from current enterprise software experience. The Java eco-system has the absolute largest programming vocabulary ever (J2EE, JEE, ...) and is widely used.

AT&T/Lucent once wrote the software for a telephony switch in Lisp - I think the project ran over a decade and created more than one generation of working/shipping hard&software. The team was easily 100+ people. I heard a talk of the responsible manager years ago. They wrote basically the same functionality as a ten times larger C++ project and the Lisp team lead was extremely satisfied with what they wrote.

AT&T Management favored the C++ project for mostly non-technical reasons - C++ being an 'industry language' with a larger supply of developers. Not surprising for AT&T - Ericsson made a similar decision at some point in time with their (later lifted) 'Erlang ban'.

We have to decide what's enough to convince (and convince whom) I guess.

Just to throw out a couple of examples:

One of the larger businesses I'm aware of that's using a Lisp is Nubank in São Paulo. Valued at $1bn+ and 4 million paying customers[1]. Finance is a fairly complex domain.

King in Stockholm has also fairly recently rewritten their main game creation tooling in Clojure[2].

1: https://www.reuters.com/article/nubank-creditcards/brazilian...

2: https://techblog.king.com/how-we-use-clojure-at-king-to-writ...

I have experience of great success and productivity in small teams with Common Lisp and Clojure. I don't have direct experience of dysfunction in a larger Lisp team. That was a guess based on how being a senior dev in a 50 man C# shop felt :)

It strikes me as a matter of structure. Lisp provides almost none, whereas python provides more. Anything not provided by the language and environment must be provided by the team. If they can, that's great, but it's going to be easier to get a small team to agree on a structure than a large one.

Wouldn't say so, there are plenty of conventions and common practices shared by overwhelming majority of Lisp developers. Project structure, system definition, development environment, naming conventions, idiomatic use of data structures and object system, all that is established across the board.

> Language power is inversely related to maintainability/readability,

Is that really True?

Having worked on VB6 codebases in the past, the less powerful nature of the language just meant a LOT more code which is definitely harder to maintain.

It's inversely proportional to length too. Maintainability is about maintaining a delicate a balancing act between several competing fundamental concerns - two of which are expressiveness and verbosity.

I think python's popularity is partly because it found a sweet spot that was neither too expressive nor too verbose. It's certainly possible to dial up the expressiveness (LISP, Perl) or dial it down (Golang, VB) and get something that is harder to maintain both ways.

Python derives a fair amount of expressiveness from the power it gives to library authors. A lot of this in turn comes from its dynamic implementation.

As a library author you can write effective python at different levels. Some involve quite heavy meta-programming (jinja2, collections.namedtuple, django's ORM) and most users would never find this out.

Python has C++/Lisp level of power, but since many just do toy scripts they don't realize it.

Again I think Perl / Python are a perfect example of why post I was responding to is not true.

> Language power is inversely related to maintainability/readability,

Perl and Python are both considered equally powerful languages, yet Perl is a fair bit more expressive and as a result is often harder to maintain.

No, it’s not, and even if it were true it wouldn’t disqualify lisp, since you can quite happily wield lisp in a context which lets you express logic in simpler/constrained forms. Consider hiccup, datalog DSLs, etc.

Well,

The law of power linked above says to use the least powerful language appropriate for the task. So it's possible VB6 fell into the category not-powerful-enough/not-appropriate.

Well I don't find mature Python codebases (e.g. Homeassistant) particularly easy to inspect or change. Guess that's where me and 2005 Aaron Swartz would disagree.

What language's mature codebases do you find particularly easy to inspect or change?

None, which was my original point. The difference between the projects/teams easily trumps whatever is there between the languages.

When I talked with Alexis Ohanian he told me that the Lisp version was difficult to keep running. I think the term he used was that it often fell down.

I don't use it, but I'm not noticing any such backlash for Clojure

>>Statement like these are what make me suspect Lisp code would be a maintenance nightmare.

After having maintained Java code bases that do 300 classes just to post a JSON to a REST end point, I'm fairly confident Lisp code can't be that hard to maintain.

Yes, this is why macros have been abandoned in most entreprise languages (C#, Java)

As if they've tried them and then abandoned them? Java, fone one, didn't even have generics and closures when it came out.

It didn't have macros because it was intended for the ho-hum enterprise programmer of the time, who, the thought was, would not know what to do with them.

Instead, they re-invented all those things badly (e.g. through gobs of XML and ugly reflection based metaprogramming).

Nobody still uses them, even if they are available. In fact anything that doesn't looks enterprisey enough never goes past code reviews.

The adoption cycle for even the simplest of Syntactical features when it comes to Java enterprise is >10+ years. In some companies its never.

The saddest part isn't even that. The sad part is a whole generation of programmers have been raised, and turned to be architect astronauts without ever using something like a lambda or a closure.

The only hope for programming as a craft now is hoping Oracle kills Java(even if by mistake), and then some thing like Perl 6 comes along to replace it.

I'm not sure that will help. I see a kind of "family resemblance" between COBOL and enterprise Java. I wonder if any language that is going to play in this space is destined to become a monstrosity - destined by the nature of the problem space rather than the nature of the language.

I am aware that when I say this, I am basing my opinion on a sample size of two...

Nonsense, the enterprise programmer of the time was programming in C or C++ and was making heavy use of macros.

Macros, unlike generics are super easy to implement, so there is no reason not implement them, unless you specifically don't want to implement them.

Java didn't have macros because no one wanted the kind of dialect that macros allow, ie. re-learning a language every time you change company.

> Nonsense, the enterprise programmer of the time was programming in C or C++ and was making heavy use of macros.

C macros are entirely different in use from Lisp macros. C macros are written in a text substitution language that knows virtually nothing about C, whereas Lisp macros are written in Lisp and operate on regular Lisp data structures. Even trivial things are very difficult to get right with C macros, whereas very complicated things are often elegant and simple with Lisp macros. It's an entirely different experience. They're not at all comparable.

C programmers learn to fear macros because C macros have a lot of problems. Few of those carry over to Lisp macros.

then again enterprise software and languages are also full of sdls, plugins, frameworks, libraries and other pieces and parts that enable the same kind of power that lisp has.

People haven't really given up on the idea of building out functionality for specific portions of their codebase (and we really shouldn't) we've just seemingly exchanged one very powerful solution for a sea of different tools.

Actually C# and Java do have macros, they just aren't on the syntax level.

Attributes/annotations, compiler plugins, expression trees and aspects take the role of macros.

The more power and liberty a language offers, the more likely you will end in the state of "write once, never understand again".