I sympathize, but if you're working for a company then somebody is either going to need to be able to read and understand your Lisp code, or the WASM it generates, in order to maintain it after you move on to some other company.

sph probably has a clause in there to own the code. A traveling salesman among a graph of corporate nodes. Their own tools, always honed; their own solutions, always at hand.

But owning the code doesnt mean removing the runtime after he "blessed" the company with his proprietary "help" and some poor underpaid sob now has to "only maintain" the work of the great master.

He'll code it in C or Java or Javascript and that'll be it thank you very much, so that we can maintain it forever.

Not sure what this subthread is worried about. I never said I was going antisocial and forcing Lisp upon my fellow coworkers.

I just said that, where I have complete control (i.e. on personal projects, or companies I bootstrap) I will choose Lisp because I wouldn't have to care for junior employees.

This forum is so preoccupied by only considering something that could be understood by a team of thousand average-skilled engineers, and only the easiest to understand languages matter, which is why all Lisp discussions devolves into mentioning how hard it is to adopt in large corporate teams.

The power of Lisp is inversely proportional to the headcount, and sometimes you're the only one working on a project, so you want max velocity and flexibility. Not everything has to be optimised for a FAANG development model.

Ah I misunderstood. You mentioned junior engineer and I interpreted the context as being in a company. But for personal projects, or any other ones with like-minded contributors, more power to you! I try to do all mine in Haskell fwiw, for similar reasons :).

That's a good point, the maintenance burden of vendor libs. It may not necessarily be closed source, but for other reasons--hard math, unfamiliar language, or domain depth--might as well be a proprietary blob.

However, re-reading sph's comment above and seeing their response below, this truth table may help fill in context for me (thinking aloud and all that):

  A: Running Lisp stuff for personal
     and/or own startup
  B: Embedding the libs as a B2B solution
  C: Maintenance overhead

  A  B  C   A & B & C
  T  T  T   SkyMarshal and xwolfi's comment
  T  T  F*  I agree there would be a cost
  T  F* T   sph using for own stuff or biz
  T  F* F   Same as above
  F* T  T   N/A
  F* T  F   N/A
  F* F  T   N/A
  F* F  F   N/A

The asterisk (*) above meaning we can abort there since it wouldn't make sense to proceed to the other values.

So then B is where things went one way or the other. And admittedly, I must have assumed B.

> How many date/time libraries have been written since the invention of UNIX?

Indeed. This service (especially the time zones) should be part of the standard operating system API.

What I mean is that I should be able to use TensorFlow, or a Ruby library or Qt6 from any other platform and language, without someone having to write bindings to it or porting it wholesale. We've been wasting thousands of man years just rewriting the same code everywhere, with the quality of implementation being dependent on how popular the language is. So you get the best libraries on Java, and smaller ecosystems never reach critical mass because there's no good libraries. This is unsustainable.

I really am hyped for WASM components.

Wasm is just java for people who weren't around for Java.

Unfortunately, making a new isa is the easy part. The hard part is defining the abi.

.net came closest. Wasm is focusing on the wrong problem.

The standard operating system API should provide abstractions for all general real-world objects the machine is expected to represent or interact with: dates, times, durations, recurrences, abstract time concepts like "the second Monday of every month except when it falls on a holiday", people, places, events, to-do lists...

These are things that businesses have to deal with every day. The fact that we don't have those things, standard, as a part of a programmer's toolkit is a great failure of language and OS designers.

https://web.archive.org/web/20180223094826/http://www.xent.c...

As a language designer and implementer, I have spent a lot of hours writing time&date code, and disagree that I'm to blame for them not being standard.

I've also released them with a Boost license, so anyone can use them for any purpose.

The JVM lets you program in whatever you want to and then use code written in whatever comfy language (Java, C/C++ via native interop, Kotlin, etc) or a Lisp dialect (Clojure). I frequently use Java and Clojure together in the same project to great satisfaction, but I know what you mean anyways. We need WASM to get around the web question. I just hope it can fulfill the promise you have set upon it.

We already had it 10 years ago with PNaCL but then politics happened.

I've been JVM languages sharing libraries, but is the WASM ABI going to be rich enough to support that?

We (sadly) rarely see languages that target binary (whether x86 or ARM or just LLVM) sharing libraries. Partly it's because the .so and .dll interfaces only support the C ABI, and the absence of a rich well-defined OOP abstraction.

But, yea, I'm not totally sure if a low level WASM ABI would lead to a rich ecosystem of multi-language libraries, unless the WASM ABI is at a high enough level that it defines higher-order functions, classes, etc.

WASM has a low level ABI, but that's the thing WASM components are trying to rectify. Components is a proposed spec that builds on top of WASM.

Imagine a .so library with a native concept of high level objects that can be understood and passed between libraries written in different languages.

I have been doing that in JVM and CLR ecosystems for about 20 years now, somehow it is a novelty in WebAssembly, latest trend is even to re-invent application servers.

I haven't been keeping up so maybe someone who has can comment but doesn't WebAssembly have a similar problematic relationship to tail calls and deep recursion as the JVM does?