When you justify text for print, you almost always have to manually tweak the result to avoid wrong spacing, bad hyphenation, rivers, ...
Justified text and automatic layout do not (yet) go hand in hand.
Left aligned text has also its issues but, most of the time you won't notice them on screen.
The article you're linking looks better than average, but it feels a bit too much like a text wall to my eyes...
I guess that the lines contain a number of characters and words that is big enough to allow a more even distribution, at the price of longer lines that are less comfortable to read.
For me the rule is still that text that is automatically formatted should be mostly left aligned.
But indeed, if you correctly setup the hyphenation, you can produce something that is somehow OK.
I suspect the wall-of-text effect isn’t caused by justification. Gwern is using first-line indents to signal a new paragraph instead of spacing them, as is more usual on the web.
In my eyes, vi is ok for system administration, but not for programming.
The differences are not huge, but even if I have a "small" .vimrc with one single plugin, I have issues using the vim.tiny installed on Debian by default.
- a real undo
- buffers
- macros (recorded on the fly with ththe q key)
- visual mode (included the block selection mode)
- text completion (ctrl-p, ctrl-x-f)
- automatic indenting
- advanced text objects (selecting everyting between '()')
Not having one single of them would not hinder me much... but all of them at once: that hurts!
My personal answer: I'm touch typing. I can do so without looking at the screen. While I'm typing, I can think of what I want to say next. At least to some degree.
Vim helps me to stay focused, to stick to my thoughts instead of having to work with the IDE/editor.
I don't have to select a word, by detecting its boundaries (or point to it and double click), delete it and type an new word.
ciwnew word^
what looks like random chars is almost a reflex, when you get the Vim "grammar".
(of course, you can do it with any editor: ctrl-left, ctrl-shift-right, delete, "new word".)
So, yes, you're 100% right: programming is no about typing. And Vim helps me to care even less about typing the code.
one thought: after having read your introduction for the teachers, i wonder why you did not "sort it" the other way round: first the hands on and the tutorials and then the theory...
we suggest the kids to first do the pong game in scratch (we have a booklet with step by step instructions) and then use the set of cards (in order) to do the same.
we try to avoid that they just copy the snippets line by line, without thinking at what they are doing...
i will now give them a link to your book when they want to learn about python!
i really liked it, but i don't consider it a mature product i would use "in production".
because of our approach, we can't really adopt it until it's natively supported by a "package" like mu-editor or thonny
my conclusion was:
as a "senior" programmer, who grew up with procedural programming, i'm still "scared" about relying on annotations and async programming.
but, for kids coming from scratch and without much other experiences, i'm not sure that it will be a big stumbling stone.
they will simply "learn" it in a different way: at the beginning, programming is (mostly) black magic anyway : - )
it might be even easier for them to use play, than relying on the magic update() and draw() functions...
(and, no, i don't think it makes a big difference to call those function from a main loop like in pygame or having them implicit like in pygame zero)
probably, the biggest issue would be that the founding blocks of play do not match what the kids will learn in most python tutorials and books (they probably won't find any reference to async or annotations in most programming books for kids or even for beginners!)
all in all: i like play and i think it could be a good match if the focus is more on computer science topics...
in our case, the focus is on the kids having a good time on sunday afternoons and getting them to learn to be an (active) actor in front of their computer, not just a (passive) consumer. we are not too picky about the concepts : - )
in my experience, pygame zero works well with 10 - 14 year kids.
i run a coderdojo and we have developed a system of cards that helps the kids creating a pong game with pygame zero.
in two hours of our weekly meeting, they manage to
- install the mu editor,
- create the game window
- download an image from the internet,
- put it in their game
- move the image around with the arrow keys
mostly by themselves.
loading the image is indeed one of the big issues they often face.
but i'm convinced that it will often be an issue anyway: kids need some mentoring there.
(really, you cannot rely on the fact that they will be typing the file name correctly or that they will put the image in a specific directory, with the right extension).
this having been said, writing a full pong is much harder as in scratch.
they do need some real mentoring for the further steps.
concerning your suggestion with yeso: for our setup, providing an image through the command line is probably not an improvement.
most of our kids are using windows or mac and we avoid forcing them to use the terminal during their first steps of "creating a game with real programming".
Are you saying that writing a full Pong in Pygame Zero is much harder than in Scratch? I'm not sure what you mean by "harder as in scratch".
I was pretty impressed with the Pong game in 5'30" in https://www.youtube.com/watch?v=KoWqdEACyLI when I first watched it, but I suspect it might be pretty intimidating for a total newcomer.
And, yeah, I wasn't suggesting that you should pass filenames on the command line to simplify debugging. It's just that that program is an image viewer, not a game, so taking the filename on the command line is what it does. If you hardcode the filename and rely on CPython's prompt finalization, you can reduce the program to four lines, which is less even than PyGame:
#!/usr/bin/python
from yeso import *
w = Window('hello, world', (406, 220))
w.frame().copy(read_png('admu_shell.png'))
while True: w.wait()
- a pong in 5'30"... of course, but his real tutorial is 3 hours : - ) ... and that pong game does much more than what our kids can achieve...
- our kids debugging skills are often very limited (both in skills and patience)... correctly matching the filename and the actor is a good example for learning the debugging but it's often already too much: they just want to see it work!)
Left aligned text has also its issues but, most of the time you won't notice them on screen.
The article you're linking looks better than average, but it feels a bit too much like a text wall to my eyes... I guess that the lines contain a number of characters and words that is big enough to allow a more even distribution, at the price of longer lines that are less comfortable to read.
For me the rule is still that text that is automatically formatted should be mostly left aligned. But indeed, if you correctly setup the hyphenation, you can produce something that is somehow OK.