Python seems fine, except that I can't get comfortable in a language that uses whitespace as part of its syntax.
I know the typical arguments of "linter, etc" but I believe my ruby and JS code, which includes using a linter and formatter, is easy to reason because brackets allow for better mental encapsulation.
All personal experience, I can't speak to the technical differences.
So Ruby using end instead of brackets or white space is one of my favorite features of the language.
No, it doesn't, because written language explicitly marks ends, and sometimes also begginings, of structural units (programming gets brackets from natural language), it doesn't just use white space (until you get to units bigger than sentences.)
Written language does of course use white space to separate words (this was not always the case, see for example classical Latin).
And I think it's fair to say that a line of Python is roughly equivalent to a sentence, and whitespace indentation is only used for syntax at that level.
The analogy breaks down a bit at higher levels, as Python blocks can recurse, but in writing we have structures like chapters, books, etc.
Beginnings are usually more prominent (more whitespace, bigger fonts and different alignment, or introductory sentences with colons for lists), just like in Python.
I am only saying that there's no need to make up arguments against significant-indentation. You can like how it looks or not: that's pretty subjective, though.
The only two objective arguments for either side I can see are:
* Terminating "end" or "}" are superfluous if you are already indenting code.
* Re-indenting a block with no termination indicator can lead to subtle bugs (at least more of them compared to when an indicator for block end is present).
In programming things are frequently nested several levels deep.
This is the key difference that makes a termination character/word important I think.
It's not as common because writing is not all hierarchical all the time (or at least, lots of space would be wasted if entire chapters/sections were indented one level extra), whereas programming is heavily hierarchical with shorter "blocks".
Horizontal indentation is the most common way to express that hierarchy, including in programming languages that use block termination indicators — indentation is used to help humans parse the code, termination indicators are there to help computers parse it.
You are making it sound as if you are not making use of indentation when programming: I thought the only complaint was about it being significant.
If you look at significant whitespace through the lens of developer preference, then sure, it sucks. Where it shines is ensuring code is readable by people other than the guy who likes 320 character long lines, and likes aligning everything to the = sign. The only language I know that is as easy to read as Python is Go, and it does so by forcing developers to use go fmt.
As a regular user the tradeoff pays great dividends every single day in readability for years on end. I would remove more punctuation if I could… every single new feature to Python seems to include colons lately. :-/
No, I don't miss brackets everywhere one bit.
Python, however, does indeed preclude one from using additional signifiers of code structure beyond indentation.
And in practice you don’t type out parentheses. You put in a single opening parentheses and your editor will add the closing parentheses and add the appropriate indentation (and if desired, newlines) for you. In practice the only difference in typing is typing a single ( character vs a single <tab> character.
All that being said, this is the very definition of bike shedding, so it’s really not a factor when picking one language over another.
By "parentheses" do you mean "brackets"? If so, sure, you can use indentation along with brackets, but why am I now using two things? With Python, all I need to do is backspace every once in a while, to signify the end of indentation, which is very easy to do.
I can copy code marked up with parens and brackets from basically any source (no matter how it's indented or how whitespace is handled) and my linter will automatically understand and format it nicely.
In an indentation language - If I copy a chunk of code that's nested more or less deeply than the section I'm currently working on, I have to manually replace whitespace everywhere. Sometimes the linter is smart enough, sometimes it's not.
I actually find Python easier in this regard, even in editors where I have to re-select everything I just pasted.
I choose to believe that this means S-expressions.
The classic example being the arbitrary restrictions on the Python lambda syntax.
Ruby is more orthogonal and systematic. Everything is an object, and you call methods on those objects. And sending a block as a method parameter gives you something that very much resembles functional programming (minus the immutability).
There are a few other constructs (it's not quite so dogmatic about object orientation as Smalltalk), but Ruby is very regular and so you can understand how everything works with a small number of syntactic constructs.
That's actually because Guido thinks multi-line expressions are messy to parse, rather than because they can't be done. Consider:
f = lambda x:
return x + 5
print(sum(map(lambda n, b:
while n:
b.append(n)
n -= 1
return b
, range(3), [[], [], []]), []))
At first I disliked this, but it does nudge you towards readability, which winds up to be a good thing. And if you look at it, there is very little space difference between an unnamed lambda and an embedded function:
def lambda_version():
a = lambda x:
line one
line two # note: this sort-of requires the idea of implicit return, which Python does not have outside of lambda
a()
def named_version():
def lambda_replacement():
line one
return line two
lambda_replacement()This came up nearly 100+ times in those 3 months, just in the classes I TA'd for.
Making invisible characters carry significant meaning really throws non-programmers for a loop at times: It's so easy, right until they break it and don't understand how.
Mis-indented whitespace is not.
if(err) {
console.log('something bad happened')
recover()
continue()
No such luck for
if err
print("something bad happened")
recover()
continue()
Then start worrying about the bad indentation :)
If you're blindly running software that has never been looked at, tested, and even run once to verify it works, the main problem is elsewhere.
I actually strongly disagree with this. There's a reason basically every style guide under the sun defaults to requiring brackets for things like single-line conditionals (where they're optional in a lot of languages): It removes this class of error entirely.
There are lots of other ways to fuck things up with brackets, so no arguments there.
> If you're blindly running software that has never been looked at, tested, and even run once to verify it works, the main problem is elsewhere.
I don't think this is really relevant. In this context - the goal of the student isn't to produce good python code, it's to complete the lab they're working on with their partners. The single biggest case I see where this happens is as follows:
1 - Student A writes some code
2 - Student B writes some code
3 - Student A wants to use what student B wrote
4 - Student A copies the code from student B into their file, but the indentation is wrong.
5 - Student A then starts removing indentation (line by line - which is the real mistake, really) and goes one line too far, or one line too short.
6 - Student A and B test one of the cases for the integrated code (either the success or the failure) and it works fine (in my example, imagine they test the error case and see it does what they expect)
7 - Then later they realize the other case is breaking, but they don't know why: usually because it's been half an hour since they pasted that code into their editor, and checking indentation doesn't immediately come to mind.
8 - I get called over to help
They shouldn't be copy and pasting between each other if they don't understand how indentation works. Basics first.
A good editor can help. Geany is good for beginners and can show whitespace. I also recommend the tool pyflakes to everyone, beginner and expert alike.
With inexperienced programmers like you bring up, if it was mistyped instead:
if(err) {
console.log('something bad happened')
recover()
continue()
Significant indentation can throw someone for a loop in a very narrow set of copy-paste mistakes (i.e. where pasted code is still indented in a way to pass the syntax checks, since you can't mix and match number of spaces in Python either).
Though having good editor support is crucial for programming.
Black can also diagnose/fix some issues.
Let's have it handle tabs or spaces while we're at it. The answer could always be "whatever you prefer".
My kingdom for better tooling!
As long as you don't mix tabs and spaces in the same file python is fine with either.
Even though I fully buy that argument, I still prefer spaces, perhaps for the same reasons I like to format my code myself (vs. auto-formatters). Even software engineers can't be all reasonable all the time :)
There was an article the other day showing how to take latex math notes in neovim the other day. They showed a plugin that displays a render of text on lines that the cursor is not on.
Perhaps there is a way to set that up for languages with brackets? Just show the brackets relevant to that line (and the closing ones perhaps)
It's a complex problem. There is a lot of interesting design space to explore there, but that issue needs a solution.
I think it really helps being able to see the characters properly. (Also helps avoiding mixing tabs and spaces like some bloody animal.)
While there is some value in whitespace-insensitive syntax, I think using whitespace is a neat and human friendly way to keep things separated and to show structure. We are good at spatial thinking
For example this text is using whitespace between words to tell you where which words starts and ends. It uses paragraphs to further split up certain ideas. (Same with math notation which also uses whitespace)
{[Do; you; think; that; this; is; easier; to; read; ?][Does; it; feel; more; comfortable;?]}
Getting used to new syntax is not as hard as people pretend it is. Never understood the aversion of some people. For Python being whitespace sensitive is a great choice as it helps the pseudocode look of it and is often used as a beginner language. You want beginners to learn how to properly indent code and to suffer if they mix tabs and spaces. (Though maybe now that we have automatic code formatting in many languages, maybe less so.)