On Tue, 3 Mar 2015 07:25:23 +0000 KatolaZ <kato...@freaknet.org> wrote:
> Well, if you found that *for your particular tasks* C can replace Perl > or Python, I believe you. But it's just not true that this should be > the case for everybody else, in every possible use case. > What I have found is that many of the arguments surrounding the particular choice of "this language is better for task A, while this one is better for task B" is very subjective and often entirely false. All computer languages are constrained to the physical nature of the processor, so the benefits of one over another are usually really nothing more than syntactic sugar. Perl or Python in the core language might be "better" for breaking down strings, but give C an identically functioned library and it will do just as well. Both languages are actually written in C and the thus constrained by C's internals, which are actually nothing more than the processor architecture. I honestly wouldn't give a tinker's dam what people want to use, if it were not for the fact that many of the popular languages use some really annoying name mangling techniques, produce less than optimal object code, and waste energy by constantly reconverting high level code back into object code every time that it executed. > But you can't deny that other languages > exist, and can be useful (even *more* useful than C for certain > tasks), Actually, that is precisely the mode of thinking that I am challenging. I will grant you that given the fact that C has seen a lack of use over Perl or Python, and thus its users find one easier, but I would also argue that an experienced C programmer with the vast arsenal of C libraries that exist, could easily turn that argument on its head, especially with RAD tools. Perl or Python's syntactic abilities are in reality, nothing more than blocks of C code, compiled into their interpreter cores. As a counter-argument, I would offer that you can perform any task in C, (with the extremely occasional asm block) that the processor is physically capable of, but the reverse cannot be said of other languages. > > Unfortunately, the world is not just black or white, when it comes to > languages. And I am among those who believe that the world *IS* and > *SHOULD BE* absolutely black or white, in many other respects... :D THAT is very true, and regardless of what we decide here, the world will go on its merry way. These languages might be "easier to use" by those allergic to to lower level ones, but the overhead and inefficiency wastes battery power. Ultimately, the time the programmers might save are spent by the potential thousand users who have wait 5 minutes for the app to run rather than 2 1/2. I think the end goal of my "rage" against certain programming languages would be to shame them into creating better compilers, optimizers and using the traditional interpreter only for debugging. > 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*. My sympathies. XML is like the fleas on a mangy dog. It's hard to get rid of and everywhere you turn, it reappears. Well my response to that would be that it is easier for "you" to use Python for this task, but it would NOT be easier for someone else to do so. The whole "ease argument" is entirely subjective. > 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, at > most, and gives you the same set of functionalities at the cost of a > slightly longer processing time (in the range of tens of seconds, or > minutes, in the worst case). And if I have to use that code only once > (as it is *very often* the case with 98% of the code), then the Python > way is overall far better, faster, easier and convenient than any > other thing you can conceive. > > Not if you use a library already written for the task. As I said, i find the argument somewhat subjective and based on your personal preference. On the other hand, I can say factually that Python's abilities are nothing more than C code behind the scenes. The day that Python is actually written in Python rather than C, then I will happily accept that argument. Cheers! t.j. _______________________________________________ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
