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
176  7996 
Thomas Reichelt wrote: 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,
You might want to take a quick look at Haskell, although I think it is
still largely an academic's language. A quick roundup of
similarities/differences:
Haskell is strongly typed but fully supports polymorphism
Haskell is functional rather than imperative
Haskell uses significant whitespace, like Python
Website: http://www.haskell.org/
HUGS is a good interpreter for Haskell if you want to try it out.
Sam
Thomas Reichelt <XX********@gibts.net> pisze: 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?
Static typing would destroy all fun in Python. Eventually we would end
with ObjectPascal-like language, just running in VM and not compiled.
Maybe Borland's Delphi for .NET is what you look for?
--
Jarek Zgoda http://jpa.berlios.de/
>>>>> "Jarek" == Jarek Zgoda <jz****@gazeta.usun.pl> writes:
Jarek> Static typing would destroy all fun in Python. Eventually
Jarek> we would end with ObjectPascal-like language, just running
Jarek> in VM and not compiled.
Using a type inference system, it wouldn't. The code would "flow" like
it does now. Some corners of the code would probably benefit from
having explicit declarations to smooth up the process, but most of the
code could look exactly the way it does now.
--
Ville Vainio http://tinyurl.com/2prnb
>>>>> "Sam" == Sam Jervis <sa*@heffalump.me.uk> writes:
Sam> You might want to take a quick look at Haskell, although I
Sam> think it is still largely an academic's language. A quick
Sam> roundup of
I think the Haskell programming experience is totally different from
the Python experience, because of the functional approach. This also
implies that there is about a zero possibility of introducing the
language in commercial projects because of peer opposition and the
"academic" flavor of the language (no libraries, absent/elitist
community that doesn't even need libraries).
The Lisp programming experience might be more pythonic, but the syntax
(or the absence of it) kinda ruins it too. But then again, Lisp is
dynamically typed but with type declarations.
--
Ville Vainio http://tinyurl.com/2prnb
Ville Vainio wrote: >> "Jarek" == Jarek Zgoda <jz****@gazeta.usun.pl> writes:
Jarek> Static typing would destroy all fun in Python. Eventually
Jarek> we would end with ObjectPascal-like language, just running
Jarek> in VM and not compiled.
Using a type inference system, it wouldn't. The code would "flow" like
it does now. Some corners of the code would probably benefit from
having explicit declarations to smooth up the process, but most of the
code could look exactly the way it does now.
Yes, type inference, for example, would be a great addition to Python! I
took a look at OCaml a while ago, but as I am not very addicted to pure
functional programming, it wasn't my thing. Also, compared to Python, the
number of libraries is small, and the support for UI is cumbersome... but
type inference is great.
What I would have in mind is a flag, or maybe language directive, that
switches static typing via type inference on. Of course, some of the
dynamic features of Python would have to be disabled then, but it would
result in better error-checking, and perhaps bytecode compilable to native
code, resulting in faster execution.
--
greetz tom
"Thomas Reichelt" <XX********@gibts.net> wrote in message
news:2k************@uni-berlin.de... 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?
I believe that it's on Guido's wish list, at least as an option.
At one time there was a types sig that was looking into it,
but I don't know of its current status. It got bogged down
and didn't deliver anything.
There are a couple of projects that have done some kind
of type inference in Python. You might check out Bicycle
Repair Man, which has a type inference engine that it uses
to help in refactoring. I've also heard of another academic
project that was supposed to release code sometime this
summer, but the name escapes me.
There are a number of places that would have to be cleaned
up to make type inference work well. The <string>.find() method
is practically a poster child for a method that would give any
type inference mechanism fits. It returns an integer, right?
Wrong. It's supposed to return either an index into the string
(a separate type) or an indication it didn't find one. However,
the result sometimes evaluates to False when it found one,
always evaluates to True when it didn't, and is a valid index
even when it didn't find a match.
A <string>.findall() method that returned a list of all
matches is much cleaner: it evalutes to false when the
list is empty (no matches), it never returns something
that looks like an index for a non-match, and it's
compatible with the for statement.
John Roth
Thank you,
--
greetz tom
Dnia Sat, 03 Jul 2004 10:56:24 +0200, Thomas Reichelt napisa³(a): What I would have in mind is a flag, or maybe language directive, that
switches static typing via type inference on. Of course, some of the
dynamic features of Python would have to be disabled then, but it would
result in better error-checking, and perhaps bytecode compilable to native
code, resulting in faster execution.
Sounds just like Starkiller+Psyco combo :) (Even though Starkiller is not
released yet AFAIK.)
--
Marek Baczyñski :: UIN 57114871 :: GG 161671 :: JID im******@jabber.gda.pl
evolve or face extinction (applies to you, too!)
> Haskell is strongly typed but fully supports polymorphism Haskell is functional rather than imperative
Haskell uses significant whitespace, like Python
and it is at least 3 days behind Python. At least in Sweden, @ Chalmers ...
EuroHaskell was just behind EuroPyhton
Quoth Thomas Reichelt <XX********@gibts.net>:
| 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?
I haven't tried it, but Nice is a Java based language with a more
sophisticated type system than Java, and a few extra conveniences. http://nice.sourceforge.net/
It doesn't appear to have type inference, which so far as I know
may be exclusive to functional languages, but it does have the
"contract", "interface" etc. stuff that seems to be needed with
statically typed object oriented languages. I can't tell right
away from the web pages, but it looks like subtype polymorphism
is all you get - so for example in a context that expects a File,
you can't show up with something that was just built in the shape
of a File, it has to be a subclass of File. Again as usual with
object oriented languages. But the type system certainly looks
more powerful, the language looks more expressive whatever that
means, and the Java implementation means lots of libraries.
Haskell is a conundrum. Not many known users outside of academia,
some kind of intractable problems that seem likely to keep it that
way, but it has deep roots and has become the archetypal functional
programming language with a supportive community that shows no signs
of withering away. And after all it's an inspiring language to use.
Not like the other relatively popular functional programming language
these days, rather the opposite.
Donn Cave, do**@drizzle.com
Thomas Reichelt <XX********@gibts.net> wrote in message news:<2k************@uni-berlin.de>... Moin,
short question: is there any language combining the syntax, flexibility and
great programming experience of Python with static typing?
Run, run, and run. Do not look back. And for heavens sake: use
"Bigloo".
I was not in dire need for looking back to Python any longer once I
encountered Bigloo:
- types
- object system
- pattern matching
- exception handling
- keywords
- Bee (development environment)
- excellent foreign function interface to C: Bigloo speaks C indeed!
- Java backends (automatically generated from Scheme code)
- .Net integration
- excellent and very stable high perfromance compiler for speed;
performance is on par with OCaml
- nearly on every platform
- and do not forget: though, there are types but you /always/ will get
the option of using Bigloo as it were an ordinary Scheme with all the
freedom so to speak! Types will never be your stumbling block as in
Clean or Haskell for example.
Fensterbrett
PS: Note: with srfi-1 you get a lot of typical functional programming
support! Hey man you can even download the srfi-functions for "lazy
streams".
Marek Baczy?ski wrote: Dnia Sat, 03 Jul 2004 10:56:24 +0200, Thomas Reichelt napisa?(a):
What I would have in mind is a flag, or maybe language directive, that
switches static typing via type inference on. Of course, some of the
dynamic features of Python would have to be disabled then, but it would
result in better error-checking, and perhaps bytecode compilable to
native code, resulting in faster execution.
Sounds just like Starkiller+Psyco combo :) (Even though Starkiller is not
released yet AFAIK.)
Starkiller sounds very interesting... I am sure it is worth trying when it's
released!
--
greetz tom ch********@hotmail.com wrote: Thomas Reichelt <XX********@gibts.net> wrote in message
news:<2k************@uni-berlin.de>... Moin,
short question: is there any language combining the syntax, flexibility
and great programming experience of Python with static typing?
Run, run, and run. Do not look back. And for heavens sake: use
"Bigloo".
I was not in dire need for looking back to Python any longer once I
encountered Bigloo:
[...]
Thanks, but... Scheme... I hate parens ;)
--
greetz tom
Ville Vainio wrote: >>"Jarek" == Jarek Zgoda <jz****@gazeta.usun.pl> writes:
Jarek> Static typing would destroy all fun in Python. Eventually
Jarek> we would end with ObjectPascal-like language, just running
Jarek> in VM and not compiled.
Using a type inference system, it wouldn't. The code would "flow" like
it does now. Some corners of the code would probably benefit from
having explicit declarations to smooth up the process, but most of the
code could look exactly the way it does now.
I don't really believe that is true. Many Python functions have
extremely complex type signatures. In a type inferenced language you
don't type in type signatures everywhere but you do define have to
design your types with the inferencer in mind. This would be a big
change in Python programming style.
To put it another way: Jarek complains that static typing would destroy
the "fun". I think he means Python's flexibility. A type inferencer
removes the need to declare types but a statically type-inferenced
language is still statically typed. It will still be strict about type
usage.
Paul Prescod
Thomas Reichelt <XX********@gibts.net> wrote in message news:<2k************@uni-berlin.de>... Thanks, but... Scheme... I hate parens ;)
Do not take the following patronizing. But why to you believe that you
hate parens?
You put yourself into big troubles if you miss the opportunity of
Bigloo. I haven't counted parens or had to cope with it in any time I
can think of since parens will never come in your way. Why should
parens interfere with your way?
The code is much better structured in Scheme than in Python. It is a
big mistake to assume that Python displays any readability. The one
and only thing, provided I were a teacher, which I would never use for
annoying school people in introductory courses would be Python for its
huge learning curve and its messy behavior.
You should give Scheme a try.
Fensterbrett ch********@hotmail.com wrote: Thomas Reichelt <XX********@gibts.net> wrote in message
news:<2k************@uni-berlin.de>...
Thanks, but... Scheme... I hate parens ;)
Do not take the following patronizing. But why to you believe that you
hate parens?
You put yourself into big troubles if you miss the opportunity of
Bigloo. I haven't counted parens or had to cope with it in any time I
can think of since parens will never come in your way. Why should
parens interfere with your way?
Because the syntax of Scheme, Lisp etc. is strange to me. I don't speak
lightly, 'cause I have tried some of the dialects (although it was a long
time ago). It was not that I couldn't write correct code in it, but after
implementing some of my "test" programs that I write in every new language
I try, I looked at them and thought "O my god, what a mess". Guess that
it's my brain fooling me...
The code is much better structured in Scheme than in Python. It is a
big mistake to assume that Python displays any readability. The one
and only thing, provided I were a teacher, which I would never use for
annoying school people in introductory courses would be Python for its
huge learning curve and its messy behavior.
This is coming close to trolling, IMHO.
--
greetz tom
On Sun, 04 Jul 2004 10:18:18 +0200, Thomas Reichelt
<XX********@gibts.net> wrote: The code is much better structured in Scheme than in Python. It is a
big mistake to assume that Python displays any readability. The one
and only thing, provided I were a teacher, which I would never use for
annoying school people in introductory courses would be Python for its
huge learning curve and its messy behavior.
This is coming close to trolling, IMHO.
Perhaps it is.
But as an advocate of the potential of Python in education, it is to
me not unitneresting to hear, and I do not totally discount the point
of view.
Learning curve, messiness aside - there is little question to be that
the Scheme community has approached the issue of the role of
programming education, as an element of an *education* in general, in
more mature, sophisticated, and honest ways then I have generally
noticed in the Python community.
I recently reread the introduction to How to Design Programs, which is
a book that is part of the TeachScheme project. http://www.htdp.org/2003-09-26/Book/...ml#node_chap_1
It expresses in a few paragtraphs some of the inescapable
fundamentals:
"Becoming and being a programmer is fun, but it is not easy."
"Programming a computer requires patience and concentration. Only
attention to minute details will avoid frustrating grammatical
mistakes."
The obvious.
Much of what you hear in the Python world regarding education sounds
different.
"Python is easy, and learning to program with Python is easy."
Often implying that it is only that others are making the effort in
languages other than Python that makes it seem otherwise.
Which is wonderful to hear, and would be worth saying, if saying it
would make it true.
Of course, it doesn't.
Of course, its nonsense.
Art
>>>>> "Chain" == chain lube <ch********@hotmail.com> writes:
Chain> You put yourself into big troubles if you miss the
Chain> opportunity of Bigloo.
I agree. Should I also forward this message to 10 other people to
dodge the impending doom?
Chain> The code is much better structured in Scheme than in
Chain> Python. It is a big mistake to assume that Python displays
Chain> any readability. The one
So true.
(set! x 10)
Is so much more readable than
x=10
Chain> annoying school people in introductory courses would be
Chain> Python for its huge learning curve and its messy behavior.
With all due respect, someone that thinks python has a huge learning
curve must be a little bit on the slow side, cognition-wise.
--
Ville Vainio http://tinyurl.com/2prnb
>>>>> "Arthur" == Arthur <aj******@optonline.com> writes:
Arthur> "Python is easy, and learning to program with Python is
Arthur> easy."
Arthur> Often implying that it is only that others are making the
Arthur> effort in languages other than Python that makes it seem
Arthur> otherwise.
Arthur> Which is wonderful to hear, and would be worth saying, if
Arthur> saying it would make it true.
Arthur> Of course, it doesn't.
Arthur> Of course, its nonsense.
Well, many of us just think it's true. Only the academics seem to
think Scheme is easier to learn than, say Python or even C. Students
often disagree.
--
Ville Vainio http://tinyurl.com/2prnb
Thomas Reichelt <XX********@gibts.net> wrote in message news:<2k************@uni-berlin.de>... 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,
If you are using Python mainly for numerical work and use Numeric or
Numarray for array operations, Fortran 90 or 95 may be the closest
replacement with static typing. The syntax is fairly similar (assuming
that the free source form of F90/F95 is used, as it should for new
code). Fortran 2003 supports object-oriented programming with
inheritance (as does Python), but full F2003 compilers are not
available yet.
Paul Prescod wrote: To put it another way: Jarek complains that static typing would destroy
the "fun". I think he means Python's flexibility. A type inferencer
removes the need to declare types but a statically type-inferenced
language is still statically typed. It will still be strict about type
usage.
I am one who would really like _optional_ static typing information to be
available in python, but for different reasons than the usually requested here:
performance. My field is scientific computing, and when you are inside a
simple for loop, manipulating arrays of homogeneous data, the overhead of
python's dynamicism is a killer. Obviously what ends up happening is that we
rewrite those parts of our codes in C/C++/Fortran, but it would be great to be
able to simply tell python the types of the variables and have it not do any of
its dynamic runtime checks.
I do not believe in static typing as a compile-time 'feature': I've grown to
feel that all the supposed benefits of static typing can indeed be achieved
with proper testing, and the _huge_ gains in flexibility and productivity one
gets from python's type model are something I don't want to do without.
But for tightly constrained code that needs to run as fast as possible, without
repeating any unnecessary work (such as type detection), having an option to
declare type information would be a huge boon.
Cheers,
f
Fernando Perez wrote: I am one who would really like _optional_ static typing information to be
available in python, but for different reasons than the usually requested here:
performance. My field is scientific computing, and when you are inside a
simple for loop, manipulating arrays of homogeneous data, the overhead of
python's dynamicism is a killer. Obviously what ends up happening is that we
For performance, maybe Psyco is what you need, without the need fo
static typing, but rather different compilation of code for different
types, like with C++ templates.
Regards,
Nicolas
Nicolas Fleury wrote: Fernando Perez wrote: I am one who would really like _optional_ static typing information to be
available in python, but for different reasons than the usually requested
here:
performance. My field is scientific computing, and when you are inside a
simple for loop, manipulating arrays of homogeneous data, the overhead of
python's dynamicism is a killer. Obviously what ends up happening is that we
For performance, maybe Psyco is what you need, without the need fo
static typing, but rather different compilation of code for different
types, like with C++ templates.
Psyco sounds appealing, but it's an x86-only solution. That won't be of much
help on a Cray or an Itanum cluster...
Cheers,
f
Fernando Perez wrote: Psyco sounds appealing, but it's an x86-only solution. That won't be of much
help on a Cray or an Itanum cluster...
Itanium
stupid typo.
f
On 04 Jul 2004 21:40:11 +0300, Ville Vainio <vi***@spammers.com>
wrote: >> "Arthur" == Arthur <aj******@optonline.com> writes:
Arthur> "Python is easy, and learning to program with Python is
Arthur> easy."
Arthur> Often implying that it is only that others are making the
Arthur> effort in languages other than Python that makes it seem
Arthur> otherwise.
Arthur> Which is wonderful to hear, and would be worth saying, if
Arthur> saying it would make it true.
Arthur> Of course, it doesn't.
Arthur> Of course, its nonsense.
Well, many of us just think it's true. Only the academics seem to
think Scheme is easier to learn than, say Python or even C. Students
often disagree.
I don't think the academics you are referring to think Scheme is
easier to learn than Python, I'm thinking that they might be thinking
that neither is *easy*, and easy isn't the point in any case.
It is precisely this promotion as "easy" as somehow representing an
ultimnate good, in the context of education, that I find frustrating
to hear repeated so often here.
Is that the most important thing that Python has to offer?
It seems to me that in many respects Python is a programmer's
programming language. Isn't it safe to say that most people who use
Python, learned their fundamentals elsewhere, and find Python as a
productive way of applying what they already know.
This would be consistent with something I believe I read Guido as
having said in a recent interview. That Python was originally
developed as a tool for C programmers. ABC roots notwithstanding
I think I can be articulate as to why Python can be a good tool to
apply to educational challenges. But "easy" is never a word that
comes quickly to mind.
"Glue" comes to mind.
"Fun" comes to mind - and I see nothing wrong with *that* word in an
educational context.
It happens that *I* have learned Python and not learned Scheme, or C.
Maybe precisely *because* it is messier than either. ;)
Art
Try numeric / numarray (optimized arrays/matrices of real/complex for
scientific computing). Paul Prescod wrote:
To put it another way: Jarek complains that static typing would destroy
the "fun". I think he means Python's flexibility. A type inferencer
removes the need to declare types but a statically type-inferenced
language is still statically typed. It will still be strict about type
usage.
I am one who would really like _optional_ static typing information to be
available in python, but for different reasons than the usually
requested here:
performance. My field is scientific computing, and when you are inside a
simple for loop, manipulating arrays of homogeneous data, the overhead of
python's dynamicism is a killer. Obviously what ends up happening is
that we
rewrite those parts of our codes in C/C++/Fortran, but it would be great
to be
able to simply tell python the types of the variables and have it not do
any of
its dynamic runtime checks.
I do not believe in static typing as a compile-time 'feature': I've
grown to
feel that all the supposed benefits of static typing can indeed be
achieved
with proper testing, and the _huge_ gains in flexibility and
productivity one
gets from python's type model are something I don't want to do without.
But for tightly constrained code that needs to run as fast as possible,
without
repeating any unnecessary work (such as type detection), having an
option to
declare type information would be a huge boon.
Cheers,
f
>>>>> "Arthur" == Arthur <aj******@optonline.com> writes:
Arthur> I don't think the academics you are referring to think
Arthur> Scheme is easier to learn than Python, I'm thinking that
Arthur> they might be thinking that neither is *easy*, and easy
Arthur> isn't the point in any case.
Actually, the "real" attitude of the lecturers is often "now everyone
knows C (or C++, ot Java, or...) already, let's look at something
completely different". And apparently, the number of schools using
Scheme is constantly dropping - it has either been dropped already, or
the schools are considering dropping it. Usually replacing it for
Java, but they would do better to replace it with Python, of course.
Arthur> It is precisely this promotion as "easy" as somehow
Arthur> representing an ultimnate good, in the context of
Arthur> education, that I find frustrating to hear repeated so
Arthur> often here.
Perhaps. Perhaps you read it as "easy as in VB", while it actually
means "easy to learn, easy to do everything".
Arthur> It seems to me that in many respects Python is a
Arthur> programmer's programming language. Isn't it safe to say
Arthur> that most people who use Python, learned their
Arthur> fundamentals elsewhere, and find Python as a productive
Arthur> way of applying what they already know.
Quite probably, but that's more because of the current status of the
language as a "grassroots" language, where savvy programmers check it
out and start using it as opposed to many languages that are being
pushed by authorities (schools, conservative companies etc.).
Arthur> It happens that *I* have learned Python and not learned
Arthur> Scheme, or C.
Arthur> Maybe precisely *because* it is messier than either. ;)
Frankly, there is no real reason to learn Scheme. Common Lisp, OTOH,
has at least a theoretical possibility of being useful in the real
world (apparently Debian even provides some *gasp* libraries for
Common Lisp).
C itself is probably not too messy (awkward and clumsy, yes). Programs
written in C are.
--
Ville Vainio http://tinyurl.com/2prnb
Fernando Perez <fp*******@yahoo.com> writes: I am one who would really like _optional_ static typing information
to be available in python, but for different reasons than the
usually requested here: performance. My field is scientific
computing, and when you are inside a simple for loop, manipulating
arrays of homogeneous data, the overhead of python's dynamicism is a
killer. Obviously what ends up happening is that we rewrite those
parts of our codes in C/C++/Fortran, but it would be great to be
able to simply tell python the types of the variables and have it
not do any of its dynamic runtime checks.
I do not believe in static typing as a compile-time 'feature': I've
grown to feel that all the supposed benefits of static typing can
indeed be achieved with proper testing, and the _huge_ gains in
flexibility and productivity one gets from python's type model are
something I don't want to do without.
But for tightly constrained code that needs to run as fast as
possible, without repeating any unnecessary work (such as type
detection), having an option to declare type information would be a
huge boon.
I guess that you know that this sort of thing is successfully done in
Common Lisp (and Dylan and probably some, if not all, Schemes).
I've even heard rumours of Guido saying that something like it will
appear in a future, Python.
I would certainly warmly welcome it, if it should arrive in Python.
Ville Vainio <vi***@spammers.com> writes: Only the academics seem to think Scheme is easier to learn than, say
Python or even C. Students often disagree.
Sounds great; I bet it makes a lot of Python fans feel warm and fuzzy
inside. Unfortunately the claim is completely unfounded.
You should take a look at what the TeachScheme people have been doing,
and what they seem to be achieving.
Ville Vainio <vi***@spammers.com> writes: Chain> The code is much better structured in Scheme than in
Chain> Python. It is a big mistake to assume that Python displays
Chain> any readability. The one
So true.
(set! x 10)
Is so much more readable than
x=10
Well, that rather depends on what you are used to. But it is
undeniably true that the former is better structured.
[Ville Vainio] [Chain Lube]
The code is much better structured in Scheme than in Python. It is a
big mistake to assume that Python displays any readability.
With all due respect, someone that thinks [...]
Flamatory comments are not really my bag. :-)
But as someone who much liked both Scheme and Python, let me stress a
few aspects where Python attracted me more than Scheme.
The most important one is the bulk of library code which comes standard
with Python, but which has to be collected or rewritten in Scheme, not
being part of the standard.
Another is that, despite Scheme attempts to be minimalist (something
that I much like), Python is -- or at least once was! :-) -- more on the
side of having only one way of doing things. Two examples come to mind.
Scheme has three ways to write a conditional statement: `(cond ...)',
`(if ...)' and `(case ...)'. All have virtues and drawbacks, and I often
switch between the three, depending on my code, and the edits I do on my
code, so it stays best at all time. This is annoying.
Scheme has many ways for looping while changing local variables, some
of which are less nice and which I did not use much, I'm not even
discussing them. The `(let loop ...)' construct is useful for writing
tail-recursive loops without creating a flurry of little separate
functions, but it is often clearer writing destructive `(set! ...)'
instead of always being tail-recursive, even if tail-recursivity
often yields more efficient compilation. When you mix assignment and
tail-recursion, the amount of solutions for a piece a code is near
exponential in the number of variables. I found this annoying, too.
Bindings, conditionals and loops are very basic and ubiquitous in any
programming language, and Python got these relatively simpler than
Scheme. Scheme may be minimalist overall, but because of the frequency
of the above constructs in a program, the minimalism is not so apparent.
P.S. - On the other side, in those rare circumstances one needs
continuations, Scheme offers them very easily, while there are rather
painful to simulate in standard Python. Also, there once was a notable
distance between Scheme and Python about lazy evaluation and closure
construction, but more recent versions of Python offer fairly tractable,
almost easy approaches for such things.
--
François Pinard http://www.iro.umontreal.ca/~pinard
Jacek Generowicz schrieb: (set! x 10)
Is so much more readable than
x=10
Well, that rather depends on what you are used to. But it is
undeniably true that the former is better structured.
You mean the expression
"(set! x 10)" is_better_structured_as "x=10"
is true? How is is_better_structured_as defined? :)
Mit freundlichen Gruessen,
Peter Maas
--
-------------------------------------------------------------------
Peter Maas, M+R Infosysteme, D-52070 Aachen, Tel +49-241-93878-0
eMail 'cGV0ZXIubWFhc0BtcGx1c3IuZGU=\n'.decode('base64')
-------------------------------------------------------------------
Peter Maas wrote: Jacek Generowicz schrieb:
(set! x 10)
Is so much more readable than
x=10
Well, that rather depends on what you are used to. But it is
undeniably true that the former is better structured.
You mean the expression
"(set! x 10)" is_better_structured_as "x=10"
is true? How is is_better_structured_as defined? :)
I think you mean "is_better_structured_than", not "_as".
What you wrote, if true, would mean that Jacek meant
"x=10" was the better structured one...
(Anyway, arguing over "structured" is silly. Clearly "more readable"
rules. ;-)
-Peter
Peter Maas wrote: Jacek Generowicz schrieb:(set! x 10)
Is so much more readable than
x=10
Well, that rather depends on what you are used to. But it is
undeniably true that the former is better structured.
You mean the expression
"(set! x 10)" is_better_structured_as "x=10"
is true? How is is_better_structured_as defined? :)
Hey, it is
(is_better_structured_as "(set! x 10)" "x=10")
Be consistent!
Reinhold
--
Wenn eine Linuxdistribution so wenig brauchbare Software wie Windows
mitbrächte, wäre das bedauerlich. Was bei Windows der Umfang eines
"kompletten Betriebssystems" ist, nennt man bei Linux eine Rescuedisk.
-- David Kastrup in de.comp.os.unix.linux.misc
On 05 Jul 2004 13:24:08 +0200, Jacek Generowicz
<ja**************@cern.ch> wrote: Ville Vainio <vi***@spammers.com> writes:
Chain> The code is much better structured in Scheme than in
Chain> Python. It is a big mistake to assume that Python displays
Chain> any readability. The one
So true.
(set! x 10)
Is so much more readable than
x=10
Well, that rather depends on what you are used to. But it is
undeniably true that the former is better structured.
Well it does seem to me that the subtleties of assignment in Python is
an excellant example of where its "easiness" is more apparent than
real.
The notice of which takes nothing away from Python.
But does work toward dispute of certain discriptions of it.
Art
>>>>> "Jacek" == Jacek Generowicz <ja**************@cern.ch> writes:
Jacek> Ville Vainio <vi***@spammers.com> writes: Only the academics seem to think Scheme is easier to learn
than, say Python or even C. Students often disagree.
Jacek> Sounds great; I bet it makes a lot of Python fans feel warm
Jacek> and fuzzy inside. Unfortunately the claim is completely
Jacek> unfounded.
Jacek> You should take a look at what the TeachScheme people have
Jacek> been doing, and what they seem to be achieving.
I took a look at the TeachScheme website. One example program in
particular caught my eye in http://www.teach-scheme.org/Talks/.
the Scheme version:
( define ( guest name list )
( cond
( ( empty? list ) ?no )
( ( equal? name ( first list )) ?yes )
( else ( guest name ( rest list )) ) ))
C/C++:
------
#include <stdio.h>
typedef struct listCell * list;
struct listCell {
int first;
list rest;
};
bool guest (int x, list l) {
if (l == NULL)
return false;
else if (x == (l -> first))
return true;
else
return guest (x, l -> rest);
}
int main (int argc, char ** argv) {
list l1, l2, l3 = NULL; int x;
l1 = (list) malloc (sizeof (struct listCell));
l2 = (list) malloc (sizeof (struct listCell));
l2 -> first = 3; l2 -> rest = l3;
l1 -> first = 2; l1 -> rest = l2;
scanf ("%d", &x);
printf ("%d\n", member (x, l1));
}
----------
So they implement a linked list data type in C/C++ version, and use
the native/natural linked list (i.e. just a list) in Scheme. That's
kinda weasely road to take, don't you think? Especially if they use
this as marketing material for non-techies...
And here's the equally weaselish Python version, which they
unsurprisingly don't include:
-----------
def guest(name, list):
return name in list
-----------
I'd like to see an example program, targeted at, say, 12 year olds,
where Scheme beats Python in simplicity (one that is not a compiler,
mind you ;-).
--
Ville Vainio http://tinyurl.com/2prnb
Donn Cave <do**@drizzle.com> wrote: I haven't tried it, but Nice is a Java based language with a more
sophisticated type system than Java, and a few extra conveniences.
http://nice.sourceforge.net/
It doesn't appear to have type inference, which so far as I know
may be exclusive to functional languages, [...]
Just for the record, there's a dialect of C called Cyclone,
which supports type-inference (although with some limitations).
Since it's derived from C, it's not a functional language, but
it has grown quite some features typically found in functional
languages. http://www.eecs.harvard.edu/~greg/cyclone/index.html
There's a mirror at AT&T: http://www.research.att.com/projects/cyclone/
Best regards
Oliver
--
Oliver Fromme, Konrad-Celtis-Str. 72, 81369 Munich, Germany
``All that we see or seem is just a dream within a dream.''
(E. A. Poe)
Oliver Fromme wrote: Just for the record, there's a dialect of C called Cyclone,
which supports type-inference (although with some limitations).
Since it's derived from C, it's not a functional language, but
it has grown quite some features typically found in functional
languages.
http://www.eecs.harvard.edu/~greg/cyclone/index.html
Its extra pointer qualification features are interesting. Thanks for
bringing this to my attention, I don't think I'd heard of it before.
--
__ Erik Max Francis && ma*@alcyone.com && http://www.alcyone.com/max/
/ \ San Jose, CA, USA && 37 20 N 121 53 W && AIM erikmaxfrancis
\__/ If I had another face, do you think I'd wear this one?
-- Abraham Lincoln
On Mon, 05 Jul 2004 15:02:59 +0200, Peter Maas wrote: You mean the expression
"(set! x 10)" is_better_structured_as "x=10"
is true? How is is_better_structured_as defined? :)
def is_better_structured_than(a, b): # take Peter's suggestion
"Returns true if a is better structured than b."
if not equivalent(a, b):
raise ThatsNotFairError
return len(a) > len(b)
(It is the only logical interpretation of the statement since in any sane
parse tree of the two on some fair ground they are indistinguistable. If
you don't like this logic, Jacek, I recommend meditating on your knowledge
of computer science, not blaming me; I mean that first sentence quite
literally.)
Ville Vainio wrote: >> "Jacek" == Jacek Generowicz <ja**************@cern.ch> writes:
C/C++:
------
#include <stdio.h>
typedef struct listCell * list;
struct listCell {
int first;
list rest;
};
bool guest (int x, list l) {
if (l == NULL)
return false;
else if (x == (l -> first))
return true;
else
return guest (x, l -> rest);
}
int main (int argc, char ** argv) {
list l1, l2, l3 = NULL; int x;
l1 = (list) malloc (sizeof (struct listCell));
l2 = (list) malloc (sizeof (struct listCell));
l2 -> first = 3; l2 -> rest = l3;
l1 -> first = 2; l1 -> rest = l2;
scanf ("%d", &x);
printf ("%d\n", member (x, l1));
}
----------
Some people need to be shot ! This is not C or C++ code, it is C code and
considered very bad C++ code. No wonder that C++ get so much bad press with
such slander.
The *real* C++ version :
#include <list>
#include <string>
#include <algorithm>
using namespace std;
bool guest(string m, list<string> l)
{
return find(l.begin(),l.end(),m) != l.end();
}
// And now the testing code
#include <iostream>
void try_find(string m, list<string> l)
{
if(guest(m,l))
cout << "Found " << m << '\n';
else
cout << "Missing " << m << '\n';
}
int main()
{
list<string> l;
l.push_back("Hi");
l.push_back("There");
l.push_back("You");
try_find("Hi",l);
try_find("Yes",l);
try_find("You",l);
}
Thomas Reichelt a écrit :
(snip) Yes, type inference, for example, would be a great addition to Python! I
took a look at OCaml a while ago, but as I am not very addicted to pure
functional programming, it wasn't my thing.
<ot>
Err... OCaml is certainly not a 'pure'[1] fpl. It has support for
imperative and OO programming too (the 'O' is for 'Objective').
[1] at least according to the 'official' definition of 'pure functional
programming languages', which is (in short) that you can *never* change
the value of a variable.
</ot>
My 2 cents,
Bruno
Jacek Generowicz <ja**************@cern.ch> wrote: Ville Vainio <vi***@spammers.com> writes:
(set! x 10)
Is so much more readable than
x=10
Well, that rather depends on what you are used to. But it is
undeniably true that the former is better structured.
In the early days of pocket calculators, Texas Instruments had all
these RPN (reverse Polish notation) models. Now, many people argued
that computationally RPN made more sense. But the market has spoken
otherwise. No matter how much sense it may make in theory, in practice
the majority of people will NOT buy nor use a RPN calculator. Sure,
there are always going to be those that stick with RPN calculators and
praise their structuredness to no end.
In academia all this is fine and dandy. In business, igonoring
user-friendliness means... well, no business. RPN calculators are a
good example.
Trust me. Codeblocks, not Lisp/Scheme's PN expressions, are the way of
the future. It's very simple logic: people want machines to act more
like people, they don't want to be told to act more like machines.
Again, RPN calculators are a good example.
regards,
Hung Jung
On 05 Jul 2004 21:08:35 +0300, Ville Vainio <vi***@spammers.com>
wrote: I'd like to see an example program, targeted at, say, 12 year olds,
where Scheme beats Python in simplicity (one that is not a compiler,
mind you ;-).
The TeachScheme project is pretty explicit in targetting high school
and up, so targetting 12 year olds is not in its scope. Having a scope
seems to indicate that some thought has been given, or experimentation
done, about age appropriateness To me, a sign of maturity of
approach.
Wild claims are made about the age appropriate range of Python
learning, with next to nothing to back those claims.
That being said, I can certainly understand being turned off by some
of the Talk you cite.
A good deal of embedded hype, of its own.
Knowing that that kind of thing goes on around the TeachScheme project
is one reason I find it hard to fully embrace.
My own ideal would be an approach that probably did in the end center
around Python, but that was itself less hype ridden. Less glib use
of the word "Easy", for example. Age appropriatenss ideas based on ,
well, something.
Art hu********@yahoo.com (Hung Jung Lu) writes: In the early days of pocket calculators, Texas Instruments had all
these RPN (reverse Polish notation) models.
I don't think TI ever made any RPN calculators.
In academia all this is fine and dandy. In business, igonoring
user-friendliness means... well, no business. RPN calculators are a
good example.
Scientific users still often prefer RPN. Business users might prefer
algebraic to RPN, but for that matter they're likely to prefer Cobol
(or Java or whatever they call it now) over Python.
On 5 Jul 2004 12:59:17 -0700, hu********@yahoo.com (Hung Jung Lu)
wrote: In academia all this is fine and dandy. In business, igonoring
user-friendliness means... well, no business. RPN calculators are a
good example.
Academia and business have very different reasons for being, or
should.
Part of the problem here is in fact taking valid lessons learned in
HCI for - say - business users, and then making invalid assumptions as
to what those lessons mean in a learning process in an academic
setting.
We can't expect those who control the realm of the business interface
to help us make the distinction. We could more likely expect them to
help misdirect the process, with and without subtlety.
All of which relates back to why the word "easy" disturbs me so much.
I'm not sure a process which involves the goal of learning is ever the
easist way from here to there.
It is *easiest* not to learn programming at all. And one gets by with
that fine.
Art
>>>>> "Arthur" == Arthur <aj******@optonline.com> writes:
Arthur> On 05 Jul 2004 21:08:35 +0300, Ville Vainio <vi***@spammers.com>
Arthur> wrote:
Arthur> Wild claims are made about the age appropriate range of
Arthur> Python learning, with next to nothing to back those
Arthur> claims.
I would expect Python to be easier than the line numbered Basic
horrors that kids (including your truly) polluted their brains with
back in the eighties. The only problem is the lack of native language
(as in non-english) documentation. This should be easy to fix - some
pedagogic specialist write a simple tutorial that is short enough to
translate quickly, and people translate it.
After translating a tutorial, the next pedagogic step is to remove
that geforce card and Windows from the machine. The kids these days
are not dumber than earlier generations, they just have too much
entertainment that keeps them away from coding :-).
Arthur> My own ideal would be an approach that probably did in the
Arthur> end center around Python, but that was itself less hype
Arthur> ridden. Less glib use of the word "Easy", for example.
Into dull professionalism, are we ;-)? I bet the phenomenon you
observe is because many of us are not interested in education as such,
it's just awe-inspiring to imagine all the fun those kids could have
with Python, compared to POS languages we've had to use.
--
Ville Vainio http://tinyurl.com/2prnb
Ville Vainio <vi***@spammers.com> writes: I would expect Python to be easier than the line numbered Basic
horrors that kids (including your truly) polluted their brains with
back in the eighties.
I'm not really convinced of that, at least for the simplest types of
programming.
On Seg 05 Jul 2004 19:03, Ville Vainio wrote: After translating a tutorial, the next pedagogic step is to remove
that geforce card and Windows from the machine. The kids these days
are not dumber than earlier generations, they just have too much
entertainment that keeps them away from coding :-).
Hey! How are they going to code OpenGL stuff nicely if they don't have a
good video adapter to try it? ;-)
With regards to small tutorials there are some of them even in other
languages other than in English. Take a look at the python.org website and
you'll see non-English docs linked there --- and also in some of the
English documents...
--
Godoy. <go***@ieee.org>
On 06 Jul 2004 01:03:58 +0300, Ville Vainio <vi***@spammers.com>
wrote: After translating a tutorial, the next pedagogic step is to remove
that geforce card and Windows from the machine. The kids these days
are not dumber than earlier generations, they just have too much
entertainment that keeps them away from coding :-).
What they do on their own time ...
Certainly no Windows desktops allowed in school.
Though if the criteria is what's easiest, I probably lose my case.
Art This thread has been closed and replies have been disabled. Please start a new discussion. |
