recently, you were rambling on-and-on about how netbsd was not a good desktop setup, even though netbsd primary usecase is embedded systems. nobody owes you anything; so just read threads that are interesting and ignore the rest; if that is not acceptable, why don't you be the change you wish to see in the world?
Dreams can come to a sudden halt, and as Walt Lawrence, John Callhan and Mark Zupan have demonstrated, it strengthens the reinvention and creative problem solving muscles.
It's common to hear folks in these situation saying that the "tragedy was the best thing that happened to me"; when I was young, I didn't really believe it, (watching the documentary of Walt Lawrence or reading John Callahan's book 'don't worry, he won't get far on foot'), but now that i am older, i can confirm it is definitely believable :)
Sure it is a good hobby for learning things; the title is definitely a clickbait and attention seeking;
The speaker has usb interface, and since it uses HID, its bandwidth is limited to 64bytes max per ms; it runs freertos, and for the price of the speaker it is highly unlikely it runs an mcu with trustzone;
moreover, usb descriptors are exchanged with the host in the clear, so patching it and adding a keyboard (that most os will implicitly trust) requires a usb cable, and there is definitely some 'touch' involved to get to that step, even if we ignore the physical access to the speaker/pc for the sake of argument;
of course, once that's done, updating image over bluetooth is easy, and that's the claim behind 'without ever being touched';
Ken Thompson's criticism of C++ as incoherent, complex and garbage heap of ideas still resonates with me; C++98 was the last version I used for work although I've dabbled in 11/17/20 out of curiosity.
IMO, if c++/cfront didn't ride on the tails of c, I'm skeptical it would've seen widespread use, but then, that's its main identity which limited it in ways that C++ was not willing to change; It is highly irritating to spend as much time to sanitize the implementation with Coverity/Valgrind and the ilk when the compiler could've handled it.
With C++98, Bjarne's book on c++ internals could've give you good insight into what went on, but later it turned into a whole cottage industry of "effective, more effective, proficient, performant, c++" series of books -- so kiss goodbye to any notion of being able comprehend existing code that's not written by you (until llms arrived). I'm happy to have spent time to learn problem domain instead.
I'll still watch the documentary since it has some of my favorite folks (Kernighan, Stepanov).
> if c++/cfront didn't ride on the tails of c, I'm skeptical it would've seen widespread use
What launched C++ into success was Zortech C++. At the time, 90% of programming was done on MS-DOS. Cfront was nearly unusable on DOS, because:
1. agonizingly slow to compile
2. no support for near/far pointers, which was essential for non-trivial apps
Zortech C++ fixed those problems, and sold like wildfire. This provided critical mass for C++ to succeed. The traffic on comp.lang.c++ angled sharply upward. Borland saw our sales, and abandoned their OOP language product and did Turbo C++ instead. Microsoft saw Borland's success and then did their own C++.
We sold a lot of Zortech C++ compilers to Microsoft. They used it to develop COM.
I heard rumors that Microsoft was developing their own OOP C, called C*. I've never been able to confirm it, though.
Your perspective on this may be distorted due to your personal involvement. Do you believe MSVC++ or Turbo C++ would still have existed without Zortech C++ arriving first? Because if so then I don't think you can really take credit for C++ popularity on the PC.
> Do you believe MSVC++ or Turbo C++ would still have existed without Zortech C++ arriving first?
Nope. As I mentioned, Borland was working on their own OOP C language. ZTC++'s success caused them to abandon it and do Turbo C++. I know this because of my conversations with Eugene Wang. And Turbo C++'s success caused Microsoft to do MSVC++, which was quite late to the game.
Before C++, the newsgroup traffic on C++ and ObjC was about the same. The C++ traffic took off after ZTC++ was released.
Little known fact - when I was contemplating enhancing Zortech C into C++, I was concerned about AT&T's intellectual property. I contacted Ryan Williams (I think that was his name), AT&T's IP lawyer. I asked him:
1. do I need a license to create a C++ compiler?
2. do I need to call it something other than C++?
He laughed and said, no, I could do whatever I wanted. He also thanked me for being the only compiler guy to ask permission.
I read about his passing a few years ago. He was a solid guy.
Something that not many people consider. It is almost certain that C++ "saved" C by existing. Without C++ there would be an enormous pressure to add more features to C itself. One reason why C committee could get away without adding much over the years was that they could nod towards C++ and say "that's their job, not ours". And if later didn't exist who knows what kind of language C would become. Classes? Templates? Lambdas? We can only speculate.
I don't know if this is true. In the 80s there were many languages that were C with additional features or C preprocessors that added and experimented with features similar to cfront. You had OOPC (object-oriented pre-compiler), Objective-C, C*, Concurrent-C. People were experimenting in all kinds of ways by taking C and trying things out with it.
I think it is absolutely true, because adding features to an experimental language that has no tools or ecosystem surrounding it does nothing and people know that.
Niche experiments having features doesn't accomplish anything, but adding just one more feature to C seems plausible.
With C++ people could point people to another production ready language compatible with C that people could use, so there was somewhere they could do and an example of the feature working instead of someone promising silver bullets in theory.
Yeah, OPs claim feels disconnected from C’s identity. C stayed conservative because the areas where it excels (to this day) benefit from its “portable assembler” design history. A history with no C++ wouldn’t have changed that, instead another (either non-C extended or alternative C-adapted [Obj-C, for instance]) language would have taken the market C++ did; likely with a larger runway time due to the lack of interoperability/superset compilation.
Hilarious coming from the guy whose shitty Multics ripoff directly inspired "Worse is Better"
From the essay:
"Unix and C are the ultimate computer viruses.
A further benefit of the worse-is-better philosophy is that the programmer is conditioned to sacrifice some safety, convenience, and hassle to get good performance and modest resource use. Programs written using the New Jersey approach will work well both in small machines and large ones, and the code will be portable because it is written on top of a virus.
It is important to remember that the initial virus has to be basically good. If so, the viral spread is assured as long as it is portable. Once the virus has spread, there will be pressure to improve it, possibly by increasing its functionality closer to 90%, but users have already been conditioned to accept worse than the right thing. Therefore, the worse-is-better software first will gain acceptance, second will condition its users to expect less, and third will be improved to a point that is almost the right thing. In concrete terms, even though Lisp compilers in 1987 were about as good as C compilers, there are many more compiler experts who want to make C compilers better than want to make Lisp compilers better.
The good news is that in 1995 we will have a good operating system and programming language; the bad news is that they will be Unix and C++."
I highly respect the Ken Thompson and the rest of the old UNIX hands, but wouldn't they admit that the real world is messy and the best solutions in isolation don't always win?
Their creation C and UNIX won over the more advanced LISP and Smalltalk systems because they were simpler to implement. Even their own more advanced Plan 9 based OSs could not displace the more widespread unix-like systems.
It seems distribution and 'good enough' to rely on always wins. IMO, dynamic languages like Perl, Python, Ruby, JavaScript, PHP and the heavily marketed Java provided good enough high level facilities that have prevented people from reaching for Lisp and Smalltalk.
Looking at it through this lens, perhaps C++ was the vehicle for strapping some high level facilities on a widely adopted low level performant language that made it just good enough of a technology for wide adoption.
You think that LISP and Smalltalk aren't widely used is because they weren't easy to implement in the late 1980's? There have been many languages that have risen to prominence in the 40 years since, yet LISP and Smalltalk remain niche languages.
My opinion is that Lisp and Smalltalk are too pure and abstract. C is heavily tied to the real world of computing and can be easier to grasp for beginner. But try to explain variable bindings (instead of assignment) or message passing (instead of function calls) to a beginner in programming. It’s not that they’re hard to explain or understand, they’re just hard to be completely grasped without a foundation in computer science. They’re too alien.
Rust, Python, Java, Ruby, Scala, Swift to start with. These are languages with very wide adoption. Objective-C is very Smalltalk-like, but it is being phased out for Swift.
It's why I've found Rust a joy - enough had happened in programming languages, that it was able to reinvent C++ with some of the best parts of the Haskell/ML/Scala family, some of the ergonomics of Python/nodejs, and bringing the borrow checker too.
C++ is this weird amalgam of like 7 different generations of languages.
But by far the worst part is the developer hostility behind the idea of UB. "Oh, this is not an error, it will compile, we will just secretly stab you in the back."
You can get good and avoid it, and there are tools to help you, but why is that at all a reasonable stance for the definition of a language?
Saying this about Rust and C++ is like saying the kitchen you just built is cleaner than the old kitchen you used for 50 years. Get back to me in another few years.
Now for Rust I don’t think it is going to change a lot. Because it is based on ML, it has the best foundations and all features are known. The question is more how much Haskell vs script/imperative do you want your language to be, and what’s the purpose of the language rather than we had the wrong paradigm and found a new better one. For Rust 99% of its features are known and most are already implemented.
Maybe things around the borrow checker, and await, but beyond that nothing as much as what C++ saw in its history. Even more when for instance you see the article from the guy doing Gleam where traits (impl) are not necessary, all you need is data and function to have the same functionality. Or how ML have been the main factor to most new languages or new features to existing languages.
The future is ML, with languages dedicated to specific use cases and niches. And also ML languages easily readable by AI.
> IMO, if c++/cfront didn't ride on the tails of c, I'm skeptical it would've seen widespread use
Obviously. C++ was a "better C" in that you could keep a lot of your "legacy" C code while improving your codebase piecemeal with C++ features. Your management didn't even have to care, in that C/C++ was accepted as a valid descriptor even by people who should have known better. It's a wonder Java/C# and Perl/PHP never caught on.
> kiss goodbye to any notion of being able comprehend existing code that's not written by you (until llms arrived).
In my experience it takes a while (<=3 months) for folks to become proficient when they see an alien dialect of c++. That may sound totally unacceptable to you (fair). Cpp is also a “big tent” language in that it is genuinely multi-paradigm.
I think LLM’s might help, but sometime they hurt too (confidently/persuasively wrong analyses). The gain is large for small/trivial contributions. For changes that require genuine understanding, I’m not sure (large error bars personally as to whether the sign is even positive).
The last one from Scott Meyers was the final nail in the coffin for me. The chapter about auto and template parameter deduction specifically. Since then, I've been happy with Golang and Java.
(briefly looked at the website). If you find traction for this idea, that's great. I use claude, and its feedback memory mechanism is already too much for me -- it crams a lot of 'project related' but unimportant cruft, and it keeps growing, and purging it is a chore (its own lexicon, lack of why it is relevant etc). My preference is to front end lot of disciplined design work, so it's memory tends to be quite useless really. The difficulty of getting paid $20 per month is another challenge. Either way, I wish you the best!
I think for me and the idea I saw a fundamental shift in the experience chatGPT provided once it was able to remember cross/post chat things. The APIs do not have this offering and are pretty bare, so being able to put this on top of any LLM API I think is a value add.
I am curious how you are using Claude in your case? Web-ui? Co-Work? Does not seem like API, but would help me.
see what people call desktop for a sys admin in unix is the ability to run xterms and ssh without having to remap keys on a standard pc kbd or get into arcane teminal configuration just to do admin tasks. I dont need a desktop (and dont have a desktop) I need working terminal. i figured out my issues but the point stands, xterm ssh from netbsd to debian should not corrupt a terminal or require debugging two dozen possible causes. Have normal defaults. on OpenBSD I never needed to touch terminal settings if I didnt want to same with linux. only netbsd is stuck in 1982 where it is question if bkspace is del or ^H.
reply