101–110 of 146 posts
Earlier quoted context omitted.
In most European universities CS and Engineering are intermingled. Pure CS theory tends to be a maths major.
> In most European universities CS and Engineering are intermingled. Not at the time, when CS didn't even exist in many European universities, or was rudimentary at best.
Earlier quoted context omitted.
Counterpoint, Rust is actually easier to learn, and take way less time from inception to writing production-ready code.
even the tutorial says that borrowing has a high learning curve
Earlier quoted context omitted.
The problems with modules is not getting the system right, the module proposal owners are well aware how to do it. The problem was the politcal wars of tons of companies that don't want to let go of their in-house build systems based on translation units just to make use of modules. So the end result is a compromise to make some of those big names happy.
Can you give a specific example of something which was "bent up" from its more appropriate standardization to placate those large companies?
Which also brings their macros into scope.
Earlier quoted context omitted.
On single developer projects as long as one doesn't stay too much away from them, scale it up to multiple sized distributed teams, add binary libraries, and you end up with double frees, leaks and ownership issues all over the place.
Of course there will always be some issues somewhere. But, ignoring perfect memory safety, the issues are widely overblown, to the extent that I find manually managing memory a lot easier than dealing with GC once a project grows beyond a couple KLOC. It's all about proper planning and code organization. Use pooling, central manager structures, etc. If it can be avoided, then do not allocate and free stuff in a singl…
That doesn't work in enterprise projects with heavy dosis of consulting.
Earlier quoted context omitted.
Plenty of GC enabled system languages have proven their value, up to building full stack graphical workstations, so far they just lacked somg big corp political and monetary willingness to push them down the anti-GC devs no matter what. Thanfully with the likes of Swift on iDevices, Java/Kotlin on Android (with an increasingly constrained NDK), COM/UWP über alles + .NET on Windows, ChromeOS + gVisor, Unreal + GCed C+…
Swift's GC is really a lot closer to modern C++ style memory management than the other languages you mentioned. If you use RAII & shared_ptr in C++ you are using the exact same techniques that Swift's "GC" uses.
As someone who had spent quite some time developing C++ refactoring tools, here's the most concise example of the problem: void func() { a d; } If a is a class template, the line in func() declares an instance of type "a ". If a is a global variable, it describes an invocation of the " " operators for 4 different variables. Maintaining a parse tree of this is a massive mess, especially if func() is a template itself…
Can we design a language (cpp-prime?) that is basically c++ but makes parsing easier? I'm thinking reduce the keyword reuse, use different symbols for multiplication and pointers etc. The code would be easy for c++ developers to read and converting between the two could be automatic. However, we would be able to build tooling for this new language much more easily. It would also compile quicker.
There are been hundreds of attempts using a number of different ideas. The reason for C++ and not those alternatives is there is a lot of C++ code. If most of my code is C++ I don't gain anything from your new language as I spend most of my time maintaining old code. Even if I use your language for new code that means I constantly have to remember if I'm fixing a bug using C++ code rules or the new language rules. So…
I, for one, find different languages with similar appearance needlessly confusing. I what the experience with different syntaxes for the same language would be.
Earlier quoted context omitted.
> I give it about 10 years time, for pure manual memory management to be like Assembly and embedded development. For someone who has spent some time thinking about memory management strategies, manual MM isn't actually that much additional work. By far, most code doesn't allocate or free (and that's a good thing). So MM->GC is hardly like Assembly->Compiler. In Assembly you're constantly allocating and pigeonholing,…
> By far, most code doesn't allocate or free (and that's a good thing). Depends on the code you write. If, like in C++, non-stack memory management is painful, programmers tend to react like you suggest. In pure-by-default languages, you are creating new and destroying old objects all the time. (At least conceptually. A sufficiently smart compiler can eliminate most of that.)
Earlier quoted context omitted.
Rust seems to be the most successful zero-overhead language competitor to C++, though it's far not as mature as C++ yet.
Rust has a high learning curve (borrowing, etc). Rust is a competitor to ADA, not C++. You can certainly ask developers to write things in rust instead, and even progressively rewrite codebase in rust since it's compatible with C++, but a language is about adopters, and ease of learning for beginners and students.
Can we design a language (cpp-prime?) that is basically c++ but makes parsing easier? I'm thinking reduce the keyword reuse, use different symbols for multiplication and pointers etc. The code would be easy for c++ developers to read and converting between the two could be automatic. However, we would be able to build tooling for this new language much more easily. It would also compile quicker.
There's not really a need anymore, because LibClang[1] has solved the parsing problem. Historically it was really hard to write tooling (syntax highlighters, static analyzers, scripts to update build dependendencies, etc.) for C++ due to the difficulty of parsing the language. In the past several years, that has completely changed - you just call LibClang to handle the parsing for you, and work with the high-level ab…