Slashdot Mirror
A New Programming Language Expands on Google's Go (infoworld.com)
"One sure sign your language is successful: When people build other languages that transpile into it." An anonymous Slashdot reader quotes a report from InfoWorld:
The Have project uses Go's toolchain, but sports a different syntax and makes key additions to the language... Previously, a language named Oden worked with Go's toolchain to add features that Go didn't support. Now Polish developer Marcin Wrochniak has introduced Have, a language that transpiles to and expands on Go.
In the blog post that introduces the project to Go developers, Wrochniak describes Have as a hobby project, with the goal of becoming a "companion" to Go that addresses some of its common "landmines"... Go uses curly braces in the manner of C/C++, while Have uses block indents, like Python... The way that variable declaration, structs, and interfaces work have all been modified in Have to be more consistent with each other and to avoid internal inconsistencies that Wrochniak feels are a common source of bugs.
In the blog post that introduces the project to Go developers, Wrochniak describes Have as a hobby project, with the goal of becoming a "companion" to Go that addresses some of its common "landmines"... Go uses curly braces in the manner of C/C++, while Have uses block indents, like Python... The way that variable declaration, structs, and interfaces work have all been modified in Have to be more consistent with each other and to avoid internal inconsistencies that Wrochniak feels are a common source of bugs.
We need at least five new programming languages per year because C++ simply doesn't do the job. C++ doesn't even have a code of conduct! How am I supposed to know what to do if somebody takes offence at my code?
I'm glad to hear they got rid of the curly braces and copied Python. It's a truly excellent idea to have indentation determine program flow. I think this could be extended further and have program flow dictated by the font you use in your editor. Arial instead of if statements, Comic Sans instead of for loops, etc.
Anyway, I'm really happy to see programming languages going the same way as user interface designs, with people desperate to throw away what works and replace it with something inferior because they believe they're innovative and creative. Maybe we could do the same with cars next; I've always thought steering wheels where a stupid idea and you could steer far more easily with a system of cogs and pulleys.
Please, for the love of the children, can we STOP innovating on curly braces already.
And here I was all pumped up about the Erlang to Elixir upgrade path, repeated for Go, which suffers from the same weird Erlang-like conservatism that isn't suitable for all needs (such as most projects by corporations employing fewer than 20,000 technologists).
Conservatism has its uses, but it's no silver bullet, nor can removing braces make it so.
"Curly" braces to denote blocks of code and semi colons to denote end of statement are the marks of a sane language.
Anything else just asks for subtle bugs.
40 years programming experience has taught me this but if you want to find this out for yourself carry on :)
You could do something like Ada does where it has a closing block construct.
For example, loop blocks have an opening "loop" statement and a closing "end loop" statement.
This.
I love Python but I fucking can't stand the lack of curly braces.
You can tell how powerful someone is by the magnitude of the crime they can commit and be able to get away with.
Love the name. Especially I love trying to find any information on this bloody language:
* have tutorial
* have language tutorial
* have programming language tutorial
* have to go transpiler
* how to program in have
* have wiki
Next up, a webserver written in have called "the", a debugger for the language called "how", and IDE for it named "it" -- "debugging the with how in it".
GoToo? GoTwo?
Indentation is the strongest indicator of block structure to the people reading and writing the code, but the toolchain uses a *different* set of indicators (the braces and semicolons). Any person who is looking at code - especially just quickly scanning code - is going to rely on the indentation to denote blocks first, and then to a lesser degree things like curly braces - the spacing and positioning are simply stronger visual cues.
In most languages, this is what can lead to a few types of subtle bugs, e.g.
if (x y);
doSomething();
Python's stance is that the humans and the tools should use the same block identifiers. Sure there are other ways to solve the problem (like make the tools look for likely errors and warn the user), but Python chose the route of just getting people and tools on the same page - it's not a bad solution.
Personally, I've used Python for many years now, in everything from tiny startups to Fortune 500 companies, for everything from small tools to enormous, distributed systems. Like any language, it has its strengths and its weaknesses, but the indentation is not an issue in practice, but is instead an asset. All of the potential or theoretical problems that people complain about with indentation-based blocks are overblown and simply doesn't occur in practice - at least no more than any other type of problem (I can't even remember the last time we had a bug due to it - probably not in this decade).
If that's not your cup of tea, that's fine. I just find it interesting that (a) it does not actually cause problems in practice and (b) when I hop over to a language like C++ I find that curly braces are just noise and feel wholly unnecessary - just extra stuff to help the tools along, and not there for my benefit as a developer.
Did you use to work for Taco Bell?
funny that your text ends with a )... I'm still searching for the (
Delete the last tab on the last line of a python block. Does the code still run? Almost certainly. Does the interpreter give a warning? Nope.
Now delete the last curly bracket from a C/C++/java block. Does the code compile? Not on your life. And if I have to explain why then you have no business giving an opinion on this topic.
Two major issues. One- indent only code is nearly impossible to find bugs in. I've seen teams of programmers look for weeks for the source of an issue, it ended up being 1 line that used a tab instead of spaces. Indentation fails because of such issues.
Secondly, you can't copy paste cleanly from the web with an indentation based language.
Either of those is a disqualified by itself. Both together make it such a brain dead choice nobody should even look at a language that uses it
I still have more fans than freaks. WTF is wrong with you people?
I would named it GOTO.
Dave Barnes 9 breweries within walking distance of my house
So you're saying a) you have a team that doesn't know how to turn on the 'show whitespace' characters option in every single IDE / code editor, b) a team that doesn't follow a style guide that dictates whether you must use tabs or spaces, and to know why this is important, and c) an important consideration for your work is how to copy and paste code from Stack Overflow. If you get stuck up on indents being a problem, I'll respectfully submit that it's not the language's fault...
Python's stance is that the humans and the tools should use the same block identifiers. Sure there are other ways to solve the problem (like make the tools look for likely errors and warn the user), but Python chose the route of just getting people and tools on the same page - it's not a bad solution.
Sorry but it is a bad solution. I used to be a fan of indentation until I started writing large programs. Such big projects often require refactoring of the initial design and thus massive cut-and-pasting, with all the standard ensuing pitfalls.
This is a problem that clearly didn't occur to the Python designer and to this date is both unsolved and a major source of bugs.
For grownups we still have braces
Call me old-fashioned, but to me braces look weird on people older than 12-15 years old.
lucm, indeed.
I think I get the point you're trying to make, but I'm a bit dubious - it's a syntactically valid change, so there's no reason for the tool to complain. That's in the same class of errors as deleting a digit from a constant, accidentally pressing '+' instead of '-', removing the '=' from a '=' expression, and so on.
I personally don't care if certain people like Python or not - language preference is often fairly subjective. I'm doubtful, however, about claims that the indenting is bad in any objective way - I've seen too many people use it for too many years on too many projects without it being a problem. I mean, don't you think this would be tripping people up constantly if it were a real issue in practice?
I've watched veteran devs pick up Python as well as recent college grads pick it up, and this just isn't an issue. I can maybe/kinda/sorta almost convince myself that I've just been extraordinarily lucky to have never had this be a problem, but for it to not be a common problem for all of those other people, on all of those other projects? Nah, it just doesn't add up. Everything I've seen suggests that this is a problem that could occur in theory, but rarely if ever does in practice.
None of those things should ever be an issue in the first place. Are there good reasons to keep an eye on the use of tabs and spaces? Yes, sometimes. Should they ever stop your code compiling or have any effect on how it compiles? Hell no - just as using all caps for variable names, if you choose to do so, shouldn't.
If you get stuck up on indents being a problem, I'll respectfully submit that it's not the language's fault...
By that logic, doesn't any crazy and pointless thing a language might require get a free pass? What if I fork Go and my new language requires each line to be numbered? If you get stuck up on that, it's not the language's fault...
systemd is Roko's Basilisk.
"nearly impossible to find bugs in" ?? Sorry, but that's at best a wild exaggeration. I have no way of knowing if you've really seen "teams" of programmers spend "weeks" looking for one line being wrong with tabs or spaces, but it strains credulity - if it's true, then that may say more about those developers. Sorry, I'm sure that comes across rude, and that's not my intention, but ... wow. So this code passed your unit tests and there was some corner case w/o coverage in which it resulted only in something like a logic error and not something more obvious like throwing an exception? Not saying it can't happen, but the whole scenario sounds a bit fishy, especially if it took multiple teams multiple weeks to find it. Anyway...
On the whole, I haven't found Python any harder to find bugs in, and there are a good chunk of bugs that simply don't occur in it, so that it has been a net gain for me. I guess YMMV, but again, I've used Python along with other languages for literally decades and what you're describing just doesn't occur. Maybe I should go buy a lottery ticket or something because I'm wildly lucky... or maybe this just doesn't happen very often in practice.
You still can't use the language name as a search term.
This is the same problem that clueless Hollywood producers have when they give their opus an unsearchable title like Next and wonder why nobody watches it and nobody reviews it.
I suggest Seagull, the language that craps all over your Android device and then flies off again.
Well, I too have anecdotes in the opposite direction, so not sure what to say. I've used Python on very, very large projects that have undergone multiple, massive refactorings and I'm not aware of a single time in a refactor that this was an issue. Honestly, as I've read your message and others' and genuinely tried to imagine the circumstances under which it would happen, I'm really struggling. Like, do you have these 10 page functions or something and large swaths of code are being cut and paste willy nilly?
The "major source of bugs" comment - is that "major source of bugs [in programs I've worked on]" or "major source of bugs [for Python programs generally]"? If it's the latter, I'd love to hear more because, again, my experience and the experience of everyone I've ever worked with who uses Python is the exact opposite.
Hmm, no, that's not what I said (or meant). Rather, when I go to a language like C++, the braces feel entirely superfluous, which begs the question: why are they here? Even with the IDE doing a lot of the work to keep them in sync with the indentation (which in itself is pretty telling), they still feel like completely unnecessary noise.
All languages have things you do that aren't really for your benefit as the developer and are there because the language or other tools need them, and that's a source of friction and too much of that makes it tedious to use that language. Remember in the old days when in C you had to put all your variables at the start of a function? Despite a few who would claim that it aided in "organization" or something, the fact of the matter is that it was because the tool chain just wasn't smart enough yet. Not a big deal, but a case where you're doing stuff not because it helps you, but because the language requires it. For me, curly braces are another example of that, that's all. If you like 'em, great, more power to you. But Python is by no means broken or bad or poorly designed for not having them.
I don't miss them in Python, and in languages that use them I really wish they weren't there.
Agreed. And more importantly, if you have braces, it is possible for the IDE to programmatically fix the indentation so that it is easy to read. There's absolutely no sane reason to require a programmer to use whitespace for any reason other than between tokens that would otherwise be a single token if shoved together. All other use should be superfluous, and the IDE should make it readable for you without the need for a person to do it.
And the reason braces should be in every programming language, IMO, is that it makes it easier to jump to the end of a block. When I have nested blocks in a properly braced language, I can hit percent in vi, and I'm at the end of that block. I don't have to move the cursor to the beginning of the line and laboriously hit the down arrow key a line at a time until I find a line that isn't indented as far. Therein lies the path to madness.
Want to dramatically improve the programming world in a single project? Design a meta-language for code formatting so that a set of text-based rules can enforce everybody's own quirky code formatting standards. Make it handle at least the twenty or so most popular programming languages. Then open source it under a BSD license so that the interpreter can be readily built into every IDE on the planet. Then, we can finally dispense with all of these silly programming languages that use whitespace syntactically once and for all.
Check out my sci-fi/humor trilogy at PatriotsBooks.
"golang"
easy.
I'm exactly the opposite. I've used C for two decades and Python for one. I'm perfectly comfortable in either one and use both on a daily basis. Yet given a choice I'd go with C's curlies any day. Python code always looks unbalanced and incomplete to me, like the end of the function got
Chelloveck
I give up on debugging. From now on, SIGSEGV is a feature.
The biggest problem with indentation-as-structure is that tools in general support it poorly. When cutting-and-pasting or moving code around, it's easy to mess up the indentation of the code being transformed. By contrast, I can move around brace-delimited code sloppily, then tell my IDE to auto-indent, and it looks nice and legible. (It also acts as a form of error-checking; if the resulting indentation looks weird, it's a strong signal that I've screwed my blocks somewhere.)
Of course he does. They were the only ones to survive the franchise wars.
BeauHD. Worst editor since kdawson.
People that think braces and statement terminators are problematic have never used a good auto-formatter.
Hmm, that seems like a pretty sweeping generalization, no? I've used every major IDE out there too, and I don't dev in just Python. As noted earlier, my dislike of braces is that they are noise, and more subtly, they introduce this problem where the block structure indicator that actually matters to the tool (the braces) is a weaker indicator than the one people naturally see more strongly (the indentation - the "shape" of the code is a stronger indicator of structure than some relatively small symbols).
I'm genuinely confused by people who think that cutting and pasting a few lines in problematic in Python. That sort of thing is what people do all day, every day... and somehow it's not causing widespread problems or anything close to it. Even copying and pasting from websites works well (although I find there aren't many real world cases where anyone copies and pastes code verbatim off the web, especially anything more than a few lines).
Anyway, all I can do is reiterate that I've used Python for decades, and watched others - of all skill levels - use Python for decades, and this simply isn't a problem that occurs with any sort of regularity (like I mentioned elsewhere, I can't actually remember the last time I /ever/ saw this happen in practice). Because of this, I really struggle to reconcile lots of first hand experience to the contrary with people who assert it's a major problem (or even a minor problem that occurs with any sort of regularity). Any suggestions?
I guess so? I dunno - somewhat ironically, I do *all* of my Python development in vim and I have no special plugins or anything that assist with it other than the native indent stuff, and it's only with other languages (Java/.Net/ObjC/C++) that I feel the need for a full IDE.
Maybe that's for other reasons though (like other languages being more verbose or something). I just find it interesting that in the scenario in which you feel I should really need the aid of a good tool is where I use the most rudimentary development environment. :) Again, I move chunks of code around all the time, so it seems like I should be running into this issue constantly and yet... it doesn't happen. I don't consider myself some superstar dev, I don't consider myself lucky, so I'm at a loss to explain it, especially when the same is true of all of the other people I've worked with that use Python as well. Life's mysteries I guess!
> Real programmers use IDEs with syntax checking.
No true Scotsman fallacy.
Yes, you can, because it's referred to as 'golang'
Loading...
"One sure sign your language is successful: When people build other languages that transpile into it."
Funny, I interpret that more as "your language is fundamentally flawed but you have a captive audience forced to write in it so they try to make the best of it."
When all you have is a hammer, every problem starts to look like a thumb.
"Curly" braces to denote blocks of code and semi colons to denote end of statement are the marks of a sane language.
I fail to see why mandatory ";}" is sane.
When all you have is a hammer, every problem starts to look like a thumb.
I can't figure out why you would want to build anything on top of Go; the language has several intrinsic design shortcomings and limitations that are reflected in its runtime.
Between C++, C#, and Swift, I see little reason for another compiled language (add Python and JavaScript for interpreted languges). If you really want something more obscure and less associated with big companies, add D and Ruby to the list.
I'd bet it's about as much an exaggeration as people claiming that C++'s operator overloading hides all sorts of crazy logic and performance pitfalls. I've been programming in C++ for decades on million-line projects, and not once have I seen anything like that.
I've actually been programming in Python the past few months. Because the indentation require aligns with what you naturally do as a programmer, it hasn't seemed all that problematic to me.
C++ has a ton of really nasty, subtle pitfalls that you just have to learn to avoid through rigorous self-discipline: Don't forget to initialize your variables. Don't forget your virtual destructor. Don't return and use the address of a temporary variable. Don't screw up your copy and move constructors. Etc, etc. Seen all of these cause issues that were tricky to track down in real life.
I dunno, in practice C++ still seems a hell of a lot trickier to use than Python, so I have a hard time getting worked up about indentation when I'm using to working in a language with beartraps and landmines liberally sprinkled throughout it. Maybe I'll have a different opinion if I work on it longer.
Irony: Agile development has too much intertia to be abandoned now.
I've used Python on very, very large projects that have undergone multiple, massive refactorings and I'm not aware of a single time in a refactor that this was an issue.
It's those wrongly refactored lines you aren't aware of that will seriously bite you in the ass.
When all you have is a hammer, every problem starts to look like a thumb.
I see that exactly no major new language projects have chosen to follow Python lead with whitespace. Or to put it another way, if Python had been defined with curlies, nobody would have complained "we want significant whitespace! Please please!".
When all you have is a hammer, every problem starts to look like a thumb.
*sigh*, no, it's not that at all. I'll assume you're trolling, but for the sake of the discussion: yes, obviously the compiler requires them, but that's purely because that's the way the language was designed. My point - which I'm pretty sure you got - was that if you're coming from a language like Python, you tend to wonder why a language like C++ requires them. As in, you don't see the point of them, that's all.
Because the indentation require aligns with what you naturally do as a programmer, it hasn't seemed all that problematic to me.
No, just a survivable wart. If Python did not have significant whitespace, nobody would miss it, but Python having significant whitespace has caused endless complaints, so it is clearly a negative for the language. Other things being equal, fewer warts is better.
When all you have is a hammer, every problem starts to look like a thumb.
C'mon, go re-read what I said - not once did I suggest that "everyone" (or anything close to that) was having problems with those things, only pointing out that that is a class of problems that can arise due to having both braces and indentation (which is significant on some level to the human but not the language). Unlike many of the anti-Python posts, I didn't make any claim that this was a major source of bugs, a huge issue, etc.
Anyway, looks like my posting limit is just about up with this story, not sure if /. will let me continue feeding ACs, so thanks for the discussion and have a great day!
Actually, lots of people would miss it - just go ask on on comp.lang.python for example - it's one of the features that many people really prefer about the language. I for one do. I totally get that you might not like it, but to a /lot/ of people not only is it not a negative, it's a big positive.
I don't know about everyone else, but I find it *immensely* helpful to write debugging statements without indentation. This makes it so that they stand out from the normal statements among which the debugging statements are inserted. This is the reason I won't even consider using Python.
Just stick "# XXX" comments around your debug code. Many editors automatically highlight XXX so prominently that it's just as easy to spot as unindented code.
Now, all you Python-indentation-style lovers, consider how you would code this kind of Go initializer: := [][]int{{1,2,3},{4,5,6}}
arr
(This declares the variable 'arr' as a slice of slices of ints and initializes the variable.)
You mean, like:
arr = [[1,2,3][4,5,6]]
What's the problem?
Stockholm syndrome.
When all you have is a hammer, every problem starts to look like a thumb.
Python is actually full of limitations imposed by the indentation nonsense. Those limitations show up when a programmer goes beyond simple programs and wants to do more advanced things in the language. For example, lambdas are limited to one expression in Python. There's literally no reason other than because the indentation rules would cause problems otherwise.
So someone who wonders about C++ braces is someone who doesn't appreciate what advantage they provide. Such people don't appreciate the advantages because they haven't needed them in Python. They haven't needed them because they don't exercise the language fully. In other words, they are novice programmers.
I don't think we should care what novice programmers have to say. How about they just shut up and learn?
I have dyslexia, and severe issues with telling whether things are vertically or horizontally aligned. Curly braces are much, much more useful than horizontal indentation for me; I imagine people with more severe visual impairment would have even worse issues. (I can configure my editor to do vertical greenbar for the background, but that's a hack that only works in my local environment.)
but Python having significant whitespace has caused endless complaints
Can't argue with you there... It's definitely a polarizing feature.
Irony: Agile development has too much intertia to be abandoned now.
The IDE gives the warning. Real programmers use IDEs with syntax checking...
You obviously only do web programming and/or don't program on big systems. I want to see you ssh into a server that doesn't have a GUI and use an IDE to fix a program. You'll fail dramatically and then what will you do?
This is why I use "vi" as my editor. It doesn't require a GUI (there is version with one if you're in a position to use it), and I'm guaranteed vi will be available on every Linux/Unix server I work on. IDE's are also bloated; try to use an IDE on a server with only 1G of RAM total.
Indentation is the strongest indicator of block structure to the people reading and writing the code,
Not entirely. Indentation tells you were the block is, but it doesn't tell you where the block ends. That's implied by seeing more stuff in the outer block. I spend plenty of time in non curly brace languages, but I find that the lack of an explicit end of block market in Python makes it harder for me to read. I can't scan the code visually nearly as early as I can in other languages. The form of the end maker, whether it's }, end, fi, esac or whatever doesn't really matter. I find that technically redundant visual cue very helpful.
SJW n. One who posts facts.
;} is very clear.
guarantee end all the previous parsing and drop the local frame.
Computers are mind numbingly stupid. We have syntax to overcome how we deal with that. In this case we are covering two vastly different concepts with absolute precision of syntax.
Coffeescript has got rid of so many syntactic markers and declarations that it has almost no error detection. For example, the sentence 'mares eat oats and goats eat oats and little lambs eat ivy' generates no errors in coffeescript. Nor will the obvious error 'return if ab then'
I refuse to use any language based on significant whitespace You couldnt pay me enough to do it Yes Ive used Python and others and I know why I hate significant whitespace so much It is just like writing sentences with no punctuation It is kind of like trying to read my comment Without punctuation it starts to look like a run on sentence
I have 37 years expereince programming and while I find curly braces absolutely mandatory, the semicolons are something I could do without. I don't need them to find my way around code, but I include them for people who complain about "missing semicolons" in languages where semicolons are optional.
How do you write math without curly braces?
On what level is the math education in your world ??
Most logical statements in math starting with "it exists" (an reversed E) or "for all" (an on the top A) use curly braces.
Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
Your post makes no sense.
With x-tags vi/iY is an IDE like any other IDE. And there is no IDE that is "bloated" and needs more than a few hundred MB of RAM. If an IDE needs lots of RAM it is because of the size of your source code ... go figure. Yes, a few hundred MB for Eclipse is a lot. But you are not running a server ... and develop on it ... on 1GB.
Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
How long has "transpile" been a word? It's new to me, as of today. But I don't get out much ...
There's no time like the present. Well, the past used to be.
Secondly, you can't copy paste cleanly from the web with an indentation based language. ... please, reconsider your carrier plan.
If your programming know how is on such a low level that you can not reread something you copy pasted and fix the errors: let me say it bluntly, you should not be programming!!!!
Sorry, I hope I never have to oversee a programmer like that. There is nothing wrong with copying snippets from e.g. Stack Overflow, but complaining the formatting gets messed up and then you can not get it running anymore
Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
Oh my. You claim that semicolon as terminator is dramatically easier to parse than semicolon as separator, or dramatically more precise. Please never write a parser that I might have to use.
When all you have is a hammer, every problem starts to look like a thumb.
The C-- I know was intended as a portable assembly, mostly for compilers to use as an intermediate language. No "come from" or "do for a while" ala intercal but a variety of low level operations and a low level type system.
I found it interesting but it never took off.
Apologies in advance for the bad font, but Slashdot stopped allowing because of the trolls, so this was the only way to get indentation. Ugh. There's some irony for you.
I've used GNU indent, and it is maybe 1% of the way to a complete solution, if that. A complete solution needs crazy things like:
* Variable weights for indentation priority between the minimum indentation of a continuation line relative to the first line and colon alignment in Objective-C
* Rules on where whitespace can and can't be inserted to correct alignment (e.g. rules like "Don't put any space between the (strong, atomic) and the subsequent type name in an Objective-C property, in such a way that they can be outweighed by other rules if it makes the line too long
* Choosing whether to indent function parameters by the standard n spaces instead of indenting to the open parenthesis if the latter approach would result in a single parameter getting split across multiple lines and the former approach wouldn't
* Closing up space between certain types of tokens (arbitrarily)
* Adding space between certain types of tokens (arbitrarily)
* Proper handling of comment markup (e.g. HeaderDoc, Doxygen, JavaDoc, etc.) with knowledge of where newlines and whitespace matter
* Ability to handle programming languages other than C and related languages
And so on. Basically, the set of rules would likely mean that everything on the left side of the language's BNF would be a named token type, and you could specify rules regarding whether spaces could be added before or after that token type. For example, you might write rules like this:
my-if-statement-whitespace-ruleset {
weight 10000;
if.token {
space-after: 1;
}
}
my-if-statement-whitespace-ruleset {
weight 10000;
function.name {
space-after: close-up;
}
}
To specify that an if statement should be followed by exactly one space before the opening parenthesis, but a function should not, and any such space should be removed.
You'd also need to be able to contextually describe specific tokens like braces. For example, if you wanted to indent the opening brace of a function by 4 and every line nested inside it by 8, you might write something like:
my-function-body-indent-rule-set {
weight: 100;
function.body.first-matching-child("{") {
min-indent: [previous-line] + 4;
child-indent: [previous-line] + 8;
}
}
So basically, something vaguely like CSS, but with weighting instead of order-based priority, plus the ability to define fallback rules with lower priority that get used if the higher-priority rule fails because it conflicts with another rule that has higher priority (e.g. an indent rule set that uses four-character indent if the first rule set for indenting to the open parenthesis gets overruled by a maximum line length rule).
Check out my sci-fi/humor trilogy at PatriotsBooks.
Well, I too have anecdotes in the opposite direction, so not sure what to say.
I am: this whole religious war is vapid. I've yet to see anyone in one of these threads post any actual evidence. It's all opinion, anecdote, vague references to use cases, and general handwaving (when it's not simply childish insults).
Now, if someone has some actual data from a methodologically-sound study to show that one of the options - punctuation pairs or whitespace or what have you - is demonstrably superior or inferior, with good probability, then I'll be glad to take a look. But comments like "curly braces ... are the mark of a sane language" carry no weight, and neither does the feeble "40 years a programmer" attempt to establish ethos. (I've been a professional programmer for three decades, and a student and amateur for a good number of years before that. So what?)
I also haven't seen anyone mention other alternatives. There are languages that use keyword pairs, such as the shell languages that adopted ALGOL's reverse-spelling quirk (if/fi, case/esac, etc.), or COBOL-85's scope terminators like end-if and end-perform. It's quite possible those are more human-readable (less likely to be overlooked) than curly braces; simple editors can't do trivial pair matching, but modern parsing ones can, and do.
(Or there's COBOL's traditional non-paired punctuation scope termination, but I think nearly everyone agrees that one actually is a Bad Thing. Oh, the number of overlooked periods in classic COBOL code...)
Very late post but I still have to add my $.02. I feel like your objection here is too strong and artificial.
I've used both Python and C-style languages including Go for a long time now (15 and 30+ years). I don't really mind either block system. I've had problems with editors doing unexpected things with Python code blocks, and I have to be watchful of that. But in practice I agree with the gp -- it's very rarely a problem except with beginners.
Curly braces are good for auto-formatting, and gofmt really seems to fit with the philosophy of Go in general, so I disagree with what Have is attempting to do in this case since I don't see how gofmt can do its job in this case. But I've also seen some really bad code with curly-braces. Recently I've had to work with a large (million lines) C++ code base that's completely inconsistent, mixing tabs and spaces with no one tab width making sense even within a single file. Every developer had their own editor and settings. Reading that was a major PITA and literally dozens of bugs ended up being wrong-code-block (indent level) types of bugs. And how often have you found yourself counting braces, brackets, and parentheses to find that balancing problem? That doesn't go away with Python, but it helps a little.
I also kind of hate this style that's so popular:
if (stuff)
{
something;
}
else
{
something_else;
}
Reading lots of code written this way is significantly more taxing for me than the more compact styles, especially as outer blocks stretch out over multiple pages of text.
So: You have to be careful when editing indent-sensitive code like Python. But you also have to be careful when editing code with block delineators. Both styles can be bug-prone and are sensitive to accidental editor actions as well as mixed-developer consistency issues. For me the pros and cons of the two are closely balanced.
Whereas I, who (amusingly enough, perhaps) have been a copy editor, had no trouble at all reading your post. But I also have little trouble reading text in a mirror, or letters that are upside-down. That seems to hint that this may be a cognitive thing, and for some people significant whitespace works and for some people it just doesn't and it won't, and the endless arguing about it might be pointless.
Breakfast served all day!