Live data from Hacker News

Peter Naur's view of programming

hiringengineersbook.com

181–190 of 198 posts

Re: Peter Naur's view of programming

#181

The 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…

It sounds like the new teammates are too comfortable if their current learning rate is 2-4 years. That number could also be an overestimation, which reinforces the relative rank in the team.

This points to another "field of tension": when the value of the company is in the minds of the programmers (not in the code), how should an organization handle rank such that all team members become stakeholders in the most effective progress?

I suspect more like academic rank rather than "team lead" or "lead dev".

Re: Peter Naur's view of programming

#182
post #171

Earlier quoted context omitted.

Haha I wonder how did you came across this link? This demo website might disappear or at least the pdf might be removed from it. The stable version of this PDF is on my web page here: https://pablo.rauzy.name/dev/naur1985programming.pdf EDIT: to the mods: maybe the link in the parent comment could be updated and my comment deleted? (I am the maintainer of cygale.net — the demo website can be edited by virtually anyon…

I found the link via Google Scholar search = https://scholar.google.com/scholar?q=Programming+as+Theory+B... I was looking for a version of the paper with machine-selectable text (because the PDF linked in the OP is a scan with no OCR).

Okay thanks. I will put a permanent redirect to inform GScholar's index of the actual stable URL of the document. Text selection and accessibility is indeed why I took the time to build this proper PDF as I explained here before seeing your comment: https://news.ycombinator.com/item?id=26035175

Re: Peter Naur's view of programming

#183

I think the author is seriously confused over the value of some crap his startup created in a couple man years vs actual products with market share, long term maintenance and thousands+ of man years of engineering/testing/documentation time. He even admits that they were rewriting large parts of it on a regular basis. That by itself indicates much of the code actually had little value, if the engineers themselves wer…

I think the author makes a great argument, and would add network effects to reasons why code is worthless. Let's say I build an exact clone of Facebook, do I take away any value from Facebook.com? How about Office 365, I offer an exact copy of their cloud, except the sync doesn't work because OneDrive is built into Windows and won't authorize with my clone. I guess before everything sync'd and auth'd to the cloud I c…

(moving the security bits up because I find it dangerous)

And the security argument is a strange one. If you never let the code "mature" then your defect count remains high. Which means there are likely exploits that can be quickly found with simple automated tools, vs being hardened enough that it actually takes real effort to find the ever more obscure cases. Which is why when you look at windows, a lot of the exploits recently are because they churned pieces of the OS that were decades old. And the "unsupported" versions of the OS weren't vulnerable. Similarly, the product I was working on a few years back dodged heartblead for the same reason. We were on a fairly old version of SSL only being patched with security updates. So, when the exploit finally became public we didn't have anything to worry about. Our version of SSL simply wasn't affected.

Its very dangerous to think that the most secure version of a product is the one that isn't battle tested because its being churned. That is just a reformation of the security through obscurity argument and assumes there aren't blackhats more than happy to hack a product and keep quiet about an exploit for years. Combined with the fact that now your hoping to randomly close these exploits through code churn just screams of a naive development model.

(comment on network effects)

I've rarely heard anyone mention any of the recent web based "innovation" as a reason to use photoshop over gimp, or even older versions of photoshop. OTOH, when I heard these discussions in the past, there were real hard reasons people didn't use gimp (color profiles?), libreoffice (document compatibility), etc. So the "innovation" needs to be something the end user finds useful, not just pretty buttons, or software subscription models.

Its obviously not enough to just appear to be a clone, there have to be real reasons to consider an alternative to overcome the network effects. When that happens you can bet people start choosing the "clone", which does in fact devalue the original offering. If a legitimate facebook , O365, etc competitor shows up you can bet people will start to switch even with the network effects of those two products. In the case of photoshop, from what i've heard a lot of people have been looking at Affinity's product. Which points to gimp still not being a proper alternative.

This isn't just software, its everything. Everyone keeps buying x86, until the day it turns out there is a cheaper/faster arm laptop. And it might not even be a change in the products themselves, the US automakers lost out in the 1970's because the market changed and they weren't as well positioned for it.

Re: Peter Naur's view of programming

#184
Had a very similar moment at one of the startups I worked for, which also served as my introduction to a new CEO.

Shortly after NewCEO was hired, we had an all-hands introduction meeting. "All hands" at this point meant about 50 people, so our largest conference room was packed. I ended up sitting on the floor by the big whiteboard, opposite NewCEO. He started talking about how bigger companies were (he believed) actively trying to reverse-engineer our product. Without exactly meaning to, I said "good luck" loudly enough to get his attention, so he looked at me expectantly.

"We're having enough trouble engineering it forwards."

A few people laughed. NewCEO kind of glared. I guess I should mention that I was the product architect BTW. We never particularly got along, but he was neither the first nor the last CEO I outlasted during my career so meh.

Getting back to the point, maybe a competitor who had access to our code might, with great difficulty, learn something about the problem domain we were exploring (continuous data protection). More likely they would have been misled by all the remnants of wrong turns we'd taken during the exploration process. They'd literally be better off without it. Our entire business was a gamble that we could get to market before bigger competitors woke up to the opportunity and threw more bodies/dollars at it. As it turns out, that's exactly what did happen. We lost the bet. Other people having our code would not have changed that outcome one bit.

Re: Peter Naur's view of programming

#185
post #23

Earlier quoted context omitted.

Two more reasons Google doesn't touch others code: 1. They have monorepo with custom build infra, which makes integrating any third_party code pretty hard. 2. In google career culture, one gets promoted for development of something new, not integrating existing proved solutions.

>They have monorepo with custom build infra, which makes integrating any third_party code pretty hard. Why would it be significantly harder than creating new project?

Different company, maybe different problem, but importing code at Facebook was similarly difficult. The build issues were the least of it. More significant by far were the all-but mandatory requirements to integrate with the in-house deployment infrastructure, service discovery, background-task scheduling, metrics, logs, alerts, data structure libraries, RPC framework, etc. Your project already implemented some of those internally, or used open-source alternatives? Too bad. You could keep the core logic, but practically everything about how it connected to the rest of the world would have to be rewritten. Often, it just wasn't worth it, and a new "FB native" service reimplementing the same functionality was easier. If you didn't do it yourself, some other group would constantly be threatening to do it for you. It's hard to focus on code when you continually have to justify your project's very existence.

Re: Peter Naur's view of programming

#186
post #157

Earlier quoted context omitted.

Yes. You'll install a bunch of recent stuff around it. But the heart of it, TeX, is still the same old version.

Old version? You have to understand that some applications need innovation based on new ideas. TeX is only popular in the academic and publishing world, not like a web browser. Can we write a complex equation in TeX as easy as we write in popular word applications like MS Word?

Can we write a complex equation in TeX as easy as we write in popular word applications like MS Word?

Thank you for the most ludicrous comment that I've seen today. The popularity of TeX in academia is exactly because writing complex equations in popular word applications is painfully hard, and the typesetting is poor. By contrast writing them in TeX is easy and the typesetting defaults to excellent.

Talk to anyone who has to actually write many such equations. They will verify that it is not a question of "as easy". It is massively easier and better in TeX. Which is why academics working in math, physics and computer science overwhelmingly choose TeX.

Re: Peter Naur's view of programming

#187
post #186

Earlier quoted context omitted.

Old version? You have to understand that some applications need innovation based on new ideas. TeX is only popular in the academic and publishing world, not like a web browser. Can we write a complex equation in TeX as easy as we write in popular word applications like MS Word?

Can we write a complex equation in TeX as easy as we write in popular word applications like MS Word? Thank you for the most ludicrous comment that I've seen today. The popularity of TeX in academia is exactly because writing complex equations in popular word applications is painfully hard, and the typesetting is poor. By contrast writing them in TeX is easy and the typesetting defaults to excellent. Talk to anyone w…

> It is massively easier and better in TeX.

Obviously depends on where along the learning curve, and preformed command line literacy, which on a venue like HN is always assumed to be native.

As a hypothetical, consider a Rip Van Winkle situation in which a mathematician wakes from a coma he's been in since the 1970s. Now force him to typeset one of his monographs. He'll do it in MS Word.

Re: Peter Naur's view of programming

#188
post #186

Earlier quoted context omitted.

Can we write a complex equation in TeX as easy as we write in popular word applications like MS Word? Thank you for the most ludicrous comment that I've seen today. The popularity of TeX in academia is exactly because writing complex equations in popular word applications is painfully hard, and the typesetting is poor. By contrast writing them in TeX is easy and the typesetting defaults to excellent. Talk to anyone w…

> It is massively easier and better in TeX. Obviously depends on where along the learning curve, and preformed command line literacy, which on a venue like HN is always assumed to be native. As a hypothetical, consider a Rip Van Winkle situation in which a mathematician wakes from a coma he's been in since the 1970s. Now force him to typeset one of his monographs. He'll do it in MS Word.

Obviously depends on where along the learning curve, and preformed command line literacy, which on a venue like HN is always assumed to be native.

Actually not.

As a hypothetical, consider a Rip Van Winkle situation in which a mathematician wakes from a coma he's been in since the 1970s. Now force him to typeset one of his monographs. He'll do it in MS Word.

I have personal experience pertaining to this.

Before I was a programmer, I was a graduate student in mathematics. I wound up in the early 90s having never used Word or TeX and in a position where I needed to type up a paper. I began with Word, and before long I complained about how hard it was. A fellow grad student said I should learn how to do it in TeX.

It was literally faster, *on the very first paper that I tried to type*, to learn TeX and then type my paper in TeX than it was to try to do it in Word. The visual result was also massively better with TeX. Typesetting math formulas in Word is simply that bad.

I've tried to typeset some simple mathematics in Word since. The experience has not materially improved when it comes to typing real mathematics.

Based on this personal experience, I am quite confident that in the Rip Van Winkle situation that you describe, the mathematician will wind up doing it in TeX. And do it the same way that I did. Try Word because that seems easier. Ask a fellow mathematician when that proves to be a terrible experience. Be pointed at TeX and given a few tips. Discover that it is easier.

Re: Peter Naur's view of programming

#189
post #188

Earlier quoted context omitted.

> It is massively easier and better in TeX. Obviously depends on where along the learning curve, and preformed command line literacy, which on a venue like HN is always assumed to be native. As a hypothetical, consider a Rip Van Winkle situation in which a mathematician wakes from a coma he's been in since the 1970s. Now force him to typeset one of his monographs. He'll do it in MS Word.

Obviously depends on where along the learning curve, and preformed command line literacy, which on a venue like HN is always assumed to be native. Actually not. As a hypothetical, consider a Rip Van Winkle situation in which a mathematician wakes from a coma he's been in since the 1970s. Now force him to typeset one of his monographs. He'll do it in MS Word. I have personal experience pertaining to this. Before I was…

Okay, you win. Also: our individual opinions become vanishingly insignificant relative to the aggregate opinion of the market, one that continues to pay for MS Equation Editor.

Re: Peter Naur's view of programming

#190
post #188

Earlier quoted context omitted.

Obviously depends on where along the learning curve, and preformed command line literacy, which on a venue like HN is always assumed to be native. Actually not. As a hypothetical, consider a Rip Van Winkle situation in which a mathematician wakes from a coma he's been in since the 1970s. Now force him to typeset one of his monographs. He'll do it in MS Word. I have personal experience pertaining to this. Before I was…

Okay, you win. Also: our individual opinions become vanishingly insignificant relative to the aggregate opinion of the market, one that continues to pay for MS Equation Editor.

Also: our individual opinions become vanishingly insignificant relative to the aggregate opinion of the market, one that continues to pay for MS Equation Editor.

Actually they don't.

People preferred paying for products like https://www.dessci.com/en/products/mathtype/ which allowed people to type TeX into Microsoft documents than they did Equation Editor. Therefore Microsoft gave up on Equation Editor. They then created an XML-based markup language for math, and MathBuilder around that. Which they then put a TeX translation layer into so that you can type simple TeX in Word, Outlook, and so on, then get a math equation out.

Sadly for Microsoft, they didn't actually remove Equation Editor. I say sadly because they eventually had to. Per https://securityboulevard.com/2018/01/microsoft-kills-old-of... it was found to have a serious security hole, and removing it was easier than fixing it.

Incidentally, despite having both TeX and MathML available to look at, Microsoft failed to turn out something as good as TeX for serious use. As a result most journals will not accept documents produced using Math Builder.

So the aggregate opinion of the market is in. TeX was better than MS Equation Editor. (Which is why TeX outlived MS Equation Editor.)

Post reply on HN