forum-msg-id-124826-edit
Original date:2014-07-28 18:51:26 Edited by: jimcbrown Subject: Re: Data structures in the next release
I was thinking it over, actually. Considering the long delay in getting 4.1 out, maybe it is ok to include new features like structs after all...
So i think data structures are never likely to be happen... (becouse there are not easy to learn and do not fit into the simple Euphoria typesystem).
So structs are nothing to wait for.
Like ne1uno said, we already have them.
No, Euphoria allready has memstructs (and yes, there are great and really important for wrappers and for porting to 64bit).
But memstructs are only pointers to memory areas and are only useful for interacting with C (or C Style) Librarys. I do not think you want Euphoria Programers to work with Pointers all the time?!
That's a good point. memstructs is for interfacing with C (when you have to use pointers).
and last but not least there are not even in the default branch. So if i count the time (nearly 2 years for a bugfix release for 4.0.5) I think there is still some time to wait for a 4.1 with memstructs
Conceded.
But Euphoria still lacks structs (or Records) for Euphoria DataTypes.
I agree with SDPringle here, we more-or-less already have them: http://openeuphoria.org/forum/m/124818.wc
It'd be nice to see struct_assign() in the stdlib though, and maybe even some syntax sugar for it.
It's a toy language, you can play with it and then go on to something real.
I think this is less true since 4.0 came out (it was more true of say, version 2.3). Besides, Linux (the kernel) started out the same way (as a toy kernel), but with time grew into something bigger.
Sure, you are right. But Euphoria and Linux are in the same age.
Agreed, Euphoria is slightly older actually (it started in the mid 80s, Linux kernel was 1991 or 1992 iirc).
So Linux (Kernel) evolved a little bit faster and is not comparable....
The big difference IMVHO is that Euphoria wasn't open source until just a few years ago.
I still like it (becouse i'am just playing) but i do not await real progress.
Define progress. Does 64bit support, multi-thread support, and data structure support count?
64bit support is a really progress,
And I can assure you that more progress is in the works.
multi-thread support? Where?
Phix had it first: http://openeuphoria.org/forum/120729.wc#120729 (I consider Phix part of the Euphoria family of languages...)
There's also an OpenEuphoria version that's in-progress (but highly experimental)...
data structure support? See above...
Ditto.
It's nice for text processing
Ironic, as it's not really intended to specialize in text processing, unlike languages like Perl or awk.
No, it's not ironic, that's (from my point of view) one of Euphorias strong sides.
Conceded.
Its just easy to learn.
That's a huge benefit regardless of any other faults.
Easy to learn does not mean easy to use...
But being easy to learn is a huge benefit regardless. Being easy to use would be an additional huge benefit.
but does not offer something you can't do in any other language.
I think this is an unreasonable requirement. All procedural computer languages are equivalent. At the end of the day, the code is turned into machine code that a computer understands. It's not possible to add features or abilities on top that can't be written in that machine code.
This is a very reasonable requirement (again, from my point of view). Becouse why should anyone choose Euphoria over any other language if there is no difference?
Why not?
Even if we had huge differences (I'm thinking Java vs Ocaml/Effiel/Erlang/C-- here), I'm not sure it'd make much difference in terms of usage. Ray Smith had it down IMVHO - the biggest, most popular languages tend to have the biggest commercial backing. Short of having all of that, we just simply can't compete in terms of marketing, advertising, etc.
Why do you think people choose a highlevel language over assembler if the result is the same?
The result isn't the same, because assembler is hard to learn and hard to use (relatively speaking), and it's not portable. There's no single assembler language, but a bunch of them (roughly one per cpu architecture), and you more or less have to relearn everything from scratch when you move to another arch.
From my point of view. Euphoria is dead and outdated. You better do not await something new.
From my point of view, Euphoria is more-or-less missing only two features - native multithread support and generators. (I'm still working on the first but not making a lot of progress yet.) Otherwise, it mostly has everything you'd expect from another language.
Development has been sluggish lately, but I assume that's because all-volunteer team is busy in real life. You get what you pay for ... or, if you really want to see things speed up, you can join the team and start playing around with the source code of the language itself (and not necessarily in that order)!
I do not have the knowledge to work on the language itself,
If you really wanted to, I suspect you could catch up really quickly. A lot of the work in adding new features to Euphoria can be written in Euphoria itself. I've seen your past work in the language and rated it highly.
i do not even have enough knowledge to work on a wrapper (even my tinewg was build on the hope that someone jumps in and tell me that I'am doing it wrong).
I've used tinewg and I think you sell yourself short here. I find it a great product.
I know i get what i pay for ... but what i miss is 'Tue Gutes und rede darueber.' translate to 'Do good and tell people about it!'
Agreed. But, well, real-life and all that ... what's a person to do?
I miss 'the progress in OpenEuphoria pushed to the public', i'am sure not every Euphoriaprogramer likes to install gcc and msys and hg to just have the most recent Interpreter.
You mean the eubins? Getting those back up is definitely a priority.
I'am really sure they want them on the downloadpage. Including some information.
Maybe things like Multiassign (easy to use and really fast) or deprecated support or 64bit support or reduced parsing time or smaller dll's or fixed memory leaks ....
64bit support has been up there for a while. I think Matt has put up binaries for his branches, like memstructs, from time to time as well.
I'm not sure it makes sense to have all that information in the download page however. That's available from the hg logs (which you can browse online) and from the release notes (also available online).
|
Not Categorized, Please Help
|
