Hacker News Reader

Comment by andrehacker | Hacker News Reader

Myeah, C and C++ have the advantage that the compilers support compile for old versions of the language. The languages are in much flux partly because of security problems, partly because features are added from other languages. That means that linking to external libraries using the older language version will fail unless you keep the old version around simply because the maintainer of the external library DID upgrade.

Python is not popular in ML because it is a great language but because of the ecosystem: numpy, pandas, pytorch and everything built on those allows you to do the higher level ML coding without having to reinvent efficient matrix operations for a given hardware infrastructure.

View on HN

>Python is not popular in ML because it is a great language but because of the ecosystem: numpy, pandas, pytorch and everything built on those allows you to do the higher level ML coding without having to reinvent efficient matrix operations for a given hardware infrastructure.

Ecosystems don't poof into existence. There are reasons people chose to write those libraries, sometimes partly or wholly in other languages for python in the first place.

It's not like python was older than or a more prominent language than say C when those libraries began.

(i assume with "The languages are in much flux" you meant python and not c/c++ because these aren't in flux)

Yeah i get why Python is currently used[0] and for a theory-focused book Python would still work to outline the algorithms - worst case you boot up an old version of Python in Docker or a VM, but it'd still require using only what is available out of the box in Python. And depending on how the book is written, it may not even be necessary.

That said there are other alternatives nowadays and when trying to learn the theory you may not need to use the most efficient stuff. Using C, C++, Go, Java, C# or whatever other language with a decent backwards compatibility track record (so that it can work in 5-10 years) should be possible and all of these should have some small (if not necessarily uberefficient) library for the calculations you may want to do that you can distribute alongside the book for those who want to try the code out.

[0] even if i wish people would stick on using it only for the testing/experimentation phase and move to something more robust and future proof for stuff meant to be used by others

"The languages are in much flux" you meant python and not c/c++ because these aren't in flux

No I meant C++.

2011 14882:2011[44] C++11

2014 14882:2014[45] C++14

2017 14882:2017[46] C++17

2020 14882:2020[47] C++20

2024 14882:2024[17] C++23

That is 4 major language changes in 10 years.

As a S/W manager in an enterprise context having to coordinate upgrades of multi-million LOC codebases for mandated security compliance, C++ is not the silver bullet in handling the version problem that exists in every eco system.

As said, the compilers/linkers allow you to run in compatibility mode so as long as you don't care about the new features (and the company you work for doesn't) then, yes, C/C++ is easier for managing legacy code.

These are new features. Many of them are part of the library not the language. Generally speaking what you do is enable the new features in your compiler, you don't need to disable that to compile old code. It's not a problem to work on legacy code and use new features for new code either.

I can show you a 2 year old python program that will fail to work on an existing version of python.

Can you do that with a gcc version?

AFAIK none of this cause existing code to not work.

Scott Myers, author of the extremely popular Effective C++ explainers, gave up on the language because of its churn.

https://www.youtube.com/watch?v=KAWA1DuvCnQ

This video is eleven years old. Contemporary C++ is very nice language, the only thing that I miss is a standalone REPL.

But, I think, current code editors can be viewed as same thing.

C++ has issues with becoming more bloated and complicated but it does not have issues with having existing code breaking due to these changes (aside perhaps some very edgy edge cases).

> That means that linking to external libraries using the older language version will fail unless you keep the old version around simply because the maintainer of the external library DID upgrade.

This just isn’t true. C ABIs has not seen any change with the updated standards and while C++ doesn’t have a stable ABI boundary you shouldn’t have any problem calling older binary interfaces from new code (or new binary interfaces from old code provided you’re not using some new types that just aren’t available). That’s because the standard library authors themselves do strive to guarantee ABI comparability (or at least libc++ and stdlibc++ - I’m not as confident about MSVC but I have to believe this is generally true there too). Indeed the last ABI breakage in c++ was on Linux in C++11 15 years ago because of changes to std::string.

Reply on news.ycombinator.com