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

41–50 of 62 posts

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

#41

Post by galaxyLogic »

aidenn0 wrote: post #13
dang wrote: post #6

Earlier quoted context omitted.

Have they said whether it's a complete CL implementation or just a subset? I have the impression that it gets asymptotically more difficult as you approach the finish line.

Assuming you aren't just talking about how any project becomes harder to fix bugs in once you've fixed the easy bugs, it only gets more difficult as your approach the finish line if you don't plan on making a CL implementation from the start. It's really easy to make something that kind-of looks like CL by use of clever smoke and mirrors, and many "Lisp in X" projects do so. See e.g. parenscript's LOOP implementation…

When you say "Implementing CLOS is a massive undertaking" do you mean implementing CLOS in some other language than Lisp?

Shouldn't it be possible to implement most of CLOS in CLOS itself and thus reuse already existing CLOS-code?

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

#42

Post by aidenn0 »

galaxyLogic wrote: post #41
aidenn0 wrote: post #13

Earlier quoted context omitted.

Assuming you aren't just talking about how any project becomes harder to fix bugs in once you've fixed the easy bugs, it only gets more difficult as your approach the finish line if you don't plan on making a CL implementation from the start. It's really easy to make something that kind-of looks like CL by use of clever smoke and mirrors, and many "Lisp in X" projects do so. See e.g. parenscript's LOOP implementation…

When you say "Implementing CLOS is a massive undertaking" do you mean implementing CLOS in some other language than Lisp? Shouldn't it be possible to implement most of CLOS in CLOS itself and thus reuse already existing CLOS-code?

I meant implementing CLOS in any language is a large undertaking, but then pointed out two portable implementations in CL one could use, to save that work.

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

#43

Post by mark_l_watson »

zeIMOr5vRXhVpO wrote: post #26

> 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.…

Give SBCL another try for building compiled applications. If you compile SBCL from source, enable compression of standalone compiled apps.

I own a license for LispWorks Pro, which does a very good job building applications, but SBCL is also good for delivering apps.

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

#44

Post by agumonkey »

neilv wrote: post #16
Abhinav2000 wrote: post #2

This part is really interesting: > It is fast - our spatial classifier takes only milliseconds to come to a conclusion about a page (there is additional time prior to this step due to the OpenCV processing - but not too much) and identify it and doesn’t require expensive hardware. Most of our instances run on ARM-64, which at least at AWS, is 30% or so cheaper than x86-64. The s-expression structures align to documen…

> 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).

I felt this so very often. There are economical paradoxes and sociological issues at play. People want to be impressed and a big corp makes it look like hard while 3 lispers does not have the glow and even at lower prices you may fail to sell good work.

A lot of this world work this way, if everybody worked smart and efficiently there would be a lot less jobs.

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

#45

Post by sigg3 »

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…

The interview sort of answers this:

> Because we operate a lot in Latin America, I trained non-lisper engineers who speak Spanish on how to program Lisp

So they grew their lisp heads from raw human. That's not an overhead most companies would readily accept.

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

#46

Post by math-dev »

p_l wrote: post #27
math-dev wrote: post #24

Earlier quoted context omitted.

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 o…

Thanks!!

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

#47

Post by math-dev »

Decabytes wrote: post #39
math-dev wrote: post #23

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 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

I’ve heard that. How do you find racket for speed and also interactive development?

I don’t mind a bit of scheme / racket, so would be curious to jump in.

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

#48

Post by math-dev »

ranit wrote: post #34
math-dev wrote: post #23

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…

> but I shouldn’t advertise this too much - its a secret weapon! But do you use this weapon?

Yes, I am thinking of starting a part time web company based on it. But very early days so I shouldn’t be quoted or assumed to be anywhere successful as my preceding sentence may imply.

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

#49

Post by inopinatus »

Karrot_Kream wrote: post #30
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…

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.

Incompetent managers certainly believe they're hedging for bus factor by increasing headcount.

In practice, it doesn't work. For any given product there's still always a small/solo core team.

Don't optimise your business for mediocrity.

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

#50

Post by brabel »

zeIMOr5vRXhVpO wrote: post #26

> 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.…

Doesn't `(save-lisp-and-die :executable t)` [1] create static binaries?

I had a look at one of my SBCL-made binaries on MacOS, it shows this:

    ▶ otool -L  lisp-enc 
    lisp-enc:
 /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1292.100.5)
 /usr/lib/libz.1.dylib (compatibility version 1.0.0, current version 1.2.11)
EDIT: GraalVM takes several minutes to generate binaries, and the binary may not behave the same as the JVM-based runtime, so I wouldn't recommend using that.

[1] http://www.sbcl.org/manual/#Function-sb_002dext-save_002dlis...

Post reply on HN