5 ms·

Remarkable to me that Google would spend so much on software engineers and then hobble them with blub languages. If they decided to push a niche but superior la

Remarkable to me that Google would spend so much on software engineers and then hobble them with blub languages. If they decided to push a niche but superior language then people would learn it (as they did with Go).

bitwize 3y ago
Google's main line of business back in the day involved crawling and indexing as much of the entire web as possible. When you're operating at that kind of scale, back in the 2000s-early 2010s your choices were C++, and pretty much nothing else. Garbage-collected languages introduced too much overhead. Keeping the number of languages small, and keeping them purpose-focused (C++ for the heavy stuff, Java/Python for web backends, JavaScript for UIs) helped unify coding standards and conventions within and across teams, reining in the chaos that would have ensued had Google allowed developers or teams to choose languages willy-nilly. These sorts of language restrictions are not a knock against the skill of Google engineers. A good programmer can be good in any language. Even C++. Even Java. Think of the midwit meme, with the simpleton at the left going "just write everything in C++ or Java", the midwit in the middle going "NOOOOOO! Lambda calculus/monads/Hindley-Milner type systems!" and the genius/Jedi monk at the right going "just write everything in C++ or Java". The appeal of Lisp when writing production code is to lazy, mediocre programmers who think Lisp's sexy features will extend the reach of what they can create. Which is true, to a certain extent, but a) not as much as they may think; and b) when you consider that Lisp programs are bloated and slow compared to the corresponding C++ programs, the juice just isn't worth the squeeze. Lisp peaked ~60 years ago. There are very sound technical reasons why it is obscure today.
- MaxBarraclough 3y ago
  > A good programmer can be good in any language Kinda. Language-specific expertise should not be downplayed. If you've spent a decade honing your craft writing C and assembly for exotic embedded platforms, you'll be a valuable asset for certain projects, but your experience won't translate to Scala or Haskell.
  - lispm 3y ago
    Part of your expertise is not the language, but the application to embedded platforms.
    - MaxBarraclough 3y ago
      Of course, but the point stands. Consider an expert in C programming for embedded platforms, and an expert in Ada (or Forth) programming for embedded platforms. The surrounding expertise is similar, but the language-specific expertise shouldn't be dismissed.
  - bitwize 3y ago
    I think I meant more like "every language can have good programmers writing top quality code in it, even (especially) the blubs", not that a given good programmer will be able to immediately translate their expertise to a vastly different language or environment.
  - fire_lake 3y ago
    > A good programmer can be good in any language Well, I’ll rewrite it in Brainfuck then.
- cess11 3y ago
  SBCL generates quite performant code. A distinguishing characteristic of languages like Lisp or Elixir is the metaprogramming. C++ and Java have nothing like their macro systems, and when an application grows and turns complex it's a very nice tool to keep developer facing code neat and readable. Usually it also keeps it more robust under change, there are fewer lines where typos or logic bugs can creep in when you write less boilerplate and use well designed code generation instead.
  - bitwize 3y ago
    > SBCL generates quite performant code. Then why are virtually all browser engines, high-performance games, and video codecs written in C++? Why is every massive-scale web application written in C++? The only one that comes close that's written in Lisp is QPX, and even then they had to write a lot of C++ because Lisp's I/O facilities just weren't up to the task of moving the huge amounts of data they had to move. > C++ and Java have nothing like their macro systems C++ has template metaprogramming, which covers like 90% of the cases where you'd actually need Lisp macros, and outputs code that's statically typechecked with deterministic memory and runtime constraints.
    - cess11 3y ago
      Whatsapp is written in C++? When did they do the rewrite? You can have compile time type checking in Common Lisp if you want.
    - nequo 3y ago
      > Why is every massive-scale web application written in C++? Sibling mentioned WhatsApp which was Erlang. Facebook is PHP. Pre-Musk Twitter was written in Scala.
      - p_l 3y ago
        Twitter before Scala was done in Ruby on Rails, even.
    - p_l 3y ago
- reikonomusha 3y ago
  I think this is the perfect opinion to have for a middle manager at a large FAANG with seemingly infinite developer supply and little existential incentive to innovate. In practice, C++ and Python codebases have insane amounts of churn. They're constantly moving targets and require a lot of overhead to keep in shape, from just about every perspective: performance, security, maintainability, implementation compatibility, etc. It's tolerated though because it's standard practice, and we developers get a paycheck anyway. Languages like OCaml, Common Lisp, Haskell, and other niche but obviously practical languages continue to be indispensable to certain cohorts of companies and developers. While I do agree that Lisp specifically peaked in popularity decades ago, it still exists in the commercial domain with resounding staying power, even in environments where it could in theory be replaced by C++ or Python. It's also abundantly clear there's a hunger for new (or at least replacement) languages for the stalwarts. Rust, Julia, Mojo, Swift, and OCaml are a few such languages that get attention in their commercial investment and development, often with the specific purpose of replacing Python or C++. As a personal anecdote, I find professional Common Lisp programmers generally to be quite sensitive to matters of bloat. Some programmers go as far to chisel away needless cons cells (or allocation in general), and constantly be in touch with the compiled assembly—something frequently ignored by professional C++ programmers of comparable experience. I would love to hear the "very sound technical reasons" explaining Common Lisp's obscurity. Given the vast and diverse biome of programming languages in use today, including and especially in professional settings, I'm quite interested in understanding what technical reasons uniquely relegate Lisp to obscurity.
  - perrygeo 3y ago
    My take (not OP) is that it's not so much the technical features of Lisp itself, but the fact that other languages evolved competing features. Over the years, they have slowly chipped away at Lisp's advantages. 50 years ago, Lisp was uniquely powerful with no rival. Today, Lisp is yet-another powerful language to choose from.
    - vindarel 3y ago
      I disagree: Common Lisp has many remaining powerful features AND a large set of them, when a language maybe caught up with one. The interactive debugger is unmatched, image-based development nearly doesn't exist elsewhere, the condition system… Example: fix a bug without quitting the debugger, re-compile the fixed function with one keystroke (instant feedback), go back to the debugger, choose a stack frame to resume execution from, see the execution pass. You didn't re-run everything from zero. SBCL has pretty good type inference at a keytstroke (not complete, but useful, for a Haskell on top of CL see Coalton), it's fast, different implementations, stability…
- tester756 3y ago
  > A good programmer can be good in any language. But will good programmer be equally productive in all languages? What if good programmer + good lang/ecosystem = 1.25x productivity of good programmer + worse language/ecosystem?
deleted 3y ago
[deleted]

bitwize 3y ago

Google's main line of business back in the day involved crawling and indexing as much of the entire web as possible. When you're operating at that kind of scale, back in the 2000s-early 2010s your choices were C++, and pretty much nothing else. Garbage-collected languages introduced too much overhead. Keeping the number of languages small, and keeping them purpose-focused (C++ for the heavy stuff, Java/Python for web backends, JavaScript for UIs) helped unify coding standards and conventions within and across teams, reining in the chaos that would have ensued had Google allowed developers or teams to choose languages willy-nilly. These sorts of language restrictions are not a knock against the skill of Google engineers. A good programmer can be good in any language. Even C++. Even Java. Think of the midwit meme, with the simpleton at the left going "just write everything in C++ or Java", the midwit in the middle going "NOOOOOO! Lambda calculus/monads/Hindley-Milner type systems!" and the genius/Jedi monk at the right going "just write everything in C++ or Java". The appeal of Lisp when writing production code is to lazy, mediocre programmers who think Lisp's sexy features will extend the reach of what they can create. Which is true, to a certain extent, but a) not as much as they may think; and b) when you consider that Lisp programs are bloated and slow compared to the corresponding C++ programs, the juice just isn't worth the squeeze. Lisp peaked ~60 years ago. There are very sound technical reasons why it is obscure today.

MaxBarraclough 3y ago
> A good programmer can be good in any language Kinda. Language-specific expertise should not be downplayed. If you've spent a decade honing your craft writing C and assembly for exotic embedded platforms, you'll be a valuable asset for certain projects, but your experience won't translate to Scala or Haskell.
- lispm 3y ago
  Part of your expertise is not the language, but the application to embedded platforms.
  - MaxBarraclough 3y ago
    Of course, but the point stands. Consider an expert in C programming for embedded platforms, and an expert in Ada (or Forth) programming for embedded platforms. The surrounding expertise is similar, but the language-specific expertise shouldn't be dismissed.
- bitwize 3y ago
  I think I meant more like "every language can have good programmers writing top quality code in it, even (especially) the blubs", not that a given good programmer will be able to immediately translate their expertise to a vastly different language or environment.
- fire_lake 3y ago
  > A good programmer can be good in any language Well, I’ll rewrite it in Brainfuck then.
cess11 3y ago
SBCL generates quite performant code. A distinguishing characteristic of languages like Lisp or Elixir is the metaprogramming. C++ and Java have nothing like their macro systems, and when an application grows and turns complex it's a very nice tool to keep developer facing code neat and readable. Usually it also keeps it more robust under change, there are fewer lines where typos or logic bugs can creep in when you write less boilerplate and use well designed code generation instead.
- bitwize 3y ago
  > SBCL generates quite performant code. Then why are virtually all browser engines, high-performance games, and video codecs written in C++? Why is every massive-scale web application written in C++? The only one that comes close that's written in Lisp is QPX, and even then they had to write a lot of C++ because Lisp's I/O facilities just weren't up to the task of moving the huge amounts of data they had to move. > C++ and Java have nothing like their macro systems C++ has template metaprogramming, which covers like 90% of the cases where you'd actually need Lisp macros, and outputs code that's statically typechecked with deterministic memory and runtime constraints.
  - cess11 3y ago
    Whatsapp is written in C++? When did they do the rewrite? You can have compile time type checking in Common Lisp if you want.
  - nequo 3y ago
    > Why is every massive-scale web application written in C++? Sibling mentioned WhatsApp which was Erlang. Facebook is PHP. Pre-Musk Twitter was written in Scala.
    - p_l 3y ago
      Twitter before Scala was done in Ruby on Rails, even.
  - p_l 3y ago
reikonomusha 3y ago
I think this is the perfect opinion to have for a middle manager at a large FAANG with seemingly infinite developer supply and little existential incentive to innovate. In practice, C++ and Python codebases have insane amounts of churn. They're constantly moving targets and require a lot of overhead to keep in shape, from just about every perspective: performance, security, maintainability, implementation compatibility, etc. It's tolerated though because it's standard practice, and we developers get a paycheck anyway. Languages like OCaml, Common Lisp, Haskell, and other niche but obviously practical languages continue to be indispensable to certain cohorts of companies and developers. While I do agree that Lisp specifically peaked in popularity decades ago, it still exists in the commercial domain with resounding staying power, even in environments where it could in theory be replaced by C++ or Python. It's also abundantly clear there's a hunger for new (or at least replacement) languages for the stalwarts. Rust, Julia, Mojo, Swift, and OCaml are a few such languages that get attention in their commercial investment and development, often with the specific purpose of replacing Python or C++. As a personal anecdote, I find professional Common Lisp programmers generally to be quite sensitive to matters of bloat. Some programmers go as far to chisel away needless cons cells (or allocation in general), and constantly be in touch with the compiled assembly—something frequently ignored by professional C++ programmers of comparable experience. I would love to hear the "very sound technical reasons" explaining Common Lisp's obscurity. Given the vast and diverse biome of programming languages in use today, including and especially in professional settings, I'm quite interested in understanding what technical reasons uniquely relegate Lisp to obscurity.
- perrygeo 3y ago
  My take (not OP) is that it's not so much the technical features of Lisp itself, but the fact that other languages evolved competing features. Over the years, they have slowly chipped away at Lisp's advantages. 50 years ago, Lisp was uniquely powerful with no rival. Today, Lisp is yet-another powerful language to choose from.
  - vindarel 3y ago
    I disagree: Common Lisp has many remaining powerful features AND a large set of them, when a language maybe caught up with one. The interactive debugger is unmatched, image-based development nearly doesn't exist elsewhere, the condition system… Example: fix a bug without quitting the debugger, re-compile the fixed function with one keystroke (instant feedback), go back to the debugger, choose a stack frame to resume execution from, see the execution pass. You didn't re-run everything from zero. SBCL has pretty good type inference at a keytstroke (not complete, but useful, for a Haskell on top of CL see Coalton), it's fast, different implementations, stability…
tester756 3y ago
> A good programmer can be good in any language. But will good programmer be equally productive in all languages? What if good programmer + good lang/ecosystem = 1.25x productivity of good programmer + worse language/ecosystem?

deleted 3y ago

[deleted]