How knowing Lisp destroyed my programming career (2006) • Hacker News Board

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

#81

Post by d3ckard » Wed, Mar 14, 2018, 12:02 PM UTC

DanielBMarkham wrote: post #55

d3ckard wrote: 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…

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 using. Once the problem becomes apparent, somebody writes a library, which allows us to write a couple of times more crappy code before everything collapses. Rinse and repeat.

Since we are unable on scale to choose right abstractions when necessary, we quite often get ourselves in situations, when it's actually preferable to rewrite everything using lessons learnt. Rewriting comes with its own set of new problems and cycle is complete.

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.

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

#82

Post by kamaal » Wed, Mar 14, 2018, 12:02 PM UTC

arethuza wrote: post #62

kamaal wrote: post #43

Earlier quoted context omitted.

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.

I was slightly surprised when I Googled AbstractFactoryServeletConfigurationSingletonDispatcher that your comment was the only match (at least at the time I looked).

That's possible. Last time I checked not everyone working in every single company uploads their code to some public website.

Also that word represents a culture which is what I was talking about.

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

#83

Post by andai » Wed, Mar 14, 2018, 12:03 PM UTC

pjc50 wrote: post #69

d3ckard wrote: 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.

Nor indeed the plumbing in your house! It would be a very gross world indeed without it.

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

#84

Post by pjc50 » Wed, Mar 14, 2018, 12:07 PM UTC

golergka wrote: post #79

pjc50 wrote: 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.

> Maintaining a distinction between "actual software development" and "plumbing" is elitist You are correct - however, it doesn't mean that this statement is necessarily wrong. 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 - but it's worth remembering that this correlation is not absolute, and som…

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

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

#85

Post by wheresvic1 » Wed, Mar 14, 2018, 12:08 PM UTC

Oh wow, I was first introduced to Java in my undergrad and somehow I had some serious issues with the whole OOP stuff.

Thankfully, I took some AI courses, which came with LISP and I was so excited to use it everywhere.

Unfortunately, however, doing basic I/O, networking (this is around 2006) and testing was too complicated for me so I dropped it again in favor of C++ in grad school (performance was also an issue, we needed to crunch a lot of data fairly quickly).

I would love to go back again and give it a shot - any pointers on the best way to learn/start?

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

#86

Post by bjoli » Wed, Mar 14, 2018, 12:08 PM UTC

submeta wrote: 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…

What made it click for me is the nature of scheme: a few, very well thought out abstractions, that compose well to build a really neat language. I never really made friends with other languages. Where scheme composes the primitives for problem solving, I find that languages like python or ruby provide either one way for each different thing, or a very large hammer for every problem you might find, be it list comprehensions or generators or whatever OO voodoo you can come up with.

The feeling I got when learning scheme was that of liberation. People have that epiphany all the time, but with different languages and techniques. For me it was scheme.

And of course, I could never be bothered with syntax. If something becomes too verbose in scheme, I write a macro to simplify it. The only thing I need to know is whether something is a function or a macro. After 3 years of writing python on and off, I still manage to mess up syntax unless I think very hard before writing.

I am however not a programmer, and of average intelligence. In fact I am on the very top of the bell curve, looking down on the rest of you.

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

#87

Post by beagle3 » Wed, Mar 14, 2018, 12:10 PM UTC

pavlov wrote: post #22

zero_shift wrote: post #4

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.

There's more to it; The paradigm is so different and so effective at a large problem domain (which includes mostly mathy things and big data), and you can do similar things in many languages, although not quite as elegantly and succinctly.

I faced two problems after K:

1. The whole software engineering world starts to look like a ridiculous house of cards; When you're used to seeing implementations of fast and efficient in memory databases in ~20 lines, or an npm-style package manger[1] in less than ~400 lines (comments included). Modern software engineering practices enable and encourage solutions that are inefficient in many respects. Maybe it cannot be better at a large enough scale, but it affects and infects the smaller scales as well. It is extremely frustrating.

2. Getting actual work done requires interfacing with the world, which isn't quite up to the k/q/apl standards of terseness and efficiency -- mostly "accidental complexity"[2]; So, e.g., if you have to have web presentation, or work on import/export, they dominate your effort due to accidental complexity that cannot be removed. Which is doubly frustrating.

[0] http://nsl.com/k/t.k

[1] https://github.com/yang-guo/qp

[2] https://www.quora.com/What-are-essential-and-accidental-comp...

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

#88

Post by DanielBMarkham » Wed, Mar 14, 2018, 12:11 PM UTC

d3ckard wrote: post #81

DanielBMarkham wrote: post #55

Earlier quoted context omitted.

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…

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

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

#89

Post by demircancelebi » Wed, Mar 14, 2018, 12:11 PM UTC

pavlov wrote: post #30

Dude2023 wrote: post #7

A required thought-piece for all JavaScript devs. Enjoy monopoly while it lasts, but be humble.

Fortunately JavaScript doesn't have the problem described by the OP: "With a secret weapon like Lisp in my arsenal in 1986 I could blow my competition out of the water with one hand tied behind my back and holding a martini in the other." A present-day JavaScript practitioner will have his left hand busy trying to figure out what's this week's fashionable way to pass around some data in this month's fashionable frame…

I disagree. It is true that many Javascript developers lack the formal CS education, but since it is the de facto language of the web with relatively lower barrier of entry, there are many people working on great projects. NPM is the largest package registry in the world, and whenever working on a project I find that I can solve most of the mini problems with a quick search. Jumping from framework to framework without really understanding the underlying technologies/thinking is a problem that should not be attributed to language itself, but to some of its users.

Although this low barrier of entry sometimes lead the users of the language to bad results, I especially like Javascript because of its welcoming nature. One can even argue that it democratises the software creation process on Earth by allowing anyone to quickly start tinkering with it and see the results immediately, most likely in a web environment.

Also, although it definitely has some quirks and may cause some frustration to starters, it also allows an experienced developer to be expressive and quickly build products, and may allow its users to enjoy their martinis.

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

#90

Post by pjc50 » Wed, Mar 14, 2018, 12:11 PM UTC

d3ckard wrote: post #81

DanielBMarkham wrote: post #55

Earlier quoted context omitted.

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…

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