abathologist

The inevitable march of progress.

All the ones trying to do that, yes.

Generally interesting reflections here, yet I see the same kind of myopia and fatalism that is rampant in our (fashion) industry:

yet I have no doubts that this looping future is going to be our future despite the fact that I presently resent it

Why would anyone concluded this? LLMs are just one kind of application of MLs to software production. There is a vast solution space for automating parts of software production. The idea that slop loops are the inevitable future because they happen to be accelerating output at the moment just seems profoundly short-sighted and lacking in vision.

Would be interested in a comparison with https://sourcehut.org/ (which has a comparable minimal aesthetic, but also has the deep benefit of being FOSS.

Good point. We mustn't forget the magical money box: that's where the real value is delivered!

'Long', as in 1-3 years? (https://www.tomshardware.com/pc-components/gpus/datacenter-g...)

Oh really? A 195% cost to revenue ratio isn't bad at all? I'm not a biz expert, but I spent a few minutes looking this up (e.g., what are usual cost-to-revenue ratios for new lines of business), and this sounds like BS to me.

It's not weird if you consider the details and the many ways that the situations are very different. But also, people cared about that other kind of BS too, e.g., https://news.ycombinator.com/item?id=39438372 or https://www.currentaffairs.org/news/2017/10/undercover-at-th...

Rogue looks like this: https://upload.wikimedia.org/wikipedia/commons/0/0c/Rogue_Sc...

Brogue looks like this: https://syltefar.com/screenshot/?id=624

Dear Alan,

It is with great joy that I have accepted the invitation to write you a personal letter. Even in your scientific writings your presence as a person is very strong, which is unusual for a mathematician. The traces of your personal life and your dramas extend beyond the limits of your own personal circumstances to concern us all ...

...

Perhaps the greatest catastrophe of anti-scientific computationalism can be seen in the recent theory of "The End of Theories". In a series of widely quoted articles, informaticians or managers of very large databases explain that: "Correlation supersedes causation, and science can advance even without coherent models, unified theories". In short, networked computers, bringing to light very extended correlations in huge databases, make it possible to predict and act, without the need to "understand": scientific intelligibility is an uncertain luxury that is subjective and outdated, and theories are fallible proposals. Data, especially in large quantities – tera-terabytes, Big Data – is objective, is a new form of the absolute, is individually exact, expressed in digits. Thus, they argue, the larger that databases become, the more that statistical regularities, brought to light by computers, can govern us without the need to understand the meaning of the correlations, to interpret them, and without the need for theories about them, for interpretations.

Fortunately, mathematics allows us to demonstrate the absurdity of these claims: Cristian Calude and I have written an article about this. Precisely the immensity of data involved has allowed us to apply the theorems of Ramsey and Van der Waerden. These make it possible to show that, given any "regularity", or any correlation between sets of numbers, you can find a number p large enough, such that every set with at least p elements contains a regularity (or a correlation between numbers) with the same structure. Now, since this applies to every sufficiently large set (with at least p elements), this also applies when it is generated … by a random process. Indeed, we observe, almost all sets of fairly large numbers are algorithmically random (one can give a mathematical definition of them, in terms of incompressibility), i.e., the percentage of non-random tends to 0 as p goes to infinity. So, if you observe regularities in increasingly large databases, it is increasingly likely that the inserted data are due to chance, in other words are perfectly without meaning and do not allow prediction nor action.

...

The LLMs are training "us" now.

First we develop the machines, then we contort the entire social and psychic order to serve their rhythms and facilitate their operation.

I did a few days of AoC in 2020 in λProlog (as a non-expert in the language), using the Elpi implementation. It provides a decent source of relatively digestable toy examples: https://github.com/shonfeder/aoc-2020

(Caveat that I don't claim to be a λProlog or expert.)

All examples showcase the typing discipline that is novel relative to Prolog, and towards day 10, use of the lambda binders, hereditary harrop formulas, and higher order niceness shows up.

I find that if I have my rabbit's foot and lucky socks on, I win working code ~1.2x more often.

This will soon be happening with our parents' social security checks, our friend's cancer treatment plan, our international flights logistics, our ISPs routing configurations, ...

Fun times are coming.

Search should be a public service, open and transparent, funded by tax revenue, and maintained for the public good. It is too important a service these days to leave it up to profiteers (who have repeatedly demonstrated they are not responsible or responsive stewards of the public good).

For example "cites a different person as an author, who happened to have done all the substantive work on a related code base". ;)

This is great. If you think that the phenomena of human-like text generation evinces human-like intelligence, then this should be taken to evince that the systems likely have dementia. https://en.wikipedia.org/wiki/Montreal_Cognitive_Assessment

Right? Why would anyone muddy work with morality in this day and age? Morality is so 2010s.

I am excited too! It is probably too much to hope, but I nonetheless am hoping that magit gets a jj backend before I have enough motivation or need to learn a new tool to do the same old stuff :D

Same. I have not been able to find an explanation of anything jj supports that I don't have already with magit, but I am open to learning :)

I'd argue that you understand what a light switch does well enough to use it effectively for its purpose.

When me move from just making use of something to using something to make with, that is when we should have a deeper understanding I think.

Does that sound right?

the important distinction here is that I wouldn't call myself an electrician if my relationship to the subject matter doesn't extend beyond the desire to flip a switch.

Yeah, that seems right to me!

A key -- perhaps THE key -- remark here, IMO is the following:

I do want to make things, and many times I dont want to know something, but I want to use it

This confesses the desire to make, to use, and to make use of, without ANY substantive understanding.

Of course this seems attractive for some reasons, but it is a wrong, degenerative way to be in the world. Thinking and being belong together. Knowing and using are two dimensions of the same activity.

The way of these tools is a making without understanding, a using without learning, a way of being that is thoughtless.

There's nothing preventing us from thoughtful, rigorous, enriching use of generative ML, except that the systems we live and work in don't want us to be thoughtful and enriched and rigorous. They want us pliant and reactive and automated and sloppy.

We don't have to bend to their wants tho.

Careful, that way leads roboticization, according to me https://news.ycombinator.com/item?id=44010933 :|

Backward compat has nothing to do with the size of the stdlib, AFAIK. It seems you want to pick on a different part of the language ecosystem.

It's true this a matter of taste, but also worth noting that the OCaml compiler devs have made it very clear they are open to well-motivated extensions of the stdlib, and it has been growing at a decent clip in the last few years.

TypeScript certainly has a more complicated and flexible type systems in many respects, but it is not the same w/r/t safety. It is quite common to run across `any`s all over the place in TypeScript code, and there is no such thing in OCaml. TypeScript's systems is explicitly unsound (i.e., not fully type safe) by design: https://www.typescriptlang.org/docs/handbook/type-compatibil...

They already happily will. Gemini told me

Large Language Models represent a fundamentally degenerative technology because they systemically devalue the very processes that underpin human progress: original thought, rigorous inquiry, and shared trust. On an individual level, they encourage cognitive offloading, substituting the difficult work of critical thinking and creative synthesis with effortless, probabilistic text generation. This fosters an atrophy of intellectual skills, making society more dependent on automated systems and less capable of genuinely emancipated thought. This intellectual dependency, in turn, threatens long-term technological advancement by trapping us in a recursive loop of recycling and rephrasing existing knowledge, rather than fostering the groundbreaking, first-principles discoveries that drive true progress. Ultimately, this technology is dangerous for society because it erodes the foundation of a shared reality by enabling the mass production of sophisticated misinformation, corroding social trust, and concentrating immense power over information into the hands of a few unaccountable entities.

As someone who has worked professionally in both, programming in rust does not feel much like programming in OCaml. Working with traits in an imperative manual memory managed language is really different than working with proper modules in a mixed paradigm language with an awesome GC.

It's got about the same amount of type safety

What?

A different perspective is that JS has made practical application of PLT part of their secret sauce, and deepening into their PLT roots is thickening the sauce.

I love SML, and came to OCaml a bit begrudgingly initially just for a larger ecosystem. But, I think the object system gets a unjustly bad wrap. The OCaml object system is dope. It is rarely needed and not the best feature for most use cases, but when you want structurally-typed records, or need open recursion (or need to represent JS objects for the amazing `Js_of_ocaml`), they are a perfect fit.