2 ms·
The thing is... that's all the major languages. Even the ones that aren't necessarily like that, the culture / style ends up like that. The Python I'll write an
by morelisp 5y ago
The thing is... that's all the major languages. Even the ones that aren't necessarily like that, the culture / style ends up like that. The Python I'll write and pass review at work is vastly different than the Python I would like to write, because I know the next person isn't going to understand my brilliant __metaclass__ and nested decorator approach that cuts 10k of imperative bullshit down to 20 lines - or worse they will understand it enough to make a change that causes an unacceptable performance degradation and not enough to realize that they did it.
There's the famous line from GLS about Java:
> We were not out to win over the Lisp programmers; we were after the C++ programmers. We managed to drag a lot of them about halfway to Lisp.
And probably there's some equivalent idea about Go not trying to win over the Clojure programmers, but rather dragging the enterprise Python/Ruby/JS/Java programmers halfway to C.
- oalae5niMiel7qu 5y ago> my brilliant __metaclass__ and nested decorator approach that cuts 10k of imperative bullshit down to 20 lines - or worse they will understand it enough to make a change that causes an unacceptable performance degradation and not enough to realize that they did it. That's just Python and its endless edge cases, caused by everything being special-cased into the interpreter. If you were using Lisp, the macro equivalent of your ________dunder________ method would likely have no edge cases, so the next guy who makes a change with only a partial understanding wouldn't end up introducing that performance degradation.
- morelisp 5y agoWith Lisp, the performance comes pre-degraded!
- oalae5niMiel7qu 5y agoMaybe compared to C++. Lisp outperforms Python.