C
Charles Oliver Nutter
Wilson said:
A stable development release. As I understand it, 1.9.1 will still be
considered "unstable" as far as release cycles go...
- Charlie
This is why Ruby 1.8.6 can never be made to run anywhere near as fast as Python 2.5.1
A stable development release. As I understand it, 1.9.1 will still be
considered "unstable" as far as release cycles go...
- Charlie
B
Bill Kelly
Wow, I wish there were some sort of universal wisdom involved, but
I'm pretty sure it was a combination of pragmatism and a personal
bias toward a particular sort of elegance and aesthetics in language
design that appeals to my own sensibilities. (In other words, matz kicks
ass at language design!)
Of course, some languages were easier to loathe than others. <grin>
This article pretty well summarizes the sort of horror I felt when
dealing with VB6: http://www.ddj.com/windows/184403996
As for Python, i tended to find the experience more frustrating and
less fun than writing comparable code in Ruby. Learning Ruby, for me,
involved a lot of "oh, wow, cool I can do that!" Whereas learning Python
I noticed a lot more, "oh... I'm not allowed to do that."
I last used Python about six years ago, and I understand some things
have evolved or improved since then (don't they have something more
akin to Ruby blocks now? And list comprehensions?)
But anyway, a few examples of things that rubbed me the wrong way
about Python. (Note, these may be things that Python people
absolutely love about the language!)
I found the distinction between expressions and statements, and the
restrictions on where one or the other could occur in the syntax, to be
very rigid and unhelpful.
For example, the syntax is:
if expression:
statement
elif expression:
statement
else:
statement
And assignments are not allowed in expressions.
Thus, code that I wanted to write in Python like this, is illegal:
while match = tagOrTextRegexp.search(html, pos):
pos = match.end()
gd = match.groupdict()
if (val = gd.get('startTag')):
attrs = parseAttrs(gd['allAttrs'])
self.handleStartTag(val.lower(), attrs)
elif (val = gd.get('endTag')):
self.handleEndTag(val.lower())
elif (val = gd.get('text')):
self.handleNonTagText(val)
elif (val = gd.get('comment')):
pass # ARTHUR (to KNIGHTS) Walk away. Just ignore them.
else:
assert 0, "unexpected match in regexp - supposed to be impossible"
...ended up being written like this:
while True:
match = tagOrTextRegexp.search(html, pos)
if match is None:
break
pos = match.end()
gd = match.groupdict()
# no assignment-in-conditional sux, Guido
val = gd.get('startTag')
if val is not None:
attrs = parseAttrs(gd['allAttrs'])
self.handleStartTag(val.lower(), attrs)
else:
val = gd.get('endTag')
if val is not None:
self.handleEndTag(val.lower())
else:
val = gd.get('text')
if val is not None:
self.handleNonTagText(val)
else:
val = gd.get('comment')
if val is not None:
pass # ARTHUR (to KNIGHTS) Walk away. Just ignore them.
else:
assert 0, "unexpected match in regexp - supposed to be impossible"
I found this sort of thing very annoying, as can be seen from the note
I left in the code for Guido (von Rossum, Creator of Python.) <grin>
Another example would be class methods. (As opposed to instance methods.)
I remember how hacky and inelegant it seemed to me that every instance
method in Python needed to explicitly list the 'self' parameter:
class Foo:
def bar(self):
print "bar!"
f = Foo()
f.bar
But when I was learning Python, I had an insight and thought, well, at least
I know how to define class methods! Just leave off the self parameter!
class Foo:
def a_class_method(x,y)
return x+y
Then I should be able to call it directly on the class, with no instance passed
in:
Foo.a_class_method(1,2)
Nope. Just doesn't work. No way to define class methods. (Dunno if this
has changed in the past six years or not.)
Anyway, I don't recall many other examples anymore, but I vividly remember
feeling frustrated in this manner often enough while learning Python that I
would actually exclaim, "Guido!!!!" out loud at my desk when it would
happen. (But I should point out that I was still having fun. After all, I enjoyed
programming in Python _a lot_ more than Java.)
Finally, I suppose this is a bit silly, but my very first few minutes with
Python gave me a tangible feeling of trepidation when the following
happened:
I fired up Python (whatever the version was back then), and I got an
interactive interpreter. I was like, yay! cool!
Python 2.4.1 (#1, May 27 2005, 18:02:40)
Type "help", "copyright", "credits" or "license" for more information.
Then I tried to quit:
And I thought... Oh no. Somebody actually knew exactly what I
wanted the computer to do - and actually went through the trouble
to program a message to tell me I was doing it wrong.
But again, while these are aspects of Python that rubbed me the
wrong way, I realize that others may and do feel completely
differently. If Ruby didn't exist, I'd have probably have used
Python for quite a while (maybe moving on to OCaml or Erlang
by now, I dunno.)
Hehe.
I would totally still use Forth for embedded systems programming.
How else could one get an entire dynamic interactive extensible image-
based language with its own compiler and interpreter and editor and
assembler into a few KBytes of memory.
What occurred to me over the years, though, was what really made
Forth so remarkable was its achievement of providing such a dynamic
environment out of such utter sheer simplicity of code and memory
architecture.
There's a lot of beauty in an entire interactive compiler / interpreter
system with a main loop that looks like:
: QUIT ( -- ) BEGIN RESET QUERY INTERPRET AGAIN ;
And of course RESET, QUERY, and INTERPRET are quite simple
themselves. And it's like, Wow! All this dynamicity from such a
beautifully simple architecture!
But as computers got bigger and bigger memories and faster
CPU's, hard drives, file systems, operating systems... I started
to want features that would add complexity to the Forth system,
such as heap-based memory allocation, hashed headers to compile
faster (now that my system included thousands and thousands
of words for interfacing with the operating system), etc...
And eventually Forth wasn't so simple anymore.
And I think Forth's simplicity is part of its appeal... so I started to
hit a wall.
I'll admit I've sometimes wondered what a Forth system would be
like, though, if one took Ruby's VALUE type and made everything
on the data stack something akin to a ruby VALUE. So that
elements on the data stack would become actual objects with
an associated type... and ... well anyway... I guess it would be
sort of a cross between Ruby and Forth. <grin>
But anyway... now I have to get back to some C++ code. (But
tomorrow back to getting paid to code Ruby! Yay!)
Regards,
Bill
I'm pretty sure it was a combination of pragmatism and a personal
bias toward a particular sort of elegance and aesthetics in language
design that appeals to my own sensibilities. (In other words, matz kicks
ass at language design!)
Of course, some languages were easier to loathe than others. <grin>
This article pretty well summarizes the sort of horror I felt when
dealing with VB6: http://www.ddj.com/windows/184403996
As for Python, i tended to find the experience more frustrating and
less fun than writing comparable code in Ruby. Learning Ruby, for me,
involved a lot of "oh, wow, cool I can do that!" Whereas learning Python
I noticed a lot more, "oh... I'm not allowed to do that."
I last used Python about six years ago, and I understand some things
have evolved or improved since then (don't they have something more
akin to Ruby blocks now? And list comprehensions?)
But anyway, a few examples of things that rubbed me the wrong way
about Python. (Note, these may be things that Python people
absolutely love about the language!)
I found the distinction between expressions and statements, and the
restrictions on where one or the other could occur in the syntax, to be
very rigid and unhelpful.
For example, the syntax is:
if expression:
statement
elif expression:
statement
else:
statement
And assignments are not allowed in expressions.
Thus, code that I wanted to write in Python like this, is illegal:
while match = tagOrTextRegexp.search(html, pos):
pos = match.end()
gd = match.groupdict()
if (val = gd.get('startTag')):
attrs = parseAttrs(gd['allAttrs'])
self.handleStartTag(val.lower(), attrs)
elif (val = gd.get('endTag')):
self.handleEndTag(val.lower())
elif (val = gd.get('text')):
self.handleNonTagText(val)
elif (val = gd.get('comment')):
pass # ARTHUR (to KNIGHTS) Walk away. Just ignore them.
else:
assert 0, "unexpected match in regexp - supposed to be impossible"
...ended up being written like this:
while True:
match = tagOrTextRegexp.search(html, pos)
if match is None:
break
pos = match.end()
gd = match.groupdict()
# no assignment-in-conditional sux, Guido
val = gd.get('startTag')
if val is not None:
attrs = parseAttrs(gd['allAttrs'])
self.handleStartTag(val.lower(), attrs)
else:
val = gd.get('endTag')
if val is not None:
self.handleEndTag(val.lower())
else:
val = gd.get('text')
if val is not None:
self.handleNonTagText(val)
else:
val = gd.get('comment')
if val is not None:
pass # ARTHUR (to KNIGHTS) Walk away. Just ignore them.
else:
assert 0, "unexpected match in regexp - supposed to be impossible"
I found this sort of thing very annoying, as can be seen from the note
I left in the code for Guido (von Rossum, Creator of Python.) <grin>
Another example would be class methods. (As opposed to instance methods.)
I remember how hacky and inelegant it seemed to me that every instance
method in Python needed to explicitly list the 'self' parameter:
class Foo:
def bar(self):
print "bar!"
f = Foo()
f.bar
But when I was learning Python, I had an insight and thought, well, at least
I know how to define class methods! Just leave off the self parameter!
class Foo:
def a_class_method(x,y)
return x+y
Then I should be able to call it directly on the class, with no instance passed
in:
Foo.a_class_method(1,2)
Nope. Just doesn't work. No way to define class methods. (Dunno if this
has changed in the past six years or not.)
Anyway, I don't recall many other examples anymore, but I vividly remember
feeling frustrated in this manner often enough while learning Python that I
would actually exclaim, "Guido!!!!" out loud at my desk when it would
happen. (But I should point out that I was still having fun. After all, I enjoyed
programming in Python _a lot_ more than Java.)
Finally, I suppose this is a bit silly, but my very first few minutes with
Python gave me a tangible feeling of trepidation when the following
happened:
I fired up Python (whatever the version was back then), and I got an
interactive interpreter. I was like, yay! cool!
Python 2.4.1 (#1, May 27 2005, 18:02:40)
Type "help", "copyright", "credits" or "license" for more information.
Then I tried to quit:
And I thought... Oh no. Somebody actually knew exactly what I
wanted the computer to do - and actually went through the trouble
to program a message to tell me I was doing it wrong.
But again, while these are aspects of Python that rubbed me the
wrong way, I realize that others may and do feel completely
differently. If Ruby didn't exist, I'd have probably have used
Python for quite a while (maybe moving on to OCaml or Erlang
by now, I dunno.)
And why did you stop using Forth? Is there *really* a way to break the
addiction?
Hehe.
I would totally still use Forth for embedded systems programming.
How else could one get an entire dynamic interactive extensible image-
based language with its own compiler and interpreter and editor and
assembler into a few KBytes of memory.
What occurred to me over the years, though, was what really made
Forth so remarkable was its achievement of providing such a dynamic
environment out of such utter sheer simplicity of code and memory
architecture.
There's a lot of beauty in an entire interactive compiler / interpreter
system with a main loop that looks like:
: QUIT ( -- ) BEGIN RESET QUERY INTERPRET AGAIN ;
And of course RESET, QUERY, and INTERPRET are quite simple
themselves. And it's like, Wow! All this dynamicity from such a
beautifully simple architecture!
But as computers got bigger and bigger memories and faster
CPU's, hard drives, file systems, operating systems... I started
to want features that would add complexity to the Forth system,
such as heap-based memory allocation, hashed headers to compile
faster (now that my system included thousands and thousands
of words for interfacing with the operating system), etc...
And eventually Forth wasn't so simple anymore.
And I think Forth's simplicity is part of its appeal... so I started to
hit a wall.
I'll admit I've sometimes wondered what a Forth system would be
like, though, if one took Ruby's VALUE type and made everything
on the data stack something akin to a ruby VALUE. So that
elements on the data stack would become actual objects with
an associated type... and ... well anyway... I guess it would be
sort of a cross between Ruby and Forth. <grin>
But anyway... now I have to get back to some C++ code. (But
tomorrow back to getting paid to code Ruby! Yay!)
Regards,
Bill
R
Robert Dober
You were also graceless before you met her, right? Sorry for playing
such stupid games <blush>.
Robert
W
William James
Bill Kelly wrote:
[...]
With apologies to Stephen Crane.
Code as I Code
"Code as I code," said Guido,
"Or you are abominably wicked;
"You are a toad."
And after I had thought of it,
I said: "I will, then, be a toad."
[...]
With apologies to Stephen Crane.
Code as I Code
"Code as I code," said Guido,
"Or you are abominably wicked;
"You are a toad."
And after I had thought of it,
I said: "I will, then, be a toad."
S
Shai Rosenfeld
Bill said:
^
|
|
|
(( very true ))
M
Michal Suchanek
Quack! Quack!
(or whatever English toads say .. did you notice that animals that
cross a border often start doing quite different sounds?
)Thanks
Michal
R
Ron Fox
I'm new to this newsgroup, having come here from many years with
another scripting language (Tcl/Tk; in fact in about 2hrs I'll be on my
way to New Orleans for Tcl 2007). I'm going to spout a slightly
different belief than most of the respondents.
There are cases where speed is almost completely irrelevant.
What is important is completion of a functioning application that
satisfies the customer (internal or external). For many many
applications this can be done, on modern computers without any
attention to the speed of the application. If my program takes
100ms to execute and yours takes 1usec, I contend that most users
will not notice, or care about the difference.
I also contend that while there >are< cases where performance is
important (much of my work is doing soft real-time data taking systems
for a national nuclear physics research lab... performance for the
data taking parts of those systems is critical), for a great deal of
software it is not. For responsiveness to a GUI element, you can pretty
well work in the 100-500ms range of performance...for all but
graphically intensive games where you have to get down to about 16ms.
Whatever language works in that performance range for your application
is suitable.
So what I would say is rather closed minded is the statement:
If that's true, start learning assembly. That's going to give you the
absolute best performance...for a specific machine. And that points to
the real issues. For me, choosing a programming language is
a set of engineering compromises. The compromises are usually a result
of the dynamic tension between the need to hit specific performance
goals, the portability of software written in the language, the
expressive power of the language in the problem domain in which I'm
working, and the availability of mature, low defect libraries in the
problem domain in which I'm working. What drove me to Ruby, for
example, is a new project to do laboratory administrative data
processing that requires us to show a specification of the underlying
business process and demonstrate that the code faithfully executes it,
and the existence of John Metraux's OpenWfeRu and the densha example of
how to host it on rails, as a tool to solve this problem....and about
2-3 weeks evaluating this tool for suitability as a partial solution to
this problem.
I _am_ programming language agnostic. As such I write and have written
in Assembler, Forth, Fortran, C, C++, Tcl/Tk, Ruby, Perl, Python,
Pascal.. I've even developed application specific languages and then
used them. None of these languages is a silver bullet. Each has
advantages and disadvantages, and the wise programmer will weigh them
carefully when selecting which ones to use to solve any given problem.
Ron Fox
National Superconducting Cyclotron Lab
Michigan State University
East Lansing, MI 48824-1321
another scripting language (Tcl/Tk; in fact in about 2hrs I'll be on my
way to New Orleans for Tcl 2007). I'm going to spout a slightly
different belief than most of the respondents.
There are cases where speed is almost completely irrelevant.
What is important is completion of a functioning application that
satisfies the customer (internal or external). For many many
applications this can be done, on modern computers without any
attention to the speed of the application. If my program takes
100ms to execute and yours takes 1usec, I contend that most users
will not notice, or care about the difference.
I also contend that while there >are< cases where performance is
important (much of my work is doing soft real-time data taking systems
for a national nuclear physics research lab... performance for the
data taking parts of those systems is critical), for a great deal of
software it is not. For responsiveness to a GUI element, you can pretty
well work in the 100-500ms range of performance...for all but
graphically intensive games where you have to get down to about 16ms.
Whatever language works in that performance range for your application
is suitable.
So what I would say is rather closed minded is the statement:
If that's true, start learning assembly. That's going to give you the
absolute best performance...for a specific machine. And that points to
the real issues. For me, choosing a programming language is
a set of engineering compromises. The compromises are usually a result
of the dynamic tension between the need to hit specific performance
goals, the portability of software written in the language, the
expressive power of the language in the problem domain in which I'm
working, and the availability of mature, low defect libraries in the
problem domain in which I'm working. What drove me to Ruby, for
example, is a new project to do laboratory administrative data
processing that requires us to show a specification of the underlying
business process and demonstrate that the code faithfully executes it,
and the existence of John Metraux's OpenWfeRu and the densha example of
how to host it on rails, as a tool to solve this problem....and about
2-3 weeks evaluating this tool for suitability as a partial solution to
this problem.
I _am_ programming language agnostic. As such I write and have written
in Assembler, Forth, Fortran, C, C++, Tcl/Tk, Ruby, Perl, Python,
Pascal.. I've even developed application specific languages and then
used them. None of these languages is a silver bullet. Each has
advantages and disadvantages, and the wise programmer will weigh them
carefully when selecting which ones to use to solve any given problem.
Ron Fox
National Superconducting Cyclotron Lab
Michigan State University
East Lansing, MI 48824-1321
J
John Mettraux
Hi Ron,
my name is "Mettraux".
Thanks again for your contributions to OpenWFEru. And thanks for the ad here.
Best regards,
S
Shai Rosenfeld
Ron said:
there we go.
Y
Yossef Mendelssohn
And why did you stop using Forth? Is there *really* a way to break the
addiction?
It sounds like the question you're trying to ask is "*How* did you
stop using Forth?"
HTH HAND
B
brad
I use and enjoy both. They are different, and alike at the same time. I
wish the best of both could be squashed together into a new language
wish the best of both could be squashed together into a new language
W
William James
Michal said:Quack! Quack!
(or whatever English toads say .. did you notice that animals that
cross a border often start doing quite different sounds?
Thanks
Michal
I think they would say, "Croak! Croak!" (At least, I always do.)
It's English-speaking ducks that say "Quack!"
J
julik
You sure do seem to know a lot about trolls.
Seriously, though, any move that falls outside the troll's script is a
valid move. Not playing at all works, but rarely, since not everyone
follows that advice.
According to some (albeit minor) Google pointers we might be dealing
with another Ilias Lazaridis here, so folks be alert!
R
Robert Dober
Shall I know that gentlemen
, could you explore a little bit pls?Robert
C
Chad Perrin
I use and enjoy both. They are different, and alike at the same time. I
wish the best of both could be squashed together into a new language
I think you accidentally left an additional attribution on that quote.
C
Chad Perrin
Nah . . . I wasn't Graceless then. I was just "yet to be Graced".
P
Phrogz
Then you need to head outside to some swampy areas in the Northeast of
the U.S. in the springtime. The toads, they be loud.
M
M. Edward (Ed) Borasky
Phrogz said:
I've lived near swamps ... I guess the frogs I heard were really toads??
G
Giles Bowkett
Seriously, though, any move that falls outside the troll's script is a
Patagonian death gerbils!
(Are we playing Discordian Mornington Crescent? Best kind.)
--
Giles Bowkett
Blog: http://gilesbowkett.blogspot.com
Portfolio: http://www.gilesgoatboy.org
Tumblelog: http://giles.tumblr.com/
Patagonian death gerbils!
(Are we playing Discordian Mornington Crescent? Best kind.)
--
Giles Bowkett
Blog: http://gilesbowkett.blogspot.com
Portfolio: http://www.gilesgoatboy.org
Tumblelog: http://giles.tumblr.com/
R
Robert Dober
I just realized, this is not my cow, er universe.
Robert