From: ······@exploited.barmy.army
Subject: Re: "Programming is FUN again" rambling commentary
Date:
Message-ID: <6e65bn$ohb$1@Masala.CC.UH.EDU>
In article <···················@typhoon.texas.net>,
Dan Higdon <····@charybdis.com> wrote:
>······@exploited.barmy.army wrote in message
[Snip]
>>And I can't blame them. I'd happily program in FORTH or Scheme
>>or Common Lisp or Haskell or a billion other languages (including
>>Ada) over C or C++ any day.
>
>I'd happily chose SML (or scheme) over C/C++ any day of the week if
>I could. However, realtime 3D simulations that have to target common
>home computers really can't afford that luxury. C/C++ is your
>only real choice. For me, speed is the PRIMARY concern, with
>OS integration a close second.
>
Well at work I'm restricted by something a little more down to
earth. They use C/C++/Fart-ran (misspelling intentional),
so I'm stuck using them. At home, Lisp does everything
I want it to do with perfectly acceptable performance so
I don't have to stain my hands over there.
>>90% of the satisfaction I get from writing a program is in
>>seeing it run and using it.
>
>For me, 75% of my satisfaction comes from knowing that I've
>come up with a valid and sensible (in time and space)
>solution to the problem. The other 25% is watching it
>run. I guess that's why I love scheme so much - it really
>lends itself to algorithmic tweaking. Forth (my previous
>favorite) is the same way, but I feel that Forth has been
>left behind. It was great on 8-bit micros, but is a little
>"embedded" feeling for modern systems, IMHO.
Hmmmm good point, maybe I should revise my "90%" figure :)
>
>>Amen. For Lisp, there's more, like the fact that I've got a
>>very powerful, very flexible, very dynamic language that
>>will let me do things I could never dream of doing in
>>other languages. Add to that the incredible power and
>>simplicity of the list, and it's not hard to see the
>>tremendous appeal Lisp has.
>
>Yes, I agree (substituting scheme for lisp - I find lisp's
>symbol value/function dichotomy annoying).
Scheme IS Lisp. It's a dialect of Lisp. You are confusing
a family of languages (Lisp) with specific implementations
(like Common Lisp). I understand what you are trying to say,
but you should be more specific to avoid confusion.
> Add to that
>SML's rabid typechecking (if it compiles, chances are it
>will do what you want first time), and THAT's a fun
>programming system. I haven't had the chance to really
>hammer DrScheme's "Mr.Spidey" utility, but I suspect I
>would really appreciate that sort of analysis as well.
>
Have you by any chance tried Haskell? That has some serious
type checking and type inferencing, and IMO a nicer syntax
than the ML family of languages. It is purely functional
so when you get to IO you'll have to deal with monads, but
it's a great language and also tons of fun.
[Snip]
>>Yeah, nothing beats not having to worry about segmentation
>>violations, and being able to actually treat all data as
>>first class members (a simple task that C is too braindead
>>to let you do).
>
>I really don't like being put in the position to defend C, but this C
>bashing
>is getting a little out of hand.
It isn't bashing, it's a statement of fact.
>
>I take it you've never programmed in any sort of assembly language?
Yes I have. I've programmed in VAX PDP-11, x86 and 65xx
(C64 in particular -- 6510) assembly languages.
>There is a very zen-like enjoyment you can get from writing to the
>bare metal. You get exactly what you ask for, no more, no less.
>If you've never tried it, you probably won't understand. It's a very
>similar rush to what Forth gives you. C is like that as well.
I can understand the thrill of programming to the bare metal,
but C does NOT give me that thrill. C is low level enough
to make even the most trivial problems a pain in the neck,
but high level enough that you don't get the thrill of
programming to the bare metal.
>Sure, it's got a list of problems a mile long, and C++ has become
>a travesty of languages (especially the new ANSI spec - shudder),
>but straight, classic ANSI-C is enjoyable in its own right. But
>I can't stand those obfuscation nuts either - bad programming
>is bad programming, no matter what you call it.
Well I see nothing enjoyable or even worthwhile in C, so I guess
we'll just have to agree to disagree.
>
>>Right. Don't forget the interactive design. You can design
>>and test functions on the fly, without the compile/run/link/debug
>>cycle. I spent almost no time debugging Lisp programs. I
>>develop them in pieces as I go along, using very high level
>>abstractions to produce reliable modules.
>
>Interactive design is a MAJOR strength of lisp/scheme/sml.
>I can't even guess how many hours of my life I could have
>saved if C++ had a simple interactive testing environment.
>
Yes, that feature alone would seriously make life easier,
even in C/C++. It's especially agonizing when you take
a LONG time to compile (where I work, compilation times of
15 - 30 minutes are not unusual).
I remember reading about a C interpreter a LONG time ago.
It may have been a sort of garage project in somebody's
spare time, but I thought you'd be interested in knowing
that there may have been such a beast somewhere :).
>>In the time it takes me to write a trivial C program, I could
>>write 10 non-trivial Lisp ones and be well into my 11th. And
>>they'd work more reliably, be more flexible, and be more
>>maintainable too.
>
>That's because you're probably not very good at C. :-)
Actually, I know C better than I know Scheme, Lisp, or Haskell,
yet I can do better using the latter 3 languages.
>But all exaggeration aside, I'm sure that's largely true. Remember
>C is really a platform independed assember with limited block
>structuring. As such, it's designed to give you direct access to
>machine operations. So it's not really fair to compare with lisp.
>Just as a hunch, I'd guess that a GIF decoder would be easier to
>express in C than in Lisp, and would run much faster. Of course,
>an A* search algorithm would have the exact opposite property.
Comparing C and Lisp is fair, since both are general purpose
languages. Just because C is a portable psuedo-assembler
does not make it immune from comparison or criticism. We're
talking about getting the job done, and intentions mean nothing now,
only results.
As for a GIF decoder, since I'm not sure what the algorithm
is (I suppose I could find out), I can't say whether or not
C would be better at it than Lisp. A* search I do know and
agree with however.
[Snip]
>That's pretty close. Forth also lets you define new compiling words
>(similar to macros in scheme), and the syntax can lend itself to some very
>simple and intuitive usages.
The one thing that got to me about Forth (and this may be due to my
own ignorance of the language at the time) was the inability to
get at any data lower than 3 levels down on the stack without
popping everything before it off. Things like rotate and swap
let me re-arrange stuff 3 levels deep, but after that I found
myself scratching my head. It's very possible that I wasn't
writing code in the spirit of Forth (ie: trying to write C in
Forth).
One of the things I liked was the way many definitions were
mostly tacit. That was nice (it's also a nice feature of
Haskell and even J). Whether tacit definitions give you any
kind of gain apart from fun and joy is another matter (they
could be considered higher level and closer to the way
we think about a problem and save some typing).
[Snip]
>>Definitely. For me Lisp always runs fast enough, so the performance
>>is never an issue.
>
>Sadly, that's not the case for me. Also, I don't know of any Lisp systems
>that would let me interface with Microsloth's DirectX interfaces - also
>a requirement of my apps.
>
Hmmm, not even Allegro Common Lisp?
>>C would still suck however. It still wouldn't allow for higher
>>order functions (only miserable function pointers which are
>>no substitute), no dynamism, no first class data types, no
>>true module system, etc...
>
>Yep - don't try to make C something it isn't. C++ tried to
>extend C into a language suitable for application development,
>but IMHO has crumbled under its own creeping featuritis.
Hmmmm, I'd rather have too much than too little, so I would
consider C++ to be better than C (at least it did go on to
correct some of C's flaws like having to pass pointers to
function parameters just to modify them). I am not saying
that C++ is good mind you, but I do consider it to be better
than C.
I would say that C++'s problem is the fact that it's trying
to graft a high level concept on what is essentially a
low level language.
>Maybe that's because we've chosen C due to the fact that we need
>to fly through an amazing number of computations a second more than
>we need memory safety.
>
>I suspect some lisp programmers get off on using the most obscure corners
>of the Common Lisp spec to get something done. The hacker mentality
>comes in all flavors - you hack whatever system you're using.
You are right, however the attitude of using a dozen side effects
in any statement seems to be widely entrenched in C attitudes.
Many of the books I read recommended using such tricks.
>
>>That's because C encourages this faulty mind-set. The whole
>>attitude of C is "obfusicate your code so that your program
>>will run fast on a VAX PDP-11".
>
>Amusing, but untrue.
Well if you read the books and look at code, they're all
encouraging obfusication for the purposes of "efficiency".
But these tend to be low level considerations that seem
to rely on architectural-dependent issues. Can you say
that these tricks will guarantee faster code on every
platform?
>
>>Besides, C doesn't have anything to offer, so the advocates
>>have to try to convince themselves that the language they are
>>using is worthwhile by doing such pointlessly stupid tricks.
>
>C has exactly three things to offer - easy availability of good quality
>compilers, the ability to generate fast, small footprint executables,
>and the ability to replace assembly language as an implementation
>language for a large class of problems.
>
Wouldn't Forth have the same three things to offer? I don't
recall Forth being compiled however.
>If you need those things, you don't really have a credible alternative
>for professional ISV development. Oh yeah - a fourth thing C has
>is easy access to pretty much any current operating systems system
>calls, which is also invaluable for commercial software.
Since whether or not you have O/S system calls is an
implementation dependent issue, I'm assuming you are speaking
with regards to calling conventions and other low-level
isms which makes the addition of such calls easier? Correct
me if I'm wrong.
[Snip]
>>Not to those doing the coding :)
>
>Amen. I eagerly await the day that C/C++ can be dethroned. Already,
>people in the industry are starting to come around to realizing how
>crappy the C/C++ family of languages is for large-scale development
>of sophisticated apps. Now, if our "fun" languages could only replace
>C in the real world, programming for a living could become fun again.
>
Amen. I truly hope that day will come, but to be honest I have
very little faith in the computing industry. Yes, researchers
are doing some very exciting things, but the industry at large
is dissapointing to say the least.
I fear that if C/C++ die, then something even worse will replace
them.
>(postscript - I just came of a 5 hour debugging session where I ultimately
>discovered that some RAM had been decommitted a few instructions too
>early. How much Lisp could you sling in 5 hours? <Sigh>)
Exactly.
>
>----------------------------------------
>····@charybdis.com
>There's no one left to finger
>No one here to blame
>
>
>
--
Regards,
Ahmed
My email address has been altered to avoid spam. Please send
email to punkrock at cs dot uh dot edu.
······@exploited.barmy.army wheezed these wise words:
> Actually, I know C better than I know Scheme, Lisp, or Haskell,
> yet I can do better using the latter 3 languages.
Same here. At one time, the only language I knew better than C was
Forth. Now I know C well enough to appreciate not using it.
The pro C argument I see most often is based on how well C is suited
to device drivers, which amuses me. I used to write device drivers in
Forth with no sweat, but I wouldn't touch a driver that needs to run
at the kernel level. Is this the best domain for C? Something that is
inherently painful? How many apps run inside the kernel?
And then we have the tools to make C "easier", like Bounds Checker.
Why are tools like this not needed in Lisp? The security they offer is
already provided by Lisp.
We could argue that pure FP languages like Haskell offer even more,
because they make state dependancies explicit. However, this state
independance could also be acheived in Lisp, by using a pure FP style
(easy enough in Scheme). If you want something like Monad IO, this too
could be done. Perhaps it's just a question of discipline?
How easy is it to do this in C/C++? I know there's a book about
functional programming in C, but I've not seen it yet. Unfortunately,
I don't know of any tools for C/C++ that would work in an FP style.
Imagine the difficulty of interfacing a typical GUI framework in C++
with some C code that uses continuations. While in theory it could be
done, it would require considerably more discipline than most C/C++
programmers are used to, and I keep reading about problems in C++
frameworks (written by pro C++ folk). If you have to work with non-FP
folk, this will be a disaster. Their code has to work with yours, and
yours must work with theirs. Any problems will be blamed on the least
"trusted" code, and that'll be the FP code. "Trusted", in this
context, is a political attribute, and will therefore vary depending
on who you ask. I don't trust C++.
Like C++ tools, it may be best to avoid C++ folk. ;) (If you can.)
This isn't bashing, it's just advice for like minded individuals. Nor
is it whinging to point out that C++ folk have a high profile. I often
get blank looks when I mention Lisp to people. I sometimes think I
should get a little card printed with the URL for "Lisp: Good News Bad
News How to Win Big".
I could hand them out faster than my business cards...
--
Please note: my email address is munged; You can never browse enough
"Oh knackers!" - Mark Radcliffe
>>>>> "W" == ······@exploited.barmy.army wheezed these wise words:
W> Actually, I know C better than I know Scheme, Lisp, or Haskell,
W> yet I can do better using the latter 3 languages.
>>>>> "M" == Martin Rodgers <···@this.email.address.intentionally.left.crap.wildcard.demon.co.uk> writes:
M> Same here. At one time, the only language I knew better than C
M> was Forth. Now I know C well enough to appreciate not using it.
M> The pro C argument I see most often is based on how well C is
M> suited to device drivers, which amuses me. I used to write
M> device drivers in Forth with no sweat, but I wouldn't touch a
M> driver that needs to run at the kernel level. Is this the best
M> domain for C? Something that is inherently painful? How many
M> apps run inside the kernel?
I use both Scheme and C for my programming. As much as I like Scheme
and use it as much as I can, it doesn't seem to make sense for many
different kinds of applications. Here are a few things I have done
recently for which C has seemed the best solution:
- Real-time robot control code (I actually wrote a simple embedded
real-time Scheme interpreter for _high-level_ control of the
robot, but I would never use it for computing real-time robot
dynamics and control equations at a lower-level).
Granted, I could use something like Ada and possibly Forth for
this, but I wouldn't use Lisp.
- Writing a real-time garbage collector for a Scheme interpreter
(this requires interfacing with the OS for memory allocation,
laying out heaps of conscells in the allocated memory, and all
sorts of nasty bit-twiddling in unused least-significant-bits of
memory pointer representations for space efficiency).
Writing this in Lisp makes no sense to me. I'm not even sure
this would be too easy to do any other language besides C
(I want portability, so assembly language isn't an option).
- Animating an OpenGL rendering of a hand from a stream of
finger-joint data from a Cyberglove for a virtual reality
environment.
Knowing that I generally have a working C compiler available no matter
what system I use or what else is going wrong with the system, is also
extremely important.
-Chris
ps. I can't stand C++, but I'll admit I once thought it was cool.
Christopher Lee wheezed these wise words:
> I use both Scheme and C for my programming. As much as I like Scheme
> and use it as much as I can, it doesn't seem to make sense for many
> different kinds of applications. Here are a few things I have done
> recently for which C has seemed the best solution:
I can certainly say there are times when it's easier to use a tool
that already exists, rather than develop something new in Lisp. Lisp
_can_ win big, but some jobs are just too small for Lisp to make a
difference. And then there's:
> - Real-time robot control code (I actually wrote a simple embedded
> real-time Scheme interpreter for _high-level_ control of the
> robot, but I would never use it for computing real-time robot
> dynamics and control equations at a lower-level).
> Granted, I could use something like Ada and possibly Forth for
> this, but I wouldn't use Lisp.
Interpreted? Hmm. I realised very quickly (even before I began coding
in Lisp) that an interpreter can be used for development, but a
compiler may be better for delivery. In some cases, it can be worth
writing a specialised interpreter and compiler, to support what ever
domain you're working with. Robot control sounds like an excellent
example. For me, it used to be parsers. The code can be tested with an
interpreter (initially, this was all I had), and later compiled to C
or assembly language.
I also like the idea of compiling Lisp to Forth. Build a vocabulary
for the domain you're using, in Forth. Build an interpreter for the
same domain, in Lisp. Then write a compiler for the same domain
specific language, and use your Forth vocabulary as the target.
When Forth programmers do this, they don't necessarily need to make
the distinction between development and delivery in this way. It may
not even be necessary in Lisp, if you use a native code compiler.
However, for real time control you may certainly wish to make such a
distinction, and this is easy enough.
See the Persona project for an example of a declarative definition of
a problem that compiled into C++ animation code:
http://www.research.microsoft.com/
> - Writing a real-time garbage collector for a Scheme interpreter
> (this requires interfacing with the OS for memory allocation,
> laying out heaps of conscells in the allocated memory, and all
> sorts of nasty bit-twiddling in unused least-significant-bits of
> memory pointer representations for space efficiency).
Do you really need to write your app using a Scheme interpreter? Why
not write it in a language implemented in Scheme? Perhaps this is a
cope-out, but I'd want to use a domain specific language anyway, so
this seems like not such a strange thing to do. I've seen it done by
C++ programmers - even MS use domain specific languages! The only
problem is that they tend not to compile to C, C++, or even bytecodes.
Still, they serve a valuable purpose by being highly domain oriented.
They save the programmer a lot of time writing (and later reading)
code to, say, create a user interface by building lots of window
objects.
> Writing this in Lisp makes no sense to me. I'm not even sure
> this would be too easy to do any other language besides C
> (I want portability, so assembly language isn't an option).
You can very simply write a compiler for a specialised language that
uses C as the target language. Forth programmers do this with threaded
code, and sometimes even machine code. You could also write Lisp code
to compile a domain specific language to native code.
If I ever find the time, I may get around to working a audio synth
definition language, for describing the "modules", their settings, and
connections. Effectively, a modular synth in software. The idea is for
it to compile to either native code or assembly language. I'd like to
optimize the code by removing redundant instructions and exploiting
CPU pipelining as much as possible.
Even if the result is not realtime, like some soft synths, it should
be as fast as I can make it. Is that the same as writing a soft syth
in Lisp? How is that different from using, say, Music 11?
> - Animating an OpenGL rendering of a hand from a stream of
> finger-joint data from a Cyberglove for a virtual reality
> environment.
You might like to look at Conal Elliot's work:
http://www.research.microsoft.com/research/graphics/elliott/RBMH/
If this can be done in Haskell, then why not also Lisp? Note how
Haskell does things like I/O. When the language has difficulty doing
things directly, we can pass high level instructions on to simpler
code. I like the idea of compiling to bytecodes which are then
interpreted by code written in C/C++. Just wrap a bytecode engine
around the OpenGL calls, and write the Lisp code at a higher level.
Instead of writing the app directly in Lisp, write Lisp code that
writes the code. In other words, write a compiler.
Somebody once said that real programmers don't write comments, they
write code that writes comments. I feel the same way about C code.
Lisp programmers should write Lisp that writes C. ;)
Not that this is always easy to do! Nor is it always easy to convince
other people that this can be done. It's far easier to demonstrate
that it can be done and _why_ it should be done. Catch 22. You can't
do this until you've written it, and you might not get to write it
until you've convinced...Well, you get the picture. Perhaps you've had
this experience yourself.
Sometimes the real problem is showing that you can save time by doing
it this way. When there's a deadline looming ahead, it's amazing how
conservative people can become. When we've had the Lisp experience, we
find it can work the other way - but we need that positive experience.
> Knowing that I generally have a working C compiler available no matter
> what system I use or what else is going wrong with the system, is also
> extremely important.
This is why I like using C as the target language. Find (or write) a
Lisp to C compiler. I'm writing my own (or ressurecting an old one I
wrote a few years ago), mainly so I can avoid the assumptions made by
most Lisp compiler writers. I have to work with some very odd limits.
It occured to me a few years ago that my compiler should work _very_
well with hand held computers - once I get it finished.
> ps. I can't stand C++, but I'll admit I once thought it was cool.
I've never liked C++ much. There are a few features which might've
helped me once (6 years ago?), but now I have big doubts. I prefer to
use only a few of the C++ extensions to C. Perhaps this is just a
reaction to the rapid changes over the last few years, but I worry
when I see compilers give me "new behaviour" warning messages.
--
Please note: my email address is munged; You can never browse enough
"There are no limits." -- ad copy for Hellraiser
From: Brian Denheyer
Subject: Re: "Programming is FUN again" rambling commentary
Date:
Message-ID: <m23egnxtor.fsf@soggy.aqua.com>
Christopher Lee <·········@ri.cmu.edu> writes:
>
> - Real-time robot control code (I actually wrote a simple embedded
> real-time Scheme interpreter for _high-level_ control of the
> robot, but I would never use it for computing real-time robot
> dynamics and control equations at a lower-level).
> Granted, I could use something like Ada and possibly Forth for
> this, but I wouldn't use Lisp.
Couldn't compiled scheme be used here. I am not clear on whether this
is a language limitation you are alluding to pr a performance
limitation.
> - Animating an OpenGL rendering of a hand from a stream of
> finger-joint data from a Cyberglove for a virtual reality
> environment.
See above.
>
> Knowing that I generally have a working C compiler available no matter
> what system I use or what else is going wrong with the system, is also
> extremely important.
True portability of C is nice. The only thing that seems to be a
problem in scheme portability is r5rs macros and the numeric tower
(engineers need complex #'s !). Neither seems to be very important if
you are mostly concerned with real-time sort of things.
slib seems to adequately handle all most other needs, although I
confess that python is VERY nice in that regard,
i.e. w.r.t. libraries.
> ps. I can't stand C++, but I'll admit I once thought it was cool.
Ditto.
--
Brian Denheyer
······@northwest.com
Christopher Lee (·········@ri.cmu.edu) wrote:
: I use both Scheme and C for my programming. As much as I like Scheme
: and use it as much as I can, it doesn't seem to make sense for many
: different kinds of applications. Here are a few things I have done
: recently for which C has seemed the best solution:
: - Real-time robot control code (I actually wrote a simple embedded
: real-time Scheme interpreter for _high-level_ control of the
: robot, but I would never use it for computing real-time robot
: dynamics and control equations at a lower-level).
: Granted, I could use something like Ada and possibly Forth for
: this, but I wouldn't use Lisp.
You might be interested in Aubrey Jaffer's (author of scm) web pages.
http://www-swiss.ai.mit.edu/~jaffer/Work.html
Aubrey describes writing the low-level part of an NT device driver in Scheme,
which is then automatically translated to C.
--
Ben Caradoc-Davies
Be sure to include a "cookie-for-procmail" in any email sent to me.
From: Rob Warnock
Subject: Re: "Programming is FUN again" rambling commentary
Date:
Message-ID: <6eact8$2df67@fido.asd.sgi.com>
Ben Caradoc-Davies <····@physics.otago.ac.nz> wrote:
+---------------
| You might be interested in Aubrey Jaffer's (author of scm) web pages.
| http://www-swiss.ai.mit.edu/~jaffer/Work.html
|
| Aubrey describes writing the low-level part of an NT device driver
| in Scheme, which is then automatically translated to C.
+---------------
FWIW, note that Jaffer recently added explicit BSD-style use/redistribution
permission to the copyright on "Schlep", his Scheme compiler:
ftp://ftp-swiss.ai.mit.edu/pub/users/jaffer/schlep.scm
Also note that "Schlep" makes no pretense of being a fully-general
Scheme compiler -- it's really just a tool to let Aubrey write
(and test) the software *he* needs in Scheme, yet deliver it in
(fairly human-readable) C, sometimes linking with C code others write.
As such, perhaps it should be thought of as a "template" of a compiler
or a metacompiler that one bends & tweaks as needed for the project at
hand. (If you take snapshots of Schlep every few months, you'll see
that's what he seems to be doing himself.)
All I'm saying is that it will almost certainly "need some assembly"
[significant local modification] to be useful for anyone else than
Aubrey. (Which didn't detract at all from its usefulness to *me*!)
-Rob
-----
Rob Warnock, 7L-551 ····@sgi.com http://reality.sgi.com/rpw3/
Silicon Graphics, Inc. Phone: 650-933-1673 [New area code!]
2011 N. Shoreline Blvd. FAX: 650-933-4392
Mountain View, CA 94043 PP-ASEL-IA
······@exploited.barmy.army wrote in message
<············@Masala.CC.UH.EDU>...
>In article <···················@typhoon.texas.net>,
>Dan Higdon <····@charybdis.com> wrote:
>>······@exploited.barmy.army wrote in message
>
>[Snip]
>Well at work I'm restricted by something a little more down to
>earth. They use C/C++/Fart-ran (misspelling intentional),
>so I'm stuck using them. At home, Lisp does everything
>I want it to do with perfectly acceptable performance so
>I don't have to stain my hands over there.
Looks like we're kindred spririts of a sort, substituting
SML for Lisp. :-) I still can't believe I'm defending C/C++,
since I'm their biggest detractors here at work. Oh well,
back to it....
>Scheme IS Lisp. It's a dialect of Lisp. You are confusing
>a family of languages (Lisp) with specific implementations
>(like Common Lisp). I understand what you are trying to say,
>but you should be more specific to avoid confusion.
Absolutely - a subtle but important difference. (Chalk it up to
a very long day.) Common Lisp was the dialect I specifically
don't care for, although it does seem to be the most capable
of "real world" development, due to its extensive tools.
>Have you by any chance tried Haskell? That has some serious
>type checking and type inferencing, and IMO a nicer syntax
>than the ML family of languages. It is purely functional
>so when you get to IO you'll have to deal with monads, but
>it's a great language and also tons of fun.
Yes - actually I got my start in non-lisp functional languages with
Gofer, a dialect of Haskell. I agree - I really like the syntax,
especially the "literate" versions, where the "normal" text was
comments, and you had to mark the source lines!
In the end, I'm using SML because I like the fact that it's not
quite as pure functional, and it's not lazy. (Although you can
simulate lazy evaluation like you do in Scheme - with promises.)
Lazy languages seem a little tricky to reason about mathematically.
Perhaps that's just because I'm a little out of touch with modern
CS practices.
>Yes I have. I've programmed in VAX PDP-11, x86 and 65xx
>(C64 in particular -- 6510) assembly languages.
I stand corrected. (Gotta love the 6502 stuff - first RISC chip, IMHO)
>Well I see nothing enjoyable or even worthwhile in C, so I guess
>we'll just have to agree to disagree.
Agreed. That's why there are so many computer languages. :-)
>I remember reading about a C interpreter a LONG time ago.
>It may have been a sort of garage project in somebody's
>spare time, but I thought you'd be interested in knowing
>that there may have been such a beast somewhere :).
Yep, I remember that one too. Strange but interesting idea.
I don't remember how well it worked.
>>That's because you're probably not very good at C. :-)
>Actually, I know C better than I know Scheme, Lisp, or Haskell,
>yet I can do better using the latter 3 languages.
(The smiley was for sarcasm - I'm glad you didn't take offense at my
statement, I *was* just joking.) I've found that to be true as well.
I actually freaked out a coworker by prototyping a particularly
tricky algorithm in SML first. The "fun language" world has another
convert now! :-)
>Comparing C and Lisp is fair, since both are general purpose
>languages. Just because C is a portable psuedo-assembler
>does not make it immune from comparison or criticism. We're
>talking about getting the job done, and intentions mean nothing now,
>only results.
Fair enough. That would be like holding Lisp's symbolic processing
nature against it for numeric or data processing applications.
>As for a GIF decoder, since I'm not sure what the algorithm
>is (I suppose I could find out), I can't say whether or not
It involves a lot of pointer arithmetic and such. You could certainly
do it in Lisp, but my argument is that expressing memory accesses
and pointer arithemetic is cleaner in C than Lisp, since C has
notations to directly support these activities. Much like lisp has
notation for list handling, which is mildly painful in C.
>C would be better at it than Lisp. A* search I do know and
>agree with however.
>The one thing that got to me about Forth (and this may be due to my
>own ignorance of the language at the time) was the inability to
>get at any data lower than 3 levels down on the stack without
>popping everything before it off. Things like rotate and swap
[snip]
Most Forths have and 'index' word that you can use to go arbitrarily
deep into the stack. Modern Forth dialects even let you declare
"parameters", which become local words that produce the value
passed in, although that's kind of "cheating" IMHO. :-)
>>Sadly, that's not the case for me. Also, I don't know of any Lisp systems
>>that would let me interface with Microsloth's DirectX interfaces - also
>>a requirement of my apps.
>>
>Hmmm, not even Allegro Common Lisp?
Don't know about that one, so I may be wrong about that. It's likely that
Allegro Common Lisp wouldn't fit my memory footprint though.
(Still doesn't validate my argument here - it would be interesting to
know if Allegro can call DirectX. I'd better do some research....)
>Hmmmm, I'd rather have too much than too little, so I would
>consider C++ to be better than C (at least it did go on to
>correct some of C's flaws like having to pass pointers to
>function parameters just to modify them). I am not saying
>that C++ is good mind you, but I do consider it to be better
>than C.
I program almost exclusively in C++, so I'd tend to agree with
you. The problem is, unlike Lisp, grafting extra features onto
the language just makes it more cumbersome and complex.
I think CLOS is a good example of how Lisp can be cleanly
expanded to new programming models without kludging up
the original language. One of the advantages of not really
having a syntax, I suppose. :-)
(I've only ever looked at CLOS, so I have no real experience
with it, and may be completely off-base)
>I would say that C++'s problem is the fact that it's trying
>to graft a high level concept on what is essentially a
>low level language.
Amen, brother. Leo Brodie postulated that Forth is neither a
high-level nor low-level language, but an "all level" language,
because you could seamlessly go from assembly programming
to arbitrarily abstract interfaces. Lisp is the same way, shifted
up the "level" a little. You can happily write everything from
compilers to sophisticated AI systems in it, all without doing
anything wierd to the language.
That's why Lisp is fun to me.
>You are right, however the attitude of using a dozen side effects
>in any statement seems to be widely entrenched in C attitudes.
>Many of the books I read recommended using such tricks.
Yes, it does seem to be a C-cultural thing. Some of those tricks
are accepted idoms of the language however, so I don't object
to their use.
>Well if you read the books and look at code, they're all
>encouraging obfusication for the purposes of "efficiency".
"Obfuscation is in the eye of the beholder". I think you're
referring to rampant abuses of the pre and pos-increment
operators , such as "while ((*a++ = *b++) != '\0');" for
a string copy. Yeah, it's ugly, but most C programmers
understand it as an idiom. I personally would use strcpy(),
but I try to focus on readability. Probably because I'm a
freak who likes to program in functional languages on his
off time. :-)
>But these tend to be low level considerations that seem
>to rely on architectural-dependent issues. Can you say
>that these tricks will guarantee faster code on every
>platform?
No, indeed you can't. That's why I shy away from them for
the most part. But, I sometimes find myself disassembling code
to see if I can trick the compiler into producing better code for
a given expression. After a while, you find out what works and
what doesn't for your compiler.
Actually, that last paragraph may be the most damning criticism
of C/C++ I can think of! Imagine having to program in a language
where second-guessing the code generator was even something
you were TEMPTED to do! Scary. Scarier still is that I've often
wondered how to disassemble SML functions. It's a sickness -
I think I might need professional help. :-)
>Wouldn't Forth have the same three things to offer? I don't
>recall Forth being compiled however.
Yes, it does. All Forths are compiled in some way. Traditional
Forths compile to a list of word pointers and constants. Some
newer Forths compile to "direct threaded" code, where the target
of every call is real machine code, and the interpreter is invoked
as needed.
>Since whether or not you have O/S system calls is an
>implementation dependent issue, I'm assuming you are speaking
>with regards to calling conventions and other low-level
>isms which makes the addition of such calls easier? Correct
>me if I'm wrong.
Yes, it is an implementation issue for the most part. The C calling
conventions mesh very well with OS calling conventions. Probably
because many of those are implemented in C. It's true that a
sufficiently well-integrated Lisp system would be able to do all
these things. I may be falling prey to the fallacy that most Lisp
systems want mammoth memory footprints, and don't really
let you get "down and dirty" with the OS. I would still question
the validity of trying to write "Quake" in Lisp, however.
>Amen. I truly hope that day will come, but to be honest I have
>very little faith in the computing industry. Yes, researchers
>are doing some very exciting things, but the industry at large
>is dissapointing to say the least.
>
>I fear that if C/C++ die, then something even worse will replace
>them.
Like Java! :-) I've followed a lot of the so-called practical languages,
like Eiffel, Dylan and Oberon in hopes that a better GP languages
might catch on, but so far, it's been all for naught. Lisp languages
have the disadvantage that many find their syntax (or lack thereof)
difficult to read, which is probably the largest obstacle to Lisp world
dominance. Look at Java - I suspect the reason people even consider
looking at it is that it looks just like a light version of C++.
Sigh. I suppose most of us will have to continue writing fun programs
in fun languages in our off-time, and slog through cruddy, cryptic
languages at work.
----------------------------------------
····@charybdis.com
There's no one left to finger
No one here to blame
From: ······@exploited.barmy.army
Subject: Re: "Programming is FUN again" rambling commentary
Date:
Message-ID: <6e9h3f$4t9$1@Masala.CC.UH.EDU>
In article <···················@typhoon.texas.net>,
Dan Higdon <····@charybdis.com> wrote:
>······@exploited.barmy.army wrote in message
>>Well at work I'm restricted by something a little more down to
>>earth. They use C/C++/Fart-ran (misspelling intentional),
>>so I'm stuck using them. At home, Lisp does everything
>>I want it to do with perfectly acceptable performance so
>>I don't have to stain my hands over there.
>
>Looks like we're kindred spririts of a sort, substituting
>SML for Lisp. :-) I still can't believe I'm defending C/C++,
>since I'm their biggest detractors here at work. Oh well,
>back to it....
Looking through your post I can agree that we seem to
birds of a feather (is this the start of a beautiful friendship? :)).
I like quite a few languages, pretty much functional languages
although this little chat has convinced me to give Forth another
chance, if for nothing else than fun (I've already downloaded like
a billion interpretors :)).
I wouldn't mind being a C/C++ detractor at work if I only
had the chance to do some detracting!
>
>>Scheme IS Lisp. It's a dialect of Lisp. You are confusing
>>a family of languages (Lisp) with specific implementations
>>(like Common Lisp). I understand what you are trying to say,
>>but you should be more specific to avoid confusion.
>
>Absolutely - a subtle but important difference. (Chalk it up to
>a very long day.) Common Lisp was the dialect I specifically
>don't care for, although it does seem to be the most capable
>of "real world" development, due to its extensive tools.
No problemo, I may have made that mistake in the past too,
and given that Common Lisp does seem to be the most
popular lisp dialect, it's no surprise that it is
often thought of as "Lisp".
I like Scheme's elegance and consistency but as you said
Common Lisp is the most capable of "real world" development.
Some people like to brag about Scheme's small size, what they
neglect to mention however is that the size is due to a
serious lack of functionality.
What I wouldn't give for a Scheme with Common Lisp power.
>
>>Have you by any chance tried Haskell? That has some serious
>>type checking and type inferencing, and IMO a nicer syntax
>>than the ML family of languages. It is purely functional
>>so when you get to IO you'll have to deal with monads, but
>>it's a great language and also tons of fun.
>
>Yes - actually I got my start in non-lisp functional languages with
>Gofer, a dialect of Haskell. I agree - I really like the syntax,
>especially the "literate" versions, where the "normal" text was
>comments, and you had to mark the source lines!
Hugs (another dialect of Haskell) was my first introduction to the
glorious world of Functional programming. Granted, I had used
Common Lisp before in AI, and , but it was Haskell that
introduced me to the functional paradigm, which I continue to use in
Lisp (Scheme, Common Lisp, Elisp).
>In the end, I'm using SML because I like the fact that it's not
>quite as pure functional, and it's not lazy. (Although you can
>simulate lazy evaluation like you do in Scheme - with promises.)
>Lazy languages seem a little tricky to reason about mathematically.
>Perhaps that's just because I'm a little out of touch with modern
>CS practices.
Are promises a completely accurate simulation of lazy
evaluation ala Haskell? I mean in Haskell you can
use things like infinite sized lists without a problem
because the system will only access as much of the
list as is needed. Do promises do that as well?
>
>>Yes I have. I've programmed in VAX PDP-11, x86 and 65xx
>>(C64 in particular -- 6510) assembly languages.
>
>I stand corrected. (Gotta love the 6502 stuff - first RISC chip, IMHO)
Tell me about it! What I especially loved about the C64
in particular was that game support was built in, and very
easy to use. Hardware sprites, collision detection, it was
all there.
>
>>Well I see nothing enjoyable or even worthwhile in C, so I guess
>>we'll just have to agree to disagree.
>
>Agreed. That's why there are so many computer languages. :-)
:). And finding out about all these languages is almost as much
fun as coding in them. Keeps me off the street :).
>
>>I remember reading about a C interpreter a LONG time ago.
>>It may have been a sort of garage project in somebody's
>>spare time, but I thought you'd be interested in knowing
>>that there may have been such a beast somewhere :).
>
>Yep, I remember that one too. Strange but interesting idea.
>I don't remember how well it worked.
I was lucky to even remember that it existed :).
This was back in my BBS days, before I had internet access,
almost a decade before. I used to BBS with a Tandy 1000EX
and a 1200 Baud modem. Ahhh, the bad old days :)
>
>>Comparing C and Lisp is fair, since both are general purpose
>>languages. Just because C is a portable psuedo-assembler
>>does not make it immune from comparison or criticism. We're
>>talking about getting the job done, and intentions mean nothing now,
>>only results.
>
>Fair enough. That would be like holding Lisp's symbolic processing
>nature against it for numeric or data processing applications.
Lisp can do numeric and data processing perfectly well.
In particular using mappings, filters, and reduction functions (they
are generalized to work over arbitrary sequences) can make such tasks
for better suited for Lisp than most other languages.
>
>>As for a GIF decoder, since I'm not sure what the algorithm
>>is (I suppose I could find out), I can't say whether or not
>
>It involves a lot of pointer arithmetic and such. You could certainly
>do it in Lisp, but my argument is that expressing memory accesses
>and pointer arithemetic is cleaner in C than Lisp, since C has
>notations to directly support these activities. Much like lisp has
>notation for list handling, which is mildly painful in C.
>
Well the pointer operations -- are they for accessing devices
as memory (like screen buffers) or data (array accesses)?
I can't see a problem with Lisp using its own data structures to
handle this, rather than playing with pointers.
Of course as I've said, I'm not familiar with the GIF
decoder algorithm. I've done RLE, and that's about it.
>>The one thing that got to me about Forth (and this may be due to my
>>own ignorance of the language at the time) was the inability to
>>get at any data lower than 3 levels down on the stack without
>>popping everything before it off. Things like rotate and swap
>[snip]
>
>Most Forths have and 'index' word that you can use to go arbitrarily
>deep into the stack. Modern Forth dialects even let you declare
>"parameters", which become local words that produce the value
>passed in, although that's kind of "cheating" IMHO. :-)
Yeah, it would seem to take the fun out of it :). Another
kind person (whose name escapes me at the moment) was kind enough to
send me email, informing me about some other words that
could do what I was complaining about, but informed me that
this should be largely unnecessary if I factor my code
properly.
>>Hmmm, not even Allegro Common Lisp?
>
>Don't know about that one, so I may be wrong about that. It's likely that
>Allegro Common Lisp wouldn't fit my memory footprint though.
>(Still doesn't validate my argument here - it would be interesting to
>know if Allegro can call DirectX. I'd better do some research....)
I've got a free (limited) version of Allegro at home on a
P-100 with 16 Megs of RAM running Win95. Allegro has visual
GUI design capabilities, and a nice enviornment. I don't
know what the minimum system requirements were, but the
program ran pretty decently (for what little I did with it).
I only suggest that it may have a DirectX interface
because it has GUI capabilities, so it seems as good
a choice as any.
Check out http://www.franz.com for more details.
[Snip]
>I think CLOS is a good example of how Lisp can be cleanly
>expanded to new programming models without kludging up
>the original language. One of the advantages of not really
>having a syntax, I suppose. :-)
Pretty much :). The fact that we have introspective
capabilities, closures, a very consistent function-driven
syntax, and a powerful macro system means that extending
the language is very simple.
>
>(I've only ever looked at CLOS, so I have no real experience
>with it, and may be completely off-base)
I'm no expert at CLOS either :)
[Snip]
>
>"Obfuscation is in the eye of the beholder". I think you're
>referring to rampant abuses of the pre and pos-increment
>operators , such as "while ((*a++ = *b++) != '\0');" for
>a string copy. Yeah, it's ugly, but most C programmers
>understand it as an idiom. I personally would use strcpy(),
>but I try to focus on readability. Probably because I'm a
>freak who likes to program in functional languages on his
>off time. :-)
>
Well I can understand what what the line is doing, but
it's still bad programming practice. You're cramming
a loop condition with a loop body, and anybody with
a clue will tell you that this is complete crap.
>>But these tend to be low level considerations that seem
>>to rely on architectural-dependent issues. Can you say
>>that these tricks will guarantee faster code on every
>>platform?
>
>No, indeed you can't. That's why I shy away from them for
>the most part. But, I sometimes find myself disassembling code
>to see if I can trick the compiler into producing better code for
>a given expression. After a while, you find out what works and
>what doesn't for your compiler.
>
>Actually, that last paragraph may be the most damning criticism
>of C/C++ I can think of! Imagine having to program in a language
>where second-guessing the code generator was even something
>you were TEMPTED to do! Scary. Scarier still is that I've often
>wondered how to disassemble SML functions. It's a sickness -
>I think I might need professional help. :-)
>
You do need help, and fast :)
[Snip]
>
>Like Java! :-) I've followed a lot of the so-called practical languages,
>like Eiffel, Dylan and Oberon in hopes that a better GP languages
>might catch on, but so far, it's been all for naught. Lisp languages
>have the disadvantage that many find their syntax (or lack thereof)
>difficult to read, which is probably the largest obstacle to Lisp world
>dominance. Look at Java - I suspect the reason people even consider
>looking at it is that it looks just like a light version of C++.
>
While I'll be the first to state that Java is overrated,
I will also be the first to state that it is better than
C/C++. It does have some decent features (like all
objects being references), but also some idiotic
shortcomings (primitive data types are not objects).
Overall, I think that even if it is adapted, it will be a
step in the right direction (at least it has garbage
collection).
>Sigh. I suppose most of us will have to continue writing fun programs
>in fun languages in our off-time, and slog through cruddy, cryptic
>languages at work.
>
Unfortunately it looks like this will be true for some time to
come.
>----------------------------------------
>····@charybdis.com
>There's no one left to finger
>No one here to blame
>
>
--
Regards,
Ahmed
My real email address is punkrock at cs dot uh dot edu
······@exploited.barmy.army wrote:
> In article <···················@typhoon.texas.net>,
> Dan Higdon <····@charybdis.com> wrote:
> >······@exploited.barmy.army wrote in message
>
> >>Hmmm, not even Allegro Common Lisp?
> >
> >Don't know about that one, so I may be wrong about that. It's likely that
> >Allegro Common Lisp wouldn't fit my memory footprint though.
> >(Still doesn't validate my argument here - it would be interesting to
> >know if Allegro can call DirectX. I'd better do some research....)
>
> I've got a free (limited) version of Allegro at home on a
> P-100 with 16 Megs of RAM running Win95. Allegro has visual
> GUI design capabilities, and a nice enviornment. I don't
> know what the minimum system requirements were, but the
> program ran pretty decently (for what little I did with it).
> I only suggest that it may have a DirectX interface
> because it has GUI capabilities, so it seems as good
> a choice as any.
Just a student here, please ignore me if I don't know what I'm talking
about. :)
I'm doing a project (robotic simulation) using Allegro CL and Direct-X.
It is fairly easy to do using DLL function calls. Allegro has filled
all my needs so far (except for a terrible help system, IMHO). But
then, Common Lisp is a difficult language to learn, it's not jest the
help system's fault. :)
······@exploited.barmy.army wrote in message
<············@Masala.CC.UH.EDU>...
>I like quite a few languages, pretty much functional languages
>although this little chat has convinced me to give Forth another
>chance, if for nothing else than fun (I've already downloaded like
>a billion interpretors :)).
<GRIN!> Like I said, I think the world may have passed Forth by.
Just my opinion, of course - chances are it's just me that's passed
Forth by. I've become accustomed to named variables, parameter
lists and strong type-checking. :-)
>I like Scheme's elegance and consistency but as you said
>Common Lisp is the most capable of "real world" development.
>Some people like to brag about Scheme's small size, what they
>neglect to mention however is that the size is due to a
>serious lack of functionality.
That's one reason I don't mess around with Scheme as much anymore.
I still read the newsgroup though, because I love Scheme's concept and
the sorts of discussions that arise from contemplating Scheme.
>What I wouldn't give for a Scheme with Common Lisp power.
Amen!
>Hugs (another dialect of Haskell) was my first introduction to the
>glorious world of Functional programming. Granted, I had used
>Common Lisp before in AI, and , but it was Haskell that
>introduced me to the functional paradigm, which I continue to use in
>Lisp (Scheme, Common Lisp, Elisp).
Yep. I started out with some nameless Lisp interpreter for my
Apple ][ in the mid-80s, and then "discovered" Common Lisp
at UTexas. (I also did my share of Icon, Prolog, and Smalltalk,
but they were all to "special purpose" to be generally useful, IMHO.)
I gotta admit, though, that the Haskell 'where' syntax a lot. Much
nicer than SML's let...in...end (which works almost identically
to Lisp's (let...) form, for those who don't program in SML or Haskell.)
>Are promises a completely accurate simulation of lazy
>evaluation ala Haskell? I mean in Haskell you can
>use things like infinite sized lists without a problem
>because the system will only access as much of the
>list as is needed. Do promises do that as well?
Nope, not at all. If you know Scheme promises, you know what
I'm talking about. You can evaluate (define p (promise (lambda (...)
...))),
and get back a "promise" type. It won't be evaluated until you use
(force p) on it. At that point, p evaluates to the result of the lambda
expression, and all subsequent (force p)'s will return that same value
without recomputing. With this and some clever programming, you
can implement lazy lists (with lazy-car, lazy-cdr, whatever) that can
process these infinite lists. As far as "real" lazy programming goes,
you're out of luck.
>>I stand corrected. (Gotta love the 6502 stuff - first RISC chip, IMHO)
>
>Tell me about it! What I especially loved about the C64
>in particular was that game support was built in, and very
>easy to use. Hardware sprites, collision detection, it was
>all there.
Yep, we're just now starting to catch up with 3D games - all the
C64 stuff worked great for 2D games.
>>Agreed. That's why there are so many computer languages. :-)
>
>:). And finding out about all these languages is almost as much
>fun as coding in them. Keeps me off the street :).
You and me both. I catch a decent level of friendly hostility from
my coworkers for being a "language hound". They don't understand
what a conceptual advantage it is to understand all the
paradigms embodied by different language designs (functional,
lazy, logic/Horn clause, etc.)
>Lisp can do numeric and data processing perfectly well.
>In particular using mappings, filters, and reduction functions (they
>are generalized to work over arbitrary sequences) can make such tasks
>for better suited for Lisp than most other languages.
C's Fortran-like expression syntax is convenient. Of course, one
of the first macros I wrote was and infix macro, that worked something
like: (infix 3 + 2 * x) => (+ 3 (* 2 x)). Try THAT in C. :-)
>Well the pointer operations -- are they for accessing devices
>as memory (like screen buffers) or data (array accesses)?
>I can't see a problem with Lisp using its own data structures to
>handle this, rather than playing with pointers.
No, just memory/array access. And there's nothing magic about
GIF decoders, I was just saying that C's syntax is more streamlined
for memory access and linear processing than Lisp. You may
only agree that it's more terse and confusing, however. :-)
>I've got a free (limited) version of Allegro at home on a
>P-100 with 16 Megs of RAM running Win95. Allegro has visual
>GUI design capabilities, and a nice enviornment. I don't
[snip]
I tried that one out, but never had time to really pound on it
enough for full evaluation. It did look really nice, however.
>Pretty much :). The fact that we have introspective
>capabilities, closures, a very consistent function-driven
>syntax, and a powerful macro system means that extending
>the language is very simple.
Lisp's greatest strength, if you ask me. Otherwise, I see Lisp
as just another non-pure functional language without static
type checking. :-)
(let's see how many black eyes I get for THAT comment!)
>>"Obfuscation is in the eye of the beholder". I think you're
>>referring to rampant abuses of the pre and pos-increment
>>operators , such as "while ((*a++ = *b++) != '\0');" for
>>a string copy. Yeah, it's ugly, but most C programmers...
>
>Well I can understand what what the line is doing, but
>it's still bad programming practice. You're cramming
>a loop condition with a loop body, and anybody with
>a clue will tell you that this is complete crap.
But it's still an idiom, even with the loop invariant slammed
in there with the mutator condition.
>You do need help, and fast :)
That is a distinct possibility. :-)
>While I'll be the first to state that Java is overrated,
>I will also be the first to state that it is better than
>C/C++. It does have some decent features (like all
>objects being references), but also some idiotic
>shortcomings (primitive data types are not objects).
Yes, it is a better language. Once the implementations
catch up, I hope it gets used more.
>Overall, I think that even if it is adapted, it will be a
>step in the right direction (at least it has garbage
>collection).
Maybe Java will finally be the language that teaches the
world that automatic memory management is a GOOD thing.
Best of all, Apple can't kill it like they more-or-less did Dylan. :-/
Then, they'll come to see the beauty of the classical GC'ed
language - Lisp! (Ok, that was really cheezy, but the sentiment
holds true.)
----------------------------------------
····@charybdis.com
There's no one left to finger
No one here to blame
From: ······@exploited.barmy.army
Subject: Re: "Programming is FUN again" rambling commentary
Date:
Message-ID: <6ebknr$cep$1@Masala.CC.UH.EDU>
In article <················@typhoon.texas.net>,
Dan Higdon <····@charybdis.com> wrote:
>······@exploited.barmy.army wrote in message
><············@Masala.CC.UH.EDU>...
>>I like quite a few languages, pretty much functional languages
>>although this little chat has convinced me to give Forth another
>>chance, if for nothing else than fun (I've already downloaded like
>>a billion interpretors :)).
>
><GRIN!> Like I said, I think the world may have passed Forth by.
>Just my opinion, of course - chances are it's just me that's passed
>Forth by. I've become accustomed to named variables, parameter
>lists and strong type-checking. :-)
I don't really know what the status of Forth is, but then
popularity was never a factor in my decision to program :).
>
>>I like Scheme's elegance and consistency but as you said
>>Common Lisp is the most capable of "real world" development.
>>Some people like to brag about Scheme's small size, what they
>>neglect to mention however is that the size is due to a
>>serious lack of functionality.
>
>That's one reason I don't mess around with Scheme as much anymore.
>I still read the newsgroup though, because I love Scheme's concept and
>the sorts of discussions that arise from contemplating Scheme.
Same here. I'm sitting back, hoping that I'll be here when
(or if) the day arrives that the next standard (R6RS?) adds
just enough functionality to make migration back to Scheme
wortwhile.
I can still hope can't I?
[Snip]
>
>Yep. I started out with some nameless Lisp interpreter for my
>Apple ][ in the mid-80s, and then "discovered" Common Lisp
>at UTexas. (I also did my share of Icon, Prolog, and Smalltalk,
>but they were all to "special purpose" to be generally useful, IMHO.)
I never used Icon (I read about it), but I did use Prolog and
Smalltalk. Prolog is much more flexible than it seems, but it
may still be too narrow in scope, but Smalltalk struck me as
sufficiently general purpose.
The thing that got to me about Smalltalk (both a blessing
and a curse), is that the enviornment was considered part of
the language (I'm talking about GUIs, browsers, etc....).
This was nice in that Smalltalk probably has the nicest
development environment around, but bad in that systems
that didn't have GUIs were more or less SOL. I mean I had a
CLI version of Smalltalk, and a Smalltalk book and
I was trying to define a class, and the book had instructions
like "click on so and so". Kind of tough when you're
sitting in DOS :)
>
>I gotta admit, though, that the Haskell 'where' syntax a lot. Much
>nicer than SML's let...in...end (which works almost identically
>to Lisp's (let...) form, for those who don't program in SML or Haskell.)
I admit, I like Haskell's "where" syntax more than (let...).
It's nice to be able to defer component defnitions until
after the main logic.
[Snip -- Promises vs. Lazy Evaluation]
Thanks for the info.
>
>You and me both. I catch a decent level of friendly hostility from
>my coworkers for being a "language hound". They don't understand
>what a conceptual advantage it is to understand all the
>paradigms embodied by different language designs (functional,
>lazy, logic/Horn clause, etc.)
It's a tremendous advantage. You learn new and exciting
ways of doing things, you understand new languages which may
be the norm a decade from now, and you may find a gem that
could make life a bit easier for you.
Where I work, I don't get any such luxury. I'm basically
stuck trying to debug/enhance/modify horribly written
C, C++, and Fortran code by applying equally gruesome hacks.
It's one ugly hack after another. Forget prototyping,
it's usually a brainless hack job, obfusicated by
idiotic dependencies that shouldn't be there!
>
>>Lisp can do numeric and data processing perfectly well.
>>In particular using mappings, filters, and reduction functions (they
>>are generalized to work over arbitrary sequences) can make such tasks
>>for better suited for Lisp than most other languages.
>
>C's Fortran-like expression syntax is convenient. Of course, one
>of the first macros I wrote was and infix macro, that worked something
>like: (infix 3 + 2 * x) => (+ 3 (* 2 x)). Try THAT in C. :-)
Right, it is pretty convenient, especially for complex
formulas, but after a while you get used to the
Lisp way :)
>
>>Well the pointer operations -- are they for accessing devices
>>as memory (like screen buffers) or data (array accesses)?
>>I can't see a problem with Lisp using its own data structures to
>>handle this, rather than playing with pointers.
>
>No, just memory/array access. And there's nothing magic about
>GIF decoders, I was just saying that C's syntax is more streamlined
>for memory access and linear processing than Lisp. You may
>only agree that it's more terse and confusing, however. :-)
Well which is more streamlined would depend again on whether or not
the algorithm is conducive to maps, reductions, and filters.
If so, then the higher order sequence operations will make
Lisp much more streamlined than C's syntax (since we wouldn't
have to get into array access much, or even at all).
>
>>Pretty much :). The fact that we have introspective
>>capabilities, closures, a very consistent function-driven
>>syntax, and a powerful macro system means that extending
>>the language is very simple.
>
>Lisp's greatest strength, if you ask me. Otherwise, I see Lisp
>as just another non-pure functional language without static
>type checking. :-)
>(let's see how many black eyes I get for THAT comment!)
Hahahahahah. Well it's Common Lisp's distinguishing characteristic
to have introspection and a powerful macro system, take that away
and you've taken away quite a bit :). I wouldn't say that what's
left is just another non-pure functional language -- you've still got
quite a bit of horsepower under that hood :).
>
>>While I'll be the first to state that Java is overrated,
>>I will also be the first to state that it is better than
>>C/C++. It does have some decent features (like all
>>objects being references), but also some idiotic
>>shortcomings (primitive data types are not objects).
>
>Yes, it is a better language. Once the implementations
>catch up, I hope it gets used more.
Oh yes, the dreaded implementations :). The last time I
used Java, I was running JDK 1.0.1 (or something like that).
Within a week I had deleted it from my hard drive, and swore
that I wouldn't touch Java again until someone wrote an
implementation that actually worked for a change. Since then,
I've found vastly superior languages, and I doubt I'll be so much
as thinking about Java now :).
>
>>Overall, I think that even if it is adapted, it will be a
>>step in the right direction (at least it has garbage
>>collection).
>
>Maybe Java will finally be the language that teaches the
>world that automatic memory management is a GOOD thing.
>Best of all, Apple can't kill it like they more-or-less did Dylan. :-/
Dylan was what, basically a sugared-syntax version of Lisp? I always
wondered what the point of having a Lisp with a "traditional" syntax
would be, when much of the power comes from the non-traditional
syntax. I mean try treading code as data and vice versa with
a non-lisp-like syntax.
>
>Then, they'll come to see the beauty of the classical GC'ed
>language - Lisp! (Ok, that was really cheezy, but the sentiment
>holds true.)
Man, I'd platform dive in a pool of melted Limburger just to see
Lisp get widely used.
>
>----------------------------------------
>····@charybdis.com
>There's no one left to finger
>No one here to blame
>
>
>
---
Regards,
Ahmed
My email address has been altered to avoid spam. To email me,
send email to punkrock at cs dot uh dot edu.
>Dylan was what, basically a sugared-syntax version of Lisp? I always
>wondered what the point of having a Lisp with a "traditional" syntax
>would be, when much of the power comes from the non-traditional
>syntax. I mean try treading code as data and vice versa with
>a non-lisp-like syntax.
Actually, the first implementation of Dylan had Lisp syntax (see Apple's
first DRM)! Then the brains behind it felt that by giving it a more C-like
syntax, it would gain acceptance more readily. Basically Dylan was (is? I
thought that Harlequin was still working on an implementation) a Lisp that
is OO from the ground up, using CLOS-like generic operations on all
primitives as well as "objects". It also had some enhancements for
improving performance. Also, no MOP (though I may be mistaken about this).
So, it was a conceptual child of Oaklisp, with an object system like CLOS,
and single lexically bound name space like Scheme. It probably would have
been a worthy Lisp branch had they not messed up the surface syntax with all
of that horrid C stuff.
--
Frank A. Adrian
First DataBank
············@firstdatabank.com (W)
······@europa.com (H)
This message does not necessarily reflect those of my employer,
its parent company, or any of the co-subsidiaries of the parent
company.
······@exploited.barmy.army wrote in message
<············@Masala.CC.UH.EDU>...
>Same here. I'm sitting back, hoping that I'll be here when
>(or if) the day arrives that the next standard (R6RS?) adds
>just enough functionality to make migration back to Scheme
>wortwhile.
>
>I can still hope can't I?
Maybe! I get the distinct impression that the Scheme community has
turned away from making Scheme a "real world" development
system, and is using it mostly as a testbed for new and powerful
language ideas, like the macro system. (Which is VERY cool,
BTW.)
>I never used Icon (I read about it), but I did use Prolog and
>Smalltalk. Prolog is much more flexible than it seems, but it
>may still be too narrow in scope, but Smalltalk struck me as
>sufficiently general purpose.
I liked Icon a lot, because it gave me Prolog's backtracking with
a more "classic" syntax, and the ability to program procedurally
if I wanted to. (Gee, are we getting a theme here?) Prolog can
do some REALLY neat stuff, and I suspect the newer dialects would
really surprise me.
>The thing that got to me about Smalltalk (both a blessing
>and a curse), is that the enviornment was considered part of
>the language (I'm talking about GUIs, browsers, etc....).
Yep, nice environment, but difficult to deliver programs with, IMHO.
>I admit, I like Haskell's "where" syntax more than (let...).
>It's nice to be able to defer component defnitions until
>after the main logic.
Very nice, indeed! I just looked at the Haskell page, and grabbed
a copy of the HUGS interpreter. VERY cool stuff; I had no idea how
far that language had come since the ol' Gofer days. Thanks for
cluing me in on that one. It even has what looks like practical and
usable (for my purposes - Win32 deliverable development)
implementations.
>Where I work, I don't get any such luxury. I'm basically
>stuck trying to debug/enhance/modify horribly written
>C, C++, and Fortran code by applying equally gruesome hacks.
Darn, sorry to hear that. I've had jobs like that before - I spent
many a-year working on project management software written
in Fortran and xBASE. <shudder> That's about as far away from
programierenvergnuegen as you can get. :-) Actually, the guys I
was working with were cool enough to help ease the pain, but it's
not Lisp programming, that's for sure.
>>C's Fortran-like expression syntax is convenient. Of course, one
>>of the first macros I wrote was and infix macro, that worked something
>>like: (infix 3 + 2 * x) => (+ 3 (* 2 x)). Try THAT in C. :-)
>
>Right, it is pretty convenient, especially for complex
>formulas, but after a while you get used to the
>Lisp way :)
Yeah, in all honesty, I rarely used my infix macro. Of course, I use an
HP calculator, so non-arithmatic representations don't scare me. :-)
>Well which is more streamlined would depend again on whether or not
>the algorithm is conducive to maps, reductions, and filters.
>If so, then the higher order sequence operations will make
>Lisp much more streamlined than C's syntax (since we wouldn't
>have to get into array access much, or even at all).
I'll have to think over that one - a linear mapping from encoded data
to unencoded data, where both datasets are 2 dimensional, but just
may be treatable as a 1 dimensional stream if you squint right. Hmmm.
>>Lisp's greatest strength, if you ask me. Otherwise, I see Lisp
>>as just another non-pure functional language without static
>>type checking. :-)
>>(let's see how many black eyes I get for THAT comment!)
>
>Hahahahahah. Well it's Common Lisp's distinguishing characteristic
>to have introspection and a powerful macro system, take that away
>and you've taken away quite a bit :). I wouldn't say that what's
>left is just another non-pure functional language -- you've still got
>quite a bit of horsepower under that hood :).
Oh sure, I don't disagree with that at all. Macros and introspection are
very nice. I think the lack of macros (and any sort of conditional
compilation)
are serious flaws in SML. Introspection in a strongly-typed (dang, what's
the
correct term for languages who's variables have type restrictions, as
opposed
to Lisp's variables, which can refer to any type?) language is difficult at
best,
and really relies on the development environment. Fortunately for me, my
programming style rarely needs to query types, so I don't miss it that much.
It would be nice to know such facilities where there should I need them
however.
>Oh yes, the dreaded implementations :). The last time I
>used Java, I was running JDK 1.0.1 (or something like that).
>Within a week I had deleted it from my hard drive, and swore
>that I wouldn't touch Java again until someone wrote an
>implementation that actually worked for a change. Since then,
>I've found vastly superior languages, and I doubt I'll be so much
>as thinking about Java now :).
Ditto. Although the Scheme->JavaVM compiler is an interesting concept.
>Dylan was what, basically a sugared-syntax version of Lisp? I always
Not quite, but almost. I can best explain it with an analogy:
"Dylan is to CLOS as Scheme is to Common Lisp (without CLOS)"
Dylan uses multimethods, and is a fully object oriented language. The
interesting thing about Dylan is that since every object is based on
<Object>, you can use as much or as little type checking as you want.
You can even fully type specify a method, and expect the compiler to
generate maximally efficient code (no need to see if that value is
a number before you add something to it - the compiler can already
guarantee that it's a number). I know analysis tools can do this under
traditional Lisps, but in Dylan the program has the option of manually
specifying as tight or as loose a typecheck as desired.
>wondered what the point of having a Lisp with a "traditional" syntax
>would be, when much of the power comes from the non-traditional
>syntax. I mean try treading code as data and vice versa with
>a non-lisp-like syntax.
I don't think Dylan can do the code/data thing with the infix syntax,
although I think Dylan retains the old-fasioned Lisp syntax for just such
an occasion.
----------------------------------------
····@charybdis.com
There's no one left to finger
No one here to blame
"Dan Higdon" <····@charybdis.com> wrote:
>
>Oh sure, I don't disagree with that at all. Macros and introspection
>are very nice. I think the lack of macros (and any sort of
>conditional compilation) are serious flaws in SML. Introspection in a
>strongly-typed (dang, what's the correct term for languages who's
>variables have type restrictions, as opposed to Lisp's variables,
>which can refer to any type?) language is difficult at best, and
>really relies on the development environment. Fortunately for me, my
>programming style rarely needs to query types, so I don't miss it
>that much. It would be nice to know such facilities where there
>should I need them however.
The CAML people from INRIA in France have done some fairly cool work
on macro processing for their version of ML. Given that ML's syntax is
somewhat more complicated than lisp's, this is quite an achievement.
Tony.
In article <············@masala.cc.uh.edu>,
······@exploited.barmy.army writes:
> Where I work, I don't get any such luxury. I'm basically
> stuck trying to debug/enhance/modify horribly written
> C, C++, and Fortran code by applying equally gruesome hacks.
> It's one ugly hack after another. Forget prototyping,
> it's usually a brainless hack job, obfusicated by
> idiotic dependencies that shouldn't be there!
Boy! This sure sounds like a description of my jobs
over the last 5 years or so! What's really depressing
is that my current company USED to be full of
lisp/scheme hackers. Unfortunately, someone let the
marketing yahoos into the picture and now it's C++ on
NT. Needless to say, I don't find programming "fun"
anymore. It's dull, tedious, and monotonous.
Isn't there any company left out there that's
interested in doing things "right"?
Mike McDonald
·······@mikemac.com
From: Rob Warnock
Subject: Scheme promises [was: Re: "Programming is FUN again"...]
Date:
Message-ID: <6ea4k6$2emdp@fido.asd.sgi.com>
<······@exploited.barmy.army> wrote:
+---------------
| >simulate lazy evaluation like you do in Scheme - with promises.)
|
| Are promises a completely accurate simulation of lazy
| evaluation ala Haskell? I mean in Haskell you can
| use things like infinite sized lists without a problem
| because the system will only access as much of the
| list as is needed. Do promises do that as well?
+---------------
Well, in some ways they're even lazier, since you *must*
"force" a promise to get it to evaluate itself. [To be more
precise, the standard doesn't *require* auto-forcing, but
it does *allow* implicit forcing by primitives. But few
implementations do that.]
But in general, yes, Scheme promises allow straigtforward construction
of virtually-infinite objects of which only the forced subset is manifest
(e.g., a list of the positive integers, or a list of primes).
However, note that Scheme requires that a forced value be memoized
(cached) so that if it's forced again it's not recomputed. Thus Scheme's
promises may differ from forms of lazy evaluation which allow unrestricted
side effects, e.g.:
> (define foo
(let ((x 0))
(delay (begin (set! x (1+ x)) x))))
> foo
#<promise>
> (force foo)
1
> (force foo)
1
Contrast this with a closure with local state ("forced" by calling it):
> (define bar
(let ((x 0))
(lambda () (set! x (1+ x)) x)))
> (bar)
1
> (bar)
2
-Rob
p.s. IMHO, Scheme promises are a gross hack which would have been totally
unecessary if Scheme had had even a simplistic macro facility required
in the base language [before R5RS]. The only thing "delay" *really* gives
you is a little syntactic sugar for writing an unevaluated expression.
R5RS recogizes this by downgrading "delay" & "force" from "syntax" &
"procedure" to "library syntax" & "library procedure" (meaning they can
be readily expressed in terms of "more primitive" required features).
-----
Rob Warnock, 7L-551 ····@sgi.com http://reality.sgi.com/rpw3/
Silicon Graphics, Inc. Phone: 650-933-1673 [New area code!]
2011 N. Shoreline Blvd. FAX: 650-933-4392
Mountain View, CA 94043 PP-ASEL-IA
Dan Higdon wrote:
>
> [Many good comments about using intelligent higher-level languages]
>
> Sigh. I suppose most of us will have to continue writing fun programs
> in fun languages in our off-time, and slog through cruddy, cryptic
> languages at work.
>
Yes, but how much do you get paid because you are able to understand the
cruddy, cryptic language? :-) I sometimes enjoy thinking about the
analogy of computer programmers as priests (in the ancient sense). We
are highly respected (and well paid) because we are able to understand
the mystifying oracles and omens that the average person is unable to
comprehend.
I know this statement is incredibly cliche, but it fits: When life gives
us lemons, it's fortunate for us that we are able to make lemonade.
Another cliche: just my $0.02.
- Mike
Michael Hobbs wrote in message <·················@ccmail.fingerhut.com>...
>Yes, but how much do you get paid because you are able to understand the
>cruddy, cryptic language? :-) I sometimes enjoy thinking about the
>analogy of computer programmers as priests (in the ancient sense). We
>are highly respected (and well paid) because we are able to understand
>the mystifying oracles and omens that the average person is unable to
>comprehend.
A point well taken. I get the satisfaction of a decent payrate, steady
work,
and my product on the shelf at the local CompUSA at the end of the day.
That's worth something, and any programming is more fun than not
programming. Of course, my life would be a little nicer if I didn't always
have to wonder when the undetected memory leak/trasher will rear its
ugly head. That's not as much fun.
Still, knowing C/C++ has helped to feed me and fund my various hobbies,
so I shouldn't bite the hand that feeds me, even if the hand is just as
likely
to strike me when my back is turned. :-)
----------------------------------------
····@charybdis.com
There's no one left to finger
No one here to blame