Antibabelic

To be fair, the parent post was clearly talking about Slavic languages, not "all the languages USSR forced cyrillic alphabet on", which were not Slavic and which required significant modifications to the alphabet.

"Slav" deriving from the Slavic term for "word" is something of a false etymology that was invented in the 19th century. It is implausible on philological grounds: you'd expect a different vowel in this word if this were the case, and the suffix *-ninъ is only otherwise used in terms derived from place names.

It is more likely[0] that the term derives from some toponym. This is in line with how tribal names tend to work in Europe and is not problematic in terms of historical linguistics, however it gives less fuel to romantic nationalism and armchair speculations about national "identities" or "mindsets".

-----

[0] https://en.wiktionary.org/wiki/Reconstruction:Proto-Slavic/s...

This is a novel claim to me. I don't think Glagolitic looks particularly like cursive Greek, and I haven't seen this idea in scholarship. What is your source for it?

Oddly, the article doesn't mention the most interesting part. Most scholars believe that Cyril and Methodius did not design Cyrillic, but instead something called Glagolitic.[0]

Glagolitic very quickly got pushed out by what were essentially Greek letters. If you look at Bulgarian and Byzantine manuscripts from the time, they are almost impossible to tell apart, unless you know the languages.

The reason for that is pretty obvious if you look at the Glagolitic letters themselves: they are horrible UX. You need a lot more strokes than for something like Greek or Latin to record the same information. Because Glagolitic was contrived and not polished with use over the centuries, there was very little reason to use it over Greek.

-----

[0] https://en.wikipedia.org/wiki/Glagolitic_script

No hackers on Hacker News? Oh my oh my

Land of Lisp is actually a very, very bad introduction.

Isn't solving problems, instead of blindly implementing a high-level description of the solution, your job as a developer?

What kind of projects are people working on, where understanding what features the management wants is the only difficult part and the rest can just be "typed out" (or, today, offloaded to an LLM)? If that's what you do, then I'm not surprised so many people on HN think LLMs can replace them.

This book is a great introduction to Common Lisp and Lisp in general. Very no-nonsense. Happy to see it here!

Two days ago: https://news.ycombinator.com/item?id=47988776

> It used to be that writing your own editor, your own file manager, your own window manager, was a project of years.

This is... Not really true? Especially if you are writing just for yourself. These are week-long projects at most to get to a usable state, if you know what you're doing. This is why there are so many text editors and window managers in the first place.

> Well, I’ve been radicalized. I’ve learned enough performance-oriented programming to be dissatisfied with the common functional languages (Haskell, OCaml, Common Lisp/Clojure, Scheme) because each of these languages are predicated on the existence of garbage collection and heaps.

I would take another look at Common Lisp if I were the author. Manual memory management is very much an option where you need it.

I promise you, "the code that institutions had been keeping to themselves" is not nearly as special or good as you are implying here.

People getting to know each and working together to genocide another group of people that's slightly different from them does indeed have many precedents in history.

The problem with your idea is that you see "humans" as some kind of abstract unified whole. People care about their peers far more than they do about "humans" in the abstract. When you're a powerful venture capitalist, these peers are other venture capitalists for example. Some call this "class consciousness".

Some problems don't have solutions.

This is simply incorrect. Engineers can in fact be held responsible for negligence if insecure engineering results in damage from a terrorist attack that could've plausibly been prevented.

The data is in the linked paper. It's a direct quote from the abstract.

I don't think that's quite the point that example was intended to illustrate. The idea is not the you're looking for C0 bytes or any other kinds of bytes in particular, but rather that it's easier to fish out unique and interesting information in a sea of noise when you have color-coded bytes: like the fact that there's a conspicuous lonely C0 or some other value or series of values that stand out.

Incidents happen in the meat world too. Engineers follow established standards to prevent them to the best of their ability. If they don't, they are prosecuted. Nobody has ever suggested putting people in jail for Russia using magic to get access to your emails. However, in the real world, there is no magic. The other party "outmatches" you by exploiting typical flaws in software and hardware, or, far more often, in company employees. Software engineering needs to grow up, have real certification and standards bodies and start being rigorously regulated, unless you want to rely on blind hope that your "general" has been putting an "honest effort" and showing basic competence.

Software engineering is voodoo masquerading as science. Most of these "laws" are just things some guys said and people thought "sounds sensible". When will we have "laws" that have been extensively tested experimentally in controlled conditions, or "laws" that will have you in jail for violating them? Like "you WILL be held responsible for compromised user data"?

This is a contradiction. If most people objected to bad music, that would make popularity directly related to quality.

> There is only one formula for healthy and refreshing sleep: Go to sleep only when you are very tired. Not earlier. Not later. Wake up naturally without an alarm clock.

This is very easy to say when you're not suffering from insomnia and other sleep disorders.

Clojure is reasonably popular as far as programming languages go. It's not difficult to get a job as a Clojure developer, particularly in certain sectors (fintech and healthcare are the heaviest Clojure users). Of course C++, Java, C# and PHP dwarf both Clojure and Rust by several orders of magnitude.

"The TIOBE index measures how many Internet pages exist for a particular programming language."

For some reason I doubt this is in any way representative of the real world. Scratch, which is a teaching language for children, bigger than PHP? Which is smaller than Rust? Yeah, these are results you get when you look at the Internet, alright.

It's almost as if different tools exist for solving different problems. Clojure is "Lisp on the JVM". That's the core premise behind the language. Rust is a "systems programming language with a focus on type and memory safety". This is an apples-to-oranges comparison. They offer different benefits while providing different drawbacks in return. Their ecosystems are likewise very different, in each case more closely tailored to their particular niche.

The JVM is one of the major selling points of Clojure. You can "write once, run anywhere" and benefit from Java's massive ecosystem, all without having to use a Blub language. Modern JVM implementations are also incredibly fast, often comparable in performance to C++ and Go.

A programming language is not the compiler. A programming language is, in fact, not software.

> It was the last time that a Japanese company made a fundamentally Japanese move.

What do you mean by this?

There is no "lack of understanding" here. The people responsible for these interfaces understand consent perfectly well, they just don't care for it.