View mode: basic / threaded / horizontal-split · Log in · Help
May 07, 2008
Re: why ; ?
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
May 08, 2008
Re: why ; ?
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.
May 08, 2008
Re: why ; ?
"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.
May 08, 2008
Re: why ; ?
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.
May 08, 2008
Re: why ; ?
"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 ;) )
May 09, 2008
Re: why ; ?
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.
Top | Discussion index | About this forum | D home