why scheme over perl or python?
gavino
Pascal Bourguignon
> why?
If you have to ask it, then you can't afford the answer.
--
__Pascal Bourguignon__ http://www.informatimago.com/
"You question the worthiness of my code? I should kill you where you
stand!"
Robert FISHER
> why?
Irrational non-conformism?
I guess what it basically comes down to is that every time I read about
Python, I didn't find anything that makes me think, "I have to try that
language!"
Yet, just about every time I read about Scheme, I found things that made
me think, "I have to try that language!"
--
Robert FISHER
http://robert.infogami.com/
Email sent to the address in the header is presumed spam.
I apologize for any inconvenience.
Emilio Lopes
> "gavino" <boot...@yahoo.com> writes:
>> why?
> If you have to ask it, then you can't afford the answer.
Absolutely :-).
To the OP: stop to theorise about Scheme and solve a problem with it!
But since you asked for a reason:
If you give someone Fortran, he has Fortran. If you give someone
Lisp, he has any language he pleases.
- Guy L. Steele
In which other language can you mix Prolog with CML (Concurrent ML) to
solve your problem in a way that YOU judge the best?
[1] http://kanren.sourceforge.net/
[2] http://s48.org/1.3/manual/manual-Z-H-8.html#node_sec_6.8
--
Emílio C. Lopes
Munich, Germany
Brandon J. Van Every
gavino wrote:
> why?
Perl and Python are slow languages. This is acceptable for some
problem domains, and a nuisance for others. I'm primarily interested
in 3D graphics, AI, and game development. There are good open source
compiled Schemes available, such as Chicken Scheme.
htttp://www.call-with-current-continuation.org .
For my problems, I prefer to get High Level Language features such as
garbage collection, some kind of macros and syntax rewriteability,
lists and trees as fundamental data structures, etc. and not have to
pay a big performance penalty for those features. This leaves a short
list of functional programming languages such as OCaml, Clean, various
Schemes, and various Common Lisps. Of these, I eventually went for the
languages with the best Windows support that were open source. Also C
FFIs are important to me, and I found OCaml's a bit tacky. Bigloo
Scheme and Chicken Scheme both have excellent C FFIs, being Scheme-to-C
compilers. That I ended up on Chicken Scheme might be considered
historical accident compared to Bigloo, but Chicken does have a
slightly larger community.
I think your question is better asked as, "Why a particular language
implementation over perl or python?" All language implementations are
not created equal on all platforms.
If I were doing web stuff I'd use either Python or Ruby. I do not see
anything compelling about Perl, and I've never heard anyone utter
anything but unpleasantries about PhP.
Cheers,
Brandon Van Every
Edu
gavino escreveu:
> why?
You know, Perl and Python have a few tools for symbolic computation.
Lisp and Scheme have a lot of tools for symbolic computation. However,
Lisp and Scheme have one tool that no other language has: Both
languages show a syntax that are very easy to deal with. Since the most
difficult problems in computer science arises from processing complex
syntactic structures, Scheme and Lisp are hard to beat. I will give
you an example. An engineer had a data cloud with about 1000000 points.
These points were represented as large integers, and our problem was to
read them, transform them into double float, and Marshal them. You
could say that this is the ideal problem for Perl and Python. However,
both languages don't have powerful compilers, and cannot deal with
structures as large as the data cloud of the example. I thought about
OCAML, but the size of the problem put the compiler on its kneels.
Then I tried Bigloo. I added an open parenthesis at beginning of the
file, a close parentheses at the end, opened the file, and read
everything with a single command:
(let ((pin (open-input-port "myfile.txt")))
(process (read pin)) )
A few lines were enough to add the double format, Marshal everything,
and output the solution. The star of the night was the command (read
pint)... This command was possible because Scheme can read, write, and
process lists (even gigantic lists) so easily. By the way, Python and
Perl are very slow... and have a nasty syntax. Conclusion: Scheme over
Perl because Schem has a nice syntax, easy to learn, easy to process,
easy to read, easy to write, easy to store.
Edu
Shriram Krishnamurthi
>
> Perl and Python are slow languages.
The phrase "X is a slow language" is nonsensical. Languages are
neither slow nor fast, only their implementations are, and even those
only in very coarse terms (because it is individual programs that are
slow or fast, and even that dependent on the input).
> I'm primarily interested
> in 3D graphics, AI, and game development. There are good open source
> compiled Schemes available, such as Chicken Scheme.
> htttp://www.call-with-current-continuation.org .
What 3d-graphical games with AI have you written with Chicken?
Shriram
Robert FISHER
> Languages are
> neither slow nor fast, only their implementations are
Ah, but with Perl & Python & their ilk, there's often little difference
between the language & the implementation.
Not to take anything away from your excellent point, though.
allen_caned
A non-higenic-macros and good recursion suport are 2 resons to go
scheme. terser than common lisp wich i also like. and get
mit-gnu-scheme they have non higenic macros, wich are more powerful but
more dangerous than higenic-macros. the only reson not to go with
scheme is because of the way the standard is witch is tiny, and with to
much vender difrences
Förster vom Silberwald
gavino wrote:
> why?
Perl and Python share trillions of useful libraries and people like it.
However, Scheme shares trillions of sex-appeal and I like it.
Schneewittchen
Förster vom Silberwald
> You
> could say that this is the ideal problem for Perl and Python. However,
> both languages don't have powerful compilers, and cannot deal with
> structures as large as the data cloud of the example. I thought about
> OCAML, but the size of the problem put the compiler on its kneels.
You are kdding right? Could you be more specific on that particular
probelm? I am no OCaml fan but somewhat sceptical about your
experience.
> Then I tried Bigloo. I added an open parenthesis at beginning of the
> file, a close parentheses at the end, opened the file, and read
> everything with a single command:
>
> (let ((pin (open-input-port "myfile.txt")))
> (process (read pin)) )
I use Bigloo every day and I am pleased to read this. But still I
cannot believe it that OCaml failed on your problem.
Have you posted your experience on the Ocaml mailing list? I would have
liked to read the thread.
Thanks,
Schneewittchen
Brandon J. Van Every
None! I just spent the past 9 months getting Chicken to build reliably
under CMake. So now MinGW is well supported, that was the main goal.
Plus I get VC++ and Cygwin with the same build system almost for free.
Now I'm moving on to OpenGL support problems, but as often happens, I
have to go replenish the money pump somehow. A sad thing about open
source is it doesn't pay my grocery bills. It's a problem, and I'm
unsure of the solution.
Cheers,
Brandon Van Every
Brandon J. Van Every
Shriram Krishnamurthi wrote:
> Brandon J. Van Every wrote:
> >
> > Perl and Python are slow languages.
>
> The phrase "X is a slow language" is nonsensical. Languages are
> neither slow nor fast, only their implementations are, and even those
> only in very coarse terms (because it is individual programs that are
> slow or fast, and even that dependent on the input).
Actually, since we're playing the fun CS game of splitting hairs,
languages can indeed constrain performance, to the point that no
implementation can surpass a certain performance threshold in practice.
Such is Python. It's been several years and I've heard of a lot of
"faster Python" projects, and as far as I'm aware, none have turned
Python into a speed demon. For all I know it could be a mere
implementation issue, that 1 guy working on an optimization project
isn't enough engineering chutzpah to really make a big difference. Or
it could be, as some have alleged, that Python has certain semantics
that get in the way of performance.
I haven't really studied the problem closely. 1 year ago I was
worrying about compiler design. I ended up throwing up my hands at all
the esoterica, and concentrated on just getting Chicken to build
reliably on Windows. I figured after I got it built, I could optimize
it if it was lacking somehow. Since it is BSD licensed, I could even
use it as the basis for my own compiler someday, if I was so inclined.
It's also reasonable to say that some languages will retard performance
for some problem domains. Lazy evaluation languages are a good example
of that. For some problems, it's a win; for others, it's a loss. When
attacking problems in a declarative style, you can spend so much time
guessing about what's going on "under the hood" and trying to
anticipate it, that it's not worth it.
Cheers,
Brandon Van Every
Pierpaolo BERNARDI
Sexpr-appeal, you mean?
Cheers
P.
gavino
Interesting. Can web site publishing be considered a expert system?
Jens Axel Søgaard
> Interesting. Can web site publishing be considered a expert system?
<http://en.wikipedia.org/wiki/Expert_system>
--
Jens Axel Søgaard
gavino
gnu scheme has the full macros of CL? what! where is paul graham to
comment!
jason.o...@gmail.com
> An engineer had a data cloud with about 1000000 points.
> These points were represented as large integers, and our problem was to
> read them, transform them into double float, and Marshal them. You
> could say that this is the ideal problem for Perl and Python. However,
> both languages don't have powerful compilers, and cannot deal with
> structures as large as the data cloud of the example.
I'm guessing this is a troll. In Python, you would just write:
process(map(float, open(filename).read().split()))
...unless I'm missing something. A million floats fits pretty
comfortably in memory these days.
-j
gavino
liek prevayler?
Danny Milosavljevic
On Tue, 08 Aug 2006 12:48:05 -0700, Brandon J. Van Every wrote:
> Shriram Krishnamurthi wrote:
>> Brandon J. Van Every wrote:
>> >
>> > Perl and Python are slow languages.
>>
>> The phrase "X is a slow language" is nonsensical. Languages are
>> neither slow nor fast, only their implementations are, and even those
>> only in very coarse terms (because it is individual programs that are
>> slow or fast, and even that dependent on the input).
>
> Actually, since we're playing the fun CS game of splitting hairs,
> languages can indeed constrain performance, to the point that no
> implementation can surpass a certain performance threshold in practice.
> Such is Python. It's been several years and I've heard of a lot of
> "faster Python" projects, and as far as I'm aware, none have turned
> Python into a speed demon. For all I know it could be a mere
> implementation issue, that 1 guy working on an optimization project
> isn't enough engineering chutzpah to really make a big difference. Or
> it could be, as some have alleged, that Python has certain semantics
> that get in the way of performance.
Probably. But see
http://sourceforge.net/projects/shedskin/
for a python-to-C++ converter.
>[...]
cheers,
Danny
Jens Axel Søgaard
> Probably. But see
> http://sourceforge.net/projects/shedskin/
> for a python-to-C++ converter.
Shed Skin is an experimental Python-to-C++ compiler. It can convert
pure, but implicitly statically typed Python programs into optimized
C++ code. Currently, these programs cannot freely use the Python
standard library.
Only pure programs?
--
Jens Axel Søgaard