Talk:Euphoria (programming language)

From Wikipedia, the free encyclopedia

I'm sure this is a worthy subject, but claims like "easier to learn than BASIC" and "fastest interpreted language" are just advertising mumbo-jumbo. Sure, you want to have who designed it and what their goals were, but if I'm looking at an enecylopedia article about a programming language, I want to know who uses it and for what, what it looks like (maybe some sample code?), what actual features it has in plain English, and a link to their website if any.

Actually not just ad mumbo-jumbo, I believe those were specific design goals of the language...I'm having a bit of difficulty wording them objectively though. There are benchmarks and such, but I didn't want to get into technicalities. There's a link to the website at the bottom. If you want sample code, I can accomodate. :) Is it a bit better now?

Looks better to me anyway. We can also soon put this under euphoria (programming language) or perhaps euphoria (prog. language), because CliffordAdams has just come out with the latest version of UseMod. --LMS


Contents

[edit] However

This is actually a language goal. I also can guarantee you that it's easier to learn than basic.

I have used and participated in the development of this language (and external freeware libraries) for 10 years now, in this time I have never heard anyone say BASIC was easier to learn.

It may also be said that the language construct is simple, yes. But it's impossible to say write a core windows program without using pointers, so yes you use them all the time, and no, the language does not protect you from this. It's an impossibility.

That's a problem with the windows API really, because when I make a windows program in Euphoria, it's subject to exactly the same memory faults and errors as if I had made it in C, it just happens to be about 10 times faster to actually code.

"Not using pointers" etc is not actually a language construct is what I mean, intrinsically it doesn't matter if the language supports pointers or not, the reality is you use them regardless of the support. And just because the language doesn't support them, doesn't mean you get pointer errors because you allocated the memory with the Windows GlobalAlloc() command.

A pointer is really more NOT a language reference. It's just (usually) a 32-bit integer which points to a memory offset. Any language is capable of using this really, and no language can ever protect you from undesired results. HoCkster

I have to agree that Euphoria is easier to learn than BASIC, provided you intend to learn the entire language in each case (not just a subset).

More importantly, Euphoria has fewer built-in limitations (which you also have to learn about, but which are seldom documented :)

As far as speed is concerned, it's easy to prove for yourself that Euphoria is faster than most other interpreted languages in most instances. Of course it's often possible to craft a test which will show that any language X is the fastest for some task, if you choose that task carefully.

But what matters to me is that Euphoria is fast enough to use commercially, and no one asks me if I can "speed up" their applications. If I had to write everything in C (or C++, Delphi, COBOL, Fortran...) I would get 1/3 as much work done, and therefore be making 1/3 as much per hour.


Everyone says everything is easier to learn than BASIC, and then I look at the first line of a sample program and run. I have used FirstBasic and find it fast enough for anything I will ever do but unless the ad is BS the same company has beefed up their PowerBasic Console model to almost the best C compiler speeds. This looks interesting but so doesn't Forth - but as above, the first line of code seems almost mystical ( requires a baseline of knowledge I suppose that makes any language seem easy to the possessor of said knowledge ). BASIC is for us linear thinking dopes ( non ++ anything people ).

[edit] EUPHORIA's "Hello, World!"

puts(1, "Hello, World!")

[edit] memory

sure if you're doing a single function program then you will not need to explicitly allocate or deallocate memory. to develop and full application in linux gui's or windows, you have to allocate memory period and be subject to the pitfalls of doing this. who said in euphoria you don't need to allocate or free memory? it supports this explicitly, and thus allows you to use linux .so and windows .dll files and hence have access to the relative api. by saying that euphoria does not need to allocate memory could be interpreted as in a way saying it is less powerful than C, which is a dubious speculation. euphoria supports direct memory allocation in a far more sophisticated manner than c.

If you are interfacing with a decent library then the library will be doing most of the allocating for you, otherwise in Euphoria it will do it for you automatically if you are just dealing with loading bitmaps, reading files and manipulating memory etc. This needs no memory allocation. Where you have to allocate memory is for the smaller things like passing a "string" to a C function. You have to convert it first to a Unicode, Ascii and most often null terminate it to make it "C compatable".

Its not entirely possible in a GUI environment to make a program which does not explicitly allocate memory, maybe your library does all of it for you however, and the code *you* write involves no memory allocation at all.

I've made some Euphoria programs in windows in which the memory allocation amounted to nothing other than the (48 byte) WndClassEx structure, and convering text via SetWindowText to control functions, calling the function then immediately freeing the memory block allocated - on a sliding scale the amount you *have* to allocate is really not what you'd call problematic, or likely to lead to any major pitfalls.

The way *most* people use euphoria, developing programs/utilities etc with an overhead library involve no direct memory manipulation at all, which is why the claim euphoria does not need to allocate memory is so often stated. The Reality is Euphoria only ever *has* to allocate memory when it calls a compiled function in another language, which in turns requires memory to manipulate whatever data it is you are passing to it, as it is presumed you both have read/write access to this same memory block. Which is the simplest way to overcome the many different ways many different languages use memory.

Euphoria can manipulate memory just like C can, just if you don't call C libraries I'd say its a *lot* quicker just to do it in native Euphoria. HoCkster

[edit] Note on integer size

Euphoria uses 31-bit values for integers NOT 32 and this fact is stated repeatedly throughout the official documentation. The 32nd bit designates it as an integer instead of an atom. This is NOT a typo so don't correct this. - DNewhall

[edit] Integer Size: further clarification

Integers are 30 bits in a signed or unsigned direction. Hence integers overload at 2^30 plus or minus, and atoms at 2^40 something plus or minus. Hence the above post is correct that an integer is really 31 bits, but it is forced as a signed variable (you don't get to choose). You can't declare an integer (be it 31 bits) as signed or unsigned so the 31 remaining bits fall into the category as a signed variable. One bit designates the sign, and the remaining 30 bits the actual value of the integer. HoCkster

[edit] Integers Overload, Atoms Approximate

As a further note, Integers Overload, Atoms Approximate. Integers handle exact integer values NOT up until 32 btis, it's been well documented not to use integers for 32 bit numbers (use atoms).... they start to approximate at 2^48 onwards. ~~