Comment by reikonomusha | Hacker News Reader

Comment by reikonomusha | Hacker News Reader

Many folks have said it here but I'll say it again: Common Lisp.

I have been using it professionally for 5+ years as a full-time employee at various companies. Some big-name ones, some smaller start-up ones. The mean Lisp team size has been around 4, but I did work on a project of 15 Lisp programmers. None of these projects were legacy code. Some were in places you wouldn't expect (embedded, multi-processor systems on custom-designed boards, for example). In every single case, we had no additional trouble hiring a Lisp or Lisp-capable programmer as compared to hiring for any other language, including Python. (In fact, Python was more difficult to hire for because the market is saturated with beginners who claim expertise.)

Lisp is one of those languages where the ratio of long-term benefits and productivity vs. good initial impressions is at a record high. It doesn't look like C or Python or JS, with all the parentheses, so people brush it off.

Lisp isn't the pinnacle of every great idea to come about in computer science and software engineering, but it is one of the most robust, macroscopically well designed, and most productive languages for translating arbitrary abstract ideas into maintainable, production code. Even if it doesn't look initially very pretty in the eyes of a career Python programmer.

>In every single case, we had no additional trouble hiring a Lisp or Lisp-capable programmer as compared to hiring for any other language, including Python

Doesn't that imply an over-supply?

I did my grad research on a highly specialized topic, involving plenty of math/physics.

Then I worked in industry applying my skills for 4 years.

Then I switched to programming - nothing related to my engineering degrees. This job requires only a BS (and not really that - one of my coworkers has no degree).

The highly specialized job was the one where I had little leverage, lower pay, and a miserable experience. Why? Fewer jobs than supply.

Whereas for programming, the supply is much larger than for the specialized work, but the demand is even larger than the supply.

The geek in me yearns for a job where I can go back to numerical algorithms and physics. But frankly, those jobs tend to suck when you don't have much leverage.

If you have become a truly skilled industrial programmer, you can very easily go back. There are a lots of interesting scientific programming jobs, but your typical Ph.D or post-doc is only half trained for them, at best.

There are fewer pure research positions, and unless you are very good there is a leverage problem there because every year dozens of new grads come looking for essentially that job. Something to bear in mind if your desire is primarily to work in matlab/python/R on things that look a bit like your thesis did.

Does it indicate over-supply? Maybe, but it's probably a bit more complicated than that. There is a very large supply of self-proclaimed Python programmers. (There's no official accreditation of this, of course, so we can only go by self-proclamation.) But this is unlike, say, raw materials supply for building a bridge. A lot---and by "a lot", I mean enough to be noticed when hiring---of the "Python programmer supply" is under-skilled. So, in reality, and limited to my own experience, the supply of skilled, knowledgeable Python programmers is much less than that of the total supply, so I'm not sure I'd label it as "over-supply".

With that said, though, and especially with huge companies like Google using Python as one of their main languages, the supply of qualified Python programmers is no doubt larger than that of Lisp. But, it's a fallacy to believe that the supply of qualified programmers correlates inversely to the time spent searching for them. It's sometimes easier to find needles that standout in the haystack.

As for software jobs in the domain of math/physics/etc., they're out there, but just harder to seek out. The world hasn't run out of hard science problems to solve, and many companies would go to great lengths to hire brilliant individuals who have both scientific acumen and programming skills.

>As for software jobs in the domain of math/physics/etc., they're out there, but just harder to seek out.

I'm well aware of that. However, my experience is the working conditions are poor. Some do have a higher salary, but everything else seemed worse.

Also, not entirely related, but it does suck more when you're working on a very challenging problem, and can't fully crack it on the company's desired schedule. You get negative feedback with veiled threats about losing your job. When you're in that situation, and realize that you can get a much easier job with similar pay, you have to ask yourself whether the risk of working a "science" job is worth the rewards.

It was all fun in grad school, where the deadlines were much looser and you're not worrying about saving for family, retirement, etc. But it really sucks if your livelihood is at stake merely because you wanted the thrill of working on a more challenging problem.

I've often thought it's probably like that. I'm an engineer solving complicated problems, but nothing cutting edge. Hours and pay are good.

I would guess, maybe, but if the companies hiring Lispers try to low-ball their pay and work experience too much, the Lispers will just move on to programming a different language somewhere else.

Yes, might take a little time to get your Github up to speed with samples in a different language and employers intelligent enough to see past "X years in Y language" requirements, but I think it will be an easier shift than numerical algorithms and physics to programming, I think.

Can you elaborate on the work you did - in particular what problems did you have to solve, and why Common Lisp was used instead of other languages?

Slime + emacs for your environment?

Yep, all the way. Slime + Emacs + Paredit.

Ah interesting. I thought paredit was standard in emacs.

You mention several benefits, how many of those do you feel apply to all "lispy" languages, and how many are specific to Common Lisp [in your opinion]?

I think it applies to Common Lisp specifically. I think languages like Scheme are just "not there" in terms of ecosystems and other things important to the professional programmer. I think debuggers, avenues for professional support, a unified standard, a variety of highly compliant open source implementations, and other things are necessary for any projects a business should invest in. Not to mention a sort of package manager.

The one exception is maybe Clojure, but I find Common Lisp to be all around better at the problems I've worked on (namely ones where at some point or another, a native machine code compiler is required). Clojure' async/immutability story seems good for larger distributed systems, though, and interoperation with Java is invaluable to some projects. (Though, Common Lisp does have an implementation atop the JVM, called Armed Bear Common Lisp. This is one of the many benefits of an official language standard.) But by using Clojure you are definitely locking yourself into a single implementation.

Are there resources you'd recommend for finding jobs in CL ?

The canonical site is https://lispjobs.wordpress.com/

Googling, LinkedIn searching helps.

+1

Reply on news.ycombinator.com