Interesting Links for 29-09-2017

[andrewducker]

The Coming Software Apocalypse

I'm not completely sold by this. There are areas where it definitely makes sense, but I'm not sure how it would fit into a lot of the work I see. But I'm prepared to be convinced.
(tags: software design complexity )

China to shut down North Korean companies

(tags: china NorthKorea )

Edinburgh set for first all-electric buses

(tags: Edinburgh buses transport electricity )

What happened to the improved UK plug?

(tags: uk design electricity )

If you have any interest in Robert Heinlein then you should take a look at this new book on his work

(tags: scifi heinlein )

Brexit: European Parliament to propose Northern Ireland stays in single market

(tags: europe UK NorthernIreland )

In people with OCD, actions are at odds with beliefs

(tags: belief behaviour psychology )

Self-esteem in kids: Lavish praise is not the answer, warmth is

(tags: children parenting )

Floating Point Visually Explained

(tags: numbers mathematics programming computers )

Amazon developing three new sci-fi series: Lazarus, Snow Crash and Ringworld

(tags: Amazon scifi tv )

Does Adding Expensive Housing Help the Little Guy?

(tags: housing economics )

A large chunk of British "exports" are actually people selling gold from London vaults

And because this mostly leaves the EU it distorts our trade balances
(tags: uk gold Europe )

EU justice commissioner resists calls for legislation on online hate speech

(tags: freespeech europe hate )

Comments

[momentsmusicaux]

> What happened to the improved UK plug?

Huh. So actually, genius designer is actually not very good designer who doesn't bother reading the specs and requirements of the thing they are trying to design!

[calimac]

That first article is the only article on software that you've linked to and I have read that I have been able to understand.

I'm interested in its discussion of WYSIWYG. This is now so intuitively obvious in word processors that I wonder how many programmers who postdate its introduction are aware that it once did not exist, or could mentally comprehend an environment in which it did not.

Since I did learn word-processing without it, and lived through its introduction and refinement, I am worried about its use as an example, or perhaps an analogy for, a direct connection between the programmer and the result. Because that's not exactly what WYSIWYG is. The "See" in the name refers to what you see on screen and the "Get" to what you get when you print it out, and the way it worked, at least originally, was not to allow you actually to see what the printed document would look like. No, what it did was to develop a way to mock, to imitate, the printed document on screen. Fonts came in two sets: printer fonts and screen fonts, and the match between them was not always perfect (especially in fussy matters like kerning). At that level of fussiness you were back to the pre-WYSIWYG practice of iterative jumping between adjusting the screen and viewing a printout.

The point is that WYSIWYG didn't actually connect the person with the product. It just modeled it, and models can have flaws. I don't know if the fundamental workings of WYSIWYG have changed since then, or if it's just a smoother modeling, but if the latter there's a danger in relying on the kind of practice of which the author uses WYSIWYG as an example and which is here advocated.

[skington]

WYSIWYG has changed since then. Yes, it used to be that a word processor would generate PostScript output, and that could subtly diverge from what you had on the screen, but these days the computer is in charge of all layout, and generates a dot-perfect image that it sends to the printer.

I think you still have vestiges of the old approach, where you wrote using special command sequences in one window or mode, and then looked at the output in a preview window or mode (or just printed it out), in specialised maths layout software like LaTEX. And of course you have plenty of programmers who are stubborn holdouts; in my industry, the most common programmer's editor is vim, which uses an ultra-simple keyboard-based interface inherited from the 1970s whose fundamental requirement was "let's not involve any modifier keys like control or alt because we can't afford the bandwidth". As a result its learning curve is almost vertical - there are no menus, button bars, tool tips, and there is only grudgingly colour - but there's an almost macho "I learned how to use it, so can you" approach.

(To be fair, a stripped-down editor that you can rely on being installed on pretty much any machine you connect to, and which will work even if bandwidth is limited, is useful if you're regularly in the business of connecting to random servers and doing stuff on them. But that's no reason for you to use something like that as an editor of choice in the comfort of your own desktop or laptop computer.)

[skington]

I have an instinctive wariness when it comes to people saying "if we just use this magic bullet, all our computer problems will be solved!" (With its inherent, implicit, corollary: "you aren't doing these things, therefore you are stupid and wrong".) I remember when the people pushing XML said "all of your systems will be able to talk to each other automatically", and we know how well that went.

So, for instance, the paragraph beginning with "Part of the draw for customers, especially in aviation", describes a waterfall approach, with no automated tests. Maybe you could achieve something similar by implementing a more agile approach to development, and make sure you always had good test coverage? (Obviously for a well-understood industry such as aeronautics you don't want to get too crazy on agile, but there are some techniques that are worth stealing.)

And of course those companies, like car companies, who don't understand yet that they're in the business of writing software, and are cobbling together complicated systems written by the lowest bidder, are in for a world of hurt. But, again, anyone who's been in the industry more than 5 years could have told them that.

People on the cutting edge are just as bad, of course. Front-end Javascript appears to have it particularly bad, with its plethora of flavour-of-the-week frameworks, and language variants which transpile to Javascript; but server-side guys are just as guilty of "hey, check out this cool new thing" syndrome. Now, in some cases they may well be right: certainly let's never code anything in C again, because that way we won't ever have any of the terrible security vulnerabilities that pointer arithmetic and null-terminated strings give you. And the compiler-verified type-safety that many of the functional languages give you is apparently really good, and could avoid many of the problems mentioned in the article. But against that, you have the problem that you then have to reimplement all of the tools the legacy languages have (TLA+ is Java-only, according to a quick skim of Wikipedia), which requires you to realise that those tools were useful. Which, if you're an ambitious 20+ open source guy more prone to just rewriting everything rather than fixing 2+ year-old bugs, you might well not.

[momentsmusicaux]

The other thing about WYSIWYG is that someone's got to code it in the first place.

So the Mario thing looks amazing, and you can code the game in real-time. But someone had to write something to allow you to do that, something that's just as complex as the game itself if not more.

And how do you WYSIWYG *that* software?

[andrewducker]

I don't have a problem with Waterfall - if your requirements are _really_ known up front, and _really_ aren't going to change. Aeronautics may be one of a very limited number of areas where that's true. Maybe.

My understanding is that the answer to "Let's never use C again" is "Rust". But that's just an observation from a distance ;-)

[andrewducker]

Yeah, Vim/Emacs worship is boggling to me. I like things that are rather more fully-functioned. VS Code is my current editor of choice, and that manages to be fast _and_ rather powerful at the same time.

[andrewducker]

Yeah - I'm not sure how you WYSIWYG your way down the chain.

Although "break your code into small bits, and then see what comes out depending on how you tweak what goes in/internal parameters" is a fairly standard part of unit testing/TDD, i's just not as visual.

[momentsmusicaux]

I read somewhere ages ago that it's essential for coding that you see the effect your changes have.
(Eg with web development I am always dumping values of variables to the browser, where I have tools that format them nicely with expandy bits and so on.)
The Mario thing is a particularly nice way to see your changes, but not everything's going to be suited for that.

[skington]

Still my favourite for "no, the 1990s didn't happen" is the people who read and write email in mutt or similar. And then complain about people who send email in only text/html format.

[skington]

That's mostly what I meant when I complained about magic bullets. It sounds like a lot of the problems are about proper software engineering: code reuse, code review, all the sorts of things that frankly we've known about since the 1980s, maybe the 1990s if you think about formalising refactoring and TDD. If the problem is "cars are computers now, and Volkswagen et al don't understand computers" the solution isn't "let's fix computers so they work in cars", it's "let's fix car companies so they understand that they're computer companies now".