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 _______________________________________________ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
