1. party cancelled
- Posted by jiri babor <jbabor at PARADISE.NET.NZ> Sep 10, 1998
- 400 views
- Last edited Sep 11, 1998
Ok, guys, I am sorry, but there is going be no party. Insufficient interest. Hawke was obviously keen, but unwilling to contribute. David tried to sneak in, but was caught and disqualified. The guy obviously makes too many mistakes and is looking for a more fault tolerant system, but that would be a new feature and the party invitation clearly specified only hatable *existing* features were admissible. So now I have the unenviable task to deal with (some will say to) the defenders of the faith. First I will tackle 'irresistible' urges of John DeHope. John wrote: >"case sensitivity" > >Euphoria does one thing that so many other languages don't: it makes you >be a good programmer. John, it's never that easy - you have watched too many TV commercials if you really believe that. Seriously, I have change my mind on this one so many times, I am not quite sure where I stand right now , but the only significant benefit of case sensitivity is that it allows you the lazy 'x' and 'X' as two distinct variables and set and Set and SET as separate routine names - a programming practice which is very difficult to recommend. >"unnecessarily long words and redundant brackets" > >Again, readability. So many people shrug off this issue as if it didn't >matter. The only people who think readability isn't an issue are A) >people who have never had to debug or alter somebody else's code, and B) >people who have never had to debug or edit their own code 3 months after >they write it. Short, illegible syntax is bad: EU is good. What's EU again? (Beautifully observed, David! Thanks.) >"constants" > >It boggles my mind that anybody could really consider constants to be a >bad thing. At this point I wonder if Jiri is just being silly. Unfortunately, this item is slightly out of context, it would make more sense following my 'automatic variable declaration' fiasco. I am not saying the constant is a bad thing, but there is nothing inherently special about it either. It is just a container with a label, a piece of data, just like any other variable. So if you do not want to change it, don't. And if you do not trust your memory, capitalize its name, as I suggested previously. (In some programming environments constants could be fetched faster than normal variables, then, of course, it makes more sense to have a separate mechanism.) >"comma separator" > >Maybe I have gone too far, because this is really going out on a limb. >Jiri: You are kidding, right? No, not kidding. Read again David's comment. It is quite refreshing, because *he* knows what he is talking about! >"curly brackets" > >This improves readability. The concept of a sequence it totally foreign >to anything except Euphoria, it needs its own syntax. In what possible way do the curly brackets improve readability? As you said - mind boggles! I have studied dozens of languages (and used many of them) so please believe me the concept of a sequence is nothing new under the sun. I fact, there is probably not a single element of Euphoria, taken in isolation, that cannot be found elsewhere. What is pretty unique is a very clever selection of various bits and pieces, and the way Robert beautifully welded the lot together. >"types, type checking" > >I'm going mad! Please, somebody that knows Jiri, tell me he is just >kidding! I know jiri quite well and he is not going mad either. To use David's phrase, there are no compelling reasons for types and type checking in Euphoria. Once again I draw your attention to David's own comments, and he has probably done more programming in Euphoria than the rest of us together! And if that is not enough, I'll quote from the Master's letter (Robert is not around at the moment, but I am sure he would not mind). This was in response to my suggestion that types and type checking were really nothing more than a debugging tool of doubtful value: >In the beginning (pre-1.0), all variables were declared as object. >There were no types. >About half way through coding language wars I found that >this hurt the readability of the code, because I started to forget >which variables normally contained sequences, and which >contained atoms. That's when I worked out Euphoria's strange >"type" mechansim. I created built-in types "sequence" and "atom", >and then I wanted a way for the user to add his own types. ("integer" >came later). With user-defined types, my intention was to >have a debugging aid (and to some extent a documentation aid). >It's a way of catching logical errors. I was thinking more in terms of >very large projects, with many programmers. Later on, when I suggested that a non-programmer user was not going to be helped or impressed by "type check failure in line nnn" error message, this is what Robert had to say: >It was never my intention that user-defined types be used to validate >user input. Types should only be used to enforce *internal* >consistency of the program. To be quite honest, I did not find that terribly convincing. So if somehow they enhance your confidence, please, go on and use types as much as you like, but at least until I find how 'enforced internal consistency of the program' can really help me, I will follow David's lead and shy away from them. >"variable declaration" > >I can't go on. Nobody can question the wisdom of undeclared variable >errors. RDS has come so close to creating the perfect programming >language... this must be a joke. No joke, he said with a dark promise in his voice... Should I ask what is so innately wise about an error message. Appropriate perhaps, but wise? Ok, let's take it slowly: what is a constant and what is a variable is sometimes a difficult choice, and very often what started its life as a constant becomes a variable, as the complexity of the program increases. My point is the decision is often quite arbitrary. When we declare our constants, we are quite happy to leave it to the interpreter to fit them with the appropriate types internally. But when it comes to variables, for some inexplicable reason and for *no obvious benefits* we insist on telling the compiler what sort of container we require when it is perfectly capable of deciding that on its own. It is just a modern trend in language design that also makes sense. If you have listened to my argument and can now accept that *explicit* types are completely redundant, then all we really need is a generic object, and this proposition is just a logical extension of the argument. I repeat: a variable can be implicitly, automatically declared by the very first assignment of a value to it. In other words, when you say x=20, for instance, the compiler checks the table of variables for 'x', and if it finds it, it just changes the value. If it does not, it simply creates a new object, an integer in this case, with an appropriate label. An uninitialized variable would still be flagged, so if you say y=x before 'x' is implicitly declared, you would still get the usual dose of compiler 'wisdom' that you seem to cherish so much. Lastly and sadly, Alan Tu. Alan, this is not easy, because I am really angered by you repeated demands that I get off the list. So I'll give you just a couple of free tips: when you do not understand something, it is not necessarily the writer's fault, more often it is your own ignorance. And when you have absolutely nothing to contribute, just shut up! I do. jiri
2. Re: party cancelled
- Posted by Hawke <mdeland at NWINFO.NET> Sep 10, 1998
- 407 views
*sigh* again i hesitate to reply...but... {jiri} > but the only significant benefit of case sensitivity is that it allows > you the lazy 'x' and 'X' as two distinct variables and set and Set and > SET as separate routine names - a programming practice which is very > difficult to recommend. to be fair, before my 'real reply', and to emphasize this ever so crucial point, i wholeheartedly agree. an example that bit me quite viciously only recently: whilst working on the truecolor library, just before my severely fatal winBLOZE crapout, i decided to declare some constants for color... simple enuff? Black={0,0,0} and Blue={150,0,0} and Red={0,0,150} and Green={0,150,0} and etc etc etc (BGR by the way) good so far right? well, when the mouse cursor decided to wrap itself on the right edge of the screen to the left, i had to enter that ever so fun 'fullblowndebugthisdamnthingmode' that we have all done once or twice. lo! and behold! the library included another file (graphics.e i think it was) that had already!!! defined BLACK= WHITE= GREEN= etcetcetc... ewwww nasty, bad bad thing, bad form! this coulda reeked bloody havoc had I not caught it, from some coder using this library, and trying to track down BLACK versus Black...yuck! onwards: {jiri} > It is just a modern trend in language design that also makes sense. If > you have listened to my argument and can now accept that *explicit* > types are completely redundant, then all we really need is a generic > object, ummmm.... perhaps???... maybe??? you didn't fully read 'the masters letter' as he says WHY!!! generic objects only as our choice are 'bad'. {robert} > >In the beginning (pre-1.0), all variables were declared as object. > >There were no types. > >About half way through coding language wars I found that > >this hurt the readability of the code, because I started to forget > >which variables normally contained sequences, and which > >contained atoms. That's when I worked out Euphoria's strange > >"type" mechansim. I created built-in types "sequence" and "atom", > >and then I wanted a way for the user to add his own types. Your suggestion to simply capitalize the first letter if it's a constant (or whatever) really -wont- solve the problem robert is referring to. Namely, readability!.... a very very crucial concept, that goes byebye if you attempt 'naming conventions' that aren't standardized in some fashion. What if joebob capitializes the third letter if it's int, and the first if it's sequence whereas bettyboob uses all cap except the second letter if its an atom... see???? Without some amount of 'typing', even if it is 'fake' (such as a strictly adhered to naming convention used by *all*), readability (and even maintainability) just suffers horridly. {jiri} >I repeat: a variable can be implicitly, automatically >declared by the very first assignment of a value to it. In other >words, when you say x=20, for instance, the compiler checks the table >of variables for 'x', and if it finds it, it just changes the value. >If it does not, it simply creates a new object, an integer in this >case, with an appropriate label. I could agree that having the interpreter do that, automagically, as it does for constants anyway, might just be a good thing. It would be the next logical extension to the arguement that inspired EU (datsa Euphoria :) ) by robert. That C++ (for ex) was just overburdened with overtyping (pascal aint far behind) and it spawned the need for a separate routine for *each* data type. Counterpoint? Can you proffer a solution, implementing this suggestion, that does not hurt readability, elegance, efficiency (after all, having the interpreter do all that 'figuring' might slow it down...easy enuff to get around too i suppose...), maintainability, portability, and reliability? {jiri} > An uninitialized variable would still > be flagged, so if you say y=x before 'x' is implicitly declared, you > would still get the usual dose of compiler 'wisdom' that you seem to > cherish so much. this of course would be mandatory, in an 'object' only language. to sum up: you seem concerned with readability, as marked by your arguement for case insensitivity (which woulda flagged my example real fast, and saved me and perhaps others a lotta headaches), and this concern is good (IMO). But, then... it seems to me that you almost revoke that concern by taking away all 'typing' completely, and whilst doing so, fail to offer an equitable solution to the dilemma robert (and anyone else who has worked on a program that is thousands of lines long) faced with readablity and maintainability. *shrug* that's just how i see it... --take care all, and remember, if it wasn't for typos, none of us would get any programming done at all, and the term 'pre-alpha' would be meaningless (the horror!) :) *watches the ruffled feathers settle slowly, liltingly to the computer printout riddled floor* --g'night--Hawke' all opinions expressed by my words are words that expressed my opinions.
3. Re: party cancelled
- Posted by C & K L <candkNOSPAM2ME at TICNET.COM> Sep 10, 1998
- 402 views
jiri babor wrote: > >"unnecessarily long words and redundant brackets" > > > >they write it. Short, illegible syntax is bad: EU is good. > > What's EU again? (Beautifully observed, David! Thanks.) For a newbie, EU is unknown. For "us," it's known. But it really doesn't matter here. Your point about somebody using "EU" outside programming is irrelevant. The points regarding readability applied to program code that may need to be altered/debugged/whatever, in the future, not informal electronic correspondence. cha-ching (two cents down the drain) ck
4. Re: party cancelled
- Posted by lithex <lithex at INTERGATE.BC.CA> Sep 11, 1998
- 391 views
Hi I think that case sensitivity is a good thing. What I find is that I try to make my code self documenting by choosing nouns for variable names and verbs for procedure and function names, and that I often run out of synonyms for closely related items. Often enough too, the appropriate word is already in use as a reserved keyword. The ability to distinguish words by case give a much larger number of useable names that are suggestive of the action they are associated with. The only argument I can see against case sensitivity is just that people have trouble typing capitals - you know - hitting two keys at once requires advanced digital coordination. Why would anybody mind constants? If you use them they're handy, if you don't they are not. Why deny them to those who like them? Is there a proposal for a substitute for curly brackets? There aren't all that many non-alphanumeric keys on my keyboard that don't need a shift. I use typechecking when I'm debugging during development. It's very useful then, and can be turned off when you don't need it. What could be the problem with it being included in Euphoria as an option, instead of as a requirement as it is in most other languages that I've seen. Party on dudes Bye Martin
5. Re: party cancelled
- Posted by Robert B Pilkington <bpilkington at JUNO.COM> Sep 11, 1998
- 381 views
[CasE SensiTiviTy] >I think that case sensitivity is a good thing. What I find is that I >try to make my code self documenting by choosing nouns for variable >names and verbs for procedure and function names, and that I often >run out of synonyms for closely related items. Often enough too, >the appropriate word is already in use as a reserved keyword. The >ability to distinguish words by case give a much larger number of >useable names that are suggestive of the action they are associated >with. > >The only argument I can see against case sensitivity is just that >people have trouble typing capitals - you know - hitting two keys at >once requires advanced digital coordination. Fact: Programming uses lots of shift characters. That's why we make the big bucks. (Well, sorta... just take out the 'big', and maybe the 'bucks'...) I think case sensitivity is good, if keeps you from writing "ThIs" in some places, and "This" in others, and "this" in still other places, all meaning the samething. Instead, you can use all those as different variable names! Also, if you don't want to make your variable/constants/subroutines use uppercase letters, don't. It's as simple as that. Okay, so I don't see this coming to an end, there's no good argument on either side. Let's just keep it as is so it gets compiled faster. (There, we win! [constant CONSTANT] >Why would anybody mind constants? If you use them they're handy, if >you don't they are not. Why deny them to those who like them? Constants are good. Code that uses constants like PI will run just as fast as programs that replaces the constant with the number, 3.14(more numbers), and be more readable. Plus, if for some reason PI should happen to change, you only have to change one number in the code . . . [SHIFT+characters] >Is there a proposal for a substitute for curly brackets? There aren't >all that many non-alphanumeric keys on my keyboard that don't need a >shift. This is also why the suggested {30 (50+40) (40-3) -5} will fail. It requires more shift9 and shift0's than the old style commas. The reason the curly braces are used, is because that's what's used in C for similar stuff: // C code! // Don't remember if this only works for constants or not, but I have // done this with either variables or constants. int sequence[5] = {0, 1, 2, 3, 4}; // Ah, safe (Now somebody is going to bring up variable initializations in the declaration, ie integer x=0, which I can agree with.) _____________________________________________________________________ You don't need to buy Internet access to use free Internet e-mail. Get completely free e-mail from Juno at http://www.juno.com Or call Juno at (800) 654-JUNO [654-5866]