What are the jewels of Scheme?
bobu...@yahoo.com
In Scheme
(if (or (and (>= n 0) (> d 0)) (and (< n 0) (> d 0)))
In Python
if ((n>=0 and d>0) or (n<d and d>0)):
Observations
1. Scheme takes 25% more characters then Python to express the
condition
2. When I wrote Python I started from then left and finished at right,
but when I wrote in Scheme I started in the middle and expanded
outwards. I had to use the mouse much more then when I wrote the Python
code
3. Maybe I'm brain damaged but it takes less time for me to see (and
understand) that the Python code is correct then to see that the Scheme
code is correct.
Don't misunderstand me I'm no advocate of Python nor of Scheme. I'm
just trying to compare and decide which language to invest time in.
Somebody said that the jewels of Scheme are hidden. I've looked at
Scheme a week or so and must admit that the statement is true because I
haven't yet discovered those jewels. But I'm sure that they are there
becuase I have high respect for people who invented and developed
Scheme. On the other hand the jewels of Python are not hidden, but very
visible. For instance introspection, metaclasses and native primitives
like lists, tuples and dictionaries .
I'm not interesting in war, I would just like to hear an honest opinion
of what the jewels of Scheme really are.
Bob
Jens Axel Søgaard
> Suppose tha n=-5 and d=-3. Is the condition after if true or false?
>
> In Scheme
> (if (or (and (>= n 0) (> d 0))
> (and (< n 0) (> d 0)))
>
> In Python
> if ((n>=0 and d>0) or (n<d and d>0)):
>
> Observations
> 1. Scheme takes 25% more characters then Python to express the
> condition
> 2. When I wrote Python I started from then left and finished at right,
> but when I wrote in Scheme I started in the middle and expanded
> outwards. I had to use the mouse much more then when I wrote the Python
> code
Don't use the mouse. Use an editor that makes it easy to move
back-and-forth betweem matching parentheses. E.g Alt+left-arrow and
Alt+right-arrow works in DrScheme.
> 3. Maybe I'm brain damaged but it takes less time for me to see (and
> understand) that the Python code is correct then to see that the Scheme
> code is correct.
I doubt they both are correct :-)
Anyways d>0 occurs twice it is simpler to write
(and (> d 0)
(or (>= n 0) (< n d))
Note that "<" and ">" is normally read "increasing" and "decreasing",
since you can write e.g. (< 1 x 3 y 7) .
> Don't misunderstand me I'm no advocate of Python nor of Scheme. I'm
> just trying to compare and decide which language to invest time in.
> Somebody said that the jewels of Scheme are hidden. I've looked at
> Scheme a week or so and must admit that the statement is true because I
> haven't yet discovered those jewels.
Where have your treasure hunt led you so far?
--
Jens Axel Søgaard
Nils M Holm
Using proper indentation makes this quite easy to read:
(if (or (and (>= n 0)
(> d 0))
(and (< n 0)
(> d 0)))
> Observations
> 1. Scheme takes 25% more characters then Python to express the
> condition
I am sure that APL uses much less characters than most languages,
but I am not sure about the implications of this fact.
> 3. Maybe I'm brain damaged but it takes less time for me to see (and
> understand) that the Python code is correct then to see that the Scheme
> code is correct.
See above. You may need some time to get used to Scheme syntax, but
it is worth the effort. An editor that matches parentheses definitely
helps.
> Somebody said that the jewels of Scheme are hidden. [...]
Here is an unordered list of some things that I like about Scheme
(I do not know much about Python, so I do not claim that Python
does not have them):
1. Lexical closures
2. Small size
3. Simple syntax
4. Clean design
5. Same notation for code and data
6. Symbols as data types
7. Bignum arithmetics
8. Lexical closures
IMO, Scheme is a great language for exploring algorithms.
--
Nils M Holm <n m h @ t 3 x . o r g> -- http://www.t3x.org/nmh/
Marcin 'Qrczak' Kowalczyk
> Suppose tha n=-5 and d=-3. Is the condition after if true or false?
>
> In Scheme
> (if (or (and (>= n 0) (> d 0)) (and (< n 0) (> d 0)))
>
> In Python
> if ((n>=0 and d>0) or (n<d and d>0)):
Which condition? The Scheme one has (< n 0) where the Python one has n<d.
Both are suspicious because d>0 is repeated. Why not to factorize it out?
> 1. Scheme takes 25% more characters then Python to express the
> condition
My Kogut is yet shorter:
if (n>=0 & d>0 | n<d & d>0)
--
__("< Marcin Kowalczyk
\__/ qrc...@knm.org.pl
^^ http://qrnik.knm.org.pl/~qrczak/
Björn Lindström
> (if (or (and (>= n 0) (> d 0)) (and (< n 0) (> d 0)))
>
> 1. Scheme takes 25% more characters then Python to express the
> condition
Then try not to type as many of them yourself. I like the paredit
pseudostructural editing mode for Emacs for this purpose.
http://mumble.net/~campbell/emacs/
> 2. When I wrote Python I started from then left and finished at right,
> but when I wrote in Scheme I started in the middle and expanded
> outwards. I had to use the mouse much more then when I wrote the
> Python code
The mouse!? Use an editor that allows you to move the cursor with the
keyboard. paredit also helps with this, but just inserting your
parenthesises with M-( in Emacs goes a long way.
> 3. Maybe I'm brain damaged but it takes less time for me to see (and
> understand) that the Python code is correct then to see that the
> Scheme code is correct.
Adding a newline makes that quite a bit clearer.
(if (or (and (>= n 0) (> d 0))
(and (< n 0) (> d 0))))
Add more to taste.
--
Björn Lindström <bk...@stp.lingfil.uu.se>
Student of computational linguistics, Uppsala University, Sweden
Bruce Lewis
> Suppose tha n=-5 and d=-3. Is the condition after if true or false?
>
> In Scheme
> (if (or (and (>= n 0) (> d 0)) (and (< n 0) (> d 0)))
>
> In Python
> if ((n>=0 and d>0) or (n<d and d>0)):
>
[...]
> 3. Maybe I'm brain damaged but it takes less time for me to see (and
> understand) that the Python code is correct then to see that the Scheme
> code is correct.
Neither is correct. The predicate in Scheme should be (positive? d) and
in Python (d>0).
Please try another example.
bobu...@yahoo.com
>2. Small size
>3. Simple syntax
>4. Clean design
>5. Same notation for code and data
>6. Symbols as data types
>7. Bignum arithmetics
>8. Lexical closures
Thanks Nils,
The list you provided above is the kind of thing I hoped to see.
1. Many languages have closures (including Python) according to
Wikipedia.
2 and 4. I agree. R5RS is only 50 pages. Scheme has roots in lambda
calculus (probably the smallest language in the world) created by a
mathematician (Church) which makes it probable that Scheme has sound
foundation.
3. This one bothers me. I feel that Scheme makes the job easy for
computers but hard for humans. Maybe I'm mistaken and that it's
something you must get accustomed to.
5. This is actally what made me start looking at Scheme!!
6. This one I don't understand could you please explain what you mean.
7. Bignums are cool if you need them. Many applications do not.
8. Same as 1.
Bob
Shiro Kawai
If you're using mouse when you edit code, probably Lisp-family language
isn't your choice. It still isn't your choice even if you're
cursor-key
oriented.
When I first saw a long-time Lisp programmer editing (and debugging)
his
code on Emacs it blowed my mind. His code was flying. Basically,
once you get used to, you won't work on (and think on) per-character
basis anymore. Instead, you work on per-expression. No matter how
complex the expression is, spanning many lines or nested so deeply,
you can treat the whole expression with a few keystrokes---e.g.
cutting an expr, skip next two exprs, paste the original expr, then
adjust the whole indentation; or sending a whole expression to
interactive
REPL and check the result; or factoring out a subexpression and turning
it into a local function. You get a feeling you are grabbing the code
itself, not the characters on the screen.
For your original question: probably it's easier to appreciate what's
special in Scheme by shifting your viewpoint from a language user
to a language designer---the former is to accept the language features
as given and unchangeable, and tries to write all the solutions in it;
while
the latter first look at the problem, think about what language is
suitable
to describe the problem, then write the language using the base
language.
One example: Python got list comprehensions recently. That's a cool
feature to have. You can write code more in a way you couldn't before.
Somebody posted a code in Scheme that implements list comprehensions
essentially in several lines. It's a joy to have that. And it has
always been
possible; you don't need to wait for somebody to add the feature.
Jonathan Bartlett
jewels of scheme is that any construct that doesn't exist can be
fashioned simply and easily from Scheme's feature set using closures,
continuations, and macros.
With Scheme macros, you have the ability to invent your own
domain-specific sublanguage easily and use that to simplify your coding
experience.
See:
http://www-128.ibm.com/developerworks/linux/library/l-metaprog1.html
Another jewel of Scheme that I don't think is available in Python is
tail-call elimination. See:
http://www-128.ibm.com/developerworks/linux/library/l-recurs.html
Jon
----
Learn to program using Linux assembly language
http://www.cafeshops.com/bartlettpublish.8640017
Jens Axel Søgaard
>>1. Lexical closures
> 1. Many languages have closures (including Python) according to
> Wikipedia.
It is a truth with modifications that Python has closures.
First of all the body of a Python closure needs to be an expression -
an arbitrary statement is not allowed.
Furthermore mutating variables in an outer scope is, well, problematic:
<http://mail.python.org/pipermail/python-list/2004-July/229478.html>
--
Jens Axel Søgaard
Jens Axel Søgaard
> 1. Lexical closures
> 2. Small size
> 3. Simple syntax
> 4. Clean design
> 5. Same notation for code and data
> 6. Symbols as data types
> 7. Bignum arithmetics
> 8. Lexical closures
9. A rich literature!
<http://library.readscheme.org/>
--
Jens Axel Søgaard
bobu...@yahoo.com
>Shiro Kawai wrote
> When I first saw a long-time Lisp programmer editing (and debugging)
> his code on Emacs it blowed my mind. His code was flying. Basically,
> once you get used to, you won't work on (and think on) per-character
> basis anymore. Instead, you work on per-expression.
This sounds wonderful. I would very much like to learn that myself.
I'm using Windows XP, is there some Tool like Emacs you've mention for
Windows. Right now (I'm using DrScheme with Windows XP)
> think about what language is suitable to describe the problem,
> then write the language using the base language.
You're right, this is the same as Jonathan Bartlett is saying below
about metalanguage, and also what impressed me in the SICP video
lectures. That is a real jewel.
Bob
Björn Lindström
> This sounds wonderful. I would very much like to learn that myself.
> I'm using Windows XP, is there some Tool like Emacs you've mention for
> Windows. Right now (I'm using DrScheme with Windows XP)
Yes, there is such a tool. It's called Emacs.
http://www.gnu.org/software/emacs/windows/ntemacs.html
Ulrich Hobelmann
> bobu...@yahoo.com writes:
>
>> This sounds wonderful. I would very much like to learn that myself.
>> I'm using Windows XP, is there some Tool like Emacs you've mention for
>> Windows. Right now (I'm using DrScheme with Windows XP)
>
> Yes, there is such a tool. It's called Emacs.
>
> http://www.gnu.org/software/emacs/windows/ntemacs.html
An interesting one is the Paredit minor mode
(http://mumble.net/~campbell/emacs/paredit.el). I've only tried it with
Common Lisp, but it should work with Scheme too.
Pressing the ( key opens a balanced set of ()s. Closing it with )
results in a line break and a reindent. Even characters like backspace
don't work as usual, but backspace inside or after a () deletes both
characters. It encourages you to cut&paste or type whole expressions,
so you always end up with balanced ()s in your code (shift-alt-left for
instance marks a whole expression to the left etc.).
--
the bottom line is that a JavaSchool that won't teach C and won't teach
Scheme is not really teaching computer science, either. -- Joel Spolsky
Nils M Holm
> >1. Lexical closures
> >2. Small size
> >3. Simple syntax
> >4. Clean design
> >5. Same notation for code and data
> >6. Symbols as data types
> >7. Bignum arithmetics
> >8. Lexical closures
>
>
> 3. This one bothers me. I feel that Scheme makes the job easy for
> computers but hard for humans. Maybe I'm mistaken and that it's
> something you must get accustomed to.
I feel that Scheme notation is quite nice for editing, but you
have to give up thinking in terms of "lines" and start thinking
in terms of "expressions".
Because I am using vi(1), I will give an example using vi (although
most people will probably tell you that this is not the right editor
for Scheme):
First include :set showmatch in your EXINIT variable. (I actually do
not do it, because it distracts my mental focus, but YMMV.) One of
the most important commands of vi is % which moves the cursor to a
matching parenthesis. Using this command, you can delete, copy, and
paste expressions. Here is an example. To write
(+ (some-function a b) (some-function c d))
you enter (vi commands in <>; y% copies everything between a paren
and a matching paren, p pastes copied text):
<i>(+ (some-function a b)<ESC><y><%><$><p><i> <ESC><A>)<ESC>
and then change "a b" to "c d" in the pasted sub-expression.
Another nice feature of vi is the ! command which pipes text to a
program. Just enter an expression, go to its opening paren, type
<!><%>scheme<ENTER> (where "scheme" is your Scheme interpreter),
and watch it being replaced with its normal form.
I am not going to tell you, or anybody else, to use vi. Other
editors certainly provide similar functions or even better ones.
What this demonstrates, though, is that even an editor that does
not support LISP (modern vi's do not even seem to have :set lisp)
can be used to edit Scheme in a comfortable way.
> 6. This one I don't understand could you please explain what you mean.
This is directly related to 5. In Scheme, symbols themselves are
first-class values, so you can write
(cons 'a 'b) => (a . b)
This is why you can decompose lists representing Scheme programs
and look at their components:
(car '(define (f x) (* x x))) => define
So this expression defines something, etc
I prefer symbols over other types in samples like the above, because
symbols are the most simple types. They cannot be decomposed (unless
you write your own EXPLODE function) and they do not have any values.
They just represent themselves and that's it.
> 8. Same as 1.
The alpha and the omega of Scheme. ;-)
Jonathan Bartlett
> First of all the body of a Python closure needs to be an expression -
> an arbitrary statement is not allowed.
Actually, that is only true for lambda closures. You can do more
general closures using default arguments. For example, see this code:
def make_counter():
start = 0
def count_func(current=[start]):
current[0] = current[0] + 1
return current[0]
return count_func
a = make_counter()
b = make_counter()
print a()
print b()
print b()
print b()
print a()
It's ugly, but it works.
MSCHAEF.COM
<bobu...@yahoo.com> wrote:
...
>>3. Simple syntax
...
>3. This one bothers me. I feel that Scheme makes the job easy for
>computers but hard for humans. Maybe I'm mistaken and that it's
>something you must get accustomed to.
I think Scheme makes the syntax hard for humans _at first_, since it's so
strange looking if you're expecting infix notation. Once you clear the
initial hurdle, things get much better; what's really happened is that the
strange looking syntax has changed the parse tree of your program from
being something that only the compiler sees to a blantantly visible,
user-land concept. In turn, that makes a lot of interesting things much
easier to do:
1. More powerful source code navigation
2. Source code transformations
3. Domain specific languages
Some of this stuff can also be done in infix languages: There's nothing
that precludes there from being a way to read/manipulate the syntax tree
of an infix language. A Java compiler could expose a parse tree API and
let the user plug in the equivalent of macros to extend the compiler: I
think python already does something like that. The problem is that, unlike
Scheme, this is another concept to learn and the barrier to entry is
higher: It's more difficult for the user.
-Mike
--
http://www.mschaef.com