4 ms·

The overall tone of the responses here are surprisingly negative and doing a lot of Monday morning quarterbacking, as if this was some kind of failure. There ar

The overall tone of the responses here are surprisingly negative and doing a lot of Monday morning quarterbacking, as if this was some kind of failure. There are wild assumptions about their clientele and the desires of the company, completely disregarding the fact that the company did this to meet their own stated objectives. They wanted something easy to deploy (single executable), easily portable, very small CPU footprint, and very small memory footprint. Lua is well regarded for all these things, and the company succeeded in meeting all these objectives. Congratulations Distelli. Nice job. And thanks for sharing.

tyingq 11y ago
One of my replies may be in your "negative" pile. It wasn't intended to be negative, just to point out that the cited reasons in the article for the switch weren't specific to python...just how they decided to use it. They may have been concerned about packaging python because of the size, but didn't call that out. Had the title been "Why we Chose to use Lua" it probably would have garnered more positive comments.
devishard 11y ago
Total rewrites are almost always the wrong move. It may be true that they meet their stated objectives, but some of those objectives could have been achieved without a rewrite, and some of those objectives don't make sense. I've written plenty of single executables for multiple targets in Python. Figuring out how to do that would certainly have taken less time than the rewrite. Small resource usage may make sense, but they didn't relate it to any actual customer need, and given it was already running on RHEL, I doubt this was a reasonable goal. Unless it also needed to run on pocket calculators, the resource needs of a Python program are well within reason for most target environments. To be clear, I don't think Lua is a worse choice than Python for a new project; my objection is to the rewrite. There are problems with both languages. Sure, now packaging is easier, but when he runs into a hard problem that would have been solved by an existing Python library is he going to rewrite again? It's a junior developer mistake to blame issues on your tools and rewrite instead of getting things to work in your existing environment. Mature tools like Python (or even to a lesser extent Lua) are rarely the problem. There are certainly exceptions where there are serious problems such that changing tools makes sense. But none of the problems mentioned in the writeup are that. The bad part of the rewrite is that there is no possible way to know what was lost. There are edge cases which were discovered and handled in the old product that will have to be rediscovered in the new one. It sounds like they haven't lost any business over this, so it will be okay in the long run. But I suspect they could have done this a lot easier and cheaper. Just because it turned out okay doesn't mean this is an exemplary choice we should learn from.
lmm 11y ago
If you rewrite your app you end up with something better, in any language. It's an uncontrolled experiment, and so the headline is very likely misleading - this isn't about Python and Lua. And many of us have been majorly inconvenienced when a manager read a similar headline and declared that we would rewrite our app in language y, regardless of whether that language is appropriate to our circumstances. Something like http://roscidus.com/blog/blog/2013/06/09/choosing-a-python-replacement-for-0install/ http://roscidus.com/blog/blog/2013/06/09/choosing-a-python-r... where the author actually considers multiple candidates and performs a controlled comparison would be far more valuable. Given that the goals sound very similar I'd be very interested to see a comparison between Lua and OCaml.
- _pmf_ 11y ago
  > If you rewrite your app you end up with something better, in any language. You end up with something that is superficially better, but misses a lot of edge cases that the ugly legacy application covered. Fortunately, you have usually moved on to save other projects, leaving lowly maintenance developers to fix the problems, thereby creating job security. It's a win win situation, really.
- collyw 11y ago
  Working code is worth a lot. No amount of unit tests will make up for the real user testing done in the wild. I have had some horrendous pieces of code that I kept because I knew they worked.

tyingq 11y ago

One of my replies may be in your "negative" pile. It wasn't intended to be negative, just to point out that the cited reasons in the article for the switch weren't specific to python...just how they decided to use it. They may have been concerned about packaging python because of the size, but didn't call that out. Had the title been "Why we Chose to use Lua" it probably would have garnered more positive comments.

devishard 11y ago

Total rewrites are almost always the wrong move. It may be true that they meet their stated objectives, but some of those objectives could have been achieved without a rewrite, and some of those objectives don't make sense. I've written plenty of single executables for multiple targets in Python. Figuring out how to do that would certainly have taken less time than the rewrite. Small resource usage may make sense, but they didn't relate it to any actual customer need, and given it was already running on RHEL, I doubt this was a reasonable goal. Unless it also needed to run on pocket calculators, the resource needs of a Python program are well within reason for most target environments. To be clear, I don't think Lua is a worse choice than Python for a new project; my objection is to the rewrite. There are problems with both languages. Sure, now packaging is easier, but when he runs into a hard problem that would have been solved by an existing Python library is he going to rewrite again? It's a junior developer mistake to blame issues on your tools and rewrite instead of getting things to work in your existing environment. Mature tools like Python (or even to a lesser extent Lua) are rarely the problem. There are certainly exceptions where there are serious problems such that changing tools makes sense. But none of the problems mentioned in the writeup are that. The bad part of the rewrite is that there is no possible way to know what was lost. There are edge cases which were discovered and handled in the old product that will have to be rediscovered in the new one. It sounds like they haven't lost any business over this, so it will be okay in the long run. But I suspect they could have done this a lot easier and cheaper. Just because it turned out okay doesn't mean this is an exemplary choice we should learn from.

lmm 11y ago

If you rewrite your app you end up with something better, in any language. It's an uncontrolled experiment, and so the headline is very likely misleading - this isn't about Python and Lua. And many of us have been majorly inconvenienced when a manager read a similar headline and declared that we would rewrite our app in language y, regardless of whether that language is appropriate to our circumstances. Something like http://roscidus.com/blog/blog/2013/06/09/choosing-a-python-replacement-for-0install/ http://roscidus.com/blog/blog/2013/06/09/choosing-a-python-r... where the author actually considers multiple candidates and performs a controlled comparison would be far more valuable. Given that the goals sound very similar I'd be very interested to see a comparison between Lua and OCaml.

_pmf_ 11y ago
> If you rewrite your app you end up with something better, in any language. You end up with something that is superficially better, but misses a lot of edge cases that the ugly legacy application covered. Fortunately, you have usually moved on to save other projects, leaving lowly maintenance developers to fix the problems, thereby creating job security. It's a win win situation, really.
collyw 11y ago
Working code is worth a lot. No amount of unit tests will make up for the real user testing done in the wild. I have had some horrendous pieces of code that I kept because I knew they worked.