Avoiding Feature Creep: or On the Up-Sides and Down-Sides of Having an Evolving LanguageI feel the need to say something here, inspired by recent language feature discussions and suggestions, both on our public Chrome newsgroups but also in the betas. I know that many of you, our users, originally come from a Delphi background, and traditionally, Borland introduced about one change to the language per decade, or so it felt like, at least. In contrast, we've been quite "liberal" with extending and evolving the Chrome language; Chrome is only some four years old, and we've added a lot of cool stuff over the course of its life. And don't get me wrong, i think that's a good thing! However, there's a fine line (a very fine line) between keeping a language evolving and growing on one hand, and implementing everybody's "wouldn't it be fun if" suggestions, on the other. We will of course keep expanding the Chrome language according to our vision of where the language should go (and in fact we have many good concepts planned for 'Oxygène' and versions beyond), but that does not mean that we can (or will) jump at every suggestion or language change request that is brought up. This should not be taken personally by those of you who submit suggestions; it's not that your ideas are bad (at least not all of em ;-), but we do need to keep the balance and evolve the language into a consistent direction - not just add every neat gimmick that someone can come up with. Otherwise, we'll end up with a language that no-one recognizes and where no two features work consistently between themselves, five years from now. We don't want that, and i'm sure our users don't want that, either. And if you want something that feels like every singe syntax element was devised by a different person new to the language, there's always Ruby ;) This is of course not to discourage the submission of ideas - many of the language features we've introduced into Chrome have originated from ideas submitted by users and beta testers (sometimes verbatim, and sometimes by evolving the original idea into what we same fit best). Please keep bringing us your ideas, but also please keep in mind that we simply cannot run with each and every one of them! Let me know what you think... Yours, Comments, Pingbacks:
Comment from: Robert [Visitor]
Well, this sums it up qute nicely. :-)
I, too, think that Chrome could get easily highly complex or even inconsistent. OTOH, I will keep on making suggestions, trusting in your and Carlo's taste of what makes sense for Chrome and what doesn't. This worked out very well for the past, right? Cheers, Robert  Permalink
10/04/07 @ 15:06
Comment from: Ajasja [Visitor]
"And if you want something that feels like every singe syntax element was devised by a different person new to the language, there’s always Ruby ;)"
Lame... Permalink
10/04/07 @ 15:58
Comment from: C Johnson [Visitor]
"where no two features work consistently"
Where condition do Begin End; Repeat Until condition; I think we are technically already there, we kinda started there. Permalink
10/04/07 @ 17:37
Comment from: marc hoffman [Member]
@Robert: indeed it has, yes. please keep bringing em on! ;)
@C: i disagree, there's no real inconsistency here. Pascal has different *types* of code constructs, and supporting more then one type of construct doesn't make an inconsistency yet, its essential. You have constructs that take single statements, such as "if expression then statement" or "for ... do statement', and then you have code blocks that can include, one or more statements, such as "begin statements end", "repeat statements until expression" and others. That's just flexibility you need for a language - no language could work well without block statements. It's important to realize that the "begin/end" in your above sample is *not* part of the while "construct", it's a separate statement, the syntax for while is simply "while expression do statement". @Ajasja: thanx for the detailed and well-explained rebuttal. Fact remains, that is the impression i got from Ruby. One day i was following along a Ruby tutorial, figuring with all the fuzz, let's see what this language is like. i liked it for about 20 minute, until the 5th syntax element was introduced and i though wait a minute. this is completely inconsistent with how the 4th one worked. and come to think of it, that one was was inconsistent with the 3rd!. To me, it looked like these features were added to the language without thought for consistence and on the whim of the moment - we need to be able to do this? ok, let's cram it in there somehow. If i have the spare time, i might go back to the tutorial in question and see if i can find some concrete examples... Permalink
10/05/07 @ 10:22
Comment from: Les May [Visitor]
· http://www.mmu.myzen.co.uk/
Yes you have been a bit liberal in extending Pascal. But provided you don't weaken the strong type checking I'm not sure that matters. Some of the things you have added are a definite asset, e.g. the loop construct. This allows a single type of loop with the chance to test and break at the start or end. It nicely resolves the inconsistency in the syntax of repeat.. until loops. In line type declaration? Fine up to a point, e.g. with 'for' loops. Even better here if the variable went out of scope on exiting the 'for' loop. Otherwise a likely source of confusion. Type inference? I'm happy put in an extra line with a proper type declaration which makes things clearer, so I don't use it. Shouldn't we know the type of the objects we use before we operate on them?
We spend most of our time reading our programs not writing them. Anything which makes them less easy to read and understand is a bad thing. Please don't drop support for 'function' and 'procedure'. It is a nice way of jogging the memory that a method does or does not return something. A good syntax highlighting editor like PSPad allows the user to choose what he/she thinks ought to be considered as 'keywords'. This goes a long way to mitigating the problem of additions to the language. Incidentally PSPad now has a built in Chrome Code Explorer the author added at my request. It makes a fine combination with the command line compiler you have so kindly released to us. Permalink
11/12/07 @ 21:36
Comment from: Les May [Visitor]
· http://www.mmu.myzen.co.uk/
Type inference may seem like a good idea but it leads to some very strange and potentially dangerous effects. In my view as presently implemented it seriously weakens the strong typing and compile time error checking of Pascal.
The problem can best be understood by running the following code. namespace DaftIdea; interface type A = class public class method Main; end; implementation class method A.Main; const S : char = ' '; var R : string; V : integer; C : array of String; begin R := 'A B C D'; C := R.Split(S); V := 15; for each V in C do begin Console.WriteLine(V); Console.WriteLine(V.GetType().ToString()); end; Console.WriteLine(V.GetType().ToString()); Console.Read(); end; end. What we see is the same variable NAME being attached to two different TYPES. The compiler issues a warning but it issues the same warning if V is declared as of type string and not integer. This way of implementing type inference is poor. The compiler should check for cases like that above and refuse to compile such code. The V used in the for each loop goes out of scope when the block is exited. This is an excellent and sensible way of implementing type inference. It should be retained. Permalink
11/27/07 @ 20:20
Comment from: marc hoffman [Member]
Les,
while i see your point, you example has nothing to do with type inference, really, but only with variable scope. the same would hapen if your for loop would excplitily type the variable ("for each v: string in..."). similar, the same problem applies to, say, a class-wide property name conflicting with a local var. Permalink
11/27/07 @ 21:26
Comment from: Les May [Visitor]
· http://www.mmu.myzen.co.uk
Thank you for the comment. I had previously tried the explicit type declaration hoping that the compiler would refuse to compile the code and tell me I had a duplicate name. In my view this is the correct way to avoid the problem of having the same NAME for two variables which are of different TYPE.
The going out of scope of the variable declared or inferred in a for loop is an excellent way of doing things which I applaud. But I do not think it overcomes the problems which could arise from having one name, with two (or more) types, in a single method. I don't think the class (unit or program) wide variable with a local variable of the same name in a method is quite the same. This has been a well understood part of 'traditional' Pascal since Wirth created it. Type inference (and in line type declaration) seem to be creating a 'block within a block' structure and introduce a new rule about duplication of variable names. Both type inference and in-line declaration in for loops could have been implemented in a way which avoids the potential problems. It is not my intention to make a 'mountain out of a molehill' and I hope that other people will offer their views on the matter. Permalink
11/28/07 @ 17:01
Comment from: marc hoffman [Member]
Les,
i'm certainly with you. We debated the two options we had here quite a bit (error vs warning), and one of the deciding factors was that with the warning, the code is actually compatible with scenarios where people defined their variable manually (in v1) before the for each loop. for loops have always been defined in the way that the result of the loop var is "undefined" after the loop exists, so that the code below actually works correct in Chrome 1.x and Joyride (in 1.x it uses i for the loop and needs it defined prior; in Joyride, the loop declares its own i). var i: Int32 := 123; ... for each i in IntArray do ... if we had opted for the error, this code would have broken from 1.x to Joyride. Permalink
11/28/07 @ 17:11
Comment from: Les May [Visitor]
· http://www.mmu.myzen.co.uk
Thank you for the explanation of the rationale behind your choice.
A declared variable can be used a second time in a later for loop in 'traditional' Pascal, i.e. it remains known to the compiler. I think what is meant in most texts is that its value may be undefined upon exit from the loop. In FreePascal it has the terminating value of the for loop. In the Chrome implementation of for loops which make use of in line declaration or type inference, the loop variable is undefined upon exit, i.e. not known to the compiler. This leads to a much safer outcome in these two cases. Can I suggest that it might be helpful if the nature of the warning was changed to something like 'duplicate variable name' to emphasise the point? I assume this would need only a minor change to the compiler. Permalink
11/28/07 @ 20:31
Comment from: marc hoffman [Member]
Les: sure thing, i'll have a look if we can improve the warning message...
thanx! Permalink
11/28/07 @ 22:41 Leave a comment:
|
marc hoffmanChief Software Architect & LinksNavigationArchives
XML Feeds
|
||
