Thread: Which language?

Originally Posted by Mario F.

Hence why C# or Java can't beat C++ on game development for instance, or why none of these languages could efficiently be used on many embedded systems or be used to emulate these systems, or even be used to create an efficient compiler, operating system, or even a GUI.

This is more of the lopsided ignorance. I am sure perl could be used to create a highly efficient compiler (I'll bet it's even been done); one of it's claims to fame is not just the string handling potential of the syntax, but that it cannot be outpaced doing it because of the nature of the underlying C code (ie, a perl program will be as fast as a C/C++ program at string processing).

Which "string processing" is a pretty broad realm. The people who wrote POGL (the perl openGL bindings) claim that

General Purpose GPU (GPGPU) processing is one area in which Perl can be compared with compiled languages in terms of performance.

Based on their own benchmarks, Perl OpenGL developers claim that there are no significant performance differences between C and Perl (via POGL), when rendering a realtime 3D animated object with dynamically generated texturemaps.

which is a pretty fancy claim and I have not seen it refuted either.

As for creating an OS, well, most people would agree the only realistic choice there is a compiled language.

As for GUI's: IMO this is exactly the kind of thing interpreted languages are perfect for. Again, my experience is specifically in perl (having done GUI work in C and perl): I have never seen nor heard of a GUI application that could not be done just as well in perl as it would in C/C++, and with a fraction of the codebase. You clearly have never used these languages, Mario, and have a completely corrupt understanding of what they are about.

All GUIs in Perl that I have seen have been butt ugly.
Or was it Python?

Originally Posted by Elysia

All GUIs in Perl that I have seen have been butt ugly.

There are gtk and I think wxWidget API's, which means they look exactly like other GUI's because they use the same libraries.

You would not even know they were perl (or python, or ruby, or believe VB), is the point. The "appearance" is in the library and most of those are not language specific.

Originally Posted by MK27

This is more of the lopsided ignorance[...]I am sure perl could be used to create a highly efficient compiler (I'll bet it's even been done); one of it's claims to fame is not just the string handling potential of the syntax, but that it cannot be outpaced doing it because of the nature of the underlying C code (ie, a perl program will be as fast as a C/C++ program at string processing).

You say I'm ignorant and then base all your argument for perl being able to create "highly efficient compilers" (your words, not mine) in such a trifle issue as string processing? Part of the reason why most people don't take you seriously anymore.

As for GUI's: IMO this is exactly the kind of thing interpreted languages are perfect for.

Only... I didn't mention GUIs. I said GUI Libraries. But I guess you have no idea what I'm talking about. And comparing C with Perl in terms of access to GUI based material is really a motivating factor to put you back on my ignore list. You are just too weird for me.

Originally Posted by Mario F.

You say I'm ignorant and then base all your argument for perl being able to create "highly efficient compilers" (your words, not mine) in such a trifle issue as string processing? Part of the reason why most people don't take you seriously anymore.

I wasn't aware that they had started . Anyway, I'll stand by my statement on this one. Stage 1 of compilation is 100% about string processing and so is a lot of the rest. Unless you want to interpret "string processing", or data parsing, in a naive way, in which case we are just arguing semantics and the underlying truth of what I've said remains the same.

Only... I didn't mention GUIs. I said GUI Libraries. But I guess you have no idea what I'm talking about. And comparing C with Perl in terms of access to GUI based material is really a motivating factor to put you back on my ignore list. You are just too weird for me.

Actually, you said "even a GUI". As usual, when someone points out you are lying or extremely wrong, you turn around and try and pretend you never said exactly what you said.

As for my opinion about GUI programming, I do it, mostly in C, I understand how it works, and I'll stand by statement on this one even more firmly: interpreted scripting languages are *perfectly* suited to it, and no ridiculous delusion of yours will change that.

Originally Posted by MK27

Actually, you said "even a GUI".

Indeed. Had to go back and check. Was pretty sure I mentioned GUI libraries. But I didn't.

As usual, when someone points out you are lying or extremely wrong, you turn around and try and pretend you never said exactly what you said.

LOL! I don't have to. It's everywhere in plain sight for anyone to see. It would be very easy to check as I did. In any case it was a honest mistake. Something that you instead see as me lying. It's your prerogative and I honestly don't give a rat's arse for what you think.

What is funny about all that is that my mistake actually strengthens my argument. Something that your own ignorance failed to realize.

Let me tell you something about Perl and GUIs that you don't know. What you see in gtk2-perl and wxPerl is languages bindings for perl of these two libraries. Language Bindings, not libraries actually written in Perl. Perl has no language facilities that would allow it to write a GUI library, much less a GUI from scratch.

As for my opinion about GUI programming, I do it, I understand how it works, and I'll stand by statement on this one even more firmly

Oh shutup!

It could be said you are wrong and that would be the end of it. But because instead you decide to stand on your high horse full of your own ignorance while shooting insults at everyone that tries to tell you how wrong you are, you are nothing more than a an annoying idiot deserving of no more attention.

Originally Posted by Mario F.

Let me tell you something about Perl and GUIs that you don't know. What you see in gtk2-perl and wxPerl is languages bindings for perl of these two libraries. Language Bindings, not libraries actually written in Perl. Perl has no language facilities that would allow it to write a GUI library, much less a GUI from scratch.

I know that. Perl modules (which are usually OO API's) can be written in either C or perl, and a lot of them are in C, esp if performance is an issue. The perl developers are really C developers which that point is, I would think, really obvious.

Beyond a "my language is better than yours and you should only choose ONE" context, this makes a ton of sense: the purpose of perl is to provide a high level programming interface (the perl language) to a high performance C application (the perl interpreter and libraries). That's what interpreted languages are about. So I think you could provide a perl programming API that would allow you to develop a GUI library, which would be interesting because it would be cross platform, but really there is not a need for this, and as you say (again, this is a truism), yes, at some point all that perl has to be implemented in a compiled language.

That's the relationship.

And I'm sorry for implying you might be a liar, Mario, but when an otherwise intelligent seeming person gets all vehement about a dumb assertion, you have to wonder what the point is

The funny thing is, I really should be taking my own advice here more. Now when I do GUI programming I almost always do it in C/Gtk+ because I'm trying to develop my proficiency there*, when I know that perl would hasten the process.

* like it's nice to be able to go, hey, a GUI would be handy here and whip one off quickly and easily. Which I guess answers the question: I use C for the GUI because it's an interface to a C program.

MK; Sorry bro but there is no way in hell any interpreted language will make as efficient compiler as a compiled language and a low-level one at that. Try it for yourself: write a (small) compiler in both Perl and C and see which one is more efficient. Don't confuse "getting your job done quickly" which Perl is good at with "executing the code quickly" which C will smoke Perl at. I mean think about it: unless your C is brain-damaged by the coder, there is no way a process that is compiled is going to be the same speed as a process that is interpreted at run-time, *then* executing compiled code (in runtime libs). No way unless you have some way of making the script interpretation take 0 clock cycles.

On the GUI question I think since any code talking to a GUI library will work there, any language will be as suited for the task. wxWidgets has bindings for many languages for example so you would have no clue what is behind the UI...could be C, C++, Perl, Python, etc.

Originally Posted by jeffcobb

MK; Sorry bro but there is no way in hell any interpreted language will make as efficient compiler as a compiled language and a low-level one at that. Try it for yourself: write a (small) compiler in both Perl and C and see which one is more efficient. Don't confuse "getting your job done quickly" which Perl is good at with "executing the code quickly" which C will smoke Perl at. I mean think about it: unless your C is brain-damaged by the coder, there is no way a process that is compiled is going to be the same speed as a process that is interpreted at run-time, *then* executing compiled code (in runtime libs). No way unless you have some way of making the script interpretation take 0 clock cycles.

Sure, but that is a very crude way of looking at it. Most of the capabilities of the interpreter are already compiled in. Everytime you run a script, the regular expression engine (for example) does not have to be re-compiled -- the interpreter already exists. So this thing about the runtime expense can be grotesquely mis-conceived. WRT to how long the interpretation takes, it's important to consider that 1000 lines of code has the potential to do things that are not simply ten times more complex than 100 lines (I don't know of any formula here, but hopefully the point is clear). The upshot of that is that as the code base grows, the interpretation time will scale down in relation to the execution time. Also, perl is a very compressed language, meaning not much code has to be interpreted in order to "trigger" a lot of activity. On a system where you are running a lot of perl, the interpreter stays in shared memory, meaning it's own deployment time is 0.

That's why you can end up with statements like (to repeat this quote) "Perl OpenGL developers claim that there are no significant performance differences between C and Perl (via POGL), when rendering a realtime 3D animated object with dynamically generated texturemaps." Which makes total sense to me and I believe them, and it's not the only time I've seen it stated that specific kinds of tasks are streamlined so effectively by the perl interpreter that the execution time is simply the execution, ie, it matches the C implementation.

In general, though, I'm nbt trying to argue that interpreted languages should be expected to match the performance of compiled ones (or recommending that someone write a C compiler in perl as some kind of stunt), just that they do not necessarily have to be significantly slower either, and for many many purposes the difference will be irrelevant.

Originally Posted by MK27

Sure, but that is a very crude way of looking at it. Most of the capabilities of the interpreter are already compiled in. Everytime you run a script, the regular expression engine (for example) does not have to be re-compiled -- the interpreter already exists. So this thing about the runtime expense can be grotesquely mis-conceived. WRT to how long the interpretation takes, it's important to consider that 1000 lines of code has the potential to do things that are not simply ten times more complex than 100 lines (I don't know of any formula here, but hopefully the point is clear). The upshot of that is that as the code base grows, the interpretation time will scale down in relation to the execution time. Also, perl is a very compressed language, meaning not much code has to be interpreted in order to "trigger" a lot of activity. On a system where you are running a lot of perl, the interpreter stays in shared memory, meaning it's own deployment time is 0.

That's why you can end up with statements like (to repeat this quote) "Perl OpenGL developers claim that there are no significant performance differences between C and Perl (via POGL), when rendering a realtime 3D animated object with dynamically generated texturemaps." Which makes total sense to me and I believe them, and it's not the only time I've seen it stated that specific kinds of tasks are streamlined so effectively by the perl interpreter that the execution time is simply the execution, ie, it matches the C implementation.

In general, though, I'm nbt trying to argue that interpreted languages should be expected to match the performance of compiled ones (or recommending that someone write a C compiler in perl as some kind of stunt), just that they do not necessarily have to be significantly slower either, and for many many purposes the difference will be irrelevant.

But the interpretation is *still happening* and therefore cannot be zero. In your example you confuse "recompiling the regex parser" (which does not require recompilation) with the higher level code that calls it (which requires interpretation). Also in a compiled language environment the regex parser doesn't require compilation either...

Until the time taken for interpretation is zero (aside from using a quantum computer, physically impossible), interpreted languages will be by definition slower than compiled languages even with the same runtimes under the hood. Crude? More like fundamental truth. I know that some scripting languages can perform as *acceptably* as compiled languages but to make the blanket statement that Perl is as fast as C and the time taken for interpretation is non-existent does a disservice to the "C++ Programming 101" folks you referred to about a thousand posts back. I guess dealing with realtime systems gives one a different perspective on "time".

Oh and to fan the flames a little, something I just read off of Linux Today I thought was funny:
"If Python is executable pseudocode, then perl is executable line noise."

Just teasing with the last bit

Originally Posted by Elysia

All GUIs in Perl that I have seen have been butt ugly.
Or was it Python?

It is probably the Tk library rather than the language Elysia; it is indeed butt ugly but it has been around since pre-Win31 days. The wxWidgets library MK (I think) referred to is available to many languages (C/C++/Perl/Python/etc) and when built on Windows looks like Windows, when built on Mac looks like OS/X (or whatever the current build is), on Linux looks like GTK....

I would hope so. I shudder to think of them.
What is annoying is that even standard windows controls--which requires NO extra coding at all!--looks prettier than make-up GUIs, and to be frank, yes, the look of the GUI DOES matter. I would rather use a poor application with pretty GUI than a very good app with a horrible GUI.

Originally Posted by Elysia

I would hope so. I shudder to think of them.
What is annoying is that even standard windows controls--which requires NO extra coding at all!--looks prettier than make-up GUIs, and to be frank, yes, the look of the GUI DOES matter. I would rather use a poor application with pretty GUI than a very good app with a horrible GUI.

I guess that is the difference between us (*NIX and Windows): I would like something with a nice GUI *when a GUI makes sense* but I demand something that works well in any case. Here are some shots of what wxWidgets looks like on various platforms...Screenshots - wxWidgets

Originally Posted by jeffcobb

But the interpretation is *still happening* and therefore cannot be zero. In your example you confuse "recompiling the regex parser" (which does not require recompilation) with the higher level code that calls it (which requires interpretation). Also in a compiled language environment the regex parser doesn't require compilation either...

Yeah, I didn't think you actually meant that, just wanted to make sure that we understand that the overhead is purely the script interpretation.

Which that's a task with a lot of leeway for done okay->done incredibly well. Larry Wall has a doctorate in linguistics, I believe. That may seem irrelevant until you consider that the Backus-Naur Form was derived from Noam Chomsky (a linguist, I think he formalized the equivalent of the "turing" test to demonstrate what constitutes a human language).

But name dropping aside, I think what I said about the relationship between the code base and what the code base does is what will determine the "interpretation time", and it seems to me that the execution time for 1000 lines of perl will just completely dwarf what it takes to parse it.

This size/activity relationship applies even more to single commands. If you have a module method that triggers a lot of complex activity, parsing that one line amounts to squat. So you get all these claims like from POGL whereby when doing certain things, the activity is so streamlined it does match the equivalent in C. Part of the reason I believe that's almost certianly true is:

1) what seems like a "fundamental" truth, as you say, often turns out to be much more complicated -- or even false -- when examined closely.
2) I don't see anyone presenting serious refutations of such claims, ie, some people have test data to prove something is one way, and no one seems to have any data proving they are wrong. Even if it seems counter-intuitive to the casual observer.

Vis. Tk, yeah, plain Tk is like plain Qt 3 -- it's really really plain. That third wx window from jeffcobb's link is very bland too. But it can be made to look nice (IMO), I think I've posted this pic here before recently. Tk has some other limitations too, I won't recommend it for too much -- except it is also very easy to use. Quick and simple.

That picture is looking ugly.