Comments are explanations to the future maintainers of the code. Even if you’re the only person who will ever see and touch the code, even if you’re either immortal and never going to quit, or unconcerned with what happens after you leave (and have your code self-destruct in such an eventuality), you may find it useful to comment your code. Indeed, by the time you revisit your code, weeks, months or years later, you will find yourself a different person from the one who wrote it, and you will be grateful to that previous self for making the code readable.
Month: March 2014 Page 2 of 4
Note that this does not make Lisp “mainstream” for others, but it does make Lisp “mainstream” for yourself, and I think anybody who wants to make a change needs to start with himself. it is also very frustrating to wait for others to make the necessary difference first.
As a followup to my initial getting started post:
* I later replaced the Clozure App with the command-line version, obtained by
`svn co http://svn.clozure.com/publicsvn/openmcl/release/1.9/darwinx86/ccl`
- The basic slime (running in
comintmode) is a bit too bare-bones, and it’s much better to add
`(setq slime-contribs ‘(slime-fancy))`
From 1998 [http://firstname.lastname@example.org]
Today’s GUI’s are generally built out of hard-coded event handlers.
A language that could describe the display and the events and associate them with protocol elements such that it would all be data-driven (instead of code-driven) and which required a protocol between the server and the client such that the server only dealt with function calls returning values to the client and the client did all the event handling and dispatching and display, would cause a giant leap forward in GUI design and simplify the tasks involved tremendously.
But thanks to Microsoft, we now mostly have code-driven GUIs that are as portable as the average Egyptian pyramid and which ensure as much “full employment” as the same pyramids, and we now mostly have people who don’t even understand the differences and the layering of language, protocol, and display engine.
Why is it that so many Lisp people appear clinically depressed and so utterly unable to appreciate what they have and go gather people and have fun together if that’s what they want? not only does it bug the hell out of me that people don’t just do what they would like to do instead of this depressing shit – how can they stand it themselves? and who wants to share anything with people who can only be expected to say “thanks, that’s very nice, but what’s the use, anyway?” sheesh!
It’s all a matter of communication: if you could describe what you’ve done or what you need done in such a way that a computer can help you find what somebody else wants or has already done, without the high overhead involved in normal transactions and without the high cost of expression yourself very clearly, then that computer or network of computers could perhaps again make possible what smaller societies that had total communication did, only now with computers taking care of the total communication, and also the almost cost-free shipping of the works involved.
I’m getting somewhat peeved with the repetitive claims that C is so fast.
It isn’t. it never was. It’s just that the language is fairly transparent down to the machine level so when you change something in the C code, you can predict the effect on the compiled machine code.
That doesn’t make it fast, it only ingratiates the control-freak aspect of most programmers.
Here’s what I did, though perhaps a better order of steps exists:
- Downloaded Emacs for OSX
Downloaded ClozureCL from the Mac App Store.
Ran ClozureCL, then “File -> Load File …”, and selected
(ql:add-to-init-file)to make sure I don’t have to repeat this step again
(ql:quickload :quicklisp-slime-helper). This downloaded SLIME and told me what to add to my
`(load (expand-file-name “~/quicklisp/slime-helper.el”))`
- Made a useful symlink:
`ln -s /Applications/Clozure CL.app/Contents/MacOS/dx86cl64 ~/bin/ccl`
- Added a reference to this in my
`(setq inferior-lisp-program “~/bin/ccl”)`
- Ran emacs,
M-x slimeworks !
(or as the prompt says, “Happy hacking!”)
From this thread, a perspective on types:
Getting a type system right requires so much detailed specification that the cost is so high that mistakes are actively discouraged. this cost is not necessarily offset by the benefits of using such types, especially not if the program needs to adapt its specification to changing needs discovered only as the program is being used in preliminary forms (often called “prototypes”, but I’m not sure building a prototype only to discard it and build “the real thing” is a good idea. It seems the projects that go into a state of completion such that they are no longer learning from the experience of use are extremely rare. projects that no longer can learn from the experience of use is, however, quite common.
My conclusion is that less strongly typed (i.e., dynamically typed) systems are the ultimate type systems, because they allow growth and change, while preserving the ability to use machine reasoning about types. strict type systems, where every “object” is a type, do not scale well because the computer is not involved in the typing decisions, only in checking them. still, some of the lessons of “object-oriented” programming in the Algol family can be fruitfully employed in dynamically typed systems.
Essentially, it is the a priori aspect of strongly typed systems that is fundamentally unsuited to the process of acquiring the knowledge of the types necessary to implement them and relate them correctly.
NETSCAPISM /net-‘sca-,pi-z*m/ n (1995): habitual diversion of the mind to purely imaginative activity or entertainment as an escape from the realization that the Internet was built by and for someone else.