Another "Go is Python-like" article.
in [Python]
|
From: Patrick Maupin on 22 May 2010 15:13 On May 22, 5:00 am, Michele Simionato <michele.simion...(a)gmail.com> wrote: > On May 21, 4:20 pm, Grant Edwards <inva...(a)invalid.invalid> wrote: > > > What about Go, exactly, do people see as Python-like? > > The philosophy of keeping things simple. I find the concurrency > mechanism quite Pythonic. That's nice. > Moreover Go interfaces are quite akin to Python duck typing, but > better. That's nice too. > There also things which are quite different from Python e.g. > the attitude towards exceptions. That's a biggie. One of the beautiful things about Python is how it lets me incrementally deal with incompletely specified problems -- "here's some source data -- go do something useful with it". The FAQ discusses why the go language deliberately leaves out assert -- the developers rightly view assert statements as problematic in achieving 5 nines in a server environment, and they (somewhat incorrectly IMO) view them as problematic when testing things. Looking at their rationale, it is appears that one or more of the primary go developers had to deal way too often with people who overuse and abuse exceptions, so they are reverting to an almost childish "I'll fix their little red wagon! When they have to use *my* language, they won't be able to do that anymore!" kind of mentality. Another possibility is that they viewed the complexity of exceptions as interfering with their primary goals, and felt it necessary to rationalize their absence after the fact. For some kinds of programming, the lack of exceptions wouldn't keep me from programming Pythonically, but for huge classes of problems, it would. That's a big deal for me personally -- although I like to have lots of tools in my toolbox, the one I reach for when doing exploratory programming is probably going to have exceptions. And guess what? If the exploratory programming winds up being "good enough" (as often happens), then no recoding is required. > In theory Go should be akin to C, > but my gut feeling is that in practice programming in it should not > feel too much different from > programming in Python (but I do not have first hand experience). For well-specified problems, I might be able to agree with you, but I'm not sure. Even then, sometimes I build stuff incrementally, trying out various kinds of internal interfaces. During that development process, exceptions are a valuable mechanism for ensuring that both sides of an interface agree on the contract. (Obviously, unit testing is useful in this as well, but premature unit testing can add friction that makes it difficult to converge on an optimal design -- it's no fun to be continually rearchitecting unit tests because of other design decisions.) What will be interesting to see is if a culture develops inside google where people prototype in Python or some other language and then implement the final cut in go. If this happens often enough and the cost of recoding the final implementation is deemed high enough, then the natural question will be "What can we add to go to make it a better prototyping language?" Regards, Pat
From: Steven D'Aprano on 22 May 2010 19:14 On Sat, 22 May 2010 12:13:30 -0700, Patrick Maupin wrote about the lack of exceptions in Go: > Looking at their rationale, it is appears that one or more of the > primary go developers had to deal way too often with people who overuse > and abuse exceptions, so they are reverting to an almost childish "I'll > fix their little red wagon! When they have to use *my* language, they > won't be able to do that anymore!" kind of mentality. Another > possibility is that they viewed the complexity of exceptions as > interfering with their primary goals, and felt it necessary to > rationalize their absence after the fact. That's two possible explanations. A third is that they genuinely believe that exceptions lead to poor programming practice and left them out, just as the designers of many other languages believe that goto leads to poor practice and leave it out as well. I don't think there's necessarily anything "childish" about choosing to leave out a language feature that you think is bad from a language you design. Indeed, when I design my killer language, the identifiers "foo" and "bar" will be reserved words, never used, and not even mentioned in the reference manual. Any program using one will simply dump core without comment. Multitudes will rejoice. -- Tim Peters, 29 Apr 1998 -- Steven
From: Patrick Maupin on 22 May 2010 20:58
On May 22, 6:14 pm, Steven D'Aprano <st...(a)REMOVE-THIS- cybersource.com.au> wrote: > On Sat, 22 May 2010 12:13:30 -0700, Patrick Maupin wrote about the lack > of exceptions in Go: > > > Looking at their rationale, it is appears that one or more of the > > primary go developers had to deal way too often with people who overuse > > and abuse exceptions, so they are reverting to an almost childish "I'll > > fix their little red wagon! When they have to use *my* language, they > > won't be able to do that anymore!" kind of mentality. Another > > possibility is that they viewed the complexity of exceptions as > > interfering with their primary goals, and felt it necessary to > > rationalize their absence after the fact. > > That's two possible explanations. A third is that they genuinely believe > that exceptions lead to poor programming practice and left them out, just > as the designers of many other languages believe that goto leads to poor > practice and leave it out as well. > > I don't think there's necessarily anything "childish" about choosing to > leave out a language feature that you think is bad from a language you > design. While I admit that "childish" is an inflammatory simplification, other than that, I think that your possible explanation is, essentially, identical to my first possibility -- why would you think exceptions were bad if you didn't have first-hand evidence of that? Regards, Pat |