1. 10
  1. 17

    Point eight on my outside view checklist:

    Do they refuse to acknowledge any downsides or tradeoffs of $THING versus other approaches? If there are tradeoffs, are they just humblebrags like “this doesn’t work with corporate drones?”

    1. 5

      Thanks for sharing this link; it seems like a very valuable tool.

      1. Are they fixated on an “enemy” technology they blame for modern computing’s problems?

      You don’t see it as much these days, but in 2009 when this article was written, its author and many other Common Lisp fans would go off at the drop of a hat about how evil Java was and how anyone using it must be a brainwashed corporate drone.

      1. 3

        That was a good list, thank you. Also, props for debunking Carl Hewitt, it’s sorely needed.

      2. 9

        Interesting comment from Peter Norvig there: http://www.loper-os.org/?p=69#comment-17594

        There are other languages which allow developers to be very productive, and all it takes is spending a bit of time learning them. Having said that, I do agree with the thesis that corporation value fungibility of developers a lot, and I find that soul crushing.

        1. 8

          The response to that by the website’s primary author is as classy as usual, too. With friends like these…

          1. 6

            I think “fungibility” is a particularly pessimistic view. The same benefits that facilitate “fungibility” in a corporate context also facilitate collaboration generally including in the open source, research, and just-for-fun worlds.

            1. 4

              Counterpoint: If you work on something truly valuable to society, it’s irresponsible to make it depend on you alone. We humans are fragile creature, after all.

              1. 3

                Agree, although this is an extreme example. There aren’t that many things that are truly valuable to society. Most of the time, it’s valuable only for your corporate overlord as a mean to extract money, and if that goes up in flame, I won’t feel bad at all.

            2. 8

              The argument here feels pretty odd to me. “Lisp prevents developers from being fungible” is a stone’s throw away from, “Lisp developers write code that nobody else can maintain.” Which I know for a fact isn’t true (or at least not universally true) but it doesn’t seem like a great sales pitch.

              I don’t want to go on vacation or quit a job and have my project fall apart because I was completely non-fungible.

              I also fundamentally disagree that companies in general are unwilling to let developers use tools that maximize productivity. Sure, there are companies where godawful tools get mandated from above (say “Mulesoft” to me and watch my eye twitch) but there are also a lot of them where the engineering team has free rein to choose its own tools.

              This post should be tagged rant IMO because it comes off like a bitter rant.

              1. 4

                I agree with this criticism, and my limited, unprofessional experience with Lisp macros and similar features has been than I am a fungible cog when I return to a project after a few months away. I might half-remember where the clever bits are, but not how they work or what the gotchas are.

              2. 6

                To say that Lisp is the epitome of languages is foolish – and when you release yourself from that “insight”, things start to look a hell of a lot better. Ruby, for example, was huge in developer workflows at the time. And yet we can see very clearly it’s expressive power, and it is precisely because it is a derivation directly from Lisp and Smalltalk! Ruby is a rather strange language to get used to from Java, so how does this come about? Why did legions of Java developers find themselves writing Ruby? The reason for it’s mass adoption is strikingly clear and can be traced directly back to – Ruby On Rails.

                You see, if Lispers had been inclined to be communal, social, human beings, rather than the anti-social, “lone wolf” stereotype they self-branded as (Which is in fact a non-sequitur. Wolves move in packs and are social animals too, lest humans might never have formed as deep a relationship with them!), they could have built wonders. Imagine what the software landscape might look like today if Liquid On Lisp was the style of the time!

                What limits commercial adoption of Lisp, and it’s relatives, is the fact that while you can design everything from scratch in a weekend, that is a weekend that you could have spent actually finishing and polishing the thing you wanted to make! Instead, because of this stereotypical behaviour, you are left with fixing up an unfinished, half-built, crufty core of a library that was beautiful at first, but doesn’t implement half of the things that you need! That is, if you can even find an implementation of what you want, which half of the time, you can’t.

                How can Lispers claim expressive power, when it takes days to do what Ruby On Rails can do in minutes?

                You need to, just to get somewhere. And all that, from the point of view of an employer, is attractive. Ten people who communicate, document things properly and work together are preferable to one BBM hacking Lisp who can only be replaced by another BBM (if you can find one) in the not unlikely event that he will, at some time, go down without being rebootable.”

                Well, err, yes. Yes exactly. It’s not good for anyone, even if you are not in a company, if the developer of the software you need a) hasn’t documented anything, and b) has got hit by a bus!

                Communication is a natural consequence of working, while you may think you work alone, you do not. You must build according to those who pay you, there are limits on what you yourself put in the design based on the ideas you have come into contact with, through talking with others. You might sit alone at your desk for the writing-the-code, but the entire lead up to that is communication, and planning, however unconscious. You need a mental model of what the thing looks like to actually build it. Thus communication is an integral part of design.

                Processes are a natural consequence of design, while organic design is venerable, humans still largely prefer paths and walkways to muddy dirt. You can see this with electronics, too – Electrical Engineers don’t design on the fly, they design beforehand, to the point that likely 70% upwards of the work of EE is design work, even back in “the old days”. You can claim you are closer to the “old” school of computing. But mathematicians, electrical engineers, etc. – the second generation of programmers of the 60s - 70s, all spend large amounts of time thinking about design – whether consciously or unconsciously. The noticing of patterns in how people implement, was Christopher Alexander’s revelation, that came from thinking about design – “How can we design better? What are the major features of designing a Thing (in general)?”. Therefore, building blocks of designing (patterns) can be formalized into a Process, by noticing the benefits and negatives of each pattern, and formalizing those constituent parts once again into a generalized guide of what is best for each scenario – what has been found to consistently fail, what patterns should not be recommended for such a moment.

                While you may not actively be thinking about this during programming at any given time, it is worth considering that you are likely bound to these patterns even if you attempt to grow the program organically – since they essentially describe concepts “already encountered in the wild”. While in a modern form to middle management they may represent some form of Robustness guarantee, they also represent a normal development in a field, and a normal development of thinking about programs in a scientific way full stop.

                It would be foolish not to pay attention, as a new woodworker, to the volumes produced thusfar, would it not? You could end up building a chair that collapses, and while you might learn that lesson, unneeded resources are expended. Likewise, it is foolish as a programmer in the modern environment to ignore processes and patterns developed over time, lest you spend unneeded resources developing code that turns into waste before your eyes.

                So yes, while tools that limit patterns in turn limit design, they can also provide guarantees. They provide the guarantee that you haven’t, for example, shot yourself in the foot during the design process. All of which come back to wasted developer time. Surely a time loss can be said to be a negative thing, right?

                1. 4

                  Innovation isn’t everything. In fact it is only a minor part of modern software. The majority of modern software development is infrastructure building. Imagine I thought up a way to use commonly used programming paradigms to, for example, create a system that ensures poor children get free meals at schools, and then set a non-profit with a tiny budget. I might ask for programmers to volunteer or work for cheap because it is a good cause. I might hire someone and find they are not a good fit for the project. Programmer fungibility is extremely important, innovation is not. Yes innovation has its place in the same way that pure science research has its place, but if I am making t-shirts I am not looking at the newest techniques for spinning carbon nanotubes.

                  The issue with big corporations preferring developer fungibility is not the preference, it is the corporations. Their goal is to make a profit, this means that they will underpay their staff and under serve their customers at the same time if they can get away with it. The increasing disuse of anti-monopoly legislation and the increasing amount of control that corporations exert over governments through lobbying and campaign financing means increasingly that we live in a world where giant mega-corporations grow unchecked and dominate more and more of our daily existence. This, coupled with the fact that they are basically economic predators that have no interest in human well-being at all is the real elephant in the room.

                  This is not meant as an argument against lisp, quite the opposite in fact. If lisp promotes innovation at the expense of developer fungibility it seems a perfect fit for software research, and also for creative hobby projects and any reasearch that uses software as a tool and investigates anything sufficiently abstract.

                  1. 1

                    Ever wonder why it is customary to speak of the wildly different Common Lisp, Scheme, ZetaLisp, Emacs Lisp, etc. as though they were a single language? I would like to suggest that we start referring to C/C++, Java, Python, etc as ALGOL.

                    It’s tempting to just say, “we usually don’t consider Scheme and Common Lisp to be the same language,” but there’s actually a deeper reason for the author to feel this way. Languages with macros can have dialects which originate from libraries. This also happens in C++, where Boost is a dialect; in Java, where Spring is a dialect; and in Python, where Numpy is a dialect. The author merely makes the mistake of thinking that Scheme and Common Lisp are dialects of some single common “Lisp” language.

                    1. 4

                      I don’t know if this specific author is guilty of this, but I have encountered CL programmers who intentionally conflate CL and “lisp” because they believe CL is the only One True Lisp, and all the others are pretenders to the throne that don’t deserve recognition.

                      1. 2

                        As someone outside the LISP community looking in, I often think of Scheme and Common Lisp as the same—they both have an annoying amount of parenthesis, they both have CAR and CDR and both use lists as the only data structure [1]. A better example is C and C++. There are plenty of people who still think of C as a subset of C++, when that hasn’t been the case since 1999.

                        [1] There was that Lisp class I took at college, but it never got around to mentioning any other data structure than the list. Even ANSI Common Lisp takes it sweet time to mention anything other than lists.

                        1. 1

                          The author merely makes the mistake of thinking that Scheme and Common Lisp are dialects of some single common “Lisp” language.

                          Really? Bringing up the extremely tired “Is Scheme Lisp?” argument? Please find a new holy war.

                          1. 1

                            Go on; what do you think I said?

                            1. 2

                              I think you misunderstood (or at least the comment you wrote conveyed that you misunderstood) the OP and interpreted the comment “as though they were a single language” to mean that the author does in fact think they are all dialects of the same language.

                              That being said, I think I also misunderstood your comment about “some single common “Lisp” language” to mean that you see Scheme as “not a lisp”, whereas I think now that you meant that they are separate languages like C and Java, regardless of their lineage or lisp-ness.

                              My apologies for misunderstanding you.