Oh absolutely. The wireless for gaming headsets isn’t Bluetooth either. If your argument is Bluetooth isn’t suitable for real time, I’m on board - I’d even go further and say Bluetooth isn’t suitable for anything other than fire and forget.
Gaming headsets are usually 2.4GHz wireless, and pro audio stuff is ~500-800MHz and the proper stuff requires a wireless license to use.
Yes. LLMs are search engines into the (latent) space or source code. Stuff you put into the context window is the "query". I've had some good results by minimizing the conversational aspect, and thinking in terms of shaping the context: asking the LLM to analyze relevant files, nor because I want the analysis, but because I want a good reading in the context. LLMs will work hard to stay in that "landscape", even with vague prompts. Often better than with weirdly specific or conflicting instructions.
But search engines are not a good interface when you already know what you want and need to specify it exactly.
See for example the new Windows start menu compared to the old-school run dialog – if I directly run "notepad", then I get always Notepad; but if I search for "notepad" then, after quite a bit of chugging and loading and layout shifting, I might get Notepad or I might get something from Bing or something entirely different at different times.
Probably true for many. When thinking about hard problems I'm usually not thinking in language, at least not the kind we speak between us humans, so it can be incredibly distracting if I have to "translate" back and forth while both thinking and communicating.
Java also targets an abstract machine model (JVM) - such statement really doesn't mean much.
Assembly is not about corresponding to exactly which gates open when in the CPU. It's just the human writable form of whatever the CPU ingests, whereas C is an early take on a language reasonable capable of expressing higher level ideas with less low-level noise.
I seriously doubt anyone who has written projects in assembly would make such comparisons...
>I seriously doubt anyone who has written projects in assembly would make such comparisons...
With genuine respect, I believe this type of insinuation is rarely productive.
Someone might still have silly opinions, even if they have been paid to write assembly for 8-24-64 bit cisc, risc, ordered and out of order ISAs, and maybe compilers too. Peace :)
Yes but someone might also have silly opinions from having no experience how production assembly actually looks, such as underestimating just how different working with that is to working in high-level languages like C and why such languages were quite revolutionary. :)
This should not be mistaken as appeal to authority, it is merely reasonable discrimination between those speaking from experience, and those forming opinions without experience.
If one believes those with experience has poorly informed opinions, they're always free to gain experience and associated perspective. They will then either have the fundamentals to properly push their viewpoint, or end up better understanding and aligning with the common viewpoint.
Yes and no, you can use c in situations where there's no "assembly", for instance when synthesizing FPGAs. You target flow graphs directly in that case IIRC.
sure, I was thinking of large OO cores. "Correspondd to the instructions the cpu runs and their observable order" is how I'd characterize C as well, but to each their own.
I have empathy for this having written compiler passes for 10ish years of my career. But as I've studied register renaming, speculative branch prediction and trace caches I would no longer agree with your last sentence. It's fine though, totally just an opinion.
When I was in third grade, I decided I want to make computer games to get more of them. Dad got me started with GW-Basic turtle graphics and I made pictures with them - usually non-functional title screens for my games.
At some point I had made a small space ship and was able to make it turn around with the wonderful angle command [1]. However, I could not figure out how to make it move "forward" regardless of the angle.
I was also attending an after hours computer graphics club, mostly about Deluxe Paint, taught by a 20-something student (who much later went on to found a GPU company and got acquihired by ATI/AMD). He would help me occasionally, and in this case he took a tiny slip of paper and wrote down a couple of lines about sin and cos. No questions, no explanations, no gatekeeping.
Just like that I internalized this foundational piece of trig - later when it arrived in school maths it was easy and obvious for me. I had a practical application, but even more I think was because it started as a need I had, and when given to me, felt like a gift and an enabler.
Still much later I studied Seymour Papert's pedagogy and understood I had lived it. I consider myself fortunate.
Finnish has been very peripheral and isolated due to geography. It is closely related to Estonian, but remains much more similar to their common archaic root, while Estonian has streamlined and developed due to more contact and exchange.
In my experience search engines have rapidly deteriorated - probably because of the SEO arms race - and LLMs often feel like search engines used to feel back when they worked. Who knows what will happen once all the marketing attention shifts towards influencing LLM output.
It’s worth noting that C++ standard libraries have mostly moved away from copy-on-write strings, due to their poor performance in multithreaded scenarios. And JavaScript engines have ended up adding a bunch of optimizations that simulate mutable strings in certain common scenarios. It depends on what the code in question is doing, and I think the ideal scenario is to allow both in different contexts as long as they can be kept distinct.
Mutable string literals can't be easily deduplicated, unless your language semantics are that a literal is a singleton and all mutations are visible by all other evaluations of that literal. But no sane language would do that.
If the strings are backed by reference counted buffers, you can use copy-on-write semantics to provide the API of a mutable string but share buffers when a string is copied. Most C++ standard libraries actually did this prior to the multicore era.
For sure. Data structures and call graphs like to converge, so when designing a data model, you are actually designing the (most natural) program flow too.
