On Tue, 3 Mar 2015 07:25:23 +0000
KatolaZ <katolaz@???> 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.