Notices by Palaiologos (kspalaiologos@fedi.absturztau.be)
-
Embed this notice
Palaiologos (kspalaiologos@fedi.absturztau.be)'s status on Sunday, 15-Dec-2024 18:55:51 JST 
Palaiologos
@taylan Why does Japanese use weird glyphs to encode their language? Why can't they use the Latin alphabet and settle on writing everything with Romaji all the time to convenience me, a stranger?
Asian languages have some benefits: e.g. thanks to the fact that Cantonese (a language also encoded with an inscrutable unreadable alphabet) has single-syllable digits, native Cantonese speakers on average remember phone numbers better and have an expanded working memory.
https://www.sciencedirect.com/science/article/pii/S0749596X22000766
https://www.npr.org/sections/krulwich/2011/07/01/137527742/china-s-unnatural-math-advantage-their-words
Etc...
I will give this question benefit of doubt and assume that it's genuine: the reason is mnemotechniques (APL glyphs make sense for what they do and have clear patterns) and context confusion. E.g. to me, & is exclusively address-of or bit-and. If a language used it in some other context, I would be confused and I would never recover. Which is why if you settle on terse syntax custom operators are our only option.
Why not words? Out of convenience: scanning and parsing the word requires more intellectual effort to parse and register than pattern-matching a glyph and when used often enough, verbose names become a nuance. You can ask this question to e.g. Haskell designers, who thought that `foldl1` is a good function name - why not use the `fold_left` convention like OCaml does? Without closer inspection, it appears more readable.
And finally: APL was developed as a mathematical notation. Mathematics do not use words, but they could. Instead of F = ma, we could say that force is equal to the mass multiplied by acceleration - imagine how difficult would it be to derive Telegrapher's equations with such an inefficient thought model. -
Embed this notice
Palaiologos (kspalaiologos@fedi.absturztau.be)'s status on Sunday, 15-Dec-2024 04:37:00 JST
Palaiologos
How I see APL is as an inherent and obvious product of programming language evolution.
Once you start with Assembly and get good enough, you notice that you no longer think in terms of opcodes, GOTOs or registers; instead, you think of variables and high-level control structures (if this then that). translating mental pseudocode to assembly becomes tedious.
Then, we saw the advent of higher level languages like C: you no longer have to spend so much intellectual effort on translating ideas into code, as the compiler can do it better. Further, the gist of the idea can be understood better by most programmers by seeing more structured code than assembly.
After that, we realised that writing a hash map from scratch in every source file is also an inefficient use of programmer time, as humans find it easy to conceptualise basic data structures like a dictionary. Unfortunately, this is where most programmers nowadays plateau: when writing code, they think of for loops, hashmaps and if statements. The average programmer deludes themselves that they are not bottlenecked by their typing speed or their skill at translating abstract ideas into code: they see programming as the act of such translation without regard to the art of reasoning in abstraction.
The CS-savvy programmers discover functional programming. They learn about recursion, which greatly simplifies many structural operations. But at some point they notice that recursion as a concept is powerful and low level: difficult to debug, difficult to reason about, difficult to match patterns on, verbose. At this point, they discover recursion schemes and become efficient at juggling around maps, filters, scans and reduces. They make it easy to do basic strength reduction and optimisations, change existing behaviours and add components to data processing pipelines, on top of being rather easy to reason about to a skilled programmer. But many people don't ever get to this stage - see the amazement at "ngn scans".
And then the ultimate step of this evolution is noticing that most of these maps that hide recursion deep down are not necessary and if only data was arranged in arrays, the loops could be tucked away inside of even the most primitive operations. This is what makes APL relevant and so representative of human thought - it minimises the amount of intellectual effort that is required to turn abstract ideas into code. It lets programmers focus not on the bread and butter of computer science but further develop ideas and improve as scientists and problem solvers.
But - as I mentioned before, most people stop at the third stage: they can never efficiently reason about abstract ideas or very high level code, because they're not representative of their mental model which was shoehorned into ALGOL-style programming. They never solve problems abstractly - they think in terms of code, which has high degree of cognitive overload due to the need of mentally materialising all the ceremony and magic that's related to inherently verbose mainstream languages. And this is why they never feel bottlenecked by the speed at which they write stuff.
This is why APL simply doesn't work in a commercial, group setting. Readability in the common sense is a dial that you can twist between programmer convenience and efficiency and how digestible the code is to the average person. Unfortunately, you will be hiring average people and you will not meet two efficient programmers with the same mental model, so the idea of abstracting away reality doesn't work. You have to agree on the lowest common denominator in terms of abstraction levels that makes working comfortable for everyone: it's easier to adopt a (simplified) shared common mental ground than get everyone to agree on the local zen of code.
But maybe forcing people to agree on the "zen of code" would be a good thing: so-called readable code is meant to simplify onboarding and development of code because programmers don't need to spend a long time figuring out how the whole thing works. That may be a bad thing: programmers may delude themselves into thinking that appearing to work is the same as working, and hence introduce subtle bugs into the code base that they don't really understand, which the upfront familiarity would have de facto required. This is a common trend in programming right now. I don't agree with it, because every code base builds up their own non-standard set of primitives in utility classes that take a long time to grasp, while APL regardless of where you use it is mostly the same and idiomatic due to the fact that primitives actually do things.
Bottom line: Is becoming more efficient at programming and abstract reasoning through the use of better tooling a ever goal for programmers? There is no tangible benefit from being specifically faster at greenfield programming. I find it desirable because I am a young programmer and first and foremost a scientist, but I would imagine that my more senior colleagues don't have a reason to chase this - they work on established code bases that grew hairs and limbs over the years, just like every commercial/long-term project and don't ever have the drive to return to greenfield programming. -
Embed this notice
Palaiologos (kspalaiologos@fedi.absturztau.be)'s status on Thursday, 25-Jul-2024 01:26:16 JST
Palaiologos
My own "tier list" of programming languages, judging by how nice they were to use for tasks I had at hand.
S tier: C, Java, APL
A tier: Rust, Elixir, TypeScript
B tier: Haskell, JavaScript, Perl
C tier: Lua, Python, C++
D tier: PHP, Go, Common Lisp -
Embed this notice
Palaiologos (kspalaiologos@fedi.absturztau.be)'s status on Monday, 22-Jul-2024 19:30:18 JST
Palaiologos
@puniko indeed. -
Embed this notice
Palaiologos (kspalaiologos@fedi.absturztau.be)'s status on Monday, 22-Jul-2024 18:39:53 JST
Palaiologos
Finally! I have 4 full pages of table of contents. -
Embed this notice
Palaiologos (kspalaiologos@fedi.absturztau.be)'s status on Wednesday, 10-Jul-2024 17:02:58 JST
Palaiologos
One thing that I hate about literature markets is that the median customer has the intelligence of a Trump voter.
Out of curiosity I checked out the reviews online of the best data compression book available on the market right now (K. Sayood's) - it's about 100€ for a brand new copy at 800 pages. Reviews? Sorry, one star. Too expensive.
I could understand if the price tag of 200€ was too expensive. But 100€ for a book this big, really? An A4 page costs ~0.05€ to print; do some math in your head to notice how the author makes 0.07€ per page on this book (and probably even less if you add the publisher tax). Seriously, /that/ is too much? Most people don't understand two things: writing books incurs a non-linear cost. It's actually closer to being quadratic. If n is your amount of pages, it takes O(n^2) time to write, review and edit it all. Second, nobody is actually capable of doing a calculation like this in their head.
The only reason why you can buy e.g. JK Rowling's hot air for a few bucks a copy is precisely because publishers did the calculation and figured out that it's going to be economically feasible to batch print it and distribute it. Now take any less popular book where the publisher didn't entirely have such an assumption. Jane Hodge's "Shadow Of A Lady" (in the non-mass-market edition) by my calculations ends up at TWICE the cost per page compared to K. Sayood's book. No reviews about it being bonkers expensive. Go figure.
TL;DR: the average person can't divide two numbers in their head & that writing long form books is a stupid idea in this wretched economy. -
Embed this notice
Palaiologos (kspalaiologos@fedi.absturztau.be)'s status on Sunday, 07-Jul-2024 01:58:31 JST
Palaiologos
these two screenshots come from a single book. 7 pages apart. -
Embed this notice
Palaiologos (kspalaiologos@fedi.absturztau.be)'s status on Wednesday, 03-Jul-2024 04:35:56 JST
Palaiologos
Larry Wall on Lisp:
> Lisp has all the visual appeal of oatmeal with fingernail clippings mixed in. -
Embed this notice
Palaiologos (kspalaiologos@fedi.absturztau.be)'s status on Monday, 17-Jun-2024 03:51:52 JST
Palaiologos
@lanodan There are many things that I don't like about autotools, this is one of them. Why would *anyone* want a dist package?
But, I guess, nobody should have an obligation of having autotools/automake/libtool/m4 installed just to build a C project. -
Embed this notice
Palaiologos (kspalaiologos@fedi.absturztau.be)'s status on Monday, 17-Jun-2024 01:20:36 JST
Palaiologos
@lanodan Full story: https://github.com/kspalaiologos/bzip3/issues/81 -
Embed this notice
Palaiologos (kspalaiologos@fedi.absturztau.be)'s status on Monday, 17-Jun-2024 01:15:14 JST
Palaiologos
@lanodan That happened with Ubuntu for the longest time in late 2022. They were shipping a version that was broken on Macs. For my CI pipelines I had to patch it. -
Embed this notice
Palaiologos (kspalaiologos@fedi.absturztau.be)'s status on Sunday, 16-Jun-2024 20:26:35 JST
Palaiologos
before MTF transform: spiky, unpredictable, chaotic
after MTF transform: smooth, nice, pretty -
Embed this notice
Palaiologos (kspalaiologos@fedi.absturztau.be)'s status on Thursday, 13-Jun-2024 06:20:56 JST
Palaiologos
something makes me feel like i've stagnated as a mathematician and a programmer. i no longer solve problems on paper. i don't write as much code as i used to. the code that i do write - i usually solve new problems and is rarely difficult in the engineering perspective.
this makes me worried. i have noticed that my problem solving ability has gone down very significantly. -
Embed this notice
Palaiologos (kspalaiologos@fedi.absturztau.be)'s status on Monday, 13-May-2024 16:04:19 JST
Palaiologos
german business model was based on cheap energy from russia, cheap subcontractors in eastern eu and steadily growing exports to china. all three are gone by now, but german politicians are still stuck in a world that doesn’t exist anymore.
so now after the whole country has been turned into a smelly coal-burning pit thanks to fake reports about nuclear and understating the coal plant emissions by 200x, there's no going back and germany is sooner or later going to level with eastern european countries. -
Embed this notice
Palaiologos (kspalaiologos@fedi.absturztau.be)'s status on Wednesday, 08-May-2024 21:54:54 JST
Palaiologos
@nullenvk @puniko they're more complicated but the basic idea of including/excluding an event and computing the optimal followup works for every DP problem. -
Embed this notice
Palaiologos (kspalaiologos@fedi.absturztau.be)'s status on Wednesday, 08-May-2024 21:54:52 JST
Palaiologos
@nullenvk @puniko except the non-decision-oriented ones. -
Embed this notice
Palaiologos (kspalaiologos@fedi.absturztau.be)'s status on Wednesday, 08-May-2024 21:46:28 JST
Palaiologos
@puniko thankfully they're not that bad. it's a competitive programming class and, i'm not gonna lie, if your hammer is reduction to a variant of knapsack every DP problem looks like a nail -
Embed this notice
Palaiologos (kspalaiologos@fedi.absturztau.be)'s status on Wednesday, 08-May-2024 21:42:27 JST
Palaiologos
4h of mandatory lectures left let's go -
Embed this notice
Palaiologos (kspalaiologos@fedi.absturztau.be)'s status on Monday, 06-May-2024 08:10:51 JST
Palaiologos
Not sure where the JVM "bloat" moral panic comes from. You can have one instance per system and if you're very concerned with space, you can put it in a squashfs image or 7z archive and mount the latter using FUSE. Just ran a test:
27493121 jdk-8u422-jre.7z
28188489 jdk-22+34.7z
For comparison:
5554652 /usr/lib/x86_64-linux-gnu/libc.a
80555360 /bin/hugo
16661392 /bin/audacity
4906512 /bin/obs
Download a few apps that statically link to glibc (even though in most cases it's questionably legal...) and JVM no longer feels like bloat. -
Embed this notice
Palaiologos (kspalaiologos@fedi.absturztau.be)'s status on Monday, 06-May-2024 08:10:50 JST
Palaiologos
If anything, I would panic that all the "C replacements" always statically link to everything wasting space and that every electron app I install bundles the same stuff over and over again so that you can't get rid of it and have one runtime per system.
All GNU social JP content and data are available under the 
