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.

Comments

Failed to fix the number one Go problem.

[Anonymous Coward]

You still can't use the language name as a search term.

Re:Failed to fix the number one Go problem.

[Applehu Akbar]

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.

Re:Failed to fix the number one Go problem.

[Anonymous Coward]

"golang"

easy.

Re:Failed to fix the number one Go problem.

[Assmasher]

Yes, you can, because it's referred to as 'golang'

Re:Failed to fix the number one Go problem.

[Anonymous Coward]

Yes, you can, because it's referred to as 'golang'

So, is Have called 'havelang'?

We Need More Programming Languages!

[Anonymous Coward]

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.

Re: We Need More Programming Languages!

[Anonymous Coward]

what else if not program flow should indention express? visual art, perhaps?

Re: We Need More Programming Languages!

[Viol8]

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.

Re: We Need More Programming Languages!

[Anonymous Coward]

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.

Re: We Need More Programming Languages!

[Anonymous Coward]

Sure, as soon as we get editors that format the code the way we like it, but save it the way the project coding standards require - so that diffs aren't stupid and reindentation commits are a thing of the past. It drives me nuts when I have to blame recursively until I find out what the original message was on the reindented lines.

Re:We Need More Programming Languages!

[Anonymous Coward]

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.

No worries. Tesla is on the case! Their new PullThis-h27B is just like that. But the deal is; if you actually use it (like AutoPilot), Elon Musk will call you out in public for being an idiot for actually using something they claimed worked. Clearly the "user" (you're not a driver anymore) is to blame for, you know, actually using it. Ta... da. Enjoy.

Re: We Need More Programming Languages!

[Anonymous Coward]

Lo and behold. Someday in the distant future amongst a sea of humanity that is bereft of hope, solace and sanity an individual will stand up, oh he will stand up. And lo he will scream: "This fucking python shit is the worst load of low-IQ, lazy ass crap I've ever had the fucking displeasure of having my fucking eyeballs and brain assaulted by."

And behold (and lo too) the masses will rejoice and "C" the light and begin the long exodus to the land of true intelligence, freedom and professionalism, the land of C++ once again.

Because in the end who (but a clueless lazy ass script-kiddie) wants to ride a broken Scooty-Puff, Jr., when you can be a man and ride the Scooty-Puff, SENIOR and get the real job done. Hells yeah. Amen.

Re: We Need More Programming Languages!

[Anonymous Coward]

C++ is for wussies. asm(bly)

Re: We Need More Programming Languages!

[bheerssen]

Unless you're talking about tabs versus spaces. If a compiler encounters one or more spaces at the beginning of a line, it should throw a fatal error. Four spaces my ass... learn to indent properly, dammit.

Re: We Need More Programming Languages!

[TheGratefulNet]

I posted about this last time the python wars were on ;)

there should be 2 concepts that are never co-mingled. there is 'define a block' for the computer and 'define a block' for humans.

python's mistake was that they combined them. what we SEE (and makes sense, based on our 2d vision/brain abilities) needs to be something to show us, quickly, what a block is. indenting works and that's fine.

what the computer PARSES does not need visual 2d help. the computer parser needs to be so robust that it is immune to our petty 'what we SEE' things. for this, we use brackets or begin/end blocks or what the hell bash uses (never liked it, but its also a block structure that is immune to spaces, more or less). and you can post code that is messed up by good old html and 'webmasters' and then extract it via a download, compile it and it will work.

with python and other misguided languages, a simple mistaken space format change - which often happens when posting code to forums - will totally blow your code reliability. it MAY or may NOT work. even if it works, is it actually correct? yeah, that can be pushed left. and that, too. it still 'works' but is it RIGHT?

sigh. this is fucked up, guys. it happens enough that we need to learn our lesson, say 'nice try' but it did NOT work out.

we need to keep the computer parser block stuff separated from our 'presentation layer' that we, humans, use to create and edit and read source code.

give me brace-based c code, totally mess up the spacing and I can run it thru a beautifier (for me, just plain emacs) and I'll SEE what you meant by your code. just cannot do that with the python style languages.

please, language creators of the next generation: learn from this. guido is a smart guy, but he's not perfect and he was 100% wrong when he decided to COMBINE those 2 concepts. good try, pat on the back and all that, but admit it didn't work out and lets move on, already!

Re: We Need More Programming Languages!

[Anonymous Coward]

C++ is for wussies. asm(bly)

HA! Now I have you!

int main() { /* Add 10 and 20 and store result into register %eax */
        __asm__ (
                  "movl $10, %eax;"
                  "movl $20, %ebx;"
                  "addl %ebx, %eax;"
        );
        return 0 ;
}

Both baby. Scooty-Puff-DA-MAN to the rescue.

Re: We Need More Programming Languages!

[Chelloveck]

Unless you're talking about tabs versus spaces. If a compiler encounters one or more spaces at the beginning of a line, it should throw a fatal error. Four spaces my ass... learn to indent properly, dammit.

I could get behind this if and only if the compiler enforces *exactly* one tab per indent level, and prohibits tabs anywhere else in the line. Without these rules the whole magic of the "anyone can adjust the tab width however they like" feature of tabs gets hopelessly broken.

Re: We Need More Programming Languages!

[Anonymous Coward]

Funny, having started my career on C and eventually C++, I didn't find transitioning indentation based syntax a big deal. At my current and previous two jobs I've used a mix of Python and C, and the indentation has been inconsequential. The post and having to skim past cheap rehashed jokes about such syntax consumes more effort than having to use it for years. I actually slightly prefer the curly brace syntax, but the difference in practice is too small to care.

Re:We Need More Programming Languages!

[Anonymous Coward]

I think this could be extended further and have program flow dictated by the font you use in your editor.

To wit let me introduce Color Forth.

Color is a semantic in the syntax of the language.

Re: We Need More Programming Languages!

[R3d M3rcury]

Four spaces my ass... learn to indent properly, dammit.

And while you're at it, 2 Spaces!

Re: We Need More Programming Languages!

[Anonymous Coward]

For computer hardware like circuit boards and chip logic, the design is done visually with layout diagrams (chip sockets, pin connections, connectors), symbolic/logic blocks. Now they can even have the actual final product rendered photorealistically in real time as well as being 3D printed.

With blender, shaders used to do things like metal, glass and fabric can be built using dataflow graphs.

Some applications can be designed using UML but still requires bits of code to be written. Presently programmers are really like the Mentats from Dune, able to visualize the operation of a system in their mind and deduce where things can go wrong.

Re:We Need More Programming Languages!

[Anonymous Coward]

Was going to say this, but minus the humor. There are too many programming languages already and every year or two another is introduced. Then you have dumb startup founders buying into the hype of some new language, so developers have to learn it on top of everything else they have to know and keep on top of. HR then starts posting ridiculous job requirements related to the new language(s), frameworks, and libraries that no one can meet because the languages are too new and not popular enough yet. Then for the next several years, those behind the language, frameworks, and libraries keep releasing significant new changes every few months that require old code to be reworked,

Re: We Need More Programming Languages!

[Anonymous Coward]

I have been tempted to change the Python source code to eliminate syntactic meaning of whitespace outside of strings and between language elements. All indentation should not be a syntactic requirement for the compiler or interpreter. Damn it, Guido stop being such a bloody academic ivory tower bastard.

Re: We Need More Programming Languages!

[Tough Love]

guido is a smart guy, but he's not perfect...

I wonder about that. So many blunders in Python, e.g., the whitespace, the inefficiency, the lack of backward compatibility. Could have been great.

Re: We Need More Programming Languages!

[Anonymous Coward]

Using tabs instead of spaces is a sign of a diseased mind.

Re: We Need More Programming Languages!

[DMFNR]

It would be nice, but it wouldn't be just as simple as removing it from the interpreter. Whitespace is what Python uses to delineate blocks, the same way that C uses curly brackets or Pascal uses "begin/end".

for i in range(10):
        print "In the loop"
        print "In the loop"
print "not in the loop"

If you take away the whitespace the interpreter has no way of knowing when it's in the loop and when it's not. So you'd have to add a "next" statement like BASIC, or some other sort of block deliminator. At that point you might as well just create a whole new language.

Re: We Need More Programming Languages!

[Anonymous Coward]

Tabs allow you to count indent levels 1:1, assure that the same levels vertically align, and are easier for an editor to increase/decrease indent levels.

Quick: you have tabs set at 4 spaces, and find a line which is indented 5 spaces. What level is it at?

Re: We Need More Programming Languages!

[Anonymous Coward]

Indentation is for writing comments in the margin. It's not needed in an era where nobody prints code listings on paper anymore.

Re: We Need More Programming Languages!

[Anonymous Coward]

swosh
      swosh
            swosh
                  You can read, but obviously you can't understand...

Re:We Need More Programming Languages!

[Pseudonym]

I'm glad to hear they got rid of the curly braces and copied Python.

I get annoyed every time someone mentions indentation-based structure and seem to think that it was an original idea in Python. Python contains no original ideas that I'm aware of. No, that's not how I judge a language, but it's one of the criteria I used to decide if I want to learn a language or not.

I also get annoyed every time this discussion happens and someone seems to think that Python would be a great language if only it had curly braces. Python is a terrible language, the lexical syntax for which is the least objectionable thing about it.

Re: We Need More Programming Languages!

[Anonymous Coward]

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.

Why? In practice it works very well. In fact it's a pretty strong indicator of a poor programmer if they don't do indentation well because it usually a very visible indicator they've got only a shaky grasp of block structure.

I've both written and maintained large block keyword packages and large block indent packages over many years using a number of different coding styles. Both block conventions work just fine and I'm comfortable in both. I have a slight preference for block indent languages even though I started with with block keyword languages mainly because it's less visual noise and a more compact layout that is easier to parse visually. Main downsides are that line continuation sometimes looks a little funny and large blocks covering multiple screen pages can sometimes be confusing, though you shouldn't be doing blocks that large in any case for other reasons.

Your example of a missing block tail tab is not a problem at all in practice - you're missing the fact that it's very visible and that block keyword languages have similar block nesting issues, particularly those like C with implied one-line blocks.

Re: We Need More Programming Languages!

[bheerssen]

>.<

Re: We Need More Programming Languages!

[Anonymous Coward]

You're right; I don't understand "swosh".

Re: We Need More Programming Languages!

[Anonymous Coward]

>there should be 2 concepts that are never co-mingled. there is 'define a block' for the computer and 'define a block' for humans.

Actually the whole point of indentation in Python is that they think that these should be the same and I agree that they should be the same.

Why should they not? It makes no sense if the computer does something opposed to what I see.

>less). and you can post code that is messed up by good old html and 'webmasters' and then extract it via a download, compile it and it will work.

How about we fix the tools instead? Also, it's not like you extract random things via download, compile it and run it, right? You do read it, right? But you can't read it when it's formatted like hell. So fix the tools not to break it in the first place. It's not a law of the universe that it has to break it or anything.

>with python and other misguided languages, a simple mistaken space format change - which often happens when posting code to forums -

As opposed to all other characters, where a single character change makes it work a-ok? Oh, that breaks it, too.

This is something I'll never understand. Code is not like a book. Code is functional. All things should have a purpose and you should *not* be free to choose a "style" - it's engineering and you are not Picasso.

>sigh. this is fucked up, guys. it happens enough that we need to learn our lesson, say 'nice try' but it did NOT work out.

But it does work out. All major companies use Python, the scientific world uses Python and the majority of Linux distros use Python so much that most wouldn't even boot without it. What didn't work out? It worked out just fine.

>we need to keep the computer parser block stuff separated from our 'presentation layer' that we, humans, use to create and edit and read source code.

No. Definitely not. Why?

As an argument against what you advocate, see the Apple bug with the if statement where they forgot to add the curly braces. That could not have happened with Python! That you argue that the computer *should* interpret it differently than the developer saw it on the screen he worked on is... incredible.

Re: We Need More Programming Languages!

[leptons]

Cool story, bro.

Re: We Need More Programming Languages!

[Anonymous Coward]

Apl forever. You can write it and never even have to think about editing the code. And it is industrial standard expoit resistant.

Re:We Need More Programming Languages!

[Anonymous Coward]

I have no beef with Elon on Autopilot. IMO, it's ok to claim it works, and also disclaim *relying* on it working. That's just typical engineering. I will be upset when they claim you can rely on the technology and it doesn't work (which it will, surely, in some cases). That's worth getting upset about.

Hearing that it works in some situations and then relying on it is a non-sequitur, and i can't condemn that.

Re: We Need More Programming Languages!

[Anonymous Coward]

> Tabs allow you to count indent levels 1:1, assure that the same levels vertically align, and are easier for an editor to increase/decrease indent levels.

You have to count ? Doesn't your editor tell you what column the cursor is on ?

Re: We Need More Programming Languages!

[Anonymous Coward]

I don't mean "enumerate," I mean 1 tab = 1 indent level. Nice and simple.

Re:We Need More Programming Languages!

[lsatenstein]

I truly loved APL's syntax and functionality. It beats Python by a mile, when looking to produce error free code that is succinct and for an APL programmer, easy to read.

Re: We Need More Programming Languages!

[Anonymous Coward]

Lots of pontificating out there buddy, good to know you have the one true way.

As for me, I prefer that what I see and what the compiler sees are one and the same thing.

Most common forums have /code, {code} or whatever today.

Re: We Need More Programming Languages!

[PCM2]

Perl forever! You can write it, and afterward you won't even be able to edit it.

s/Have/Have Not/g

[epine]

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.

Re:s/Have/Have Not/g

[w1z7ard]

I actually like ML style: "let foo = bar in zed".

I agree that curly braced languages should stay as curly braced languages, but it's myopic to assume it's the only choice for scoping when designing a new one.

In any event, you're right that what is broken about GO is not really the scoping mechanisms.

Curly braces = good. Indents = bad.

[Anonymous Coward]

"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 :)

Stew

[Anonymous Coward]

How about just stop reinventing the wheel?

Holy fuck. This is like claiming you have a new stew by altering the size of the same ingredients and adding them in a different order.

It's still stew.

Re:Stew

[jwymanm]

Did you use to work for Taco Bell?

Re:Stew

[kuzb]

Of course he does. They were the only ones to survive the franchise wars.

Re: Stew

[Anonymous Coward]

Go Have Lunch.

What about the Ada way ?

[Anonymous Coward]

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.

Re:What about the Ada way ?

[OzPeter]

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.

Re:What about the Ada way ?

[Anonymous Coward]

The implication of course is that you don't need begin/end or curly braces in Ada to show where the loop begins and ends.

Re:What about the Ada way ?

[Hognoxious]

No, you just need to wear your fingers out. 7 (seven) extra characters! I can barely span four frets as it is.

Re:What about the Ada way ?

[Anonymous Coward]

An excellent idea.
Taking it one step further, we could unify the different blocks with begin...end .
And while we're at it, maybe we could replace those with symbols, to give the real code more room, hmm let's say { and } ?

Re: What about the Ada way ?

[Anonymous Coward]

Given the availability of the Unicode font livraries for mathematical symbols and APL, I think it's time we added new mathematical operators to C++. Just thonk, these would be international as they would not be english words.

The "auto" keyword could be replaced by a glyph for a sports car. "Goto" could be replaced by an airplane glyph. "Switch" could be replaced by a broomstick glyph while "case" would become the suitcase glyph.

Re:What about the Ada way ?

[dunkelfalke]

Bass frets?
Actually on a German keyboard it is faster to type begin and end than a curly brace.

Re:What about the Ada way ?

[angel'o'sphere]

And on an iPad or Android device the language does not even matter.

Only special code editors like Textastic have an extra line of keys for common "programmer symbols".

@Dunkelfalke, if you are on a Mac, consider to make your own keyboard layout with a program called "Ukelele". I just map [] and {} to the german Umlauts (more or less like on an US keyboard).

When programming I switch to the "special" language ;D ... on the other hand with modern IDEs typing { generates the appropriated } anyway.

Re:What about the Ada way ?

[Hognoxious]

Bass frets?

I wish. Actually sometimes it's useful to have small hands.

on a German keyboard it is faster to type begin and end than a curly brace.

They gave priority to the letters with squiggles like the French? Even so I'd be surprised if it's more than two presses each, even if one of them is the devil's own AltGr.

Re:What about the Ada way ?

[dunkelfalke]

Umlauts. So opening a curly brace would be AltGr + 7 and closing it would be AltGr + 0. Both is uncomfortable and they are not really close to each other.

Have small hands myself so I always had to do a classical barre chord instead of using a thumb, even on a narrow neck electric guitar.

Re:What about the Ada way ?

[Anonymous Coward]

Bass frets?

I wish. Actually sometimes it's useful to have small hands.

Given you live on this website. It is clear you have very, very, very small 'hands.'

Missed Opportunity

[Anonymous Coward]

The language building on Go should be called GoTo.

Re:Missed Opportunity

[glenebob]

GoToo? GoTwo?

Re:Missed Opportunity

[Anonymous Coward]

Why don't you just call the language 'Harmful' ?

Re:Curly braces = good. Indents = bad.

[DiSKiLLeR]

This.

I love Python but I fucking can't stand the lack of curly braces.

Curly braces = good. Indents = bad.

[Anonymous Coward]

Curly braces to delimit blocks of code and semi colons to denote end of statement are some of the marks of a sane language.

Anything else often leads to the introduction of subtle, or sometimes not so subtle coding bugs.

40 years of programming experience has taught me how to double post with subtle changes this but if you want to work this out for yourself go right ahead.

Re:Curly braces = good. Indents = bad.

[dbrueck]

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.

Re:Curly braces = good. Indents = bad.

[laejoh]

funny that your text ends with a )... I'm still searching for the (

Re:Curly braces = good. Indents = bad.

[Viol8]

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.

Re: Curly braces = good. Indents = bad.

[AuMatar]

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

Re:Curly braces = good. Indents = bad.

[Anonymous Coward]

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.

Re: Curly braces = good. Indents = bad.

[ahankinson]

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...

Re:Curly braces = good. Indents = bad.

[Anonymous Coward]

Not to mention that curly braces (along with line terminators) allows for different code standards more easily up to compressing the entire file with no line breaks. Also converting between styles is trivial.
And modern IDEs (when used properly) will remove most of the imagined inefficiencies while improving maintainability - the most important thing on REAL (as opposed to example) projects.

You will never tell the "smaller code or die" mob. They will provide endless code snippets showing you have they saved lines of code when compared to carefully chosen alternatives. They will always feel superior and never get it.

Have watched this for a decade now. Still laugh when remembering the Perl folk...

Re:Curly braces = good. Indents = bad.

[Alomex]

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.

Re:Curly braces = good. Indents = bad.

[Anonymous Coward]

So you agree with the criticism, then? You are saying you prefer no curly braces, but that, in the end, it doesn't really matter. Then why create a superset language to fix something that, in the end, doesn't really matter (among other things that also don't matter)?

Re:Curly braces = good. Indents = bad.

[Anonymous Coward]

While I guess I can think of a couple of warnings issued by IDEs but not the underlying compiler (NetBeans' "inefficient use of string concatenation" comes to mind), I can't really think of a way for the IDE or the compiler to tell that:

if(condition)
->doSomething()
->incrementCounter()

is right and:

if(condition)
->doSomething()
incrementCounter()

is wrong.

Re:Curly braces = good. Indents = bad.

[dbrueck]

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.

Re: Curly braces = good. Indents = bad.

[wonkey_monkey]

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...

Re: Curly braces = good. Indents = bad.

[dbrueck]

"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.

Re:Curly braces = good. Indents = bad.

[Anonymous Coward]

All of the potential or theoretical problems that people complain about with indentation-based blocks are overblown and simply doesn't occur in practice

I recently wanted to run a 4 line Python script from a shell script.
Only problem: since Python uses significant whitespace, I couldn't turn it into a one-liner by removing the newlines and tabs.
The solution: luckily the newlines and tabs could be written with backslash escaped characters, but it wasn't pretty.

Like other people said, I also find Python indentation problematic while refactoring. In e.g. Java, I select and move say 10 lines up to their new location, and press CRTL+F to auto-reformat/indent. In Python, I have to be very careful after such a move to get the indentation correct manually, or at best it won't run, but at wordt it will do something completely different.

Copy pasting between files is even worse, because it often eats up leading whitespace of the first line. So you have to adjust that, and then do the above dance.

And finally, copy/pasting snippets from the internet (like, the Python website) will require you to painstakingly reconstruct the indentation, because the browser is too stupid to copy it correctly.

People that think braces and statement terminators are problematic have never used a good auto-formatter. One key press and your whole file is consistently indented. Great after a copy/paste.

Re:Curly braces = good. Indents = bad.

[dbrueck]

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.

Re:Curly braces = good. Indents = bad.

[dbrueck]

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.

Re:Curly braces = good. Indents = bad.

[dgatwood]

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.

Re:Curly braces = good. Indents = bad.

[Chelloveck]

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.

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

Re:Curly braces = good. Indents = bad.

[santiago]

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.)

Re:Curly braces = good. Indents = bad.

[Anonymous Coward]

Indentation is the strongest indicator of block structure to the people reading and writing the code,[... Java like explanation to overcome feelings of Inadequacy.]

Yeah, as an assistant to the assistant office supply assistants, I can see how python really helps with all that. Nice.

Re:Curly braces = good. Indents = bad.

[dbrueck]

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?

Re:Curly braces = good. Indents = bad.

[Anonymous Coward]

I've been using Go extensively for more than a month now. Lots of things are *wonderful*, especially the rule that all blocks controlled by a conditional must be in braces, thus making it unnecessary to put parentheses around conditionals. But oh! the thing I hate the most is that semicolons are optional. Damn, what an awful idea! I'm forever having to plan out how long lines will end so that the parser won't infer semicolon insertion too early. This also makes it so that cuddled else's are required in order to avoid the dangling-else problem. Cuddled else's: yet another reason I hate the optional semicolons.

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.

More about debugging: sometimes a debugging statement should be wrapped in a else clause of a conditional in the normal program flow. In a language like C, I can add the else and its block at the left margin. When it comes time to remove the debugging statements, that else clause comes out cleanly. In Go, however, I have to alter the line in the indented code that closes the if statement. That's one more reason I want my semicolons back.

Now, all you Python-indentation-style lovers, consider how you would code this kind of Go initializer:
    arr := [][]int{{1,2,3},{4,5,6}}
(This declares the variable 'arr' as a slice of slices of ints and initializes the variable.)

Except to separate tokens in source code, whitespace between tokens should have no effect at all.

Re:Curly braces = good. Indents = bad.

[Anonymous Coward]

Mostly because you're too stupid to understand that it wouldn't be an error the IDE could pick up.

"REAL PROGRAMMERS USE IDES"

Please sit down and shut the fuck up. You wouldn't know a real programmer if he dereferenced your face.

Re:Curly braces = good. Indents = bad.

[dbrueck]

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!

Re:Curly braces = good. Indents = bad.

[Anonymous Coward]

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:

Yes, it begs the question why you don't understand how compilers work if you are a 'professional' programmer.

Re:Curly braces = good. Indents = bad.

[Anonymous Coward]

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.

I've never come across this being a problem, where someone accidentally removes a tab without intending to change the structure (ymmv). Yet I've come across many bugs of the form of a curly brace pair getting commented out and bugs from switching from a debug to release version and macros messing up C if statements and have watched time being wasted when trying to find which curly brace was accidentally removed or closed early by accident.

Just because removing a tab and a curly brace both involve a one byte change doesn't mean they happen equally frequently...

Re:Curly braces = good. Indents = bad.

[UnknownSoldier]

> Real programmers use IDEs with syntax checking.

No true Scotsman fallacy.

Re: Curly braces = good. Indents = bad.

[Anonymous Coward]

I've heard people mention those two issues, yet I've never had them come up from half a dozen different full time jobs and additional consulting gigs that involved Python. I can see why the first issue could be a major clean up once a mess is created, but in practice it seems avoidable using anything slightly more advanced than notebook for editing with simple warnings about a mix of tabs and spaces. I've never had issues with copy pasting, although maybe if you are copy pasting more than a dozen lines of code you should try to just download a file instead.

If your team has these issues, then yeah, avoid indentation based language. Yet plenty of teams don't have these problems, whether through proper editor use or simple habit or some other unseen magic.

Re:Curly braces = good. Indents = bad.

[Anonymous Coward]

The thing is: those problems you claim everyone has with braces and statement terminators, I haven't had one of those in years either. So you're making a sweeping generalization too.

And the problems I described I had with Python indentation were real too. YMMV, so don't assume your experience is the only real one. Maybe you use a better IDE than me, or maybe we just have different habits, who knows.

I use Python from time to time. I generally like it. But I would have liked it a lot more without semantic whitespace. I don't hate the indentation, because I do that anyway. But I hate the fact that, under special circumstances, I can't do away with the indentation. Like not being able to paste one-liners to a command line without painstakingly escaping and such.

Re:Curly braces = good. Indents = bad.

[Tough Love]

"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.

Re:Curly braces = good. Indents = bad.

[Anonymous Coward]

Mostly because you're too stupid to understand that it wouldn't be an error the IDE could pick up.

"REAL PROGRAMMERS USE IDES"

Please sit down and shut the fuck up. You wouldn't know a real programmer if he dereferenced your face.

Real programmers use vim with various plug-ins if they desire keyword/reserved word highlighting. Personally, I prefer a glowing green screen of text on a black background; good contrast at all screen brightness levels with a notebook computer especially when in varying lighting conditions.

Re: Curly braces = good. Indents = bad.

[Dutch Gun]

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.

Re:Curly braces = good. Indents = bad.

[Tough Love]

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.

Re:Curly braces = good. Indents = bad.

[Tough Love]

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!".

Re:Curly braces = good. Indents = bad.

[dbrueck]

*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.

Re: Curly braces = good. Indents = bad.

[Tough Love]

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.

Re:Curly braces = good. Indents = bad.

[dbrueck]

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!

Re: Curly braces = good. Indents = bad.

[dbrueck]

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.

Re:Curly braces = good. Indents = bad.

[Waffle Iron]

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:
        arr := [][]int{{1,2,3},{4,5,6}}
(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?

Re: Curly braces = good. Indents = bad.

[Tough Love]

Stockholm syndrome.

Re:Curly braces = good. Indents = bad.

[Anonymous Coward]

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..[...].

And you seem awfully desperate to convince yourself that you are not working on a steaming com-pile of python poop. When I hear people tell tall-tales of using scripting languages over real languages to do everything (which you are with the Fortune 5oo massive project crap) you are really saying this.

dbrueck: "Yeah once I was a multi-millionaire, living the high life. C++ fast cars, women, mansions, women, first-class travel, C++ women and all the best things in life. Then... then it hit me. What am I doing, I said. I could be programming in Python! I could be done with thinking man! I went there. Now I'm here."

dbrueck gets up off the dirty floor of an abandoned hovel in some shit-hole ghetto. "I mean NOW, now I have intellectual freedom man! Look I can bang that toothless crack-whore hag over there anytime I want and... hey, hey is she passed-out or dead? Anyhoo, I mean that is glory man! That is freedom man! I love it! Hey can you spare me a dollar or a semi-colon? Hey, have I told you how I was once a Fortune 5oo coder man? Yeah, but Python set me free man. No more braces man! Hey, have you got any food? Check this, with my forced indentation no matter how loaded I am I can code man, no skillz required 'cos the IDES does all the work baby.! I got it by the tail man! Hey, can I borrow your car for a little while? Yeah I gotta' buy some whitespace. Pure white baby. Hey did you give me that dollar? I am Living the Dream, baby, Living the Dream! Oh yeah! (coughs heavily into a dirty rag) I love this! Better than being in the big-time writing C++ Whoowoo!"

Doesn't really add up does it, and it never does with people who tell you they've done everything everywhere and took over world with a toothpick and a snake. Actually quite sad really.

OMG Captcha: beggar

Re:Curly braces = good. Indents = bad.

[martin-boundary]

Double sigh. That's a terrible argument, you're basically saying that people who are "learner" programmers who have not used Python enough to see its limitations wonder why C++ uses braces. Duh!

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?

Re:Curly braces = good. Indents = bad.

[Anonymous Coward]

"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.

Exactly.

Re:Curly braces = good. Indents = bad.

[secretagentmoof]

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.)

Re: Curly braces = good. Indents = bad.

[Dutch Gun]

but Python having significant whitespace has caused endless complaints

Can't argue with you there... It's definitely a polarizing feature.

Re:Curly braces = good. Indents = bad.

[kbrannen]

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.

Re: Curly braces = good. Indents = bad.

[Anonymous Coward]

> my new language requires each line to be numbered?

That is a feature that is very useful when you drop your tray of punch cards. The card sorter puts the program back together quite quickly.

Re: Curly braces = good. Indents = bad.

[Anonymous Coward]

> but Python having significant whitespace has caused endless complaints,

Mostly by programmers who don't want to understand. They want to use tab characters in source so they can fiddle with indentation levels.

Use it or don't use - I don't care. Complaining will just get advise on how to use it correctly (visible tab characters, configure editor to replace tab key with spaces, or use idle), if you don't want to take that advise then don't use Python.

Re:Curly braces = good. Indents = bad.

[Anonymous Coward]

> I recently wanted to run a 4 line Python script from a shell script.
> Only problem: since Python uses significant whitespace, I couldn't turn it into a one-liner by removing the newlines and tabs.
> The solution: luckily the newlines and tabs could be written with backslash escaped characters, but it wasn't pretty.

Python code in shell scripts works fine.

#!/bin/sh
echo "shell stuff here"
python ****
def main():
        print "python in main"
if ( __name__ == "__main__" ):
        main()
****

Re:Curly braces = good. Indents = bad.

[Anonymous Coward]

Google dropped the <<

python <<****
python code here
****

Re:Curly braces = good. Indents = bad.

[Anonymous Coward]

"enormous, distributed systems" ... please don't do that. i'm tired of cleaning up after idiots like you.

Re:Curly braces = good. Indents = bad.

[Anonymous Coward]

> I recently wanted to run a 4 line Python script from a shell script. > Only problem: since Python uses significant whitespace, I couldn't turn it into a one-liner by removing the newlines and tabs. > The solution: luckily the newlines and tabs could be written with backslash escaped characters, but it wasn't pretty.

Python code in shell scripts works fine.

#!/bin/sh echo "shell stuff here" python **** def main(): print "python in main" if ( __name__ == "__main__" ): main() ****

And here we have the epitome of the pro-python coder.

No clue where they are, no clue what they are doing. Dazed and Confused as usual. Hey "Mr. One-Trick-Pony Pro" you are not on reddit anymore, but regardless you are the best and brightest of the pyPro crowd I'm sure.

And as a perfect example, I did nothing but hit 'Quote Parent' and look how well all your wondrous indenting and dumb-ass reddit 'quotes' worked out. And there you have it. Wow.

Re:Curly braces = good. Indents = bad.

[serviscope_minor]

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.

Re:Curly braces = good. Indents = bad.

[thogard]

;} 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.

Re:Curly braces = good. Indents = bad.

[Anonymous Coward]

GNU Indent

Re: Curly braces = good. Indents = bad.

[leptons]

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

Re:Curly braces = good. Indents = bad.

[leptons]

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.

Re:Curly braces = good. Indents = bad.

[angel'o'sphere]

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.

Re: Curly braces = good. Indents = bad.

[angel'o'sphere]

Secondly, you can't copy paste cleanly from the web with an indentation based language.
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 ... please, reconsider your carrier plan.

Re:Curly braces = good. Indents = bad.

[Anonymous Coward]

> I did nothing but hit 'Quote Parent' and look how well all your wondrous indenting

If you do your programming using Slashdot editor and rely on 'quote parent' to get your code then you deserve all that you get. Use appropriate tools, as I do and it works fine:

#!/bin/sh
echo "shell stuff here"
python <<****
def main():
                print "python in main"
if ( __name__ == "__main__" ):
                main()
****

So that is twice that you have failed: once when you fail to use a shell scripting feature and wind up with crap, and now you have used the wrong tool to get a code quote and wind up with crap (I used the correct tool: select, copy, paste and it worked perfectly with Firefox on Linux).

The problem is not 'Python', it is your poor skills and poor choices. Please stay away from Python, we will all be happier.

Re:Curly braces = good. Indents = bad.

[Anonymous Coward]

I love that the new gcc compilers flag warnings when the indentation doesn't match the curly braces. Really, coders need all the help they can get.

Re: Curly braces = good. Indents = bad.

[Anonymous Coward]

C++ is a low level language that provides that level of control.
Python is a scripting language that hides the implementation of how it works.
Stop comparing a dog with a dinosaur.

Re:Curly braces = good. Indents = bad.

[Anonymous Coward]

and now you have used the wrong tool to get a code quote and wind up with crap...

Wow you are literally, quite literally too stupid it even begin to understand, aren't you. PyPro indeed. I mean you are so stupid you think that using > is the official way to quote on /.? Note the quote above? Then you don't even get _that_ when it is pointed out to you... also, that you are not on reddit anymore. Lol. And you called the behavior of using a web page/interface a tool? Do know even what a tool is? Other than "We's gots IDES!" You are the only dim-wit tool here Pal. And everyone can see it.

You are just beyond any measure of an amateur poser wannabe. That cut and past job is the greatest coding you'll ever, I mean ever do. So it figures Python is your one and only true language. Perfect. Lol.

Re:Curly braces = good. Indents = bad.

[Anonymous Coward]

> you think that using > is the official way to quote on /.?

And there is part of the problem that you have: inflexibility. You think that there should only be one way to do things and you throw insults at those that don't do it the same way that you do, and to those that attempt to educate you.

> you called the behavior of using a web page/interface a tool?

No. I called the Slashdot editor a tool, I called 'cut and paste' a tool. But you should be forgiven for not reading the message correctly because 'the red mist' clouded your vision.

And, no, I don't use IDEs, nor do I visit reddit. While I do use Python quite extensively, I still use several languages and, over the last 40 years or so, have used several others that are no longer useful to me.

Re:Curly braces = good. Indents = bad.

[Tough Love]

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.

Re:Curly braces = good. Indents = bad.

[dgatwood]

Apologies in advance for the bad font, but Slashdot stopped allowing &nbsp; 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).

Re:Curly braces = good. Indents = bad.

[Anonymous Coward]

And I proved to you how your stupid inflexible reddit junkie behavior and 'code' fucked everything up. Project much? Python much? Because Python is one of the most inflexible languages on earth, as is your behavior.

Couple that with arrogance and stupidity and we have the "perfect python poser coder." And you still don't get it and I know you won't change. You'd be insta-fired in the mission-critical companies I work with. Once again, this is perfect. You have proven the inflexibility of python AND its "users" for all to see. Lol.

Re:Curly braces = good. Indents = bad.

[Anonymous Coward]

I already indent the code so I can understand it. People read it by indentation and if indentation is incorrect they will misunderstand the code no matter where the curlies are.

I see no reason why I would have to do that work twice and insert curlies, semicolons etc just so the compiler is able to understand the code as well. That is a step backwards in terms of coding. Compilers should get smarter and not need all those cues. I need to focus on what the code does, not how to make the compiler happy.

Re:Curly braces = good. Indents = bad.

[michael_wojcik]

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...)

Re:Curly braces = good. Indents = bad.

[TopherC]

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.

Re: Curly braces = good. Indents = bad.

[PCM2]

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.

have

[Anonymous Coward]

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".

Re: have

[Anonymous Coward]

indeed. and an issue tracker called "error" along with stacktraces "so" and messages of the form "like " where id is coded in names of languages most typical for the error"

eg. search for

"go have error like Java" for NullPointerException

love it

Re:have

[istartedi]

Have Blue was actually the code name for the Stealth Fighter project. Maybe he wants to sneak in under the radar.

Re:have

[Anonymous Coward]

To be fair, Microsoft created the benchmark in douchery releasing .net.

Re:have

[Parker Lewis]

All good ideas for Gnome programs!

Re:have

[Anonymous Coward]

have to go transpiler

This is just a step above "mommy i have to go doody".

I would write 500 lines

[Anonymous Coward]

and I would write 500 more...

And if I Haver, (whatever that means),
Yeah I know I'm gonna be-
I'm gonna be the one who's Havering to you.

More languages! More APIs! More freedom!

[Anonymous Coward]

This may have worked on kids during the second dot-com boom, but people are wising up - each "new" language is just a way to get developers better locked into some company's platform. And there is nothing so magical and so missing from all other languages that each deficiency warrants designing a new language. This is all bullshit designed to waste people's time and proliferate ever more meaningless resumes responding to the demand for 5 years of experience in stuff that was released last year and will be superceded the next.

Remember back in the late '90s when people realised that the Java/NGWS(.net) battles were really about proprietary control, not about improving the state of technology? That hasn't changed.

Have?

[davebarnes]

I would named it GOTO.

Re: Have?

[Entrope]

Come on, everybody knows the ultimate language needs a COME FROM statement.

and here we go again

[Anonymous Coward]

https://imgs.xkcd.com/comics/standards.png

For the love of the children

[Anonymous Coward]

For the love of they children they did create python. For grownups we still have braces, there are things that spacing and tabbing cannot address.

Re:For the love of the children

[lucm]

For grownups we still have braces

Call me old-fashioned, but to me braces look weird on people older than 12-15 years old.

Re:For the love of the children

[angel'o'sphere]

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.

C--

[Anonymous Coward]

That reminds me of a language called C--

It had interesting constructs like "Do For A While", and of course the useful "Come From" statement.

I never understood why C-- didn't become as popular as Ada

Re:C--

[GuB-42]

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.

One sure sign your language is successfu

[Tough Love]

"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."

bad substrate, adds nothing

[ooloorie]

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.

Re:bad substrate, adds nothing

[Anonymous Coward]

Javascript is a shitty langauge and python's whitespace bullshit makes it a shittier language. So yeah, a good scripting language would be a godsend. Ruby was nearly there, but they decided to let perlisms into the language and fuck it all up. Sadly, bash is still one of the better languages for scripting things.

Re:bad substrate, adds nothing

[Anonymous Coward]

Javascript is a shitty langauge

Plain JavaScript is, but portable frontends like TypeScript and CoffeeScript make it reasonable.

and python's whitespace bullshit makes it a shittier language.

If you have a hangup about such minor syntactic issues, you aren't much of a programmer. In fact, as languages, there is little difference between Python, JavaScript (where I include better frontends, like TypeScript and CoffeScript), or Ruby. Python and JavaScript simply have spectacularly good libraries.

Re:bad substrate, adds nothing

[Anonymous Coward]

golang won't compile for many architectures, what's the point?
I'll stick with C/C++ anyday of my life.

Re:bad substrate, adds nothing

[Anonymous Coward]

You really believe it's not possible to improve the current set of programming languages? There's so many issues with those languages that its staggering. The newer language don't really address their shortcomings, but that's a different issue. You clearly have no depth of experience programming outside of OOP and procedural paradigms. Many life critical systems are not written within the C landscape and in today's world most of the projects that use C++ shouldn't.

Re:bad substrate, adds nothing

[tgv]

As far as I can tell, Have has exactly the same shortcomings as Go, but with a slightly different syntax. I don't care about indentation vs block markers (I prefer begin ... end, but there's enough vitriol already), but all Have does is put struct functions inside the struct instead of outside (with the ugly func (s *struct) syntax). Go's approach has an advantage, Have's too, but it's all very cosmetic.

The Go language is indeed limited: I see it as an odd mixture between Java and C, a Java-- if you want: no OOP, no generics, automatic memory management. It does offer easier multi-threading than either. So Go offers a lot of protection against typical C bugs, but performs better than Java. It's therefore a sane choice if you want to write low-level-ish applications, where performance matters, and you don't want to spend dev time doing your own memory management.

Personally, I find Rust very interesting, but it's a bitch when it comes to rewriting old code in it. I would love to do a bigger project in it, though, to get a better feel for it.

Re:bad substrate, adds nothing

[ooloorie]

Yes, Go's gimmick is multithreading, and it is indeed better than in C. But I think threading is also Go's greatest weakness: Go's CSP-based model was obsolete from the start; better approaches have been around for years.

Thank FUCKING GOD!

[Anonymous Coward]

It's been almost a few months since hearing about the last new programming language that extends another slightly older programming language that is a reinvention of an even older programming language.

What next?

[Anonymous Coward]

I can't wait for the language AFTER this - What is it we're supposed to Go Have? Fun?

Heaven is... Hell is...

[Anonymous Coward]

Heaven is where programming languages have
      Python’s readability
      Perl’s string manipulation
      Scala’s functional programming
      C’s performance
      Java’s library support
      Go’s compile times
      Javascript’s client-side support
      Ruby’s expressiveness

Hell is where programming languages have
      Ruby’s performance
      Python’s string manipulation
      Perl’s readability
      Java’s client-side support
      Javascript’s functional programming
      Go’s library support
      C’s expressiveness
      Scala’s compile times

Re: Curly braces = ok. Indents = ok.

[Anonymous Coward]

> it ended up being 1 line that used a tab instead of spaces. Indentation fails because of such issues.

Then:
a) do not use an editor that inserts a tab character - ever (this is usually a configuration item).
b) turn on 'visible tab characters' to ensure there are never any (this is usually a config item)..

If you think that tab characters should be used in source code than _never_ use Python, we will be grateful that you stay away from it.

Ship Of Fail Docks

[Anonymous Coward]

Go uses curly braces in the manner of C/C++, while Have uses block indents, like Python..

And we're done! Fuck that bullshit straight top hell.

Take the single worst aspect of Python and base your new language around it? WTF?

Just use a properly-designed language instead.

[Anonymous Coward]

If Go isn't doing it for you and you want something similarly C-style but with more thought put into it, then there are lots of languages out there to choose from and to help improve. There is simply no reason to "fix" a language that was designed to be so stuck in the past anyhow. Go is essentially a backwards-looking language in an era where carefully designed alternatives like Swift and Rust have completely stolen its lunch outside of the obliviously happy little Google-friendly niche Go has carved out for itself. Heck, there are lots of other older C-style languages that enable more modern coding best-practices.

python-like syntax complicates error detection.

[alw53]

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'

"Transpile"?

[eric_harris_76]

How long has "transpile" been a word? It's new to me, as of today. But I don't get out much ...

Interested for all of 10 seconds, if that

[Anonymous Coward]

I gained interest at the part that said it avoids Go land mines, and then lost it as soon as it said it got rid of C/C++ braces for Python indention. Good luck, Have, but I'm a Have Not.