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

211–220 of 433 posts

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

#211

Post by kamaal »

buserror wrote: post #57
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…

I've been writing C for 30 years+, and my style has changed massively in that time. In the meantime I did all kind of other things, perl, ruby, Obj-C, C++ (a LOT), java/script etc etc... My 'design patterns' in C now has a lot more of the things I 'liked' about these languages, lots of abstractions, actors, compartmentalization and many many more, as well as the most important bits like multi-core/threads aware APIs…

Perl style has changed over the years too. Current Perl coding standards and bulk of the code getting written is very different compared to the early internet Perl code.

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

#212

Post by threatofrain »

ubermonkey wrote: post #195
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 connect…

It's like saying a doctor isn't doing interesting things if they're just content to apply medical knowledge to improve community health. The doctor is just using tools developed by other people.

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

#213

Post by nickpsecurity »

pavlov wrote: post #22
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?

The APL / J / K family of languages seems to be very strong with this effect. If it fits your problem domain, it's (apparently) so powerful that using anything else feels like a frustrating waste of time.

Those of you interested in APL/J/K might find Iverson's book Elementary Algebra interesting where he defines lots of operations in array notation. I dug up this PDF looking for one that was out of print:

http://www.softwarepreservation.org/projects/apl/Papers/Elem...

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

#214

Post by mikelevins »

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…

I think this comment is unhelpful. The meaning of "Lisp" is a little bit complicated, but I think it can be explained better than this.

"Lisp" has two meanings: (1) ANSI Common Lisp; and (2) the family of programming languages to which ANSI Common Lisp belongs, and which was called "Lisp" many years before ANSI Common Lisp was conceived; that family includes many other languages with quite a bit of variety, including Scheme, Clojure, INTERLISP, T, kernel, picolisp, *Lisp, (the early versions of) Dylan, and many others.

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

#215

Post by piva00 »

segmondy wrote: post #180
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…

I don't agree with this view.

Most jobs working with software development is about creating business value. Either as an end-user product that your customers are going to use or with internal tooling that will help the business have more access to data, streamline processes, increase efficiency, etc.

This "no true Scotsman" approach to software development is actually quite funny after a while being a professional, it's a huge industry, there are terrible companies, there are terrible managers, product managers, etc., but there are also great ones. You can work for good ones if your current gig is mostly being pushed around by unreal expectations from your stakeholders.

The demand is not for short-term gains, how can you justify that it's going to take a year to build your perfectly architected software if the business really needs that done in 3 months and you assess it's quite doable if you decide on some constraints? Your job as a professional engineer is to be able to find ways to do your work as best as possible given constraints, to design something to be improved on over time, to communicate with stakeholders and, given your area of expertise (software), give valuable input to the business decision so they can be the best as possible at that moment.

Seeing software engineering as some grandiose goal by itself is quite wrong, software exists MOSTLY to fulfil business purposes.

It's not about "conforming", there is software that is fun to work, that are intellectual challenges by themselves but that really have no way to be justified on a business level.

This defensiveness against "business" is part of a mindset that should be broken among engineers, we should embrace we are part of a much larger process, not that we are the golden nugget and the top of the crop at a company. Our work is to enable others' work.

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

#216

Post by bpicolo »

ptero wrote: post #185
bpicolo wrote: post #163

Earlier quoted context omitted.

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

I agree that that's one really interesting way to consider the split, good call on that! Being able to experience those multiple hats is definitely important.

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

#217

Post by contingencies »

segmondy wrote: post #184
barrkel wrote: post #131

Earlier quoted context omitted.

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…

Your distinction doesn't hold up to analysis: at some level any system can be said to consist of elbow joints - eg. "processor opcodes are just elbow joints." The same can be said not only of the subsystems but also the intellectual heritage of so-called "original" systems. Nothing and everything is new. News at nine. Someone watches the news. They create a new system ever so subtly influenced by yours. Ad infinitum.

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

#218

Post by jstimpfle »

segmondy wrote: post #198
jstimpfle wrote: post #174

Earlier quoted context omitted.

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

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

No, you need to structure your data in a way that there is almost no boilerplate, and only very little glue code (which effectively amounts to "the macro code", with the difference that it's only executed once per data object).

> Do you think those are bad because those are code generation that don't look the way you think they ought to?

Good point, but I have a strong belief that the abstractions offered by C (function calls and good syntax for arrays and records) are sufficient and going up is detrimental for larger systems. I don't code in assembler because typically there is too much redundancy (function call convention) and it's too specific (architecture dependent) and probably too verbose. That said, I'm not strongly against it, but haven't really tried.

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

#219

Post by pritambarhate »

segmondy wrote: post #180
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…

> However the market does't care for that. The market prefers short term gains over long term gains.

I agree with this. For example, Sun was sold for $5.6B in 2009. [1] While Skype was sold for $8.5B in 2011 [2].

Sun had Solaris, Java, SPARC, and MySQL. Skype was a chat tool.

Even today many popular databases find it hard to get billion-dollar valuations, while multiple Social Companies has done it.

The market doesn't care about core CS. It cares about monetary gains.

[1] https://en.wikipedia.org/wiki/Sun_acquisition_by_Oracle [2] https://en.wikipedia.org/wiki/Skype

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

#220

Post by ziikutv »

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…

Any suggestions on how I can get into that 10%?
Post reply on HN