schemers.org is back up
Shriram Krishnamurthi
both www.schemers.org and srfi.schemers.org should be functional. In
principle, this means all the SRFI discussion lists should work as
before. (It also means slacker authors, especially ones who have last
names beginning with `S' and hold PhDs from universities roughly named
for fruits (as opposed to grains), need to get their tails in gear.)
In practice, though, there has been a lot of software upgrading on
that machine, which means one or more things may not work. Please be
patient and, if you find things not functioning, send me a descriptive
email message!
Cheers,
Shriram
Olin Shivers
Newsgroups: comp.lang.scheme
Subject: schemers.org is back up
Date: 07 Jun 2000 14:02:56 -0500
The schemers.org machine should be up and running again. This means
both www.schemers.org and srfi.schemers.org should be functional. In
principle, this means all the SRFI discussion lists should work as
before. (It also means slacker authors, especially ones who have last
names beginning with `S' and hold PhDs from universities roughly named
for fruits (as opposed to grains), need to get their tails in gear.)
Oh, man, you are going to feel really bad when I tell you that while you've
been sitting around for the last few weeks trying to figure out how the SCSI
connector plugs into your disk drive, I have
- Massively rewritten the char-set SRFI source code;
- updated the spec to deal with Latin-1 and Unicode;
- brought the reference implementations for both SRFI 13 & 14 into compliance
with their specs;
- Commented the reference implementations in my usual voluminous style;
- Written a regression suite for SRFI 14;
- Written module specs for both SRFIs in the Scheme 48 module language,
with complete typings in the S48 type language;
- Rewritten & extended the LET-OPTIONAL arg-parsing macro.
Everything, all told, weighs in at about a quarter meg of text.
All this while
- Getting my PhD student's 423-page dissertation on logic proofread,
- pushing another pair of Master's students out the door,
- getting my startup company to code freeze for the initial product.
On the other hand... my girlfriend is threatening to leave me for reasons
of neglect. So you'll have to take the subject line of this post as, uh,
ironic at best.
-Dr. Olin Shivers,
Ph.D., Cranberry-Melon School of Cucumber Science
Olin Shivers
this seems to be an interesting line of information.
could you elaborate a bit? I suspect a commercial GambitC :)
The commercialisation of Gambit I leave to Uber-Gambit wizard Prof. Feeley.
I'm at a little company called Smartleaf that provides investment analytics
for investors -- tools that let you optimise your stock portfolio for
after-tax returns and stuff like that.
I feel obligated to confess that, while we prototyped the early financial
models & app server interfaces in Scheme, I'm moving the heavy compute
floating-point stuff into C (for obvious reasons), and the web stuff is
now in (say it, Olin) perl. It's a daily shame I endure.
I think one of my guys does the meta-thing of writing Scheme to write C...
By the way, I have for some years now been convinced that the single biggest
technical barrier to using scsh as a perl alternate is the fact that S48 has
been around for about 10 y and still provides no way to separately
byte-compile modules into loadable object files.
Speaking of stocks & startups & Scheme, there's a company in California
that does stock-market stuff on the Web using Scheme: Xigo. Even better:
they're in *downtown* San Francisco, not the hellhole of Silicon Valley...
-Olin
Shriram Krishnamurthi
> By the way, I have for some years now been convinced that the single biggest
> technical barrier to using scsh as a perl alternate is the fact that S48 has
> been around for about 10 y and still provides no way to separately
> byte-compile modules into loadable object files.
You've said this several times. Does Perl? Last I knew, programs in
Perl and Python and the rest were written like
#!/usr/local/bin/<executable> <random flags>
<random syntax>
Have they gotten their acts together on compilation?
What about Scheme 48 heaps? And would you be happy with something
like .elc?
'shriram
Daniel C. Wang
Shriram Krishnamurthi <shr...@cs.rice.edu> writes:
{stuff deleted}
> You've said this several times. Does Perl? Last I knew, programs in
> Perl and Python and the rest were written like
>
> #!/usr/local/bin/<executable> <random flags>
>
> <random syntax>
>
> Have they gotten their acts together on compilation?
Python compiles to bytcode (.pyc) and can dump .pyc files to a ugly C
string, already. There's also a variant that compiles to Java bytecode. The
ironic thing about the Java bytecode compilers is that even with a JIT the
current Python interpreter is still faster than JIT compiled translated
Python.
Rumors have it that there is a working Perl bytecode compiler that will make
it out in some newer revision of Perl, which should also include the Perl C
compiler. I've seen prototypes of the Perl stuff that's at least a year old,
but haven't heard about any recent progress.
Reini Urban
> From: rur...@x-ray.at (Reini Urban)
> this seems to be an interesting line of information.
> could you elaborate a bit? I suspect a commercial GambitC :)
>
>The commercialisation of Gambit I leave to Uber-Gambit wizard Prof. Feeley.
oops. mixed up "feeley" with "shivers". sorry to both.
--
Reini Urban
http://xarch.tu-graz.ac.at/autocad/news/faq/autolisp.html
Reini Urban
>Rumors have it that there is a working Perl bytecode compiler that will make
>it out in some newer revision of Perl, which should also include the Perl C
>compiler. I've seen prototypes of the Perl stuff that's at least a year old,
>but haven't heard about any recent progress.
recent progress was that processing perl bytecode is actually much
slower than processing perl sourcecode. mostly the IO overhead. gzipping
it might be a solution.
strange because I always thought that bytecode will be smaller then
binaries and most of the time than soucecode as well. not so in perl.
(300+K vs 80K in one example)
http://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/2000-05/msg01109.html
the perl C compiler is seriously flawed. (imho)
maybe with a LOT of manual tweaks it will make it someday, but
dynaloading is still unsolved.
brl...@sperience.com
> and the web stuff is
> now in (say it, Olin) perl. It's a daily shame I endure.
Have you done any benchmarking of BRL? I haven't yet, as it's been more
than fast enough for "Intranet" apps. Pages are compiled to Java
bytecodes on the first invocation and when the code is modified, but
subsequent invocations are quite fast. (I still have work to do on
initial startup speed.)
If there's some functionality missing or undocumented, I'd be
interested in knowing what that is.
--
(for-each (lambda (str) (display (string-append (make-string (- 40
(quotient (string-length str) 2)) #\space) str)) (newline)) '(""
"Bruce Lewis" "MIT 1990" " http://brl.sourceforge.net/
"))
Tim Bradshaw
> By the way, I have for some years now been convinced that the single biggest
> technical barrier to using scsh as a perl alternate is the fact that S48 has
> been around for about 10 y and still provides no way to separately
> byte-compile modules into loadable object files.
I disagree with this. Perl doesn't standardly do this, and it's
reasonably usable. The biggest problems I have with scsh is that it
takes for ever to start (about 10x as long as perl, and twice as long
long as CMUCL on my machine). This might be curable by compiling, but
that isn't the only cure, witness perl.
--tim
Tim Bradshaw
Rob Warnock
+---------------
| Speaking of stocks & startups & Scheme, there's a company in California
| that does stock-market stuff on the Web using Scheme: Xigo. Even better:
| they're in *downtown* San Francisco, not the hellhole of Silicon Valley...
Yup. A friend of mine works there. (Last time I checked,
they were still hiring, if anyone's interested...)
-Rob
-----
Rob Warnock, 41L-955 rp...@sgi.com
Applied Networking http://reality.sgi.com/rpw3/
Silicon Graphics, Inc. Phone: 650-933-1673
1600 Amphitheatre Pkwy. PP-ASEL-IA
Mountain View, CA 94043
![Michael Sperber [Mr. Preprocessor]'s profile photo](http://lh3.googleusercontent.com/a-/ALV-UjW1Ug-7D5rvPAe0Dy8QWlBwdoMp8sHWFACGdNTzwJ9mF7CkTQ=s40-c)
Michael Sperber [Mr. Preprocessor]
Olin> I feel obligated to confess that, while we prototyped the early financial
Olin> models & app server interfaces in Scheme, I'm moving the heavy compute
Olin> floating-point stuff into C (for obvious reasons), and the web stuff is
Olin> now in (say it, Olin) perl. It's a daily shame I endure.
Have you considered that you might secretly crave shame and
humiliation? Your secret life is coming to the surface. Maybe it's
something psychosomatic? Or maybe it's a purely physical disorder
that's influencing your programming style to favor Perl? On the other
hand, maybe it's just some male-macho-cowboy thing.
Anyway, until we have a sworn statement as to your mental health, in
the hallways of this department (where formerly you were "Dr.S"),
you're now "Tr.S" (for "Traitor Shivers"). Think about it. Seek
help. Talk to someone. Turn in your Sig-Sauer before it's too late.
Don't kill us. We're all children under the same sun. Please.
--
Cheers =8-} Mike
Friede, Völkerverständigung und überhaupt blabla
PS: Over the years we've converted a number of (web and other) apps
from Perl to scsh, and found a uniform increase in performance and
decrease in code size and complexity. It's hard to beat Perl for
bloat and slowness.
Shriram Krishnamurthi
> Have you considered that you might secretly crave shame and
> humiliation?
I fear it might be something very much more insidious, Mike. Remember
what Charlie Daniels wrote about the time Johnny went down to Johjuh?
Oh sure, it ended differently in the song, but that's entertainment
for you, all uplifting and conceited; but we're talking Fleisch und
Blut here, my friend.
> Your secret life is coming to the surface. Maybe it's
> something psychosomatic? Or maybe it's a purely physical disorder
> that's influencing your programming style to favor Perl? On the other
> hand, maybe it's just some male-macho-cowboy thing.
Time to pull out the old classic sociological tome (F. King, of
course). Anyone notice how Tr. S's been approaching barstools lately?
'shriram
Olin Shivers
Subject: Re: My company
References: <j7vbt1d...@sun.cs.rice.edu> <qij4s73...@ernie.ai.mit.edu> <3944d083.335570504@news> <qijhfaxnk...@ernie.ai.mit.edu> <y9ln1km...@informatik.uni-tuebingen.de> <j7vem5x...@sun.cs.rice.edu>
--text follows this line--
> Have you considered that you might secretly crave shame and
> humiliation?
Between the students I teach and the VC's I hustle for investment, I've
got the shame & humiliation thing covered, thank you.
> Time to pull out the old classic sociological tome (F. King, of
> course).
Speaking of which, now would be a good time to clue in the unenlightened:
Shriram is referring to Florence King's *Southern Ladies and Gentlemen*. An
amazing, classic work. Florence understands and describes Southern culture
as well as Neal Stephenson understands and describes hacker culture. Her
book is hilarious. People not of the South will think it is extreme &
exaggerated for comic effect, so they miss the most amusing part: it is
factual and accurate. I personally know living instantiations of every
bizarre character she describes. Shriram, who has paid his dues down South,
can back me up on this.
SL&G was out of print for years; it was a book all long-term Southerners
owned, but would not lend out. It has recently been reprinted. I recommend it.
As for the Great State of Georgia, please bear in mind that while the
license plates declare Georgia to be "the peach state," anyone with a
background in AI will properly recognise Georgia as "the goal state."
Lest we wander too far from the newsgroup topic, I'll simply add that
the Georgia/Scheme connection is about to get a lot stronger. Those
considering graduate-student careers in programming language research
may wish to keep this in mind.
-Dr. S
Bradley J Lucier
Since no-one else has taken you to task for the other reason
you don't use Scheme (something like "of course we moved
the numerics to C", the original article has expired on my
machine), allow me to do so.
Last semester I used Gambit-C + Meroon to develop the programs
for my class "Numerical Methods in Partial Differential Equations."
The URL is
http://www.math.purdue.edu/~lucier/615
The system we developed is competitive with systems written in
C. (All the low-level routines where almost all the numerics
are done are limited by memory-bandwidth for both Scheme and C.)
We achieve about 60 Mflops for multigrid on a 500 MHz Alpha 21264.
Now I'm working on processing function MRI data-sets, each
about 40 Mbytes in size. In the latest tests, I get about
120 Mflops on the same machine for a partial complex
wavelet transform of the data.
So I no longer program in C.
Brad Lucier
jor...@greenapple.com
Olin Shivers <shi...@ernie.ai.mit.edu> wrote:
>
> [snip]
>
> I feel obligated to confess that, while we prototyped the early
financial
is
>
C...
>
biggest
> technical barrier to using scsh as a perl alternate is the fact that
S48 has
> been around for about 10 y and still provides no way to separately
> byte-compile modules into loadable object files.
>
> -Olin
>
I find it more than a little ironic that Olin is now
using Perl in his venture (he admits it's a great shame)
and, on the other hand, a long-time Perl guru has recently
begun to separate himself from the Perl community because
Perl does not, in his opinion, have the attributes of a
"good programming language", even calling it unusable.
The Perl guru, Ilya Zakharevic, says it better than I
could (quoting article message-id
<8f498v$751$1...@charm.magnus.acs.ohio-state.edu>
written on May 5th, 2000, posted on comp.lang.perl.misc):
>[A complimentary Cc of this posting was sent to Larry Rosler
><l...@hpl.hp.com>],
>who wrote in article <MPG.137e5a574...@nntp.hpl.hp.com>:
>> I am troubled by your philosophy of abstention from directing the
>> attention of Perl implementors toward reliability as opposed to new
>> features.
>
> I was puzzled by this attitude of Perl users for a long time. Until I
> lost any faith in that Tom knows what he writes about.
>
> Let me reiterate my current opinion on the topic: the reason for my
> puzzlement (and your trouble) is the difference between Perl as a
> scripting language and Perl as a programming language. Perl is
> absolutely fine as a scripting language. Perl is pretty unusable as a
> programming language.
>
> Thus people who use Perl "in scripting mode" do not care about bugs,
> ambiguities and undoc behaviour: they just experiment with their
> scripts until they think the scripts do what they want. The design of
> Perl makes such experiments a kind of fun in itself, and the
> understanding that this is not how things are supposed to be
> programmed is drowned in all this fun.
>
> And the ubiquitous false advertisements that Perl is a "programming
> language" creates a warm fuzzy feeling that all this fun of
> experimenting *is* programming. Hence that
>
> Programming Perl is fun!
>
> slogan. Additionally, for a lot of tasks the "scripting mode" is
> quite justifiable: the result may be easily controllable/undone, so
> that if things go wrong, you just try again. Or the problem to solve
> is so simple, that your experiments (plentiful because it is so hard
> to write correct Perl on the first try) have a good chance to cover
> most of the cases your script is going to be used in.
>
> Summary: now I'm not so puzzled as before. ;-)
>
> Ilya
I don't follow the world of high level Perl gurus very
closely, but I gather that Mr. Zakharevic knows of which
he speaks. Mr. Zakharevic wrote the portable malloc()
implementation used in Perl (if you select to build it
not using the "native" malloc) which generally greatly
outperforms those implementations found in C run-time
libraries. He's been a "Perl Porter" for many years.
Mr. Zakharevic has summed up some observations that I've
had recently concerning Perl. I found it interesting
that while Y2K passed with few incidents, the gross
majority of problems _I personally_ saw were 19100 dates
from Perl scripts on web pages.
I do a fair amount of Perl programming, because it's
expedient. But, when I put these things into production,
I do experience intermittent and difficult-to-diagnose
failures.
I want something better. Which has led me back to looking
at Scheme as a Programming Language. A Programming Language
that is also good for scripting. I believe this is one of
the primary goals of the Scsh project, if I'm not mistaken.
I'm looking at the PLT family now. I don't have the reference
with me now, but I believe it was Wirth who said in the original
_Pascal User Manual and Report_ that Pascal was not just a
pedagogical language. He went on to explain that a good
teaching language would necessarily have to include all of
the attributes of a practical real-world programming language.
I'll not comment on the success of the original Pascal language
definition as a real-world programming language.
It appears to me that the MzScheme has the necessary portability
and power to succeed in the "real-world", while maintaining a
spare feature set at base so as to not incur the problems that
Perl has had with maintenance (as Mr. Zakharevic says "bugs,
ambiguities and undoc behavior").
If I am to take up Scheme as a programming language/scripting
language, I think it's probably a good idea to focus on one
implementation, like MzScheme, at this time. Perhaps in the
future, some RnRS will nail down the necessary "real-world"
features set such that these will be dictated to all implementors
and there'll be less need to focus efforts on a single
implementation. Or perhaps that is not the point of RnRS, but
rather the SRFI process. In any case, today I believe it's most
productive to focus on a single, highly portable (if possible)
implementation, like the PLT set.
Getting back to the practical matters which informed
Olin's venture's move to Perl as an implementation language.
I am a working "programmer". I do earn a living at it. Perl,
C++, Java, etc. are "hot" skills, while Scheme may not be. I may
find myself in a position of competing with the many Scheme
educated graduates coming up, should TeachSheme! be successful.
Of course, if I can't compete, maybe I should move into something
else, but... Here's a question: Do people here see it as reasonable
to assume that Scheme experience and the development of a personal
toolkit would further my professional goals? Or, would it be a
distraction from honing skills in "hot" languages and systems?
Is this really a false dichotomy that I'm presenting? Either go with
the popular languages or Scheme? Although I can't speak from
experience, I think I would find, like Olin's people did, that it
would be relatively easy to prototype in Scheme and move to another
language as needed.
Thanks for reading my ramblings.
-Jordan Henderson
jor...@greenapple.com
Sent via Deja.com http://www.deja.com/
Before you buy.
John M. Adams
> Do people here see it as reasonable to assume that Scheme experience
> and the development of a personal toolkit would further my
> professional goals? Or, would it be a distraction from honing
> skills in "hot" languages and systems?
Yes.
Don't ignore the hot stuff. Do be informed. But bear in mind that he
who spends all his time on the hot stuff is by definition a follower.
Learn what seems powerful to YOU. Think up something interesting to
do with what you learned. Develop your own unique perspective that
way. That's the sort of outlook that will eventually impress the
right people, whoever they may be in your case.
So, if you had the thought to work with scheme. You'd better give it
a try. It wasn't a random thought. Unless you are desperate for food
and shelter, nothing that "most" people are doing with "hot" stuff
should dissuade you.
--
John M. Adams
Amit Patel
|
| Getting back to the practical matters which informed
| Olin's venture's move to Perl as an implementation language.
| I am a working "programmer". I do earn a living at it. Perl,
| C++, Java, etc. are "hot" skills, while Scheme may not be. I may
| find myself in a position of competing with the many Scheme
| educated graduates coming up, should TeachSheme! be successful.
| Of course, if I can't compete, maybe I should move into something
| else, but... Here's a question: Do people here see it as reasonable
| to assume that Scheme experience and the development of a personal
| toolkit would further my professional goals? Or, would it be a
| distraction from honing skills in "hot" languages and systems?
|
| Is this really a false dichotomy that I'm presenting? Either go with
| the popular languages or Scheme? Although I can't speak from
| experience, I think I would find, like Olin's people did, that it
| would be relatively easy to prototype in Scheme and move to another
| language as needed.
|
Learn both. Even though I don't actually use Scheme at work, I still
rely on the things I learned from Scheme when I'm programming in other
langauges.
- Amit
--
--
Amit J Patel, Computer Science Department, Stanford University
http://www-cs-students.stanford.edu/~amitp/