Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

"Software Build Processes" is now a field in its own right. There's not just a compiler. There's a build process, a dependency manager, a package manager, a source control system, tools for updating the files those use, etc. It used to be just "make", but now each language has some kind of package management system. Crates, wheels, eggs, containers, boxes inside of boxes - it's complicated.

This is all trade-school stuff, really. It's like learning how to wire electric power, with wire size, type, and color rules, fixtures, grounding, and in the US per the National Electrical Code. There's little academic content there; it's just a mass of detail. Not too hard if it's written down and the documentation is current. Which it won't be at many companies.

An argument against teaching the details in college is that students will need to know the one they're using in great detail. Knowledge about unrelated build systems doesn't transfer much.

Then there's the machine learning parallel universe, with notebooks and YAML.



I disagree that knowledge doesn’t transfer much. The commands don’t but the concepts do. I cut my teeth on Maven, then later was able to pick up a JavaScrip build system, and lately had to pick up a SBT. And I think my knowledge or at least wisdom has compounded. And those previous battles seem to have given me an upper hand or context that other coworkers sometimes lack.


I basically agree with this. This is why, at the end of the post, I recommend Python in a Ubuntu environment, where the "build process" is a single step (`python my_program.py`), and packages can generally be managed with `apt`, which is a standard tool representative of a large class of tools, which are likely to be used at some point by a large fraction of CS students.


I think Python builds have gotten nearly as confusing as Java builds (judging by how every Python project these days wants me to use virtualenv).


Yes, virtualenv. A few years ago, I said that "version pinning" was not going to end well, because it would reduce the pressure on library developers to maintain backwards compatibility. Now something equivalent to version pinning is everywhere. Moving forward is tough when, three levels down, some package wants an obsolete version of some other package.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: