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

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

#191

Post by LandR » Wed, Mar 14, 2018, 2:01 PM UTC

watwut wrote: post #109

incompatible wrote: post #26

Earlier quoted context omitted.

I'm interested in knowing your secret to finding inferior new things interesting.

Often times it is inferior, because you are acutely missing things it does not have, but did not yet learned to use things it does have effectively. So, the secret is to be alone in a room, so you can swear freely. Walk around when angry and complain to yourself. But always go back and continue using it and eventually, that phase will pass. After that you will build new set of habits that work around disadvantages an…

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

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

#192

Post by mikelevins » Wed, Mar 14, 2018, 2:02 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…

Paul Graham is a Lisper and made his fortune with a Lisp application. Moreover, he wrote a widely-read essay claiming that Lisp was the secret weapon that enabled his startup to outcompete its rivals. In that context, it shouldn't be suprising to find sympathy for Lisp in discussions hosted by Paul Graham's firm.

Lisp is quite practical for solving day-to-day problems, as long as you are a knowledgeable Lisper.

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

#193

Post by vijaybritto » Wed, Mar 14, 2018, 2:02 PM UTC

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…

You seem to be experienced and ignorant at the same time

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

#194

Post by contingencies » Wed, Mar 14, 2018, 2:03 PM UTC

cousin_it wrote: post #162

jakelazaroff wrote: post #91

Earlier quoted context omitted.

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…

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

The XKCD is a bad example in this case, as it is mostly about domain specific knowledge of computational theory or standardized algorithmic approaches to the problem spaces presented within those domains, whereas "low-level" is something different ... primarily referring to common layers underlying many domains.

Most programmers never have to write low-level code.

This is a good thing.

It doesn't mean they can't, it just means we've moved on from wasting our time re-implementing solutions to problems already adequately solved for a general case. Finally.

Manual memory management is frankly insane outside of extreme edge cases today.

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

#195

Post by ubermonkey » Wed, Mar 14, 2018, 2:03 PM UTC

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…

There's a real tension in this field between capital-C Computer Science and the work of writing code for businesses.

The business doesn't care about your toolset, probably. What they care about is solving a problem.

I've met no small number of very gifted, very creative developers that had this same mindset -- didn't give a crap about the Cool New Language or pure CS, but really DID get excited about building connections and features within existing systems to solve business problems.

These two visions of development are in tension. Few folks can get jobs writing Haskell or Lisp, but there are LOTS of jobs for .NET developers.

Neither path necessarily makes a better developer, though.

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

#196

Post by alehul » Wed, Mar 14, 2018, 2:03 PM UTC

d3ckard wrote: post #102

pjc50 wrote: post #90

Earlier quoted context omitted.

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

Good point. I would like to point out however that all of your examples appear to do well in abstracting mostly technical problems, not business problems. Technical problems are problems common across our field and natural areas of interests of those '10 %'. Business code is something written by majority of us(or at least I would expect it to be so) and it doesn't appear to scale and grow so nicely.

Sorry to interject, but I'm curious: as someone who is in their first semester of a CS education, could you elaborate on what you mean by abstraction?

So far, I just know it to mean making your function more widely applicable. I'm assuming there's a better definition I'm missing?

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

#197

Post by pulsarpietro » Wed, Mar 14, 2018, 2:04 PM UTC

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…

>Of course, as every programmer, I live in constant fear that I am part of the plumbing crowd waiting to be exposed.

How true, the 50% of jobs I see are actually semi-skilled overpayed jobs which won't last. In many cases you configure somebody's else product and you manage it at best, it won't last. It is already happening.

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

#198

Post by segmondy » Wed, Mar 14, 2018, 2:04 PM UTC

jstimpfle wrote: post #174

bjoli wrote: post #86

Earlier quoted context omitted.

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

> 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. List comprehensions, to me, are what makes Python a productive (or the most productive) prototyping language. It allows me to think and program in mathematical relations without much fuss. Add to that nice sets and dicts (needed for asymptotic efficiency), and I can easily forgiv…

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?

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

#199

Post by oblio » Wed, Mar 14, 2018, 2:04 PM UTC

jcadam wrote: post #186

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

I don't know. My industry (defense/aerospace contracting) is still infatuated with Java/C++ and Object-Oriented Design as the universal solution to all problems. It's like being stuck in the 1990s. This is the flip-side to age-discrimination - it's much less of a problem in my industry. Which, as a 37-year-old I find comforting. But when you're stuck working for 50-something pathologically risk-averse architects who…

> I'm basically waiting for the previous generation to die/retire so I can have the chance to build software the way I think it should be built.

And by the time you'll be able to do that you'll be the 50-something who keeps using functional programming while the 37-year-olds want to use dilithium crystal programming :p

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

#200

Post by 3chelon » Wed, Mar 14, 2018, 2:04 PM UTC

Jach wrote: post #133

3chelon wrote: post #101

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…

Sounds like you coded in Scheme, not Lisp. ( https://news.ycombinator.com/item?id=16584082 ) Common Lisp was designed for the messy real world, it's a workhorse, even at the cost of 'prettiness' that Scheme fans like to point out as a benefit for Scheme. So it's been used (either directly or to output a lower level machine code) for all sorts of real world things like OSes (see the Lisp Machines), video games, CAD sy…

Yeah, I remember very little about it except a _lot_ of parentheses. Interesting to hear it is a lot more "real world" than I thought - seems my understanding is flawed... but equally interesting that I was unaware of it, having never once encountered it in my entire career.