stackghost

The web is on its last legs. Why bother publishing if nobody will read it? Nowadays I just write explorative/study notes in a notebook. I retain that better than typed writing anyways.

When it comes to writing software, I don't consider myself elite, but neither do I want to use a language designed by some mid-level engineer. Do you?

Compare that to, shall we say, more permissive (and more popular!) languages like python or js where there are untold terabytes of absolute dogshit code out there.

But I find Go annoying because the language isn't very expressive. It takes a lot of code to do fairly simple things, so codebases tend to balloon in size very quickly.

If only the library ecosystem in common lisp wasn't so barren.

I'd be very interested in reading more about this.

Licensed engineers are technically held accountable by their peers. The definition of a profession (versus just a job) is that professionals as a group are self-regulating. That is why e.g. doctors can be disciplined by their College, and lawyers can be disbarred by the legal society.

This is because Professional Engineering is actually a social process, not really a technical one. The work is technical, sure, but the reason we have Professional Engineers is because society realized long ago that letting any idiot build e.g. a bridge for public traffic is a bad idea.

Society, via legislation, grants professional licensing bodies special privileges in return for exerting control over the practising members of that profession.

The reason you don't see as many EEs (or aerospace) engineers with PEs is because the products that get produced in those specialties get certified in different ways. There's no bridge equivalent to the FCC, for example.

It would fix it for me, automatically, if I was willing to let it run amok in my codebase. But asking if the "vuln" was exploitable triggered the guardrails and a "we can't show you this content" error because I am not part of the cybersecurty Trusted Access bullshit.

I used the word "arguably" in the very first word of that sentence:

>Arguably the best is SBCL

The word arguable is a synonym for the word debatable.

That does not match my experience with lisp.

If you're building products without LLMs today you're going to get outcompeted by people who do, and can iterate faster. I have written a fair bit of lisp and when it isn't refusing to fix security bugs because openai are cowards, 5.6-Sol can do in hours what would take me days.

Perhaps the default choice is Common Lisp which itself is specified in an ANSI standard and has several competing implementations. Some are compiled, some are interpreted.

Arguably the best is SBCL, which has a mature compiler and garbage collection. If you lean on implementation-specific features you can produce extremely fast code that approaches the performance of C in some benchmarks, but idiomatic and portable lisp is slower in practice.

>Why should I use it instead of any other languages?

The killer feature used to be the REPL. You can write the application function by function, and test the functions, data structures, or classes you write in the REPL as you're actively building the app.

Nowadays with LLMs writing all the code, I honestly don't see much reason to reach for lisp. Agents don't require a REPL, and other languages have vastly superior library support.

Try to find a TLS library for Common Lisp that doesn't rely on openssl, for example. Last time I looked the most mature library was marked 'experimental'.

>Please don't complain about tangential annoyances—e.g. article or website formats, name collisions, or back-button breakage. They're too common to be interesting.

I can't think of any comment less interesting and more tangential these days than yet another screed about LLMs using em dashes or particular speech patterns. Seriously who fucking cares

All the ones I've encountered in the wild ran VxWorks

There isn't a third point on the line you found because the problem stipulates that the set of points is not collinear.

As soon as the set of points are defined to be non-collinear in Euclidean space, this property must be true, purely from the definition of the problem. To suggest otherwise would be to violate either the problem definition or the axioms of Euclidean geometry.

There's nothing novel here. I feel like I'm taking fucking crazy pills.

I don't see how this rephrasing changes anything. Of course there are two points a and b because again, the definition of the problem leads naturally, obviously, and definitionally to this result.

... of course there's no single line that all the points lie on. They've been defined to be non-collinear.

Edit: can't reply because of HN's stupid rate-limit mechanism, but to this:

>So the theorem proves that no matter which way you arrange any finite set of points, except for all on the same line, then you can always find a line with exactly two points.

Of course you can. It's absolutely implied by the problem definition. My 9 year old could do this, given a ruler and a pencil, with 100% success rate. I absolutely do not believe this is a novel "theorem"

Isn't this a tautology?

The problem definition states that the set of points is in Euclidean space, which from Euclid's Axioms means we can draw a line between any two points. The set of points is defined to be not collinear, thus we cannot draw a line passing through more than two of them. This is just simple logic.

Hard disagree. If you're in a small-to-medium size codebase every day, then sure, but I have a couple personal projects that are complex enough that even though I wrote them before LLMs, I still need to go back and discover/fumble around before I can confidently make changes.

I have definitely looked at my own hand-written code and had a "wtf does this even do" moment.

Plenty of shitty spaghetti code has been written by human hands.

LLMs can write good, maintainable code too, but they need to be kept on a shorter leash with focused goals.