Hacker News Reader

> unfortunately the tale of Lisps in companies is normally that it eventually gets replaced or set aside

Wikipedia page on GOAL says exactly this happened.

"In all honesty, the biggest reason we're not using GOAL for next-gen development is because we're now part of Sony. I can only imagine Sony's shock when they purchased Naughty Dog a few years back, hoping to be able to leverage some of our technology across other Sony studios, and then realized that there was no way anyone else would be able to use any of our codebase."

Sounds exactly like the sort of thing execs think when buying a company but then don't include in their due diligence.

I used to work for a company which got bought out and it turned out that the technology that they wanted us for was exactly the one piece of our code that we white labelled.

Was does white labelling mean?

I would guess they got it elsewhere and just resold it under their own brand (at least that is what it broadly means in hosting).

I can highly recommend the interview with Jason Gregory of Naughty Dog from Handmadecon 2016. He gives a lot of insight into the reality of working with the scheme-based format in recent-ish times.

https://guide.handmadehero.org/hmcon/2016/05/

My impression isn't that scheme is being passed out just because Sony doesn't like it, but also because the language has issues. On the other hand, it seems they're putting a lot of effort into getting the nice scheme features, like hot reloading, in their C++ environment.

> because unfortunately the tale of Lisps in companies is normally that it eventually gets replaced or set aside (where new stuff is built in something else).

Any sufficiently advanced Common Lisp or Scheme program will eventually be rewritten in C++, Java, Python, or JavaScript.

> Any sufficiently advanced Common Lisp or Scheme program will eventually be rewritten in C++, Java, Python, or JavaScript.

I'd change that: `s/sufficiently advanced/sufficiently profitable/g`

The state of advancement is no indicator that something needs to be maintained, while the state of profitability is a reliable indicator that something will be maintained.

Why? Is there a reason other than "most people don't know lisp and it's cheaper not to teach them?

That's probably part of it.

Another possible factor: When I was at Google there was a similar phenomenon where any sufficiently complicated Python system seemed to get reimplemented in something with static types. A problem we had with Python (and I imagine this would be true of most Lisps -- yes, I know typed Racket exists) was that once a system got too big to keep in your head all at once, large-scale refactoring became almost impossible without the help of static types.

I agree that static types is certainly a barrier. My day job is in a dynamic language for the first time ever, and it's certainly been a challenge and learning curve for me. It's in Elixir, so I just seemingly annoy everyone by putting typespecs on everything. Haha. Even if Dialyzer isn't ran, it still provides some documentation on what's going on where.

My personal opinion is that there aren't any huge barriers to making static and dynamic types meet more in the middle. There's the gradual typing approach like that in Racket and Typed Racket, but I feel that most of the times dynamic languages are really just dealing with fairly simple anonymous unions. Like a function make take a string or float and return some data structure or a boolean value.

yup. fortunately, static typing support in python has made significant progress on both tooling and language fronts in the past few years.

In my experience, companies are deathly afraid of doing something even perceived as different when it comes to software. And my experience has been at places developing advanced novel hardware, so I would always try to point out the discrepancy. Why are people willing to try new things and train on advanced hardware projects but software gets relegated to the least common denominator? If it's not Python, C, or C++, it's a hard sell to try anything else, no matter the many multipliers that could come from switching.

I think it makes sense. When I start a new project, I tend to limit the number of risks I'm taking at a time. If I'm using a brand new language, I'm probably not going to also use a brand new database. If I'm going into a brand new domain I'm completely ignorant of, I'm going to use non-risky tech. And so on.

Could it be a lack of trust in the capability for learning new (old) things? The thinking, that a software developer is but a script kiddy?

I wish it were so simple, yet I think the rapid advances in the last 10 years or so in Java, C++, and JavaScript, which developers have been expected to learn and keep up with, are sufficient to more than cast doubt on that. The changes on whole are nearly broad enough to count as new languages. If that's not enough, then there's the mobile development side of things, which have seen actual language shifts in Objective C to Swift and Old Java to Kotlin.

Successful programs tend to attract reimplementations, and those are probably written by different kinds of people than the originals.

People even completely rewrite older Java programs into newer Java programs, changing large parts of the technology stack...

I love hearing Gavin talk about solving problems, even decades afterward, he seems genuinely excited.