Dnia Sat, 19 May 2007 00:26:15 +0900, Gregory B. napisa³(a):
Except eRuby is a general templating system, and Haml is for XHTML generation.
It is not true. Haml can generate non valid XML content as well. But it
is
true that Haml main target is XHTML and CSS generation. For CSS
generation
is Sass which uses very similiar approach
http://haml.hamptoncatlin.com/docs/sass
Is it not strange that such solution was invented
by Ruby, not Python, guys?
On 5/18/07, Jaroslaw Z. [email protected] wrote:
He didn’t say anything about readability. In terms of syntax structure
and
consistency, Haskell is better than Python. Every language is easy to
read
if you’re used to reading it.
Jason
On 5/18/07, Jaroslaw Z. [email protected] wrote:
How well does Haml work with non-HTML templating?
-austin
Hi,
In message “Re: Why not adopt “Python Style” indentation for Ruby?”
on Sat, 19 May 2007 00:20:06 +0900, Jaroslaw Z.
[email protected] writes:
|> I admit Haskell syntax is much better than Python’s.
|
|Matz, you must be joking… Python is much easier to read than Haskell.
To rephrase, “Haskell INDENTATION SYNTAX is much better than
Python’s”. Clear?
matz.
On 5/18/07, Jaroslaw Z. [email protected] wrote:
Dnia Sat, 19 May 2007 00:26:15 +0900, Gregory B. napisa³(a):
Except eRuby is a general templating system, and Haml is for XHTML generation.
It is not true. Haml can generate non valid XML content as well. But it is
true that Haml main target is XHTML and CSS generation. For CSS generation
is Sass which uses very similiar approach
http://haml.hamptoncatlin.com/docs/sass
Neither is useful for those of us who want general purpose templating.
There are bigger problems in the world than your little web-apps.
-austin, generates C++ with erb
Hi,
In message “Re: Why not adopt “Python Style” indentation for Ruby?”
on Sat, 19 May 2007 00:15:05 +0900, Jaroslaw Z.
[email protected] writes:
|What do you think about OPTIONAL block indendation in Ruby?
I am not positive for general block-by-indentation idea. If one
REALLY loves the idea, Python always waits for you.
But I sometime want “end”-less single line structure (in normal
order), e.g.
if foo then bar # pseudo syntax; you may require delimiters
not
bar if foo
especially when I write very small code chunk. Not knowing what
syntax it should be.
matz.
On 5/18/07, Eric M. [email protected] wrote:
On 5/18/07, Yukihiro M. [email protected] wrote:
I’ve picked up on python in the last couple months and like the
indentation. In addition to forced readablity, I find another
practical benefit is that it eliminates hard to track down syntax
errors due to matching {}, begin/end, etc. In ruby, C, perl, etc
these errors can be painful to track down in a large file with lots of
blocks within blocks.
Scope indicated by whitespace is an indication, IMO, that the compiler
thinks that it knows better than you do.
Always a mistake.
I want a programming language that works how I do; I don’t want to
have to work how a stupid programming language requires it.
(I sometimes put debug statements flush left so that it’s a simple
/^p to search for them. Can’t do that with scope controlled by
whitespace. Dumb, dumb, dumb, dumb.)
-austin
On 5/18/07, Austin Z. [email protected] wrote:
thinks that it knows better than you do.
Always a mistake.
I want a programming language that works how I do; I don’t want to
have to work how a stupid programming language requires it.
(I sometimes put debug statements flush left so that it’s a simple
/^p to search for them. Can’t do that with scope controlled by
whitespace. Dumb, dumb, dumb, dumb.)
That is the exact same case I find the indentation thing gets in the
way. I had to change my way of putting in print debug statements
(same as yours). Every language makes you change your ways a bit. Of
course python’s debug facilities (pdb) are much better than ruby’s so
I don’t do print debugging as much.
I would rather have multiple ways to specify blocks:
- {}'s
- indentation
- in-line (single statement/expression)
BTW, python’s lambda sucks! You can’t put generic code in there - it
must be a single expression. I think it has to do with the
indentation thing. Only statements can have code blocks (using
indentation) and a lambda is an expression. I don’t like the clear
separation of statements and expressions that python has. I think it
all comes back to the indentation thing. They didn’t do it right.
Sounds like Haskell did (but I have no experience with it).
In message
[email protected], “Austin
Ziegler” writ
es:
(I sometimes put debug statements flush left so that it’s a simple
/^p to search for them. Can’t do that with scope controlled by
whitespace. Dumb, dumb, dumb, dumb.)
Suspiciously familiar!
-s
On 2007-05-18, gga [email protected] wrote:
No editor I am aware knows how to match indentation yet or do/end
contexts (not that it could not be coded, thou).
Emacs + ruby-mode.el understands do/end just fine.
Regards,
Jeremy H.
Chris D. wrote:
As far as I can see, the ‘end’ keyword is ‘repeating yourself’ when
used with properly indented code.
class Foo
def bar(value)
if value < 7
puts “hello”
else
puts “world”
end
end
def foobar
puts “foobar”
end
end
could be
class Foo
def bar(value)
if value < 7
puts “hello”
else
puts “world”
def foobar
puts “foobar”
The is one big disadvantage in Python’s syntax. Things like…
def bar(value); (value<7) ? (puts “hello”) : (puts “world”); end
…are not possible in Python - and they are useful for the typical
one-to-three-liners in support areas, where Ruby still has the chance to
replace Perl - a chance that Python never had.
I know that my example has nothing to do with documentation oriented
software development, but this is not necessary for a broad range of
small ad-hoc tools.
Wolfgang Nádasi-Donner
On May 18, 12:19 pm, “Eric M.” [email protected] wrote:
blocks within blocks.
No, it is just the other way around. Languages that use curly braces
for indentation like C, Perl, etc. are EASY to work with once code is
not properly factored and it extends outside a single page. Ruby is
easy only when you use {, not so much when you use do/end,
unfortunately, as most editors know nothing about it. Some good
editors (emacs, for example), can tell you the context you are in the
modeline with curly braces, but not so with other block indentation
types. And most editors can easily find matching braces. No editor I
am aware knows how to match indentation yet or do/end contexts (not
that it could not be coded, thou).
Python is a true nightmare to debug and understand once you have code
that trails off a single page. A good example of these problems, for
example, is the Maya Python API which is as ugly as it can be, using
all of the ugliest things of python (tabulation using tabs, lots of
underscore methods, lots of code that is not easily refactored, etc).
Another problem with indentation only that has not been mentioned is
that simple cut and paste of source code between two files is not
guaranteed to work (and often will lead to a syntax error or worse, a
runtime error). This to me is still a big no-no for indentation only,
as most programmers do often cut and paste code from different
contexts or files. With languages that use braces or Ruby’s do/end
you really don’t have to worry about that, for the most part.
language features where Python leads Ruby.)
Here my 5 cents…
Gentlemen, if you want to code Python style, go ahead, program in
Python.
I mean every language has it’s pros an cons. I come from a Java world
(11 years of Java) and I am not asking that Ruby should be Java like.
That is absolute nonsense.
Ruby is like Ruby, so, if you like it (as I do) take it, if you
don’t… there are lots of different programming languages out there
you can choose from, or like Mats, go ahead and develop your own (you
will notice it’s actually not that easy to do it right…)
Cheers,
Enrique Comba R.
“Yukihiro M.” [email protected] wrote in message
news:[email protected]…
Hi,
In message “Re: Why not adopt “Python Style” indentation for Ruby?”
on Fri, 18 May 2007 23:15:05 +0900, “S.Volkov” [email protected]
writes:
…
|suggestion: make ‘end’ optional if code block contains only one
statement;
I’m not sure if we can define syntax for above suggestion.
while cond
puts a
puts b # delimit by indentation or else??
You are right, not feasible - rejected
or maybe
while cond: puts a # should be in same line
Thus we introduce new semantic for newline!
Following construct becomes invalid (and confusing):
while cond: puts a
puts b
end
=>my personal opinion - NO
imho: we need special terminator anyway, now it is ‘end’, could be
another;
suggestion: introduce ‘;;’ terminator for 'implicit blocks (not started
with
class/module/def/do/begin), ie:
#–
while cond : puts a ; puts b ;;
# but
while cond do puts a ; puts b end
#-- until - same as while
#–
if cond : p a ;;
#–
if cond : p a else p b ;;
#-- unless - same as if
#–
for var in expr : p var ;;
# but
for var in expr do p var end
#-- case - sorry my lunch time ended, has to return back to my office…
BRs
Sergey V.
Hi,
In message “Re: Why not adopt “Python Style” indentation for Ruby?”
on Sat, 19 May 2007 03:15:17 +0900, “S.Volkov” [email protected]
writes:
|imho: we need special terminator anyway, now it is ‘end’, could be another;
|suggestion: introduce ‘;;’ terminator for 'implicit blocks (not started with
|class/module/def/do/begin), ie:
For your information, 1.9 once had exact same syntax you’ve proposed
for a short while. I have a time machine. The idea was abandoned
since it caused serious unreadability.
matz.
On 5/18/07, Yukihiro M. [email protected] wrote:
with
|class/module/def/do/begin), ie:
For your information, 1.9 once had exact same syntax you’ve proposed
for a short while. I have a time machine. The idea was abandoned
since it caused serious unreadability.
matz.
Very glad to hear it. We don’t want Ruby turning into Ocaml, rife with
unreadable symbols and impossible to follow constructions.
Ruby’s do/end is just fine. So we can’t do two-liner if statements. I’ve
never, ever liked that syntax as it makes code at first glance
confusing.
e.g.:
int i = 0, j = 0, x = 0;
for(i = 0; i < 10 ; i++)
for(j = 0; j < 30; j++);
for(x = 0; x < 100; x++)
printf(i + j + x);
I’m a big fan of the more verbose keywords of Ruby because for one there
are
very few of them and two it makes the language easy to read.
Jason
On 5/18/07, gga [email protected] wrote:
No, it is just the other way around. Languages that use curly braces
for indentation like C, Perl, etc. are EASY to work with once code is
not properly factored and it extends outside a single page. Ruby is
easy only when you use {, not so much when you use do/end,
unfortunately, as most editors know nothing about it. Some good
editors (emacs, for example), can tell you the context you are in the
modeline with curly braces, but not so with other block indentation
types. And most editors can easily find matching braces. No editor I
am aware knows how to match indentation yet or do/end contexts (not
that it could not be coded, thou).
Vim does this just fine.
-austin
Eric M. schrieb:
You might consider something like this as an alternative block syntax.
Maybe a “:” followed by a newline (and extra indentation) would start
this style. I’m not sure of a clean way to handle arguments though.
What about another syntax:
Putting a special character at the beginning of every line that is
governed by significant whitespace.
Thes would cause no problems with normal Ruby syntax,
but would provide a way to use significant indentation if one really
wants to.
If “~” were that special character, it would look like that:
~ 5.times do |n|
~ n.times do
~ print n
~ puts
Of course, hardly any editor would be prepared to support this,
currently…
This approach would have the additional advantage
of being more robust to contexts where leading whitespace
gets stripped.
Cheers
Sven
On May 18, 5:22 pm, Sven S. [email protected] wrote:
but would provide a way to use significant indentation if one really
wants to.
If “~” were that special character, it would look like that:
~ 5.times do |n|
~ n.times do
~ print n
~ puts
I can’t count how many times I’ve forgotten “do”. Sometimes I have
wished a colon could “induce” the block:
5.times |n|:
n.times:
print n
puts
But I don’t think a line prefix is worth the trouble.
T.