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

291–300 of 433 posts

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

#291

Post by jihadjihad »

pritambarhate wrote: post #219
segmondy wrote: post #180

Earlier quoted context omitted.

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

The issue I have with this view is that unless you have people on your team with fundamental, "core CS" capability, creating a behemoth like Skype or Snap just isn't possible. Of course, there's a balance, and who knows, maybe it's Pareto with 80% of the team focused on engineering and 20% focused on math/CS/R&D.

The monetary gains the market sees are the direct result of clever math and CS, not bolt-on solutions that can be lifted from libraries on GitHub.

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

#292

Post by jstimpfle »

zeveb wrote: post #255
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…

> I much more need a syntax that does not hide what happens (procedure call, list indexing or at least "indexing"). Each of those is actually hiding what really happens. E.g. for a procedure call the runtime compares the arity of the call and the called function, inserts each argument into a data structure of some sort, perhaps grafts together environments or does other things on a language-specific basis, performs a…

For Python, I agree to an extent. The machinery is hidden of course. That's the price of the convenience of a dynamic scripting language. But one still can see the relevant things. For example, for a subscripting operation, what counts is often only the mathematical aspect of it: It's a right-unique relation (i.e. a mathematical function) applied to the given element. And it's reasonably fast - even in Python with dicts, we can assume O(1) for most purposes.

It's nice when these important properties are indicated by a visual clue (square brackets).

> A sufficiently-powerful programming language enables the programmer to develop the abstractions he needs for the problem he has.

Sure. And that programming language still happens to be C for many, many purposes.

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

#293

Post by matte_black »

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…

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 ability to distinguish between skill levels. The same will happen with code.

I remember when mobile development was at its hottest peak, declaring I was an iOS developer practically made people bow down in awe and throw offers my way for help with developing their mobile app idea (usually in exchange for equity or “revenue share”). Nowadays the field is so commoditized I don’t even mention my 8 years experience with iOS except in passing conversation.

A computer science degree is enough to call yourself a software engineer because most people can’t tell the difference these days. But for people who know the industry, a front end dev whose job is to basically push pixels on to a page is hardly an engineer, and I’d say is our modern version of a mid ‘00s website designer.

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. Naturally, this will be met with resistance because there are many people who will not qualify, and who do not want an engineering license that would require them to be liable for their work.

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

#295

Post by dhimes »

bpicolo wrote: post #250
dhimes wrote: post #235

Earlier quoted context omitted.

Thank you for your thorough reply. Colleges are under fire, even from their own ranks, by people whom I believe confuse training with education , but it's clear that's not your issue. It sounds to me like there needs to be some sort of deep-dive "onboarding" program where new hires can work on a curriculum of projects and learn the SOPs of the organization. Colleges could take some of it on, of course (testability an…

It would be interesting to see a course than spanned multiple years building upon the same project with the same team, emphasizing different aspects year-by-year, but I imagine that would be pretty nightmarish on the scheduling front.

It's also a problem of how much you can ask a student to do. There was a time when the expected time to complete a "4-year degree" was approaching 6 years in the engineering-ish fields, and the tuition-check-writers got pissed and called their state legislators to put a stop to it. So adding some sort of multi-semester capstone project would have to be woven into what is already in place, but I would imagine it wouldn't entirely fit into the curriculum without increasing the student level-of-effort (meaning, all of the stuff being taught would still have to be taught, but in addition the extra bits special to the scale of the project would add to the overall workload).

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

#296

Post by CrystalLangUser »

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…

Programming functionally forces you to approach programming in a fundamentally different way than what you’re used to.

It’s not a magic bullet. But what you learn can be used in other languages, especially things like Map, Filter, and Reduce.

I totally recommend experimenting with Clojure or Haskell and implementing a project with a pure approach & immutable binding, or as much as you can.

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

#297

Post by flavio81 »

weavie wrote: post #68
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…

We are getting to the stage now where a lot of languages are catching up with the features that lisp had in the 70's, so the huge benefits of lisp aren't quite as obvious as they used to be.

>so the huge benefits of lisp aren't quite as obvious as they used to be

They still haven't caught up. I don't find any other language that gives at least 3 of these features

- Fully interactive development -- i can recompile/redefine a function while the code is running

- Fully interactive OOP development -- i can recompile/redefine a class while the code is running

- OOP system based on multiple dispatch/multimethods

- true metaprogramming done using the same language's syntax, not a special, cumbersome lib.

- execution speed on par with the JVM and sometimes approaching C speed.

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

#298

Post by flavio81 »

drivebyops wrote: post #125
phoe-krk wrote: post #71

Earlier quoted context omitted.

Lisp isn't a functional programming language. It's multi-paradigm.

More importantly it isn’t statically typed (like F#, Haskell, etc)

>More importantly it isn’t statically typed (like F#, Haskell, etc)

You can statically type variables (bindings) in Common Lisp if you want:

    (defun little-function (x y)
       (declare (type fixnum x y)) 
           (+ x y))
Although type checking is limited at compile time.

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

#299

Post by jstimpfle »

bjoli wrote: post #286
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…

Whatever programming language you are using, at some point or at some representation the compiler will start generating code. The difference is that the default code representation of lisp allows it at source level, making writing (and debugging) them a lot easier. An if statement in python generates a shitload of bytecode that the optimizer then does what it pleases to. With lisp you can watch that process by watchi…

> An if statement in python generates a shitload of bytecode

To be precise, it will generate something like 'JUMP_IF_FALSE' which is not exactly a shitload. Not saying the execution will be fast. After all, it's an interpreted language.

> Macros allow us to extend the language.

We're on the same page. What I was saying is: if you need more than function calls and records, chances are you're doing something wrong... the program architecture becomes intransparent. Macros and other conveniences allow for hacks put on other hacks, until you don't understand your program anymore and development eventually stalls.

I once added cooperative multithreading by switching stacks in a C program. It was very easy to do and helpful for that project, but small hacks like this are rarely needed. (And in that instance it could have possibly been avoided, but I wasn't in a position to change the dataflow architecture).

Post reply on HN