Moin,
short question: is there any language combining the syntax, flexibility and
great programming experience of Python with static typing? Is there a
project to add static typing to Python?
Thank you,
--
greetz tom
Jul 18 '05
176  7971 
>>>>> "Jacek" == Jacek Generowicz <ja**************@cern.ch> writes: Smalltalk (50 projects)
Forth (55 projects)
Scheme (181 projects)
....
Jacek> Let's do this exercise again when Java reaches the age of
Jacek> Lisp. My prediction is that Lisp will still be there, while
Jacek> Java, C++ and C# will not. I rate Smalltalk's chances of
Jacek> still being there at that time
Java is the Cobol of modern times, so I believe Java will be around
(in the same despised legacy role as Cobol now).
Jacek> What they will need in the future, depends on what they
Jacek> choose to do in the future. If they want to be Java
Jacek> monkeys, then they should not bother with Scheme. If they
Jacek> want to be highly skilled programmers, then Scheme is a
Jacek> vastly superior choice to Java (and even Python).
So you think this one course will determine the future of the
students' careers? You sure exhibit a strong confidence in
education. I tend to believe that "highly skilled programmers" are
born with a certain mindset, and there is only so much school can do.
If the school churns out a succesful Java monkey with good grasp of
software architecture, project management issues etc. the school
should be considered to have succeeded in its mission. Java monkeys
pay the taxes, which support the universities.
After Programming I course (in Scheme), I still felt that I was
a better C/C++ programmer than Scheme programmer. If the same
time was spent learning Python, my Python skills would quite
probably have exceeded my C/C++ skills
Jacek> That may be. But the chances are that you were a better
Jacek> _programmer_ than you would otherwise have been. (But this
I don't think so. In fact I only grasped what is so great about Lisp
much much later. The course was a worthless distraction, which would
not have been so worthless if it was in Python.
and I would still have achieved all the "pedagogical" aims of the
course
Jacek> I doubt it. But that's just my opinion. And it all depends
Jacek> on the sort of person/programmer you are.
The only thing I learned was doing functional programming, handy ways
to use recursion etc (using set! was forbidden in the excercises). I
could have learned the same things with Python. And I don't think I
"missed" anything, got perfect score and generally considered the
course trivial.
Jacek> types of people emerging: those who will become Java
Jacek> monkeys, and those who will become skilled programmers. If
Jacek> you fall into the latter category, then teaching you in
Jacek> Python rather than Scheme would have been a great service
Jacek> to you; if you fall into the former category then it would
Jacek> probably have been a great disservice to you.
Here I disagree. Most students *will* become Java monkeys, project
managers or whatever. Doing a service for them is a sensible thing to
do, statistically. Not teaching something to would-be skilled
programmers is not a major disservice, because they probably know more
/ as much as their lecturers anyway.
Sometimes it seems as if academics are trying to make programming
appear more theoretical or difficult than it actually is. Programming
is a thing that a child can learn, which might be slightly
embarrassing to some professors...
--
Ville Vainio http://tinyurl.com/2prnb
[Michele Simionato] Yes, indeed having iterators and generators built-in in the language
(as well as an exception system) exhaust most of the use case for
continuation so you don't really feel the need for them in Python in
normal circumstances.
I recently worked on my little `pynits' tool (hoping to release it a
third time, as soon as I'm satisfied enough with the changes), and have
a need for continuations there. The circumstances for that need may be
slightly unusual, but I would surely not qualify them as abnormal :-).
Suddenly backtracking out of a complex involvement for restarting in a
new direction, for the above project at least, requires a lot of state
resumption, and doing this cleanly in Python implies a rather strict and
burdening discipline about where and how the state information is kept.
While tractable, this is not as comfortable as I would have liked it...
Maybe I'll find better ways if I let the problem mature enough? :-)
--
François Pinard http://www.iro.umontreal.ca/~pinard
François Pinard <pi****@iro.umontreal.ca> wrote in message news:<ma************************************@pytho n.org>... [Ville Vainio] >> (No, I'm not implying that Lisp is not being used for real [as
>> in non-academic] work. It is, Scheme isn't).
Francois> I surely used Scheme for real contracts, [...]
Really, when was this?
In my case, this was a few years ago, I never precisely remember dates.
I know other people who do Scheme works for a living in these days. I
would feel a bit uncomfortable in their context, because this is all
too much commercial for my own desires, and am not so money-oriented to
fully dedicate myself in these projects that have no free aspects.
There is a kind of strange constant in what people tell me however.
Scheme seems to be often used "under the cover", in that people deliver
stand-alone solutions in which the real engine is not revealed, a bit
like if Scheme was not far from being an industrial secret. :-)
It remembers me a friend of mine telling me a few months ago something
like
this: "Python or even Smalltalk are more used in the real world than
you expect, especially in the smartest firms, but they don't tell you
since they regard
it as a technological advantage".
Michele Simionato
>>>>> "Francois" == François Pinard <pi****@iro.umontreal.ca> writes:
Francois> Suddenly backtracking out of a complex involvement for
Francois> restarting in a new direction, for the above project at
Francois> least, requires a lot of state resumption, and doing
Francois> this cleanly in Python implies a rather strict and
Francois> burdening discipline about where and how the state
Francois> information is kept.
Would such a problem be solvable if you could pickle a "running"
generator? In fact, why is it not possible to pickle a generator that
is hygienic enough to not mutate nonlocal objects?
def mkgen():
x = 1
while 1:
x += 1
yield x
g = mkgen()
g.next()
g.next()
# x is 3 in generator
pickle.dump(g, open("a.tmp","w'))
g.next()
g.next()
g2 = pickle.load(open("a.tmp"))
g2.next() # yields 4
Is this what you were trying to achieve with continuations? I don't
really have an intuitive grasp of the continuation idea, it seems
messy compared to generators, so I'm trying to learn here...
Mutating nonlocals (in the gtor, or between pickling and unpickling)
would obviously hose this construct, but many generators should avoid
it in the first place. Referenced global objects would still be
referenced normally (because it happens on source code level), the
behaviour would just not be that of "saved state"...
So, is there some deep philosophical (as opposed to implementation
detail) flaw in the picklable generator idea?
--
Ville Vainio http://tinyurl.com/2prnb
On Wed, 7 Jul 2004, [iso-8859-1] François Pinard wrote: I recently worked on my little `pynits' tool (hoping to release it a
third time, as soon as I'm satisfied enough with the changes), and have
a need for continuations there. The circumstances for that need may be
slightly unusual, but I would surely not qualify them as abnormal :-).
Suddenly backtracking out of a complex involvement for restarting in a
new direction, for the above project at least, requires a lot of state
resumption, and doing this cleanly in Python implies a rather strict and
burdening discipline about where and how the state information is kept.
While tractable, this is not as comfortable as I would have liked it...
It may be possible to do what you want to do using only generators.
Assuming that you have some N-deep nested structure, you could do
something like this:
def dootherstuff():
<do some stuff>
if <exceptional condition>:
yield <some helpful value>
<do more stuff>
def dostuff():
<do some stuff>
for value in dootherstuff(): # call dootherstuff(), propogating yields
yield value
<do more stuff>
if <exceptional condition>:
yield <some helpful value>
<finish doing stuff>
for value in dostuff():
<handle exceptional condition described by value>
Alternatively, you could replace the for loops with something like:
continuation=dostuff()
try:
value=continuation.next()
except StopIteration:
<store continuation away for future use>
else:
<function completed, carry on>
Dunno if this helps or not....
On 07 Jul 2004 16:45:37 +0200, Jacek Generowicz
<ja**************@cern.ch> wrote: Another thing is whether it pays off for future students to learn a
language that they won't need after that one course,
What they will need in the future, depends on what they choose to do
in the future. If they want to be Java monkeys, then they should not
bother with Scheme. If they want to be highly skilled programmers,
then Scheme is a vastly superior choice to Java (and even Python).
unless they choose to stay in school & join academia. Some might
say that the time would be better spent by teaching Python instead.
Some might say that the time would be better spent teaching
accountancy. It all depends on what you want out of life.
Perhaps it would.
From the point of view of an outsider to the world of professional
programming:
We judge a programming language with respect to its use in the "real
world", with Python and Lisp and Scheme lovers feeling obliged to
point to their languages use in the real world. Real world seeming to
mean - more or less - the business world. By employing the highly
skilled programmer, equipped with the just right tool (be it Python or
Scheme or Lisp or whatever) someone is finding competitive advantage,
and thereby making more than ordinary profits, perhaps building an
empire or two.
But it is quite unlikely that someone is the programmer. Who brings
born aptitudes, years of study and experience, etc, to the table, and
is probably in and out on a contract basis, having earning subsistance
for a bit of time, perhaps, in fact, by accomplishing something of
brilliance.
In the realms where I have my experience, nobody would be boasting of
being that programmer.
Art
[Full-quoted and top-posted]
Mr. Hickman has provided an excellent summary of the author's results.
In article <40**********************@news.easynet.co.uk> (Wed, 07 Jul 2004
10:53:20 +0100), Peter Hickman wrote: The use of Lisp allowed the original developers of the Yahoo stores to
extend the functionality of the sites faster than their competitors and,
when a competitor can up with a novel idea, do some easy feature
matching.
The developers attributed their success to speed of development and said
that it was Lisp that allowed them develop things so quickly. They also
said that they only ever got nervous when they heard that a competitor
was looking to develop in Python.
Did they have a better design, a better architecture?
They never seemed to indicate that their architecture was anything
special or that their competitors' was especially bad. Just that they
could develop good code faster than their competitors.
What did Yahoo!-Store prove?
That large, robust production systems could be developed in a dynamic
language without being dragged down by poor performance. This went
against the current ethos that said that dynamic languages were only any
good for prototypes but you would have to convert to a real language (C,
C++ or Java) because dynamic languages would not scale.
In article <du*************@mozart.cc.tut.fi> (Wed, 07 Jul 2004 15:08:41
+0300), Ville Vainio wrote: Mostly by students, media and "the guys at the internet" ;-). Students
often have some idea of what local companies use at least,
though. ISTR the lecturer didn't disagree either.
The majority of university students fail to recognize they're in school
for an education; if they wanted job training, they should attend a
technical training institute. Here is a quote from a student in 1980:
"FORTRAN is a dead language."
Is FORTRAN dead? No.
Do I want to write more FORTRAN code? No.
Is Python the bestest language ever? No.
Do I want to write more Python code? Sure.
One indicator of the health of the language is the status in the Open
Source community.
A language's "status in the Open Source community [sic]" is indicative
almost solely of the language's popularity among a self-selected group of
programmers. The "health" of language is better measured by its utility
for a specific task.
It's more democratic than the status in the academia
(where one zealous professor can have huge influence).
This putative "democracy" is immaterial.
After Programming I course (in Scheme), I still felt that I was a
better C/C++ programmer than Scheme programmer.
Perhaps you were. C and C++ are quite important commercially but quite
unimportant in the theory the might introduce.
I'll say that let them teach Python in the introductory course, and
let the students that have the craving learn Scheme in their own
time. More people would learn more things, and have more fun.
The concepts in Scheme matter a great deal in computer science. Those that
are "craving ... fun" may do it on their own time. What you're describing
is the de-evolution of education into job training.
Hamilcar Barca wrote: ...I'll say that let them teach Python in the introductory course, and
let the students that have the craving learn Scheme in their own
time. More people would learn more things, and have more fun.
The concepts in Scheme matter a great deal in computer science. Those that
are "craving ... fun" may do it on their own time.
Why not have fun while learning computer science? Scheme is just a
programming language. It is not in and of itself a revelation of the
deepest concepts of computer science. Python supports recursion, second
order functions, numerical programming and hundreds of other important
concepts. In my mind, Scheme actually lacks important stuff like the
idea that types can be created (not simulated, but CREATED) by
programmers and not just language designers. It also lacks various other
OOP concepts (in its standard form).
Paul Prescod
Arthur wrote: ...
We judge a programming language with respect to its use in the "real
world", with Python and Lisp and Scheme lovers feeling obliged to
point to their languages use in the real world. Real world seeming to
mean - more or less - the business world. By employing the highly
skilled programmer, equipped with the just right tool (be it Python or
Scheme or Lisp or whatever) someone is finding competitive advantage,
and thereby making more than ordinary profits, perhaps building an
empire or two.
But it is quite unlikely that someone is the programmer.Who brings
born aptitudes, years of study and experience, etc, to the table, and
is probably in and out on a contract basis, having earning subsistance
for a bit of time, perhaps, in fact, by accomplishing something of
brilliance.
At the Vancouver Python Workshop there will be a talk from a guy who was
the co-foudner and first programmer at a company. The company was built
around his Python code (and presumably the business acumen of the other
guy) and now (around 5 years later) has 80 employees and is expanding so
quickly that they can't handle all of the requests pounding on the door.
He says: "he doesn't see how he could have done it without Python." Greg
Stein says the same of eShop. Paul Graham of YahooStore. They could all
be wrong but I think that there is an interesting phenomenon there...
I rather expect that as cofounder of a company that did so well so
quickly, he's earning more than substinence these days...it can happen.
Paul Prescod
Peter Hickman wrote: ...
They never seemed to indicate that their architecture was anything
special or that their competitors' was especially bad. Just that they
could develop good code faster than their competitors.
Elsewhere they do claim architectural advantage: http://www.paulgraham.com/lwba.html
"One way we used macros was to generate Html. There is a very
natural fit between macros and Html, because Html is a prefix
notation like Lisp, and Html is recursive like Lisp. So we had
macro calls within macro calls, generating the most complicated
Html, and it was all still very manageable."
"Users could write their own Rtml templates to describe what they
wanted their pages to look like. We had a structure editor for
manipulating these templates, a lot like the structure editor they
had in Interlisp. Instead of typing free-form text, you cut and
pasted bits of code together. This meant that it was impossible
to get syntax errors. It also meant that we didn't have to display
the parentheses in the underlying s-expressions: we could show
structure by indentation. By this means we made the language look
a lot less threatening."
"We could write the code to say, if the user clicks
on this link, go to the color selection page, and then come back
here. This was just one of the places were we took advantage of
this possibility. It made our software visibly more sophisticated
than that of our competitors."
Paul Prescod
Ville Vainio <vi***@spammers.com> writes: The only thing I learned was doing functional programming, handy ways
to use recursion etc (using set! was forbidden in the excercises). I
could have learned the same things with Python. And I don't think I
"missed" anything, got perfect score and generally considered the
course trivial.
Well, there's always the possibility that the course was crap. This is
not unusual, as I've suggested before.
Paul Prescod: ... It also meant that we didn't have to display
the parentheses in the underlying s-expressions: we could show
structure by indentation. By this means we made the language look
a lot less threatening."
Every sufficiently advanced LISP application will eventually reimplement
Python.
Neil
Ville Vainio <vi***@spammers.com> wrote in message news:<du*************@mozart.cc.tut.fi>...
Frankly, there is no real reason to learn Scheme.
I have to beg to differ. I am using Bigloo (Scheme) for 3 years now
for pursuing my research PhD in physics (atmospheric physics and
chemistry).
Believe it or not: I had to translate all my former Python programs to
Bigloo because I was at the point where I was not any longer happy
with Python. Numarray was such a big mess (yes I have some experience
with similar things: IDL, Matlab and especially Yorick) and Python is
simply to depressing.
Bigloo gives me all that what I need and what makes me happy. So
saying Scheme is as worthless experience calls for troubles.
What makes me happy:
- I can give types and that /tremendously/ improves readability and
catches type erros but at the same time I am /always/ using all the
freedom of Scheme programming.
- Bigloo has pattern matching
- Object orientied programming (one can even create new types)
- Foreign function interface is very sound and very easy to use (no
need of SWIG)
- Bee development environment
- I do not use the following but they are there: Java backends
(automatically produced from Scheme code) and .NET integration
- And yes: the compiler: ./a.out
- I use it on: Mac OSX, Sun OS (I am steering, post- and preprocessing
there Fortran code with the help of Bigloo), and Linux.
- And much, much more
- disadvantages: every Scheme implemenation is a unique
implementation. However, Python is also a unique implementation ...
Bigloo is very sound and I wouldn't mind to use it in any production
code in any of my "imaginative" companies.
Scheme works so well out for me, though, my knowledge of Scheme is
very shallow but it makes me happy to program in (as opposed to
Python).
Fensterbrett
In article <ma************************************@python.org > (Wed, 07
Jul 2004 23:13:49 -0700), Paul Prescod wrote: Hamilcar Barca wrote:
The concepts in Scheme matter a great deal in computer science. Those
that are "craving ... fun" may do it on their own time.
Why not have fun while learning computer science?
That would be good.
Scheme is just a programming language. It is not in and of itself a
revelation of the deepest concepts of computer science.
I agree here, too.
If I had to learn a new language now, and I got to choose, I'd learn
Scheme. Unfortunately, I do have to learn a new language now, and I get
to choose any two of the languages in the set of Java and Scala. I would
have liked Java before I learned Python.
You don't seem to have taken it this way, but I don't intend to bash
Python. It's still my opinion that Scheme is a better language,
theoretically and for instruction on principles (now known as "paradigms",
than Python. If I had to choose, between LISP (which I know) and Python,
for a "real" project, I'd choose Python.
Python supports recursion, second order functions, numerical programming
and hundreds of other important concepts.
How about currying and deferred list evaluation?
In my mind, Scheme actually lacks important stuff like the idea that
types can be created (not simulated, but CREATED) by programmers and not
just language designers.
I think your mind is correct. This lack is deliberate and even CLOS seems
to support concrete data types better than ADTs.
It also lacks various other OOP concepts (in its standard form).
In my limited experience, it's complete lacking in OO. There are many who
argue that functional programming is "better" than OOP, where
(setq better 'opinion)
Is this a good place to insert my "Smalltalk is the only language good
enough for teaching people to program" rant?
>>>>> "Hamilcar" == Hamilcar Barca <ha******@tld.always.invalid> writes: Python supports recursion, second order functions, numerical
programming and hundreds of other important concepts.
Hamilcar> How about currying and deferred list evaluation?
Deferred list evaluation: generators
Lazy evaluation in general: lambda : f(1,2)
Currying: lambda x,y : f(x,y,1,2)
Hamilcar> Is this a good place to insert my "Smalltalk is the only
Hamilcar> language good enough for teaching people to program"
Hamilcar> rant?
What's better about Smalltalk compared to Python, educationally? Just
a brief list will do.
--
Ville Vainio http://tinyurl.com/2prnb
> Currying: lambda x,y : f(x,y,1,2)
lambda x: lambda y: f(x,y,1,2)?
but then
(lambda x: lambda y: f(x,y,1,2))(3, 4)
won't work.
so much for currying?
k
>>>>> "chain" == chain lube <ch********@hotmail.com> writes:
chain> Ville Vainio <vi***@spammers.com> wrote in message news:<du*************@mozart.cc.tut.fi>...
Frankly, there is no real reason to learn Scheme.
chain> Believe it or not: I had to translate all my former Python
chain> programs to Bigloo because I was at the point where I was
chain> not any longer happy with Python. Numarray was such a big
chain> mess (yes I have some experience with similar things: IDL,
Considered complaining to Numarray people instead of interpreting it
as a flaw in Python? Sometimes even filing a bug report might help.
chain> Matlab and especially Yorick) and Python is simply to
chain> depressing.
Could you show us a code example about what depresses you? Consider
this a good chance at advocacy, concrete examples always work. I was
sold to Python when I saw how easy doing CORBA is.
chain> - I can give types and that /tremendously/ improves
chain> readability and catches type erros but at the same time I
chain> am /always/ using all the freedom of Scheme programming.
Is Bigloo statically typed? If it isn't, you can equally well assert
the argument types in python functions.
chain> - Bigloo has pattern matching
Very much doable in Python. Pattern matching is rarely needed, though
- a couple of if-elif's will typically do fine (because that's what
pattern matching essentially is).
if tuple_types_are(argtuple, (int,[str], (int,int)):
pass
chain> - Object orientied programming (one can even create new
chain> types)
Folks here say Python kinda supports OOP too.
chain> Scheme works so well out for me, though, my knowledge of
chain> Scheme is very shallow but it makes me happy to program in
chain> (as opposed to Python).
Again, why? List some reasons, and we'll see if there is something
that would help you in e.g. ASPN Python cookbook.
Of course if Python "depresses" you, there might be some deeper
personality incompatibilities issues between you and the
language. Python tends to make me happy, esp. when I'm doing list
comprehensions :-).
--
Ville Vainio http://tinyurl.com/2prnb
Ville Vainio <vi***@spammers.com> writes: >> "chain" == chain lube <ch********@hotmail.com> writes:
chain> Ville Vainio <vi***@spammers.com> wrote in message news:<du*************@mozart.cc.tut.fi>... >>
>> Frankly, there is no real reason to learn Scheme.
chain> Believe it or not: I had to translate all my former Python
chain> programs to Bigloo because I was at the point where I was
chain> not any longer happy with Python. Numarray was such a big
chain> mess (yes I have some experience with similar things: IDL,
Considered complaining to Numarray people instead of interpreting it
as a flaw in Python? Sometimes even filing a bug report might help.
Though using a language in which the stuff you need already works the
way you want it, might help more.
chain> - I can give types and that /tremendously/ improves
chain> readability and catches type erros but at the same time I
chain> am /always/ using all the freedom of Scheme programming.
Is Bigloo statically typed? If it isn't, you can equally well assert
the argument types in python functions.
You are completely missing the point.
Specifying the type in Bigloo will make the code run more quickly,
while asserting the type in Python will make the code run more slowly.
chain> - Bigloo has pattern matching
Very much doable in Python. Pattern matching is rarely needed,
Chicken and egg. The Blub Paradox. etc. etc. ...
Python provides no built-in support for pattern matching, therefore
your average happy Pythoneer will not be familiar with pattern
matching, the point of pattern matching, the benefits of pattern
matching, or the situations in which pattern matching is a big win. If
they ever do try to do pattern matching, it will probably be via some
clunky home-grown implementation, which will not exhibit pattern
matching in its best light. Therefore, they are likely to conclude
that there is no use for pattern matching ...
though - a couple of if-elif's will typically do fine (because
that's what pattern matching essentially is).
.... yup, you prove my point exactly.
My point is, of course, not specific to Python or to pattern matching;
you can replace them with any language, and any feature missing from
that language.
>>>>> "Jacek" == Jacek Generowicz <ja**************@cern.ch> writes: Considered complaining to Numarray people instead of
interpreting it as a flaw in Python? Sometimes even filing a
bug report might help.
Jacek> Though using a language in which the stuff you need already
Jacek> works the way you want it, might help more.
It's throwing baby out with the bathwater. If something is amiss in a
library, you typically don't switch the whole language (at least in
industrial/corporate setting). You would need to switch languages
every other day. Well, I've seen worse - some people actually
*implement* new languages because e.g. Python has no library that does
<fill_in>.
Is Bigloo statically typed? If it isn't, you can equally well assert
the argument types in python functions.
Jacek> You are completely missing the point.
Jacek> Specifying the type in Bigloo will make the code run more
Jacek> quickly, while asserting the type in Python will make the
Jacek> code run more slowly.
So performance was the problem? The OP should have said so, perhaps
posted some benchmarks.
Jacek> Python provides no built-in support for pattern matching,
Jacek> therefore your average happy Pythoneer will not be familiar
Jacek> with pattern matching, the point of pattern matching, the
Jacek> benefits of pattern matching, or the situations in which
Jacek> pattern matching is a big win. If
Ok, give an example where built-in pattern matching (i.e. something
not doable with a library) would be a big win.
though - a couple of if-elif's will typically do fine (because
that's what pattern matching essentially is).
Jacek> ... yup, you prove my point exactly.
Last time I checked, pattern matching essentially *is* about
1. Finding the pattern that matches the valuable of a variable
2. Unpacking the found value to a tuple.
So please try to avoid speaking in the abstract and give something
concrete.
--
Ville Vainio http://tinyurl.com/2prnb
Hamilcar Barca <ha******@tld.always.invalid> wrote in message news:<20*******************@news.newsreader.com>.. . The majority of university students fail to recognize they're in school
for an education; if they wanted job training, they should attend a
technical training institute. Here is a quote from a student in 1980:
"FORTRAN is a dead language."
Is FORTRAN dead? No.
Do I want to write more FORTRAN code? No.
Is Python the bestest language ever? No.
Do I want to write more Python code? Sure.
One should not judge a programming language based on outdated
information.
Fortran (not spelled with all caps since the 1990 standard) continues
to evolve. The 1990 standard added array functionality, modules (in
Fortran, 'use foo, only: boo' is equivalent to 'from foo import boo'
in Python) similar to that of Numeric or Numarray, the 1995 standard
added features for parallel programming such as pure and elemental
functions (similar to Python ufunc's), and the 2003 standard added OOP
with inheritance and interoperability with C.
There is a free Fortran 95 compiler for x86 Linux and Free BSD and Mac
OS X at http://www.g95.org .
>>>>> "Jakub" == Jakub Fast <kf***@poczta.onet.pl> writes: Currying: lambda x,y : f(x,y,1,2)
Jakub> lambda x: lambda y: f(x,y,1,2)?
Jakub> but then
Jakub> (lambda x: lambda y: f(x,y,1,2))(3, 4)
Jakub> won't work.
Of course it won't. It's the difference b/w taking 1 and 2 parameters.
(lambda x: lambda y: f(x,y,1,2))(3)(4)
will work.
I guess you will see that e.g in haskell
f 1 2
does exactly this:
((f 1) 2 )
Jakub> so much for currying?
Well, no.
--
Ville Vainio http://tinyurl.com/2prnb
Ville Vainio <vi***@spammers.com> writes: >> "Jakub" == Jakub Fast <kf***@poczta.onet.pl> writes: >> Currying: lambda x,y : f(x,y,1,2) Jakub> lambda x: lambda y: f(x,y,1,2)?
Jakub> but then
Jakub> (lambda x: lambda y: f(x,y,1,2))(3, 4)
Jakub> won't work.
Of course it won't. It's the difference b/w taking 1 and 2 parameters.
Which is pretty much the point of currying.
(lambda x: lambda y: f(x,y,1,2))(3)(4)
will work.
I guess you will see that e.g in haskell
f 1 2
does exactly this:
((f 1) 2 )
Jakub> so much for currying?
Well, no.
Well, yes.
In Haskell, both
f 1
and
f 1 2
will work, while in Python you have to install the plumbing yourself
every time.
You can write object-oriented programs in C ... but you have to
intstall the plumbing yourself every time. C supports object
orientation to about the same extent that Python supports currying.
You seem to be consistently implying (I just followed up another of
your posts, which implies similar sentiments) that built-in features
of other languages offer them no advantages over Python, because you
can simulate them all in Python. Why don't you take that line of
thought to its logical conclusion and program in a Turing Machine ?
Python offers no advantages over a Turing Machine, because you can
simulate all of Python's features in a Turing Machine.
Ville Vainio <vi***@spammers.com> writes: >> "Jacek" == Jacek Generowicz <ja**************@cern.ch> writes: >> Considered complaining to Numarray people instead of
>> interpreting it as a flaw in Python? Sometimes even filing a
>> bug report might help.
Jacek> Though using a language in which the stuff you need already
Jacek> works the way you want it, might help more.
It's throwing baby out with the bathwater. If something is amiss in a
library, you typically don't switch the whole language (at least in
industrial/corporate setting).
But if the language has many deficiencies (as the OP suggested it did,
form his POV), and another language does not have those deficiencies,
and no other show-stopping deficiencies ... but I think that you know
that this was the point, and are being deliberately obtuse.
You would need to switch languages every other day.
No, just find the best one for your project, and stick to it.
Well, I've seen worse - some people actually *implement* new
languages
.... like Python :-)
So performance was the problem? The OP should have said so,
I was under the impression that he had, but, upon checking, I see that
he did not.
perhaps posted some benchmarks.
Well, lemme see, Bigloo compiles down to native code, and, with type
specifications, can eliminate dynamic dispatching from your inner
loops. The concept is pretty clear. Do you really think that
benchmarks would in any way help to understand the _concept_ ... or
are you just being deliberately obtuse?
Jacek> Python provides no built-in support for pattern matching,
Jacek> therefore your average happy Pythoneer will not be familiar
Jacek> with pattern matching, the point of pattern matching, the
Jacek> benefits of pattern matching, or the situations in which
Jacek> pattern matching is a big win. If
Ok, give an example where built-in pattern matching (i.e. something
not doable with a library) would be a big win.
I am not a regular user of pattern matching, so I am probably not a
good person to champion it. This in no way takes away from my point
which is this:
Fans of programming language A typically believe that features of
language B, which are absent from A, are not very useful. This is
usually NOT because the features are not useful, but because the
person in question is ignorant of their advantages. Their ignorance
is typically borne of the absence of the feature from language A.
.... but I have a feeling that you already knew that.
>> though - a couple of if-elif's will typically do fine (because
>> that's what pattern matching essentially is).
Jacek> ... yup, you prove my point exactly.
Last time I checked, pattern matching essentially *is* about
1. Finding the pattern that matches the valuable of a variable
2. Unpacking the found value to a tuple.
And anything you can do in Python, you can do on a Turing Machine. Why
use Python, when a roll of infinite tape and a few cog wheels "will
typically do fine"?
.... but I have a feeling you already knew that.
[Ville Vainio] [Jacek Generowicz]
Jacek> Python provides no built-in support for pattern matching,
Jacek> therefore your average happy Pythoneer will not be familiar
Jacek> with pattern matching, the point of pattern matching, the
Jacek> benefits of pattern matching, or the situations in which
Jacek> pattern matching is a big win. If
Ok, give an example where built-in pattern matching (i.e. something
not doable with a library) would be a big win.
In one of my previous Scheme works, I needed pattern matching for
strings as well as for tree structures, and ended up implementing both.
Python has string pattern matching through the `re' library. It also
has a fairly limited structure pattern matching built-in, through tuple
unpacking, like in assignments or in function argument passing. The
trick is that tuple unpacking acts recursively (something I guess many
Pythoneers do not know, or at least, do not use). Another problem
with structure matching in Python is that a failed matching raises an
exception, something slow for applications heavy on pattern matching.
For very simple applications however, Python easily does as it stands.
though - a couple of if-elif's will typically do fine (because that's
what pattern matching essentially is).
Jacek> ... yup, you prove my point exactly.
And Jacek is right, once again. One should avoid being too judgemental,
especially when not much familiar with problems at stake. (Yet, I did
exactly this a few times, in the youth of my programmer life. It took a
while before I began to see how presumptuous I might have been at times
:-).) I know that some people trigger their own education by challenging
others, which is not that humble to start with, likely irritating to the
challenged people, and not looking very polite to the casual observers.
Last time I checked, pattern matching essentially *is* about [...]
Hopefully, life will give you the opportunity for many more checks! :-)
Pattern matching is by far not limited to strings, and whole areas of
technology are either dedicated or based on pattern matching.
--
François Pinard http://www.iro.umontreal.ca/~pinard
On Wed, 07 Jul 2004 23:13:49 -0700, Paul Prescod <pa**@prescod.net>
wrote: Why not have fun while learning computer science?
Yes please, fun.
I am somewhere between a CP4E-er and a "computer science" -er.
There is much to be done with programming, IMO, in the educuational
process that is something short of hard core computer science.
Practical programming as a tool for other learning and teaching
possiblities. But in areas that themselves tend to be tehnical and
demanding (mathematics and science, the most obvious), so the
association of these efforts with "technical" and "demanding" need not
be soft pedaled. It need not be "easy".
Scheme is just a
programming language. It is not in and of itself a revelation of the
deepest concepts of computer science. Python supports recursion, second
order functions, numerical programming and hundreds of other important
concepts. In my mind, Scheme actually lacks important stuff like the
idea that types can be created (not simulated, but CREATED) by
programmers and not just language designers. It also lacks various other
OOP concepts (in its standard form).
For the things I hoped to accomplish by learning to program - based on
available compatible libraries and tools - Java would have been a more
practical choice.
Not being in a position to talk to the issue of the "deepest concepts
of computer science", I would have no reason to reject Java for Python
(or Scheme).
But since my self directed efforts were not a required course, and not
designed as a career move, I did demand to be having some fun at it.
Which I think is more or less how I ended up at Python.
Hard to define why this is so. But the word "fun" is slung around the
Python community with abandon, and it is one word used within the
community that I have never found a basis to quibble with.
Art
Jacek Generowicz wrote: Ville Vainio <vi***@spammers.com> writes:
>>>"Jakub" == Jakub Fast <kf***@poczta.onet.pl> writes:
>> Currying: lambda x,y : f(x,y,1,2)
Jakub> lambda x: lambda y: f(x,y,1,2)?
Jakub> but then
Jakub> (lambda x: lambda y: f(x,y,1,2))(3, 4)
Jakub> won't work.
Of course it won't. It's the difference b/w taking 1 and 2 parameters.
Which is pretty much the point of currying.
(lambda x: lambda y: f(x,y,1,2))(3)(4)
will work.
I guess you will see that e.g in haskell
f 1 2
does exactly this:
((f 1) 2 )
Jakub> so much for currying?
Well, no.
Well, yes.
In Haskell, both
f 1
and
f 1 2
will work, while in Python you have to install the plumbing yourself
every time.
which is exactly what I meant.... :) With lambda x,y you can't just
curry the function. You can with lambda x: lambda y:, but then you can't
do regular application with it.
however, do take a look at http://www.sourcekeg.co.uk/www.pytho.../pep-0309.html
which is getting in for 2.4 (?)
k
François Pinard <pi****@iro.umontreal.ca> writes: One should avoid being too judgemental, especially when not much
familiar with problems at stake. (Yet, I did exactly this a few
times, in the youth of my programmer life. It took a while before I
began to see how presumptuous I might have been at times :-).)
Hey, join the club!
Ville is welcome to join too :-)
On 8 Jul 2004, Jacek Generowicz wrote: Specifying the type in Bigloo will make the code run more quickly,
while asserting the type in Python will make the code run more slowly.
Using Psyco, which automatically generates statically-typed code, will
also make code run more quickly. If that's not enough, you can use Pyrex,
which is statically typed.
Python provides no built-in support for pattern matching, therefore
[snip] matching in its best light. Therefore, they are likely to conclude
that there is no use for pattern matching ...
Pattern matching is rarely needed outside of functional programming
languages. My understanding of pattern matching is that it is designed
not primarily to allow functions to operate on multiple data types
(which Python does implicitly), but rather to ease writing recursive
functions, i.e.:
def mangle_list(arg):
arg -> int head, tail:
return mangle_int(head), mangle_list(tail)
arg -> float head, tail:
return mangle_float(head), mangle_list(tail)
arg -> NULL:
return NULL
else:
raise TypeError
Naturally, something like this would be replaced with a list comprehension
in Python:
def mangle_list(arg):
return [mangle_object(i) for i in arg]
A binary tree structure better shows the advantage of pattern matching,
however:
def mangle_binary_tree(arg):
arg -> a, b:
return mangle_binary_tree(a),mangle_binary_tree(b)
arg -> int a:
return mangle_int(arg)
arg -> float a:
return mangle_float(arg)
else:
raise TypeError
Something like this would be better handled by a higher-level library
function in Python.
Anyways, my point is, Python programmers don't think they have a need for
pattern matching precisely because they don't have a need for it: pattern
matching primarily benefits recursive structures, such as those commonly
found in Scheme.
[Christopher T King] Anyways, my point is, Python programmers don't think they have a need
for pattern matching precisely because they don't have a need for it:
pattern matching primarily benefits recursive structures, such as
those commonly found in Scheme.
Deep down, recursive structures originate from the problem to solve, not
from the programming language used to solve the problem.
Scheme (and other languages as well) are well-suited to solve problems
involving recursive structures, but Python is very well-suited too. If
Python programmers don't think they have a need for pattern matching,
it's merely because they did not stumble yet on problems where it fits.
--
François Pinard http://www.iro.umontreal.ca/~pinard
Christopher T King <sq******@WPI.EDU> writes: On 8 Jul 2004, Jacek Generowicz wrote:
Specifying the type in Bigloo will make the code run more quickly,
while asserting the type in Python will make the code run more slowly.
Using Psyco,
A lot of use it is on my Mac, my Sun ... etc.
which automatically generates statically-typed code,
Which in no way avoids dynamic dispatch _to_ said code.
If that's not enough, you can use Pyrex,
or Scheme, or Common Lisp ...
which is statically typed.
.... or C, or Fortan.
But why am I playing "pick nits in irrelevant details" with you ?
Python provides no built-in support for pattern matching, therefore
[snip] matching in its best light. Therefore, they are likely to conclude
that there is no use for pattern matching ...
Pattern matching is rarely needed outside of functional programming
languages.
Do you use pattern matching regularly in you progarms? If not, then
forgive me for not lending much weight to your opinion on the
matter. This is the crux of my original point.
My understanding of pattern matching is that it is designed
not primarily to allow functions to operate on multiple data types
(which Python does implicitly), but rather to ease writing recursive
functions, i.e.:
To ease writing functions. Finishing your sentence there would make it
more accurate.
Anyways, my point is, Python programmers don't think they have a need for
pattern matching precisely because they don't have a need for it: pattern
matching primarily benefits recursive structures, such as those commonly
found in Scheme.
Remind me, how often do you use pattern matching in your daily work ?
When I started using Python, there were no static methods in the
language. Whenever anyone asked about them, the answers typically went
along the lines of "There is no need for static methods in Python."
Guess what, Python now has built-in support for static methods, and
lots of people use them. If I took the time to think about it, I could
probably come up with at least five more examples of this nature.
Certain features absent from Python, are a concious design decision;
attribute access restriction, for example. Here you can state that you
don't need the feature because you think that having it is
detremental. But in the case of features which are just missing
because nobody has implemented them ... it's pretty daft to claim that
they are unnecessary in Python, unless you are an _expert_ in their
use.
On 8 Jul 2004, Jacek Generowicz wrote: Python provides no built-in support for pattern matching, therefore
[snip] matching in its best light. Therefore, they are likely to conclude
that there is no use for pattern matching ...
Pattern matching is rarely needed outside of functional programming
languages.
Do you use pattern matching regularly in you progarms?
Aside from tuple unpacking, no. I've also never found the need to do
anything more complex when writing Python programs. I am familiar enough
with pattern matching, however, that I have found the need for it while
writing C programs, specifically those operating on recursive data
structures. I've also found the need for many other concepts that I've
never actually used before (i.e. continuations, partial function
application) while programming Python, but never pattern matching.
Do you regularly find a need for pattern matching in Python? Assuming your
answer is yes, could you give some examples of where pattern matching
could help?
In article <ty*************@pcepsft001.cern.ch> (Thu, 08 Jul 2004 15:04:30
+0200), Jacek Generowicz wrote: Python offers no advantages over a Turing Machine, because you can
simulate all of Python's features in a Turing Machine.
Agreed, although personally I have other things to do between now and
8 July 2024.
Neil Hodgson wrote: Paul Prescod:
... It also meant that we didn't have to display
the parentheses in the underlying s-expressions: we could show
structure by indentation. By this means we made the language look
a lot less threatening."
Every sufficiently advanced LISP application will eventually reimplement
Python.
You made me smile but you also made me think. If you need to use Scheme
in the "real world" you will use a Scheme with Python-like libraries,
maybe infix syntax, some form of object orientation etc. So who is
morphing into who?
With respect to Common Lisp I argue no contest: if you build the world's
biggest language from the start of course every other language will look
like a subset of it. ;)
Paul Prescod
Jacek Generowicz wrote: ...
In Haskell, both
f 1
and
f 1 2
will work, while in Python you have to install the plumbing yourself
every time.
But what does this have to do with Scheme, which was the subject of
conversation? We were trying to decide what deep computer science
concepts you could learn from Scheme that you couldn't from Python.
One thing I find interesting about these deep computer science concepts
seem to be mostly just language features. I mean Java is in some sense a
really good computer science language because of all of the threading
stuff it has: you'll learn about concurrent programming better with Java
than with R4RS scheme!
It might be interesting if someone rewrote SICP for Python...would
Python exhibit big conceptual gaps?
Paul Prescod
Hamilcar Barca wrote: ...
You don't seem to have taken it this way, but I don't intend to bash
Python.
I didn't take it that way. I'm just trying to understand to what extent
your position is yours and to what extent it is just common wisdom.
Languages deemed "good for education" do not have a good history: BASIC,
Pascal, etc. Why was Pascal good for teaching? In retrospect it really
wasn't that great. But at the time it was common wisdom.
...Python supports recursion, second order functions, numerical programming
and hundreds of other important concepts.
How about currying and deferred list evaluation?
Between generators, nested functions and generator expressions I think
we're doing okay. But why are these more important concepts than (let's
say) threads or network programming? Because the latter are tainted by
real-world usefulness?
Computer science is a really massive field and I think that for every
pattern that is made easy to learn because it falls out of the language
syntax ("deferred list evaluation: now I understand lazy processing in
general") there are ten that do not (cache coherency, context-free
grammars, relational algebra, tree transformations, algorithmic
complexity, state machines, quick sort, floating point numbers, graph
theory, text searching).
Therefore we should look for a language that is fun, easy to learn
(relatively speaking!) and highly productive but not expect the language
itself to deliver the CS education. Students will probably learn more
from the library than from the language. I'd go so far as to say that
what you are looking for is a language that gets out of your way to the
greatest extent. The language is primarily a notation...not a concept.
Paul Prescod
Neil Hodgson wrote: Paul Prescod:
... It also meant that we didn't have to display
the parentheses in the underlying s-expressions: we could show
structure by indentation. By this means we made the language look
a lot less threatening."
Every sufficiently advanced LISP application will eventually reimplement
Python.
I hereby dub thee "Hodgson's Law".
Paul Prescod
In article <ma*************************************@python.or g> (Thu, 08
Jul 2004 22:24:18 -0700), Paul Prescod wrote: I'm just trying to understand to what extent your position is yours and
to what extent it is just common wisdom.
I think common wisdom would say VisualBasic and Java, for example, should
be the primary languages; when I first started school, FORTRAN, COBOL,
APL, and (enhanced) Dartmouth BASIC seemed big.
Languages deemed "good for education" do not have a good history: BASIC,
Pascal, etc. Why was Pascal good for teaching?
Pascal was big because it had a reasonably simple syntax, strong typing,
plain block structure, among other things. Did this make it the best
choice at the time? I don't think so. Was it good enough? Yes.
If I were making the decision between say FORTRAN, COBOL, APL, Pascal,
Modula, C++, Java, C#, VBA, or Python, I'd choose Python quickly. Adding
Smalltalk and Scheme would make me think harder. Perhaps it was you who
said it (or maybe I imagined it), but the availability of a work the
quality of Abelson and Sussman for Python and Smalltalk would make the
decision quite hard.
But why are these more important concepts than (let's say) threads or
network programming?
I don't see why network programming is particularly important for teaching
basic concepts. I do think parallel programming worthy of study but it's
not quite what I mean. I neglected to say so, but my comments were
directed toward introductory education.
Because the latter are tainted by real-world usefulness?
I don't worry about a taint; the choice of language for education should
not be based on salability or popularity, but rather on its ability to
express the concepts to be demonstrated by writing programs.
Therefore we should look for a language that is fun, easy to learn
(relatively speaking!) and highly productive but not expect the language
itself to deliver the CS education.
Fun isn't fundamental be neither should pain be inflicted gratuitously.
Students will probably learn more from the library than from the
language.
Perhaps or perhaps not, but...
I'd go so far as to say that
what you are looking for is a language that gets out of your way to the
greatest extent. The language is primarily a notation...not a concept.
I'd go so far as to say that I agree completely with your point.
I'm a bit tired of the attitude of undergraduates, especially, who want to
be taught a language because they think it will get them a job.
Undergratuates as a rule don't know diddly-squat, if you'll excuse the
technical terminology. I'm seriously tired of the rah-rah,
jump-on-the-bandwagon, my-krew's-using-it rationale for language choice.
I'm glad this isn't your attitude and anyway it's a different rant.
In article <du*************@amadeus.cc.tut.fi> (Thu, 08 Jul 2004 13:02:31
+0300), Ville Vainio wrote: Hamilcar> Is this a good place to insert my "Smalltalk is the only
Hamilcar> language good enough for teaching people to program"
Hamilcar> rant?
What's better about Smalltalk compared to Python, educationally?
Although I meant what I said, I said it here as a joke.
Just a brief list will do.
I don't seem to be able to provide coherent, objective arguments, at
least beyond the ones you might find at Smalltalk.org or Squeak.org.
Here's an entirely subjective opinion after over twenty years of
programming.
Among others, I learned Python and Smalltalk in the last year. I didn't
particularly like Python for the first three or four weeks before it began
to grow on me. It wasn't exactly what I was used to and it took me some
time to discover its strengths.
Contrarily, it took me no more than a day or two to really like the
Smalltalk language and its environment. After a few weeks, I was
quite surprised at the environment's capabilities: I discovered I was
doing some things I didn't realize any environment could do. I hadn't
read about them or done more than a little experimentation, they just
seemed natural. For example, it's trivially easy to stop a program's
execute, view and fiddle about with objects and code, and then continue on.
My conclusion, for what little it's worth, was "This is the way it was
intended to be."
--
[Microsoft's] illegal conduct has enabled [it] to acquire a dominant
position in the market for work group server operating systems ..."
-- European Commission ruling. 24 March 2004.
Christopher T King <sq******@WPI.EDU> writes: Do you regularly find a need for pattern matching in Python?
No. (As I already mentioned upthread.)
Which probably says more about my ignorance and lack of imagination
(or the boring range of programs I write) than about how useful
pattern matching may or may not be in Python.
That has been my point throghout.
François Pinard <pi****@iro.umontreal.ca> writes: If Python programmers don't think they have a need for pattern
matching, it's merely because they did not stumble yet on problems
where it fits.
No. It's because they don't know the concept and don't know what they
are missing.
Nobody missed OOP before it was invented. People just created
workarounds and crutches to solve problems where OOP would have been a
fit. It's not until an OOP-trained person moves to a language without
support for OOP until they realize how complicated and inelegant
things can get. (Then they might start simulating OOP one way or
another, but it's never quite the right thing.)
So, in this respect Wittgenstein applies:
"The boundaries of my language are the boundaries of my world."
Matthias
Hamilcar Barca wrote: Contrarily, it took me no more than a day or two to really like the
Smalltalk language and its environment.
This is the same experience some of us had with Python...
> Hamilcar Barca wrote: Contrarily, it took me no more than a day or two to really like the
Smalltalk language and its environment.
This is the same experience some of us had with Python...
The language: Python is wonderful, and I took to it more naturally than to
Smalltalk. But, the Smalltalk environment (Squeak is the only one I have
tried) is *really* quite amazing. I recommend playing with it a bit just
to get an idea of What Could Be even if you never intend to use it for
anything substantial.
In article <36*************@hundertwasser.ti.uni-mannheim.de>,
Matthias <no@spam.pls> wrote: François Pinard <pi****@iro.umontreal.ca> writes:
If Python programmers don't think they have a need for pattern
matching, it's merely because they did not stumble yet on problems
where it fits.
No. It's because they don't know the concept and don't know what they
are missing.
Nobody missed OOP before it was invented. People just created
workarounds and crutches to solve problems where OOP would have been a
fit. It's not until an OOP-trained person moves to a language without
support for OOP until they realize how complicated and inelegant
things can get. (Then they might start simulating OOP one way or
another, but it's never quite the right thing.)
So, in this respect Wittgenstein applies:
"The boundaries of my language are the boundaries of my world."
That's true, but it seems to imply that these concepts
have their own intrinsic virtue, independent of the
language within which they might be deployed.
If Python started as an ordinary procedural language and
added its OOP features later, I'm sure that would have
been cause for real celebration. In Python, the virtues
of OOP are clear. But if you look at Objective CAML, a
functional programming language with an elaborate, very
respectable OOP infrastructure, I think you would find
people tending to steer clear of OOP features. At least
that's my casual impression. It takes some effort to
learn, it has a slight performance cost compared to the
very efficient functional idioms, and it isn't really
essential outside of a few special areas of programming,
like graphic UI toolkits. I think it will probably remain
alone as a fully functional OOP functional programming
language, and the rest of the FPL world may forever say
nobody missed OOP even after it was invented.
I think pattern matching may be a bit like that from the
other direction. This feature couldn't be removed from
ML or Haskell family languages without mortal injury, but
that's about more than just their proclivity towards
recursive functions (?!) Pattern matching is integral
to their type systems, which gets into a large and complex
area of differences between them and Python. The main
application I'm thinking of is the sum type - an enumerated
union type. For example, Haskell functions often return
a parameterized "maybe" type, which may have a value of
either Nothing or Just a, where a is the parameter type.
The pattern matching feature dispatches on a type like
that - for example,
case (findone xyz) of
Nothing -> "not found"
Just t -> t
which elegantly combines type analysis and dispatch with
the unpacking function.
It's not like this principle has no application in Python,
there are examples all over the standard libraries where
dissimilar types can appear in the same context, but Python
not only lacks the infrastructure of sum types and pattern
matching, it also represents a different way of life where
the language and its users aren't as fastidious and people
just cope with the mess. The same feature is arguably much
less useful in Python, not just because people don't understand
the feature per se but because it has a different meaning here.
Donn Cave, do**@u.washington.edu
Paramjit Oberoi wrote: Hamilcar Barca wrote:
Contrarily, it took me no more than a day or two to really like the
Smalltalk language and its environment.
This is the same experience some of us had with Python...
The language: Python is wonderful, and I took to it more naturally than to
Smalltalk. But, the Smalltalk environment (Squeak is the only one I have
tried) is *really* quite amazing. I recommend playing with it a bit just
to get an idea of What Could Be even if you never intend to use it for
anything substantial.
My point was more subtle than it appeared. I did in fact
mean the "Python environment", as you mean the Smalltalk
environment... How I define that environment is perhaps
not obvious, but with a little imagination anyone could
start to think of ways in which I've made *my* Python
_environment_ very, very powerful, easy to work with,
etc.
And yes, I know what Smalltalk can do.
-Peter
>>>>> "Francois" == François Pinard <pi****@iro.umontreal.ca> writes:
Francois> Pythoneers do not know, or at least, do not use).
Francois> Another problem with structure matching in Python is
Francois> that a failed matching raises an exception, something
Francois> slow for applications heavy on pattern matching. For
Francois> very simple applications however, Python easily does as
Francois> it stands.
And that's where I proposed a library, taking a "structure" (tuple,
typically), a'la (int, int,(float,str),[int]) that verifies that the
tuple matches before unpacking. though - a couple of if-elif's will typically do fine (because that's
what pattern matching essentially is).
Jacek> ... yup, you prove my point exactly.
Francois> And Jacek is right, once again. One should avoid being
Francois> too judgemental, especially when not much familiar with
Francois> problems at stake. (Yet, I did
I have to admit I'm not aware of my unfamiliarity with the topic. I
was thinking of pattern matching as it is used in ocaml, assuming
scheme does the same. As you can see from a previous post, I was
asking for an example on how it would *not* work, possibly as a way to
learn something new about pattern matching. It's also an idea for a
python library. So I don't think this is entirely unproductive.
Francois> presumptuous I might have been at times :-).) I know
Francois> that some people trigger their own education by
Francois> challenging others, which is not that humble to start
Francois> with, likely irritating to the challenged people, and
Francois> not looking very polite to the casual observers.
Well, I'm still waiting for the education, so far I've only got "you
don't understand" (w/ which I disagree, for now). For a non-casual
observer, "you don't understand" is much closer to a cheap ad-hominem
shot than "can you explain this, because I disagree with this
interpretation".
Francois> Hopefully, life will give you the opportunity for many
Francois> more checks! :-) Pattern matching is by far not limited
Francois> to strings, and whole areas of technology are either
Francois> dedicated or based on pattern matching.
Yes, this is something I actually do understand. I wasn't thinking of
regexp pattern matching at all. I was thinking of
let rec len l =
match l with
[] -> 0
| [_] -> 1
| [_;_] -> 2
| _::xs -> 1 + len xs;;
But in theory, I agree with you about the approach of "younger"
programmers [I'm an old fart, BTW; 27 years and counting]. It's just
part of the thrills of being a programmer. I just don't have enough
real work to do ATM, I'm on summer vacation ;-).
Understanding that, and the fact that I'm back to work on monday
(ouch), probably the wise thing to do is to terminate this discussion
now. I hereby declare that Jacek won, Scheme kicks Pythons rear parts
(esp. the Bigloo implementation) and I prefer Python because I Just
Don't Get It (TM).
[and lest someone misunderstand that as bitter sarcasm, it's not -
it's more the reason of getting 0.5 hours of sleep within the last 36
hours, and I terminate this in quite a cheerful mood]
--
Ville Vainio http://tinyurl.com/2prnb
In article <pc********************@powergate.ca> (Fri, 09 Jul 2004
06:52:13 -0400), Peter Hansen wrote: Hamilcar Barca wrote:
Contrarily, it took me no more than a day or two to really like the
Smalltalk language and its environment.
This is the same experience some of us had with Python...
So I've read and I've found no reason to disbelieve it. As I noted when I
said this represented "subjective" opinion, It just wasn't my experience.
Ville Vainio <vi***@spammers.com> wrote in message news:<du*************@mozart.cc.tut.fi>... I have to admit I'm not aware of my unfamiliarity with the topic. I
was thinking of pattern matching as it is used in ocaml, assuming
scheme does the same. As you can see from a previous post, I was
asking for an example on how it would *not* work, possibly as a way to
learn something new about pattern matching. It's also an idea for a
python library. So I don't think this is entirely unproductive.
Francois> presumptuous I might have been at times :-).) I know
Francois> that some people trigger their own education by
Francois> challenging others, which is not that humble to start
Francois> with, likely irritating to the challenged people, and
Francois> not looking very polite to the casual observers.
Well, I'm still waiting for the education, so far I've only got "you
don't understand" (w/ which I disagree, for now). For a non-casual
observer, "you don't understand" is much closer to a cheap ad-hominem
shot than "can you explain this, because I disagree with this
interpretation".
Francois> Hopefully, life will give you the opportunity for many
Francois> more checks! :-) Pattern matching is by far not limited
Francois> to strings, and whole areas of technology are either
Francois> dedicated or based on pattern matching.
Yes, this is something I actually do understand. I wasn't thinking of
regexp pattern matching at all. I was thinking of
let rec len l =
match l with
[] -> 0
| [_] -> 1
| [_;_] -> 2
| _::xs -> 1 + len xs;;
Jacek and Francois already said what I wanted to say, so I just wanted to
give you the only reference I know about pattern matching in Scheme: google
for "Andrew Wright's pattern matching package". I looked at it in the past,
very superficially, but enough to realize that pattern matching is
something SUBSTANTIAL. An entire new way of thinking. But you should
probably be cast in the mindset of lisp-style macro programming to
appreciate it.
Also, if you don't take it as an offence, I can give you a suggestion
for a Scheme implementation you can look at, Chicken
( http://www.call-with-current-continuation.org/). I am not interested in
Bigloo since I don't care at all about being fast for numerical
analysis and I care more about other things, such as the object
system (Bigloo has a poor one because it want to be fast).
Michele Simionato
Ville Vainio <vi***@spammers.com> wrote in message news:<du*************@amadeus.cc.tut.fi>... >> "Hamilcar" == Hamilcar Barca <ha******@tld.always.invalid> writes: >> Python supports recursion, second order functions, numerical
>> programming and hundreds of other important concepts.
Hamilcar> How about currying and deferred list evaluation?
Deferred list evaluation: generators
Lazy evaluation in general: lambda : f(1,2)
this does not work so well; missing a constructs such as Scheme "set!" and "let"
anseverely limitates certain programming paradigms which are natural in Scheme.
This is ok, anyway, since Python is not Scheme. But you cannot claim that
Python support for certain things is as good as in other languages (say
Scheme, Haskell, etc.)
Currying: lambda x,y : f(x,y,1,2)
This is not currying. It is specializing arguments. Here is a reference about
specializing arguments in Scheme: http://srfi.schemers.org/srfi-26/srfi-26.html
Haskell does real currying.
Michele Simionato
"Neil Hodgson" <nh******@bigpond.net.au> wrote in message news:<5D*******************@news-server.bigpond.net.au>... Paul Prescod:
... It also meant that we didn't have to display
the parentheses in the underlying s-expressions: we could show
structure by indentation. By this means we made the language look
a lot less threatening."
Every sufficiently advanced LISP application will eventually reimplement
Python.
Neil
This is also true for Scheme: http://srfi.schemers.org/srfi-49/srfi-49.html
SRFI-49: Indentation-sensitive syntax
Indentation will rule the world! :)
(even if I must confess that secretely I am not yet convinced of the
virtues of indentation and I will estimate advantages/disadvantages to
be 1:1)
Michele Simionato This thread has been closed and replies have been disabled. Please start a new discussion. |
