Talk:Euphoria (programming language)

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?

Euphoria IS an excellent language that is relatively easy to learn, very flexable and seriously powerful. You can combine it's strongly type-checked high level features with any amount of embedded 32-bit machine code and API/Dll calls to make genuine applications in a fraction of the time required to write them in any other language that I am familiar with. The very simple data types that it was designed around can be polymorphed into any object or structure available elsewhere with ease, and the finished product will usually execute faster than anything short of pure ASM or very well written C. The main problem that Euphoria has always had is public relations one. The official website still bears the catch-cry of "Just say no to complicated programming languages". This is a philosophy that I applaude, but an advertizing blunder of biblical proportions that has relegated what is undoubtedly one of the best languages ever devised to the realms of the closet hobbiest. As a result it has barely been used for anything apart from pet hobby projects, and its own internal development. This is a real shame as virtually any commercial application on the market could have been developed in Euphoria in a fracton of the time and therefore a fraction of the cost of doing it in C++, delphi, python, PHP or whatever. It is also extremely reliable and unless you go messing around embedded or external ML will always trap it's own errors and clean up it's own mess. All this being said, until we can give it a face lift, Euphoria is mainly used by 2nd rate backyard programmers to write custom apps that keep track of the humidity in their dog's kennel.

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

However[edit]

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 ).

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

puts(1, "Hello, World!\n")

memory[edit]

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

Note on integer size[edit]

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

Euphoria can, of course, handle 32+bit integers in its atom data type.

- 32+bit isn't entirely accurate. Euphoria can only support 31bit integers, and 64-bit double precision floats. The mantissa is 52-bits. OpenEuphoria probably inherits this limitation. — Preceding unsigned comment added by 108.90.2.142 (talk) 05:44, 4 November 2011 (UTC)

There seems to be some confusion over terminology. Euphoria can store (arithmetical) integers from -9,007,199,254,740,992 to +9,007,199,254,740,992 without loss of precision. When a value is in the range -1,073,741,824 to +1,073,741,823 it is stored in the Euphoria data type known as an integer otherwise they are stored in the data type known as an atom. The integer data type is a more efficient entity and ought to be used for (arithmetical) integers in the subset range mentioned above. When using integers outside that range, such as 32-bit addresses, the atom data type must be used. Furthermore, the 64-bit version of OpenEuphoria is being readied for release, which will significantly extend the range of integers able to be used. DerekP (talk) 00:07, 5 November 2011 (UTC)

Integer Size: further clarification[edit]

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

Integers Overload, Atoms Approximate[edit]

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. ~~

What's the big deal?[edit]

Am I missing something here? The article seems to be written by someone who is unaware that programming language development continued after the creation of C. There's a lot of bragging that Euphoria doesn't require pointer or array management and doesn't have static typing, and that's great, but that applies to a wide variety of languages used today.

I see that despite using the term "object" rather liberally, there seem to be no OO facilities at all. I also can't find anything on built-in hash/dictionary support, besides using an enum to index an array. Comparing a scripting language to C is all well and good, but what makes Euphoria better than, say, Python or another dynamic language? —Preceding unsigned comment added by 96.240.116.103 (talk) 16:15, 18 May 2009 (UTC)

euphoria syntax highlighting lost[edit]

Since the switch from Geshi to Pygments for syntax highlighting (phab:T85794), support for 'euphoria' was unfortunately dropped, which was used only once on this page. The highlighting on this page is manually added. If you want specialised 'euphoria' syntax highlight support again, it will need to be added to Pygments. Alternatively, if there is another language which has similar syntax, we can add that as a fallback. John Vandenberg ^(chat) 21:11, 18 July 2015 (UTC)

External links modified[edit]

Hello fellow Wikipedians,

I have just modified 4 external links on Euphoria (programming language). Please take a moment to review my edit. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit this simple FaQ for additional information. I made the following changes:

When you have finished reviewing my changes, you may follow the instructions on the template below to fix any issues with the URLs.

As of February 2018, "External links modified" talk page sections are no longer generated or monitored by InternetArchiveBot. No special action is required regarding these talk page notices, other than regular verification using the archive tool instructions below. Editors have permission to delete these "External links modified" talk page sections if they want to de-clutter talk pages, but see the RfC before doing mass systematic removals. This message is updated dynamically through the template {{sourcecheck}} (last update: 15 July 2018).

If you have discovered URLs which were erroneously considered dead by the bot, you can report them with this tool.
If you found an error with any archives or the URLs themselves, you can fix them with this tool.

Cheers.—InternetArchiveBot (Report bug) 17:46, 24 September 2017 (UTC)

anhducwiki

Sunday, November 29, 2020