31–40 of 112 posts
Earlier quoted context omitted.
It makes me think of getting rid of OOP and saying goodbye to the overengineering overhead it involves. 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.
But Go doesn't get rid of OOP, it just fixes it.
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.
The problem is it's no better than C
What sort of development environment are others here using for go (if using it at all, of course) ? I've had reasonably good experience with the go-mode in emacs.
Sublime Text 2 + GoSublime has been a really great experience for me. http://www.sublimetext.com/2 https://github.com/DisposaBoy/GoSublime
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).
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.
C's multiple-arguments-but-only-one-return-value always was a bit weird. Does anyone know how C's authors decided on this feature?
Nowadays, polyglot approach is the only right path for a software company. When I arrived in Berlin a month ago, I was positively surprised that SoundCloud supports local Clojure or functional programming groups. Keep up with great work!
Earlier quoted context omitted.
it's not there there's no error handling; it's that there's no exceptions. Instead, you use multiple return values, one of which is an error, and you check the return value for an error. It forces you to handle errors at the call site and makes diapers unimplementable.
How does it force you to handle errors? Cant you choose to ignore the return value?
go's error handling is nice, but since it doesn't force it on you, it leads to errors of omission.
Earlier quoted context omitted.
I agree. For some reason the whole OOP thing got really out of hands and has been force fed into a whole generation of programmers. Yet there's no real evidence that OOP is the right way to go. And then there was the whole Java deal where the "everything is an object" mantra was taken so far that it hurts. The result is probably the most expensive mistake in the history of computing with machines. > UPDATE: I have a…
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.
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 presentation).
Earlier quoted context omitted.
It makes me think of getting rid of OOP and saying goodbye to the overengineering overhead it involves. 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.
...Go still has objects. It's not the notion of binding functions to data that's flawed; it's classical inheritance that's flawed.
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.
Sublime Text 2 + GoSublime has been a really great experience for me. http://www.sublimetext.com/2 https://github.com/DisposaBoy/GoSublime
Interesting that sublime text comes up. I have been looking for a "bells and whistles" sort of IDE for python for a few days now, I am traditionally a unix person so I have moved along nicely with both vim and emacs as needed, but at this point I need to work with a full featured IDE. 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…
I think for experienced devs, a text editor is quicker for dynamic languages (less experienced people will get good mileage from an IDE). Go is sort of weird in that it reads like a dynamic language, so a text editor is Good Enough, while the static compiler helps to catch the sort of bugs that float up when you're doing manual (and hence, human-error-prone) refactoring work, like changing the type of something, which IDEs tend to automate for you before compile time. That's why GoSublime really is all you need for Go, as far as I can tell. (NOTE: I've not written anything like even a medium project in Go).