Hacker News Reader

Comment by d--b | Hacker News Reader

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

View on HN

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 :)

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

And by the time you'll be able to do that you'll be the 50-something who keeps using functional programming while the 37-year-olds want to use dilithium crystal programming :p

While you're joking, one thing that appeals to me about my recent dive into functional programming is that it strikes me as knowledge that is 'fundamental' enough that it'll never disappear or become irrelevant.

Exactly like OOP!

Though, I'll point out that my problem is not necessarily with OOP, but OOD. OOP can be quite useful in some situations, such as modeling and simulation :)

Of course the design of the Java language is predicated around the idea that OOD is the one true way to design large software systems and thus must be forced by the language itself, and that is the primary reason I hate it.

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

He worked for Google pre-IPO and is now an angel investor and the CEO of Spark, I don't really think he's looking.

ok, perhaps before talking about why a career is ruined, a pre-requisite should be that the said career is indeed ruined.

Keep in mind there's a part of the Lisp crowd that prefers loop and setf over more functional idioms. Unlike many other languages, Lisp is good for writing functional code, but people tend to forget that it's also a pretty kickass imperative and object-oriented language.

> Keep in mind there's a part of the Lisp crowd that prefers loop and setf over more functional idioms.

I have used Common Lisp for low-level concurrency and IO code, and as a target language for transpilers, and the most indispensable construct for those applications is GOTO. The only other substitute is a good compiler with guaranteed tail-call optimization. Some people love to point out how you don't need Lisp because "modern" dynamic programming languages have borrowed this feature or that. Ok, but none of those languages (can anyone provide an example? I cannot think of any) has GOTO or guaranteed TCO. If you want to do systems programming in a dynamic programming language, the choice still comes down to either Common Lisp or Scheme.

>and the most indispensable construct for those applications is GOTO.

That's what I like about Lisp: It isn't opinionated. There's no weenie saying "GOTOs are harmful so we delete them from our language", or "OOP sucks so our language won't have any OOP facilities", or "mutable data is bad so there's no mutable data here", etc.

Quite the opposite, Lisp gives you everything. Want OOP? Here's a deluxe OOP system. Want to do GOTOs? Ok, here you are.

It has gotten me the best jobs I've had, but they are few and far between.

If you want to be a Lisp programmer then you pretty much have to be good at other things, too, or you may starve waiting for that next Lisp job to come along.

Of course, you can always just write your own products in Lisp.

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.

As well, dynamic typing is much less of an issue in Lisp than it is in most other dynamic languages because the debugging and error handling features are really that good; they pick up most of the slack that the less-present type system creates. It would still make a lot of static typing proponents uncomfortable, of course, because not nearly as much is being statically verified. I think that the reason people become so infatuated with static verification (and testing) (not that they're bad things or anything, but just the reason they get put on such a pedestal by some people) is frustration with languages like Python, Ruby, and Javascript, which all lack a lot of the tooling that Lisp or Smalltalk has to make working in a very dynamic environment not only tolerable, but preferable. People get frustrated with the lack of tooling around mainstream dynamic languages' dynamism and attribute it to being frustrated with the dynamism itself.

Common Lisp has strong dynamic typing. Dynamic, because language runtime maintains type information; strong, because each object has its type and cannot be treated as an instance of another type.

True, but he was asking about static typing.

Reply on news.ycombinator.com