compared languages

Forum: Programming and Scripting
Topic: compared languages
started by: curaga

Posted by curaga on July 11 2007,10:10

I found a link to a site comparing programming languages.
For fun I matched the only programming lang I know, basic, with some others. The results were very surprising:

basic beats the hell out of perl, python, and lua!

And everyone just keeps saying it's a bad lang..

with linux ver of freebasic many graphic libs can be straightly used, opengl or gtk2 programs with basic are possible..
so I'm back to basic programming.

Just a weird result I wanted to share

Posted by ^thehatsrule^ on July 11 2007,13:32

heh, comparing what?

In terms of performance, of course you would think a compiled native binary would beat interpreted scripts..

"straightly used"? I suppose you mean using native calls to those lib APIs, but then thats due to the reason above as well (those others would need some sort of wrapper?)

And it's no problem if you prefer a basic, easier-to-read high level language (no pun intended) for your learning environment.

Posted by curaga on July 11 2007,14:02

Basic can be interpreted too..

I don't plan to move to say assembler after this, so I don't consider it a learning environment..
I don't even like programming much. A few years ago, in the time of Dos and Qbasic I just got hooked to some text adventures and wanted to make some myself ;)

Posted by mikshaw on July 11 2007,14:37

I also must say that it is an unfair comparison (what is this site, by the way, and what do you mean by "beats"?). An interpreted language has its own benefits over a compiled application, and these benefits are becoming more apparent as cpu speeds and memory availability increase, making overall performance differences less noticeable and less important.

Some of the more obvious benefits of an interpreted language are:
No compiling is necessary, which makes it much easier to test and modify.
Generally less code needed to accomplish the same task.
If the interpreter is cross-platform, the script often is too (basic programs would need to be recompiled for each platform).
It's usually always open source (very few exceptions).

I'm sure there are more technical things to compare, but since I have practically no experience with compiled languages I am no authority. Here's a lengthy piece of text focusing on interpreted languages:
< http://www.tcl.tk/doc/scripting.html >

Quote

opengl or gtk2 programs with basic are possible

They are possible with script as well. In fact, there is a tiny tool called GTK-server which allows you to use gtk 1 or 2 elements from just about any script, including Bash.

Posted by curaga on July 11 2007,15:34

"beats" as in executes faster, produces smaller executables/binaries/scripts, and uses less ram when executed.

I didn't know of GTK-server, it seems great. Why was lua chosen over bash & it?

The page is < Computer language shootout >, link given by Robert in some old thread.

Posted by WDef on July 11 2007,16:54

There are always trade-offs between language choices, so, as the cliche says, it's always about what is the right tool for the particular job.

Sometimes it's better to take a little size and performance hit in order to have the conveniences afforded by higher level languages, or just a language that you know well. I mean, if you want everything tiny and ultrafast, just write it it Assembly language! Can't get any smaller, faster, or more difficult than that, short of writing in binary.

Some languages that appear to be 'interpreted' are actually compiled during run time - Perl for example, is compiled into byte code when you run it, and run on a virtual machine. Which is why you're not supposed to call a Perl program a 'script' (it isn't). It's also possible to turn Perl directly into C binaries. And is the strict sense of the word, all languages are 'interpreted' at some level.

Mikshaw: that gtk-server thing sounds interesting.

Posted by curaga on July 11 2007,17:05

Not to mention tcc can interpret C..

Posted by ^thehatsrule^ on July 11 2007,17:28

curaga: sure... but not to point out the obvious, that chart that you pointed out lists freebasic, which is not interpreted.

Good points, WDef. I suppose it's similar to Java. I do not know much about Perl, but I have always heard of its source being called "scripts" -- seems like for historical reasons or whatnot.

Posted by mikshaw on July 11 2007,21:49

Quote

produces smaller executables/binaries/scripts

This I have much trouble believing. One of the benefits of using an interpreted language is that much of the code that would normally be compiled with your program is already compiled into the interpreter, so scripts can be _much_ smaller than compiled apps that do the same thing.

Quote

I didn't know of GTK-server, it seems great. Why was lua chosen over bash & it?

Lua is a much simpler language. I haven't actually tried GTK-server yet, but from looking through the docs and examples, it seems terribly complicated in comparison to creating murgaLua scripts. I'm sure there is probably a significant difference in runtime performance as well, but that's just an assumption.

I'm also not sure about the "tiny" part. I was going by the size of the source package, which is approximately the same as the compiled murgaLua binary. For all I know, it may suck up a huge amount of code from Gtk

GTK-server website: < http://www.gtk-server.org/ >

Posted by WDef on July 12 2007,10:38

Quote

but I have always heard of its source being called "scripts"

People do use the term - some Perl heavies get annoyed about it though - I guess they feel it demotes Perl.

Larry Wall himself says he doesn't care, but that "a script is what you give the actors. A program is what you give the audience." That's not meant to make sense, he's famous for his wise cracks.

From Perlfaq1:

Quote

Perl programs are (usually) neither strictly compiled nor strictly interpreted. They can be compiled to a byte-code form (something of a Perl virtual machine) or to completely different languages, like C or assembly language. You can't tell just by looking at it whether the source is destined for a pure interpreter, a parse-tree interpreter, a byte-code interpreter, or a native-code compiler, so it's hard to give a definitive answer here.

Now that "script" and "scripting" are terms that have been seized by unscrupulous or unknowing marketeers for their own nefarious purposes, they have begun to take on strange and often pejorative meanings, like "non serious" or "not real programming". Consequently, some Perl programmers prefer to avoid them altogether.

Actually the way Perl runs depends on the particular circumstance - it can run it different ways. I don't fully understand this yet, it's there in the Perl docs.

Posted by mikshaw on July 12 2007,14:13

Quote

"a script is what you give the actors. A program is what you give the audience." That's not meant to make sense, he's famous for his wise cracks.

Actually it does make sense. Maybe it's not terribly accurate, but it's clever =o)

My personal take on the naming is that people need to lighten up. It's all programming anyway, regardless of how simple or "nefarious" (I don't recall hearing anyone insist that spam is not email). A script, in my opinion, is any application that a user executes while it's in plain text form. Whether it gets compiled or interpreted at runtime is an insignificant difference. The main thing is that a script is plain text from the user's point of view, so it can be easily read, transferred, dissected, and improved at any time, right up to the second it is executed (and apparently beyond that point, for some languages).
Little technicalities concerning the naming of things (Linux vs. GNU/Linux) have their place (legal documents, for example), but should remain ignorable in everyday communication.

Posted by WDef on July 14 2007,11:58

Indeed.

Yes Larry's clever (and funny) all right.
He also peppers his code with wisecracks etc. There's a collection somewhere .. some of these require a knowledge of the Perl world to get.

They might not like getting called "scripters" but one nice thing about the Perl community is that they are very tolerant of beginner's code (Larry Wall calls it "babytalk", but that's meant to be affectionate - he likes babies - not patronizing), because any Perl that works and is syntactically correct is ok, and there's many ways to do any one thing in Perl. And it's easy to start but there's a seemingly infinitely long learning curve after that (as I have found out ) ....