Walter Bright:
> Those things are fine for scripting language programs that are fairly short (like under a screenful). It gets increasingly bad as the size of the program increases.

You may look at Zope (written in Python), that codebase is a bit more than a screenful long; so evidence shows you may be wrong.

You may also take a look at Scala code, that is a java-like language (plus functional ideas) with optional semicolons. It seems a good enough language to use.
Note that the "auto" of D too removes redundancy, and once it has caused me a little bug, quickly fixed, I think "auto" is very useful still.

> How should:
>    f()
>     *g()
> parse?

Like this:
f();
*g();

That's a call to f() followed by what it seems an error.

Bye,
bearophile

bearophile wrote:
> Like this:
> f();
> *g();
> 
> That's a call to f() followed by what it seems an error.
> 
> Bye,
> bearophile

An expression statement is not an error. If g() returns a struct with an opStar() that has side effects, that's a perfectly valid construction, and an excellent idea for the next D obfuscated code contest you're in.

"bearophile" <bearophileHUGS@lycos.com> wrote in message news:fvt3r2$2qfj$1@digitalmars.com...
> Walter Bright:
>> Those things are fine for scripting language programs that are fairly short (like under a screenful). It gets increasingly bad as the size of the program increases.
>
> You may look at Zope (written in Python), that codebase is a bit more than a screenful long; so evidence shows you may be wrong.
>

Just because a large program *has* been written in such a language doesn't mean it's a good idea in general. I could write a large mission-critical program in Perl or a graphics library in brainfuck if I really wanted to, just like a builder could put up a house by using a big rock instead of a hammer. Still doesn't mean it's the right tool for the job.

> Note that the "auto" of D too removes redundancy, and once it has caused me a little bug, quickly fixed, I think "auto" is very useful still.
>

I'd argue that the metric of "with/without redundancy" is a little bit misleading, simply because we can all come up with obscure counter-examples (ex: A language that requires you write an exact duplicate of every source file, just like when creating a password. Wheee!). The way I see it, the real issue is whether the alleged productivity enhancement helps the programmer make mistakes, or helps the programmer catch/avoid mistakes. Typically that takes the form of some sort of redundancy, but the key is "Mistakes: Nurtured Or Inhibited?". That's just the way I see it, anyway.

>> How should:
>>    f()
>>     *g()
>> parse?
>
> Like this:
> f();
> *g();
>
> That's a call to f() followed by what it seems an error.

Depends on the specific manner in which semicolons are made optional. If they're just flatout made optional by having "end-of-statement" somehow be inferred by statement semantics, then the code is totally ambiguous (But I'm not sure anyone was really advocating this method anyway, were they?) If, however, newline either becomes the new "end-of-statement" or shares the "end-of-statement" role with semicolon, then yea, it gets interpreted as two unrelated function calls, the second of which is attached to a unary prefix "*" operator. In the case of newline being a/the "end-of-statement", then multi-line statements would be either impossible, or require a "C Macros"/"Visual Basic"-style symbol for "continue statement on next line" (which is perfectly doable, but not something I'm personally a big fan of for reasons I mentioned in an earlier post in this thread.)

Maybe I just stated the obvious there, I dunno. But I thought it should said that there are those different possible meanings for "optional semicolons", each with their own implications.

Nick Sabalausky wrote:
> Just because a large program *has* been written in such a language doesn't mean it's a good idea in general. I could write a large mission-critical program in Perl 

I know of at least one large (non-web) system written in Perl that was servicing over 2 million users before being switched. Perl with "use strict" and some good coding standards can be just as clean as any other language. It's gotten a bad reputation because of its shell scripting roots and use by web designers with limited programming experience.

IMHO, Perl is a _lot_ easier to (write, read, maintain) than PHP. When I was writing PHP for a resarch project, I found myself literally spending hours tracing down bugs caused by typos in variable names, but a simple "use strict;" in Perl fixes that completely.

"Robert Fraser" <fraserofthenight@gmail.com> wrote in message news:fvu5k1$2gct$1@digitalmars.com...
> Nick Sabalausky wrote:
>> Just because a large program *has* been written in such a language doesn't mean it's a good idea in general. I could write a large mission-critical program in Perl
>
> I know of at least one large (non-web) system written in Perl that was servicing over 2 million users before being switched. Perl with "use strict" and some good coding standards can be just as clean as any other language. It's gotten a bad reputation because of its shell scripting roots and use by web designers with limited programming experience.
>
> IMHO, Perl is a _lot_ easier to (write, read, maintain) than PHP. When I was writing PHP for a resarch project, I found myself literally spending hours tracing down bugs caused by typos in variable names, but a simple "use strict;" in Perl fixes that completely.

Well, it was just an example. Perhaps a poorly chosen one. I'm really not as familiar with Perl as I am with others like PHP, VB*, Python, etc. Feel free to take "Perl" and insert "{name of some shitty language here}".

(Since you bring it up: as much as VBScript annoys the crap out of me, I find that I still prefer it to PHP for the sole reason that VBScript has "option explicit", fixing all those stupid hard-to-track-down typos. Not that PHP doesn't have it's advantages over VBScript in other areas, though. If they'd add a "use strict", I'd be flying a giant "PHP > VBScript" banner. At least for pre-.NET ASP anyway. Not sure how relevant that is now though. As for ASP.NET, well, I've been successfully avoiding web dev for awhile so, don't know, don't care ;) )

Nick Sabalausky wrote:
>> IMHO, Perl is a _lot_ easier to (write, read, maintain) than PHP. When I was writing PHP for a resarch project, I found myself literally spending hours tracing down bugs caused by typos in variable names, but a simple "use strict;" in Perl fixes that completely.
> 
> Well, it was just an example. Perhaps a poorly chosen one. I'm really not as familiar with Perl as I am with others like PHP, VB*, Python, etc. Feel free to take "Perl" and insert "{name of some shitty language here}".

Sorry; I know that wasn't the point of your post. Perl is just unjustly maligned because it _can_ be confusing and is often used badly. But the language is actually quite well-designed.