On Sat, May 17, 2014 at 04:14:21PM +0200, Teodoro Santoni wrote: > You're speaking like you're using some OS in which, during runtime, > the code of that software written with a scripting language > is passed through a dispatcher that recalls namespace sessions > and, then, to a limited number of scripting interpreters loaded > and daemonised in memory when available for executing code, > without seeing an interpreter for every process spawned > by every scripted program, which is what happens on my uglybuntu > with programs written with scripting languages. >
First, please don't top post. Second, that is a total non sequitur. Because I was talking about disc space and you are talking about processes. I said, I want _one_ perl/python/php (ok, bad example) on my box instead of one for every package that might use it. That way, it's on my box only once. It's configured only once and it's downloaded only once. Of course it's run for every program that needs it whenever it's needed. And of course the parsing overhead sucks. However, at that point we're usually talking about stuff that might be beyond my ability to reimplement in a compiled language. And is _definitely_ beyond my ability to do so on the spot. > Although it's true that it's a waste of data downloading the > whole damn language everytime you need the ultimate geek > hipsterish idea put down on iPad during a pause spent taking a > sh*t... Slow down there: If you deem the software you use of that low quality, why use it at all? Unless of course, you're unable or unwilling to reimplement that software. That other people whipped up inside of five minutes. You know, those people talking about how low-productive C is? Maybe they're on to something here. OK, in the end I usually find that five minute programs that do in their language what I can't do in C even after hours typically do so by using the language's standard library, which is far more extensive (read: bloated) than C's, so I have to actually implement stuff that was already done for the script kiddie. > But an interpreter is a parser and some modules > dynamically loaded, most of the time with scripting langs, so > dunno, when deploying a package nobody impedes a distro community > to deploy a JIT compiler that loads some of the modules during > compilation. Last I checked, all the major interpreters are already in all the major distributions, so what's your point here? "Don't make packages with dependencies"? In that case, why use package managers at all? *glance to Windows* Oh, right... > Or saying f*ck the whole script idea and rewrite > the whole thing in C/Go/Pascal/Ada/whatever you like to compile. > Yes, yes, real hackers write in C. And if you can't write it in C, you write it in FORTRAN. And if that's not possible you write it in assembly. And if that's not possible you solder it. Jokes aside, the whole "compiled vs. scripted" thing never made sense to me. Not in the almost religious ways many view this issue (not just here but on other forums, too. Only, for those the pendulum usually swings too far in the other direction). To me, that debate just misses the point. It is clear that scripted languages have their pros and cons over compiled ones and what to use is to be decided on a case-by-case basis. Especially, compiled languages are not inherently better than scripted languages. Both can be memory hogs and both can be beautiful, it depends on the skill of the programmer. I don't use C religiously, I use it because I know it well and I usually want readability and traceability, Speed being a tangential concern at best. But if I need a ton of string handling, for instance, C would not be my first choice. At least not if heightened security is necessary. Ciao, Markus
