3 ms·

This article correctly asserts that advanced programming techniques aren't invalid because less experienced developers don't immediately comprehend how they wor

This article correctly asserts that advanced programming techniques aren't invalid because less experienced developers don't immediately comprehend how they work. But from a business standpoint, it is still important. If you are the senior developer and all of your team are fresh out of college, it might be counterproductive for you to go crazy with programming "magic". The examples given of what isn't magic (inheritance, extensions, monkey patches) are completely arbitrary. The truth is that it isn't magic to some developers and it is to others, and you need to know who's reading your code. In the same vein, there are plenty of operations that can be done with arithmetic only (obviously not magic, right?) whose purpose is completely incomprehensible to anybody who didn't write it. Most of these will also be incomprehensible to the author after a period of weeks or months. The same goes for complex sed or regex expressions or a million other one-liner tricks that we nerds love so much. Even if I don't expect anyone other than myself to ever read the code (no, make that especially if it's just for me) I write a brief comment with some explanation of what it does. Or maybe wrap it in a semantically accurate function. I did a little bit of Ruby/Rails about 10 years ago, and this article also reminds me why I have avoided Ruby since, coming to down to this (non)quote: > As Matz says (reciting from memory), “Ruby is complex language to make developer’s life simple”, not the other way round. Ruby claims to make the developer's life simple by being complex, which in my opinion is just backwards reasoning. You lost as me at "parentheses are optional". I'm not even a Python guy at all but I'll go back to my favorite truism from the Zen of Python: explicit is better than implicit. Give a team of nerdy programmers too many routes to the same goal and you're guaranteed to end up with a bunch of code that nobody understands.

imiric 5y ago
> I'm not even a Python guy at all but I'll go back to my favorite truism from the Zen of Python: explicit is better than implicit. The Zen of Python is more of a meme than a list of guiding design principles of the language. This explicit over implicit one in particular. Python does things very implicitly. It encourages operator overloading, so you're never really sure what `a + b` does without seeing the `__add__` implementation. Same for `len()`, `str()` and a few others. Metaprogramming is also considered an advanced topic and used extensively in the wild. Python programmers love implicit behavior and building abstractions that hide the complexity away. It's kind of what the language is about, so being explicit over implicit is rarely followed. Similarly for the other points in the Zen. "There should be one obvious way to do it" is an internal joke; the Dutch line following it is the punchline. While it doesn't follow Perl's extreme TMTOWTDI mantra, there are often many non-obvious ways of doing the same thing in Python. See `str.format()`/`%`/f-strings, for loop/comprehensions, enum implementations, the packaging mess, etc. A language that follows explicit over implicit and one way of doing things is Go, where you're actually forced to do things a certain way because of the design simplicity. Granted, not everything, as generics are now a thing, and modules were a mess for a long time, but it mostly follows Python's Zen more than Python.
tuckerman 5y ago
Ruby definitely is divisive with some of its opinions and I much preferred working in large python/c++ codebases than Ruby, but in my personal life for side projects and (especially) for DSLs, I find working with Ruby a real treat. For the latter case in particular, having multiple ways of expressing constructs, including omitting parens, means that you can create very expressive DSLs that are understandable to non-engineers while still being "just code", allowing advanced users to get things done without too much work.

imiric 5y ago

> I'm not even a Python guy at all but I'll go back to my favorite truism from the Zen of Python: explicit is better than implicit. The Zen of Python is more of a meme than a list of guiding design principles of the language. This explicit over implicit one in particular. Python does things very implicitly. It encourages operator overloading, so you're never really sure what `a + b` does without seeing the `__add__` implementation. Same for `len()`, `str()` and a few others. Metaprogramming is also considered an advanced topic and used extensively in the wild. Python programmers love implicit behavior and building abstractions that hide the complexity away. It's kind of what the language is about, so being explicit over implicit is rarely followed. Similarly for the other points in the Zen. "There should be one obvious way to do it" is an internal joke; the Dutch line following it is the punchline. While it doesn't follow Perl's extreme TMTOWTDI mantra, there are often many non-obvious ways of doing the same thing in Python. See `str.format()`/`%`/f-strings, for loop/comprehensions, enum implementations, the packaging mess, etc. A language that follows explicit over implicit and one way of doing things is Go, where you're actually forced to do things a certain way because of the design simplicity. Granted, not everything, as generics are now a thing, and modules were a mess for a long time, but it mostly follows Python's Zen more than Python.

tuckerman 5y ago

Ruby definitely is divisive with some of its opinions and I much preferred working in large python/c++ codebases than Ruby, but in my personal life for side projects and (especially) for DSLs, I find working with Ruby a real treat. For the latter case in particular, having multiple ways of expressing constructs, including omitting parens, means that you can create very expressive DSLs that are understandable to non-engineers while still being "just code", allowing advanced users to get things done without too much work.