Hacker News Reader

Comment by wmanley | Hacker News Reader

I feel like Kay has taken a rather too narrow view of what counts as programming. IMO here are the breakthroughs in the last 20 (ish) years:

1. Stack Overflow - search for your problem, copy and paste the answer.

2. git - Revision control that is low enough overhead that you need to have a reason not to use it.

3. Open-source software as a commodity - Unless you've got very specific requirements there's probably a system that can do most of your heavy lifting. (Almost) no-one writes their own JSON parsers or databases or web frameworks. Using open-source software is low overhead and low risk compared to engaging with some vendor for the same.

4. Package managers - By making it easy to include other peoples code we lower the bar to doing so.

The common thread here is code-reuse. None of the above are programming languages, but all have driven productivity in building systems and solving problems.

View on HN

Code reuse was the holy grail of the 90's. People expected classes to be the unit of code reuse, then enterprise services, then after a dozen years of disillusionment we finally got the recipe right.

We finally got the recipe right?

How? With micro-services? Or Kubernets clusters?

Or copy-paste from SO?

Or is it more about Linux packages? Maybe NPM?

I'm really not sure we've got this right by now.

Actually everything is over and over rewritten. May it be because of the language used, may it be because of frameworks, or architectures.

Polyglot runtimes that could enable true code reuse at least across language boundaries (like GraalVM) are just emerging.

For the higher build blocks though there's still nothing to enable efficient reuse. (People try of course. So mentioning micro-services was no joke actually).

> Stack Overflow

Its blessing and a curse. I think software would be better if coders read mans and other documentation more often (and standards like RFC where it is applicable).

> git - Revision control that is low enough overhead that you need to have a reason not to use it.

RCS - 1982 CVS - 1990

They are limited compare to git, but they perform the main function - track changes in text files allowing to see previous versions, a diff for each change, commit messages. CVS compare to tarballs for each release (or worse to a mess of files .bak, .bak2 e. t. c.) is a breakthrough. Subversion, Mercurial, git is IMHO just evolution of earlier VCS.

> Package managers - By making it easy to include other peoples code we lower the bar to doing so.

CPAN - 1993 FreeBSD pkg_add - 1993

> Open-source software as a commodity

Here I fully agree. Opensource started to get some traction 20ish years ago (probably thanks to more widely available Internet and support from corporations like IBM), but its use is still growing.

When I look back it seems to me that 1990s were very fruitful and the next 20 years progress in software was somewhat slower, but progress in hardware enabled previously impossible stuff without revolutionary changes in software.

The point was that these were either dismissed or weren't considered by Kay when describing breakthroughs in computer programming. They aren't breakthroughs in computer programming languages, but IMO are breakthroughs in computer programming.

> RCS - 1982 CVS - 1990

I don't accept CVS as a breakthrough in the same way as git has been. Back in 2000 - 10 years after CVS - using source control wasn't a given. We had articles like "The Joel Test"[1] encouraging teams to use source control. CVS was a pain to set up and limited once you did. Thanks to git (and DVCS in general) using source control is the default for 1 person throwaway projects up to projects with thousands of contributors and million lines of code.

[1]: https://www.joelonsoftware.com/2000/08/09/the-joel-test-12-s...

SVN fixed a lot of the issues with CVS, FWIW; setup, maintenance, robustness were much improved. But, yes, git was a major breakthrough. Even if you ignore the advantages of a DVCS and git's raw speed, git provides the ability to branch freely, with reasonable confidence that you can merge without spending days reconstructing your divergent source ("merge hell").

> We had articles like "The Joel Test"[1] encouraging teams to use source control.

IMHO source control used more widely nowadays not thanks to git per se, but thanks to availability of free VCS hosting platforms like github.com

Subversion IMHO is more beginner friendly than git, but we AFAIR didn't have good subversion platforms (with cheap of free private repos). Sourceforge added SVN in 2006 (which is late), but sourceforge GUI is an abomination and there are reasons not to trust it: https://en.wikipedia.org/wiki/SourceForge#Controversies

I suspect this has a lot to do with the architecture of git allowing relatively "dumb" servers. To run a git server, you only need the capacity to receive, serve and compare git hashes and blobs.

For SVN at least (last I used it), the server is expected to perform all sorts of potentially expensive operations (esp. for large repos): diffs, merges, branches, etc. since the client does not have the full repo/history. Given at the time computing power was less cheap, it would mean that hosting SVN services incurred a non-trivial cost.

(And IIRC CVS was so bad that I don't think anyone in their right mind should actually try to host a free/cheap service around it.)

Also, initial versions of SVN was released around 2004, while git 1.0 was technically in 2005. It took a while for people to get used to git, but given its technical superiority (and its momentum given Linus' approval) and being less demanding on the server side to host, hosting for git was a correct decision to make anyways.

> I think software would be better if coders read mans and other documentation more often (and standards like RFC where it is applicable).

MAYBE the quality on average would increase, but less software would definitely be created.

YouTube. My son learns a lot of his programming from searching YouTube and watching videos. Doesn't seem like it would be high density, but I'm amazed that there are really good videos/tutorials on pretty obscure topics. And since all YouTube videos have dates, it's actually easier to find current tutorials.

Are those tutorials good because they're videos, or despite being videos? I'm inclined to believe the latter. What sort of content is there in programming lessons that wouldn't be better presented as text?

They are probably better as videos. For example for Roblox Studio, the content in videos is better as it is clear exactly what you need to do.

More importantly the content is easier to produce as a video, which allows a lot more content to be generated.

They are more easily accessible via one interface, instead of sifting through search engine results.

Disclaimer: prefer text myself

I would add: Better, more complete libraries shipping standard with languages.

Reply on news.ycombinator.com