Thread: Which language?

Originally Posted by Elysia

That picture is looking ugly.

I understand some people are predetermined to never be satisfied. Like, if your definition of a great car is a Corolla, it's impossible to say that some other car is better, because it won't be a Corolla. It's that simple. In which case you might as well just say any car that's not a Corolla sucks, because it's not a Corolla. My little sister's like that -- she has menus for every day of the week, and it never changes. Wednesday is shake and bake chicken with potatoes. That's what Wednesday is. She just keeps having the same seven meals over and over and over and she's happiest that way.

I actually like the old school candy color look of Tk a lot more than some of the latest "expanse of beveled grayness" type stuff. And I have friends who've managed to do completely disgusting things with their windows desktop. I guess there is no accounting for taste.

Elysia; One thing to keep in mind is that the world is no longer just Microsoft Windows and there is an ever-growing need for a single code-base that can provide a GUI on ALL platforms. Aesthetically it might look like plain old Windows to you (and it is) but the trick here is with a single recompile it produces a natural-looking Linux/Solaris/Mac version with no additional effort. If you just code to the Windows API, good luck porting (I have and no it is not what I would call "good" luck...). In addition, wxWidgets supplies many things that others complain about portability: socket and network libs, threading/process control libs, etc that you have one code-base for and works the same on all platforms. Will it ever look better than (say) Vista? Nope but that isn't the point. It can however look *just like* Vista (or XP or 9x). This saves a TON in development effort and cost.

MK: I really wish you would think about this logically:
1. Any interpreted language has to go through an interpretation->runtime bindings->runtime lib step. A compiled language goes right to the last step and can only be slower than the script language if the C (for example) source is brain-damaged. Clock cycles are clock cycles.
2. IOW if the Perl is even *close* to the C execution time, that only means that the C source is more poorly-constructed/designed than the logic in the Perl + any efficiencies in the runtime bindings the saves more time than the interpretation. In such a case its time to fix your C.

To paraphrase you from another thread: no magic here..

As for the Perl vs C-based compiler I only suggested that you do it so you would see there is a lot more to writing a compiler than simple string interpretation...I really didn't think you would do it though

Originally Posted by jeffcobb

Elysia; One thing to keep in mind is that the world is no longer just Microsoft Windows and there is an ever-growing need for a single code-base that can provide a GUI on ALL platforms. Aesthetically it might look like plain old Windows to you (and it is) but the trick here is with a single recompile it produces a natural-looking Linux/Solaris/Mac version with no additional effort. If you just code to the Windows API, good luck porting (I have and no it is not what I would call "good" luck...). In addition, wxWidgets supplies many things that others complain about portability: socket and network libs, threading/process control libs, etc that you have one code-base for and works the same on all platforms. Will it ever look better than (say) Vista? Nope but that isn't the point. It can however look *just like* Vista (or XP or 9x). This saves a TON in development effort and cost.

And that is good. Way better than your custom make-up GUI.
Unfortunately, not everyone seems to follow this principle!

Originally Posted by jeffcobb

MK: I really wish you would think about this logically:
1. Any interpreted language has to go through an interpretation->runtime bindings->runtime lib step. A compiled language goes right to the last step and can only be slower than the script language if the C (for example) source is brain-damaged. Clock cycles are clock cycles.

I understand what you are saying (you've said it a few times now) and superficially I agree. My point is that the main meal is in the last step, and without a much more detailed understanding of how the interpreter works, I think you are throwing darts blindfolded to conjecture about what the relationship of the first two steps to the last one is. Pretty clearly, the goal would be to minimize them, and also pretty clearly, the execution time is mostly in the library objects that the interpreter links to -- which is the C library.

So (again) it is believable to me when someone claims "for events of type X"*, the interpreter's overhead becomes insignificant in relation to the task carried out by the runtime libs -- which is the exact same task, so you will get cases where perl matches C.

However, no one (including me) is claiming this is always the case, or that perl could do it faster, etc.

As for the Perl vs C-based compiler I only suggested that you do it so you would see there is a lot more to writing a compiler than simple string interpretation...I really didn't think you would do it though

God no. I have read a lot of the "Dragon Book", I'm not talking totally off the top of my head. Altho I did not get much beyond parsing, which is mostly string interpretation. IMO this is kind of a red herring anyway: what constitutes string interpretation? AFAICT it would be synonymous with parsing a data stream, which can cover a pretty range of activity, and certainly includes the full range of data handling and structuring. A parsed string is a tree.

*eg, 3D rendering with dynamic textures, which is pretty specific and does not mean "all 3D rendering"

Originally Posted by Elysia

And that is good. Way better than your custom make-up GUI.
Unfortunately, not everyone seems to follow this principle!

I had a custom make-up GUI? <scratches head>

Okaaaay

MK27 showed one, yes?

Originally Posted by MK27

My point is that the main meal is in the last step, and without a much more detailed understanding of how the interpreter works, I think you are throwing darts blindfolded to conjecture about what the relationship of the first two steps to the last one is. Pretty clearly, the goal would be to minimize them, and also pretty clearly, the execution time is mostly in the library objects that the interpreter links to -- which is the C library.


However, no one (including me) is claiming this is always the case, or that perl could do it faster, etc.



God no. I have read a lot of the "Dragon Book", I'm not talking totally off the top of my head. Altho I did not get much beyond parsing, which is mostly string interpretation. IMO this is kind of a red herring anyway: what constitutes string interpretation? AFAICT it would be synonymous with parsing a data stream, which can cover a pretty range of activity.

*eg, 3D rendering with dynamic textures, which is pretty specific and does not mean "all 3D rendering"

Sigh. Fine. I have written a number of scripting languages along with the accompanying runtimes and interpreters (not all of them well mind-you; its not a trivial task and I had to learn how to do it "on the job" which means I had to go home at night one day not knowing how to do it and come in the next ready to write shippable code). Did I write Perl? No and neither did you. However I am familiar with the steps involved and am not throwing darts so to speak. If the script and the compiled executable has the same runtime as you mention above, then by definition any additional steps taken by the interpreted language results in more time. It is just that simple. As for the Perl compiler that was an example I thought you brought up a while back and if you look at the GCC source you will discover that your stream parsing is just a tiny fraction of what goes on...even the Dragon book should illustrate that.

Originally Posted by Elysia

MK27 showed one, yes?

It's candy colored! You should see the "bumblebee" skins

Generally the larger mainstream GUI libs leave the make-up details to a generic system default. The advantage: everything looks the same. The disadvantage: everything looks the same.

Tk doesn't have that capacity AFAIK.

Originally Posted by Elysia

MK27 showed one, yes?

Oh the Tk thing; don't know that I would call it a made-up GUI (like I said it predates Windows GUIs in any form IIRC) but yeah Tk is a dog. However the thing with Tk is that it was designed a long time ago for people with way different needs/expectations than those you share today. In your Windows world it would be more analogous to having a GUI that could be called (interactively) from a batch file.

I have attached (I hope) a screen shot from something similar (GUI lib made for scripting languages) to show another possible option....

Above pic looks like gtk?

Originally Posted by jeffcobb

I have written a number of scripting languages along with the accompanying runtimes and interpreters (not all of them well mind-you; its not a trivial task and I had to learn how to do it "on the job" which means I had to go home at night one day not knowing how to do it and come in the next ready to write shippable code). Did I write Perl? No and neither did you. However I am familiar with the steps involved and am not throwing darts so to speak.

Sure, so you maybe have a GP's perspective on neuroscience ("I did my year at the hospital")? I have to reconcile that with the statements made by other developers -- who admittedly could be self-interested, but for now I'll assume are NOT out and out liars. And it still seems to me that what you are saying is true in the sense that there is a "natural and logical" limitation here BUT it is not clear at all exactly how relevant it is.

It is analogous to the point that coding in asm will produce almost always be faster if done well: okay (that makes natural and logical sense), but by how much?

if you look at the GCC source you will discover that your stream parsing is just a tiny fraction of what goes on...even the Dragon book should illustrate that.

Hmmm, back to this concept of the tiny fraction

Fair enough. I think this thing about what constitutes "string handling" is very vague anyway, I suppose I should have thought about it more or researched exactly what it refers to in the "perl performance" context that I brought it in from. I do know that it underlies the POGL benchmarks (can't find the original article now), where they are handling textures for vector processing like strings.

WRT to the Dragon Book, the first third is about lexing/parsing, so that's a fraction (if you take parsing, constructing symbol tables, et al. to be 100% about string handling).

I was also referring to optimization and so forth but whatever. I think the difference in our views is that you are thinking of relative speeds and I am thinking of literal speeds. For a GUI which spends its time waiting for user input you are right: C is faster but Perl is fast enough. For things where time matters then no, Perl is not fast enough because at the end of the day it is not the fastest solution.

Believe who you will and prosper in your beliefs.

I gotta say I am going to regret going to back to work next month and miss out on all this fun...

Originally Posted by jeffcobb

For a GUI which spends its time waiting for user input you are right: C is faster but Perl is fast enough. For things where time matters then no, Perl is not fast enough because at the end of the day it is not the fastest solution.

For a GUI I believe they will literally be identical since the GUI completely loads and then waits for events to handle.

Vis, "not the fastest solution" is the reason we all have to do everything in assembly. If you were talking orders of magnitude, okay, but according to the benchmarks, it is not orders of magnitude -- it's often completely NEGLIGIBLE.

Believe who you will and prosper in your beliefs.

Oh you just want to win an argument at all costs :P

Originally Posted by MK27

For a GUI I believe they will literally be identical since the GUI completely loads and then waits for events to handle.

Vis, "not the fastest solution" is the reason we all have to do everything in assembly. If you were talking orders of magnitude, okay, but according to the benchmarks, it is not orders of magnitude -- it's often completely NEGLIGIBLE.



Oh you just want to win an argument at all costs :P

I have been doing this for a long time MK; I know what I have seen and experienced on the job and else-where and it simply doesn't back your claims. YMMV. All I can say is all I ever say: some day, you will see.

As for winning the argument, you lost it the second you claimed Perl could create an efficient compiler...the rest was just discussion.

But I still will miss the debates

Originally Posted by jeffcobb

As for winning the argument, you lost it the second you claimed Perl could create an efficient compiler...the rest was just discussion.

Googling for this is tricky, since "perl compilers" won't fly, but I did try ("compilers written in perl"), since AFAICT the perl community will do anything and everything just to prove a point -- last year I ran across a scheme that involved a bunch of grad students who were developing an Operating System in perl, and I think acquiring some kind of degree in the process. Which superficially, me and the GP might consider that impossible.

Anyway, I thought this was interesting:
Writing Interpreters, Compilers and Translators in Perl
seems there are already a set of modules for the parsing phase (which I would expect).

And there are compilers (for something...) written in perl out there (which I would expect), altho they are not for compiling C code, so that could mean anything. But really, who would want to do such a thing (write a C compiler in perl)? I think you are being a little silly Jeff.

Vis, your obstinacy about the relative speed of interpreted languages: you are just wearing a team jersey IMO, tch.

Originally Posted by MK27

Vis, your obstinacy about the relative speed of interpreted languages: you are just wearing a team jersey IMO, tch.

Not at all; we just live and work in different worlds. You live in a PC world where scripting languages can thrive; I tend to live more in the embedded/realtime space, a place where the suggestion of using an interpreted language on such a device would get you laughed out of a design meeting.

Thus I would posit that the validity of your argument is highly dependent upon the piece of ground that you are standing on.

As for the "team jersey" again you speak from a position of insufficient knowledge; I like scripting languages for the thing they are good at. As a matter of fact I run an OSS project on Source Forge written in Python in my copious spare time. I have written a lot of Python code even to the point of getting it to run on the PS3 which is sooooo not Intel it might as well be from another planet.

So no, there is no team jersey here mate; just the knowledge that I use (for my needs) the right tool for the right job. Again, on the PC it may not matter much but there is a whole other world out there. In the apps you work on time must not count; in mine (most of the ones I do/did for work) it does, even those NEGLIGIBLE amounts you scoff at.