1. Future direction and purpose of Euphoria?
- Posted by ryanj Mar 26, 2014
- 3883 views
I love how Euphoria works. The syntax is great. But, in a modern era of web apps, mobile devices, and mega-corporation-driven technologies, how can Euphoria compete? What is the purpose of Euphoria? Is there some niche market it can fill? What can it be used for, beyond casual hobby programming? Why are other languages so much more common?
- Java is used on many devices, made possible by it's "virtual machine". It seems like Euphoria can do that, with IL. This has made it possible to port to multiple platforms already. Perhaps it's the OOP that people like, which makes code more modular and structured. Euphoria can emulate "objects and classes", or use a preprocessor to customize the syntax. Personally, i like the syntax just the way it is.
- PHP is common for web development. Euphoria can do that very well, but only by CGI, which is less efficient. Perhaps someone should make modules that plug in to http servers like PHP. Then Euphoria could actually be allowed on more web servers, just like PHP.
- Python & Perl seem to be common for scripts inside open-source programs that are written in C or C++. For example, X-Chat, Blender, and advanced text editors. Euphoria could be a really good scripting language if the interpreter was modified to do this (perhaps as a eui.dll/eui.so file).
- C, C++, C#, etc. seem to be the industry standard languages, but Euphoria is so much more elegant and easier to learn. We can already translate to C and compile on multiple platforms. C is even used on many types of micro-controllers, so Euphoria could probably be ported to micro-controllers that have enough processing power and RAM.
What's missing from Euphoria? What markets should the Euphoria focus on? I think Euphoria has potential, but there are some areas i think could use some work:
- True multithreading and multiple cores
- Professional-level Graphical User Interface development tools and libraries
- Common file formats: JPG, PNG, XML, HTML, SVG, ODF, etc.
- Audio streaming
- Web server modules and features for professional web development
- Script engine (run euphoria program inside a program)
- Micro-controller or low-power CPUs without an OS (either translate to C for the specific platform, or compile directly to assembly)
2. Re: Future direction and purpose of Euphoria?
- Posted by Lone_EverGreen_Ranger Mar 26, 2014
- 3867 views
I love how Euphoria works. The syntax is great. But, in a modern era of web apps, mobile devices, and mega-corporation-driven technologies, how can Euphoria compete? What is the purpose of Euphoria? Is there some niche market it can fill? What can it be used for, beyond casual hobby programming? Why are other languages so much more common?
- Java is used on many devices, made possible by it's "virtual machine". It seems like Euphoria can do that, with IL. This has made it possible to port to multiple platforms already. Perhaps it's the OOP that people like, which makes code more modular and structured. Euphoria can emulate "objects and classes", or use a preprocessor to customize the syntax. Personally, i like the syntax just the way it is.
- PHP is common for web development. Euphoria can do that very well, but only by CGI, which is less efficient. Perhaps someone should make modules that plug in to http servers like PHP. Then Euphoria could actually be allowed on more web servers, just like PHP.
- Python & Perl seem to be common for scripts inside open-source programs that are written in C or C~++. For example, X-Chat, Blender, and advanced text editors. Euphoria could be a really good scripting language if the interpreter was modified to do this (perhaps as a eui.dll/eui.so file).
- C, C++, C#, etc. seem to be the industry standard languages, but Euphoria is so much more elegant and easier to learn. We can already translate to C and compile on multiple platforms. C is even used on many types of micro-controllers, so Euphoria could probably be ported to micro-controllers that have enough processing power and RAM.
What's missing from Euphoria? What markets should the Euphoria focus on? I think Euphoria has potential, but there are some areas i think could use some work:
- True multithreading and multiple cores
- Professional-level Graphical User Interface development tools and libraries
- Common file formats: JPG, PNG, XML, HTML, SVG, ODF, etc.
- Audio streaming
- Web server modules and features for professional web development
- Script engine (run euphoria program inside a program)
- Micro-controller or low-power CPUs without an OS (either translate to C for the specific platform, or compile directly to assembly)
I too agree Euphoria could be so much more. One thing Euphoria is lacking is some sort of structure. By that I mean like a struct or class in C++, yes I know it can be emulated, but I think Euphoria would be much better if it had a way of dealing with this naturally. Also, there are some wrappers and libraries that achieve what you have said you want Euphoria to do. Though not perfect. Euphoria is a open source project, so anyone can contribute and bring these changes to Euphoria. I think within time Euphoria will probably gain these features. Also, I think Euphoria is easy to learn because it lacks true OOP, so adding true OOP may not be such a good idea, but it is possible that adding some loose form of OOP may be beneficial for Euphoria. Also, a built-in GUI library for Euphoria would be excellent.
3. Re: Future direction and purpose of Euphoria?
- Posted by useless_ Mar 26, 2014
- 3830 views
- Last edited Mar 27, 2014
<giant snip>
Euphoria is a open source project, so anyone can contribute and bring these changes to Euphoria.
<snip>
Also, I think Euphoria is easy to learn because it lacks true OOP, so adding true OOP may not be such a good idea, but it is possible that adding some loose form of OOP may be beneficial for Euphoria. Also, a built-in GUI library for Euphoria would be excellent.
Matt did an oop in Eu years ago.
useless
EDIT : someone edited this post.
4. Re: Future direction and purpose of Euphoria?
- Posted by DerekParnell (admin) Mar 26, 2014
- 3803 views
... What's missing from Euphoria? ...
It's not so much that we lack ideas, or even direction. The main issue is that we lack skilled people with enough time and energy to do the work required without getting paid for it.
In my own situation, I expect that the second half of the year will be more open for me to get back into contributing.
5. Re: Future direction and purpose of Euphoria?
- Posted by ChrisB (moderator) Mar 26, 2014
- 3803 views
Hi
strangely enough I've been kind of thinking about this myself recently. I'vebeen looking for a toolkit to install on a linux machine without faffing about with a load of other library and dependency installs (and getting frustrated as usual).
I think Euphoria needs a gui toolkit as a standard part of the install, rather than the diverse range of kits we currently have. Whether it be windows api, wxwidgets, gtk etc, it needs to be transparent to the user what the underlying toolkit it is, it needs to cross platform (bare minimum windows and linux), and it needs to install on whatever flavour of linux it is installed on all by itself. It also needs a RAD environment.
Maybe this is a wishlist rather than a future road, but put the elegance and simplicity of eu with the power of cross platform rapid gui development, and that would certainly build a great foundation for a future road.
Chris
6. Re: Future direction and purpose of Euphoria?
- Posted by jaygade Mar 26, 2014
- 3796 views
I love Euphoria, but after what? Sixteen years following it now? I'm moving on to other stuff.
I've contributed a little here and there. I love the language, the simplicity, and the syntax. But then I started really digging into the source code and realized what a mess it really is internally. Maybe it's not the worst source code out there, but when I compare the source to something much cleaner like the FreeBASIC source, it's like wow. All kinds of kluges, work-arounds, platform-specific code which should be generalized, etc.
The community has made great strides with this move to an expressive standard library -- kudos to Jeremy Cowgar for getting that started -- and with the addition of certain features and 64-bit-ness -- kudos to Matt Lewis and Jim C Brown and others.
But I really think is that the main language needs a re-write from the ground up (C backend and Euphoria front end and translator), which is much too large of a job for me. The standard set of functions needs to be examined and decide what should be internalized as C functions and what should remain as Euphoria functions -- especially sequence functions. Other technologies such as an LLVM intermediate language and/or JIT compiler should be investigated as possible improvements. Additionally, Euphoria REALLY needs a REPL, which hasn't been satisfactorily written yet so far as I know.
Currently I'm interested in Julia, which has many of those features, but which is also much less mature and which doesn't have quite as good of documentation as Euphoria.
I'm still going to hang out here as this community is still important to me, and I may even still contribute to some interesting problems/bugs as they come up. But without some serious refactoring, I don't see a lot of progression possible for Euphoria in comparison to all the other languages out there.
Long live Euphoria and rapid development.
7. Re: Future direction and purpose of Euphoria?
- Posted by BRyan Mar 27, 2014
- 3699 views
I think that there would be more contributions to Euphoria if some knowledgeable person
would document in "complete detailed" how to add a built-in "euphoria coded" function to the
source code.
This is one of the biggest stumbling blocks for the average user to contribute ideas.
The only documentation for adding to the source is still in a 2.x document which was
included by Rob years ago.
Forked into: Adding a Builtin to EUPHORIA
8. Re: Future direction and purpose of Euphoria?
- Posted by m_sabal Mar 27, 2014
- 3717 views
I think Euphoria needs a gui toolkit as a standard part of the install, rather than the diverse range of kits we currently have.
Though it isn't entirely the fault of the Euphoria community, this is one of the main reasons I stepped away from the language with version 4. Other contributing factors related to the gui problem are related to the changes between Windows UIs from XP to Vista to Win8, and Mac's dropping of Carbon support. Now Mac has even dropped native X-Windows support. Any language that is going to be competitive going forward either has to drop cross-platform support, run within a VM (Euphoria would probably be better suited to Parrot than JVM), or find a way to incorporate native UI and database access from multiple vendors within the language itself. Considering the number of established languages coders have to choose from, these are now entry-level requirements.
9. Re: Future direction and purpose of Euphoria?
- Posted by ryanj Mar 27, 2014
- 3655 views
I think Euphoria needs a gui toolkit as a standard part of the install, rather than the diverse range of kits we currently have.
Though it isn't entirely the fault of the Euphoria community, this is one of the main reasons I stepped away from the language with version 4. Other contributing factors related to the gui problem are related to the changes between Windows UIs from XP to Vista to Win8, and Mac's dropping of Carbon support. Now Mac has even dropped native X-Windows support. Any language that is going to be competitive going forward either has to drop cross-platform support, run within a VM (Euphoria would probably be better suited to Parrot than JVM), or find a way to incorporate native UI and database access from multiple vendors within the language itself. Considering the number of established languages coders have to choose from, these are now entry-level requirements.
I am trying to provide a solution to this problem with FluidAE, which will eventually have a cross-platform IDE and graphical tools for running, binding, translating, and debugging euphoria programs, as well as a complete solution for making "professional" GUI applications. However, i will need help porting it to other platforms. Also, it is difficult to make to run well without true multithreading. It's too bad that the GUI response time suffers every time the program is processing something, while 3 out of 4 cores are idle.
10. Re: Future direction and purpose of Euphoria?
- Posted by ryanj Mar 27, 2014
- 3681 views
I think we should seriously consider adapting Euphoria to web development and scripting, because a fast interpreted language like Euphoria would be perfect for both of those areas. They both require very little or no GUI or other C/C++ library wrapping, except some basic stuff that has already been established, such as database access.
Perhaps someone in the development team can look at what it would take to convert the euphoria interpreter into an Apache module? Also, we already have tools for generating webpages, but the last time i looked, the documentation was practically non-existent.
Also, what if the dev team could build a eui.dll and eui.so file that a program can link to? There could be an API for running a euphoria program as a script and interacting with it.
11. Re: Future direction and purpose of Euphoria?
- Posted by Lone_EverGreen_Ranger Mar 27, 2014
- 3649 views
I think we should seriously consider adapting Euphoria to web development and scripting, because a fast interpreted language like Euphoria would be perfect for both of those areas. They both require very little or no GUI or other C/C++ library wrapping, except some basic stuff that has already been established, such as database access.
Perhaps someone in the development team can look at what it would take to convert the euphoria interpreter into an Apache module? Also, we already have tools for generating webpages, but the last time i looked, the documentation was practically non-existent.
Also, what if the dev team could build a eui.dll and eui.so file that a program can link to? There could be an API for running a euphoria program as a script and interacting with it.
I like Euphoria the way it is. Its not perfect, but its not horrible either. I'd also rather Euphoria be kept as a hobbyist language then be converted to be used for total web development. I do agree though that a native GUI toolkit would be very beneficial to Euphoria.
12. Re: Future direction and purpose of Euphoria?
- Posted by useless_ Mar 27, 2014
- 3633 views
I think we should seriously consider adapting Euphoria to web development and scripting,
I'd also rather Euphoria be kept as a hobbyist language then be converted to be used for total web development.
Well, that's what ry said, it's already a hobby language, and now convert (with some adaptive layer, i presume) to plug into apache etc to be easily used in web servers.
useless.
13. Re: Future direction and purpose of Euphoria?
- Posted by Jerry_Story Mar 31, 2014
- 3505 views
The problem with Euphoria is not Euphoria itself but the fact that the installation of wxEuphoria is not automated. Do that and Euphoria will fly.
I should be able to install or update wxEuphoria, dependencies and all, with a single mouse click. Make that possible and Euphoria will fly.
14. Re: Future direction and purpose of Euphoria?
- Posted by Lone_EverGreen_Ranger Apr 03, 2014
- 3341 views
The problem with Euphoria is not Euphoria itself but the fact that the installation of wxEuphoria is not automated. Do that and Euphoria will fly.
I should be able to install or update wxEuphoria, dependencies and all, with a single mouse click. Make that possible and Euphoria will fly.
You know adding wxEuphoria to the standard install of Euphoria might be a good idea, but it would also require more work. Also, making it easier to install is another good idea. Also, I know there is supposed to be memstruct for 4.1.0, something like a struct or class system would be nice for Euphoria, I know it can be simulated using sequences, but having something like a struct or class would help organize code more.
15. Re: Future direction and purpose of Euphoria?
- Posted by ryanj Apr 03, 2014
- 3322 views
I like Euphoria the way it is. Its not perfect, but its not horrible either. I'd also rather Euphoria be kept as a hobbyist language then be converted to be used for total web development. I do agree though that a native GUI toolkit would be very beneficial to Euphoria.
So, we should just stop developing Euphoria and leave it the way it is? I'm not saying it should be "converted" to anything, I'm saying in addition to the current interpret, bind, shroud, and translate executables, an Apache module could be added, as well as an interpreter in a dll file to run euphoria source code as a script inside a program.
16. Re: Future direction and purpose of Euphoria?
- Posted by Lone_EverGreen_Ranger Apr 03, 2014
- 3289 views
I like Euphoria the way it is. Its not perfect, but its not horrible either. I'd also rather Euphoria be kept as a hobbyist language then be converted to be used for total web development. I do agree though that a native GUI toolkit would be very beneficial to Euphoria.
So, we should just stop developing Euphoria and leave it the way it is? I'm not saying it should be "converted" to anything, I'm saying in addition to the current interpret, bind, shroud, and translate executables, an Apache module could be added, as well as an interpreter in a dll file to run euphoria source code as a script inside a program.
I never said we should stop developing Euphoria. I do agree a GUI toolkit would help Euphoria tremendously. Also, in my last post I also mentioned having some of struct or class structure would also help Euphoria as well.
17. Re: Future direction and purpose of Euphoria?
- Posted by ryanj Apr 03, 2014
- 3299 views
I like Euphoria the way it is. Its not perfect, but its not horrible either. I'd also rather Euphoria be kept as a hobbyist language then be converted to be used for total web development. I do agree though that a native GUI toolkit would be very beneficial to Euphoria.
So, we should just stop developing Euphoria and leave it the way it is? I'm not saying it should be "converted" to anything, I'm saying in addition to the current interpret, bind, shroud, and translate executables, an Apache module could be added, as well as an interpreter in a dll file to run euphoria source code as a script inside a program.
I never said we should stop developing Euphoria. I do agree a GUI toolkit would help Euphoria tremendously. Also, in my last post I also mentioned having some of struct or class structure would also help Euphoria as well.
I'm sorry, that come out a little bit harsh. I agree, a GUI toolkit would be great, as well as an easier way to link to C/C++ libraries. What is this "struct" branch I've been hearing about?
18. Re: Future direction and purpose of Euphoria?
- Posted by ryanj Apr 03, 2014
- 3289 views
The problem with Euphoria is not Euphoria itself but the fact that the installation of wxEuphoria is not automated. Do that and Euphoria will fly.
I should be able to install or update wxEuphoria, dependencies and all, with a single mouse click. Make that possible and Euphoria will fly.
You know adding wxEuphoria to the standard install of Euphoria might be a good idea, but it would also require more work. Also, making it easier to install is another good idea. Also, I know there is supposed to be memstruct for 4.1.0, something like a struct or class system would be nice for Euphoria, I know it can be simulated using sequences, but having something like a struct or class would help organize code more.
I'm not sure if a specific GUI library should be "official", because people have different preferences. But there's no reason why wxEuphoria, win32lib, euGTK, and FluidAE couldn't have their own versions of IDEs that are easy to install, learn, and use....well, other than the fact that it takes time to develop all of that. Personally, I plan to develop a cross-platform IDE and graphical debug/bind/translate tools for Euphoria in FluidAE. I would like to make a Euphoria installer utility, but the biggest problem I see is dealing with administrative privilege elevation. Registry and file system access is probably not hard to deal with.
19. Re: Future direction and purpose of Euphoria?
- Posted by Lone_EverGreen_Ranger Apr 03, 2014
- 3327 views
The problem with Euphoria is not Euphoria itself but the fact that the installation of wxEuphoria is not automated. Do that and Euphoria will fly.
I should be able to install or update wxEuphoria, dependencies and all, with a single mouse click. Make that possible and Euphoria will fly.
You know adding wxEuphoria to the standard install of Euphoria might be a good idea, but it would also require more work. Also, making it easier to install is another good idea. Also, I know there is supposed to be memstruct for 4.1.0, something like a struct or class system would be nice for Euphoria, I know it can be simulated using sequences, but having something like a struct or class would help organize code more.
I'm not sure if a specific GUI library should be "official", because people have different preferences. But there's no reason why wxEuphoria, win32lib, euGTK, and FluidAE couldn't have their own versions of IDEs that are easy to install, learn, and use....well, other than the fact that it takes time to develop all of that. Personally, I plan to develop a cross-platform IDE and graphical debug/bind/translate tools for Euphoria in FluidAE. I would like to make a Euphoria installer utility, but the biggest problem I see is dealing with administrative privilege elevation. Registry and file system access is probably not hard to deal with.
It is true making a GUI would be diffcult, but it would help. Also, wxEuphoria, FluidAE and Win32lib and the other GUI toolkit wrappers are great. By having a struct or class structure, what I mean is, it would be nice if for instance, if Euphoria had a struct keyword, like how struct is in C. Struct Player { Health, Lives} end Struct or something like that. Yes I know 4.1.0 is supposed to have some sorta of memstruct, but I don't know, I haven't looked deeply into it yet. Also, yes having some more functions to make it easier to wrap C and C libraries would be great. Also by having some sort of struct in Euphoria, it would be much easier to wrap classes or structure functions from C and C libraries.
20. Re: Future direction and purpose of Euphoria?
- Posted by Nevla Aug 12, 2014
- 2937 views
I love Euphoria, but after what? Sixteen years following it now? I'm moving on to other stuff.
I've contributed a little here and there. I love the language, the simplicity, and the syntax. But then I started really digging into the source code and realized what a mess it really is internally. Maybe it's not the worst source code out there, but when I compare the source to something much cleaner like the FreeBASIC source, it's like wow. All kinds of kluges, work-arounds, platform-specific code which should be generalized, etc.
...
But I really think is that the main language needs a re-write from the ground up (C backend and Euphoria front end and translator), which is much too large of a job for me.
Is the situation really as messy as you describe it? Or perhaps the above comments were a bit of an overstament? I am surprised that the language developers have not responded to these strong statements.
21. Re: Future direction and purpose of Euphoria?
- Posted by jimcbrown (admin) Aug 12, 2014
- 2919 views
I love Euphoria, but after what? Sixteen years following it now? I'm moving on to other stuff.
I've contributed a little here and there. I love the language, the simplicity, and the syntax. But then I started really digging into the source code and realized what a mess it really is internally. Maybe it's not the worst source code out there, but when I compare the source to something much cleaner like the FreeBASIC source, it's like wow. All kinds of kluges, work-arounds, platform-specific code which should be generalized, etc.
...
But I really think is that the main language needs a re-write from the ground up (C backend and Euphoria front end and translator), which is much too large of a job for me.
Is the situation really as messy as you describe it? Or perhaps the above comments were a bit of an overstament? I am surprised that the language developers have not responded to these strong statements.
Speaking as a language developer, I concur with jaygade.
There are good historical reasons for this mess (the current incarnation of the language started out as a DOS-only program, and was heavily optimized for speed on 1990s era systems), but that doesn't make it any easier to use.
I'm reminded here of the original Linux kernel project, and how it was first ported to another platform (I don't remember which, PowerPC or Alpha or m68k or something...) and it ended up with two separate code branches for each platform. Linus Torvalds quickly wised up and realized such a mess would be unmaintainable, and the end effect was that reports were done so all the ports were in the same code base.
Due to the level of complexity and lack of interest, no one has taken the time to tackle this. I think everyone pretty much considers it a good idea, but it's just hard and unrewarding.
22. Re: Future direction and purpose of Euphoria?
- Posted by Nevla Aug 12, 2014
- 2881 views
Speaking as a language developer, I concur with jaygade.
There are good historical reasons for this mess (the current incarnation of the language started out as a DOS-only program, and was heavily optimized for speed on 1990s era systems), but that doesn't make it any easier to use.
I'm reminded here of the original Linux kernel project, and how it was first ported to another platform (I don't remember which, PowerPC or Alpha or m68k or something...) and it ended up with two separate code branches for each platform. Linus Torvalds quickly wised up and realized such a mess would be unmaintainable, and the end effect was that reports were done so all the ports were in the same code base.
Due to the level of complexity and lack of interest, no one has taken the time to tackle this. I think everyone pretty much considers it a good idea, but it's just hard and unrewarding.
The question comes to my mind: which of the two major currently supported platforms (Windows and Linux) is more likely to receive the best support in the future developments of the language? I am asking this on the assumption that, short of re-writing the whole thing from the ground up as suggested by jaygade (which seems very unlikely, from what I understand, because of lack of resources), the time may come when the developers decide to concentrate all their efforts on one platform only. Of course, this is just pure speculation on my part. However, it is an undeniable fact that messy code in the long run tends to become more and more unmanageable, and this might also push the decision towards restricting the scope of supported platforms.
A twin question is: at the present stage, which of the two above-mentioned platforms is better supported by Euphoria? On which of the two does Euphoria work better?
23. Re: Future direction and purpose of Euphoria?
- Posted by jaygade Aug 12, 2014
- 2916 views
BTW, take my criticism with a grain of salt. I have a lot of faith in the core Euphoria developers.
Because of the way some portions of the code are written, though, makes it difficult to port or maintain on other platforms such as OS X and ARM. We end up with some #ifdef hacks in the code to make things work differently on different platforms when some areas (but not all) should be refactored instead. I think there should probably be very few areas of the code that are truly platform-dependent.
However, the job was too big for me. I may tackle it again in the future. Plus I'm really quite an amateur still, and I'm also afraid of introducing changes or "cleanup" which will work on my platform but will horribly break others.
Regardless, support for both Linux and Windows are very strong, I don't believe that support will decrease at all on either platform.
24. Re: Future direction and purpose of Euphoria?
- Posted by jimcbrown (admin) Aug 13, 2014
- 2839 views
The question comes to my mind: which of the two major currently supported platforms (Windows and Linux) is more likely to receive the best support in the future developments of the language?
It's really developer driven. Right now we have a few who do Linux/GNU, a few who do Windows, and some who do both. A platform gets supported for as long as there are interested devs who want to support it.
I am asking this on the assumption that, short of re-writing the whole thing from the ground up as suggested by jaygade (which seems very unlikely, from what I understand, because of lack of resources), the time may come when the developers decide to concentrate all their efforts on one platform only. Of course, this is just pure speculation on my part. However, it is an undeniable fact that messy code in the long run tends to become more and more unmanageable, and this might also push the decision towards restricting the scope of supported platforms.
I think this is assumption is demonstratably false. The opposite tends to be true - we have less support for OSX and BSDs now, but the source is still there and if a new dev wants to start actively pushing out new BSD builds or something, that dev will have a running start thanks to the earlier work left in.
If anything, we're pushing for more platforms, not less.
A twin question is: at the present stage, which of the two above-mentioned platforms is better supported by Euphoria? On which of the two does Euphoria work better?
Actually, this question is ill-defined, as these aren't really a single platform. The experience may well differ between Linux/GNU on ARM and Linu/GNU on x86-64, for example.
With this in mind, I'd say that support for all platforms represented in your question are more or less equally well supported.
Since I only use one platform, I can't answer the other question.
25. Re: Future direction and purpose of Euphoria?
- Posted by Nevla Aug 13, 2014
- 2837 views
I think this is assumption is demonstratably false. The opposite tends to be true...
Jim, I am not going to argue with you. After all you are one the developers and I am just a newcomer to the language. But what I was trying to say, I guess, is that concentrating on a more restricted number of platforms would probably help in letting you sort out that "mess" and to have a cleaner code.
26. Re: Future direction and purpose of Euphoria?
- Posted by jimcbrown (admin) Aug 13, 2014
- 2866 views
I think this is assumption is demonstratably false. The opposite tends to be true...
Jim, I am not going to argue with you. After all you are one the developers and I am just a newcomer to the language. But what I was trying to say, I guess, is that concentrating on a more restricted number of platforms would probably help in letting you sort out that "mess" and to have a cleaner code.
Not really. A lot of the ugly code is quite platform independent, unfortunately.Dropping platforms might simplify things a little, but not enough.
27. Re: Future direction and purpose of Euphoria?
- Posted by mattlewis (admin) Aug 13, 2014
- 2854 views
Because of the way some portions of the code are written, though, makes it difficult to port or maintain on other platforms such as OS X and ARM. We end up with some #ifdef hacks in the code to make things work differently on different platforms when some areas (but not all) should be refactored instead. I think there should probably be very few areas of the code that are truly platform-dependent.
The platform ifdefs (from memory) tend to be things that really are different. Like...a system library that uses a different name or a different signature (lots of these between BSD and Linux and especially Windows). In some cases, we've abstracted these to the header and use our own macro wrappers so the ifdefs don't show up in the actual code.
Other areas involve low level stuff like calling C functions. Or making callbacks. Then you have 32 vs 64 bit stuff that really can't be abstracted any further (we do use stdint.h, so lots of stuff 'just works' on different platforms). We're cutting / have cut down on the number of compilers, which has simplified a fair amount of stuff.
That said, if anyone can spot something that could be refactored to make supporting different platforms easier, I'm sure we'd be interested in finding that and doing it.
Matt
