HN Theater @HNTheaterMonth

When Go was first announced ~2009, Rob Pike explicitly framed it as a systems language

https://www.youtube.com/watch?v=rKnDgT73v8s

I would not say it's the same as Java or C#. The crucial difference is that it compiles to a native executable binary file, not something that needs a virtual machine.

⬐ Erlangen

I think Rob Pike has changed his idea. I remember watching Youtube video featuring language designers(golang, d and rust), where Rob Pike, Andrei Alexandrescu and Steve Klabnik talked about the stories behind three languages. Rob Pike said something like, "Golang was mistakenly called system language, it should be called server programming language instead".

I tried to find the video on youtube, but to no avail.

⬐ KineticArms

I don't know if I'm just overworked or what, but the comparison of java to Go cracked me up, to the point of actual laughing out loud. Java is like that JNCO and puka shells phase, we all thought we were hot shit but now we just try to not mention it and cringe when evidence shows up.

⬐ bhedgeoser

C programs are executed inside the C virtual machine.

⬐ wizofaus

Can't tell if serious...

⬐ never_inline

Either a reference to Abstract Machine from the standards, or something suggesting the processor is a C virtual machine.

⬐ PopGreene

Interesting article:

"C Is Not a Low-level Language" (https://queue.acm.org/detail.cfm?id=3212479)

⬐ never_inline

I have read that.

While I feel that article is being too harsh on C, it would be interesting to have cache intrinsics just like we have SIMD intrinsics. I would imagine that would be more complex to implement, however.

⬐ culi

You mean the C abstract machine?

⬐ sanderjd

It is possible to compile Java and C# binaries. It is true that it is not as common and they were not designed that way, but I think this difference is mostly an implementation detail. I think these are indeed the best comparison languages to Go. They're all mature statically checked languages with good garbage collectors and concurrency features.

Actually, Go is at least 6 years old; the original announcement was Oct 30, 2009:

https://youtu.be/rKnDgT73v8s

⬐ merb

yeah sorry however I would actually use go version 1 as a reference. everything before was changing just too often, there was go fix however still many changes. also everything before 1.0 wasn't targeted too much about performance. also I can remember how much the template spec changed. thats what I used these days quite heavily. I have a book about go that dates 2011, and I think that was go 0.7 as far as I remember.

⬐ lsllc

Fair enough; in that case Go 1.0 is just about 4 years old:

https://blog.golang.org/go-version-1-is-released

If I remember properly, when Go was first developed, compilation time was one of the primary metric that Rob Pike et al were optimizing for, and drove major aspects of its design. It shouldn't be surprising that Go blows other systems out of the water in this regard.

Here he is talking about it:

https://www.youtube.com/watch?v=rKnDgT73v8s#t=8m53

⬐ pjmlp

> It shouldn't be surprising that Go blows other systems out of the water in this regard.

For any developer that never used Turbo Pascal, Modula-2, Oberon compilers, just to cite a few examples among many possible ones.

Those that did, can not comprehend why companies invested in languages like C and C++, which created this notion all compilers should be slow.

⬐ insulanian

Oh yes, Turbo Pascal (and even Delphi / Object Pascal) had a really fast compiler. Sigh... those were the days...

⬐ pcwalton

My point is that you pay a price for this: LLVM's optimization passes are much, much more sophisticated than those of the Plan 9 toolchain. In optimized builds of Rust, the LLVM optimization and compilation time tends to dominate, so having a simpler type system wouldn't really help.

You could have a more C-like language that isn't so dependent on expensive optimization passes like multi-level inlining and SROA, granted, but I think most any high-level language—i.e. one that isn't a bare-metal language like C and Pascal—is going to have lots of opportunity for expensive optimizations.

⬐ tormeh

If optimization is the problem, then compilation at Go speed should be possible with -O0.

⬐ DasIch

Just having the ability to perform such optimizations requires an architecture that is sure to have some overhead no matter which optimizations, if any, are actually executed.

⬐ Jweb_Guru

Rust could still have a toolchain like DMD devoted to fast compilation with minimal optimization. It just doesn't, yet (and likely won't for quite some time, since the present advantages of having a single toolchain are fairly significant and Rust doesn't have a formal specification yet).

⬐ steveklabnik

Multirust makes working with multiple toolchains on *NIX pretty great, but no formal spec can be a pain. Ruby doesn't have a spec, yet has multiple implementations, so it's not the _end_ of the world...

⬐ pcwalton

There are C compilers out there that work like this (like, say, the Plan 9 C compiler) and they rarely ever get used in practice, because GCC and clang -O0 are fast enough. I think making a second compiler backend just to eliminate the IR generation step isn't going to be the solution we want in the long run.

⬐ andrewchambers

I think they are only fast enough because developers have not been exposed to better. In general, I would like to see more aggressive build modes for CI servers, and less aggressive modes for dev.

⬐ tarblog

Also, I'm confused by the word "aggressive" here. Could you elaborate please?

⬐ andrewchambers

Aggressive optimization. I just mean on a build server time isn't as much of a factor as local development.

Go has been announced as a systems programming language: https://www.youtube.com/watch?v=rKnDgT73v8s. After some backlash the slogan has been changed quietly.

> it seems initially it was meant to be those kind of "systems"

From the announcement talk: "And it's a systems language in the sense that we intend it to be used to write things like web servers" http://www.youtube.com/watch?v=rKnDgT73v8s

I don't think that Google ever wanted to develop a new OS kernel.

⬐ rdtsc

> From the announcement talk

From the announcement blog (and that was the widely circulated quote in tech news not the video transcript):

---

Go combines the development speed of working in a dynamic language like Python with the performance and safety of a compiled language like C or C++. [...] And the compiled code runs close to the speed of C [...] Go is a great language for systems programming with support for multi-processing ...

---

http://google-opensource.blogspot.com/2009/11/hey-ho-lets-go...

> I don't think that Google ever wanted to develop a new OS kernel.

As the meme goes, they keep using the word "systems", I don't think it means what they think it means.

⬐ justin66

> As the meme goes, they keep using the word "systems", I don't think it means what they think it means.

I'm pretty sure it doesn't mean what you think it means. The only title I have on my bookshelf which has "Systems Programming" in the title is System Software: An Introduction to Systems Programming. The book is about creating assemblers and compilers for a made-up architecture called SIC: http://en.wikipedia.org/wiki/SIC/XE

This is neither here nor there, but the point is that a fair number of accomplished people in the field were apparently at one time less hung up about precisely what "systems programming" might mean and (this is just conjecture on my part, since honestly, who cares?) probably just used it as a contrast with applications programming.

⬐ wglb

Jeez.

These dudes were writing "systems" long before most folks here on HN were programming.

To me, and to them, "systems programming" has a particular meaning that does not include kernels. Like it means assemblers, compilers, web servers.j

I think they have more credibility about what it means than perhaps you do.

⬐ dbaupp

Before many HNers were even born too.

⬐ nl

This is possible the worst example of selective quoting I've seen on HN.

From the bit you left out:

Want to write a server with thousands of communicating threads?

It's always been clear what kind of apps Go is targeted at, and it's never been operating systems.

⬐ frou_dh

It's a tough crowd when being the authors of both the Unix and Plan 9 kernels isn't sufficient to get the benefit of the doubt on this matter!

⬐ SkyMarshal

That's probably the problem. When those guys say "systems", people expect they mean OS/kernel-level stuff.

I would like to add on to this:

Generics may not be the correct solution, but I would really like a way to make collections which are general enough to be used by any datatype. As of now, I cannot do that without doing the typical `interface{}` approach.

The built-in data structures + channels are able to handle this, but if I just want a set of elements, what do I do? Make a `map[foo] bool`? If I see such a piece of code in an unfamiliar code base, I have no idea whether to test for key existence or whether I have to test whether the bool is true. A generic set would leave me puzzled and type unsafe[1]: What types could possibly exist in this set? A set of foos is not that hard to comprehend, and is in fact very much more straightforward to understand than a generic set, which in unfamiliar code may contain anything, or a mapping from foos to bools.

[1]: Rob Pike mentions in http://www.youtube.com/watch?feature=player_detailpage&v... that type safety is of high importance for Golang, but how does one achieve that if all the different datatypes I implement/need use `interface {}` where I have to cast all values afterwards? That seems very type unsafe, from where I stand.

⬐ mietek

Your puzzling "generic set" isn't what is usually meant by a generic set in a statically typed language.

A generic set would be defined disregarding the type of its elements: "set of ?s". However, a single instance of a generic set would only be allowed to contain members of a single type: "set of foos". This is called parametric polymorphism.

⬐ scarboy

You should be using map[T]struct{} for sets instead of bool. struct{}s use 0 bytes and there will be no confusion as to what the value is for.

For performance of compilation. Go compiles crazy fast -- think two seconds for complete compiler and runtime on a notebook. This provides for rapid hack-compile-debug iterations.

http://www.youtube.com/watch?feature=player_embedded&v=r...

⬐ gnuvince

D is a language with operator overloading and function overloading (no keyword arguments however), at it compiles even faster than Go.

    /tmp/dmd2/src/phobos/std$ wc -l *.d | grep total
     162688 total
    /tmp/dmd2/src/phobos/std$ time dmd -c *.d > /dev/null
    std.cpuid has been deprecated. It will be removed in January 2013. Please use core.cpuid instead.
    std.md5 is scheduled for deprecation. Please use std.digest.md instead
    std.perf has been deprecated. It will be removed in January 2013. Please use std.datetime instead.
    Notice: As of Phobos 2.055, std.regexp has been deprecated. Please use std.regex instead.
    
    real	0m1.210s
    user	0m1.016s
    sys	0m0.188s

1.2 second to compile 162k LOC. Not too shabby!

The "Talks and Videos" page (http://go-lang.cat-v.org/talks/) is outdated as well. Here's my personal list:

Why Learn Go? http://www.youtube.com/watch?v=FTl0tl9BGdc Short interview with Rob Pike, OSCON 2012

Get Started with Go http://www.youtube.com/watch?v=2KmHtgtEZ1s Andrew Gerrand

A Tour of Go http://www.youtube.com/watch?v=ytEkHepK08c Russ Cox

Go Concurrency Patterns http://www.youtube.com/watch?v=f6kdp27TYZs Rob Pike, Google I/O 2012 Goroutines, Channels

Meet the Go Team http://www.youtube.com/watch?v=sln-gJaURzk Panel (Pike, Thompson, Griesemer, Gerrand, Fitzpatrick, Simons), Google I/O 2012

Computing Map Tiles with Go on App Engine http://www.youtube.com/watch?v=sPagpg0b7no Chris Broadfoot, Andrew Gerrand, Google I/O 2012

Go in Production http://www.youtube.com/watch?v=kKQLhGZVN4A Gustavo Niemeyer, Google I/O 2012

Go: Code that grows with grace http://vimeo.com/42146678 (Contains some audio glitches) Andrew Gerrand

Interview with Rob Pike http://www.infoq.com/interviews/pike-google-go/ Rob Pike, GOTO Conference

Lexical Scanning in Go http://www.youtube.com/watch?v=HxaD_trXwRE Rob Pike

Cuddle, A Go AppEngine Demo http://www.youtube.com/watch?v=HQtLRqqB-Kk Andrew Gerrand

Building Integrated Apps on Google's Cloud Platform http://www.youtube.com/watch?v=Mo1YKpIF1PQ Andrew Gerrand, Google Developer Day Japan 2011

Real World Go http://www.youtube.com/watch?v=7QDVRowyUQA Andrew Gerrand, I/O BootCamp 2011

Go: it's that simple?! http://www.youtube.com/watch?v=LWpm1qpWRwA Andrew Gerrand, OSDC 2011

Practical Go Programming http://www.youtube.com/watch?v=2-pPAvqyluI Andrew Gerrand, FOSDEM 2011

Writing Web Apps in Go http://www.youtube.com/watch?v=-i0hat7pdpk Andrew Gerrand, Rob Pike, Google I/O 2011

Go Programming http://www.youtube.com/watch?v=jgVhBThJdXc Rob Pike, Google I/O 2010

Another Go at Language Design http://www.youtube.com/watch?v=7VcArS4Wpqk Rob Pike, Stanford University

Public Static Void http://www.youtube.com/watch?v=5kj5ApnhPAE Rob Pike, OSCON 2010

The Go Programming Language http://www.youtube.com/watch?v=rKnDgT73v8s Rob Pike, Google Tech Talk

⬐ thebigshane

I haven't 'diff'-ed these two lists but a similar listing of Go-related talks can be found on Go community's unofficial wiki: https://code.google.com/p/go-wiki/wiki/GoTalks

thinking OOP as a solution may lead to an article like this whereas it merely is a vehicle. you may or may not use it.

problems of OOP is explained in Go Language video by Rob Pike*, however very intellectually stated arguments in this article are mainly false.

http://www.youtube.com/watch?v=rKnDgT73v8s

programming languages influence how you think about programming to such a degree that it's difficult to reason objectively about them.

it's rare for me to watch long videos, because they are information-poor for the time investment, but i watched rob pike talk for an hour about go this evening. a lot of it is really interesting, but a lot of things about the syntax made me think: ow, that's going to be painful for me if it becomes successful.

rob's talk: http://www.youtube.com/watch?v=rKnDgT73v8s

From the Tech Talk PDF, it is mentioned that Robert Griesemer, Ken Thompson, and Rob Pike started the project in late 2007. Ian Lance Taylor and Russ Cox joined in 2008.

And the goal, as they mention, seems to have the efficiency of a statically-typed compiled language with the ease of programming of a dynamic language but with -

Safety: type-safe and memory-safe.

Good support for concurrency and communication.

Efficient, latency-free garbage collection.

High-speed compilation.

They are aiming at a lightweight type system with no implicit conversions and no more 0x80ULL.

A good starting point is their FAQ page and also the tech talk at youtube: http://www.youtube.com/watch?v=rKnDgT73v8s

⬐ 10ren

My 100ms Story:

100ms. Perceptually, the time it takes for a newline. I was really struck by that. I've felt that waiting for 5 seconds for an ant/java compile was too long (use time ant, like Rob - ant under-reports) but thought I was just being impatient. I mean, it's not enough time to even start a sword-fight. However, hearing Rob Pike (who, by the way, looks way too young to be the C/unix legend from the beginning of time that he is) say 100ms was their target for compiles in this talk made me take it seriously.

So, I hacked together a "javac server", that accepts filenames and compiles them. It doesn't exit between compiles, so it only pays the java-start-up cost once (about 2.5 seconds), and then it drops to about 0.5 a second or so. And then, after a few executions, JIT kicks in, and gradually gets even faster - typically between 100ms and 200ms for a compile (though quite often below the magical 100ms barrier).

Bonus 1: In unix, I used rlwrap, which gives you bash-editing features (from readline) to your own programs, and I discovered that the "-c" option enables tab-filename-completion! It becomes almost as easy to use as the shell. This made me so happy, I had to clap for joy, rlwrap is amazing. The only lack is no * , ?, [], {a,b} etc.

Bonus 2: I made it also run the code. A problem I found was that in Java, a class is only loaded once, so if you recompile the source, and reload it... you still have the first one. The only way to overcome this I found was to create a new classloader each time, that hadn't already loaded that class (a gotcha: be careful that this new classloader does not delegate to classloader that already has loaded that class).

Including bonus 2, this gave a combined compile-and-run time average <200ms (about 190ms). Basically negligible. In fact, the first few times I used it, it felt like nothing had happened, and I had to carefully check by deleting the .class file etc... that it really was compiling in that eye-blink. It was amazing. I'll stress this: it is actually faster than just running the code. I found java takes 450ms on average, and now it's running and compiling in 190ms (it's because java also has that startup cost). That is, it's now twice as fast to both compile and run as just running it.

The magic I discovered is that there's now no need to have separate text files for input, and the infrastructure of parsing, reading directories, etc. You can play with your code by writing snippets of code, and it feels instant. It feels as responsive as an interpreted language like Python or lisp in a REPL.

Going from 5 seconds to <200ms has really made me happy - not just the figures, but the feel of it - and brought more joy into coding. I guess x20 faster is going to have an impact.

10ren

⬐ j_b_f

This is actually a great Google Tech Talk on the language, definitely worth watching for anyone interested in Go.

Doubt it will be successful, no beards: http://www.youtube.com/watch?v=rKnDgT73v8s

⬐ agl

Ken, iant and I have beards thank you :) Rob, gri, Russ and Kai are sadly lacking.

⬐ nailer

Any chance you could please ditch the brace requirement?

You're already marking up the code for humans using indentation, don't repeat yourself by having the compiler use a different parsing mechanism (and make developers mark up seperately for their colleagues and the compiler).

⬐ jacquesm

Let's please not ditch the brace requirement.

⬐ nailer

Could you provide either some supporting arguments or a response to the parent post?

⬐ wsprague

The only thing I HATE about Python is the mandatory indentation. The problems with it are:

1. It mixes format with logic. Don't we all know this is one of the greatest evils one can commit?

2. Indentation is a bitch to parse compared with braces. Violates occam's razor of software of engineering -- simpler is better. Unnecessary complexity is the second greatest evil in software engineering.

3. Indentation is neither symmetrical nor logically unique. Therefore you can't delete all the formatting from a python program and expect a formatter to get it right. With symmetric braces a formatter always knows exactly what logical level it should be on by counting the number of closed braces; not possible with python's goofy system.

4. All that tiresome debate and worry over tabs versus spaces.

5. One can't really say "braces are redundant not indents" or "indents are redundant not braces". Redudency is commutative. I would say braces are for computers, indents are from human; it is simple to go from braces to indents but not so in the other direction.

Just a note -- I will always pick Python over any other scripting language. I just think the indentation is a serious mistake; there are so few other bad choices it tends to irk me that much more.

⬐ nailer

Indentation is logic. Repeating logic is one of the greatest evils one can commit. http://en.wikipedia.org/wiki/Dont_repeat_yourself

Re: parsing, read each line, if the indent is greater than the current indentlevel, add line to a new block, else, add line to existing block.

Tabs were considered harmful before Python, they're still considered harmful now.

You could add braces to Python quite easily, I think this has already been done in jest a few times...

⬐ bugmenot

DRY: I only type braces, the editor does the indenting for me. And it's resistant to mistakes during cut/paste - refactoring of code.

⬐ maw

My main gripe with Python is that it's impossible for autoindenters to work correctly. Consider this code:

    if x == foo:
        # do things
        if y == bar:
            # do something
        # do other stuff <-- at what indent level should this line live?
    # get on with life

You and I know what that means given its indentation, but an autoindenter can't know what to do with the fifth line. It gets worse when you're moving blocks of code into different indent levels.

Now, it's true that in this simple case, you could rewrite the snippet starting with:

    if x == foo and y == bar:
        # ...
    # get on with life

but when blocks get long, this becomes less practical. And your autoindenter still doesn't know when to stop indenting and get on with life.

As a result, in my Python code, I use otherwise gratuitous pass statements all over the place–ugly, but it does the trick.

    if x == foo:
        # do things
        if y == bar:
            # do something
            pass
        # do other stuff <-- at what indent level should this line live?
        pass
    # get on with life

My hypothetical ideal language (the one that's not lispy in outward appearance, anyway) would use braces but would also not run if any inconsistencies of indentation are found.

This would be allowed:

    if x == foo {
        # stuff
        # more stuff
    }

But this would not:

    if x == foo {
        # stuff
       # more stuff <-- BAM!
    }

⬐ jacquesm

Sure. The 'indentation is enough' argument ignores that braces offer redundancy and are unambiguous.

They're like guard rails on the highway, they make totally explicit what is going on.

The 'but you're writing for other humans to read' argument imho is not 100% the truth, you're writing for both the computer and other humans to read.

Humans like the indentation, the braces make it explicit.

The computer doesn't care about the indentation, it just looks at the brackets.

Drop a bracket and you get an error, drop a couple of spaces and your program will happily continue to work, only not in the way you intended.

it's funny how even in languages that don't use 'begin/end' markers (such as python) there are extraneous characters, such as the () pair when calling a function (surely there are ways to do without that ?), or when making a list or a dictionary.

Some things come in pairs, and the beginnings and endings of blocks are such things.

In Pascal it was BEGIN and END, which seemed overly verbose, in C it was { and }, which seems about as minimal as you can go before you become invisible, and when you get invisible you lose something.

Try cutting and pasting some python examples from online fora and see how well it works without.

And try figuring out from a python program that has been created on a box with alternate tab settings what it's intended function was (yes, I know there are tools for that situation).

Begin and end block have meaning, they are 'there', and even if you don't strictly speaking need them they cost next to nothing and make me feel a lot more like things are spelled out to mean exactly what I'm reading.

I should probably start collecting python examples in the wild on the web where the indentation is clearly messed up so the code no longer works the way it is intended, this is a lot more common than you'd want. It is also very frustrating when learning a language.

So, please keep those braces.

⬐ blasdel

it's funny how even in languages that don't use 'begin/end' markers (such as python) there are extraneous characters, such as the () pair when calling a function (surely there are ways to do without that ?)

The () when calling a function with no arguments is not extraneous -- because Ruby lets you omit that, it needs yet another function type to disambiguate when you want a reference to a method (total of 4: Methods, Procs, Lambdas, and Blocks).

What is completely superfluous in the syntax is the colon preceding an expression suite -- you're already using a keyword and indenting the next line(s).

⬐ nailer

Redundancy is an argument against braces, not in favor.

'They're like guard rails on the highway, they make totally explicit what is going on.'

Using this logic, perhaps you should add some ASCII art to your source to denote blocks a third time? This is also a common practice. Do you feel the same about duck typing?

'The 'but you're writing for other humans to read' argument imho is not 100% the truth, you're writing for both the computer and other humans to read.'

Yes, that's true the computer also parses the code. You still haven't provided an argument why using seperate blocking formats is required.

'they cost next to nothing and make me feel a lot more like things are spelled out to mean exactly what I'm reading.'

The cost is evident: there are many cases of indentation not matching braces and vice versa, and the inconsistency between these causing confusion between the language and the humans trying to debug issues.

Tell me you've never looked for an unmatched brace in code you can otherwise parse?

⬐ jacquesm

I was going to answer you until I got to the 'ascii art bit', clearly you are not taking this serious.

I apologize for wasting your time with my attempt at putting in to words what I was thinking, at your request no less.

⬐ nailer

I am taking it seriously, else I wouldn't have bothered replying to a blank 'i disagree' post with a polite request that you contribute to the discussion. The question is quite genuine - where in your view does the need for redundancy stop?

⬐ jacquesm

Braces have a very practical level of redundancy, they cost literally next to nothing in terms of effort and reduce a whole class of errors to 'impossible'.

Let me give you a simple example, in two psuedo languages, one with and one without braces:

   if a > b
     a = a + 5
     b = b / 2

   if (a > 0) {
     a = a + 5
     b = b / 2
   }

vs

   if a > b
     a = a + 5
   b = b / 2

or

   if (a > b) {
     a = a + 5
   b = b / 2
   }

Even though the text is similarly corrupted (for whatever reason) the redundancy in the second example makes it clear that something is amiss, you could even lose the second brace and still at least know that all is not kosher in that segment.

That's not 'ascii art', that's functional.

Redundancy definitely has it's uses.

I'm going to do some digging later on and find a bunch of examples of broken code due to cut & paste problems, some of it on the django site, no less.

That's something that would never happen in C or any other 'overspecified' language.

And regarding 'finding that matching bracket' that is exactly what they're for, if you can't match the bracket chances are that you really do have a problem in the code.

⬐ nailer

If you've spent any time with Python, it should be immediately clear that:

   if a > b
     a = a + 5
     b = b / 2

is quite different from:

   if a > b
     a = a + 5
   b = b / 2

Without needing a second markup for the compiler to emphasize the point.

⬐ None

None

⬐ jacquesm

Of course it is clear that they are different, that was not the point of the argument...

The point is that you can't know which one was the one that was meant to be written there in the first place, and all that changed is some literally invisible characters are gone.

It's like with comments and code, if a comment says 'add two volumes' and I see that the code does not do that then I have a hint that something is not correct.

It could be the comment or it could be the code, but there is something smelly there.

Redundancy = good.

⬐ nailer

'all that changed is some literally invisible characters are gone.'

Er, no. That's not the extent of the changes at all: the very visible code has shifted to the left. I refuse to believe you cannot see that with your own eyes.

'The point is that you can't know which one was the one that was meant to be written there in the first place'

In any language at all, the lack of indentation makes it quite clear the intention is different.

⬐ pohl

You've lost sight of jacquesm's premise, which is when 1) the intention is not accurately reflected by the indentation, and 2) does not break the syntax of the language.

You asked what benefit might come from the redundancy of a curly brace, and this was a scenario in response.

⬐ nailer

When the intention is not reflected by the indentation, you need to fix that, in every programming language.

Python also has the handy benefit of telling you this immediately.

jacquesm's statement about the visible difference is obviously false.

However I don't think it's doing anyone any good to keep contributing on this topic. All I was doing was making a suggestion to improve something. The troll who posted 'no' with no arguments has a bunch of supporters, I'm being moderated down to nothing. You're not responding to my points, and you seem to think I'm not listening to you, though I'm trying to understand what you're saying. I give up, this isn't worth it.

⬐ pohl

I'm only guessing, but the downmods may actually be because of disingenuous rhetoric. Example: "you need to fix that, in every programming language."

This problem only exists if indentation is significant in the language as a way of demarcating blocks. This is exactly the reason for the suggested syntactic redundancy. A reasonable person can accept the tradeoff, but it's not reasonable to insist that the tradeoff isn't there at all.

Edit: the proposed scenario is readable code. It is, in fact, disingenuous to ignore that. It isn't candid to claim apathy, either.

⬐ nailer

Needing to have readable code is a problem is every language.

If you find that disingenuous, fine, I don't care anymore.

Edit: you consider badly indented code readable? You must be great fun to work with. :^)

⬐ jacquesm

Is it possible for you to have an argument without resorting to the personal ?

⬐ nailer

This thread started with a contentless troll post. You've said things in this post that are provably untrue, and the other poster has accused me of being disingenuous. You've also moderated simple, globally accepted truths like 'unreadable code need to be fixed' past zero without replying.

I suggest you examine your own courteousness.

⬐ pohl

In my defense, Python would agree with me that it is readable: it would happily execute the line in the wrong block scope because of a single, invisible character was present or missing.

I bet you meant "semantically correct" instead. Yes, every program's semantics need to be correct in order for the program to be correct. That's a tautology, and it's a deflection from the subject of the tradeoff analysis that you requested upthread.

You're probably a bundle of joy to work with, too. :^)

⬐ nailer

No, I mean readable. For example:

   if (a > b) {
     a = a + 5
   b = b / 2
   }

...is not considered readable brace-requiring language because it's appearance doesn't reflect what's executed.

Ie:

* Python and similar languages would execute the code consistently with how it looks. This is good.

* A brace-requiring language would execute the code in a way that is not consistent with how it looks. This is not good.

Scroll up: I didn't request any analysis, I made a suggestion. Someone posted a blank 'no', and I asked them for a more civil explanation of their views.

⬐ pohl

...and I asked them for [an] explanation of their views

Yeah, that's the request I was referring to.

Python and similar languages would execute the code consistently with how it looks. This is good.

It's good and bad. You win something, you give up something. This is the nature of a tradeoff. It's not like Python lives in an alternate universe where tradeoffs don't exist. But I'm beginning to think its advocates live in one where tradeoffs are invisible in broad daylight.

⬐ nailer

'Yeah, that's the request I was referring to.'

Having an opinion thrust at you does not equate to soliciting said opinion.

It's your responsibility to clearly state the benefits of what you're advocating. You don't seem to be able to do that.

⬐ pohl

Redundancy is an argument against braces, not in favor.

I disagree. I know that the word "redundant" sometimes carries a negative connotation, but the truth is that it is a mere property whose value depends upon the context and associated tradeoffs.

Spacecraft have redundant systems, but those systems are far from superfluous.

Human languages have built in redundancies. Generally they are there for ensuring communication still happens in a noisy environment.

My music CDs have redundancy in the encoding, and thankfully at that: after years of accumulating scratches I could still rip them without loss of quality. Redundancy was a positive here too.

Redundancy is a tradeoff, not an automatic downside.

⬐ nailer

Agreed about context, but let's be clear: spacecraft and music CDs have redundancy to prevent loss.

What loss are you preventing by requiring blocks be delimited twice?

Have you considered that inconsistencies due to repetition are frequently themselves cites as a cause of data loss?

Ever had code that looks good to you but doesn't parse because a machine is expecting an extra bracket?

⬐ pohl

I'm no rocket scientist, but I'm pretty sure that not all redundancy in spacecraft is aimed at preventing data loss. If you look closer you'll see redundant gyros for attitude control, redundant sources of power (solar panels, fuel cells) and probably numerous redundancies in environmental subsystems on the ISS (air, water, waste), and even redundant explosive bolts for stage separation.

I think jacquesm already mentioned the value of the redundancy above: you will never have a situation where a change in indentation leaves you with a runnable, but semantically-different program when you pasted code from a forum or from a machine with different tab settings. Note how the missing-bracket case in your last question is superior to this: a missing bracket offers fail-fast detection of the problem. If you indent a line wrong your program may still run, but differently: indent the last line of a block at the wrong level and it may happen after a loop rather than inside a loop.

The indentation is for the person. The braces are for the compiler. I like this, personally. I understand how some may prefer the python way (it has a superficial elegance, after all). But I personally don't like the downsides that jacquesm mentioned.

⬐ nailer

'you will never have a situation where a change in indentation leaves you with a runnable, but semantically-different program when you pasted code from a forum or from a machine with different tab settings.'

In that situation, with any computer language, you'll have an unreadable program. In Python, you'll need to fix the readability before the program will execute - which is a win to me.

⬐ pohl

I'll admit I don't know what magic the Python interpreter is capable of. I was imagining cases where an indentation change does not break readability:

    for foo in bar:
        foo.fizzle()
    baz.wibble()

...versus...

    for foo in bar:
        foo.fizzle()
        baz.wibble()

...how would it know that I wanted to wibble the baz every time I fizzle a foo, as opposed to wibbling the baz only after all foo have been fizzled?

⬐ nailer

Because you've told it to by making your data look correct.

Python executes your data the same way you yourself parse it: by how it appears. Brace requiring languages execute your data using different rules than you use to parse it.

Redundancy of logic is universally known to be a poor engineering practice.

⬐ pohl

Tortoise: I'd like a bicycle helmet, please.

Achilles: Why do you want to wear a helmet?

Tortoise: So that I won't hurt my head if I bump it.

Achilles: You won't bump it.

Tortoise: Suppose I do.

Achilles: You won't bump your head.

Tortoise: But suppose, hypothetically, that I fall off my bike and bump my head. What would protect it from injury?

Achilles: Your head is not injured, because you didn't bump it.

Tortoise: But that's the very basis of my hypothesis!

Achilles: Yeah, I'm going to just ignore you said that, and tell you again that you won't bump your head.

Tortoise: How do you know?

Achilles: Because you made sure that it didn't come into contact with anything.

Tortoise: Good night, dear Achilles. May you encounter others like you.

⬐ nailer

Sorry poor Tortoise, you're putting words into Achilles mouth.

Fortunately, Python gives you:

* A helmet. It won't parse unblocked code like any other language.

I'm not sure why you think blocking a second time with brackets would improve things or avoid this risk. But hey, if you want to wear a second helmet, that's cool. May you encounter others like you. :^)

* A mirror where things are as large as they appear (the blocking looks like it executes), unlike other languages where these can get out of sync and cause problems. If you enjoy this risk, that's awesome. High five.

* A handy warning light should you accidentally stray too far to the wall (Python will telling you that your readability is broken at the same time it tells you your blocking is - and you only need one fix). If you'd prefer not to be told about this, two places to fix things, and enjoy receiving badly written code, that's your prerogative and who am I to say anything other than that it's not mine.

Achilles: Nice bike and helmet.

Tortoise: No!

Achilles: Er, ok. Could you explain?

Tortoise: I need to get a helmet!

Achilles: You're already wearing one.

Tortoise: But what if I fall?

Achilles: You're wearing a helmet, which will protect you.

Tortoise: But I need to get a helmet.

Achilles: No you don't, you're wearing one. Oh and by the way, you need to be visible at night. The helmet's reflective, so you probably don't want to cover it with another ...

Tortoise: You're not listening to me!

Achilles: I am listening, but I'm also disagreeing. Are you listening to my disagreement?

⬐ praptak

> Any chance you could please ditch the brace requirement?

Wearing braces is optional. It's only the beards that are mandatory.

We (the Go team) all work at Google :) See also http://www.youtube.com/watch?v=rKnDgT73v8s

⬐ messel

Thanks Adam.