Live data from Hacker News

How knowing Lisp destroyed my programming career (2006)

coding.derkeiler.com

151–160 of 433 posts

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

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

> is elitist

I know I'm supposed to think that that is bad, but I can't come up with why it would be.

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

#152
post #144

Earlier quoted context omitted.

No, no, it doesn't fall apart! Lisp is Turing-complete. You can do (in English): "David has %n% apple%(when (> n 1) "s")%." You can move that rule to function etc. You can tweak that for the language you use in an endless number of ways.

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

[deleted]

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

#153
post #95

Earlier quoted context omitted.

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…

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

College doesn't go half the way to prepare you to be a successful engineer.

This is something I'm hearing alot at the moment, and not just about engineering. What would you say college taught you?

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

#154
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…

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

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

I think a deeper problem is that we're not really doing such a great job writing features for developers either. I'm amazed at how much of what I do is still done in the terminal or a bare-bones REPL, not so different from how they worked a few decades ago, when there's so much that could actually improve my day-to-day in small but very noticeable ways.

For example, I make almost constant use of the autocomplete feature when I work with the BEAM REPL (Elixir). I was amazed to find out that this was a relatively new feature. I can't count how many keystrokes it saves me throughout the day.

Of course, I still can't use VIM-style keybindings, and I'm being forced to write my REPL-code line by line instead of a Chrome Devtools style snippets. But, as you say, I do have tons of frameworks to choose from that all do mostly the same thing, and yet none of them do the relatively common thing that I need, so each of them requires me to read documentation and figure out how to configure it 'just-so'...

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

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

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

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

Call it what you will, there are ranges of skills needed in technical activity, and those of the engineer are not the same as those of the technician, though it is much more of a continuum than any two words suggest. In many branches of technology, there are certain tasks that need an understanding of calculus, but it is not so clear that there is an equivalent in software development, and I certainly do not think that programming in Lisp as opposed to C (or any other language choice) counts as such.

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

#157

Horses for courses, surely? I've never coded in Lisp except for one undergrad assignment in the early 90s... but I know it's good for functional, heavily recursive, algorithmic type problems. But the world is far messier than that and if, like me, you come from a systems or real-time programming background then Lisp basically did not exist and you were using C-based languages (or even assembler) that were close to th…

"lisp is one of the least functional languages ever created" -Doug Hoyte https://letoverlambda.com/index.cl/guest/chap5.html#sec_1

Here is the source for how Unix interrupts are handled in SBCL https://github.com/sbcl/sbcl/blob/master/src/code/signal.lis...

And the manual for handling async threading in SBCL http://www.sbcl.org/manual/#Threading

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

#158
post #144

Earlier quoted context omitted.

No, no, it doesn't fall apart! Lisp is Turing-complete. You can do (in English): "David has %n% apple%(when (> n 1) "s")%." You can move that rule to function etc. You can tweak that for the language you use in an endless number of ways.

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

A generic translator cannot realistically cope with Lisp. It has to be a translator + NLP guy working together in conjunction to bring a high quality localization for the given textual model.
Post reply on HN