Re: [dev] C coded cross-platform youtube video viewer
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
Received on Sat May 17 2014 - 22:53:28 CEST
This archive was generated by hypermail 2.3.0
: Sat May 17 2014 - 23:00:08 CEST