191–200 of 201 posts
Earlier quoted context omitted.
Gandalf wasn’t a technologist. (Edit) and his magic wasn’t remotely Vancean
This is true, but the practical LLM wrangling seems less technological than I think any tech I have seen until now.
Shallow and composable is something we all experience when using UNIX tooling. GUIs are where this all falls apart as they are literal islands that don’t communicate with each other in a composable manner. I’ve been experimenting with some GUI-meets-shell-pipeline ideas with a tool I’ve been working on call guish. https://github.com/williamcotton/guish I’m curious to know if anyone knows of any similar tools or appro…
If you look at the resumes of engineering or automotive company leadership, you'll see people going through stages of ever expanding responsibilities of part, component and product design, or management of production facilities of increasing size and importance. The CEO will still emphasize their technical knowledge, non-technical staff will at least try and fake it. In agile software development on the other hand, t…
> I partly blame Hollywood and their incessant humiliation of software/IT people, while creating endless leading roles for doctors and lawyers, effortlessly weaving their complicated terminologies into fascinating storylines, which is aparently not possible to do for us? Doctors and lawyers deal with people and everyday problems that are easy to turn into a interesting story. I don't see many contract lawyers or radi…
Hi! Author here. I think it's important to address certain aspects of this post that people tend to misunderstand, so I'll just list them here to save myself the effort. * I do not argue against abstractions, but against the unrestricted application of them. * I do not advocate for a reversion to more constrained platforms as a solution. * I do not advocate for users becoming "more technical" in a "suck it up" fashio…
I liked the way you showed the problem as ongoing in history. Indeed, the phrase "software crisis" is nice because it references the first point when the situation was articulated. That said, I think the reason the situation is not going to change is clearly economic. That's not saying that bad software is cheaper. But there's a strong incentive to cheap, bad practices because cutting corners allows one person/organi…
It takes time and effort to optimize software for performance, user-friendliness, developer-friendliness and everything that ethical and mindful developers hold up so highly, but that’s not the kind of thing that the big money or academic prestige is very interested in. The goal is to get the most users possible to participate in something that doesn’t repulse them and ideally draws them in. The concerns of ethics, dignity, and utility are just consequences to settle, occasionally dealt with before the world raises a stink about it, but are hardly ever part of the M.O.
Imagine if developers could make a dignified living working to listen to people and see what they really need or want and can focus on that instead of having to come up with a better ‘feature set’ than their competitors. It’s essentially why we have hundreds of different Dr. Pepper ripoffs sold as ‘alternatives’ to Dr. Pepper (is this really a good use of resources?) instead of making the best Dr. Pepper or finding a way to tailor the base Dr. Pepper to the consumers taste, assuming enough people claim they want a different Dr. Pepper.
Hi! Author here. I think it's important to address certain aspects of this post that people tend to misunderstand, so I'll just list them here to save myself the effort. * I do not argue against abstractions, but against the unrestricted application of them. * I do not advocate for a reversion to more constrained platforms as a solution. * I do not advocate for users becoming "more technical" in a "suck it up" fashio…
My problem with your article is that it seems to operate on the misconception that someone must completely understand from top to bottom the entire stack of abstractions they operate atop in all of its gory and granular detail in order to get anything done, and so a larger tower of abstractions means a higher mountain to climb up in order to do something. But that's simply the opposite of the case: the purpose of abs…
Only if those abstractions are any good. In actual practice, many are fairly bad, and some are so terrible they not only fail to fulfill their stated goals, they are downright counterproductive.
And most importantly, this only works up to a point.
> Yes, the machine and systems underneath the abstractions are far more complex, and so if you set out to try to completely fit all of them in your brain, it would be much more difficult than fitting the entirety of the Commodore 64 in your brain, but that greater complexity exists precisely to free the higher layers of abstraction from concerns about things like memory management and clock speeds and so on.
A couple things here. First, the internals of a CPU (to name but this one) has become much more complex than before, but we are extremely well shielded from it through its ISA (instruction set architecture). Some micro-architectural details leak through (most notably the cache hierarchy), but overall, the complexity exposed to programmers is orders of magnitudes lower than the actual complexity of the hardware. It's still much more complex than the programming manual of a commodore 64, but it is not as unmanageable as one might think.
Second, the reason for that extra complexity is not to free our minds from mundane concerns, but to make software run faster. A good example is SIMD: one does not simply auto-vectorise, so to take advantage of those and make your software faster, there's no escaping assembly (or compiler intrinsics).
Third, a lot of the actual hardware complexity we do have to suffer, is magnified by non-technical concerns such as the lack of a fucking manual. Instead we have drivers for the most popular OSes. Those drivers are a band-aid over the absence of standard hardware interfaces and proper manuals. Personally, I'm very tempted to regulate this as follows: hardware companies are forbidden to ship software. That way they'd be forced to make it usable, and properly document it. (That's the intent anyway, I'm not clear on the actual effects.)
> I think a world in which we abandoned C Machines and the paradigm where everything is opaque black box binaries that we control from a higher level shell but have no insight into, and instead iterated on what the Lisp Machines at the MIT AI Lab or D-Machines at Xerox PARC were doing, would be far better, and would allow us to achieve similar levels of ease and productivity with fewer levels of abstraction.
I used to believe in this idea that current machines are optimised for C compilers and such. Initially we could say they were. RISC came about explicitly with the idea of running compiled programs faster, though possibly at the expense of hand-written assembly (because one would need more instructions).
Over time it has become more complicated though. The prime example would again be SIMD. Clearly that's not optimised for C. And cryptographic instructions, and carry-less multiplications (to work in binary fields)… all kinds of specific instructions that make stuff much faster, if you're willing to not use C for a moment.
Then there are fundamental limitations such as the speed of light. That's the real reason between cache hierarchies that favour arrays over trees and pointer chasing, not the desire to optimise specifically for low(ish)-level procedural languages.
Also, you will note that we have developed techniques to implement things like Lisp and Haskell on stock hardware fairly efficiently. It is not clear how much faster a reduction machine would be on specialised hardware, compared to a regular CPU. I suspect not close enough to the speed of a C-like language on current hardware to justify producing it.
Earlier quoted context omitted.
Just curious, could you give a specific example where you've found it's better to reinforce an inaccurate mental model of the software? And how do you go about it?
I did it a ton, in my day job (image processing/camera control). I won’t directly link to that (personal policy), but we were in a constant war with the hardware people, who wanted, basically, skeuomorphic representation. We found that users often found these to be overcomplex, and that software often allowed us to abstract a lot of the complexity. Many camera controls are where they are, because, at one time, we nee…
Earlier quoted context omitted.
I did it a ton, in my day job (image processing/camera control). I won’t directly link to that (personal policy), but we were in a constant war with the hardware people, who wanted, basically, skeuomorphic representation. We found that users often found these to be overcomplex, and that software often allowed us to abstract a lot of the complexity. Many camera controls are where they are, because, at one time, we nee…
Thanks for the info, so you're talking about adjusting or replacing the UX based on user feedback. It makes sense now, but I guess I was imagining something different when you mentioned reinforcing inaccurate mental models.
That way, they will hear it from the users.
I am often written off as "a whiner," but they have to pay attention to the end-users.
Earlier quoted context omitted.
> No, I'd argue it's much more common for there to be flaws. They're just not obvious. They're random crap like my phone continuing to vibrate after I've answered the call until I get another call or text. This is kind of what I'm talking about. The absolute massive complexity within your device that you and billions of people to seamlessly make calls from anywhere in the world to anywhere in the world with devices m…
> But yes, sometimes the phone doesn't stop vibrating. I failed to communicate clearly. Yes, I agree, the scope of human achievement is amazing, software included. However, the issues with software go far deeper than just the trivial example I gave of the phone. It's pervasive and pernicious. I assume most software developers understand this as lived experience, but I'll elaborate more. Almost every single person I k…
So it’s not so much that we don’t have people pushing for quality, we do. We just can’t agree on what quality even looks like.
> It is no longer easy to build software It is very easy if you know the right tools for the right job, but information about these are suppressed so you never hear about them. What the vast majority of people think the tech tooling landscape looks like and what it actually looks like are very different. The tools we know about are mostly horrible. They try to be silver bullets but they're really not good for anythin…
Web3 / popular crypto is not my bailiwick (although I like math and so unpopular crypto). Your video is three hours long, I'm not going to watch the whole thing, and leave it at that. That's not a slight, but three hours for something which I already feel isn't going to deliver something I can use today, next week, or this month. I'm a big believer in no/low code and run-anywhere... although those might also not mean…
It makes it impossible to introduce back end bugs or security flaws (assuming that access control rules are defined correctly; which is a lot easier to verify via a simple UI than reading thousands of lines of back end code).
Look at this app I built with it on the side: https://www.insnare.net/
It's only ~1300 lines of custom code in total. Most of it is HTML. Throughout the entire process from start to finish, I never encountered a single back end bug. Deployment essentially never fails; the UI doesn't let you do anything invalid and it helps avoid inefficient queries. Yet look at the complexity of what kinds of queries and filters I can run against the data and all the different views. It has almost 1 million records... Indexes are not even fully optimized. Look at the data that's behind access control/associated with specific accounts (e.g. the Longlists).
Go ahead and try to bypass access controls... The WebSocket API is documented here: https://github.com/Saasufy/saasufy-components/wiki/WebSocket...
It would normally have taken months and tens of thousands of lines of code (front end and back end) to build that.
The value is there in terms of security, development efficiency, maintainability etc... The hard part is getting people to see it.