On Tue, Mar 03, 2015 at 07:25:23AM +0000, KatolaZ wrote:

> On Mon, Mar 02, 2015 at 04:35:24PM -0600, T.J. Duchene wrote:
> > When you code in Perl, you are using subroutines and libraries that
> > were incorporated into Perl core.    The fact you are calling an
> > entire subroutine when you "split" strings in Perl is no different
> > than having a C string library.  You call the library to do the
> > work.  You don't care how it does it, only that you get the results.
> > C gets a bad reputation because a percentage of programmers never
> > learned how to prevent buffer overflows or leaks is all.  That is
> > certainly not C's fault.

> >
>
> And I can mantion dozens of counterexamples in which Perl or Python
> would solve the task more easily than C. Just to give you an idea, I
> have been doing quite a bit of XML parsing, mainly to convert data
> sets of all sorts in a reasonable (ASCII) format. Well, I have done it
> both in C and Python, so I think I can make a fair comparison between
> the two *for this particular task* and for *my specific needs*.
>
> Usually the C implementation of a non-trivial XML parser might require
> a couple of days to be finished and be able to digest the whole schema
> (you have to construct the data structure piece by piece, and to pass
> around a lot of garbage, and to be sure that you don't have leaks
> anywhere, and to catch and handle errors by hand...). Conversely, the
> Python implementation is usually ready in less than two hours,

Are you using expat for the C implementation, like you are for Python
behind the scenes?

python-stdlib requires expat, BDB 5.3, bz2, ncurses, readline, sqlite,
and openssl, along with FFI, terminfo, and mime-support.

However, I recognize you probably won't get C done in less than 2 hours
like you do with Python.

I will say that it sometimes seems like the reason leaks are a problem
in C specifically is that leaks aren't considered a problem in other
languages.
Sure, gc-based languages eventually collect the garbage.
But they seem to take a long time to do it.
And they encourage a sloppy approach where acquiring a resource is not
habitually matched with releasing it.

And exceptions can at times be more obscure and verbose than checking
return values: something three imports deep could throw an exception
you never thought about, and it may propagate.

Now, I've used Python a little bit, and I've used C a little bit.
I won't say that Python/$scripting_language "should not be used, period".
But there are a lot of the features that come at costs that sometimes
seem to be ignored.

Thanks,
Isaac Dunham