71–80 of 112 posts
I'm confused. I see the word "engineer" appear several times, but the company appears to offer MP3 recording technology and a "share" button. Where are the moving parts?
There's always many problems that aren't immediately apparent but difficult.
Earlier quoted context omitted.
It got out of hand, but it's still a rather nice paradigm if you're actually simulating a system or designing a GUI. Teaching it as the One True Paradigm is certainly bad, but it certainly has its uses.
> designing a GUI Not really. HTML/CSS/JavaScript combination is not really OO, but works really really well. In general, I think that any "programming language" for GUI is a fail - we need to develop a declarative approach to GUI (like HTML/CSS, but with more features (e.g. effects) and more emphasis on Application Development (e.g. it's still really hard to create a photoshop-like interface in HTML), less on text p…
HTML+HTTP works really well as a way to scale up client / server GUI over a high latency / low bandwidth network. That's its strong point; not that it makes for a good UI in terms of human factors.
Earlier quoted context omitted.
The argument is roughly that it is, in fact, not very useful, while opening up a vast array of misuses - especially in the domain of being all too clever. What does "+" mean on a list and an object? Add, probably. But what if it's two lists? Union? Or add the second list as the last element to the first? Named functions "add" and "union" aren't any less readable and loads more descriptive. The only situation you posi…
Of course, Go itself is completely unsearchable, so you always have to search for Golang, which means that thee mut be hundreds of pages that get missed.
Earlier quoted context omitted.
And how do you know what add(foo, bar) does internally?
add(foo, bar) isn't any clearer than foo + bar, but usually an overloaded operator doesn't correspond to "add". For example, in Javascript: "Hello" + " " + "World!". What the operator there is doing is concatenating the strings, so if you had a method to do it you wouldn't call it add - you'd call it concat.
especially, as most new engineers on Go projects lament, during error handling Does any have pointers to reading material or care to explain the lack of error handling in Go?
..., 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.
I'm still a bit of a novice, could someone elaborate on what he means by operator overloading being "problem creating?" I thought that was one of the main, 'core' concepts of OOP. Inheritance, and polymorphism. How would you make something like a GUI without being able to specialize classes by overriding certain methods? Have I misunderstood his point?
addClickHandler(myFunction)
In Go, there is also an "interface" which is basically a set of methods.
I'm still a bit of a novice, could someone elaborate on what he means by operator overloading being "problem creating?" I thought that was one of the main, 'core' concepts of OOP. Inheritance, and polymorphism. How would you make something like a GUI without being able to specialize classes by overriding certain methods? Have I misunderstood his point?
Earlier quoted context omitted.
Go doesn't "lack error-handling." They're referring to the fact that Go doesn't have exceptions; you check return codes to detect and handle errors. For some this is tedious, but has advantages (mentioned in the article) with respect to understanding an entire program.
The problem is it's no better than C - the correct way is to return sum types, either values or errors. A good language would statically check that any returned values are only used when there are no errors, preventing invalid values being accessed. This requires some flow analysis, but brings real benefit and safety.
Earlier quoted context omitted.
A well known and tested approach, sum types (tagged unions), would have been way better, but it was cast aside because the designers were apparently unaware of the improvements to union types made since C's inception: http://www.reddit.com/r/programming/comments/w1ig0/things_i_...
There is no reason for any new language to lack tagged union types. It disturbs me that Brian Cox rejects a simple, proven language feature that he does not even understand , even though it would take all of 2 minutes of searching/reading to understand. I'm sure he spent at least that long composing the replies in that thread, never moving past the ego-threat of "will Go ever have X?" to honestly evaluate the questio…
Earlier quoted context omitted.
How does it force you to handle errors? Cant you choose to ignore the return value?
You can absolutely ignore it. Or in the case of the Write call, which only returns an error, just never assign it. go's error handling is nice, but since it doesn't force it on you, it leads to errors of omission.