How would you make something like a GUI without being able to specialize classes by overriding certain methods?
Have I misunderstood his point?
The only situation you positively need operator overloading is when doing arithmetic, and you should do that using the built in types. This, of course, sucks when the built in types are inadequate, and you e.g. want to use a arbitrary precision library such as BigDecimal in Java.
This, of course, is an opinion, and I'm not shy to admit it's been shaped by being burned by Lift, the Scala web framework which makes heavy use of symbolic function names which makes it incredibly difficult to talk about or search for answers online.
Those guys seem to manage the flexibility pretty well.
I personally like overloading, but I think it's probably too easy to abuse, and I can see how it would cause problems with a team size larger than 5.
As far as I can see, whenever the Go team encountered a language feature that could possibly be abused, they always deferred to leaving it out. Whether that is good or bad I'm not sure we will know until we have years of experience with it.
All features can be abused.
The Go philosophy is more to leave out features that obscure the meaning and understanding of code (what is also known as "magic").
Also part of the Go philosophy is to not include any feature unless it is clear that its benefits are greater than its costs, and which might interact in unpredictable ways with other existing features.
In other words, the default is to leave things out, rather than to include them, the opposite of a kitchen sink approach.
However, operator overloading is very much needed for when creating user defined types that have arithmetic properties, such as bigint, or matrix.
As for the confusion about whether + means "add" or "concatenate", that is unresolvable. The D programming language deals with it by introducing the ~ binary operator to mean "concatenate". No more problems.
Although in D one can overload operators to mean any crazy thing one wants to, the consensus in the community is to eschew non-arithmetic use in the same manner that the C community has condemned:
#define BEGIN {
#define END }In go you get polymorphism via interfaces and you can share implementation via embedding. http://golang.org/doc/effective_go.html#embedding
addClickHandler(myFunction)
In Go, there is also an "interface" which is basically a set of methods.
By reading the code "foo + bar" you can't know what is really doing internally.
He is talking about operator (+-*=[]&) overloading. Not method overloading.
http://code.google.com/p/goclipse/ https://github.com/nsf/gocode
I am using the evaluation version of pycharm and I must say it is quite impressive, although paying for an editor does seem odd after using emacs for so many years but it is a well designed software and I think worth the price.
That said I have been asked to give sublime text a try and I must say it looks a lot better than pycharm, I think will give it a try next (it is certainly a lot cheaper and if I understand correctly has much wider language support than pycharm).
It took us 25 years to begin to see that the king is naked!
UPDATE: I have a feeling that in 25 years we'll be dissing the current fad du jour - functional programming.
> UPDATE: I have a feeling that in 25 years we'll be dissing the current fad du jour - functional programming.
In 25 years, we will be laughing at the present for sure. I just disagree on what that fad is (functional programming is hardly popular enough to be called a "fad", but it's been bubbling under for 30+ years). I think it is dynamic programming languages like Ruby and Python, which to some degree are great but fall apart quickly. Another candidate is Node.js -style asynchronous programming, which will be laughed at once a mainstream language ships with a proper async model like the IO manager of Haskell or Erlang.
Eliminating side effects sounds brilliant until you start interacting with filesystems or networks. What, you can't memoize those ops or split them across a pmap?
That king is an impostor. http://c2.com/cgi/wiki?AlanKayQuotes
> UPDATE: I have a feeling that in 25 years we'll be dissing the current fad du jour - functional programming.
Only if unwashed masses start doing a half-baked version of FP without really understanding it. This is what happened to OO. It's similar to what happens to musical genres.
especially, as most new engineers on Go projects lament, during error handling
..., err := doStuff()
if err != nil {
return err
}
When people say Go poor or no error handling, this is probably what they are complaining about. The fundamental properties offered by try/catch/throw are unpacked by Go into defer, recover and multiple value returns and type switches. Go's designers make the argument that when used thoughtlessly, exceptions encourages error handling antipatterns.
This requires some flow analysis, but brings real benefit and safety.
I don't see how the latter is true. What's the practical difference between wrapping a function call in a try/(no-op)catch and entirely ignoring the error return value?
I have always wondered, however, that if moving to a new language seems great because of the language, or because you have such a better understanding of the implementation of the problem you are trying to solve.
New is fun. Exploration is fun. I think a lot of people will swear by a new language simply because it's not old and probably doesn't suffer many of the same deficiencies they're used to in their "every day," language.
This to me is an illusion however. One must remain skeptical and treat new, untested languages with even more scrutiny than an old one. Many of these new languages will make extraordinary claims. Discovering the evidence to support these claims is often left as an exercise to the programmer.
That being said, new has a lot of advantages. It's free to try to break away from past paradigms that perhaps limited programmers. Stability can always come later once the core ideas have been fleshed out. And it's always fun to work on fresh ideas rather than refining the same old ones that we're plagued with.
Personally I wouldn't use a language and compiler that only just reached 1.0 this year in a production system. If I was really interested in Go I'd certainly hack with it and perhaps on it, but I wouldn't trust it to be reliable. Maybe that makes me an old, stodgy fart but I trust wisdom over brilliance when it comes to building systems that are dependable and robust.
With Go 1.0 there is an even greater focus on stability: http://golang.org/doc/go1compat.html
Go is also quite different from most 'new' languages, many people find it to be the most fun language they have used in a long time (even after using many other new languages).
This might be in part because one of the things that makes Go special (and my favorite "feature") is not just the features it has, but all the stuff it doesn't have.
Go is simple and doesn't get on the way and lets you focus on the problem, other "new" languages are often described as "powerful", but much of the work involves using their "features", when Go is more often described as productive, the focus is not in the language and its features but on the problem you are trying to solve and the language gets out of the way.
Certainly it deserves more faith than any random language designed for the exploration of new paradigms and features and which is only used by its maker?
Like any other compiled language would do.
Why would this bother you that they are trying new things and learning?
Where are the moving parts?
There's always many problems that aren't immediately apparent but difficult.
(Yes, I will commit to finish the rest of the series)