Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

lisp-journey.gitlab.io

Post reply on HN
Print view View original

21–30 of 62 posts

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

#21

Post by hcarvalhoalves »

csande17 wrote: post #19
neilv wrote: 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). 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…

Hiring thousands of developers is a success metric now.

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

#22

Post by Jtsummers »

hcarvalhoalves wrote: post #21
csande17 wrote: post #19

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…

Hiring thousands of developers is a success metric now.

Management is still one of the fastest ways to a high paying job. Managers get rewarded (implicitly or explicitly) for being in charge of more people, either with better pay in the same position or by appearing to be more competitive when going for promotions. This creates a perverse incentive where someone can make decisions which promote a higher headcount at the cost of actual capability or efficiency.

It's often not even deliberate. No one sits down and says, "This language or tool kit requires a higher headcount, so I'll select it for my project". But they aren't motivated to find a more efficient approach that results in them being put in charge of a smaller team (because this would cost them and not reward them).

EDIT: Some grammar things.

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

#23

Post by math-dev »

pphysch wrote: post #18
neilv wrote: 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?

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, but this is not as good as other language implementations for various reasons) and not having the backing of Apple, Microsoft, Google or Facebook, and thus lacking in APIs.

But given its dynamic development (its a real joy), its very well suited to exploratory programming.

Web Development is an undiscovered gem for Lisp. It doesn’t face the issue of GUI / lack of APIs, since you can work directly in HTML / JS / CSS for the front end, and its a serious solution that covers servers, databases and all aspects of the stack very well. Its simply amazing (this is coming from a web developer), but I shouldn’t advertise this too much - its a secret weapon!

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

#24

Post by math-dev »

dataangel wrote: post #20
the_optimist wrote: post #12

Earlier quoted context omitted.

What's a quota?

I think he means they one of the biggest consumers of cluster resources. Each group within google probably has a quota for how many resources they are allowed to use. It's unclear here if their consumption is so huge because they are successful or inefficient though...

Does anybody know what they actually do? I see them mentioned all the time but I don’t get it. Is it just flight information or do they do pricing analysis and other stuff

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

#25

Post by reikonomusha »

math-dev wrote: post #23
pphysch wrote: 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 main developers of a Lisp compiler is employed by Google to work on exactly that.

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

#26

Post by zeIMOr5vRXhVpO »

> I liked the idea of distributing binary applications as well, which we needed to do in some instances, and building a binary runtime of the software was a great draw, too.

fwiw this is possible to with clojure using graalvm. Only mentioning this because of the clojure comparison in the earlier paragraph. While I do lament the JVM I haven't found a straightforward way to build statically compiled binaries with sbcl. I would love to be proven wrong though! :D

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

#27

Post by p_l »

math-dev wrote: post #24
dataangel wrote: post #20

Earlier quoted context omitted.

I think he means they one of the biggest consumers of cluster resources. Each group within google probably has a quota for how many resources they are allowed to use. It's unclear here if their consumption is so huge because they are successful or inefficient though...

Does anybody know what they actually do? I see them mentioned all the time but I don’t get it. Is it just flight information or do they do pricing analysis and other stuff

QPX (ITA's, and now Google's) system is responsible for calculating and searching airfares, i.e. the complete "solution" for "I want to get from A to B with those constraints". It's what responds when you ask google flight for a route, essentially. This is quite computationally complex due to many dimensions involved in airfare calculations. This system is essentially implemented on top of SBCL with some small bits of C++ (responsible, IIRC, for handling memory-mapped airfare data files).

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

#28

Post by p_l »

math-dev wrote: post #23
pphysch wrote: 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…

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 with lower experience and those not willing to learn a new language. An example I was given was that choosing Common Lisp and combining it with globally remote hiring greatly increased the quality of incoming applicants - and that had they went with the popular option (Python in their case) they'd have to deal with deluge of fresh bootcamp grads of which many had unwarranted high opinion of themselves.

Both Kina Knowledge and ITA Software (and from what I heard but can't cite now, other companies as well), teaching people Common Lisp on the job apparently tends to work pretty well, and willingness to master a new language correlates much better with good skills. It does have the disadvantage of not being able to throw a new hire directly tickets to solve, but the timeframes I was given were essentially "it takes around a month for new hire to go from zero to productive lisp programmer".

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

#29

Post by cle »

hcarvalhoalves wrote: post #21
csande17 wrote: post #19

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…

Hiring thousands of developers is a success metric now.

It's also a way to hedge risks. If you've got a single programmer working on something, they're a single point of failure and they also have huge leverage (which can be good or bad depending on the person and circumstances).

Not that middle management bloat isn't a thing...it definitely is. But I don't think it's as black-and-white as it's made out here.

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

#30

Post by Karrot_Kream »

csande17 wrote: post #19
neilv wrote: 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). 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.
Post reply on HN