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

[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.)

[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.

[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.

[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]

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]

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".