6 ms·
What if all problems were solvable by adding or removing a layer of abstraction? Perhaps, like any other tool-set... C has an optimal problem domain not everyo
by Joel_Mckay 4y ago
What if all problems were solvable by adding or removing a layer of abstraction?
Perhaps, like any other tool-set... C has an optimal problem domain not everyone can understand, and it is often unrelated to llvm compilers.
Those who failed to learn why C++ evolved into its current state, are simply doomed to naively make another iteration of the same tantalizing bad design choices.
https://en.wikipedia.org/wiki/Second-system_effect https://en.wikipedia.org/wiki/Second-system_effect
- marcosdumay 4y agoHow will undefined operations change with your new layer of abstraction? Anyway, you are really claiming that a sandbox capable of running C programs will solve more problems than writing your code in Rust?
- Joel_Mckay 4y agoI am inferring languages like Rust are not a replacement, but rather focus on a different problem domain already addressed in higher level languages. Its not a complete waste of time, but I have yet to see a use-case only Rust features could better achieve. I am not smart, so may have missed something important. =)
- marcosdumay 4y ago> languages like Rust Hum... If you know other languages similar to Rust, I'm curious to know them. Maybe there is something better out there, but AFAIK, the closest thing in existence is C. > a different problem domain already addressed in higher level languages Things like device drivers and embedded software. It's also what people push into submission when they want high performance software, but this is always a hard thing to do. I do really not recommend you to use Rust if a higher level language solves your problem. > I have yet to see a use-case only Rust features could better achieve It helps achieving things like making sure your GPU driver fucking works, instead of doing what the nvidia driver does. Of course, this article is about a different way of making sure it works. One that requires a lot more of work, but can provide some assurances that Rust can't. It is also easier to apply over Rust than C, but neither are the best target for it.
- Joel_Mckay 4y ago"making sure your GPU driver fucking works" Well I did notice how nVidia left out the part that the CUDA C API had a known bug that would crash on exit due to a de-allocation bug for years. Thus, C++ became the de facto interface for their GPU library. All code is terrible, but some of it is useful (except rust and VB). ;)
- whalesalad 4y agoWith things like WASM and GraalVM this is becoming more and more realistic. We don’t really write ASM anymore because it’s tedious and error prone, same can be said for C. I wouldn’t choose it today unless I absolutely had to. Abstraction is the way.
- qsort 4y agoAnd the language you use to target WASM is... C? I'm not necessarily saying it's a good language, but it's an excellent abstract machine. It won't die.
- SkyMarshal 4y agoJust about every language can compile or transpile to WASM: https://github.com/appcypher/awesome-wasm-langs https://github.com/appcypher/awesome-wasm-langs
- pjmlp 4y agoThere are plenty of WASM runtimes without any C on them.
- qsort 4y agoI'm not talking about the language you use to write the runtime. I'm talking about the language you use to write the code that becomes the WASM that the runtime runs. They not need be the same. As others have pointed out you can compile pretty much everything to WASM, but it's most often done with the same languages you'd use to compile to native code; C, C++, Rust, the usual suspects.
- pjmlp 4y agoD, Go and C# use their own bootstrapped compilers, just to give three examples from many others.
- Joel_Mckay 4y agoThe annoying part is having to endure the Astroturfing campaigns. I'd prefer a clear 1 liner in Julia or Prolog over 80 pages of unknown correctness. ;)
- billfruit 4y agoThere is benefits to using better and better tools as they are being invented and evolved. In many aspects C is a primitive tool.
- Joel_Mckay 4y agoNodeJS project: 441MB, 32872 dependencies, and uptime <5 days due to patching cycles C project Version: 2.5MB, 6 dependencies, and uptime 3+ years (OpenSSL patch ended the streak.) Being busy is not necessarily productive, and "Better" is often use-case dependent. =)
- ilyt 4y agoSo how you wrote same app that have half a gig of dependencies in NodeJS ? I have 10+ year Perl app that never needed fixing but I don't present it as an example of Perl being better than everything. Also JS is a particularly bad language in near-every respect and not even in same category as C so I dunno why you compare them in the first place.
- Joel_Mckay 4y agoPerl was awesome when no other options were available. And one will find many languages inherited its features, as is was great for parsing text. "So how you wrote same app that have half a gig of dependencies in NodeJS ?" Nope, some have greatness cast upon them... great heaping piles of steaming greatness... One likely already knows the greatness of which I speak. ;)
- kevingadd 4y agoWho's proposing replacing C with NodeJS? In the context of a discussion of how using verifiable/safe by design languages is an alternative to C?
- Joel_Mckay 4y agoIt was in jest of a "Novelty bias" assertion. ;)
- maratc 4y agoThe fundamental theorem of software engineering (FTSE) is a term originated by Andrew Koenig to describe a remark by Butler Lampson attributed to David J. Wheeler: "We can solve any problem by introducing an extra level of indirection." The theorem is often expanded by the humorous clause "…except for the problem of too many levels of indirection," referring to the fact that too many abstractions may create intrinsic complexity issues of their own. https://en.wikipedia.org/wiki/Fundamental_theorem_of_software_engineering https://en.wikipedia.org/wiki/Fundamental_theorem_of_softwar...
- Joel_Mckay 4y agoYes, written by someone who has never inherited a code-base hundreds of juniors patched over 12 years. At that point, you launch a separate division, slowly transfer functional support, and jettison the old structure after a year. ;)
- agentultra 4y agoIt's a funny aphorism at best but I don't think software would work nearly as well if there were more than a grain of truth to it. Think of all the layers of abstraction that have led to this moment, you reading this comment, me writing it: the hardware, the operating systems, libraries, run-times, the network... it's immense. And it's a wonder that it works so well let alone at all. I like this quote but I think it applies to weak abstractions; ie: not abstractions at all but, as they say, indirection and obfuscation. Using the word "abstraction" has done a lot of harm to efforts to convey the importance and utility of various formal methods from property testing to proof automation. A solid abstraction has fundamental laws and properties. It aids in mastering complexity rather than hinders.
- warinukraine 4y ago> "We can solve any problem by introducing an extra level of indirection." It's worth keeping in mind that this isn't a fundamental law of the Universe. Not all abstraction layers are equally good. Just because it's possible to do a bad job at something doesn't mean we can't try and do a good job.
- nomel 4y ago
- deltasevennine 4y ago>Perhaps, like any other tool-set... C has an optimal problem domain not everyone can understand Maybe this is true specifically for C. However you imply this is true for "any other tool-set". This is also a form of bias. It is illogical and irrational to think that every tool set is good for something. Things that exist can be horribly bad for everything and things that exist can in theory be good for almost anything. There is not magical rule that says all tool-sets are great because they're always optimal for some niche problem domain. The universe is not made up of apples and oranges. There are rotten oranges and rotten apples as well.
- Joel_Mckay 4y agoLanguages like Python/C# have fundamentally broken threading models. And yet people like to use these for cluster work. Kind of like eating steak with a spoon, as you never knew about forks. There are often language specific features that are not isomorphic, and are the primary reason a language was developed in the first place. =)
- achr2 4y agoCan you explain what you mean by C# having a "fundamentally broken threading model"?
- deltasevennine 4y agoSure there are forks and there are spoons. But there are also lumps of coal. You have a problem: You need to eat soup and steak. So you use a spoon or a fork. The lump of coal is useless. You can probably smash the steak with it then eat the remains or lick the soup off the wet coal you dipped into it. Possible but a horrible tool overall. There is an argument to be made whether certain languages are lumps of coals rather then a spoon or a fork =).
- meltyness 4y agoThis is a wrong interpretation of the obvious solution, enforcing sane standards for the typical imperative patterns used and assuming feasibility of static analysis. Programmer as user just makes sense once you've moved past punch cards to interactive IDEs. Everyone should have stopped using punch cards by now, but lo-and-behold this is still basically the standard in some outfits.
- Joel_Mckay 4y agoIn some remote places... weaving machines still use punch cards, as the factory has run for over a century without electricity. One can never assume our use-case assumptions will generalize. =)
- meltyness 4y agoRight, but they almost certainly have on-hand a skilled reviewer that verifies that good-faith programmers haven't done anything incorrectly that would bork a machine. ... that step wouldn't constitute introducing an abstraction either.
- pclmulqdq 4y agoAbstraction is probably the most expensive (and bug-ridden) thing we do in computing. For OS writers and users, it is not a good idea to add any more abstraction than you absolutely need.
- Dylan16807 4y agoC on a modern compiler is very abstract, and the abstractions are an insecure pain in the ass.
- Joel_Mckay 4y agoAh yes, the infamous gcc -O3 gamble ;)