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.
ALGOL called from the 1950's and it wants its syntax back.
And no .. I didn't warn it about anything.
I am Slashdot. Are you Slashdot as well?
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".
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.
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?
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.
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.
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.
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.)
"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.
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.
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.