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

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

#171

Post by lostcolony » Wed, Mar 14, 2018, 1:29 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.

Most marketing solutions are abstractions of business problems. CRMs, tracking, automated reporting tools, etc.

Of course, they also require a fair bit of custom code that is purely plumbing to hook them up (translate data from one source and stick it into the tool).

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

#172

Post by yoz-y » Wed, Mar 14, 2018, 1:29 PM UTC

larkeith wrote: post #53

yoz-y wrote: post #19

Earlier quoted context omitted.

I started with Pascal, then learned Perl. When I was writing Pascal I was excited about stuff I could make the computer do, but pascal made me like the actual act of programming.

I can't tell if that's a typo or commentary on Perl.

A typo... sadly it's too late to edit the comment.

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

#173

Post by Confusion » Wed, Mar 14, 2018, 1:34 PM UTC

oldandtired wrote: post #168

ThrowawayR2 wrote: post #145

Earlier quoted context omitted.

> Maintaining a distinction between "actual software development" and "plumbing" is elitist... Is the distinction between an aerospace engineer and aircraft mechanic "elitist"? Which would you prefer to have designed the next aircraft you fly in? Plumbing is really what the vast majority of us do. With varying levels of skill, we glue various pre-written libraries and packages together with a bit of business logic, s…

As I know as couple of people who either build aircraft for a living or build aircraft for their personal use, neither of them is an aerospace engineer. But I'd happily fly in their aircraft. Irrespective of the title, can they design and build the object in question. This applies to all fields. The point that we must look at is whether or not the problem before us can be solved by us. It doesn't matter if you build…

People who build aircraft are not people who design aircraft.

Moreover, the point of the comment isn't about the titles assigned to these people by someone external: it's about the actual skills they have that would cause you to assign such titles to them.

If you know people who can design new aircraft, then they are, by definition, aircraft engineers. They may have a job as an aircraft mechanic, but that's besides the point. That doesn't mean the average aircraft engineer is capable of designing aircraft.

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

#174

Post by jstimpfle » Wed, Mar 14, 2018, 1:34 PM UTC

bjoli wrote: post #86

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 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 forgive it that it is built on an everything-is-an-object paradigm (there are few things I detest more than OOP).

I've never truly understood why you need the meta-capabilities of LISP. I much more need a syntax that does not hide what happens (procedure call, list indexing or at least "indexing"). Macros amount to code generation. Code generation is mostly bad, it typically means the problem wasn't thought through, and that there is a lack of clearly defined building blocks. So far I've only ever generated a few C structs and enums, but I'm not sure it was an entirely good idea. It was super easy to generate from Python, anyway.

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

#175

Post by threatofrain » Wed, Mar 14, 2018, 1:36 PM UTC

Bromskloss wrote: post #151

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.

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

It really depends on some pretty subjective values held on faith, that position, power, and profit ought to be shared.

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

#176

Post by zero_shift » Wed, Mar 14, 2018, 1:36 PM UTC

oblio wrote: post #161

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?

C++ was launched in 1985. Perl was launched in 1987. Python was launched in 1991. Java and Javascript were launched in 1995. C# was launched in 2000. So the newest out of the popular languages is already 18 years old. You don't need Fortran or Cobol or Lisp to have been able to do this... It's already almost 60 years since that time.

*how many languages would have given you [the luxury of programming effectively] for twenty years?

C++ doesn't qualify, to my mind, because the language has had many iterations and also because, as the post's author points out, writing C++ in the early 90s was not always a pleasant experience.

Python and even Perl are good contenders, as they have both been relatively stable languages. I'm not sure Java counts - Java 10 is quite different to Java 1.0, not just in terms of language features but often paradigms too (think 5's generics and 8's lambdas).

As for C# - I've never done .NET, so I'll have to take you on your word.

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

#177

Post by falcolas » Wed, Mar 14, 2018, 1:38 PM UTC

Zak wrote: post #98

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…

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

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

All my opinion, of course: The time (cost) required to create such easily available introspection is too high for the comparatively small gains. REPLs in modern languages (when even implemented) are just so often a completely separate mode of operation.

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

#178

Post by ptero » Wed, Mar 14, 2018, 1:39 PM UTC

ptero wrote: post #11

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?

COBOL?

Just to clarify: that was a tongue in cheek comment. The cycle of language introduction, acceptance, toolchain maturity, obsolescence quickened up a LOT in the last 15-20 years. Many earlier languages, from ALGOL to Fortran would have given you a comfortably large set of jobs to choose from for over 20 years.

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

#179

Post by jakelazaroff » Wed, Mar 14, 2018, 1:44 PM UTC

vbezhenar wrote: post #113

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…

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

Sure, I'll concede all of those points! But I think they fundamentally change the question, because now you're presenting a different set of problems to solve.

Understanding one level of abstraction doesn't mean that you understand the levels above or below it. It's perfectly possible (likely, even!) that a team will have someone who can build a good Rails app and someone else who can make sure the HTTP code and infrastructure is secure, yet those people won't have many skills that overlap.

Yes, there are definitely good programmers and bad programmers. IMO, that has to do with how effectively you can solve problems you care about, not (as the comment to which I was replying suggests) the level of abstraction you're comfortable with.

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

#180

Post by segmondy » Wed, Mar 14, 2018, 1:45 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…

I sort of agree, but I also disagree. I think 90% of us are capable of doing "actual software development."

However the market does't care for that. The market prefers short term gains over long term gains. Perhaps we can blame wallstreet? Due to the demand for short term gains, the ask from most developers is "how fast can you build this" not "how can you build this to be most efficient and cheapest in the long run and lifetime of the product" To move quick, developers must then employ abstractions layered upon abstractions.

The short term winners get lots of money for demonstrating wins quickly. The losers conform to keep up.