1. Matt versus Chris
- Posted by jiri Mar 13, 2009
- 1030 views
The the boring tiff between Matt and Chris is gaining momentum and becoming a bit more entertaining, unfortunately for very wrong reasons: it is now completely ridiculous, and nasty insults are creeping in. The guys are both desperately trying to defend indefensible positions.
Here is my take: the old system was clearly bad and no amount of fine fiddling could fix it. The new scheme is poorly documented and appears to be just as bad as the old one, with added level of complexity. Depending on your point of view, it seems to present more problems than it solves.
I know it is easy to criticize and it is much harder to come up with a good solution. I haven't got one - these days I am interested in euphoria only for purely sentimental reasons. But I have one or two suggestion despite the fact they were already sneered at by Matt and co.
First of all, keep it simple! That's the main attraction of euphoria: after all, after more than fifteen years of development it is still essentially a hobbyist's language and that's not going to change any time soon just because you add few tweaks and a half-baked standard library.
If you want something a little bit more concrete, here we go again: keep 'include' directive just for the purpose of joining files at the same level, no hierarchy, just seamless (monolithic) insertion. Keep 'global' directive for system wide, generally useful definitions, and the new 'import' 'export' combination could be used to bring in marked definitions just from 'import'ed files. All naming conflicts would have to be resolved with full qualifications.
And while I am at it, perhaps one or two more (old!) ideas. Drop the stupid, quasi-religious 'declare before use' notion! It has no place in the modern world with fast and sophisticated tools combined with powerful hardware. It is an anachronistic obnoxious restriction of the program's logic flow without any palpable benefits. The compiler will bark at you in a fraction of a second if you forget to declare anything, even in relatively huge programs.
I think we will all agree the sequence is the main feature of euphoria, indeed the cornerstone of the language. It is a remarkably flexible, polymorphous beast, immune from any sort of typing. Strangely enough Rob designed a statically typed language with a weird typing system around it. I think that's one of the reasons why many dynamically typed languages of roughly the same vintage or younger (python, lua, ruby, etc) became vastly more popular. Their authors realized that the bug reduction claims for such systems were always grossly exaggerated. Simply ditch the type declarations altogether, or make them merely optional ('strict' or 'explicit' directive?) to pacify the ultra-conservative element, the retired submariners among us. That would substantially reduce the number of lines we have to write, with attendant improvement in the clarity of the code.
And while I am talking about the code clarity, small doses of syntactic sugar in selected places would do wonders for the euphoria's taste. An example: a dot notation for simpler associative arrays with string keys, would be, I am sure, greatly appreciated.
Just one more, forever studiously ignored wish, before I go to bed - it is getting quite late down here in New Zealand. For goodness sake, get moving on those 'parameters by reference' perennials. For me Derek's recent adventure with stacks highlighted again how badly we need the feature...
jiri
2. Re: Matt versus Chris
- Posted by SDPringle Mar 13, 2009
- 1020 views
You wrote first as someone who wants EUPHORIA to be kept simple. Then to recommend syntax features that already exist in EUPHORIA at the present moment and finally some that was discussed and shot down and then what has been approved but do not exist. EUPHORIA has forward referencing; and type-checking can be turned off with a without statement. Dot notation was already talked about but we decided to keep colons: For compatibility with existing EUPHORIA programs. A syntax change like changing colons to dots do not gain any benefit in semantics of the language. Pass by reference is slated for after 4.0, I think.
Shawn
3. Re: Matt versus Chris
- Posted by jiri Mar 13, 2009
- 1015 views
Shawn, can you read at all?
I was also under impression that the new version of euphoria had forward referencing. I tried to re-arrange several of my pet projects using version 4.0a2. None of them worked, period.
And I was not talking about type checking. I thought it was clear enough I was talking about the need (or lack of it!) to *declare* any type of a variable - but that's obviously too difficult for you to grasp.
And again, I was not referring to your colons at all, I was talking about a dot notation as used commonly in many languages to denote elements of data structures.
Go back and do some serious reading before you open your mouth again!
jiri
4. Re: Matt versus Chris
- Posted by DerekParnell (admin) Mar 13, 2009
- 1014 views
What are you still doing up, you old curmudgeon 
I was also under impression that the new version of euphoria had forward referencing. I tried to re-arrange several of my pet projects using version 4.0a2. None of them worked, period.
If at all possible, could you spare some of your remaining life to tell us, in detail, about what you've found. If there are bugs here we need to know about them.
I was talking about the need (or lack of it!) to *declare* any type of a variable
This could be ambiguous, Jiri. Are you saying that there should be no need to declare variables at all? Or is it just that when we declare varaibles, we should not need to say what type it is?
And again, I was not referring to your colons at all, I was talking about a dot notation as used commonly in many languages to denote elements of data structures.
This is something that is seriously being considered for a future release.
An awful lot of ideas have been put forward for Euphoria's future look, and there is no way we can implement them all at once - unless you wanted to wait for a few years. So one of the decisions we made was to concentrate on those changes that might cause v3.1 programs to break. In other words, we wanted to get all the conversion issues dealt with as early as possible. So a lot of the non-breaking enhancements have been deferred until a release after v4.0.
5. Re: Matt versus Chris
- Posted by jiri Mar 13, 2009
- 1010 views
Derek, get your neglected dictionary and look up 'curmudgeon'. 'A crusty irascible cantankerous old person full of stubborn ideas'. -I don't like being called old twice in the same sentence ;)!
Sorry, Derek, I do not keep failed coding attempts and I have already installed the new (alpha3) version. But one of these days I might try the forward referencing feature of the newer version again. I would let you know how it went.
And I do not think there was anything 'ambiguous' in my sentence about variable declarations. In my book, Derek, explicit variable declaration is type specification, not to be confused with variable assignment.
Many thanks for your explanation of priorities for the new versions.
And now definitely Good Night, its almost 2 o'clock in the morning. You go to bed too, you in Melbourne are only three hours behind us anyway!
jiri
6. Re: Matt versus Chris
- Posted by mattlewis (admin) Mar 13, 2009
- 1018 views
If you want something a little bit more concrete, here we go again: keep 'include' directive just for the purpose of joining files at the same level, no hierarchy, just seamless (monolithic) insertion. Keep 'global' directive for system wide, generally useful definitions, and the new 'import' 'export' combination could be used to bring in marked definitions just from 'import'ed files. All naming conflicts would have to be resolved with full qualifications.
I believe that the current solution is doing a pretty good job of keeping it simple, at least for the way most coders will use the language. The complications arise when building a multi-file library, which most coders probably will not do. However, they do rely on those libraries. And now the library author has some important tools to ensure that his end users can easily use his library without having to worry about it conflicting with other libraries he might wish to use.
The parser tries to use the information it has to determine coder intent with respect to symbol resolution. In other words, if it has a choice between two symbols, one of which is from a file that was included, and one of which isn't, the parser will choose the one that was included. It seems pretty clear that the author wanted to use that symbol.
The typical application coder should never have to worry about using anything other than vanilla includes. Alternative designs that Chris had proposed (and has threatened to post, but has not done so yet) added additional control features, which, IMO, did not Keep It Simple.
And while I am at it, perhaps one or two more (old!) ideas. Drop the stupid, quasi-religious 'declare before use' notion! It has no place in the modern world with fast and sophisticated tools combined with powerful hardware. It is an anachronistic obnoxious restriction of the program's logic flow without any palpable benefits. The compiler will bark at you in a fraction of a second if you forget to declare anything, even in relatively huge programs.
This has largely been dropped. Across file boundaries, there is no requirement for declare before use. For routines, there is no declare before use. Variables being used in the same file or routine, however, must be declared before use. So if you simply declare variables at the top of your code, you should never have an issue.
Use before declare really makes no sense within a routine (or smaller scope, such as an if/for/while/etc block), and it simplifies the implementation a great deal to enforce local variables to be declared. This could change in the future, but I believe that the main benefits of forward referencing have been achieved.
I think we will all agree the sequence is the main feature of euphoria, indeed the cornerstone of the language. It is a remarkably flexible, polymorphous beast, immune from any sort of typing. Strangely enough Rob designed a statically typed language with a weird typing system around it. I think that's one of the reasons why many dynamically typed languages of roughly the same vintage or younger (python, lua, ruby, etc) became vastly more popular. Their authors realized that the bug reduction claims for such systems were always grossly exaggerated. Simply ditch the type declarations altogether, or make them merely optional ('strict' or 'explicit' directive?) to pacify the ultra-conservative element, the retired submariners among us. That would substantially reduce the number of lines we have to write, with attendant improvement in the clarity of the code.
If you really want to, you could simply declare everything as object, and you'd have this. If, however, you mean no such declaration (as python has), then I doubt this will ever happen.
One benefit to declaring specific types is that the interpreter and translator use that information extensively to speed up execution.
And while I am talking about the code clarity, small doses of syntactic sugar in selected places would do wonders for the euphoria's taste. An example: a dot notation for simpler associative arrays with string keys, would be, I am sure, greatly appreciated.
Just one more, forever studiously ignored wish, before I go to bed - it is getting quite late down here in New Zealand. For goodness sake, get moving on those 'parameters by reference' perennials. For me Derek's recent adventure with stacks highlighted again how badly we need the feature...
Yes, there are many syntactic sugar ideas floating around. We're certainly interested in making them, but as Derek noted, they aren't the top priority right now. Pass by reference is another topic that I believe will be addressed in 4.1. It's going to need a lot of discussion to make sure we get it right. Then we'll have to figure out how to implement it...
Matt
7. Re: Matt versus Chris
- Posted by DerekParnell (admin) Mar 13, 2009
- 1040 views
Derek, get your neglected dictionary and look up 'curmudgeon'. 'A crusty irascible cantankerous old person full of stubborn ideas'. -I don't like being called old twice in the same sentence ;)!
Um, actually I did. I wasn't sure of the spelling. Anyhow, according to http://en.wiktionary.org/wiki/curmudgeon we find ...
curmudgeon (plural curmudgeons) 1. (archaic): A miser. 2. An ill-tempered (and frequently old) person full of stubborn ideas or opinions. Usage: "There's a cranky curmudgeon working at the hospital who gives all the patients and other doctors flak." "John Doe's old age and stubborn aversion to new ideas make him a curmudgeon of a candidate."
... one of these days I might try the forward referencing feature of the newer version again. I would let you know how it went.
Excellent and thank you.
And I do not think there was anything 'ambiguous' in my sentence about variable declarations. In my book, Derek, explicit variable declaration is type specification, not to be confused with variable assignment.
Ok, after re-reading your comments (many times), I think you are saying that it would be a good thing if coders could choose whether or not they have to declare variables at all. Hmmm... not so sure this a good idea. Declaration has more purposes than just associating a data type with the symbol. It can also give scope to it, which is fairly important. I'm sure you have heard all the pro/con arguments for this paradigm, so I won't bore you again. Maybe, it is possible to come up with a compromise, but that will have to wait for a future discussion.
9. Re: Matt versus Chris
- Posted by jeremy (admin) Mar 13, 2009
- 1013 views
Here is my take: the old system was clearly bad and no amount of fine fiddling could fix it. The new scheme is poorly documented and appears to be just as bad as the old one, with added level of complexity. Depending on your point of view, it seems to present more problems than it solves.
- The new scheme is documented enough. Not perfect, but we are still alpha! During the alpha stages we code more than we bug fix or document. We bug fix problems that come up. During beta, we test out the wazoo, we document out the wazoo. That's standard practice w/most development projects. The only exception are those development teams that have a hundred developers, two hundred technical writers and three hundred dedicated testers. We are not quite there yet
- Depending on your point of view... It is the point of view of every person (except Chris) who sent over 400 messages on the dev list back and forth during the design of the new system that the new system solved the problems, was simple, and euphorian. The vote was not between Matt and Chris, I believe it was around 15 people who voted and more who were involved in the planning.
Jeremy
10. Re: Matt versus Chris
- Posted by mattlewis (admin) Mar 13, 2009
- 1094 views
This is quite the amusing topic.
As Jeremy stated, it's a continuation of discussions that happened last summer on the dev list. This probably accounts for the tone of the messages, which is unfortunate, but is the result of frustration on both our parts.
I want to be clear that the developers are interested in hearing opinions from everyone, and the tone of that thread is not typical of what happens on the dev list, nor how we'd generally respond to suggestions, criticisms, etc.
Matt
11. Re: Matt versus Chris
- Posted by bernie Mar 13, 2009
- 1042 views
I want to be clear that the developers are interested in hearing opinions from everyone. Matt
My opinion about big libraries and using EU 4.x is that the
loading ( startup, parsing, searching for forward references )
is TOO LONG or SLOW when starting a program. It does not take
that long using ver. 3.11.
12. Re: Matt versus Chris
- Posted by mattlewis (admin) Mar 13, 2009
- 1007 views
I want to be clear that the developers are interested in hearing opinions from everyone. Matt
My opinion about big libraries and using EU 4.x is that the
loading ( startup, parsing, searching for forward references )
is TOO LONG or SLOW when starting a program. It does not take
that long using ver. 3.11.
Is this using code that doesn't have 'proper' include statements? For instance, running Judith's IDE in its previously released state (Derek has started reworking it for 4.0, BTW), none of the files (except for IDE.exw) include win32lib, even though they all use it somehow. I added include IDE.exw to the top of these files, and the parsing time was dramatically reduced.
Also, we've found a memory leak in replace(). The forward referencing code makes a lot of use of replace(), so this memory leak is probably slowing things down, as well. I'm currently working on fixing it. I think I've got it fixed in the interpreter, but not the translatoryet.
There are some other things that we can probably do to speed up this process in general, and they're being looked at, though they obviously have a lower priority to getting the feature set stable, or fixing bugs such as the memory leak in replace.
Matt
