Live data from Hacker News

How knowing Lisp destroyed my programming career (2006)

coding.derkeiler.com

91–100 of 433 posts

Re: How knowing Lisp destroyed my programming career (2006)

#91
post #40

For a while now I've had a feeling that all the comments about lack of engineers(especially in software) are vastly underestimated. Probably around 10% of us is capable of doing actual software development. The rest writes plumbing and can handle the project for only as long as abstractions available through libraries can hold the complexity. If we assume most of us don't really know what we're doing, that totally ex…

Nerds screw up everything we touch. I don't think we mean to. Whatever the system, we make it more complicated, er featureful. Then we add an abstraction layer. Then we make that layer more complicated. Repeat and rinse. Some abstraction layers help more than they hurt, but the ratio is about 1-in-10 or so. For any given project, there are probably a dozen cool-sounding frameworks or layers, one of which is absolutel…

Being able to solve people's problems doesn't mean you need to be able to program.

What is a "real programmer", anyway? Is it knowing how a CPU works? Managing memory? If you rely on the garbage collector, do you really know what you're doing? If you write a Rails app without fully understanding HTTP, are you just plumbing?

Does it matter?

The reason we build tools and abstractions is to allow us to accomplish higher-level tasks without worrying about lower-level ones. Does it help if you understand lower level ones? Sure. But for millions of apps and websites that aren't Facebook or Hacker News or Firefox, the only problems are high level.

Re: How knowing Lisp destroyed my programming career (2006)

#92
post #90
post #81

Earlier quoted context omitted.

I'd put it differently. Software development severely lacks any objective metrics of performance and quality. We just haven't invented any(at least any practical enough to become mainstream). As a result, we quite often misjudge our(and others') skill and make bad decisions. It's the goal of software to provide more and more features. The problem is, we usually achieve those features by abusing abstractions we are us…

> 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,…

That's a great point.

I watch teams a lot. When I listen to them, I notice how much they talk about tooling instead of solutions. The more they talk about the tooling, the more they're sucking wind.

The truly good stuff just disappears from awareness. That's how you know if a framework or abstraction layer is working for you (instead of you working for it.) It's invisible.

Re: How knowing Lisp destroyed my programming career (2006)

#93

I came to Lisp (Scheme/Racket) from that another side (C++, Java, Perl) and it was an enlightening experience. Now I use Lisp nearly everywhere in a form of a small .NET runtime module. Lisp is excellent at templating tasks. Just for comparison: StringTemplate for .NET is a whooping 400 kB of compiled binary code while my implementation of Lisp is just 35 kB (!). Sure enough, Lisp does the very same thing as StringTe…

Although that approach to string creation tends to fall apart quickly in non-English languages: adjectival agreement, plural rules etc.

Re: How knowing Lisp destroyed my programming career (2006)

#94
post #17

> I saw people whip things up in Perl in a couple of hours that would have taken me days or weeks to do in Lisp. Perl, my first and only love.

Mine too. Until Erlang, and now Ada. I'm building myself a harem.

That's the second time I've seen Ada mentioned in as many days. Before that, I did Ada as an undergrad about 1989 and never heard of it again. Is it becoming a thing again?

Re: How knowing Lisp destroyed my programming career (2006)

#95
post #69
post #40

For a while now I've had a feeling that all the comments about lack of engineers(especially in software) are vastly underestimated. Probably around 10% of us is capable of doing actual software development. The rest writes plumbing and can handle the project for only as long as abstractions available through libraries can hold the complexity. If we assume most of us don't really know what we're doing, that totally ex…

Maintaining a distinction between "actual software development" and "plumbing" is elitist, even if you're placing yourself on the downside of that comparison and setting yourself up for imposter syndrome. You can get an awful lot done by "plumbing". Entire businesses like SAP are built on it. It can also be mission critical; in SpaceX, is the literal plumbing of hydraulic fluid and fuel flow unimportant? No.

I'm not trying to impose that one is more "noble" than the other. As you said yourself, businesses usually run on plumbing.

I'm trying to understand the industry, as it appears to be(at least to me) different than what I thought was true. I believe it to be important if we're going to do better and there is a ton of metrics showing we should do better(percent of projects failing, percent on projects exceeding budget and time, percent of projects becoming unmaintainable).

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.

It doesn't mean in any way that 'plumbers' should/would be treated worse. If anything, I would expect the opposite.

Re: How knowing Lisp destroyed my programming career (2006)

#96
post #22

Using any language for twenty years straight is going to make you complacent - but goodness, how many languages would have given you that luxury?

The APL / J / K family of languages seems to be very strong with this effect. If it fits your problem domain, it's (apparently) so powerful that using anything else feels like a frustrating waste of time.

APL/J/K are on their own league. I'm currently learning J, and the only language that has wowed me as much was Prolog and APL/J is even more profound. I won't say that I got ruined by Prolog, I got spoiled by it, but I carried over the good habits from it to other language. Sadly, I don't know that there's anything I can carry over from J. Perhaps it will improve and increase my ability to think of how to solve in parallel which is needed more and more with distributed computing/GPUs.

Re: How knowing Lisp destroyed my programming career (2006)

#97
post #95
post #69

Earlier quoted context omitted.

Maintaining a distinction between "actual software development" and "plumbing" is elitist, even if you're placing yourself on the downside of that comparison and setting yourself up for imposter syndrome. You can get an awful lot done by "plumbing". Entire businesses like SAP are built on it. It can also be mission critical; in SpaceX, is the literal plumbing of hydraulic fluid and fuel flow unimportant? No.

I'm not trying to impose that one is more "noble" than the other. As you said yourself, businesses usually run on plumbing. I'm trying to understand the industry, as it appears to be(at least to me) different than what I thought was true. I believe it to be important if we're going to do better and there is a ton of metrics showing we should do better(percent of projects failing, percent on projects exceeding budget…

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

Re: How knowing Lisp destroyed my programming career (2006)

#98
post #47

Honestly curious why Lisp has so much admiration and praise on HN. I played around with Scheme some long time ago, read SICP, learned a lot. And I know Lisp inspired many programmers like the founder of Ruby. But I would not think of Lisp when it comes to solving day to day problems. I rather pick Python because it helps me solve all kinds of problems. There are many more solutions I can think of (Ruby, Node, Go, eve…

The OP lists several features Lisp had decades before they were common to find in more widely used languages, so some of it is for historical reasons. There are two things lisps, including Scheme and Clojure have that are weak or absent in most popular languages:

One is macros. Being able to transform code before it is run using the language's built-in data structures provides a solution when the language just doesn't have the abstraction you need. Used properly, this can be invaluable. Used improperly, of course, it can make a mess.

The other is REPL-driven development. Most languages have a REPL, but they don't really embrace it the way Lisp does. I find this frustrating. Why is my editor on my PC not talking to the app running on my Android phone and letting me see its state and make changes in real time?

Re: How knowing Lisp destroyed my programming career (2006)

#100
post #66

Earlier quoted context omitted.

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

Care to elaborate?

Well Perl 6 is pretty much a completely different language and it certainly didn't exist back then. I guess you could still be using Perl 5.x but iirc modern day projects use things like Moose which is relatively new too.
Post reply on HN