8 ms·
The article mentions “Simple is better than complex”, but not the next line of the Zen of Python, which I think tells us a lot about that language’s philosophy:
by pansa2 7y ago
The article mentions “Simple is better than complex”, but not the next line of the Zen of Python, which I think tells us a lot about that language’s philosophy: “Complex is better than complicated”.
Looking closely, that line says “(not simple) is better than (not easy)”, or more clearly, “easy is better than simple”. Python definitely lives up to this - it’s easy to get started with, but if you look deeply it’s a very complex language.
Go’s philosophy is probably the opposite - that simple is better than easy. This is similar to the philosophy of Clojure, as explained by Rich Hickey in “Simple Made Easy” [0].
[0] https://www.infoq.com/presentations/Simple-Made-Easy/ https://www.infoq.com/presentations/Simple-Made-Easy/
- bjornjajajaja 7y agoIt would be nice to have “elegance” brought into the picture too. Code is an art as well!
- aequitas 7y agoUnless your building a user facing frontend please keep art out of your code. Just like a bridge internal's concrete structure doesn't need decoration so does your backend's plumbing. Writing elegant and artful code that is hard to understand and debug does not make you a clever developer. Keep that stuff for the demo-scene or 99-bottles-of-beer. Go is an language for engineering software, not crafting.
- rat9988 7y agoI have seen uncharitable interpretations, but this one is one one of the worst.
- crazyjncsu 7y ago> Writing elegant and artful code that is hard to understand and debug does not make you a clever developer The whole purpose, to me, of artfulness in code is to take unartful, hard to understand code and make it simple. What other objective is there?
- skywhopper 7y agoYou have a depressingly narrow view of what "art" can mean.
- fastball 7y agoWhat exactly are you picturing when someone says "elegant" or "artful" code? To me, elegant code is DRY code. Elegant code is code with useful abstractions where needed, and no abstractions where they just complicate matters. Code that is succinct yet clearly communicates its purpose. From the sounds of it, you have an entirely different conception of what elegant code looks like.
- gtf21 7y agoThis seems to have totally missed the first half of the comment to which you replied: _elegance_ certainly has a place in programming, just as it does in mathematics and many other disciplines. Things that are elegant are often difficult to conceive, but easy to understand being simpler solutions to a problem than something inelegant.
- tpmx 7y ago(I don't necessarily disagree, but...) It's probably changed a lot since, but at least back in the 90s demo-scene code was absolutely 100% written for the result alone, even perhaps when it should perhaps have been say 75% for the sake of reusability. Imagine "decent" 90s game code quality, then dial the qualitynotch down a bit, since it will only have to work once on a well-defined machine anway. I'm long since tuned-out. I do seem to remember Farbrausch making some waves when they started applying the concept of reusability and structure to their work in the early 2000s.
- njharman 7y ago> Writing elegant and artful code that is hard to understand You do not know the meaning of elegant. At least in context of programming and maths.
- Koshkin 7y ago> Unless your building a user facing frontend please keep art out of your code. Honestly, I had rather art be kept out of the user facing frontend. (Computer programming, on the other hand, is considered art by some computer scientists.)
- bjornjajajaja 7y agoHonestly if a solution is too hard to understand and debug then it is not elegant. Elegance is turning a complicated solution into an easier-understood one. Clever solutions could be elegant but they could also be shortcuts that are confusing and cause more harm than good. There’s definitely a difference.
- todotask 7y agoI just read Eric update quite recent on CSP. https://gitlab.com/esr/reposurgeon/-/blob/master/GoNotes.adoc https://gitlab.com/esr/reposurgeon/-/blob/master/GoNotes.ado... "Translation from Python, which is a dreadful language to try to do concurrency in due to its global interpreter lock, really brought home to me how unobtrusively brilliant the Go implementation of Communicating Sequential Processes is. The primitives are right and the integration with the rest of the language is wonderfully seamless. The Go port of reposurgeon got some very large speedups at an incremental-complexity cost that I found to be astonishingly low. I am impressed both by the power of the CSP part of the design and the extreme simplicity and non-fussiness of the interface it presents. I hope it will become a model for how concurrency is managed in future languages."
- d0mine 7y ago> dreadful language to try to do concurrency in due to its global interpreter lock don't take it too seriously. GIL has its issues and it would be nice to see it gone but "dreadful" is an overstatement. Python wouldn't be so widely used as a back-end language otherwise. Concurrency is not parallelism. On "it [Go] will become a model for how concurrency is managed in future languages." -- it is not as clear cut as it appears at the first glance: "Notes on structured concurrency, or: Go statement considered harmful" https://vorpus.org/blog/notes-on-structured-concurrency-or-go-statement-considered-harmful/ https://vorpus.org/blog/notes-on-structured-concurrency-or-g...
- murphy214 7y agoDreadful may be a little strong but anytime I've tried to implement something like asyncio for a non trivial piece of code it becomes pretty obtuse. (imo)
- fjp 7y agoI’ve found asyncio to be a very simple model to understand, using the aio libs: aiohttp, aiopg, aiobotocore, etc. Basically just slap “async” or “await” in front of everything and understand that anytime there is a network connection being accessed, that method will release control of the main thread. You just have to pay attention to where something might block the thread for any significant amount of time - heavy calculation or lengthy file IO You can spawn a multitiude of async tasks on startup and have super basic “scheduling” by using asyncio.sleep with some jitter. The only time I have seen the performance limits of a naive asyncio app reached was in an auth app that sat in front of every API request for the whole company, and even then it was an obscure DB connection pool management issue deep in psycopg2.
- masklinn 7y agoDon't forget this absolute banger: > Obviously Go chose a different path. Go programmers believe that robust programs are composed from pieces that handle the failure cases before they handle the happy path. A function which only returns an error can have its result ignored without any warning.
- throwaway894345 7y agoI don’t think that paragraph was referencing compiler guarantees.
- coldtea 7y agoIt should refer to them or address them. Since, given this, Go is no better than a language with unchecked expressions nobody handles...
- stouset 7y agoThere’s other reasons too! I’ve written the following: if v, err = func(); err != nil { nil, err } … and then went on to use `v`. Thanks to `v`s zero value being legitimate (and not nil like a pointer would be), the program continues on as if everything is okay. In case you didn’t catch it, I forgot the `return`. Rust takes a much better approach with Result, where the return value is either `Ok(v)` or `Err(e)`, and there’s no way to access a meaningless value for the other possibility.
- coldtea 7y agoYeah, and this is so simple a change (compiler wise) and far more stronger a guarantee I don't see why Go didn't implement it... At least then errors as return values would be solid. Of course now they make programmers do all the extra error wrapping thing in 1.14 to pass "richer" errors...
- pm90 7y ago