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

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

#341

Post by blt » Wed, Mar 14, 2018, 6:21 PM UTC

pjc50 wrote: post #248

matte_black wrote: post #188

Earlier quoted context omitted.

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…

Interesting that you put those three together; while cutting edge AI research might require that level of academic background, I wouldn't say that compiler work does. It's more within the reach of an undergraduate degree course. And malware (for and against) is a completely different field altogether, full of people with unconventional backgrounds and a large chunk of poachers-turned-gamekeepers. I think it will be a…

I don't agree. The typical undergrad CS program doesn't prepare people for AI research, but that's because it dedicates lots of time to discrete/combinatorial stuff and low level systems knowledge. Drop/condense architecture, OS, compiler, exotic data structures and algorithms, networking, programming languages. Add more calculus, linear algebra, probability, optimization, statistics, symbolic AI. That undergrad would be equally good at AI work as a traditional undergrad would be at compiler work. AI field is rarefied now but will not be so forever.

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

#342

Post by astine » Wed, Mar 14, 2018, 6:34 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 think that no matter where you are as a programmer, you're part of the plumbing crowd whether you like it or not. If you hack together websites using a web framework like Rails or whatever, then that web framework is likely your plumbing. If however you write a web framework, then the language (Ruby, etc) is your plumbing. Those who write languages have operating systems and those who write operating systems have hardware. Even hardware has different levels of abstraction in it from folks designing instruction sets down to folks who have to actually deal with the physics of circuits on silicon. The things is though, a lot of those folks wouldn't be able to deal with the stuff that a typical web developer deals with because they don't understand the domain. Writing a highly performant web server is a different task from writing a complete web application that uses that web server. I think that's it's useful to have a deeper understanding of the tools we use, but ultimately we all have to work at the level of abstraction that makes sense for the work we do and that's not a problem.

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

#343

Post by cr0sh » Wed, Mar 14, 2018, 6:36 PM UTC

matte_black wrote: post #293

pjc50 wrote: post #248

Earlier quoted context omitted.

Interesting that you put those three together; while cutting edge AI research might require that level of academic background, I wouldn't say that compiler work does. It's more within the reach of an undergraduate degree course. And malware (for and against) is a completely different field altogether, full of people with unconventional backgrounds and a large chunk of poachers-turned-gamekeepers. I think it will be a…

The point is there was once a time when sprinkling some HTML and putting a site on the web automatically made you a wizard, and if you were young enough you might even be hailed as “the next Bill Gates”. Those days are over. When society was illiterate, people who could simply read and write might have been held in the same prestige as those who write novels or manuscripts. As literacy grew however, so did society’s…

> Having a timeless standard for what makes someone a Software Engineer that we can all agree on and can be verified by third parties would be helpful.

I would think that if this were possible, it would have happened by now.

Programming as a profession - while not as old as other "engineering professions" - is much older than what you are insinuating here; for instance, COBOL dates from 1959, FORTRAN is a couple years older, and there are a few older languages before that.

https://en.wikipedia.org/wiki/History_of_programming_languag...

But let's use COBOL as a "standard" - since there is a ton of COBOL out there still running and being maintained (and probably more than a bit being created "new"). That's almost 60 years worth of commercial software development (using various languages starting with COBOL).

If a standard could be considered and developed, it would have likely been done by now.

There are more than a few arguments as to why it hasn't, but one of the best ones I have read about has to do with the fact that our tools, techniques, etc - seem to change and are updated so quickly, that standards for testing would become outdated at an insane pace. An engineer certified on a set of standards might be obsolete before he left the building!

Ok - somewhat hyperbolic, but you get the idea. For the "classic" engineers, their tools and techniques don't change much if at all over long periods of time - so certification is more straightforward. For some engineering professions, you can pretty much take someone who was certified in 1970, and be pretty certain that he or she would be able to do the same kind of work today. That would definitely not be the case for a proverbial "software engineer" certified to the standards of that time...

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

#344

Post by sedachv » Wed, Mar 14, 2018, 6:41 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.

> Maintaining a distinction between "actual software development" and "plumbing" is elitist

I don't think it is. Someone that is slapping together libraries from npm, but has no idea how to debug with gdb or use strace/ktrace/dtrace etc to diagnose problems with the resulting system, or does not have the skills to fix bugs or add new features to the "plumbing" - that person is not an actual software developer. There is a huge gap in skills, knowledge, and as a consequence the capabilities of these two camps of people.

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

#345

Post by blablabla123 » Wed, Mar 14, 2018, 6:51 PM UTC

sedachv wrote: post #344

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 I don't think it is. Someone that is slapping together libraries from npm, but has no idea how to debug with gdb or use strace / ktrace / dtrace etc to diagnose problems with the resulting system, or does not have the skills to fix bugs or add new features to the "plumbing" - that person is not an actual software developer. Th…

I think this is going into the wrong direction. In my world "plumbing" means realizing ways to do things. When you want to write a simple web app that shows a Hello and has a contact form: even in 2018 that's still a reasonable amount of work. It's really not a lot of code but every line needs to be chosen wisely. That's what I call "plumbing". Most people new to Software Development become desperate at such tasks and to the rest it becomes embarrassing quickly... :-)

Yeah and then there's actual code writing: the heavy lifting has been done, all the functions/classes/modules/... are still small and wait to be stretched with a lot of nice code. In well sorted projects the latter is a trivial tasks for simple features.

But yes, I agree with the sentiment that there is a lack of general "understanding of stuff". I'm not sure if you must be able to use strace to be productive but it sure helps if you're able to get to know tools that are installed on most systems. Coming back to the OP's topic: LISP is a language that uses formalisms (ways to plumb ;)), tools (ever heard of asdf?) and syntax complete alien to even long-term computer addicts. It always puzzled me how people can be comfortable using this kind of stuff.

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

#346

Post by lispm » Wed, Mar 14, 2018, 6:52 PM UTC

kamaal wrote: post #308

lispm wrote: post #260

Earlier quoted context omitted.

> For all practical purposes CL, Scheme, Clojure and Elisp are all lisps. Since only CL and Emacs Lisp can and do share actual Lisp code, I call only them Lisp for practical purposes. For 'unpractical' purposes - they share no source code but are influenced by practical Lisp - , Logo, Javascript, Ruby, Clojure ... are also Lisp.

>>Since only CL and Emacs Lisp can and do share actual Lisp code But what exactly is 'actual lisp'. I mean what is this strict definition? Forgive me, I understand calling Scheme and CL as same might feel like saying Java and C++ as same. But one would be right in saying Java and C++ both come from a C based paradigm. On the same lines one could say CL and Scheme come from lisp paradigm. At this point in time both co…

The problem is that both CL and Scheme communities have very little to do with each other.

For practical purposes Lisp dialects are those directly inheriting back to Lisp I from McCarthy. You can run programs from 1960 in Common Lisp with very little changes (unless it uses machine interfaces). To port them to Scheme is possible. To port them to Logo, Clojure, Javascript or other languages considered to be dialects in a wider sense mostly means a rewrite.

Thus for me Lisp means the dialects of Lisp and their respective communities which can share code, libraries, applications by relatively simple ports. For example Emacs Lisp has Common Lisp enhancements, which are semantically very similar. ISLISP could be directly integrated into a Common Lisp - Kent Pitman mentioned that he actually did that to see that they are culturally compatible.

Languages who don't directly share code are maybe part of an abstract family, which has no agreed on definition - thus this is for practical purposes relatively useless.

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

#347

Post by AnimalMuppet » Wed, Mar 14, 2018, 7:13 PM UTC

patrickmay wrote: post #142

Jach wrote: post #74

Earlier quoted context omitted.

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…

Good list. I'd add macros and the conditions mechanism for error handling. The latter still has no analogue in other languages.

> The latter [the conditions mechanism for error handling] still has no analogue in other languages.

Could you explain this for a non-Lisp person? (I have some understanding of macros already.)

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

#348

Post by dahauns » Wed, Mar 14, 2018, 7:13 PM UTC

kqr wrote: post #328

dahauns wrote: post #223

Earlier quoted context omitted.

Ah...! Sorry, I misunderstood you there. (Ok,ok. I admit I only skimmed your reply :) ). But why would you want Turing completeness in a user facing templating engine? This is generally considered harmful, leading to all kinds of maintenance horrors. (And that's why StringTemplate deliberately isn't.)

I'm not so sure it's the turing completeness that is harmful, rather the inscrutibility of code. Lisp doesn't have that problem since code is data!

OK, now you're just messing with me. :)

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

#349

Post by AnimalMuppet » Wed, Mar 14, 2018, 7:32 PM UTC

6ak74rfy wrote: post #288

On a tangential topic : I am intimidated by how myriad experiences with programming languages HN commentators on this thread have. I have been in this industry for about 8 years and am considered an above average developer in my current company. I have primarily worked with Java, while fiddling with others here and there. No experience with pure functional languages such as Lisp or Haskell. Am I missing out some impo…

> Am I missing out some important part of the developer experience?

Of course you are. Everyone is.

There are maybe 100 different language/style/technique boxes you could check. You might be able to check three. You look around here, and you see that, for every box, there is someone here who can check it. But no one person here can check more than 20 at most, maybe no more than 10.

Don't look at the entire site and feel inadequate. Don't even look at some of the people who have 40 years experience and feel inadequate.

But yes, as others said, look to learn things that are different from what you know.

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

#350

Post by AnimalMuppet » Wed, Mar 14, 2018, 7:35 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…

> But when you're stuck working for 50-something pathologically risk-averse architects...

Defense/aerospace is pathologically risk-averse. It's not just your set of architects.

If you want them to listen to new ideas, propose it on something that is not mission-critical. Prove it can work there, and prove the benefits. After you've done that (more than once), they may be willing to at least listen.