Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How knowing Lisp destroyed my programming career (2006)

coding.derkeiler.com

Post reply on HN
Print view View original

111–120 of 433 posts

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

#111

Post by kalkut »

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…

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

If JS devs were not able to focus on bringing value they wouldn't be able to hold jobs, build products nor profitable companies. If JS was so impratical there would not be so many people choosing it over various alternatives for building GUIs, games, websites, WebGL/WebVR, back-end services and so on.

If there is a warning in this story, it is a warning to people looking down on rising languages and frameworks. Those are the people risking to become irrelevant because of a mix of smugness, gatekeeping and ivory tower syndrome.

This attitude is exactly what lost Ron Garret when C++ and Java happened. This also prevented him to see (before the very end of his programming career) that the competition was actually doing just fine with the new tech. You and grand-parent totally missed the point of this story.

PS: You don't make npm "work"

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

#112

Post by TurboHaskal »

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…

I second this, I actually find the whole s-expr thing a bit lacking, now that the Kool-aid faded off.

Ultimately, what I really love are expression oriented languages, and the ALGOL/C and APL families have alternatives with a more succinct and expressive syntax (Perl, K).

One might also argue that Scheme is a poor man's Forth.

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

#113

Post by vbezhenar »

jakelazaroff wrote: post #91
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…

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…

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.

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

#114

Post by demircancelebi »

Dude2023 wrote: post #7

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

Of course one should be humble and seek for ways it improve. There are different languages/tools suited for different needs. But, I do not understand why do you think this piece should be a required read for Javascript devs. AFAIK, neither Lisp had a monopoly, nor Javascript does have one. It probably just has the largest user base.

In my view, users of different languages might benefit from this piece as much as JS devs. This behavior against JS devs cause unnecessary hostility.

In addition, Javascript may actually be "too big to fail", and it is actually in a very different state than Common Lisp in this sense. What I mean by that is being "the language" that is used in browsers and having the largest registry (npm).

I am not trying to attack, just curious about why do you think it specifically applies to JS devs.

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

#115

Post by tcbawo »

kamaal wrote: post #43
bhaak wrote: post #34

Earlier quoted context omitted.

I think of those C and Perl fit the most. You can't write C++ or Java like you did 20 years ago (of course, you could but you shouldn't ). Both languages and their whole ecosystems have evolved tremendously in 2 decades. 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++ an…

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.

My experience with C++ has been watching a trend towards standardization across platforms, and incorporation of functional programming concepts.

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

#116

Post by firepoet »

Jach wrote: post #74
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…

Your confusion will go away once you recognize that Scheme is not Lisp. For most purposes, Lisp means Common Lisp, or one of the Lisps that ended up merging into Common Lisp. That means that Lisp does all of these things and more, which you might not expect if you've only seen Scheme/SICP: * Multi-paradigm programming (functional programming in the immutable sense is not dominant, the Lisp OOP system is top class, mu…

To add to the confusion, this Wikipedia article says that Scheme is "one of the two main dialects of Lisp." https://en.wikipedia.org/wiki/Scheme_(programming_language)

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

#117

Post by d--b »

OceansOnPluto wrote: post #51
d--b wrote: post #25

This is from 2006 though. Since then functional programming has picked up a lot of steam again, and I'm pretty sure having been a lisper for 30 years gets you good jobs. If not in Lisp, haskell, F#, clojure or whatever...

He worked for Google pre-IPO and is now an angel investor and the CEO of Spark, I don't really think he's looking.

ok, perhaps before talking about why a career is ruined, a pre-requisite should be that the said career is indeed ruined.

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

#118

Post by pavlov »

kalkut wrote: post #111
pavlov wrote: post #30

Earlier quoted context omitted.

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…

JavaScript is for HN what sex is for highscool : those who talk the most about it are those who practise it the less. If JS devs were not able to focus on bringing value they wouldn't be able to hold jobs, build products nor profitable companies. If JS was so impratical there would not be so many people choosing it over various alternatives for building GUIs, games, websites, WebGL/WebVR, back-end services and so on.…

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.

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

#119

Post by watwut »

vidarh wrote: post #46
watwut wrote: post #16

> knowing Lisp made me all too keenly aware of Java's shortcomings, and I had a very hard time not being angry at how stupid it was that I was being forced to use it. I would take this as a the thing to remember from this. When you are too angry at something, you cant learn it. I have seen the emotional refusal to learn new inferior thing (or read comments that amounted to the same) many times already. It is somethin…

Sometimes it's not worth the pain. I have programmed in Java. I won't do so again. I concede that part of it is stubbornness, but I have to prioritize what I want to spend my time on, and there are enough jobs giving me the opportunity to work on things I like working with that I can afford to dismiss Java out of hand and focus my efforts elsewhere. I realize not everyone will have that option, but I strongly believe…

But author is talking about refusal to learn something "destroyed career".

I hated Java as everyone was supposed to in school among my peers. Java was for lesser programmers. But, there was interesting job in Java available and after using it, I liked coding in Java better then previous languages I knew (C, C++ mainly).

I liked Java pretty fast, but learning to like JavaScript took more effort. Imo, it was very very worth pain. The more pain, the more the learning process is worth - it hurts because you are learning something fundamental and getting new habits you miss.

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

#120

Post by vbezhenar »

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…

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.
Post reply on HN