The engineers who designed the #Voyager probes half a century ago even thought of the possibility that a wrong sequence of commands may point the antenna dish away from earth (like someone did a couple of days ago).
And they implemented a self-adjusting mechanism that a few times a year scans the positions of a few known stars to infer the position of the earth, and point back the antenna in the right direction.
50 years later, these wonderful machines are still working, tens of billions of km away from earth, with only 69 KB of RAM, and even a wrong sequence of commands won't put them out of use, while nowadays 4 GB of RAM aren't even enough to start VsCode or IntelliJ.
The more I understand how they were designed, the more I feel like an early Medieval engineer looking at the Pantheon or other marvels of Roman architecture. Some amazing skills, knowledge and attention to details have been lost from that generation to ours.
like this
reshared this
Charlie Stross
in reply to Fabio Manganiello • • •Shiri Bailem likes this.
Anna Nicholson
in reply to Charlie Stross • • •@cstross 48 KiB? Ha! 😉
I used Visicalc on a *32 KiB* CBM 8032!
Shiri Bailem
Unknown parent • •@Nora Rose @:gay: zetta :transknife: @Fabio Manganiello there's alot more to it than that, and purpose built hardware doesn't affect this very much (purpose built software however is a major factor).
But also, there's years of cruft from programmers no longer being under pressure for resources. Very often today the memory usage of a program relates to the fact that it would take a lot of work to optimize it, and systems have more than enough resources to run it unoptimized without much issue...
Fabio Manganiello
Unknown parent • • •@bumpus @june I've dug on this aspect (abstractions vs. specializations in engineering) in this message social.platypush.tech/@blackli….
You are right, when you optimize you usually specialize and lose abstractions, which means losing the general-purpose aspect.
But the opposite is also true - create too many abstractions, and you start introducing more cognitive burden, besides the performance overhead.
I feel like there's a "sweet spot" for general-purpose software.
Fabio Manganiello
2023-07-30 18:17:36
Shiri Bailem likes this.
Lorq Von Ray
in reply to Fabio Manganiello • • •Daniel Wurzbacher likes this.
BJ Swope :verified:➖
in reply to Lorq Von Ray • • •Daniel Wurzbacher likes this.
Natasha Nox 🇺🇦🇵🇸
in reply to BJ Swope :verified:➖ • • •@cybeej @lorq Do you (both) think it has to do with the commercialisation of education itself?
I keep seeing all those certifications and courses for and by companies and their products as well as universities and schools being filled with tech by either Google, Apple or Microsoft, and I wonder whether studying informatics is the only way nowadays to actually get taught necessary basic skills to understand the technology you're working with.
BJ Swope :verified:➖
in reply to Natasha Nox 🇺🇦🇵🇸 • • •Fabio Manganiello
in reply to BJ Swope :verified:➖ • • •good point there.
I've looked at some of the Assembly code that was written at NASA in the 1960s and 1970s (the one for the Apollo programs was also open-sourced a while ago).
I was impressed by how "embedded" it was, with literally zero room for abstractions. The code was tightly coupled to the hardware. Each single bit was crafted and optimized for its specific purpose on that specific hardware.
You can do amazing things once you remove all the abstractions. You can get very creative on how to optimize resources if you know that your code will only run on one specific piece of hardware, for a very specific purpose.
Let's not forget that until at least the early 1980s most of the computers didn't even agree on the "word size", and even on the byte as the minimum quantity of addressable information.
As we started seeking for compatibility, more general-purpose hardware and software, lower entry barriers for coding etc., we started introducing abstractions.
Those abstractions came with many advantages - namely lower barriers for coders and greater portability. Also, decoupling software from hardware meant that you no longer have to be a electronic engineer (or an engineer who deeply understands the architecture the software is running on) in order to code. But I also feel like there's an inflection point, and once we pass it those advantages start to fade.
It's obvious why a compiler that can digest the same piece of C/C++ code and produce an exe on different architectures is a useful abstraction. Same goes for a virtual machine that can run the code on any architecture without recompiling it from scratch.
But when building a basic website ends up creating a node_modules folder of 200 MB, requires the developer to be familiar with npm/yarn/gulp pipelines, transpiling etc., and maybe also with deploying their code to a Kubernetes cluster running on somebody's private cloud, I wonder if we've already passed that inflection point.
Shiri Bailem
in reply to Fabio Manganiello • •@Fabio Manganiello @Nora Rose @:gay: zetta :transknife: Absolutely agree!
That's why I tried to avoid value judgement terms in my commentary on it... I mean, I'm a python programmer (hobbyist), that right away puts me right in there with using more resources than I technically need for a project!
Kevin Karhan :verified:
in reply to Fabio Manganiello • • •Shiri Bailem
in reply to Kevin Karhan :verified: • •@Kevin Karhan :verified: @Fabio Manganiello you cite two (relatively) high level programming environments, which no amount of money would achieve that efficiency.
You know what does it easily? Writing your code in assembly like they did.
Every level above assembly your programming language is results in an exponential loss in efficiency, you trade resources for programmer workload and vice versa.
I can't find it anymore, but I remember seeing a programmer's website where they had a whole bunch of windows gadget programs, full fledged GUI applications and non-trivial ones all under 5kb in size because they were written in assembly (they made a game/hobby I believe of rewriting programs in assembly to see if they could get them under 5kb).
Daniel Wurzbacher likes this.
LisPi
in reply to Fabio Manganiello • • •Shiri Bailem
in reply to LisPi • •@LisPi @Fabio Manganiello that's certainly one way to put it lol
I write Python because when I look at trying to write the same code in C or assembly... well, I definitely don't give enough of a shit for that lol
LisPi
in reply to Shiri Bailem • • •That's not really the only option though, #CommonLisp performs within a magnitude of C/C++ with barely any effort (maybe just a few type annotations in some loops).
There are other structural problems with cpython (not sure if inherent to the language though or just a cpython problem) because it performs significantly worse than many other bytecode VM languages (like #Racket).
(I'm very willing to believe it's just cpython being a bad compiler/implementation)
Shiri Bailem
in reply to LisPi • •@LisPi @Fabio Manganiello it's definitely wildly different, and part of the reason I threw assembly as a comment in there too.
You could write a whole paper on the inherit performance problems in Python, it's a language whose first and foremost goal is readability and ease, it makes ALOT of compromises for that.
For one, CPython is interpreted, not compiled. This makes a drastic reduction in performance (PyPy uses JIT and for heavier applications ends up drastically faster than CPython).
The fact that it uses heap memory and dynamic types takes some performance hits as well.
And it's abstracted to hell and back, which makes it super easy... but super inefficient.
At your mention of it, I took one look at CommonLISP and definitely said I don't give enough of a shit to learn that lol.
🏴 Lispegistus 🧠➕🖥️
in reply to Shiri Bailem • • •The following opinion is based on 16 years of python experience(including some where I had to squeeze as much performance out of it as possible without dropping to C) and 14 years of common lisp experience: cl has every advantage python has as a high level dynamic language with support for abstraction way above what python can offer and it performs 2 orders of magnitude better in some cases. Also cl takes way more than one look to learn.
Shiri Bailem
in reply to 🏴 Lispegistus 🧠➕🖥️ • •@🏴 Lispegistus 🧠➕🖥️ @LisPi @Fabio Manganiello definitely not every advantage... one glance is enough to get the basics with python, which is kind of the point with the language. From what little I know readability is cited as the biggest reason Common Lisp isn't more popular.
I'm not going to say that Lisp is bad in any way, just that it's designed differently from Python and scratches a different itch.
Also, "support for abstraction" is a meaningless phrase, if we're going to talk about the amount of abstraction a language supports then assembly would rule them all. The difference is the base levels of abstraction, a more highly abstracted language is going to have less options for adding additional additional abstraction and you have to go significantly out of your way to reduce abstraction (Python's print command is abstracted all the way to hell and back for instance, which isn't the greatest for performance)
🏴 Lispegistus 🧠➕🖥️
in reply to Shiri Bailem • • •@shiri @lispi314 Yes, python is slightly more readable to someone who is not used to reading lisp. To someone who is, they're basically equally readable.
The problem is in python you don't have a choice, everything is either a very poorly thought out VM bytecode interpreter, or a C extension. So dicts are very fast, because they're written in C, but if you want to add your own data structures they're slow unless you write them in C. In Lisp you can do it all just fine.
🏴 Lispegistus 🧠➕🖥️
in reply to 🏴 Lispegistus 🧠➕🖥️ • • •LisPi
in reply to 🏴 Lispegistus 🧠➕🖥️ • • •@lispegistus @shiri I can remember several instances of breaking changes in minor version changes (let's completely remove/rename stdlib modules, what's the worse that could happen?) and it promptly breaking my code.
Amusingly, as far as teaching languages go I think that Racket might do a better job of both the teaching and being used effectively in prod anyway.
🏴 Lispegistus 🧠➕🖥️
in reply to LisPi • • •Shiri Bailem
in reply to 🏴 Lispegistus 🧠➕🖥️ • •@🏴 Lispegistus 🧠➕🖥️ @LisPi @Fabio Manganiello while it's popular for teaching, I don't think Python was ever intended as a teaching language specifically.
As I understand it Python was inspired by ABC, which was a teaching specific language, which could definitely be an influencing factor on a lot of things.
But the biggest thing in Python is "pretty code" (so much of PEP8 is style formatting).
Shiri Bailem
in reply to Shiri Bailem • •@LisPi @Fabio Manganiello @🏴 Lispegistus 🧠➕🖥️ also I see here a lot of the same logic I see other places where a language is considered easy to read after you've learned it and that being judged against Python's design intent of being easy to read if you don't even understand programming as if they're the same thing.
It's much like the classic argument of whether someone should learn C before Python or Python before C. One side argues that the learning value should be judged based off of the completeness of their knowledge on the other end, while the other argues that the learning value is in how easy it is to reach the end (with the completeness being a later step). (I'm in the Python before C camp, I believe a language at Python is better for learning the high level concepts and learning Python before C would be faster and easier learning both than just learning C in the first place).
Also, I think the biggest reason Python is so popular: it's so easy to make something accidentally production. So many Python projects started as a demo gadget that just became production software without any real hitches along the way (first example that comes to mind is Ansible).
🏴 Lispegistus 🧠➕🖥️
in reply to Shiri Bailem • • •@shiri @lispi314
You're only going to be a complete beginner for maybe a few weeks to a full semester depending on the person. I'd rather a language used in production be optimized for the hopefully many many years after.
Also, yes, that's true, I actually had to maintain some python that accidentally became production and fuck that.
🏴 Lispegistus 🧠➕🖥️
in reply to Shiri Bailem • • •@shiri @lispi314 Possibly, it did very quickly shift to a scripting language and was used mostly by sysadmins and as an extension until the mid-2000s when it gained a foothold in web development, that's when I picked it up.
Pretty code, compared to perl, that was the big competitor at the time, and also one of the lowest bars in existence(when you unintentionally create an esolang because you're too smart for your own good, yes, perl is on the esolang list esolangs.org/wiki/Language_lis… :)
Language list - Esolang
esolangs.orgReid :ablobcatattention:
in reply to LisPi • • •D2
in reply to Fabio Manganiello • • •Shiri Bailem likes this.
John Lusk
in reply to Fabio Manganiello • • •I bet there are some Russians performing wonders with washing-machine processors.
@inthehands
Joe Cotellese
in reply to Fabio Manganiello • • •Reminds me of this old article about the software team working on the Space Shuttle.
"The most important things the shuttle group does — carefully planning the software in advance, writing no code until the design is complete[.]”
fastcompany.com/28121/they-wri…
Lentävä Kalakukko
in reply to Fabio Manganiello • • •Time, cost, quality — pick any two.
It's no different now than it was 50 years ago. It's just which two NASA picked, and which two most regular commercial software projects pick.
jdp printmaking
in reply to Fabio Manganiello • • •Shiri Bailem likes this.
Yora
in reply to Fabio Manganiello • • •Жером "Mithriel" Дармонт 🇺🇦
in reply to Fabio Manganiello • • •Moffin'tosh
in reply to Fabio Manganiello • • •Also money and time that things where given
Arco Fox
in reply to Fabio Manganiello • • •Shiri Bailem
in reply to Arco Fox • •SFborn1940
in reply to Fabio Manganiello • • •Emanuel Schleussinger 💾
in reply to Fabio Manganiello • • •pouët.net :: your online demoscene resource
pouët.netJon
in reply to Fabio Manganiello • • •