71–80 of 146 posts
Earlier quoted context omitted.
Plenty did but none took a chunk out the C++ world that thrives on manual memory mgmt.
The C++ world that thrives on manual memory management is usually "C compiled with C++ compilers". The rest of the C++ world has long moved into automatic memory management as best practices.
Earlier quoted context omitted.
> Sure it is! A reputable CS degree will cover multiple programming languages and compiler implementation. Which is neither here, nor there. A reputable CS degree is an all rounder, it's not expertise in PL design and research. > I don’t think you could study just “compilers”, say, at undergrad level. Maybe you mean postgrad or postdoc-level qualifications? For starters, yes, but it's not about official qualification…
In most European universities CS and Engineering are intermingled. Pure CS theory tends to be a maths major.
Not at the time, when CS didn't even exist in many European universities, or was rudimentary at best.
Why shouldn't C++ templates be Turing-complete? Template metaprogramming is a great strength of C++. The language is gross but the result is quite powerful.
I don’t think it was designed to be Turing-complete, so it’s a lot more annoying than it could be when you try to use it this way.
Earlier quoted context omitted.
Building a GC into your system means building nondeterministic amounts of latency into it. Those "full stack graphical workstations" were notorious for being slow, expensive, and coming to a dead halt whenever the heap filled up. Thankfully, we have RAII as in C++ and Rust and ARC in Swift, which give you automatic memory management without a tracing GC. If your language requires a GC, it is a complete failure as a s…
Well, GC latencies don't bother game developers who work with Unity or people using Java or C# for high speed trading. Realistically, having the option to use a GC is a boon for many applications. Not everything is hard realtime all the time. Some complex applications tend to have a hard realtime part and parts where it doesn't matter. E.g. a CNC machine controller does not need a guaranteed response time for the HMI…
GC is very useful for programs that don't have any form of real time - but games are real time and thus you need to be careful to ensure that the worst case of the garbage collector doesn't harm you. Reference counted garbage collection gives you this easier than the other means. Note that I said worst case - the average case of garbage collection is better in most garbage collected languages.
Earlier quoted context omitted.
Java has generics and overloading; how far can you realistically get before building a full frontend? Honest question.
Java generics are just syntactic sugar for Object, so not a problem at all since you can't do anything with them. Java overloading is simple since all functions are in the same file (so doesn't change overload behavior depending on which files are imported) and Java lacks the user type casts C++ has, so just pick the signature fitting all provided values (with numeric casts) or throw.
Only if you do not have a concrete boundary in the generic declaration, T extends Foo can result in a function definition that takes a Foo instead of an Object.
> Java overloading is simple since all functions are in the same file (so doesn't change overload behavior depending on which files are imported)
import static java.lang.Math.*; for programmers too lazy to write Math.sin instead of sin.
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.
Earlier quoted context omitted.
The C++ world that thrives on manual memory management is usually "C compiled with C++ compilers". The rest of the C++ world has long moved into automatic memory management as best practices.
I don't think that your statement about C with C++ compilers holds true anymore. I have seen quite a few codebases that are definitely C++, but use bespoke memory management strategies where required. Pool allocators and allocation-only heaps are high on the list of things that are useful in this area, for various reasons.
Earlier quoted context omitted.
"Formal education in CS" is not the same as, say, a degree related to programming languages or compilers.
Sure it is! A reputable CS degree will cover multiple programming languages and compiler implementation. I don’t think you could study just “compilers”, say, at undergrad level. Maybe you mean postgrad or postdoc-level qualifications? It would certainly be a pretty different world if you were only allowed to design a new programming language after getting your PhD in language design.
An undergraduate degree in physics covers building nuclear reactors too. For obvious reasons we don't let undergrads design them.
This is one of the major issues with these languages that were initially designed by amateurs (I mean that in the positive sense, someone who does something because they care about it, and not because they are paid to do it). Often they simply did not see the long-term benefit of adhering to the limits of a "standard" architecture (i.e., context-free, unambiguous grammar, decidable static analysis (lookup!), multi-pa…
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.
> In practice, compilers limit template instantiation depth, so this is more of a theoretical problem than a practical one.