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

181–190 of 433 posts

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

#181

Post by segmondy »

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.

It's not elitist. It's exactly what it is. Plumbers make great money, especially ones who plumb oil pipelines underwater and such. So SAP might be a big money cow, and plumbing, but what OP was saying is that such things are not employing the "best principles" of computer science, to write well thought and efficient programs.

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

#182

Post by nradov »

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…

It's rather disappointing how the industry hasn't made any progress on CRUD application development productivity in the past 20+ years. Microsoft Visual Basic 4.0 allowed low-skilled developers to build working client/server CRUD applications far faster than any modern web development framework. Of course it's easier to distribute web applications than thick client Windows applications, but other than that we haven't gained anything.

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

#183

Post by dwringer »

Jach wrote: post #170
bjoli wrote: post #121

Earlier quoted context omitted.

Well, it was true, at least until clojure. Now we've got clojure, common lisp and scheme.

It's definitely a confusion. The point seems to come up on HN from time to time... I don't care very much about the distinctions but it's still fun to spell out my case for why maybe one should care. "Lisp" has these nice connotations as old-but-gold going back to 1960 and many success stories in real world applications. Common Lisp has a direct lineage to that Lisp, but even ignoring that there's a syntactical linea…

I think perhaps to some degree, people read "Lisp stands for LISt Processing" and internalize this as a kind of shorthand (in spite of any formal naming), so it becomes natural to call any language that operates primarily through lists, and represents source code directly as nested lists, "Lisp".

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

#184

Post by segmondy »

barrkel wrote: post #131
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 reckon all software is plumbing. Plumbing as in taking data in, processing it, and pushing the data out. Doesn't matter if it's a database, a compiler, or a CRUD app; it's all just plumbing.

No, plumbing is taking prebuilt pieces like pipes and elbows, joints, valves and just putting them together.

There are plenty of software that is not about taking pre-existing packages and gluing them together, but rather involves construction from the ground up. Building a CRUD app using an existing framework, and an existing rest API with little to no custom business logic is plumbing.

Using sci-kit for your ML app is plumbing. Writing your own novel ML/deep learning algorithm, shoving the data in and out of GPUs is not plumbing.

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

#185

Post by ptero »

bpicolo wrote: post #163
dhimes wrote: post #153

Earlier quoted context omitted.

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?

I imagine this varies, but for me most of college was very much about the pure bits of computer science - how things tick, so to speak. But very little of your day to day at most enterprises is about writing new versions of data structures, or academic-level operating systems/database work (obviously there are some roles in the industry where this is the task, but it's not the majority). That's not to say learning it…

I agree with what you say for both the college (goal, value) and much of the real work on actual systems. To me, this splits pretty neatly into "prototyping" vs "operations".

Prototyping mindset allows you to try many things due to low cost of failure; operations does not. Most software work and in general engineering work outside of academia has at least a touch of ops flavor (i.e., high cost of errors), so to be successful (e.g., not to be labeled a loose cannon) one must be able to impose self discipline required for this. But most organizations have systems and environments for prototyping (or will gladly set up one if you clearly express your wishes and articulate some benefits).

Engineer that wants to work on new ideas then must learn to wear multiple hats (prototyping vs ops) and switch them as needed: the moment one glues one on he is limiting himself to either a rigid ops work (no, we cannot try new things) or a junior level dev (he cannot touch the real systems; his code does not work well enough).

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

#186

Post by jcadam »

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 built their careers on the over-hyped tech of the previous century and refuse to listen to new ideas, it's quite frustrating. 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.

I may just leave the field altogether and hack on Lisp in my spare time :)

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

#187

Post by oblio »

zero_shift wrote: post #176
oblio wrote: post #161

Earlier quoted context omitted.

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…

I know that Lisp has been largely stable, but are you sure it hasn't changed much? Programming paradigms advance, we didn't even have unit tests or continuous integration 20 years ago (at least not widely adopted in the industry). I find it hard to believe that even a Lisp programmer would be completely "static" across 20 years, i.e. the code written 20 years ago would be truly similar to the code he writes now.

So I'm not sure I buy this argument, unless someone has solid counter arguments.

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

#188

Post by matte_black »

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.

In general plumbing is considered the “blue collar work”. No one would put a boot camp front-end JavaScript grunt in the same league as an MS or PHD guy doing artificial intelligence research, compiler assembly, or reverse engineering malware.

And it seems ridiculous at times to even throw around the title of “Software Engineer” when the field has no standards of certification or regulation like other engineers. The only distinction from the programmer and engineer is the engineer makes architectural decisions, and the larger the scale the more accurate the title. “Plumbers” are cheap and no one cares if you fire them.

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

#189

Post by VonGallifrey »

ThrowawayR2 wrote: post #145
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... 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…

I could go and say that the aerospace engineer is also just doing "plumbing". The engineer is not going to design an engine for instance. "All" he does is specify what kind of engine he would use and then plug it to the fuel system and the wing structure. The engine was designed by someone else at a different company most likely. (Example: the Airbus A320neo uses PW1000G turbofan engines made by Pratt & Whitney. "neo" stands for "New Engine Option" by the way). This happens with a lot of the parts of an aircraft. Dismissing that as "plumbing" would be absolutely insulting to the engineer.

The same is true for a lot of software development. It is true that I am not going to design and develop ALL of the components of my software. For some things I will use libs and frameworks someone else made. I don't see a reason to be dismissive about that.

For instance I will be using the libs our hardware manufacturer provides to talk to the avionics bus of the A320. I don't see a reason to redesign our own ARINC429 avionics bus libs, but I also don't see a reason why this would make what I do not "actual software development".

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

#190

Post by segmondy »

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…

If you find yourself in such a scenario, then you haven't reached the enlightenment level.

Reaching for a "safe and familiar" procedural/imperative language is like most people reaching for a claw hammer when they wish to hammer and nail something in. To most people, it's the same, they are just hitting something.

To a pro, they know when they reach for their claw hammer, a sledge hammer, a mallet, a ball pein, club hammer or cross and straight pein.

If you have a text file that you just need to slice and dice. The tool to use is awk/sed/tr/cut, or perl. Got rules? prolog. Got massive array data? APL. Got multiple massive array data that you wish to combine and separate in various ways? SQL. Surely, you can use python for all those things. But should you?

Post reply on HN