On May 22, 5:00 am, Michele Simionato <michele.simion...@gmail.com> wrote: > On May 21, 4:20 pm, Grant Edwards <inva...@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 -- http://mail.python.org/mailman/listinfo/python-list