41–50 of 60 posts
I would love to hear more about "leverage existing package management systems". I guess many people use rvm to install ruby and I always recommend newbies to try it out for that purpose. But recent criticisms of ruby made me wonder if that really is the right approach. Maybe it would be better to put more effort into creating top-notch packages for the major linux distros (and, say, homebrew). And to work with the di…
I don't know if creating top notch packages is too realistic, when the biggest difficulty with that is often the platform policy (e.g. insistence on separating documentation and runtime, even if it's more tightly coupled that it looks, having only one executable per package...) that is the biggest hurdle to overcome. The fact that no platform got it right for Perl, Python nor Ruby points to a huge difficulty...
Few people compile Python from source in the way that is common for Ruby. People do use pip/ virtualenv, but those are more the equivalent of bundler/ RVM gemsets-- they manage libraries, not entire interpreters. It's a little confusing because virtualenv appears to have its "own" Python, but really it is a symlink to the (usually) system interpreter managed by the distro.
The major distros have representatives who are active on python-dev in working out any issues that may make integration difficult between Python and the distros.
Or, they could just learn shell scripting. How much would that cost? I do not understand why the[1] shell... which is a relatively small language... is so difficult for people to learn. If you can find the time to learn Ruby, what stops you from learning a shell? What is the cost of ignoring it? 1. Preferably something resembling the proposed POSIX standard which might lend to portability. Bash is not necessarily the…
I would if RVM 1.0 didn't suck so much of my time away that I gave up and just went with vagrant.
Earlier quoted context omitted.
Correct, but it also means that the authors take responsibility for fixing those problems. That's the attitude we have for Phusion Passenger: it does a lot of stuff for you so that you don't have to. And if things break because of our fault, we take the responsibility of fixing it so you don't have to and can concentrate on your own business. Have the RVM authors not fixed the problems you experienced?
> we take the responsibility of fixing it so you don't have to Surely you must say no to some people... I can't take the risk that person might be me and then be left up the creek without a paddle. Do you have an SLA? What if I have an issue in production and the core contributors are all sleeping? Can I wake you up? Can I pay you for the right to wake you up? Even if you are awake and willing to help on my schedule,…
Why does Python still have a global interpreter lock after all these years, and why does it not have a JIT? One of the reasons is because it makes development easy, keeps the architecture simple and makes contributions easy. Writing a language implementation without a GIL, and with the latest state-of-the-art garbage collector and JIT, makes the code and architecture more complex also. The drawback of this is... that Python has a GIL and has no JIT.
Or, they could just learn shell scripting. How much would that cost? I do not understand why the[1] shell... which is a relatively small language... is so difficult for people to learn. If you can find the time to learn Ruby, what stops you from learning a shell? What is the cost of ignoring it? 1. Preferably something resembling the proposed POSIX standard which might lend to portability. Bash is not necessarily the…
That's precisely the kind of dismissive comment I needed to read today. You don't seem to have read the link, in which the author makes good points for moving to Ruby, or think that somebody maintaining 20k of complex shell script should actually "learn shell scripting". I'm sure the author is well-informed about shell scripting. While it's certainly convenient in a pitch, it has little support for unit-testing, erro…
Earlier quoted context omitted.
> we take the responsibility of fixing it so you don't have to Surely you must say no to some people... I can't take the risk that person might be me and then be left up the creek without a paddle. Do you have an SLA? What if I have an issue in production and the core contributors are all sleeping? Can I wake you up? Can I pay you for the right to wake you up? Even if you are awake and willing to help on my schedule,…
It is exactly as you say. It is a double edged sword, with both benefits and drawbacks. RVM is one example. Another example is Python. Why does Python still have a global interpreter lock after all these years, and why does it not have a JIT? One of the reasons is because it makes development easy, keeps the architecture simple and makes contributions easy. Writing a language implementation without a GIL, and with th…
rvm is complex both in implementation and in interface. The interface complexity comes from the shear number of things it tries to do automatically for you: interpreter versioning, gemsets, shell integration, plugins/extensions, devops functionality, and a bunch more! All of that is tangled together in one tool and you can't get any piece of it a la carte. Each of those things has its own plumbing commands and conceptual surface area. rbenv just fucking puts some shit on your path.
That's totally separate from an interpreter having inherent complexity in sophistication of algorithms and data structures. Personally, I think (as do the PyPy folks) that Python's design has some substantial complexities that make JIT-ing much more difficult than Lua, for example. If you choose a simpler language, you can get a simpler JIT; hence LuaJIT's success. Similarly, if you choose an even simpler language, with less mutability in core data structures, you can get a simple lock-free, multi-threaded interpreter.
Earlier quoted context omitted.
The fact that RVM "does more" means that users need to understand more in order to fix problems that it causes. If you install RVM and other things on your system break due to its tampering with .bashrc, you need to understand what it has done. If I didn't understand $PATHs, etc., I would still be unable to use "man" due to $MANPATH being broken from the last time I installed RVM.
Correct, but it also means that the authors take responsibility for fixing those problems. That's the attitude we have for Phusion Passenger: it does a lot of stuff for you so that you don't have to. And if things break because of our fault, we take the responsibility of fixing it so you don't have to and can concentrate on your own business. Have the RVM authors not fixed the problems you experienced?
This is what I think your Python example below misses. If Python is slow because it doesn't have a JIT and that causes someone's program to run too slowly, they can see that the problem is that Python is slow. Python's lack of a JIT would never cause "man traceroute" to stop working in a shell session where the user hasn't done anything related to Python and couldn't possibly guess that Python is the culprit.
Earlier quoted context omitted.
That's precisely the kind of dismissive comment I needed to read today. You don't seem to have read the link, in which the author makes good points for moving to Ruby, or think that somebody maintaining 20k of complex shell script should actually "learn shell scripting". I'm sure the author is well-informed about shell scripting. While it's certainly convenient in a pitch, it has little support for unit-testing, erro…
Well, since you seem to have insight as to the reasoning behind others' choices, perhaps you could enlighten us how someone came up with the idea of writing 20K lines of shell and passing it off to a community of Ruby developers as a "command line tool"?