APL suffers from the same apparent problems as Perl: They have friction coming from an unconventional syntax that's hard to understand without knowing the language beforehand, and when faced with competition, people went with the path of least resistance.
* Out of all people, and especially in the newer generations, it is increasingly uncommon to find someone with a desktop or even a laptop.
* Out of them, very few decide to do anything with it besides checking mail, social media, the web or play games.
* Out of them, very few decide to learn a programming language.
* Out of them, very few decide to learn anything besides Javascript or maybe Python.
* Out of them, very few decide to learn anything besides Java/C#/C++, learn algorithms, or learn tools like Vim or Emacs.
* Out of them, very few decide to learn anything besides Rust/Go/Haskell/Lisp/Scheme or even Fortran.
* Out of them, very few decide to learn a language with an alien, symbolic notation that resembles a code golfing language, and which, too, requires them to possibly learn a completely new keyboard layout to type with proificiency.
Not trying to discredit APL's contributions to functional programming and the like, but from the letter, it is pretty obvious Djkstra had little respect for friction. Not saying that he's right to dismiss it outright, though.
Now that I think about it, and I don't know if this exists yet, but APL would probably very much benefit from having a Scratch-like or Factorio-like visual editor paired with a touch interface. You would drag and drop symbols, and long-pressing a symbol would popup its definition.
You could also probably do nice things with the symbol "icon blocks" themselves, and provide them with colors or different visualizations to convey different contextual meanings.
That wouldn't help much. People who don't use these languages doesn't understand that what makes the language different isn't the syntax. There are plenty of dialects that use English words instead of symbols (check out Ivy by Ron Pike for example).
The difference is much deeper, but the best way to understand it is probably to check out an introduction (there is a lot on youtube).
I'd personally be happy to give an introduction to anyone willing to listen, but this comment field is not the place to do it.
Excel, visual "programming" lo/no code environments, and Factorio itself are all examples of this fallacy: making it easier to build complex symbolic systems doesn't help people learn how to manage that complexity; it in fact enables them to produce overtly complex systems that become hard to extend, to maintain and to debug.
That is precisely the source of my skepticism regarding the use of LLMs to code. What benefits most programmers, teams and organizations in building and manage complex systems is discipline. Disciplined work produces systems that are relatively easy to represent and reason about, and the shallow lesson people take is that easy representation is a silver bullet.
People keep falling for that trap over and over again. Understanding it deeply can provide lots of great opportunity for interesting work though.
IMO, Perl's downfall was mostly Perl 6, not the language.
Plenty people wrote plenty of Perl long ago. Yeah, the whole $ business is maybe a bit unintuitive, but it's the least of the problem really. It's easy to get past it.
IMO, the first part of Perl's downfall is that it didn't evolve fast enough. It was good enough that people tried to do big things in it and then it turned out it wasn't a good idea. Perl's OO for instance is kind of a neat hack that turns into a horrible mess with large projects. Large projects also increasingly need verification and safety because the debug costs rise higher and higher, and Perl is paradoxically safer at small scales. "use strict" works great in toy scripts and is nigh useless in OO-laden large projects where "strict" does nothing to check your $this->{foo}->{bar} hash trees. Yes, solutions sort of exist but they're all adhoc and you have to plan for them, and module writers don't use them, and...
That could have been survivable with the right improvements, but:
The second part is that Perl 6 was terribly planned and took bloody ages to get anywhere. People stopped writing Perl 5 expecting Perl 6 was around the corner, so why invest too much effort when it was clear 6 was going to be incompatible even early on? And it kept not coming out, so Python quickly ate its lunch.
>Godot locks you into the Godot way of doing things. MonoGame is a thin cross-platform abstraction over platform APIs for sprite rendering, audio playback, input, and font, leaving you to build your game engine yourself however you like.
Honestly, this sounds like a future headache that would otherwise go unnoticed unless the programmer is dealing with porting or binding over source code meant for older Windows systems to Zig (or supporting older systems in general). Eventually it might result in a bunch of people typing out blogposts venting their frustrations, and the creation of tutorials and shims for hooking to Win32 instead of the Zig standard library with varying results. Which is fine, I suppose. Legacy compiler targets are a thing.
This is already a problem with Linux binaries for systems that don't have a recent enough Glibc (unless the binaries themselves don't link to it and do syscalls directly).
Wouldn't that be just QR codes (and equivalents)? I suppose 3D printers can be used to etch/print them onto a durable material and then have it read back using the measuring tools you mention, but at that point I think you would be better off just 3D-printing out something like a a vinyl disc maker/reader and using that.
I haven't really looked into this, but is it possible to make GTK4 apps look liek standard GTK2/GTK3 applications? It feels like every single modern GTK app I've encountered has that modern Rounded-Material look to them and ignores the window manager decorations.
That's because Gtk4 does "client side decoration".
That has the advantage (or otherwise, depending on your point of view!) that the application can now place custom widgets in the title bar, and the disadvantage that when apps do that, the part of the title bar available for dragging windows around becomes significantly smaller.
My main objection to client-side decoration is that middle-clicking a window's title bar to push it to the back no longer works. (Plus, for those of us with eyes that aren't as young as they once were, it's now much harder to choose a window border style that clearly indicates which window has focus.)
My biggest problem (of many) with client side decorations is that now when your program crashes, you can't just hit the close button to have the window manager kill it, because the process responsible for drawing and responding to the close button has crashed.
The trick is to avoid software using the newer gtk versions.
`archive.ph` doesn't seem to work on paywalled Medium articles.
Not trying to point fingers or make a comment on the value of the article's content, but it's worth noting that 7 links from this Medium account have been submitted in the past 10 days. All of the previously submitted articles are similarly paywalled.
> It's ok to post stories from sites with paywalls that have workarounds.
It also says this too, but I think indeed there is no workaround, and that these submissions go against HN's policy & the first guidelines remains:
> In comments, it's ok to ask how to read an article and to help other users do so. But please don't post complaints about paywalls. Those are off topic.
Blocking file-based installations was never planned. It's fake news and always has been. It's all about requiring code signing for all code so that malware-spreading authors can be easily blocked by adding their signing key fingerprint to the blocklist.
It doesn't matter whether the app is installed via Play Store, Huawei's or Samsung's store etc., or from APK.
This is a drastic misrepresentation of the situation. All Android apps already have code signing, you cannot install an app unless it has a signature, and any future updates are blocked unless the signature matches. This is how it's been practically since the start of Android, it's part of the security model to prevent something like a malicious Firefox APK stealing your cookies.
What's new is that they were gonna block installations outside of Google Play, unless the developer has signed up for Google Play Console and has gone through a verification process there, whitelisting their signing key fingerprint. However, they've walked back on this and said they'll create a new "advanced flow" for "advanced users" that's "designed to resist coercion" to bypass this restriction. Door in the face technique IMO, the existing 12-step process to installing an app was already complicated enough.
So effectively the result is that file based installations will be blocked unless Google has specifically whitelisted their key through the Google Play Console verification process, or the user goes through this "advanced flow" which we're yet to see any details of
I am currently in process of "verifying" my identity with Android Developer console.
In addition to proof of identity (e.g. passport/driver license) Google is demanding a proof of address, government registration, this month's rental agreement, foreign passport... The process is stuck in limbo because months-old documents are deemed "outdated", and I am constantly threatened that my verification request (!) will be denied because of "exceeding allowed number of attempts" (!!)
It shares the same principle as silent Discord account bans and other "verification" harassment schemes, such as Upwork account verification. The excess developers — Google's potential competitors — need to be banished from platform as quickly and cheaply as possible, so that Google can peddle their own spyware unimpeded.
Ask your president. I suppose republicans will soon block VPN apps, adult apps and whatever comes to their minds as non-compliant with their medieval mindset.
* Out of all people, and especially in the newer generations, it is increasingly uncommon to find someone with a desktop or even a laptop.
* Out of them, very few decide to do anything with it besides checking mail, social media, the web or play games.
* Out of them, very few decide to learn a programming language.
* Out of them, very few decide to learn anything besides Javascript or maybe Python.
* Out of them, very few decide to learn anything besides Java/C#/C++, learn algorithms, or learn tools like Vim or Emacs.
* Out of them, very few decide to learn anything besides Rust/Go/Haskell/Lisp/Scheme or even Fortran.
* Out of them, very few decide to learn a language with an alien, symbolic notation that resembles a code golfing language, and which, too, requires them to possibly learn a completely new keyboard layout to type with proificiency.
Not trying to discredit APL's contributions to functional programming and the like, but from the letter, it is pretty obvious Djkstra had little respect for friction. Not saying that he's right to dismiss it outright, though.
reply