3 ms·

Your main reply to "not invented here" is "okay, invent it here and maintain it here then, buddy". One of the key skills of a a senior dev is to be able to jud

Your main reply to "not invented here" is "okay, invent it here and maintain it here then, buddy". One of the key skills of a a senior dev is to be able to judge the tradeoff between rolling your own and borrowing someone else's. In your life as a dev you'll be making this choice all the time. The pros and cons are generic: time spent, potential bugs, security, free upgrades, specific vs general solutions, external reliance, and so on. But you will exercise this judgement constantly. Also not being a LISP guy, is it really so common to roll your own everything? Would you write your own JSON parser, is it that easy in LISP?

ironmagma 2y ago
The main reply was to use more things off the shelf, or at least be aware there is a business cost of not doing so. Ironically this blog post isn’t even targeted at developers but more management types, but it wouldn’t be life without being spectacularly wrong on HN and raked over the coals on it. In short though I agree it’s not like you can just use off the shelf for everything or that that is even a good idea to try as that has its own set of problems.
danielheath 2y ago
> Also not being a LISP guy, is it really so common to roll your own everything? Would you write your own JSON parser, is it that easy in LISP? As someone who has dabbled in lisp: IME, everything is easier - enough so that I more-often _consider_ inventing something that solves my subset of the problem. I suspect this contributes to the poor library availability situation (I understand that's improved markedly in recent years, but still).
jhbadger 2y ago
It's still somewhat common, but over the past couple of decades we've created package managers like QuickLisp that allow calling external dependencies in Common Lisp as easy as it is in Python (and even systems to allow us to interact with Python to get access to its ecosystem), plus a version of Common Lisp (Armed Bear Common Lisp) that runs on the JVM to get access to that ecosystem (not to mention the Lisp-adjacent language Clojure).
- ReleaseCandidat 2y ago
  Don't forget about Clasp, which is meant to be able to use C++ libraries. The latest video I've found about it, and Kris' interviews are usually great: https://www.youtube.com/watch?v=fytGL8vzGeQ https://www.youtube.com/watch?v=fytGL8vzGeQ
ReleaseCandidat 2y ago
> Would you write your own JSON parser, is it that easy in LISP? No, that's more of a Haskell thing to do (you start with your own parser combinator, of course). Common lispers write their own testing framework - I guess that's Peter Seibel's fault ;) https://sabracrolleton.github.io/testing-framework https://sabracrolleton.github.io/testing-framework https://gigamonkeys.com/book/practical-building-a-unit-test-framework https://gigamonkeys.com/book/practical-building-a-unit-test-... https://gigamonkeys.com/book/ https://gigamonkeys.com/book/
rlonstein 2y ago
> Would you write your own JSON parser, is it that easy in LISP? I only dally with Lisp(s) but probably not, I'd reach for a library in quicklisp. However, in Janet (https://janet-lang.org/ https://janet-lang.org/) there's a PEG parser and I wrote a JSON parser for fun in 134 lines that passes most of the test suite by Nicolas Seriot. So I'd say it's reasonably easy for a better-skilled programmer than I am.
kagevf 2y ago
> Would you write your own JSON parser, is it that easy in LISP? Well, there are a lot of them. Here's a link to a guide someone wrote to compare a bunch of them: https://sabracrolleton.github.io/json-review.html https://sabracrolleton.github.io/json-review.html
marcosdumay 2y ago
Lisp people are quick to rewrite basic language semantics. As somebody already said, rewriting parsers is more of a Haskell thing to do. That said, Lisp developers learn to fight their instinct and not redefine the language all the time, just as Haskell developers learn to fight their instinct and not make complex types all the time, and C++ developers learn to fight their instinct and not use STL all the time. But those take some experience.

ironmagma 2y ago

The main reply was to use more things off the shelf, or at least be aware there is a business cost of not doing so. Ironically this blog post isn’t even targeted at developers but more management types, but it wouldn’t be life without being spectacularly wrong on HN and raked over the coals on it. In short though I agree it’s not like you can just use off the shelf for everything or that that is even a good idea to try as that has its own set of problems.

danielheath 2y ago

> Also not being a LISP guy, is it really so common to roll your own everything? Would you write your own JSON parser, is it that easy in LISP? As someone who has dabbled in lisp: IME, everything is easier - enough so that I more-often _consider_ inventing something that solves my subset of the problem. I suspect this contributes to the poor library availability situation (I understand that's improved markedly in recent years, but still).

jhbadger 2y ago

It's still somewhat common, but over the past couple of decades we've created package managers like QuickLisp that allow calling external dependencies in Common Lisp as easy as it is in Python (and even systems to allow us to interact with Python to get access to its ecosystem), plus a version of Common Lisp (Armed Bear Common Lisp) that runs on the JVM to get access to that ecosystem (not to mention the Lisp-adjacent language Clojure).

ReleaseCandidat 2y ago
Don't forget about Clasp, which is meant to be able to use C++ libraries. The latest video I've found about it, and Kris' interviews are usually great: https://www.youtube.com/watch?v=fytGL8vzGeQ https://www.youtube.com/watch?v=fytGL8vzGeQ

ReleaseCandidat 2y ago

> Would you write your own JSON parser, is it that easy in LISP? No, that's more of a Haskell thing to do (you start with your own parser combinator, of course). Common lispers write their own testing framework - I guess that's Peter Seibel's fault ;) https://sabracrolleton.github.io/testing-framework https://sabracrolleton.github.io/testing-framework https://gigamonkeys.com/book/practical-building-a-unit-test-framework https://gigamonkeys.com/book/practical-building-a-unit-test-... https://gigamonkeys.com/book/ https://gigamonkeys.com/book/

rlonstein 2y ago

> Would you write your own JSON parser, is it that easy in LISP? I only dally with Lisp(s) but probably not, I'd reach for a library in quicklisp. However, in Janet (https://janet-lang.org/ https://janet-lang.org/) there's a PEG parser and I wrote a JSON parser for fun in 134 lines that passes most of the test suite by Nicolas Seriot. So I'd say it's reasonably easy for a better-skilled programmer than I am.

kagevf 2y ago

> Would you write your own JSON parser, is it that easy in LISP? Well, there are a lot of them. Here's a link to a guide someone wrote to compare a bunch of them: https://sabracrolleton.github.io/json-review.html https://sabracrolleton.github.io/json-review.html

marcosdumay 2y ago

Lisp people are quick to rewrite basic language semantics. As somebody already said, rewriting parsers is more of a Haskell thing to do. That said, Lisp developers learn to fight their instinct and not redefine the language all the time, just as Haskell developers learn to fight their instinct and not make complex types all the time, and C++ developers learn to fight their instinct and not use STL all the time. But those take some experience.