101–110 of 165 posts
Earlier quoted context omitted.
[flagged]
Ah yes, the 10th most popular general purpose programming language in the world is a meme language. Facepalm. I know you'll ask for a source on that so: https://www.jetbrains.com/lp/devecosystem-2024/ Excluding HTML, CSS, Shell and SQL because they aren't general purpose programming languages. Excluding Typescript because it's really just type annotations for JavaScript.
Yeah
Earlier quoted context omitted.
UB has nothing to do with complexity. In any case, from about 87 UB in the core language, we eliminated 15 in the last meeting, and already have concrete proposals for 10 more. C2Y will likely not have any trivial UB and hopefully also optional safety modes that eliminate the others.
It certainly has, as proven by recent talk at BlueHat 2024, on Windows kernel refactorings, as not everyone is knowledgeable of ISO C minutia and how optimisers take advantage of it, and still think they know better than analysers.
Earlier quoted context omitted.
Eh, when you're hacking away as a solo developer on something big and new I don't think this matters at all. In my current project I did about 200x commits marked "wip" before having enough structure and stability to bother with proper commit messages. Whatever lets you be productive until more structure is helpful.
Perhaps, but I still think it is lazy. A very nice counter example of someone with high commit standards can be seen in this repository: https://github.com/rmyorston/pdpmake/commits/master/
Earlier quoted context omitted.
Eh, when you're hacking away as a solo developer on something big and new I don't think this matters at all. In my current project I did about 200x commits marked "wip" before having enough structure and stability to bother with proper commit messages. Whatever lets you be productive until more structure is helpful.
Perhaps, but I still think it is lazy. A very nice counter example of someone with high commit standards can be seen in this repository: https://github.com/rmyorston/pdpmake/commits/master/
The efficient alternative, which I’ve seen used a few times in these cases, is to retcon a high-quality fake history into the source tree after the design has stabilized. This has proven to be far more useful to other engineers than the true history in cases like this.
Incremental commits are nice but not all types of software development lends itself to that, especially early in the development process. I’ve seen multiple cases where trying to force tidy incremental commit histories early in the process produced significantly worse outcomes than they needed to be.
Earlier quoted context omitted.
While it has its fair share of quirks it is certainly not an "ultra-complex" language.
The sleight of hand here is that by leaving so many things undefined, unspecified, and implementation-defined, C gets to foist complexity off on the implementations and then act as though it's absolved of blame when things go off the rails. The fact that what felt like half of all traffic on Usenet and IRC in the 90s was comprised of people language-lawyering over what is and is not valid C disqualifies it from being…
Earlier quoted context omitted.
Not really. In the initial phase of a project there is usually so much churn than enforcing proper commit messages is not worth it, until the dust settle down.
I massively disagree. It would have taken the author approximately 1 minute to write the following high quality hack-n-slash commit message: ``` Big rewrites * Rewrote X * Deleted Y * Refactored Z ``` Done
Earlier quoted context omitted.
The sleight of hand here is that by leaving so many things undefined, unspecified, and implementation-defined, C gets to foist complexity off on the implementations and then act as though it's absolved of blame when things go off the rails. The fact that what felt like half of all traffic on Usenet and IRC in the 90s was comprised of people language-lawyering over what is and is not valid C disqualifies it from being…
I write C every day and wrote C compiler. I know all all the issues it has very well, but it still a relatively simple language. It also not that difficult to parse. The lexer hack is interesting, because you can almost get away with using a context-free lexer, but you need this one hack. But this is not really a problem. People failing to read c declarations is also not the same thing as complexity, although I would…
I’m definitely happy to see this happening. But I would like to point out two ingredients that constitute LLVM’s success beyond academic merits: License and modularity. I’m not a lawyer so can’t say much about the first one, all I can say is that I believe license is one of the main reasons Apple switched to LLVM decades ago. Modularity, on the other hand, is one of the most crucial features of LLVM and something GCC…
Earlier quoted context omitted.
I wonder if this question can attract any MLIR people to answer my question: From Chris Lattner's descriptions of LLVM vs MLIR in various podcasts, it seems like LLVM is often used as a backend for MLIR, but only because so much work has been put into optimizing in LLVM. It also seems like MLIR is strictly a superset of LLVM in terms of capabilities. Here's my question: It seems inevitable that people will eventually…
All the important bits of MLIR are closed source and there’s no indication that’ll change anytime soon. The big players have their own frontend, dialects, and mostly use LLVM backends. There’s very little common usable infrastructure that is upstreamed. Some of the upstreamed bits are missing large pieces.
Hmm I wonder what all that stuff is then that's under mlir/lib?
Like what are you even talking about? First of all there are literally three upstream frontends (flang, ClangIR, and torch-mlir). Most people use PyTorch as a frontend (some people use Jax or Triton). Secondly, downstream users having their own dialects... is basically the whole point of MLIR. Core dialects like linalg, tensor, memref, arith are absolutely generically useful. In addition many (not all) MLIR-based production quality compilers are fully open source (IREE, Triton) even if wholly developed at a for-profit.
Again, somebody who comes to the realization something is seriously wrong with ultra-complex languages in the SDK (c++ and similar). In other words, since this alternative LLVM is coded in plain and simple C, it is shielded against those who are still not seeing that computer languages with an ultra complex syntax are not the right way to go if if want sane software. You also have QBE, which with cproc will give you…
C itself is an ultra-complex language. I do not understand the mindset of the "C is simple" crowd. Is it nostalgia or romanticism for the past? If we want to devise a truly simple language, we need to start by realizing that C is just the Javascript of its day: hacked together in a weekend by someone who wished they were using a different language and then accidentally catapulted into the future by platform effects.
C99+ is just the less worse compromise.