How knowing Lisp destroyed my programming career (2006)

Not quite. "Smartass" generally implies you go around showing off your (perceived) knowledge. "Smug" implies you sit quietly in a corner feeling good about your (perceived) knowledge.

Code generation is great. If you have a well understood domain, Lisp macros allows you to construct an effective DSL so that your programmers no longer have to write "lisp code" but to program in the new language. We do this today using functions/methods, but the issue tends to be that besides understanding these functions, we need to learn how to orchestrate them and write boiler code all around them. A good DSL hides all that. The issue as I've observed is that when most people create a DSL, they really forget that they have indeed created a new language and don't document it enough. The consumers of the DSL because they can read lisp code, don't focus and live in the DSL layer but wish to peer below then get terrified when they see the macros. Most developers get terrified when they peer one level below. Have you seen the bytecode generated by python or asm code by C? Do you think those are bad because those are code generation that don't look the way you think they ought to?

Whatever programming language you are using, at some point or at some representation the compiler will start generating code. The difference is that the default code representation of lisp allows it at source level, making writing (and debugging) them a lot easier. An if statement in python generates a shitload of bytecode that the optimizer then does what it pleases to. With lisp you can watch that process by watching the source->source transformations of macros and the optimizer.

Macros allow us to extend the language. It is not just C-like code generation. The loop constructs of common lisp, or the for loops of racket (or my own reimplementation for guile scheme) are macros.

With lisp macros we can express zero cost abstractions that in other languages would have a lot of overhead, and make them feel like a regular language construct (CLOS started like that)

My own racket-like loops for guile generate code that the optimizer can then turn into optimal code: https://bitbucket.org/bjoli/guile-for-loops/overview

The downside being that macro expansion slows down compilation. My workstation can expand about 1000 loop macros/s with guile and a couple of orders of magnitude more using my chez scheme prototype (somewhere above 100k)

Why do you need the meta-capabilities of lisp? Well, language designers are human and can't predict all the features that you might find useful. Take, for example, list comprehensions.

I added some basic ones to common lisp in a couple of minutes.

  (defun read-comprehension (stream char)
    (declare (ignore char))
    (destructuring-bind (expr for var in list &optional if filter-exp)
        (read-delimited-list #\] stream)
      `(loop ,for ,var ,in ,list
          ,@(when filter-exp `(,if ,filter-exp))
          collect ,expr)))

  (set-macro-character #\[ #'read-comprehension)

  (eval (read-from-string "[(+ x 1) for x in '(1 2 3) if (> x 2)]"))
  ;; => (4)

> I much more need a syntax that does not hide what happens

Yes sir!

> (procedure call,

   80febf0:	08 
   80febf1:	c7 44 24 04 01 00 00 	movl   $0x1,0x4(%esp)
   80febf8:	00 
   80febf9:	89 3c 24             	mov    %edi,(%esp)
   80febfc:	89 44 24 0c          	mov    %eax,0xc(%esp)
   80fec00:	e8 cb c8 f4 ff       	call   804b4d0 <__fprintf_chk@plt>

Gotcha covered there too!

    80fd7eb:	8d 7c 0e ff          	lea    -0x1(%esi,%ecx,1),%edi

> I much more need a syntax that does not hide what happens (procedure call, list indexing or at least "indexing").

Each of those is actually hiding what really happens. E.g. for a procedure call the runtime compares the arity of the call and the called function, inserts each argument into a data structure of some sort, perhaps grafts together environments or does other things on a language-specific basis, performs a jump of some sort, then the called function takes over, and finally stashes its return value(s) in a data structure of some sort and performs another jump.

Even list indexing in a language like Python is relatively complex, involving a lookup of the list length, bounds-checking &c.

> Code generation is mostly bad, it typically means the problem wasn't thought through, and that there is a lack of clearly defined building blocks.

Proper syntactic abstraction is all about building the right blocks for the problem at hand. At the end of the day, all we have are bits of silicon transferring electron: everything above that is an abstraction. A sufficiently-powerful programming language enables the programmer to develop the abstractions he needs for the problem he has.

Code generation is brilliant. Remember that a compiler is a code generator. Using your own code generator allows you to declare what you want at a high level and then generate bug free code that implements it. It is like having a super fast automatic programmer at your side making you super productive.

>Code generation is mostly bad(...)C structs and enums,

C macros (or "C code generation" if you prefer) is very, very different from Lisp macros.

Lisp macros are built into the language, the whole language itself is designed around this capability.

Macros/Code Generation used correctly is exactly the opposite of what you are saying. Macros/Code Generation used correctly forces you to figure out at a much higher level what it is you want to achieve. And declare it in a formal computer readable way.

Looking at a page about list comprehensions in Python.

  S = {x² : x in {0 ... 9}}
  V = (1, 2, 4, 8, ..., 2¹²)
  M = {x | x in S and x even}

  S = [x**2 for x in range(10)]
  V = [2**i for i in range(13)]
  M = [x for x in S if x % 2 == 0]

Perl 6 closest syntax to original

  my \S = ($_² for 0 ... 9);
  my \V = (1, 2, 4, 8 ... 2¹²); # almost identical
  my \M = ($_ if $_ %% 2 for S);

  my \S = [-> \x { x**2 } for ^10];
  my \V = [-> \i { 2**i } for ^13];
  my \M = [-> \x { x if x % 2 == 0 } for S];

  my \S = (0..9)»²;
  my \V = 1, 2, 4 ... 2¹²;
  my \M = S.grep: * %% 2;

  my \S = (0..*).map: *²;
  my \V = 1, 2, 4 ... *;
  my \M = S.grep: * %% 2;

Python

  string = 'The quick brown fox jumps over the lazy dog'
  words = string.split()
  stuff = [[w.upper(), w.lower(), len(w)] for w in words]

  my \string = 'The quick brown fox jumps over the lazy dog';
  my \words = string.words;
  my \stuff = [[.uc, .lc, .chars] for words]

  noprimes = [j for i in range(2, 8) for j in range(i*2, 50, i)]
                         range(2, 8)
                for i in
                                              range(i*2, 50, i)
                                     for j in
              j
             [                                                 ]

  my \noprimes = (2..^8).map: { |($^i*2, $i*3 ...^ 50).map: { $^j }}
                 (2..^8)
                        .map:
                              { |($^i*2, $i*3 ...^ 50)             }
                                                      .map:
                                                            { $^j }

  my \noprimes = ({ $^j } for ({ |($^i*2, $i*3 ...^ 50) } for 2..^8))
                                                              2..^8
                                                          for
                               { |($^i*2, $i*3 ...^ 50) }
                              (                                    )
                          for
                  { $^j }
                 (                                                  )

  primes = [x for x in range(2, 50) if x not in noprimes]

  my \primes = (2..^50).grep: * ∉ noprimes;

  my \prime-set = 2..^50 (-) noprimes; # a Set object
  my \primes = prime-set.keys.sort;

  # create a prime supply and act on it in the background
  Supply.interval(1).grep(*.is-prime).act: &say;

  say 'main thread still running';
  # says 'main thread still running' immediately

  # deadlock main thread,
  # otherwise the program would terminate
  await Promise.new;

  # waits 2 seconds from the .act call, says 2
  # waits 1 second , says 3
  # waits 2 seconds, says 5
  # waits 2 seconds, says 7
  # waits 4 seconds, says 11
  # and so on until it is terminated

I'm not a mathematician.

To me it seems a bit verbose and clunky. It probably also only works as a single line, which seems odd in a line oriented programming language. Basically it seems like a little DSL for list generation, sort of like Perl's regexes are a DSL for string operations.

Perhaps you may want to reread the last paragraph from the original article. Maybe in a few years the world will have passed you by. Then again maybe not.

I appreciate the feedback. Maybe my approach could have left out the claim of Lisp == Common Lisp, though I still am amused (as I mention near the end of my later comment) and slightly bothered that such a diverse set of languages (Python too, it's sometimes called an acceptable Lisp) can get called "Lisps" or "dialects of" or "members of the family" rather than an explicitly vague "Lisp-like".

The main direction I was coming from though was that ~10 years ago I was just like the OP, I had read some of SICP and PG's essays and thought I knew Lisp, but no, I just knew a minimal subset of Scheme. Very pretty (https://www.thejach.com/imgs/lisp_parens.png), learned some neat things, but didn't pursue it in favor of practical workhorses like Python et al. I went with the "learn Lisp for the side effects of learning it but don't ever use it" crowd, but I never learned Lisp. It wasn't until much later that I found out Common Lisp was way more than just an ugly syntax change on Scheme that required #' in front of function names. So the features I listed in my comment are really a subset (but a strong one) of the features that would have convinced me ~10 years ago to take a much closer look into actually using Lisp and recognizing I learned something very different.

Well, it was true, at least until clojure. Now we've got clojure, common lisp and scheme.

> The latter [the conditions mechanism for error handling] still has no analogue in other languages.

Could you explain this for a non-Lisp person? (I have some understanding of macros already.)

>So you pick a LISP language you're severely limiting your hire pool.

I'd rather have 5 very good Lisp programmers than 50 code monkeys.

The whole point of picking Lisp as a language for many people is to have a hiring pool of small but good programmers.

Haskell (and other functional languages) is also built on the lambda calculus. Lisp isn't special in that regard.

The gains from Lisp-like support of live-environment programming are not small, but they are hard to communicate succinctly. The costs are real, but not onerous for a language designed to support such features.

But a person designing and implementing programming-language tools has to deliberately choose to provide the needed features because implementing them after the fact raises the costs and lowers the benefits. That means such a person must believe that the gains are worth the cost. The only people likely to believe that are people already familiar with those kinds of systems.

I should point out that clojure-android provides exactly that. The tools are not currently maintained and it is quite difficult to get a development environment set up these days, but once running, it works very well.

It's strange from my perspective to see REPLs as a separate mode of operation. Yes, there's a little overhead, and it's something you might want to strip or disable from a production build, but the overhead is small in the context of a modern application language. Contrast with something like Electron.

This style of development makes the feedback loop between the programmer's mental model of how things work and a reality check extremely tight. It's one of those things like TDD that often changes what kind of programs you write.

Likewise, an argument can be made that developers should reach for Excel more often, because Excel is what the business world knows and uses.

We have so many great, specialized tools. But the act of development often bifurcates into "problems that don't have to scale, or even present a great interface" and "problems that need extensive customization at every layer and support millions of users" and our stacks reflect that.

So tooling choice is often more dependent on maximizing leverage while setting appropriate cutoff points for scalability - in almost all production scenarios you are better off simply to design the system down to the featureset of available off-the-shelf tooling and anticipate a hard break where it migrates upwards, versus thinking you have to boil the oceans immediately so that all facets can be transitioned smoothly and all features are possible right now.

I was replying to submeta, who said:

> Honestly curious why Lisp has so much admiration and praise on HN.

So my point is that Paul Graham says Lisp was important in his success. His success was important in the creation of Y Combinator and therefore of Hacker News. So we should not be particularly surprised that readers of Hacker News include many that are favorably disposed toward Lisp.

submeta also said:

>But I would not think of Lisp when it comes to solving day to day problems.

...so I mentioned that Lisp is quite practical for day-to-day programming, if you know it well. For what it's worth, I've been using it for day-to-day programming for thirty years.

Hard to tell, not an expert, not a beginner. Enough to conclude that other languages are more productive for me.

https://www.quora.com/Where-did-we-go-wrong-Why-didnt-Common...

In the above answer to a question in Quora, he seems to suggest that most of the features in lisp eventually got adopted in most other mainstream languages. Or in other words the concept of 'acceptable lisp'.

I get what you are saying, and I feel the same way. But I think what people try to imply here- If you are using Lisp for a certain set of features, most of them are now available else where.

Sorry, I mis-remembered his position. Thanks for the correction.

'One' seems to be false.

You can program in teams with ten or in companies with hundred Lisp developers. Usually the team size does not need to be that large.

Lucent for example developed a Lisp based network switch (similar to what Ericsson did later with Erlang) and they had around 100 developers. It was competing with a much larger team developing a similar product in C++.

ITA had around 100 developers for their flight search in Lisp.

Symbolics had at its height around 1000 employees and my guess would be that 40% were Lisp programmers.

Personally I'd say there would be little problem working in a team with ten Lisp developers - you just have to find or educate them.

Indeed, the "plumbing" role is getting more and more important as there are more reusable software out there, so less need to write it from scratch.

It reminds me of how MIT changed their intro-to-programming course, from the Scheme-based one to a python based one, because "the SICP curriculum no longer prepared engineers for what engineering is like today. Sussman said that in the 80s and 90s, engineers built complex systems by combining simple and well-understood parts. The goal of SICP was to provide the abstraction language for reasoning about such systems. [...] programming today is “More like science. You grab this piece of library and you poke at it. You write programs that poke it and see what it does. And you say, ‘Can I tweak it to do the thing I want?'. The analysis-by-synthesis view of SICP — where you build a larger system out of smaller, simple parts — became irrelevant." (http://www.posteriorscience.net/?p=206)

Also reminds me of Vernor Vinge's "Zones of Thought" novels, where in the far future, the starships don't have exactly programmers, but rather a kind of software archelogists who assemble systems from software components that may be a thousand years old.

> only a handful of people is capable of actually developing software project

Failures here are almost definitely related to lack of adequate mentorship rather than anything else. College doesn't go half the way to prepare you to be a successful engineer.

There are people out there that can be self-motivated to do better, but in almost all those cases they're building skills that do the dirty work but don't feature best-practices necessary in a collaborative engineering environment.

Your first employer/team, and their ability to mentor and develop new engineers, makes a huge impact on your success as an engineer. Really capable engineering mentors are worth their weight in gold (diamonds? printer ink?) and their contribution has an exponential effect.

Death marches are caused by the people who project the image that they understand software development better than others. Spaghetti code is caused by them as well, they just pretend it's so brilliant you can't understand it. (After their departure, the RDF usually fades)

We don't need a cult of brilliance. What we do need is an atmosphere of humility. Modern software/hardware systems are of breathtaking complexity. It turns out that's simply hard for humans to hold in their minds as a whole, but we still develop software like we actually could.

For a while, we had a glimpse on what a simpler world could look like. (The early days of the web - when everything was GET/PUT/POST). We promptly proceeded to layer complexity on top of that.

And that's OK, because it gave us a lot more power. But we pay a price for that power. And every time we attribute that price to lack of brilliant people, we mostly show that we haven't even come close to understanding what it even is that makes projects succeed.

The genius myth is just magical thinking in disguise.

For many programming jobs, the ultimate goal is not the code, but solving a business problem. So to me it's fine to just "piggy-back on libraries" if the library doesn't get in the way, doesn't lead to poor performing code, and saves time.

Even as a business programmer, I agree that I do think it's a good idea to occasionally step into some places that are a little more low level. Yet from what I've seen (playing around with embedded systems and VSTs and the like), the actual coding process is, more or less, more similar than different. Both in process ("the basics" of Javascript translate to some degree to "the basics" of C), and even at the "lower level", libraries are also used quite frequently. For instance, JUCE is a package pretty frequently used for developing VSTs (VSTs itself are an SDK). These packages save time and allow developers to focus on the meat of the audio plugin, the DSP algorithms.

At a certain level, what happens is that you get into the realm of math / engineering problems. And there definitely is mindset and focus differences between engineers and business -- one that's good at one is not necessarily good at the other. I just don't think the coding aspect of that separation is as stark as you make it out.

> If you could prove that only a handful of people is capable of actually developing software project pass the stage of 'piggy-backing' on libraries, that would probably distinctly change the way we develop software

Could you explain how such proof would lead to those changes?

> death marches better. Maybe we could improve our working environments so nobody has to crunch or have a depressing spaghetti-code maintenance job

These aren't software problems, they're business and social problems. No concievable level of productivity improvement will eliminate the death march.

> If you could prove that only a handful of people is capable of actually developing software project pass the stage of 'piggy-backing' on libraries, that would probably distinctly change the way we develop software. Maybe we could prevent death marches better. Maybe we could improve our working environments so nobody has to crunch or have a depressing spaghetti-code maintenance job.

I don't think it would matter.

In one instance, you're debugging and Apache server, in the other it's an in-house server implementation. You handjam a CSS file or you can use a preprocessor to help. You can create your own SPA implementation (as I painstakingly and naively did) or use any of the hundreds of existing ones. So do you want to debug business logic or debug all of your in-house implementations and your business logic? External tools are not perfect, but the idea is that they've been battle tested to know where they shine and edge cases that were missed. On top of that, decisions about the tooling must still be made. Relational or NoSQL? You must still know the difference when choosing.

Crunch has zero to do with quality of programmers or tooling.

It has everything to do with management practices, organization, anxiety, fear or personal wish to be seen as hero.

I could go and say that the aerospace engineer is also just doing "plumbing". The engineer is not going to design an engine for instance. "All" he does is specify what kind of engine he would use and then plug it to the fuel system and the wing structure. The engine was designed by someone else at a different company most likely. (Example: the Airbus A320neo uses PW1000G turbofan engines made by Pratt & Whitney. "neo" stands for "New Engine Option" by the way). This happens with a lot of the parts of an aircraft. Dismissing that as "plumbing" would be absolutely insulting to the engineer.

The same is true for a lot of software development. It is true that I am not going to design and develop ALL of the components of my software. For some things I will use libs and frameworks someone else made. I don't see a reason to be dismissive about that.

For instance I will be using the libs our hardware manufacturer provides to talk to the avionics bus of the A320. I don't see a reason to redesign our own ARINC429 avionics bus libs, but I also don't see a reason why this would make what I do not "actual software development".

A better question: Which would you rather have doing the inspections an your aircraft?

As I know as couple of people who either build aircraft for a living or build aircraft for their personal use, neither of them is an aerospace engineer. But I'd happily fly in their aircraft.

Irrespective of the title, can they design and build the object in question. This applies to all fields.

The point that we must look at is whether or not the problem before us can be solved by us. It doesn't matter if you build from the ground up or use some pre-built parts. Is the solution going to work and solve the problem at hand. If it does then you have success, if it doesn't then you have failure.

It is a matter of understanding the problem (in terms of the problem space), what solutions you use only matters if you can't solve the problem.

Good points. You could go with Alpine Linux if you're looking to use a lean distro.

I think this is going into the wrong direction. In my world "plumbing" means realizing ways to do things. When you want to write a simple web app that shows a Hello and has a contact form: even in 2018 that's still a reasonable amount of work. It's really not a lot of code but every line needs to be chosen wisely. That's what I call "plumbing". Most people new to Software Development become desperate at such tasks and to the rest it becomes embarrassing quickly... :-)

Yeah and then there's actual code writing: the heavy lifting has been done, all the functions/classes/modules/... are still small and wait to be stretched with a lot of nice code. In well sorted projects the latter is a trivial tasks for simple features.

But yes, I agree with the sentiment that there is a lack of general "understanding of stuff". I'm not sure if you must be able to use strace to be productive but it sure helps if you're able to get to know tools that are installed on most systems. Coming back to the OP's topic: LISP is a language that uses formalisms (ways to plumb ;)), tools (ever heard of asdf?) and syntax complete alien to even long-term computer addicts. It always puzzled me how people can be comfortable using this kind of stuff.

It really depends on some pretty subjective values held on faith, that position, power, and profit ought to be shared.

Interesting that you put those three together; while cutting edge AI research might require that level of academic background, I wouldn't say that compiler work does. It's more within the reach of an undergraduate degree course. And malware (for and against) is a completely different field altogether, full of people with unconventional backgrounds and a large chunk of poachers-turned-gamekeepers.

I think it will be a long time before the field slows down enough that standardising it will be viable.

I'll take it out again if people are going to argue by string matching rather than reading the tone of the original post.

I'd say you're basically redefining elitism to mean something it doesn't mean (or at least not how it's used here).

That said, I do agree with you. I think that 1) it can be be very important to make distinctions between types of programmers, because 2) it makes it easier to actively explore the field and finding what suits your 'type'.

For example, for many people, someone who 'does' HTML/CSS with some jQuery plugins, is a programmer. But personally I'd not really call such a person a programmer. I don't mean that as a value judgment, but rather to make a distinction between 'types' of work.

Making that distinction earlier in my career could've helped me (whether the label it programmer/non-programmer is used or not), because I spent more time than I'd have liked being such a HTML/CSS/JS guy. I learned tons of very specific rules/tricks/lore that were necessary, but did not help as a programmer, and spent countless hours doing this kind of work, not really enjoying it all that much.

It was only when I started doing 'proper' javascript stuff that I realized how much fun programming is, and how my relative enjoyment of the whole front-end stuff depended on the bits of 'real programming' I would occasionally get to do. In hindsight I wish I'd figured that out earlier, and not spent so many brain cycles and storage on CSS layout tricks and discussing how much 'semantic HTML' matters.

(thankfully those things are still useful when I do full-stack type stuff, but still)

> Usually when I see a statement that reeks of elitism, I immediately assume lower probability of it being true, because elitism of a statement correlates with falsehood

Ironically, I do the precisely opposite, due to my personal experiences. Over the years I lived on this planet, I've been both in the "elitist" groups and the groups that accuse someone else of being "elitist" - and I universally found it that it's the "elitist" group that was always right. I've learned to recognize accusations of elitism as ways to cater to one's feelings of insecurity (and I was guilty of that in the past, too).

> developers think in a different way and require different tools

Yes, I think this is very much underappreciated. When people find a language or system that matches their way of thinking, it works a lot better for them. But not necessarily for the next person. So you get small communities of people who find that e.g. Lisp has been amazing for them, who can't see that other people think differently about programs and systems.

Skype is / was not "a chat tool" - Skype was an opportunity to own the IP telephony space for both the business and consumer markets. That is potentially a huge revenue base, and fits neatly into a company like Microsoft that sits astride both.

Solaris, Java, SPARC and MySQL had all demonstrated that they weren't going to acquire major revenue streams, at least under the ownership of Sun. Their valuations reflect two different types of company, something the market is very able to understand.

> Skype was a chat tool.

> The market doesn't care about core CS.

Yeah, implementing a peer-to-peer voice over IP with Skype's late 00s quality (which fell significantly since then) is not "core CS" and is just "plumbing", right.

The issue I have with this view is that unless you have people on your team with fundamental, "core CS" capability, creating a behemoth like Skype or Snap just isn't possible. Of course, there's a balance, and who knows, maybe it's Pareto with 80% of the team focused on engineering and 20% focused on math/CS/R&D.

The monetary gains the market sees are the direct result of clever math and CS, not bolt-on solutions that can be lifted from libraries on GitHub.

I actual agree with you. However when business claims to need it done in 3 months, do they? Lots of business software projects don't meet the deadline, they end up taking longer, not having complete feature and worse still ridden with bugs. They try to meet deadline, cut corners and end up with flaws. When the deadline is missed, more pressure is placed on developers and things get worse. Business tries to have their cake and eat it too. A business that exerts demand for a deadline, can't also demand for all features, cheap cost, and high quality. There are trade offs and these trade offs are often ill defined. The idea of lean software and agile is great and hopefully with time will solve this for the industry.

BTW, I'm now part of the business side now and a manager. If you give me time constraints, you don't get to give me feature demands, you can give me your prioritized feature list and I can tell you what we can deliver given all other constraints. If you demand all the features, then I take away the time constraint.

I think that it matters if you can dig into anything. Given reasonable timespan being able to learn x64 machine code, debug and fix buggy driver if necessary, for example. If you're program has GC issues, being able to read papers, read GC source code if necessary and find right set of parameters or change some lines of code. If your Rails app has vulnerability because of underlying HTTP issues, being able to learn more about those HTTP issues, read RFC if necessary, read Ruby http code if necessary and provide required fix. If your manager heard about Meltdown issue and wonders whether our services are vulnerable, real programmer should be able to read papers, understand vulnerability and whether it's important (to shut down services, for example) or not.

Abstractions are leaky. I've yet to encounter one which doesn't leak.

Though if you're working in a team, it's not necessary for everyone to be real programmer. One or two is enough. Those tasks which require real programming are rare, most of tasks are mundane.

Without low level knowledge you can't tell which feature requests are easy or hard to implement. https://xkcd.com/1425/

> we are fundamentally unable to reuse already written code on scale

Actually I disagree - it's just that when something does become reusable it immediately vanishes from people's consciousness. You can see this both in things that become standard library features, and open source components that end up ubiquitous. The list of "incorporates software from" in licenses gets ever longer as people embed copies of SQLite, logging libraries, ORMs, serialisers, and so on.

One of the original article's points was that the things he loved in Lisp became features of other languages, and so ceased to be special.

http://uk.businessinsider.com/how-many-lines-of-code-it-take...

>>It's the goal of software to provide more and more features.

That's the goal. The key question is: are we writing features that users find valuable or are we writing features that developers find valuable? They're two different things. What's happened is that the community has become incestuous. Instead of focusing on value to the user we're focusing on selling frameworks to one another.

>>Software development severely lacks any objective metrics of performance and quality.

Agreed here as well. But this is related to my first point. Nobody wants to focus on the users. It's far too easy to focus on the technology (or other developers). You write a feature for a user, you can instrument it and see whether users use it or not. You write a feature for a developer, even if nobody uses it you can argue that somewhere, somehow, that feature is going to be critical. It's an abstract value argument -- which is intractable.

>>As a result, we are fundamentally unable to reuse already written code on scale, crumbling development and putting the whole industry in constant early-stage.

It's a sad state of affairs. I suggest that your conclusion continues the broken thinking I'm describing above. We shouldn't be striving for reusable code at scale. We should be striving for people who have strong basic programming skills and are experts in some business domain. Then we would shoot for the minimum amount of technological abstraction necessary for these programmers to solve problems in that particular domain. Because that's really what the whole point is, not creating large codebases that last twenty years, creating tiny bits of code almost instantly that solve business problems for twenty years. We've got our head stuck in the wrong bucket.

Objective metrics of performance are easy to come with: speed, memory usage, latency, throughput, energy efficiency, depending on type of your software. I can launch Windows Task Manager and those metrics are right there. Those metrics can be measured and compared. Quality isn't hard either, just count bugs. Many customers don't want to pay for performance or quality, they want features, delivery speed, shiny UI and listen to marketing too much. Slack is a joke when it comes to memory consumption. But it has smiles and marketing campaigns, so everyone's using it anyway even if chatting was a solved problem 30 years ago in kilobytes of memory.

We're trying to move this forward at https://anvil.works - the usability of Visual Basic, with the ease of distribution of the web. Biased I may be, but I'd call that progress :)

I'd feel better about this if it weren't for the growing evidence that an awful lot of what we actually get is cargo-cult medicine - procedures that have been supplanted or invalidated, but are still widely used by non-research doctors who don't know better.

Obviously doctors are still good, and don't need to be doing research to make the world a better place. I agree that dismissing 'plumbing' programmers or 'rote' doctors would be a serious mistake. But... well, I can't help drawing some connections between programmers implementing already-broken security, and doctors putting in heart stents that don't actually help patients.

I don't think we're just being metaphorical here, I think research vs practice doctors often show the same patterns as programmers, for the same reasons. Creating new knowledge is neither necessary nor sufficient for keeping up with other people's knowledge, but we seem to be worryingly bad at keeping people who implement that knowledge up to date.

(Context on the doctors: https://www.theatlantic.com/health/archive/2017/02/when-evid...)

> Writing your own novel ML/deep learning algorithm, shoving the data in and out of GPUs is not plumbing.

This is plumbing as well by your definition. Writing your own novel ML/deep learning algorithm also take "pre-existing packages" and glues them together. Unless you are actually going to write your own custom OS, Language and drivers you are going to reuse stuff.

I don't think there is anything wrong with using pre-existing packages and the like. We all are doing that anyways unless your are Terry A. Davis off course.

Your distinction doesn't hold up to analysis: at some level any system can be said to consist of elbow joints - eg. "processor opcodes are just elbow joints." The same can be said not only of the subsystems but also the intellectual heritage of so-called "original" systems. Nothing and everything is new. News at nine. Someone watches the news. They create a new system ever so subtly influenced by yours. Ad infinitum.

so you're going to ask your translater to learn Lisp?

Ah...! Sorry, I misunderstood you there. (Ok,ok. I admit I only skimmed your reply :) ).

But why would you want Turing completeness in a user facing templating engine? This is generally considered harmful, leading to all kinds of maintenance horrors. (And that's why StringTemplate deliberately isn't.)

Err, or just use Razor cshtml?

This just seems like being around something awful long enough that you develop a form of stockholm syndrome.

While you're joking, one thing that appeals to me about my recent dive into functional programming is that it strikes me as knowledge that is 'fundamental' enough that it'll never disappear or become irrelevant.

>and the most indispensable construct for those applications is GOTO.

That's what I like about Lisp: It isn't opinionated. There's no weenie saying "GOTOs are harmful so we delete them from our language", or "OOP sucks so our language won't have any OOP facilities", or "mutable data is bad so there's no mutable data here", etc.

Quite the opposite, Lisp gives you everything. Want OOP? Here's a deluxe OOP system. Want to do GOTOs? Ok, here you are.

>More importantly it isn’t statically typed (like F#, Haskell, etc)

You can statically type variables (bindings) in Common Lisp if you want:

    (defun little-function (x y)
       (declare (type fixnum x y)) 
           (+ x y))

Common Lisp has strong dynamic typing. Dynamic, because language runtime maintains type information; strong, because each object has its type and cannot be treated as an instance of another type.

In Europe yes, Ada has been a constant presence at FOSDEM in the last decade and many universities.

This has taken off since we finally got an open source Ada compiler (GNAT) without the typical enterprise/military prices.

Also Ada 2012 is quite different from Ada 83.

Then we have this, https://www.cvedetails.com/vulnerability-list/opmemc-1/memor... increasing exponentially every day thanks networked computers.

From where I stand, it's not really gaining any popularity, but I always wanted to use Ada for something practical, and I finally have something that needs a good language with a rich type system that is compiled to native code (and not statically linked at that), and somehow I don't like Rust there.

I can't tell if that's a typo or commentary on Perl.

JavaScript is for HN what sex is for highscool : those who talk the most about it are those who practise it the less.

I was using JavaScript professionally in 1999 and still write it almost every day. Not sure what that makes of your sex analogy: maybe I'm the middle aged guy who goes "free love used to be much better in my day"?

You probably know what I meant by "make npm work" — dealing with the messy dependency ecosystem and the less than ideal tooling.

> You don't make npm "work"

Maybe not, but I did spend a whole day trying to get a Polymer example work at all.

Texts of that era remind us of the brilliance of Knuth. http://en.wikipedia.org/wiki/TeX

oh wow, I have that book. I also have "calculus in a new key" and a few others. Yes, I was an APL child.

I've been writing C for 30 years+, and my style has changed massively in that time. In the meantime I did all kind of other things, perl, ruby, Obj-C, C++ (a LOT), java/script etc etc...

My 'design patterns' in C now has a lot more of the things I 'liked' about these languages, lots of abstractions, actors, compartmentalization and many many more, as well as the most important bits like multi-core/threads aware APIs and so on...

I think that if you stick not just to a language but to your set design patterns and even toolset, you fall into what I call 'mind sclerosis' -- HOWEVER -- it's not because your patterns evolve and you update your toolset that you need to change language and go with all the trends... Most 'modern' patterns can be done in any languages.

In fact I do a lot more C these days than I did for the last 20 years...

C++ and Java ecosystems were run over by people who read The GoF book and decided to generate every single permutation and combination of those patterns. Code largely comes out like AbstractFactoryServeletConfigurationSingletonDispatcher.

Also a lot of applications were written as huge monoliths even a few years back.

These days people write applications to do one task properly.

> The C and Perl style OTOH has changed less. A programmer of those language from 20 years ago that is transported to the present day will have much less problems fitting in than a programmer of C++ and Java would.

This is categorically untrue for Perl.

This depends on your target platform. Mine:

> cl.exe Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 12.00.8804 for 80x86 Copyright (C) Microsoft Corp 1984-1998. All rights reserved.

I know that Lisp has been largely stable, but are you sure it hasn't changed much? Programming paradigms advance, we didn't even have unit tests or continuous integration 20 years ago (at least not widely adopted in the industry). I find it hard to believe that even a Lisp programmer would be completely "static" across 20 years, i.e. the code written 20 years ago would be truly similar to the code he writes now.

So I'm not sure I buy this argument, unless someone has solid counter arguments.

If you never knew anything but COBOL you'd probably love programming it. Knowledge of better techniques can be seriously damaging to your career.

I suffered some damage from not wanting to touch Windows (3.1) after discovering Linux in the early 1990s. Today, most jobs advertisements still look toxic.

Old timers being rained with hundreds of thousands each year to maintain legacy banking systems beg to differ

Per your own sentence, you've just committed a syntax error.

Your comment made me think of the quote by Guy Steele: "We were not out to win over the Lisp programmers; we were after the C++ programmers. We managed to drag a lot of them about halfway to Lisp."

Even the designers of Java didn't expect programmers to go from Lisp to Java.

> Going from Perl to Python in my case largely felt like trying to a run a marathon in chains.

I find that not surprising. Python is geared a specific type of programmers. If Perl fits your programming, you will feel constrained by Python.

Me personally, I never liked Perl that much. IMO it's not a programming language but a write-only brain dump.

But Ruby is to me what Perl is to others. It's combining the power and expressiveness of Perl with a consistent OO model like Smalltalk and with a sane syntax.

I share your experience. Python took all the fun out of computing for me.

In general languages tend to focus on one thing, where Perl tend to focus on many things. So it is difficult to classify.

In addition almost everything that is easy in Perl 5 is also easy in Perl 6, but it also makes a wide variety of additional things easy. For example there is are several meta operators for dealing with lists.

  (1,2,3) Z+ (10,20,30); # (11, 22, 33)
  [Z+] ( (1,2,3), (10,20,30), (100,200,300) ); # (111, 222, 333)

  [Z*] (1,2,3,4,5), ( 10 xx Inf ), ( i xx Inf ); # (0+10i, 0+20i, 0+30i, 0+40i, 0+50i)

  ((1,1),(2,2),(3,3)) «+» ((40,50,60),)
  # ((41, 51, 61), (42, 52, 62), (43, 53, 63))

There are also features which you might expect to see in a distributed language.

Basically if there is a choice between A and B, Perl tends to choose both. With Perl 6 doing this to a greater extent than previous Perls.

You might consider starting off with this classic: https://mitpress.mit.edu/sicp/

I should point out, though, SICP uses the Scheme dialect of Lisp. If you’re interested in Common Lisp, then maybe try: http://www.gigamonkeys.com/book/

I'd like my career to be destroyed too please

Yeah, it's crazy what a well-kept secret Common Lisp is. I keep on running across situations in other languages where Lisp has been sitting on the solution for decades (literally) and yet no-one knows!

Despite how much I like it, it's really not the Platonic ideal of languages: it has its warts, and it could develop even further than it has. But as it stands it's an amazingly good language which could be used for anything from writing operating systems and device drivers to web browsers to text editors to expert systems. I really don't understand why it's not more popular.

The average engineer has some dozen things they encountered in their career, and everything else is something that they haven't encountered once.

Off the top of my head, I've never encountered such tools as: Visual Basic, PowerShell, VHDL, and IBM 370 assembly language.