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.
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 :)
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.
Pretty much. Indentation should be about the look of the code in an editor, nothing more. It should be irrelevant as to how the compiler compiles it.
In all seriousness, yes!
Code that I consider "beautiful" is not just logically pure, it has a readable style thanks to whitespace.
I have seen C code that is instantly understandable because the programmer was free to format it using arbitrary whitespace - something that's not possible with Python.
sigh...here we go again.
The IDE gives the warning. Real programmers use IDEs with syntax checking. Good ones do a lot more also - including adding curly braces and other structural code meaning that this much vaunted efficiency is lost.
If you don't use one you are being an inefficient muppet or at best working with small amounts of code which is not relevant for this discussion.
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.
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.
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.)
Using tabs instead of spaces is a sign of a diseased mind.