3 ms·

There is no purpose of having a so complicated language - like c++ or java - that the majority of the programmers don't even know 100% of the language. I think

by G4BB3R 7y ago

There is no purpose of having a so complicated language - like c++ or java - that the majority of the programmers don't even know 100% of the language. I think Elm (and somehow Go) fits this category, everyone can learn in less than a week every aspect of it. Another benefit of having a very simple language is the compile time, c++ has a awful compile time, 100kloc can take half an hour, in Elm it takes less than 5 seconds (incremental compile) vs 30 seconds (full recompile).

Gibbon1 7y ago
> c++ has a awful compile time I have a thoery that C++ compiler writers obsession with pointless micro optimizations is because C++'s compilation model scales horribly. Thus they desperately want their compiler to be faster. But they are fucked because the more optimizations just slows down the compile times even more.
- pjmlp 7y ago
  Currently if you don't go crazy with meta-programming, it is possible to have C++ applications still compile faster than rustc is capable of. - Use binary libraries (don't build the world from scratch) - Use incremental compilation and linking (yes I know lld support is kind of working on nightly) - Start adopting C++ modules https://devblogs.microsoft.com/cppblog/improved-linker-fundamentals-in-visual-studio-2019/ https://devblogs.microsoft.com/cppblog/improved-linker-funda... https://devblogs.microsoft.com/cppblog/msvc-backend-updates-in-visual-studio-2019-version-16-2/ https://devblogs.microsoft.com/cppblog/msvc-backend-updates-... https://devblogs.microsoft.com/cppblog/introducing-c-build-insights/ https://devblogs.microsoft.com/cppblog/introducing-c-build-i...
- MaxBarraclough 7y ago
  You can disable optimisation if you want faster builds. The existence of optional optimisations isn't a problem.
  - Gibbon1 7y ago
    Of course not the problem is C++ compilation and link model is fundamentally broken from a performance stand point.
    - pjmlp 7y ago
      Hence C++20 modules.
dgb23 7y ago
I agree. Languages like Elm and Go seem much more sane and we'd have to include other very good examples of this like Julia and AWK. They are designed to serve a specific purpose and (try to) make the right trade-offs to achieve that. Because that is what every language has to do. There is always something about a language that is crappy/boring/verbose/difficult/complected. And even with highly extensible languages (Lisp) you are at least forced to be disciplined, which also 'sucks' in a way. Having the right trade-offs/constraints around a purpose/domain opens up many opportunities for optimization of performance, readability, accessibility and so on.
FpUser 7y ago
"There is no purpose of having a so complicated language - like c++ or java" I would not call Java complicated at all. The way they wrote some over-engineered libs for it however is a different story. FactoryFactoryFactory my a$$. I personally do not like Java for performance related reasons and inability to do some lower level tasks but for generic enterprise development those features are not really needed. As for C++ - yes it IS SUPER COMPLICATED . I do not know all of it and do not give a flying hoot about this fact. What good about C++ for me personally is that basic stuff is easy enough to comprehend and I have no problem mostly sticking to C with classes approach. However whenever I feel that I need some exotic "feature" usually I can do a bit of reading and find it. Build time is not great but at least in my cases incremental compile time is fine. My only real problem with C++ is when I need to use some third party piece of code and it is written by some cool person who has decided to write it using every feature of language available and suddenly I can not comprehend what does every second f..ng line mean.
pjmlp 7y ago
While C++ does indeed take lots of time to compile, it is possible to reduce the compilation time quite drastically. - Write modular applications and make use of binary libraries instead of compiling the world from scratch - Enable incremental compilation, incremental linking and pre-compiled headers - Don't go crazy with compile time algorithms / meta-programming
- jstimpfle 7y ago
  Congratulations, I believe you've just described C. Unless you use heap allocated objects with virtual destructors and packed in smart references everywhere. If you don't, headers will just include other headers will include other headers... And you end up waiting for minutes for the rebuild whenever you make one tiny change in one of these headers... But still, moving code from headers to implementation files helps reduce build times. (Very innovative!) Where I work, the stuff I do in C compiles in less than a tenth of the time. And that's compared to MFC-era C++ (C with classes, not C++11).
  - pjmlp 7y ago
    I don't touch C unless obliged to do so.
    - jstimpfle 7y ago
      So, unique_ptrs and virtual destructors everywhere? Or value-type structure embeddings where everything depends on everything else in the public interface? I don't think there's a lot of middle ground.
      - pjmlp 7y ago
        Sensible use of language features, and definitely no use of inherited C unsafety features like manual resource management, unchecked arrays accesses, implicit enum conversations, lack of namespacing, nullable pointers instead of references,...

by G4BB3R 7y ago

Gibbon1 7y ago

> c++ has a awful compile time I have a thoery that C++ compiler writers obsession with pointless micro optimizations is because C++'s compilation model scales horribly. Thus they desperately want their compiler to be faster. But they are fucked because the more optimizations just slows down the compile times even more.

pjmlp 7y ago
Currently if you don't go crazy with meta-programming, it is possible to have C++ applications still compile faster than rustc is capable of. - Use binary libraries (don't build the world from scratch) - Use incremental compilation and linking (yes I know lld support is kind of working on nightly) - Start adopting C++ modules https://devblogs.microsoft.com/cppblog/improved-linker-fundamentals-in-visual-studio-2019/ https://devblogs.microsoft.com/cppblog/improved-linker-funda... https://devblogs.microsoft.com/cppblog/msvc-backend-updates-in-visual-studio-2019-version-16-2/ https://devblogs.microsoft.com/cppblog/msvc-backend-updates-... https://devblogs.microsoft.com/cppblog/introducing-c-build-insights/ https://devblogs.microsoft.com/cppblog/introducing-c-build-i...
MaxBarraclough 7y ago
You can disable optimisation if you want faster builds. The existence of optional optimisations isn't a problem.
- Gibbon1 7y ago
  Of course not the problem is C++ compilation and link model is fundamentally broken from a performance stand point.
  - pjmlp 7y ago
    Hence C++20 modules.

dgb23 7y ago

I agree. Languages like Elm and Go seem much more sane and we'd have to include other very good examples of this like Julia and AWK. They are designed to serve a specific purpose and (try to) make the right trade-offs to achieve that. Because that is what every language has to do. There is always something about a language that is crappy/boring/verbose/difficult/complected. And even with highly extensible languages (Lisp) you are at least forced to be disciplined, which also 'sucks' in a way. Having the right trade-offs/constraints around a purpose/domain opens up many opportunities for optimization of performance, readability, accessibility and so on.

FpUser 7y ago

"There is no purpose of having a so complicated language - like c++ or java" I would not call Java complicated at all. The way they wrote some over-engineered libs for it however is a different story. FactoryFactoryFactory my a$$. I personally do not like Java for performance related reasons and inability to do some lower level tasks but for generic enterprise development those features are not really needed. As for C++ - yes it IS SUPER COMPLICATED . I do not know all of it and do not give a flying hoot about this fact. What good about C++ for me personally is that basic stuff is easy enough to comprehend and I have no problem mostly sticking to C with classes approach. However whenever I feel that I need some exotic "feature" usually I can do a bit of reading and find it. Build time is not great but at least in my cases incremental compile time is fine. My only real problem with C++ is when I need to use some third party piece of code and it is written by some cool person who has decided to write it using every feature of language available and suddenly I can not comprehend what does every second f..ng line mean.

pjmlp 7y ago

While C++ does indeed take lots of time to compile, it is possible to reduce the compilation time quite drastically. - Write modular applications and make use of binary libraries instead of compiling the world from scratch - Enable incremental compilation, incremental linking and pre-compiled headers - Don't go crazy with compile time algorithms / meta-programming

jstimpfle 7y ago
Congratulations, I believe you've just described C. Unless you use heap allocated objects with virtual destructors and packed in smart references everywhere. If you don't, headers will just include other headers will include other headers... And you end up waiting for minutes for the rebuild whenever you make one tiny change in one of these headers... But still, moving code from headers to implementation files helps reduce build times. (Very innovative!) Where I work, the stuff I do in C compiles in less than a tenth of the time. And that's compared to MFC-era C++ (C with classes, not C++11).
- pjmlp 7y ago
  I don't touch C unless obliged to do so.
  - jstimpfle 7y ago
    So, unique_ptrs and virtual destructors everywhere? Or value-type structure embeddings where everything depends on everything else in the public interface? I don't think there's a lot of middle ground.
    - pjmlp 7y ago
      Sensible use of language features, and definitely no use of inherited C unsafety features like manual resource management, unchecked arrays accesses, implicit enum conversations, lack of namespacing, nullable pointers instead of references,...