3 ms·
I think Go has many fun features. However, to argue that its easier to write "good" code, is hyperbole of the highest order. A programming language is a brush
by KaiserPro 8y ago
I think Go has many fun features.
However, to argue that its easier to write "good" code, is hyperbole of the highest order.
A programming language is a brush with which to paint your logic. If your picture is murky its because you, the programmer has made it murky.
There are many tradeoffs with "good" code. Readability, speed, compactness, modularisation, use of libraries. As with any other practical subject, your skill comes from practice. Yes, new tools can make it _easier_ to be more efficient, or faster. They might even badger you into good habits.
But
They cannot make you "good". Its the expensive camera fallacy. Sure a Medium format SLR will take _spectacular_ pictures, but only if you use it properly. A good photographer will be able to take wonderful images using a camera phone from 2006.
- adrianN 8y agoSure, a great mechanic can use a hammer to drive a screw, but they usually choose more appropriate tools.
- KaiserPro 8y agoyeah, they'd use nails. Which underscores my point. When you are building a table in real life you make it all from one or two materials. You'd keep to one or two types of fasteners, because its simple quicker an easier. You don't change halfway through from turned oak to carbon fibre, "because its higher performance." unless you have a bloody good reason to change. Sure I've used screws as nails, it works pretty well, but we all know its a dirty hack.
- Rapzid 8y agoIt's worse to use nails as screws IMHO, but I digress.
- KaiserPro 8y agoTo underscore the point: The Python code snippet del a[i] deletes the element at index i from a list a. This code certainly is quite readable, but not so transparent: it’s easy to miss that the time complexity is O(n), where n is the number of elements in the list. Go doesn’t have a similar utility function. This is definitely less convenient, but also more transparent. Your code needs to explicitly state if it copies a section of the list. See 2 ways to delete an element from a slice for a Go code example. I think this assertion is wrong. del in python does exactly what it says it does. There are precisely three reasons to not use del: o Because you have written your program, got all the low hanging performance fruits, and now need to optimise how you delete from (large) lists, and dequeue doesn't work for you o you are arrogant and want to show everyone how clever you are because you understand how list operation are handled under the hood. So you have written your own. o a.remove()/a.pop() you think is more readable. It is far more important to be readable than to be fast in 90% of cases. If we all really cared about speed, then React/electron/et al would never be a thing.
- zaphar 8y agoReact is actually faster than most other approaches. It was created because it was a DSL for faster and more performant DOM updating.
- KaiserPro 8y agoI think you're missing my point here. Firstly all of it is far slower than a native toolkit. secondly client side DOM rendering is almost never fast, compared to server side HTML/CSS.
- chrismorgan 8y agoPlease do not use code formatting for quotations. Use the old de facto standard of a “> ” prefix. Please also don’t use it for lists; just leave two blank lines between each point, so that they’re in their own paragraph.