1. You can't compare language features, only languages
- Posted by ghaberek (admin) Nov 19, 2014
- 2899 views
Here's an interesting blog article I came across today. It's a short read and worth the time. It certainly applies to a lot of the discussion around here lately.
http://lukeplant.me.uk/blog/posts/you-cant-compare-language-features-only-languages/
Language features exist within the context of a language and everything surrounding that language. It seems to me that attempts to analyse them outside that context simply lead to false generalisations.
Of course, being really concrete and talking about specific languages often ends up even more personal, which has its own pitfalls! Is there a good way forward?
-Greg
2. Re: You can't compare language features, only languages
- Posted by Shian_Lee Nov 20, 2014
- 2780 views
... Is there a good way forward?
-Greg
I've practiced years Tae-Kwon-Do, which is a martial art. This practice helped me to understand and to solve many questions.
During the years, I've realized the necessity to go backward. Many famous battles would have failed if the army would just go forward.
My father, which spent his entire life in the army, had to see with his own eyes the result of simply going forward - which was Stalin's favorite way; the results were millions of dead Russian soldiers. That didn't bother Stalin at all, since he was fanatic.
In war, mistakes are done. too many. and the price is very high. It's important to analyze mistakes and to fix them. A war is not a spelling mistake in MS-Notepad.
A good way forward, in many cases, is a good way backward.
Example specifically to Euphoria:
As much as the built-in 'goto' statement offers clear advantages over other types of flow control statements or methods - it has a proven bad side effects.
I guess you all programmers must know the bad side effects of 'goto'.
'goto' is a low level command. It has no place in a very high level language, which one of it's goals is to keep the code readable/maintainable and minimalist - by all the users of the language.
The way experienced fighter knows the way backward - experienced programmer must know the way backward too. It needs courage and maturity.
Removing 'goto' from the arsenal of Euphoria - is one step forward by moving one step backward.
'goto' is not the only case.
Please be brave and honest when it comes to moving backward.
And please don't attack me with 100 posts, since I don't have the time to read or answer.
Euphoria is NOT a toy language. A very professional applications, written in Basic in the 90's, are still in use until today. And also in Euphoria. One of my QuickBasic programs is in use more then 20 years already - and it kicked out from the business 3 competitors, which used C or Pascal, but failed to achieve the quality of the one I wrote in QuickBasic.
Euphoria is way beyond Basic, in terms of power and possibilities.
Again - don't attack me. I believe that the developers are still interested to hear about the users point of view.
3. Re: You can't compare language features, only languages
- Posted by ArthurCrump Nov 20, 2014
- 2757 views
I agree that 'goto' is a low level command. However, now that it has been introduced it cannot be removed.
I often used both conditional and unconditional 'goto's when I wrote in an assembly language, several decades ago. Now I would normally only use 'goto' if I were translating a program that used a form of 'goto' from another language into Euphoria; a very unlikely event now that I have been retired for several years.
Could 'goto' be marked as 'undesirable'?
Arthur
Incidentally, my first assembly language was called 'PIG'
4. Re: You can't compare language features, only languages
- Posted by system_X Nov 20, 2014
- 2819 views
The goto may be a controversial subject, but removing a feature that even just a few users rely upon can be devastating. If a feature is clearly a security vulnerability that cannot be patched without it's removal then maybe it might be acceptable to remove. Breaking user space will not make a language more popular or more reliable.
As far as the topic of this thread goes, I don't know how to give any useful input since the threads I've read have been off the charts. I suppose one could start with the goals of OE and then research successful projects with even just one shared goal and try to dissect the situation they created to be successful.
I feel like more than just languages should be compared. What truly added to a language's success. Should an official board be created like Debian? Should a feature request and/or bounty system be put in place for features, libraries, wrappers etc? I've never built a RH/Fedora package, but I'd be willing to do the research and build one if some users are interested. Is there a specific page on this website for me to officially declare that and have others +1 or -1 it other than the forum?
5. Re: You can't compare language features, only languages
- Posted by Shian_Lee Nov 20, 2014
- 2747 views
I agree that 'goto' is a low level command. However, now that it has been introduced it cannot be removed.
"cannot" will never lead us anywhere.
The courage to change will lead us somewhere. But it needs courage.
It's better to solve a problem while it's small. As time goes by, problem only gets more complex.
6. Re: You can't compare language features, only languages
- Posted by jimcbrown (admin) Nov 20, 2014
- 2739 views
I agree that 'goto' is a low level command. However, now that it has been introduced it cannot be removed.
"cannot" will never lead us anywhere.
The courage to change will lead us somewhere. But it needs courage.
It's better to solve a problem while it's small. As time goes by, problem only gets more complex.
How do you know that we haven't already passed the point of no return where goto is concerned?
7. Re: You can't compare language features, only languages
- Posted by Shian_Lee Nov 20, 2014
- 2734 views
I feel like more than just languages should be compared. What truly added to a language's success. ...
True.
I assume that most users are looking for standard GUI library; and new users are looking for an up-to-date Euphoria-IDE.
For a high level and all purpose language - GUI library and IDE is one step forward to success, these days.
8. Re: You can't compare language features, only languages
- Posted by Shian_Lee Nov 20, 2014
- 2737 views
I agree that 'goto' is a low level command. However, now that it has been introduced it cannot be removed.
"cannot" will never lead us anywhere.
The courage to change will lead us somewhere. But it needs courage.
It's better to solve a problem while it's small. As time goes by, problem only gets more complex.
How do you know that we haven't already passed the point of no return where goto is concerned?
Let the users vote for it in the front page. Add a short objective explanation, and just let them vote for a month or two.
9. Re: You can't compare language features, only languages
- Posted by evanmars Nov 20, 2014
- 2757 views
I agree that 'goto' is a low level command. However, now that it has been introduced it cannot be removed.
"cannot" will never lead us anywhere.
The courage to change will lead us somewhere. But it needs courage.
It's better to solve a problem while it's small. As time goes by, problem only gets more complex.
How do you know that we haven't already passed the point of no return where goto is concerned?
Let the users vote for it in the front page. Add a short objective explanation, and just let them vote for a month or two.
Isn't that kind of how goto got included in the first place? Should we have a vote once a year or so to decide which feature/keywords should be removed and added?
10. Re: You can't compare language features, only languages
- Posted by jimcbrown (admin) Nov 20, 2014
- 2737 views
Let the users vote for it in the front page. Add a short objective explanation, and just let them vote for a month or two.
Isn't that kind of how goto got included in the first place?
It is exactly how goto was added. A vote was taken, and users voted to have it.
In any case, this doesn't answer my original question.
Should we have a vote once a year or so to decide which feature/keywords should be removed and added?
In principle this is not a bad idea, but considering that most votes on the forum (for original concepts) have such low turn out, I'm not sure that this would tell us anything useful...
11. Re: You can't compare language features, only languages
- Posted by GreenEuphorian Nov 20, 2014
- 2768 views
I agree that 'goto' is a low level command. However, now that it has been introduced it cannot be removed.
"cannot" will never lead us anywhere.
The courage to change will lead us somewhere. But it needs courage.
It's better to solve a problem while it's small. As time goes by, problem only gets more complex.
@Sian Lee: 'problem'?!? While I appreciate your posts, frankly I do not understand your worry about the 'goto' statement. I don't see it as a problem at all. What matters most, IMHO, is not having or not having a given feature, but to make sure that the programming experience is as smooth as possible (intuitive / respecting the least surprise principle). I do not see any reason for being bothered with the current features of Euphoria. Like you rightly said in an earlier post, let's make the current version more user friendly - this should be the focus.
12. Re: You can't compare language features, only languages
- Posted by jaygade Nov 20, 2014
- 2741 views
We had this 'goto' argument many years ago, and 'goto' won. The argument itself lasted many years.
The key point is that 'goto' is still very rarely used in code. For the programmer himself? If you don't like 'goto' then don't use it. Euphoria has plenty of expressive flow control statements to use in its place.
13. Re: You can't compare language features, only languages
- Posted by irv Nov 20, 2014
- 2726 views
I have used 'goto' twice, I think, in EuGTK - and in both cases, it resulted in cleaner, easier to understand code. Using it more often that that would probably have been a mistake.
If 'goto' is a bad thing, perhaps it's not a fault of the language, but the result of the programmer choosing the wrong tool for the job.
14. Re: You can't compare language features, only languages
- Posted by LarryMiller Nov 20, 2014
- 2711 views
I voted against the inclusion of goto in Euphoria when the question came up. But I later concluded that it has it's place. You need to seriously consider any proposed use of goto. There is almost always a better way. But almost always is not always. There are unusual situations where it is the lesser evil of whatever other options are available. I believe that was the reasoning of those who wished it's inclusion in Euphoria.
The time for the decision on whether goto should be include in Euphoria has come and gone. It is a part of Euphoria and is being used. I don't see a sufficiently compelling reason to remove it.
15. Re: You can't compare language features, only languages
- Posted by _tom (admin) Nov 20, 2014
- 2736 views
Could 'goto' be marked as 'undesirable'?
This is the introduction to goto that I intend to put in the new documentation
goto
The goto flow control statement was added to Euphoria after prolonged discussion.
The goto is often considered to be:
- Evil.
- Should be removed from all languages.
Search the internet for "goto evil" and you will find lots of interesting reading.
The reality is that a goto, in a few rare situations, is the best choice.
Do not use the goto and be content that many programmers will support your programming style.
Use the goto, with discretion, and be grateful that Euphoria gives you a choice.
16. Re: You can't compare language features, only languages
- Posted by _tom (admin) Nov 20, 2014
- 2725 views
I don't know how to give any useful input since the threads I've read have been off the charts.
Just start another "off the chart" thread. Seriously, thus is the charm of the Euphoria forum.
I suppose one could start with the goals of OE and then research successful projects with even just one shared goal and try to dissect the situation they created to be successful.
I feel like more than just languages should be compared. What truly added to a language's success.
How a language becomes successful has always been a hot topic with Euphoria.
Currently, we can probably agree that an IDE specific to Euphoria would be a "good thing." We can not quantify how the lack of an IDE harms, or having an IDE boosts the popularity of Euphoria--but it is obvious that an IDE is "a good thing."
The problem is...who is going to create the IDE?
Just start another thread, toss in some ideas, and see were it takes us.
Should an official board be created like Debian?
Not enough people and resources to create a bureaucracy.
I've never built a RH/Fedora package, but I'd be willing to do the research and build one if some users are interested.
The openSUSE build service looks like the place to start.
A Euphoria rpm would be a valuable addition.
Start a thread to discover if someone has already created an rpm and then proceed.
Is there a specific page on this website for me to officially declare that and have others +1 or -1 it other than the forum?
The wiki page for "Euphoria Roadmap" is from 2010. The best place to communicate is the forum.
_tom
17. Re: You can't compare language features, only languages
- Posted by Shian_Lee Nov 21, 2014
- 2626 views
I agree that 'goto' is a low level command. However, now that it has been introduced it cannot be removed.
"cannot" will never lead us anywhere.
The courage to change will lead us somewhere. But it needs courage.
It's better to solve a problem while it's small. As time goes by, problem only gets more complex.
How do you know that we haven't already passed the point of no return where goto is concerned?
Let the users vote for it in the front page. Add a short objective explanation, and just let them vote for a month or two.
Isn't that kind of how goto got included in the first place? Should we have a vote once a year or so to decide which feature/keywords should be removed and added?
Before you should do something - you have to realize something.
Going full speed forward, without analyzing the current state of the battle field - is what Stalin did, ignoring any possible results (11 to 14 millions dead Russian soldiers).
Moving Euphoria from a very high level language to a mix of low and high level statements - is a new strategy which should be reconsidered again, before moving forward.
I agree that 'goto' is a low level command. However, now that it has been introduced it cannot be removed.
"cannot" will never lead us anywhere.
The courage to change will lead us somewhere. But it needs courage.
It's better to solve a problem while it's small. As time goes by, problem only gets more complex.
@Sian Lee: 'problem'?!? While I appreciate your posts, frankly I do not understand your worry about the 'goto' statement. I don't see it as a problem at all. What matters most, IMHO, is not having or not having a given feature, but to make sure that the programming experience is as smooth as possible (intuitive / respecting the least surprise principle). I do not see any reason for being bothered with the current features of Euphoria. Like you rightly said in an earlier post, let's make the current version more user friendly - this should be the focus.
When I was programming PLC's I had to change some programs which other people wrote.
Since PLC programming don't place any boundaries on the programmer - the code I found looked like a garbage bin; And I had to rewrite it from the beginning.
'goto' belongs to Assembly, the same way CHR$() or what ever it was belongs to BASIC.
Euphoria is losing its strength by adding strength.
I have used 'goto' twice, I think, in EuGTK - and in both cases, it resulted in cleaner, easier to understand code. Using it more often that that would probably have been a mistake.
If 'goto' is a bad thing, perhaps it's not a fault of the language, but the result of the programmer choosing the wrong tool for the job.
If Euphoria should ever be a popular language, used by programmers from all levels, 'goto' is no more then a trouble maker. New users may find 'goto' a "magic" command, a joker card, that solves any distress.
I voted against the inclusion of goto in Euphoria when the question came up. But I later concluded that it has it's place. You need to seriously consider any proposed use of goto. There is almost always a better way. But almost always is not always. There are unusual situations where it is the lesser evil of whatever other options are available. I believe that was the reasoning of those who wished it's inclusion in Euphoria.
The time for the decision on whether goto should be include in Euphoria has come and gone. It is a part of Euphoria and is being used. I don't see a sufficiently compelling reason to remove it.
If you "surrendered" to 'goto', then inline Assembly might be great as well.
I know from my personal experience that there is a solution for everything. Forcing the programmer to think how to solve a problem without using 'goto', only makes a better code and a better programmer.
In simple PLC 'goto' is not exist, only "gosub" (sometimes), it forced me to think about a better solutions, and it leaded me to find a much more advanced method to code a simple PLC - which used the PLC's limited resources in a much more efficient way.
Could 'goto' be marked as 'undesirable'?
This is the introduction to goto that I intend to put in the new documentation
goto
The goto flow control statement was added to Euphoria after prolonged discussion.
The goto is often considered to be:
- Evil.
- Should be removed from all languages.
Search the internet for "goto evil" and you will find lots of interesting reading.
The reality is that a goto, in a few rare situations, is the best choice.
Do not use the goto and be content that many programmers will support your programming style.
Use the goto, with discretion, and be grateful that Euphoria gives you a choice.
I am not grateful at all for this choice.
The lack of 'goto' in Euphoria has no meaning for me. I can live without it forever.
The existence of 'goto' in Euphoria leads me to think "What's next...?" and "What's the strategy?".
18. Re: You can't compare language features, only languages
- Posted by system_X Nov 21, 2014
- 2646 views
I agree that 'goto' is a low level command. However, now that it has been introduced it cannot be removed.
"cannot" will never lead us anywhere.
The courage to change will lead us somewhere. But it needs courage.
It's better to solve a problem while it's small. As time goes by, problem only gets more complex.
@Sian Lee: 'problem'?!? While I appreciate your posts, frankly I do not understand your worry about the 'goto' statement. I don't see it as a problem at all. What matters most, IMHO, is not having or not having a given feature, but to make sure that the programming experience is as smooth as possible (intuitive / respecting the least surprise principle). I do not see any reason for being bothered with the current features of Euphoria. Like you rightly said in an earlier post, let's make the current version more user friendly - this should be the focus.
When I was programming PLC's I had to change some programs which other people wrote.
Since PLC programming don't place any boundaries on the programmer - the code I found looked like a garbage bin; And I had to rewrite it from the beginning.
'goto' belongs to Assembly, the same way CHR$() or what ever it was belongs to BASIC.
Euphoria is losing its strength by adding strength.
This is not intended to be offensive Shian_Lee. As a martial artist of many years in the past I understand where your coming from, but this isn't war and even if goto does not belong in OE I simply cannot see breaking random programs that users and client's of users rely upon. Here's my take. Goto was voted in, Goto was then implemented, users now have the choice to goto their inventory and choose the Goto weapon of mass destruction, users develop programs using the goto weapon, we remove goto cause we don't trust programmers can goto the manual and read the warning label, now user space breaks, user's user base start creating support tickets.
Whether you have a user base of one or a user base of one million, breaking user space can potentially be very dangerous and does not make for a good reputation.
19. Re: You can't compare language features, only languages
- Posted by Shian_Lee Nov 21, 2014
- 2642 views
Whether you have a user base of one or a user base of one million, breaking user space can potentially be very dangerous and does not make for a good reputation.
Enough said.
Back to work.
20. Re: You can't compare language features, only languages
- Posted by system_X Nov 21, 2014
- 2650 views
I feel like more than just languages should be compared. What truly added to a language's success. ...
True.
I assume that most users are looking for standard GUI library; and new users are looking for an up-to-date Euphoria-IDE.
For a high level and all purpose language - GUI library and IDE is one step forward to success, these days.
I agree that's what a lot of new users are looking for. I have faith that what ryanj is working on will be of great value to help deliver a multi platform GUI library and IDE. Do you have any recommendations on the best way to interface with Linux graphics at a somewhat low level? libxcb.so no longer appears to be the way to go since everything is moving to Wayland which IMO is a good thing. EuGTK has functioned great in my testing, but it would be really nice to go lower level than that. However, would their be a performance gain to go lower than GTK?
21. Re: You can't compare language features, only languages
- Posted by irv Nov 21, 2014
- 2627 views
GTK 3.16 has an OpenGL widget for doing graphics. Support for that will be in an EuGTK update I'll try to post Dec. 1.
22. Re: You can't compare language features, only languages
- Posted by GreenEuphorian Nov 21, 2014
- 2605 views
Whether you have a user base of one or a user base of one million, breaking user space can potentially be very dangerous and does not make for a good reputation.
I don't agree. Lua developers break the language's continuity at nearly every release. Yes, it does create some disruption, but Lua users are happy all the same. The Lua development philosophy is improving the language all the time, no matter what. Result: they have a first-rate language that is very popular in its own niche.
23. Re: You can't compare language features, only languages
- Posted by system_X Nov 22, 2014
- 2555 views
Whether you have a user base of one or a user base of one million, breaking user space can potentially be very dangerous and does not make for a good reputation.
I don't agree. Lua developers break the language's continuity at nearly every release. Yes, it does create some disruption, but Lua users are happy all the same. The Lua development philosophy is improving the language all the time, no matter what. Result: they have a first-rate language that is very popular in its own niche.
Due to the fact that I'm not a Lua user, I can't state that I'm happy with their breakage process and I surely can't claim all Lua users are happy with it. I don't even necessarily think goto should stay in OE. I stated a good reason to not break user's programs with hopes that someone could reply with good enough reason we should break user's programs.
Do we have a page on this website that states goals, rules, social contract or something of the sorts?
24. Re: You can't compare language features, only languages
- Posted by Shian_Lee Nov 22, 2014
- 2529 views
Do we have a page on this website that states goals, rules, social contract or something of the sorts?
I would hope that we could avoid being totalitarian dictators and swing more towards beneficial anarchy (a.k.a democracy).
The only way to keep democracy is to establish constitution and to respect this constitution. Many democracies never did and never will respect their own constitution.
What is the "constitution" of Euphoria 4? Does Euphoria 4 has any constitution?
I could see clearly how Euphoria 3 is keeping logical boundaries - which personally I found beneficial.
I cannot see clearly the logic in Euphoria 4 strategy.
Why that's important?
I've read only 70 books or more about this subject, and I've spent years studying the necessity and result of strategy, and I simply assume that most of the readers at least understand the importance of it.
The developers will decide, not me. but the goal of the developers and the users is the same.
25. Re: You can't compare language features, only languages
- Posted by GreenEuphorian Nov 22, 2014
- 2507 views
Do we have a page on this website that states goals, rules, social contract or something of the sorts?
Apparently we don't. I created the other thread about Euphoria's identity/philosophy precisely to move a step toward this direction, but sadly not much was accomplished with it. Clear guidelines are needed not only by the developers, but also by the users, who want to know where the language is going, how it's developing. For example, as pointed out by Shian Lee, the shift in development from being a very high language to a language that mixes high and low level statements was not something insignificant, and yet it was not made obvious to all users. I am not against it, by the way. I am merely pointing out that many users would be grateful to have these major decisions clearly stated, rather than being only told features x,y,z are being added/removed. As requested in the other thread, we should define Euphoria's identity and development philosophy a bit more explicitly.
What is the "constitution" of Euphoria 4? Does Euphoria 4 has any constitution? I could see clearly how Euphoria 3 is keeping logical boundaries - which personally I found beneficial. I cannot see clearly the logic in Euphoria 4 strategy.
Same as above. System_X and Shian Lee's remarks seem to confirm my understanding that users appreciate things being spelled out.
26. Re: You can't compare language features, only languages
- Posted by jimcbrown (admin) Nov 22, 2014
- 2471 views
Do we have a page on this website that states goals, rules, social contract or something of the sorts?
Yes, we do have have a set of goals: the roadmap.
http://openeuphoria.org/wiki/view/EuphoriaRoadmap.wc
http://openeuphoria.org/wiki/view/RoadmapBeyond.wc
In terms of an explicit social contract, there's not much. We do have a coding convention and code of conduct, but that's it.
http://openeuphoria.org/wiki/view/CodingConvention.wc
27. Re: You can't compare language features, only languages
- Posted by Shian_Lee Nov 23, 2014
- 2417 views
in http://openeuphoria.org/wiki/view/RoadmapBeyond.wc:
While there are clear and simple to use ideas, such as:
- Named parameters: function abc(sequence name="John", integer age=30) ... abc(age=18)
- Sequence slicing on function returns: def = abc()[1..3]
- Multiple assignment on return: {a,b,c} = xyz() -- xyz returns {"",0,"toe"}
There are not obvious or scary ideas, such as:
- Object oriented programming or some other type of structured data access for native euphoria data
- Dynamic code evaluation, including using an embedded interpreter
Euphoria 4 already introduced tricky ways to enter or break branching statements and loops, which makes it harder to understand the code quickly, in my opinion. Adding other type of structured data might lead to a new language - maybe "Euphoria++"?
I know that someone might someday need something - but if every language should supply ALL the options for any theoretical need... then Euphoria will end up bloated, useless, not easy and not fun to use.
28. Re: You can't compare language features, only languages
- Posted by ghaberek (admin) Nov 23, 2014
- 2447 views
There are not obvious or scary ideas, such as:
- Object oriented programming or some other type of structured data access for native euphoria data
- Dynamic code evaluation, including using an embedded interpreter
Euphoria 4 already introduced tricky ways to enter or break branching statements and loops, which makes it harder to understand the code quickly, in my opinion. Adding other type of structured data might lead to a new language - maybe "Euphoria++"?
I know that someone might someday need something - but if every language should supply ALL the options for any theoretical need... then Euphoria will end up bloated, useless, not easy and not fun to use.
I think these two features would be very helpful. Most popular languages already offer object-oriented programming, dynamic code execution, REPL, and reflection. I think that by not offering these features, Euphoria quickly turns away a lot of new-comers. Just because one inexperienced programmer might break his own code with an "advanced" feature is no reason to not include that feature to the benefit of other "advanced" programmers who may use it correctly. One library that would certainly benefit from an object-oriented design is wxEuphoria, since it is based on wxWidgets, which is deeply object-oriented itself.
-Greg
