31–40 of 253 posts
Even so, there is A LOT of software already written in C/C++ that isn't going to be converted any time soon, and if you could tweak the compiler in such a way that makes those programs just 1% better, that is a REALLY BIG THING.
So, good on you Stephen Kell for this constructive paper!
This is another article overanalyzing the success of C, when in fact the reason for the success of C is very simple and obvious: Unix was free and in a lucky position in 1973; Unix got popular; C is the language of Unix; therefore C got popular. There is no inherent benefit in C that, for example, a somewhat modified version of Pascal or Algol wouldn't have inherited. And these kinds of articles always ignore the fac…
I've used both C and Pascal in embedded systems. Pascal is painful compared to C. A "somewhat modified" version might help, but I doubt it would be enough. To steal a phrase from my friend Michael Pavlinch: Pascal was like picking your nose with boxing gloves on. A modified boxing glove isn't really going to solve the problem. For that matter, once we weren't on Unix but rather on the PC, and we had a nicely-modified…
Turbo Pascal was all very well but from Microsoft's point of view it was Not Invented Here.
Earlier quoted context omitted.
I don't "tell" people, what language to use. But I do encourage them to look at new languages, especially ones that fit in the same place as one that they like. I love C. It was my first programming language. I love the syntax, I love the semantics. Years ago, I left it though, because I could deliver higher quality applications with fewer unknown bugs with Java, but I always wanted to find a reason to go back to C.…
When I checked out Rust a year ago, I immediately discovered it has no SIMD (SSE, AVX, Neon). That it has no sane ways to implement a graph structure. Also that it’s hard to compose data structures into higher-level specialized ones. Also, I highly encourage people who worry about pointer management all the time to checkout modern C++.
SIMD in Rust: http://huonw.github.io/blog/2015/08/simd-in-rust/ (yes, still in nightly)
This is another article overanalyzing the success of C, when in fact the reason for the success of C is very simple and obvious: Unix was free and in a lucky position in 1973; Unix got popular; C is the language of Unix; therefore C got popular. There is no inherent benefit in C that, for example, a somewhat modified version of Pascal or Algol wouldn't have inherited. And these kinds of articles always ignore the fac…
> For better or worse (personally, I think, for the better), they're starting with JavaScript, Python, Ruby, or even PHP. These higher level languages are still built with C(Python,PHP) or C++(V8 Javascript engine) though, so C is still a language of choice for that task, and writing a library in C allows integration with all these high level languages at very little cost. So there is still incentive for people using…
I'm not saying there is no reason for anybody to learn C, just that most programmers aren't learning C anymore.
Earlier quoted context omitted.
Notice that "scoff at" turned to "frown upon" here, but same difference. I like Rust, but the kind of attitude you've shown in this comment is a) distressingly common among Rustaceans, and b) makes everyone in the embedded world who would like to get away from C/C++ keep the whole Rust ecosystem at arms-length.
Scoff: speak to someone or about something in a scornfully derisive or mocking way. Frown: furrow one's brow in an expression of disapproval, displeasure, or concentration. Those are definitely not the same thing. Language is deliberate. I'd prefer it if you don't change mine to mean something I do not. I frown at a lot of things in software I review, then someone explains to me why they decided to do something the w…
This is a long paper and the author has 2 main claims: 1) C Language popularity is more to do with cognitive ease of memory addresses as a conceptual model for inspection and change. Author claims memory address mental model overshadows runtime performance . 2) switching to "safe" languages like Java/C#/Rust is not necessary. With no changes/violations to existing C Language specification, a new/different implementat…
Of course there's always the subjective "everything looks like a nail" usage as well, which makes every problem seem like a pointer problem because you've never tried to think of them as anything other than a pointer problem. I'm sure you could cater to that usage with a proper runtime but really, it doesn't hurt to try new things sometimes...
This is a long paper and the author has 2 main claims: 1) C Language popularity is more to do with cognitive ease of memory addresses as a conceptual model for inspection and change. Author claims memory address mental model overshadows runtime performance . 2) switching to "safe" languages like Java/C#/Rust is not necessary. With no changes/violations to existing C Language specification, a new/different implementat…
Nim seems to be trying to fit that space.
Here's a good quote: "Unless we can understand the real reasons programmers continue to use C, we risk researchers continuing to solve a set of problems that is incomplete and/or irrelevant, while practitioners continue to use flawed tools." In other words, stop blithely claiming that everyone is stupid for using C/C++. Instead, find out why they use it . Then, if you continue to think that C/C++ needs to be replaced…
C is frequently praised (including in some of the posts here) for its suitability for real-time and embedded systems development, but the author appears to be proposing modifying the C runtime and code generation in ways that, when done in other languages, are claimed to render them unsuitable for these purposes. I think researchers are justified in looking for solutions for common problems, even if many C programmer…
Don't people think there are things C could improve that wouldn't affect its suitability for these tasks? I mean getting namespaces doesn't strike me as being an hindrance for real-time systems for instance. A boolean type and true|false as keywords instead of macros? tagged unions? multiple return types to deal with errors more easily? more facilities in the language in general to avoid the use of macros to make up for its lack of polymorphism? to me macros always felt like a lazy cop-out.
This is another article overanalyzing the success of C, when in fact the reason for the success of C is very simple and obvious: Unix was free and in a lucky position in 1973; Unix got popular; C is the language of Unix; therefore C got popular. There is no inherent benefit in C that, for example, a somewhat modified version of Pascal or Algol wouldn't have inherited. And these kinds of articles always ignore the fac…
I've used both C and Pascal in embedded systems. Pascal is painful compared to C. A "somewhat modified" version might help, but I doubt it would be enough. To steal a phrase from my friend Michael Pavlinch: Pascal was like picking your nose with boxing gloves on. A modified boxing glove isn't really going to solve the problem. For that matter, once we weren't on Unix but rather on the PC, and we had a nicely-modified…
Turbo Pascal was quite successful in its day. But Microsoft chose C, and the rest is history. Absent Microsoft's decision, Pascal might still be around.
If you look at early Mac development, for instance, Pascal was actually preferred. C only ended up winning due to being better known, which was a result of the critical mass of programmers trained on Unix and Microsoft's offerings.