Live data from Hacker News

Kina Knowledge, using Common Lisp extensively in their document processing stack

lisp-journey.gitlab.io

31–40 of 62 posts

Re: Kina Knowledge, using Common Lisp extensively in their document processing stack

#31

Earlier quoted context omitted.

> It was the norm for a single programmer to be doing the work that would normally be a team (sometimes multiple teams). One thing that surprised me when I entered the professional world was just how much this is seen as a downside . At almost every level, companies will choose technologies and techniques that allow them to hire more headcount, even if that results in a worse end product. Many startups value the appe…

Bus factor. What happens if the knowledgeable lead developer gets into an accident? What happens if they retire? More realistically, what happens when they burn out because it's so hard to hire other team members and so they can never really take a vacation and have to take their pager everywhere with them? That's why businesses optimize for headcount.

I have yet to encounter positive solutions to those questions, as usually increasing headcount does not relieve pressure on team members - it's used to enable quicker replacement by yet-another-junior-to-burned-at-the-altar who will leave after gaining experience and burning out.

The classic "we have niche languages" solution to that is to enable on-the-job learning of those, and not just doing simple fact checking on whether someone honestly claimed to have learnt Popular Language X as claimed on their CV.

Re: Kina Knowledge, using Common Lisp extensively in their document processing stack

#32

Earlier quoted context omitted.

I can’t imagine the choice of language being strongly correlated with programmer skill (it would be elitist to think so, and everybody feels best in the language they spend the most time in). I think C) Lisp is well suited to certain applications, from what I can see, web development or niche areas where exploratory programming is required. The downside of Lisp is lack of good GUI (CAPI is the best they can offer, bu…

One of the main developers of a Lisp compiler is employed by Google to work on exactly that.

exactly… a new GUI lib, is this what you mean? (there is also a group working on Qt5 bindings, they say to have a working prototype and they're ironing things out since some time)

Re: Kina Knowledge, using Common Lisp extensively in their document processing stack

#33
post #28

Earlier quoted context omitted.

I can’t imagine the choice of language being strongly correlated with programmer skill (it would be elitist to think so, and everybody feels best in the language they spend the most time in). I think C) Lisp is well suited to certain applications, from what I can see, web development or niche areas where exploratory programming is required. The downside of Lisp is lack of good GUI (CAPI is the best they can offer, bu…

The choice of language is anecdotally strongly correlated with programmer skill, but the best evidence I've seen was not about "Programmers using language X are better than language Y", but about availability of programmers. Counterintuitive, it was the "elitist" lower numbers involved in some languages (not just Lisp) that were found to be advantageous by some companies in hiring. Essentially, it selected out people…

Exactly. The average JavaScript programmer is much worse than the average Lisp programmer not because of any inherent features of either language, but because JavaScript is the first thing beginners learn in bootcamps. It's the same problem PHP used to have.

Re: Kina Knowledge, using Common Lisp extensively in their document processing stack

#34
post #18

Earlier quoted context omitted.

> It was the norm for a single programmer to be doing the work that would normally be a team (sometimes multiple teams). Be careful with what you conclude from this observation. Is it that A) Lispers are generally 10x Programmers, or that B) Lisps are generally poor languages for team environments?

I can’t imagine the choice of language being strongly correlated with programmer skill (it would be elitist to think so, and everybody feels best in the language they spend the most time in). I think C) Lisp is well suited to certain applications, from what I can see, web development or niche areas where exploratory programming is required. The downside of Lisp is lack of good GUI (CAPI is the best they can offer, bu…

> but I shouldn’t advertise this too much - its a secret weapon!

But do you use this weapon?

Re: Kina Knowledge, using Common Lisp extensively in their document processing stack

#35

Earlier quoted context omitted.

> It was the norm for a single programmer to be doing the work that would normally be a team (sometimes multiple teams). One thing that surprised me when I entered the professional world was just how much this is seen as a downside . At almost every level, companies will choose technologies and techniques that allow them to hire more headcount, even if that results in a worse end product. Many startups value the appe…

Bus factor. What happens if the knowledgeable lead developer gets into an accident? What happens if they retire? More realistically, what happens when they burn out because it's so hard to hire other team members and so they can never really take a vacation and have to take their pager everywhere with them? That's why businesses optimize for headcount.

There's probably a link to monolith and distributed systems here. You gain way more resiliance when you get more people in your team, but what was once a thought firing in the brain of someone is now two people talking, which is order of magnitude slower. But on the flip side, you can probably handle more things in general this way.

Re: Kina Knowledge, using Common Lisp extensively in their document processing stack

#36
post #18
post #16

Earlier quoted context omitted.

> The article also mentioned they have 3 programmers One of the problems we had with promoting commercial use of Scheme and then Racket was that -- although some companies were using it to great success -- there weren't any job postings for it. It was the norm for a single programmer to be doing the work that would normally be a team (sometimes multiple teams). And the knowledge of that success wouldn't be well-known…

> It was the norm for a single programmer to be doing the work that would normally be a team (sometimes multiple teams). Be careful with what you conclude from this observation. Is it that A) Lispers are generally 10x Programmers, or that B) Lisps are generally poor languages for team environments?

Lisp allows you to build compilers for your own languages. Compilers are a force-multiplier, but then you're the only one that knows your language.

Re: Kina Knowledge, using Common Lisp extensively in their document processing stack

#37
post #28

Earlier quoted context omitted.

I can’t imagine the choice of language being strongly correlated with programmer skill (it would be elitist to think so, and everybody feels best in the language they spend the most time in). I think C) Lisp is well suited to certain applications, from what I can see, web development or niche areas where exploratory programming is required. The downside of Lisp is lack of good GUI (CAPI is the best they can offer, bu…

The choice of language is anecdotally strongly correlated with programmer skill, but the best evidence I've seen was not about "Programmers using language X are better than language Y", but about availability of programmers. Counterintuitive, it was the "elitist" lower numbers involved in some languages (not just Lisp) that were found to be advantageous by some companies in hiring. Essentially, it selected out people…

I think that's because usually with "elitist" programming languages you can freely play with ideas, way more than with other languages. I remember reading in "The passionate programmer" that they increase their signal to noise ratio a lot when trying to recruit Java developers by looking for Smalltalk developers.

Re: Kina Knowledge, using Common Lisp extensively in their document processing stack

#38
post #28

Earlier quoted context omitted.

I can’t imagine the choice of language being strongly correlated with programmer skill (it would be elitist to think so, and everybody feels best in the language they spend the most time in). I think C) Lisp is well suited to certain applications, from what I can see, web development or niche areas where exploratory programming is required. The downside of Lisp is lack of good GUI (CAPI is the best they can offer, bu…

The choice of language is anecdotally strongly correlated with programmer skill, but the best evidence I've seen was not about "Programmers using language X are better than language Y", but about availability of programmers. Counterintuitive, it was the "elitist" lower numbers involved in some languages (not just Lisp) that were found to be advantageous by some companies in hiring. Essentially, it selected out people…

Common Lisp certainly gives you the tools to make an unmaintainable rat's nest out of your application, but it also gives you the tools not to. I expect there's survivorship bias here.

More generally what you're referring to as elitism is really just the result of a simple theorem. As the size of the set of Xlang programmers approaches the size of the set of all programmers, the average competence of an Xlang programmer approaches the average competence of all programmers. The asymmetry is that, as far as I'm aware, there aren't really any significant languages that attract small communities of abnormally incompetent programmers. On the other hand, there are languages, like Haskell, the MLs, and some Lisps, that do attract relatively small communities of abnormally competent programmers.

None of this is to say that someone that only writes JavaScript can't be an exceptionally competent programmer. We're talking about group averages here.

Re: Kina Knowledge, using Common Lisp extensively in their document processing stack

#39
post #18

Earlier quoted context omitted.

> It was the norm for a single programmer to be doing the work that would normally be a team (sometimes multiple teams). Be careful with what you conclude from this observation. Is it that A) Lispers are generally 10x Programmers, or that B) Lisps are generally poor languages for team environments?

I can’t imagine the choice of language being strongly correlated with programmer skill (it would be elitist to think so, and everybody feels best in the language they spend the most time in). I think C) Lisp is well suited to certain applications, from what I can see, web development or niche areas where exploratory programming is required. The downside of Lisp is lack of good GUI (CAPI is the best they can offer, bu…

One of the things I like about Racket is that it has a cross platform GUI built on GTK in the standard library[1]. It also has a GUI builder app (though I’ve never used it so can’t say how good it is)[2]

1. https://docs.racket-lang.org/gui/

2. https://github.com/Metaxal/MrEd-Designer

Re: Kina Knowledge, using Common Lisp extensively in their document processing stack

#40
post #38
post #28

Earlier quoted context omitted.

The choice of language is anecdotally strongly correlated with programmer skill, but the best evidence I've seen was not about "Programmers using language X are better than language Y", but about availability of programmers. Counterintuitive, it was the "elitist" lower numbers involved in some languages (not just Lisp) that were found to be advantageous by some companies in hiring. Essentially, it selected out people…

Common Lisp certainly gives you the tools to make an unmaintainable rat's nest out of your application, but it also gives you the tools not to. I expect there's survivorship bias here. More generally what you're referring to as elitism is really just the result of a simple theorem. As the size of the set of Xlang programmers approaches the size of the set of all programmers, the average competence of an Xlang program…

Well, that's one way of looking at it, the one I've been thinking of is that the distribution of competence is similar in all languages, but with niche ones it becomes easier to filter because good applicants do not disappear under deluge of bad ones.

There's also survivorship bias in sticking long enough with programming to actually look for jobs in niche languages or accept that you will be taught on the job, something that I've seen only with either experienced or more open-minded/educated people

Post reply on HN