And to attract contributors, you have to have a convincing vision.
right
please make a decision for you to program in a language that has fame
or one that you like most. as moritz said the special variables are now
better sorted and some changes you write about are too far from perls
basic
Moritz Lenz schrieb:
What makes Perl hard to read is the excessive use of special characters
(/\W/).
I disagree: The make it look ugly, but not hard to read.
Even if it's only ugly: To what advantage? I don't think ugliness is a
good characteristic of a programming language.
Global
On 14 May 2007, at 11:51, Thomas Wittek wrote:
I also can't remember that I ever named a variable like a reserved
word or operator. And even if I could, I'd consider it to be bad
style.
How did you know which reserved words and operators were going to be
introduced in the future so you
chromatic wrote:
Global variables with cryptic names, that no beginner can make any sense
of by reading it. And after not working with $ for some months I
can't remember it either, although I've got quite some Perl experience.
Most of those have gone away.
Oh, some someone must agree that
Andy Armstrong schrieb:
On 14 May 2007, at 11:51, Thomas Wittek wrote:
I also can't remember that I ever named a variable like a reserved
word or operator. And even if I could, I'd consider it to be bad style.
How did you know which reserved words and operators were going to be
introduced in
On 14 May 2007, at 12:31, Thomas Wittek wrote:
How did C, C#, Java, Ruby, Python, Lua, JavaScript, Visual Basic,
etc. know?
They didn't.
If there is a new release, you always have to check if your code
still runs.
I think that may be the point I'm making.
--
Andy Armstrong, hexten.net
herbert breunung schrieb:
please make a decision for you to program in a language [..]
[..] try python. [..]
Oh, just because I think that they've some smart design decisions?
Why not steal them?
BTW: Why do so much people say go away if you don't like it instead of
being open for ideas and
I'm so tired of hearing how unreadable Perl is. It's specious. But
if so many people think it... Uh-uh. Instinctive reactions can be
both universal and incorrect...and I think that's what this is. At
least, among those who have even bothered to look into Perl instead of
just repeating FUD.
herbert breunung schrieb:
please make a decision for you to program in a language [..]
[..] try python. [..]
Oh, just because I think that they've some smart design decisions?
Why not steal them?
BTW: Why do so much people say go away if you don't like it instead of
being open for
Andy Armstrong schrieb:
On 14 May 2007, at 12:31, Thomas Wittek wrote:
How did C, C#, Java, Ruby, Python, Lua, JavaScript, Visual Basic, etc.
know?
They didn't.
If there is a new release, you always have to check if your code still
runs.
I think that may be the point I'm making.
Your
On Mon, May 14, 2007 at 02:36:10PM +0200, Thomas Wittek wrote:
Andy Armstrong schrieb:
On 14 May 2007, at 12:31, Thomas Wittek wrote:
How did C, C#, Java, Ruby, Python, Lua, JavaScript, Visual Basic, etc.
know?
They didn't.
If there is a new release, you always have to check if your code
On Monday 14 May 2007 04:28:15 Thomas Wittek wrote:
I'm not a friend of potential conflicts between built-in operators and my
identifier names (and especially the conflicts between scalar, aggregate,
type, and function names).
As I partially wrote Moritz, I
a) don't think that it's the
On Monday 14 May 2007 04:35:19 Thomas Wittek wrote:
BTW: Why do so much people say go away if you don't like it instead of
being open for ideas and discussing them from a neutral point of view?
Perhaps you're not a native English speaker, but running into the room and
saying Perl 6 doesn't
Thomas Wittek wrote:
Moritz Lenz schrieb:
What makes Perl hard to read is the excessive use of special characters
(/\W/).
I disagree: The make it look ugly, but not hard to read.
Even if it's only ugly: To what advantage? I don't think ugliness is a
good characteristic of a programming
Moritz Lenz wrote:
Thomas Wittek wrote:
Moritz Lenz schrieb:
I would also like semicolons to be optional.
Most people don't ;-).
Oh, really? Source? :)
I paraphrased Larry Wall. Iirc it was everybody wants the semicolon or
something - correct me if I'm wrong.
sorry, masak++ pointed out
On Mon, 14 May 2007 12:51:53 +0200
Thomas Wittek [EMAIL PROTECTED] wrote:
Reason? I still haven't seen a good justification for sigils.
This may not qualify as a good justification, but it is one I've
discussed with others and rings true for many. Take a look at
actual code written
Author: larry
Date: Mon May 14 10:13:16 2007
New Revision: 14390
Modified:
doc/trunk/design/syn/S02.pod
doc/trunk/design/syn/S06.pod
doc/trunk/design/syn/S12.pod
Log:
coercion type renamed from returns to as to avoid confusion with of type.
ambiguity in block-end parsing noted by rhr++
On 5/14/07, John Macdonald [EMAIL PROTECTED] wrote:
Removing the sigil
on a function call (it used to always be written sub(args...))
did, I think, lead to the difficulty in perl5 where it became
difficult to add new keyword operators to the language - because
they could conflict with
OK! Be concrete ! :-) ( Hart wie Beton !)
As Ruby and Python are getting more and more attraction [1][2] I think
they do something right, that Perl doesn't.
What I think where both (especially Python) do better is in readable
code.
What makes Perl hard to read is the excessive use of
On Mon, May 14, 2007 at 20:41:35 +0300, Gabor Szabo wrote:
On 5/14/07, John Macdonald [EMAIL PROTECTED] wrote:
Removing the sigil
on a function call (it used to always be written sub(args...))
did, I think, lead to the difficulty in perl5 where it became
difficult to add new keyword
Thomas Wittek skribis 2007-05-14 0:42 (+0200):
excessive use of special characters (/\W/).
This seems to be I don't like regexes. Ignoring for now that Perl 6
regexes will be more verbose and thus easier to read for someone without
much prior exposure to them, what would you suggest as an
On Mon, May 14, 2007 at 02:21:47PM -0400, Ryan Richter wrote:
: In Perl 6, the sigil is used to distinguish between
:
: foo bar
:
: which calls bar and passes the return value to foo, and
:
: foo bar
:
: which passes bar as a Code object to foo.
In other words, the sigil is consistently a
Hi everyone,
I don't want to argue about the design of perl6[1], I just wonder: why
the semicolon is still needed in the end of lines in perl6?
I can think of different reasons (history, readability, easier parsing
of multiline statements, force people to write one-line functions to
avoid
I don't want to argue about the design of perl6[1], I just wonder: why
the semicolon is still needed in the end of lines in perl6?
JavaScript allows to omit semicolumn. In lecture at Yahoo's YUI
Theatre one of JS's gurus talked about how it is organized in
JavaScript parser.
If the line of
JavaScript allows to omit semicolumn.
Sorry, s/lumn/lon/.
By the way, Perl also ignors semicolumn :-)
--
Andrew Shitov
__
[EMAIL PROTECTED] | http://www.shitov.ru
On Mon, May 14, 2007 at 07:05:01PM +0200, gabriele renzi wrote:
: Hi everyone,
:
: I don't want to argue about the design of perl6[1], I just wonder: why
: the semicolon is still needed in the end of lines in perl6?
:
: I can think of different reasons (history, readability, easier parsing
:
Frank Wiles schrieb:
Take a look at
actual code written in other languages and you'll find many variable
names that end in things like _ary, _array, _dict, _list, etc.
Actually I've not seen that often. Where I've seen it frequently is in
Visual Basic and Delphi/Pascal.
I hated it too.
But I
chromatic wrote:
theproblemlinguisticallyspeakingisthatsometimes [snipped]
I can't remember that I said that you shouldn't separate your
expressions (by punctation/whitspaces),
$.but! (*adding$ %*characters _+that^# $might) @#not_ !#be()
!necessary_ *#$doesn't! *(make) [EMAIL PROTECTED] =_easier
On 5/14/07, Andrew Shitov [EMAIL PROTECTED] wrote:
JavaScript allows to omit semicolumn.
Speaking of JavaScript, any experienced JavaScript programmer will
tell you that while semi-colons are in fact optional, you should
always treat them as mandatory, to avoid subtle errors creeping into
your
At 11:43 -0700 5/14/07, Larry Wall wrote:
In other words, the sigil is consistently a noun marker in Perl 6, even when a
sigil is used on a verb.
It would seem to me that a preprocessor, written in perl of course, could
easily respond to DIMENSION noun AS double statements or whatever you like
Thomas Wittek skribis 2007-05-14 22:20 (+0200):
But I think that the name of an identifier (noun/verb, single/plural,
the meaning of the word) already gives enough context to understand what
type it is.
So is user_id a variable or a type? How about substring or
document?
Is new a function, or
Thomas Wittek skribis 2007-05-14 22:31 (+0200):
$.but! (*adding$ %*characters _+that^# $might) @#not_ !#be()
!necessary_ *#$doesn't! *(make) [EMAIL PROTECTED] =_easier
Those characters are meaningless. The many symbols in Perl 6 have very
distinct meanings, which makes them very powerful tools!
gabriele renzi wrote:
Hi everyone,
I don't want to argue about the design of perl6, I just wonder: why
the semicolon is still needed in the end of lines in perl6?
It isn't - sometimes. S03 identifies a number of ways that an
expression can be terminated: the semicolon (';'), a block-final
Aankhen wrote:
Speaking of JavaScript, any experienced JavaScript programmer will
tell you that while semi-colons are in fact optional, you should
always treat them as mandatory, to avoid subtle errors creeping into
your code.
We should also note that the idea of omitting ';' is not as
Good examples. Now could you provide some to explain to me why it's
important to distinguish between '$', '@', '%', and ''? I ask
because I've seen a lot of object-based code that has said stuff like
'$container{$key}'; it seems that there's an assumption that $foo can
be used as a list, a
Jonathan Lang wrote:
^[3]: If this were included in the core, you might even reverse things
so that ';' is defined in terms of postfix:. or infix:{'=='},
depending on the context; in this case, postfix:? would be defined
in terms of postfix:., rather than postfix:;. In fact, the only
thing
On 5/14/07, Jonathan Lang [EMAIL PROTECTED] wrote:
Good examples. Now could you provide some to explain to me why it's
important to distinguish between '$', '@', '%', and ''? I ask
because I've seen a lot of object-based code that has said stuff like
'$container{$key}';
Well,
Juerd Waalboer wrote:
Thomas Wittek skribis 2007-05-14 22:20 (+0200):
But I think that the name of an identifier (noun/verb, single/plural,
the meaning of the word) already gives enough context to understand what
type it is.
[examples]
You are right, I should have weakened this sentence by
Thomas Wittek wrote:
chromatic wrote:
theproblemlinguisticallyspeakingisthatsometimes [snipped]
I can't remember that I said that you shouldn't separate your
expressions (by punctation/whitspaces),
$.but! (*adding$ %*characters _+that^# $might) @#not_ !#be()
!necessary_ *#$doesn't!
Juerd Waalboer schrieb:
Thomas Wittek skribis 2007-05-14 0:42 (+0200):
excessive use of special characters (/\W/).
This seems to be I don't like regexes. Ignoring for now that Perl 6
regexes will be more verbose and thus easier to read for someone without
much prior exposure to them, what
On Mon, May 14, 2007 at 02:29:11PM -0700, Jonathan Lang wrote:
2. This brings up the possibility of custom-designed termination
operators.
cf. Semi::Semicolons. I think that being flexible enough that people can
write packages like that is one of Perl 6's greatest strengths.
Long may it
Thomas Wittek skribis 2007-05-15 0:48 (+0200):
The Perl Way:
$object.foo() calls the method called foo.
$object.$foo() calls the method that is in the variable $foo.
My way:
someref = somemethod
object.someref()
Of course you could argue that you don't know in advance, if object
has a
Andrew Shitov:
If the line of code is not ended with ';' the parser tries first
to assume [..]
Wouldn't that be unambigous?
foo = 23
bar = \
42
?
I think there would be no ambiguities and you only had to add additional
syntax for the rare cases instead of the common cases.
--
Jonathan Lang skribis 2007-05-14 14:52 (-0700):
Good examples. Now could you provide some to explain to me why it's
important to distinguish between '$', '@', '%', and ''?
It's useful code self documentation, but not very important, in my
opinion.
If you have sigils, it makes sense to have
On Monday 14 May 2007 15:48:24 Thomas Wittek wrote:
But it should be no problem to put out a warning/error at runtime (or
maybe even at compile time) when a variable name clashes with a method
name.
Do you always know all of the method names in your entire memory space at
compile time?
-- c
Austin Hastings:
A similar trade-off exists with the statement terminating semicolon. In
this case, it involves the number of statements per line:
A language that terminates statements can ignore whitespace, allowing
multiple statements per line and statements that span multiple lines.
On Tue, May 15, 2007 at 01:22:48AM +0200, Thomas Wittek wrote:
Andrew Shitov:
If the line of code is not ended with ';' the parser tries first
to assume [..]
Wouldn't that be unambigous?
foo = 23
bar = \
42
?
I think there would be no ambiguities and you only had to add
Thomas Wittek skribis 2007-05-15 1:03 (+0200):
On the other hand, the overall structure of a program is often more
obvious, exactly because so much more fits in one screenful.
My suggestions won't have an impact on the expressiveness of Perl.
Not so.
Consider /@foo/, which is an
Juerd Waalboer schrieb:
Thomas Wittek skribis 2007-05-15 0:48 (+0200):
The Perl Way:
$object.foo() calls the method called foo.
$object.$foo() calls the method that is in the variable $foo.
My way:
someref = somemethod
object.someref()
Of course you could argue that you don't know in
Mark J. Reed wrote:
Jonathan Lang wrote:
Good examples. Now could you provide some to explain to me why it's
important to distinguish between '$', '@', '%', and ''? I ask
because I've seen a lot of object-based code that has said stuff like
'$container{$key}';
Well, $container{$key} is
Thomas Wittek skribis 2007-05-15 1:52 (+0200):
Would it be a good idea to call methods on objects, that never thought
of this methods?
Absolutely! Roles can be used for that too.
--
korajn salutojn,
juerd waalboer: perl hacker [EMAIL PROTECTED] http://juerd.nl/sig
convolution: ict
Speaking just for my own preferences, I very much like having sigils
to differentiate variables from routines, that is, a $ prefix versus
either or no prefix. However, I generally do *not* like the @ and
% prefixes. They seem somewhat contrived so to cover very specific
variable types while
John Macdonald schrieb:
It's also, in many cases,
harder to edit - that's why a trailing comma in a list that
is surrounded by parens, or a trailing semicolon in a block
surrounded by braces, is easier to manage.
Now that the list is surrounded by parens makes clear that it ends with
the
On 5/14/07, Daniel Hulme [EMAIL PROTECTED] wrote:
On Mon, May 14, 2007 at 02:29:11PM -0700, Jonathan Lang wrote:
2. This brings up the possibility of custom-designed termination
operators.
cf. Semi::Semicolons.
Close. I'm thinking added functionality for semicolon alternatives
rather than
On 5/14/07, Thomas Wittek [EMAIL PROTECTED] wrote:
Moritz Lenz schrieb:
What makes Perl hard to read is the excessive use of special characters
(/\W/).
I disagree: The make it look ugly, but not hard to read.
Even if it's only ugly: To what advantage? I don't think ugliness is a
good
OK! Be concrete ! :-) ( Hart wie Beton !)
As Ruby and Python are getting more and more attraction [1][2] I think
they do something right, that Perl doesn't.
What I think where both (especially Python) do better is in readable
code.
What makes Perl hard to read is the excessive use of
On Tue, May 15, 2007 at 02:02:06AM +0200, Thomas Wittek wrote:
John Macdonald schrieb:
It's also, in many cases,
harder to edit - that's why a trailing comma in a list that
is surrounded by parens, or a trailing semicolon in a block
surrounded by braces, is easier to manage.
Now that
Language design is hard. Let's go shopping! :-)
Larry
Thomas Wittek wrote:
Moritz Lenz schrieb:
What makes Perl hard to read is the excessive use of special characters
(/\W/).
I disagree: The make it look ugly, but not hard to read.
Even if it's only ugly: To what advantage? I don't think ugliness is a
good characteristic of a programming
59 matches
Mail list logo
