So here are some other things to consider that support the position that E should have only a single syntax.
Marcs wrote:
>
> Let me make sure you know what they expect as loop
> flow constructs:
>
> While( ) ... Wend
> Do While( ) ... Loop
> Do Until( ) ... Loop
> Do ... Loop While( )
> Do ... Loop Until( )
> For i in (set or list) ... Next i
> For i = 1 to 3 ... Next i
Markm wrote:
> [#] Let's compare with E
> Actually, I didn't know that VB had all these, but it doesn't matter.
[#] VB seems too different. In fact, my first reaction to seeing the above constructs was "you might as well give up". They all look so different from what E might expect that a VB programmer would need to spend time learning new constructs anyway. If you can't match the VB syntax exactly, now you have three syntaxes that a VB->E programmer would need to be able to read (VB, E/VB, and E/{}). I bet that then switching between VB and E/VB would confuse people about the syntax, and also possibly confuse them into expecting other things from E that aren't there.
> >While(cond)
> > ...
> >Wend
>
> >Do While(cond)
> > ...
> >Loop
>
> While (cond)
> ...
> End While
[-] Easy to confuse these. That makes three very similar but slightly different ways of writing exactly the same thing which the VB->E programmer must hold in his/her head at once. Granted, two of them are from VB -- but the E example helps blur the variation between the other two as it seems to stand somewhere between them. This seems like a bad thing to me. (cf. "Similar things should be either the same or very different.")
> >Do
> > ...
> >Loop While(code)
>
> Loop break
> ...
> If (! cond)
> break()
> End If
> End Loop
[-] This loop example is a lot to learn anyway. It looks to me like it already covers a good 70% of the distance from VB to E in the effort to write the Loop, add the break condition, and understand the need for declaring "break", with only a small bit of effort left to account for the braces. There is also an effort required to remember that you can't write a one-line if-statement, which i believe you can do in VB.
> Except for the test-at-the-end constructs, I believe the E versions are
> close enough for immediate familiarity and comfort.
[#] Let's do a survey. This definitely seems like an issue to be settled by experiment rather than speculation.
> [-] Irritation factor would be too high.
> When I think about the role-reversed scenario -- of asking myself to put up
> VB syntax style, my eagerness to use the language -- even my own language!
> -- goes down substantially.
[?] Are VB programmers the right audience? I assume you are saying here that the irritation would be too high for programmers familiar with VB but not with C. But i really wonder whether this is an audience we want to target. Despite their large ranks, it seems to me that VB programmers are primarily interested in scripting data flow among Microsoft applications and automating/augmenting Word and Excel with macros and such. I don't see that they would be particularly interested in secure distributed objects. Another possible survey question, then: what do VB programmers really do?
> >Meanwhile, the
> >idea of reading code with a mix of {} and endIf traumatizes me, and
> >probably a lot of other people.
>
> [-] Agreed, so don't do it.
> I know this guy, something Stiegler I think, that's already written one E
> pretty printer in E. Reading code with inconsistent indentation would
> traumatize me too, but good conventions and/or this pretty printer means I
> don't need to worry about that.
[-] It's not easy to avoid mixing syntaxes. Even if such a pretty printer existed, only a tiny fraction of users would bother to download and install it; and even if the pretty-printer/converter were set up as an integrated part of every E system, the inconvenience of running it on half the code you see would discourage its use. Would it filter all the e-mail messages you receive and all the Usenet postings you read? What if your client is Netscape, Eudora, Pine, or Emacs instead of bin/mail or trn? You may yourself be willing to write all the tutorials and examples twice, but would every third party that wrote about E publish two sets of books?
My feeling is that if both syntaxes are allowed and promoted, we will be unable to shield ourselves from the mixed code in general. And reading a mix of C-style and VB-style code would traumatize me much worse than merely inconsistently indented code. (I deal with inconsistently indented code all day -- naturally inconsistent because we don't all get our authoring tools to do it automatically, and, of course, because with these syntaxes the delimiters and the indentation together are redundant.)
> [-] I believe earlier email said VB had no inheritance,
> which is certainly encouraging. My surprise was finding out that both Perl
> & Python did have inheritance. Anyone know about Javascript or VBScript?
[#] Javascript sort of has inheritance. It is object-oriented only in a weird half-baked (typically Netscape) way -- you create methods only by first declaring functions and then stuffing the functions inside the objects individually, and you get something like inheritance by assigning to a special property name (looks like something they tried to steal from Python).
!ping