4 ms·

> Build compelling simplicity and performance will come. Python and Ruby are notable counter-examples to this. Both Python and Ruby were designed primarily fo

> Build compelling simplicity and performance will come. Python and Ruby are notable counter-examples to this. Both Python and Ruby were designed primarily for human-friendliness, as this essay advocates. Guido has described Python as "executable pseudo code". Matz has said that the primary purpose of Ruby is to make programmers productive and happy, and to design more for humans than for the machines. People have tried to make the performance come. Python is well-loved which has led to numerous attempts to accelerate it (Psyco, Unladen Swallow, PyPy). Many of these efforts have made notable progress, but none have met the bar of compatibility and performance necessary to displace the relatively slow cPython. Ruby is getting faster, but it's still among the slowest compared with its peers. There are other languages where the performance did come (JavaScript, Lua). But this is in no way a given.

AlexanderDhoore 12y ago
In the case of Javascript, the performance came at great cost. Javascript engines are monstrously complex. The language might be "simple", but the implementation is not. Lua on the other hand is probably fast because it is simple. There aren't many other programming languages like that. (C and Scheme maybe?)
- haberman 12y ago
  The Lua interpreter is among the fastest of languages in its class, but LuaJIT is also among the fastest JITs. I agree that a lot of this has to do with Lua being a simple language.
- jamii 12y ago
  The lesson from both of these is that performance doesn't magically come from simplicity but it is enabled by simplicity. A complex system is always hard to optimise. A simple system may be easy to optimise. Building simple systems whilst keeping performance in mind is a delicate balancing act. Local optimisations tend to add complexity that may prevent later optimisations. Sweeping generalisations that reduce implementation complexity often inhibit later optimisation due to lack of information (eg http://lucumr.pocoo.org/2014/8/16/the-python-i-would-like-to-see/ http://lucumr.pocoo.org/2014/8/16/the-python-i-would-like-to...).
perfunctory 12y ago
> Python and Ruby are notable counter-examples to this. I beg to differ. You seem to imply that Python is a simple language. Quite the contrary. Attempts to accelerate Python failed exactly because it's an extremely complicated language. Same goes for Ruby and JavaScript.
- haberman 12y ago
  This essay defines complexity like so: > We should measure complexity as the cumulative effort to learn and use a technology. Given that Python and Ruby are both simple to learn and use (as users, not implementors), they are both simple by the definition given in this article.
- mamcx 12y ago
  Python have a simple syntax, yet a complex implementation, so simplicity is not carried all along the path. A argument could be made this is in part the fault of C... because a state sub-goal of python is easy to integrate with C and back them the way they do it is complex, and because C is worse than python and a lot of code is made with it. So, you have a simpler language in top of a messy one (ie: In contrast with something like for example, pascal). The problem when try to make something simple is that carry the idea across boundaries/subsystem eventually break. If, for example, you wanna to make a performant language with clean syntax for a multi-procesor setup with intuitive behaviour, but, the base system/os/CPU not make it easy, you eventually need to break the simplicity along the way. This also touch the problem that to make something simple is necesary the skill and mastery across the whole problem. So perhaps python/ruby is like is because the authors are great at building a aproachable language but not at build the VM. You need to be both. Contrast with erlang. Amazing VM but whacky syntax. Or haskell, amazing ideas but the way they are teached... seriuously? A functor, monad, who talk like that? Have simplicity along ALL the path... that is hard!
- perfunctory 12y ago
  > Python have a simple syntax Python has a rather simple syntax indeed, but it has very complicated semantics. `foo.bar` - syntactically very simple expression of the attribute access has a mountain of semantics behind it. > Given that Python and Ruby are both simple to learn and use (as users, not implementors), they are both simple by the definition given in this article. Good remark. I still tend to disagree though. It's easy to learn and use a very small subset of the language. Not the whole language. Even then, it's practically impossible to limit yourself to a certain subset. Not if you want to use any python libraries.

AlexanderDhoore 12y ago

In the case of Javascript, the performance came at great cost. Javascript engines are monstrously complex. The language might be "simple", but the implementation is not. Lua on the other hand is probably fast because it is simple. There aren't many other programming languages like that. (C and Scheme maybe?)

haberman 12y ago
The Lua interpreter is among the fastest of languages in its class, but LuaJIT is also among the fastest JITs. I agree that a lot of this has to do with Lua being a simple language.
jamii 12y ago
The lesson from both of these is that performance doesn't magically come from simplicity but it is enabled by simplicity. A complex system is always hard to optimise. A simple system may be easy to optimise. Building simple systems whilst keeping performance in mind is a delicate balancing act. Local optimisations tend to add complexity that may prevent later optimisations. Sweeping generalisations that reduce implementation complexity often inhibit later optimisation due to lack of information (eg http://lucumr.pocoo.org/2014/8/16/the-python-i-would-like-to-see/ http://lucumr.pocoo.org/2014/8/16/the-python-i-would-like-to...).

perfunctory 12y ago

> Python and Ruby are notable counter-examples to this. I beg to differ. You seem to imply that Python is a simple language. Quite the contrary. Attempts to accelerate Python failed exactly because it's an extremely complicated language. Same goes for Ruby and JavaScript.

haberman 12y ago
This essay defines complexity like so: > We should measure complexity as the cumulative effort to learn and use a technology. Given that Python and Ruby are both simple to learn and use (as users, not implementors), they are both simple by the definition given in this article.
mamcx 12y ago
Python have a simple syntax, yet a complex implementation, so simplicity is not carried all along the path. A argument could be made this is in part the fault of C... because a state sub-goal of python is easy to integrate with C and back them the way they do it is complex, and because C is worse than python and a lot of code is made with it. So, you have a simpler language in top of a messy one (ie: In contrast with something like for example, pascal). The problem when try to make something simple is that carry the idea across boundaries/subsystem eventually break. If, for example, you wanna to make a performant language with clean syntax for a multi-procesor setup with intuitive behaviour, but, the base system/os/CPU not make it easy, you eventually need to break the simplicity along the way. This also touch the problem that to make something simple is necesary the skill and mastery across the whole problem. So perhaps python/ruby is like is because the authors are great at building a aproachable language but not at build the VM. You need to be both. Contrast with erlang. Amazing VM but whacky syntax. Or haskell, amazing ideas but the way they are teached... seriuously? A functor, monad, who talk like that? Have simplicity along ALL the path... that is hard!
perfunctory 12y ago
> Python have a simple syntax Python has a rather simple syntax indeed, but it has very complicated semantics. `foo.bar` - syntactically very simple expression of the attribute access has a mountain of semantics behind it. > Given that Python and Ruby are both simple to learn and use (as users, not implementors), they are both simple by the definition given in this article. Good remark. I still tend to disagree though. It's easy to learn and use a very small subset of the language. Not the whole language. Even then, it's practically impossible to limit yourself to a certain subset. Not if you want to use any python libraries.