I wasn’t referring to the mixed tab/space issue. I mean you copy a few live
that are at one indentation to another location with a different indentation -
everything is mucked up usually. You don’t have these issues with brackets -
the code is easily formatted correctly or a bracket added then
On Monday, March 1, 2021 at 9:36:57 AM UTC+13 ren...@ix.netcom.com wrote:
> I think the only time the indentation is a problem is when refactoring
> code - copying pasting code blocks seems to be a guessing game with my IDEs
> and often require manual fixes - the issue seems far less common
On Sun, 2021-02-28 at 10:11 -0800, Bob Alexander wrote:
> I never have understood the *serious* hatred of Python's "indentation
> as syntax" approach. I've used lots of bracketed and begin/end
> languages (C/C++, Algol & relatives, Ruby, and most other programming
> languages), and when I write
I think the only time the indentation is a problem is when refactoring code -
copying pasting code blocks seems to be a guessing game with my IDEs and often
require manual fixes - the issue seems far less common (and more easily
corrected) when using brackets.
> On Feb 28, 2021, at 12:12 PM,
I never have understood the *serious* hatred of Python's "indentation as
syntax" approach. I've used lots of bracketed and begin/end languages
(C/C++, Algol & relatives, Ruby, and most other programming languages), and
when I write code in those languages I usually indent as I write.
Obviously,
Popularity has nothing to do with good - thus Twitter and the Kardashians. .
> On Feb 28, 2021, at 2:35 AM, 'Dan Kortschak' via golang-nuts
> wrote:
>
> On Sun, 2021-02-28 at 09:23 +0100, Jan Mercl wrote:
>> I meant, for example, in regexp notation, ` *` vs `\n *` between a
>> function
On Sun, 2021-02-28 at 09:23 +0100, Jan Mercl wrote:
> I meant, for example, in regexp notation, ` *` vs `\n *` between a
> function signature and the opening brace of the function body.
Ah, yes.
> This assumes newline is a whitespace. Most programming languages
> agree, but humans may not.
With
On Sun, Feb 28, 2021 at 9:05 AM 'Dan Kortschak' via golang-nuts
wrote:
> I'm curious where the meaningful whitespace is in Go (for amounts
> differences in number greater than 1).
I meant, for example, in regexp notation, ` *` vs `\n *` between a
function signature and the opening brace of the
E.g. compare
a = 1
b = 2
And
a = 1 b = 2
They do no mean the same in Go.
Arnaud
On Sun, 28 Feb 2021, 08:05 'Dan Kortschak' via golang-nuts, <
golang-nuts@googlegroups.com> wrote:
> On Sun, 2021-02-28 at 08:40 +0100, Jan Mercl wrote:
> > Actually Go has that problem as well, just
On Sun, 2021-02-28 at 08:40 +0100, Jan Mercl wrote:
> Actually Go has that problem as well, just a thousand times smaller.
I'm curious where the meaningful whitespace is in Go (for amounts
differences in number greater than 1).
> FTR, I also think Python's approach to white space is a failure.
On Sat, Feb 27, 2021 at 10:37 PM Bob Alexander wrote:
> Try removing all the space from your post and see how understandable it is,
> or remove all indentation from a Go program, etc. (Hmm, that would make
> formatters a lot easier to write... )
Removing all spaces makes most languages
Well, it seems that you don't like Python any more :) But I do like it --
and I like Go too. I'd guess that lots of other folks have figured out
positive answers to your Python issues, 'cause Python ranks high on the
popularity lists. E.g on the issue of invisible characters having semantic
Don’t bother… Python is an abomination. Perfect for one-off scripts - anything
beyond that steer clear.
> On Feb 27, 2021, at 12:59 PM, Amnon wrote:
>
> I liked Python too.
> But I never really understood why anyone though that dynamic typing was a
> good idea.
> Or why performance was so
I liked Python too.
But I never really understood why anyone though that dynamic typing was a
good idea.
Or why performance was so pathologically bad,
or why they decided to make invisible characters semantically significant,
or why python applications were so fiendishly complicated to deploy,
or
Thanks, Amnon, for that well known quote from the Python world. Python has
been one of my favorite languages for around 20 years. Even had the honor
of meeting Guido while we were both working at Google a while back.
Please, Python, do not integrate a dependency management system into your
*There should be one-- and preferably only one --obvious way to do it. *
>From the Zen of Python.
But also good advice for Gophers.
On Friday, 26 February 2021 at 01:03:00 UTC skinne...@gmail.com wrote:
> I have a wonderful video of a GO program I wrote over 5 years ago which
> will not
I have a wonderful video of a GO program I wrote over 5 years ago which
will not compile today due to my failure to vendor one lost module. I too
had multiple paths in my GOPATH and it varied upon the client. I consider
the new modules an improvement but the adaptation has not been without
Given the writing on the wall that GOPATH is going away, what I have done
is created a single module where I keep all my own code, each different
experiment in its own subdirectory. I named it "github.com/...", but never
submitted it to github, so in the future I can do that without too much
fuss
Agreed -- module mode is great for "delivered code". But in a personal
single machine single developer environment, all the extra complexity and
manual overhead might not worth it. I'd guess that most students and
hobbyists don't even use SCMs. My point was that GOPATH mode is good for
them.
On
That is 100% true but a important point is that using GOPATH requires manual
dependency management via ‘vendoring’. This can be very labor intensive and
error prone - leading to security issues in your delivered code.
> On Feb 25, 2021, at 3:08 PM, Bob Alexander wrote:
>
>
> GOPATH mode
GOPATH mode does *not *limit your Go code to a single directory. I've seen
this misunderstanding stated in probably hundreds of various posts.
$GOPATH allows specification of multiple directories. I've used that
capability for several years to distribute my Go code to my personal
general library
21 matches
Mail list logo
