OT: learn a new language
Adrian Kubala
Seibel, is generously making the entire book available online for free:
http://www.gigamonkeys.com/book
Whatever you've heard about Lisp, if you've heard about it at all,
probably hasn't been good, so I'm just going to suggest that you look
into it with an open mind. Practically every interesting "new" language
development being trumpeted in mainstream languages (templates (aka
macros), object-oriented programming, JIT bytecode-compilation, generic
functions) has been in Lisp for a long time -- if you're lucky, in 10
years C% (or whatever they call it) might have all the features Lisp has
now. :)
Adrian
Joshua Shanks
http://paulgraham.com/avg.html
Tim Soderstrom
out all the Ruby on Rails stuff. But it doesn't seem all the intuitive
from the 15 or so minutes I looked at it. And my time is precious :)
Tim
Matt
Adrian Kubala <adria...@sixfingeredman.net> wrote:
When trumpeting the virtues of a functional language, don't forget to
mention other alternatives, like Scheme:
http://www.scheme.com/tspl3/
Lisp's dynamic scoping gives me nightmares and I find that the Lisp
community often uses it as if it were an imperative language in the name
of efficiency.
And for those of you who complain that Lisp and Scheme are illegible due
to parentheses, try Haskell instead. But whatever you do, learn a
functional language: it's great training for good programming skills,
and they are quite useful in "real life", contrary to popular belief.
Matt
Adrian Kubala
> Lisp's dynamic scoping gives me nightmares and I find that the Lisp
> community often uses it as if it were an imperative language in the
> name of efficiency.
Urban legends! Lexical scoping has been the default since Common Lisp
was standardized over a decade ago. Maybe you're thinking of Emacs Lisp
which everyone agrees is awful. CL does tend to encourage a less
functional style but you can still do FP just as efficiently as Scheme
if you want to (well, except maybe for full tail-call-elimination, which
most CL impls still do to some degree).
Matt
Adrian Kubala <adria...@sixfingeredman.net> wrote:
You are correct: sorry for the misinformation. I suppose it is then an
added capability that you _can_ use dynamic scoping when you require it.
Also, I have a friend trying to write a domain specific language to
sanely specify makefiles. He started using Scheme since he intends the
language to be Scheme-like. However, he quickly got bogged down in
practical issues like accessing the file system and trying to import
libraries...two things at which Scheme really sucks. After wasting a
day at it, he just started using CL and all his problems went away.
To atone for my sin against CL, check this MP3 out (Dr. Novak links to
it from his compilers web page):
http://www.prometheus-music.com/audio/eternalflame.mp3
Matt
Adrian Kubala
> [...] he quickly got bogged down in practical issues like accessing
> the file system and trying to import libraries...two things at which
> Scheme really sucks.
"Scheme isn't practical" is an urban legend too. It's like trying to
write a desktop application in J2ME and complaining that it doesn't have
Swing -- Scheme is a family of languages, and some of them really suck
at some things, but some of them (PLT Scheme for example) kick ass at
just about everything.
Emmett Witchel
I like that MP3
Emmett
Matt
Adrian Kubala <adria...@sixfingeredman.net> wrote:
I'm definitely not saying that Scheme is not practical for many
applications. I did my undergrad at the home of the original PLT
(before they shipped it off to other universities and started things
like DrJava and DrC#) and cut my programming teeth on their
implementation, DrScheme. It's a truly beautiful language and should be
among the first alternatives that come to mind when you start to design
a project.
However, Scheme lacks modules. For large implementations where it is
likely that you will want to reuse your own and other people's code, the
lack of explicit name interfaces can mean that you wind up rewriting
perfectly good code to avoid name clashes.
Such module systems have been defined, but have yet to work their way
into many of the various "real" Scheme implementations. See this paper
(although slightly out-dated, it clearly overviews what I'm talking
about):
http://www-2.cs.cmu.edu/~rwh/courses/modules/papers/curtis-rauen90/paper.
pdf
The problem is that the idea of a module isn't even defined in the R5RS
(the Scheme "standard", written in 1998). I believe that Scheme won't
come into its own for large software implementations until this happens.
Projects like SLIB:
http://swissnet.ai.mit.edu/~jaffer/SLIB.html
go to exquisite pains to make themselves amenable to all the flavors of
Scheme. A module system would make such efforts much easier.
Until then, it's pretty easy to hack together your own encapsulation
schemes, like the one written by Dr. Lavender here at UT that I've
attached (or tried to). But again, such approaches are highly
non-standardized, which I feel limits the growth of the language.
Matt
; "Poor Man's" objects using syntactic extension
; IF using GNU Guile, uncomment the following line
; (use-syntax (ice-9 syncase))
(define-syntax defObj
(syntax-rules ()
((_ (name . varlist)
((slot1 val1) ...) ; SLOTS are the object's variables
((meth1 body1) ...)) ; METHODS are the object's procedures
(define name
(lambda varlist
(let* ((slot1 val1) ...)
(letrec ((meth1 body1) ...)
(lambda (msg . args)
(case msg
((meth1) (apply meth1 args)) ...
(else
(error 'name "invalid message ~s"
(cons msg args))))))))))
((_ (name . varlist)
((meth1 body1) ...))
(defObj (name . varlist)
()
((meth1 body1) ...)))
))
; sending a message without having to explicitly quote the method
(define-syntax send-msg
(syntax-rules ()
((_ obj msg arg ...)
(obj 'msg arg ...))))
; examples
(defObj (Foo kar kdr)
((get-car (lambda () kar))
(get-cdr (lambda () kdr))
(set-car! (lambda (x) (set! kar x)))
(set-cdr! (lambda (x) (set! kdr x)))))
(defObj (Arith)
((add (lambda (x y) (+ x y)))
(sub (lambda (x y) (- x y)))
(mult (lambda (x y) (* x y)))
(div (lambda (x y) (/ x y)))
))
Adrian Kubala
> PLT [...] However, Scheme lacks modules.
Wow, that must have been a while ago! Check out PLT's current module
system[1]. I think it's the only one anywhere which correctly handles
compile-time macro dependencies and environments[2]. Modules can
redefine just about every Scheme primitive (like function application)
without stepping on each other's toes. And there's a nice reuse
framework based on ML-like functors.
They even have a nifty package distribution system where you can require
a package in code and PLT will automatically fetch the correct version
and satisfy dependencies[3]. Take that, CPAN!
PLT isn't the only Scheme with modules, either[4]. Ok, Scheme *does*
suffer from the difficulty of sharing code between implementations, but
it's still better than languages with only one implementation (Python,
Perl, PHP, ...). I tell people to just pretend PLT == Scheme and if they
someday decide they need Stalin, it's still way less work than switching
to C.
[1] http://www.htus.org/Book/Staging/how-to-use-modules/
[2] http://sixfingeredman.net/ref/programming/scheme/composable_and_compilable_macros.pdf
[3] http://planet.plt-scheme.org/
[4] http://sixfingeredman.net/ref/programming/scheme/23_things_about_modules.pdf
Matt
Adrian Kubala <adria...@sixfingeredman.net> wrote:
> Matt <mwa...@cs.utexas.edu> schrieb:
> > PLT [...] However, Scheme lacks modules.
>
> Wow, that must have been a while ago! Check out PLT's current module
> system[1]. I think it's the only one anywhere which correctly handles
> compile-time macro dependencies and environments[2]. Modules can
> redefine just about every Scheme primitive (like function application)
> without stepping on each other's toes. And there's a nice reuse
> framework based on ML-like functors.
Touche. You can tell how much I've used Scheme since coming to grad
school =) Thanks for pointing the newsgroup to those resources. R6RS
even adds modules (while calling them "controversial or difficult but
necessary" along with non-hygienic macros, records, etc.):
http://www.schemers.org/Documents/Standards/Charter/2004-10-13.pdf
Matt
Dustyn Blasig
used...
Adrian Kubala
> Forget text, go graphical and use your brain the way it was meant to
> be used...
That's funny, I was just having this very argument in comp.lang.lisp.
Why do you think people's minds are more suited to graphics than text?
Some contrary data points:
- Good artists are no more common than good writers.
- Ideographic languages are all dead.
- Many people I know prefer written directions to maps.
- Hardware design languages are gaining ground over wiring schematics.
Dustyn Blasig
> Dustyn Blasig <bla...@ece.utexas.edu> schrieb:
>
>>Forget text, go graphical and use your brain the way it was meant to
>>be used...
>
>
> That's funny, I was just having this very argument in comp.lang.lisp.
> Why do you think people's minds are more suited to graphics than text?
> Some contrary data points:
> - Good artists are no more common than good writers.
Human minds are well suited for doing complex tasks like pattern
matching, color coordination, etc. A graphical program can exploit a
much greater amount of the human brain to describe a complex program in
a much clearer way. A picture is worth a thousand lines of code.
> - Ideographic languages are all dead.
Only because the super powers of the world use alphabetic languages :)
> - Many people I know prefer written directions to maps.
I'm sure they won't think that when a street name has changed or a
few extra stop lights have been added since the directions were written.
I can remember only a few times when written directions got me where I
needed to go without a little help from the old Rand McNally map.
> - Hardware design languages are gaining ground over wiring schematics.
I can assure you this is not true. I work with VHDL and Verilog on a
regular basis, and I would much rather use a graphical programming
environment. Unfortunately, graphical programming is relatively new, and
it is much harder to write a parser/compiler for a graphical language
than a text based language, BELIEVE ME.
Feel free to check out information on a few graphical environments
(there are many more projects out there):
1. LabVIEW
2. Simulink (VHDL/Verilog Translator for MatLAB)
3. Ptolemy (Research project at UC Berkeley)
Adrian Kubala
> A graphical program can exploit a much greater amount of the human
> brain to describe a complex program in a much clearer way.
In theory, the problem is how do we exploit it? If someone really
invents a way to hijack the visual cortex to upload lots of information
into brains, books are dead... but nobody seems close to solving that
problem.
Anyways, I guess this is one thing where I'll believe it when I see it.
Right now it just doesn't seem like the problems I have programming have
anything whatsoever to do with the textual nature of my programs.
Matt
Not to be argumentative, but I thought Chinese was ideographic. Then I
read the following article:
http://www.pinyin.info/readings/texts/ideographic_myth.html
So, what languages are (were) ideographic?
But this is a total tangent from the real purpose of my post.
> - Many people I know prefer written directions to maps.
> - Hardware design languages are gaining ground over wiring schematics.
It seems like what's being said here is that people value a certain
compactness of representation. Fumbling with a map is certainly less
preferable than reading a list of road names and directions.
But I feel like both kinds of programming have their place. I
implemented a massive neural network on an ASIC for my VLSI design
project in undergrad. The image of the thing was insanely complex...but
the development environment we used to create it (Magic) had nice ways
of allowing you to zoom into more and more detail and obscure detail as
you zoomed out.
On the other hand, that project took us a few days to implement in Java
and an entire semester to create in Magic. If only I could have used
VHDL to describe the system and generate a first pass at the actual
structure, then optimized the layout by hand, I would have saved myself
(and my three partners) a lot of trouble.
Maybe having the ability to modify both representations of the same
program would be useful. Is this how LabView works? I'm certain that
Ptolemy allows you to specify simulations both graphically and via text.
Matt
dhanes...@gmail.com
Translators or interpreters, in embassies, airlines, call centres, etc.
For further information you can visit the following link:
http://www.inlinguanewdelhi.com/courses/foreign-language/