Re: Euphoria vs. other programming languages
- Posted by mattlewis (admin) Mar 12, 2009
- 1348 views
Hi Chris,
actually I do not quite understand you. I once wrote to you that this quarrel is academic and that there are more ways to reach a goal. Many ways lead to Rome. If I report a problem then because I use Eu 4.0, because it is alpha, because I do not find a workaround for myself and because I trust into the development team. If I had your knowledge and your capabilities I would try to offer a solution myself. Really.
I did, but ayatollah Matt & Jeremy said there was nothing to discuss.
Chris, we discussed this a lot. We discussed it until everyone but you agreed.
Most Eu coders are happy to have had time to write code that eventually works. When the compatibility breakage goes beyond cosmetic changes like variable names, it is quite unreasonable to ask them to rewrite, as the code organisation itself may be affected. The coder base is simply not large enough for the luxury you suggest. Perl could do it, not Eu.
Well, this is mainly what we have in the case of euphoria 4.0. You keep mentioning things that structurally break most 3.1 code. There are a few cases where this might be true due to reliance on global symbols and parsing order, I believe they are quite rare, and easily fixed.
You're a long way from convincing anyone who has knowledge of 4.0 that we're all going to have to do major overhauls of our code due to the change to scoping and forward referencing. The new standard library will perhaps be the most difficult part, and even that shouldn't be too difficult.
Other languages do this neither with their versions. To port programs from 3.1.1 to 4.0 you have to change some keywords anyway. (label, entry, continue, switch, break). I will not use global with Eu 4.0.
As I said, a 10 minute nearly automated change process is acceptable, I think. You cannot get past it anyway, or not easily. Changing the semantics of the language is a completely different story.
Please stop trying to propagate ignorance.
And to be honest I would deprecate the use of global in Eu4.0 at all. Using the public and export keywords seem to be the better strategy to test and maintain separate modules / libraries. I do run my include files with exw/exwc to see if there are error messages. And although I like IDE and Win32lib they are also good examples in my opinion that they could be improved in Eu 4.0 only by using public and export. This would lead to a different structure of the include files, but I think this would also help to test and maintain the individual modules more effectively.
Why deprecate global? It has very legitimate uses. But alternative schemes should be provided so that it becomes useful only for special cases, just like goto.
The global scope could possibly bail you out like goto. Though I'm not sure it's even that useful. It does allow some dangerous coding practices, so it certainly allows the shooting of one's foot like goto does.
Matt
