If you like turtles and programming, you might enjoy hearing about LOGO.
Back in the day, that was the first programming language I was taught. Years and years before I’d learn C or ASM.
You’d give instructions to a “turtle”, moving it about the screen, drawing as it did so. It was a magical experience for 9yo me.
Thank you! I had been picking my memory for this for so long. We too were taught LOGO in school in the early 2000s. I had forgotten the name, I found kturtle after searching about but couldn’t recall what the original program was called.
I was taught it around 1988, most likely on a Thomson MO5 ? Or maybe it was a TO9. It was a while ago :,) I just remember the fascination watching the little pixels color themselves and experimenting with the instructions to see what we could come up with.
So I’m going to say what I always say when people complain about semantic whitespace: Your code should be properly indented anyway. If it’s not, it’s a bad code.
I’m not saying semantic whitespace is superior to brackets or parentheses. It’s clearly not. But it’s not terrible either.
As someone who codes in Python pretty much everyday for years, I NEVER see indentation errors. I didn’t see them back when I started either. Code without indentation is impossible to read for me anyway so it makes zero difference whether the whitespace has semantic meaning or not. It will be there either way.
Python decided to use a single convention (semantic whitespace) instead of two separate ones for machine decodeable scoping and manual/visual scoping. That’s part of Python’s design principle. The program should behave exactly like what people expect it to (without strenuous reasoning exercises).
But some people treat it as the original sin. Not surprised though. I’ve seen developers and engineers nurture weird irrational hatred towards all sorts of conventions. It’s like a phobia.
Similar views about yaml. It may not be the most elegant - it had to be the superset of JSON, after all. But Yaml is a semi-configuration language while JSON is a pure serialization language. Try writing a kubernetes manifest or a compose file in pure JSON without whitespace alignment or comments (which pure JSON doesn’t support anyway). Let’s see how pleasant you find it.
This leads to weird bugs when you change indentation and miss a line or reorder lines. The logic changes. Not too bad when you’re on your own, as Python seems to be intended for. Add multiple developers and git merges and it is a recipe for disaster. With end tags at least you just end up with poorly formatted working code.
It’s probably more prone to mistakes like that, true. But in practice I really never witnessed this actually being a problem. Especially with tests and review.
I don’t get why people hate semantic whitespace. The whitespace would be there anyway, and if anything it’s easier to read as long as you avoid 15 nested if statements, and you’re not using a dynamically typed abomination like python.
S-expressions are a hack because the Lisp devs didn’t know how to make an actual compiler, and instead had the users write the syntax tree for them. (For legal reasons I am being facetious).
In all honesty, I can understand the reason people love s-expressions, but to me they’re just unreadable at a glance.
Semantic whitespace is awful because whitespace (something that you can’t actually see) has meaning in how the program runs. Braces {} for scopes gives you the ability to easily tell at a glance where a scope ends. Whitespace doesn’t allow for that. Especially, especially when you can accidentally exit a scope (two new lines in a row with Python) and it’s not actually an error (Pythons global scope). Yeah formatters and linters make this less of an issue but it sucks… Languages with legible symbols for scoping are significantly easier to reason about, see end symbols in Lua.
S-expressions are a hack because the Lisp devs didn’t know how to make an actual compiler, and instead had the users write the syntax tree for them. (For legal reasons I am being facetious).
McCarthy had planned to develop an automatic Lisp compiler (LISP 2) using M-expressions as the language syntax and S-expressions to describe the compiler’s internal processes. Stephen B. Russell read the paper and suggested to him that S-expressions were a more convenient syntax. Although McCarthy disapproved of the idea, Russell and colleague Daniel J. Edwards hand-coded an interpreter program that could execute S-expressions.[2] This program was adopted by McCarthy’s research group, establishing S-expressions as the dominant form of Lisp.
And for anybody thinking of implementing M-expressions, look at Wolfram Mathematica, which is the only popular M-expression-oriented language. It turns out that high-level graph-rewriting semantics are difficult to make efficient! (If you want to try, you might also want to look at GHC or other efficient graph-rewriters to see what the state of the art is like outside Planet Wolfram.)
I think its type system is “okay”, I mean inherently dynamic typing is pretty error-prone. But its type coercion algorithms are bonkers. Also that whole “NaN ≠ NaN” business…
See that’s one of the parts that is actually almost in line with other languages. In Go, for example, nil ≠ nil because nil is, by definition, undefined. You can’t say whether one thing that you know nothing about is at all like something else that you know nothing about. It really should raise an exception at the attempt to compare NaN though.
IIRC, a nil value can be checked against a literal successfully but not against another nil value. Say you want to check for equality of two vars that could be nil. You just need an extra if statement to ensure that you are not trying to compare nil and nil or nil and a non-nil value (that’ll give you a type error or NPE):
<span style="color:#323232;">var a *string
</span><span style="color:#323232;">var b *string
</span><span style="color:#323232;">
</span><span style="color:#323232;">...
</span><span style="color:#323232;">if a != nil && b != nil {
</span><span style="color:#323232;"> if a == b {
</span><span style="color:#323232;"> fmt.Println("Party!")
</span><span style="color:#323232;"> } else {
</span><span style="color:#323232;"> fmt.Println("Also Party!")
</span><span style="color:#323232;">}
</span>
Kinda. nil is a weird value in Go, not quite the same as null or None in JS and Python, respectively. A nil value may or may not be typed and it may or may not be comparable to similar or different types. There is logical consistency to where these scenarios can be hit but it is pretty convoluted and much safer, with fewer footguns to check for nil values before comparison.
I’m other words, in Go (nil == nil) || (nil != nil), depending on the underlaying types. One can always check if a variable has a nil value but may not be able to compare variables if one or more have a nil value. Therefore, it is best to first check for nil values to protect against errors that failure to execute comparisons might cause (anything from incorrect outcome to panic).
ETA: Here’s some examples
<span style="color:#323232;">// this is always possible for a variable that may have a nil value.
</span><span style="color:#323232;">a != nil || a == nil
</span><span style="color:#323232;">
</span><span style="color:#323232;">a = nil
</span><span style="color:#323232;">b = nil
</span><span style="color:#323232;">// This may or may not be valid, depending on the underlying types.
</span><span style="color:#323232;">a != b || a == b
</span><span style="color:#323232;">
</span><span style="color:#323232;">// Better practice for safety is to check for nil first
</span><span style="color:#323232;">if a != nil && b != nil {
</span><span style="color:#323232;"> if a == b {
</span><span style="color:#323232;"> fmt.Println("equal")
</span><span style="color:#323232;"> } else {
</span><span style="color:#323232;"> fmt.Println("not equal")
</span><span style="color:#323232;"> }
</span><span style="color:#323232;">} else {
</span><span style="color:#323232;"> fmt.Println("a and/or b is nil and may not be comparable")
</span><span style="color:#323232;">}
</span>
Thoroughly confusing lol. I think I need to check the spec in order to grasp this. I feel like this has more to do with the typing system rather than nil itself, maybe. I’ll see.
But yeah, this is nothing like null or undefined in JS, but more similar to NaN.
Yeah… It’s weird but I find it useful that it is, in a weird way. Treating it as an uncertainty means that one MUST explicitly check all pointers for nil as part of normal practice. This avoids NPEs.
OK, that’s excessively “convenient” for booleans. But I don’t get the passionate YAML hate, seems like a simple enough language for config. Didn’t have the pleasure (“pleasure”?) to work with it though, so what’s why else is it shitty?
Do a search for ‘why yaml is bad’ and you’ll get a lot of stories.
Constant passing problems, especially when the yaml gets very large and complex. After I implemented a new feature I was pulled into a call with 12-15 people demanding to know why it didn’t work. The new feature worked fine, The guys yaml had the wrong amount of white space and so it didn’t parse.
White space in the wrong place? Fails Wrong amount of tabs? Fail
Working in a big configuration file that has a lot of nesting? Good luck.
Best part is that most of these things don’t throw errors or anything, it just doesn’t work and you are left scratching your head as to why your deploy only fails in the production environment.
A property can have the wrong indentation and it would still be a syntactically correct yaml. It’s hard to distinguish whether a line is wrongly indented or not. Copy and paste a line and mistakenly use the wrong indentation, and the entire production breaks.
It’s hard to distinguish whether a line is wrongly indented or not.
That’s very much not my experience. I use YAML regularly and while I’ve had copy paste indentation errors when I look at the offending line it’s always obvious to me how to fix the indentation. The only indentation thing that’s ever given me trouble is embedding YAML as a string within a file that uses tabs.
Python, on the other hand, deserves all the hate it gets for making whitespace syntactically significant - I even prefer Go’s hamfisted go fmt approach to a forced syntax to python’s bullshit.
Just put them in separate functions. If you have too many levels of indent, your code is convoluted. Sticking to the line length limit sometimes forces you to write more lines than you’d like to. But it makes everything so much more readable that it’s 100% worth the trade off
It’s quite often I have to second guess whether the code is correctly intended or not. Is this line supposed to be part of this if block or should I remove that extra indentation? It’s not always entirely obvious. Extra troublesome during refactors.
In other languages it’s always obvious when a line is incorrectly indented.
Yeah, it is a completely nonsensical thing to complain about. I hate to go around matching curly brackets like some braindead nematode. If you use more than two levels you should rewrite the code in most cases… just use advanced indexing and vectorization (by pythonic ;p). Or you can loop around like a freaking peasent in your inefficient garbage code that nobody can read because it is cluttered with comments explaining basic stuff. There is a reason Python is popular… and it is not because no one can read it. Same goes for dynamic typing - it is a blessing for most tasks. I do not want to explain to the machine what every temporary variables means…
I agree but still you can oftentimes expect that the average person’s initial reaction to be somehow reluctant… until they understand it. it’s like those foods and drinks that you might need to try a couple times before you start enjoying them.
I hate em cos regardless of language auto formatter takes care of everything. So now im typing extra characters and fucking shit up and confusing myself when moving code between scopes.
In all seriousness, I freely admit that I’m biased towards python because it was my first language and remains my favorite. I use an IDE for anything but the simplest scripts, so I’ve very rarely had any issues with spacing.
programmer_humor
Active
This magazine is from a federated server and may be incomplete. Browse more on the original instance.