With respect, you are tilting at windmills. You replied to an 8 year old post from the design phase of the language. It's now 2017 and no-one wants to step back in time to change what has turned out to be a very successful design. You stated in your first message that you "simply won't use the language" because it doesn't conform to your learned preferences. I hope you reconsider and adapt to what is ultimately a minor part of learning a new language. Ian
On Mon, 24 Apr 2017, at 03:42 PM, john.deig...@gmail.com wrote: > One of the things that I learned early in life is to recognize B.S. > when I see it. My B.S. flag went up first when I read where someone > claimed that "artifacts" are bad and detract from the readability of > code. A compact and well-defined artifact, like the semicolon, makes > code *more* readable because the programmer's intent is crystal clear, > whereas removing them leaves one guessing exactly where a line ends. > The rules are considerably more complex - not to mention vary across > languages, than the simple "it ends at the semicolon" rule.> > Now I read that the programmer's preference is irrelevant (I hope that > we can agree that the programming community consists of individual > programmers!). Well, that flag just shot up again. There's no reason > that an individual's preference can't be respected when he's editing > code, even if way that the code is stored on disk is the same. That's > why I exclusively use TAB characters for indentation - some people > prefer to see 2 spaces per level of structure, I prefer 3 spaces and > someone at my company prefers 8. We get to see what we prefer without > requiring any changes to the code itself.> > So, here's my current thinking about long lines/continuation lines, > take it for what it's worth. There should be no such thing in a > language. A long line should just be a long line, without limit, in > the source file. After all, it's not the compiler that wants to split > long lines so that they are more readable - it's the programmer when > using a text editor or code viewer. Think how much simpler a compiler > would be if it could just assume that a simple (i.e. non-compound) > statement always exists on a single line! It's the editor that should > display a single simple statement on multiple lines on the screen. In > fact, the editor could provide visual cues that a single statement is > being displayed on multiple lines on the screen, such as a light gray > background color, underlining, box around it, whatever. The point is > that the individual programmer's personal preference would be used > without affecting the saved format of the code.> > For that to work well, the editor would probably have to understand > the syntax of a statement so that the line splitting will result in > something that the programmer finds readable. I don't know if a > current editor that can do that. But line splitting is something that > the compiler should *not* have to deal with. After all, it's the > programmer using an editor that cares about making long lines > readable, not the compiler.> > -- > You received this message because you are subscribed to the Google > Groups "golang-nuts" group.> To unsubscribe from this group and stop > receiving emails from it, > send an email to golang-nuts+unsubscr...@googlegroups.com.> For more > options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
