That's not the post's headline; why did someone cherry pick this subheading? Is this simple clickbaiting?
Peter Naur's view of programming
41–50 of 198 posts
Re: Peter Naur's view of programming
#42“One of the fears from management was that a big company like Google could take our code and build a competing service.” Google, or any other respectable company, would not touch source code without a permissive license with a ten foot pole, least of all if it was retrieved as a result of improper access.
Is Google also out of engineers or something? I would imagine that the important thing about building a competing service isn't understanding the specific implementation, but seeing the value in what the service provides.
True, but the premise of the article and my comment revolves around taking or seeing the code.
Re: Peter Naur's view of programming
#43Earlier quoted context omitted.
Youtube-dl is an app chasing a moving operating of trying to interact with other sites APIs... many of which don't really even want to let youtube-dl do that. Most apps aren't in such a difficult space and keep working basically forever.
> Most apps aren't in such a difficult space and keep working basically forever. Sadly, this doesn't match my experience. Software that isn't actively maintained always dies, sooner or later.
Whether this is true depends on what you do.
The last update to TeX (widely used in math and computer science for typesetting) was 12 January 2014.
A lot of payment processing systems are still running on code written in the 1960s and 1970s. Frequently untouched since Y2K.
I have a friend who went to work in the mid 2000s for a company she had worked for in the early 1970s. Out of curiosity she looked up her old programs. They were still running, unchanged. She asked why and was told, "They never broke."
One of the reasons for the survival of FORTRAN is that there are trusted software packages that people rely on which were written decades ago and still run.
There is an active emulator community for people who want to run games that are decades old, unchanged.
No, your old Netscape browser won't work in the modern web. Nor are early mobile apps going to run. But you'd be amazed at how many places you can find old software still happily running today.
Re: Peter Naur's view of programming
#44Provocative, exaggerated title but a great article.
I would argue that many bodies of source code are worth something even if they were handed to me without any additional info. Let's say I'm working with a new microcontroller and someone gives me the source to a TCP/IP stack for that new micro. From the data sheet of the micro I could make sense of the lower levels of the stack and TCP/IP is so well defined that just the value of someone making it work on the particular hardware, which is mostly busywork, has huge value.
Re: Peter Naur's view of programming
#45_My_ source code is invaluable. It's open, public, free to reuse under the GPL. It's a complete implementation of a painting application used by millions of people. It's a huge amount of knowledge readily accessible. You won't be able to buy something like this for any sum of money, so it's free.
Is it really the source code that has value, or your continued expansion and development of said code? Genuine question. The reason I'm asking, while I was writing the article, I was considering including the youtube-dl fiasco (when the RIAA took it down from GitHub) as an example. People were concerned not because the code was gone (lots of mirrors popped up quickly), but because they were worried that the contribut…
Your youtube-dl example doesn't make sense because youtube-dl wasn't wiped from everyone's computer nor from package managers nor from the internet. So of course losing youtube-dl wasn't the concern.
The thing at threat was the thing the team was using to maintain it, so that's what people were concerned about.
You don't care more about your garage than your house just because you're crying about your garage when a tornado wrecks it but not your house.
Re: Peter Naur's view of programming
#46The point about theory-building requiring (or at least being accelerated by) interpersonal communication / teaching rings very true. In the middle of last year, my team went through a major re-org, and I'm now working with a whole bunch of new teammates. My project didn't get cancelled in the reorg; in fact, it's actually come to more prominence due to synergy in the projects we work on. Essentially my new teammates…
Remote work should help you in this case. Writing and reading are scalable. 1:1’s are not for explaining how stuff works and why. If you don’t write this all down then you are introducing risk and key person dependency.
I think the point that Naur was trying to make is exactly that this process (unfortunately) doesn't scale.
That is my experience at least (even in very well documented projects).
Re: Peter Naur's view of programming
#47Source code of a large monolithic projects(Products) lacks value due not being adaptable or modular, but it has worth that can be decomposed and refactored into other software(libraries/packages/headers/functions).
I'll speak for all the ten-year vets who know stripping a monolith for parts is often as time-consuming as writing from scratch, and always uglier. Software is not a car.
Re: Peter Naur's view of programming
#48The point about theory-building requiring (or at least being accelerated by) interpersonal communication / teaching rings very true. In the middle of last year, my team went through a major re-org, and I'm now working with a whole bunch of new teammates. My project didn't get cancelled in the reorg; in fact, it's actually come to more prominence due to synergy in the projects we work on. Essentially my new teammates…
Remote work should help you in this case. Writing and reading are scalable. 1:1’s are not for explaining how stuff works and why. If you don’t write this all down then you are introducing risk and key person dependency.
It depends on the situation. Documentation and in-person meetings aren't mutually exclusive. A meeting to go through the docs and update them is often very useful.
Not everything has to be "scalable". There are many parts of the code that only 1 or 3 people will ever work on. In fact in most places I'd say that's most of the code.
Re: Peter Naur's view of programming
#49I agree with the conclusions, but the premise that “source code is worthless” is click-baity and misleading.
After having gone through a few M&A discussions with a high-tech software startup this is how I think about it: Nobody wants to buy just the source code. Talent / team that is used to work together and has proven itself has some value (i.e. “talent acquisition”), but valuation won’t be very high. What’s really valuable is talent and code (with IPR rights) combined.
But don’t think you can put the source code on GitHub under an MIT license and it won’t affect your M&A discussion... ;)
Re: Peter Naur's view of programming
#50source code is excrement. an unfortunate side effect necessitated by the immaturity of our tools. someday we'll make software without it and life will be much better for the poo tenders.
I disagree. It’s the offloading of a decision space very carefully explored. Perhaps “language” and “syntax” can be generalized (ie “excrement”), but the ability to offload a decision space about how to react to a given scenario, without requiring someone to be actively thinking about the minutiae of the problem space, will always have value.
Whether that takes the form of a dependency graph in a software application or a set of assumptions (with their corresponding citations) in a scientific journal, the decision tree (inclusive of dependency graph) will always be essential.