Sure. But get this. I tried to post my code as "Code" and the spam filter on slashdot tells me I have too many "junk" characters. That's anti-Lisp bigotry!;P
Email me at ericmoss@inebraska.com and I'll send it to you. Maybe you can get it to post correctly.;)
Oy! There's an easier way. I wrote 110 lines of Common Lisp code that interprets strings like "cat/etc/passwd | sort > foo" and captures any results that sh would normally print to stdout.
Thus, you can be inside Common Lisp (a script or a listener), call (capture "cat/etc/passwd | sort") and then manipulate the results inside Lisp. If all you need is the side-effect, that's ok too: (capture "cat/etc/passwd | sort > foo").
Eventually I might add the option of declaring aliases that can call a mix of sh and Lisp code; who knows, maybe even a way to let you put in a BNF to declare your own preferred mini-language.
So anyway, you can now use Lisp syntax where it's best, and revert to sh syntax when you have to. This lets you leverage existing scripts and files.
Plus... this interpreter doesn't invoke sh to run the Unix commands, thus reducing that overhead.
Plus... by using Lisp, you can load other Lisp code into the current image. That saves excess spawning of processes, lets you use the Lisp debugger's full power, and gives you more global knowledge about what's happening.
I'm afraid I'm going to have to agree with you on this, Eric. However, you were selective in your endorsements. What about the following, huh???
(a) the variety of argument types: If you write a library function that takes two args in version 1.0, and you add a third in version 1.1, all you have to do is make the new argument an optional arg, and all the old code calling this function WON'T break. Or you can make it a keyword argument, so you can add all the new args you want and not break old code calling the new function. In other words, libraries can evolve more gracefully.
(b) dynamic runtime: If a function breaks, you are sent into an interactive environment where you can query the program state, fix an improperly set value, create a new function or fix a broken one, compile it and continue. It's like having gdb always available, but even better.
(c) Free implementations -- CMUCL for native code compiling, CLISP for scripts, Vanilla Lisp Shell for interacting with them in an emacs session.
(d) You didn't even mention garbage collection. Sheesh.
OK, joking aside. Why am I the only one responding to my own post? Does noone care enough to agree or disagree with these assertions? Did everyone have a bad first experience with a teacher that didn't really care about Lisp enough to teach it well? Are we going to use whatever an InfoWorld-reading suit tells us is the "best"? Is the look and feel of Lisp just "too different" to even contemplate? I hope not, because a revolution in results will need a revolution in thought and approach and tools. This is important, so I'll repeat it:
If we want a fundamental improvement in functionality, we will need a fundamental improvement in how we design, and that requires a fundamental improvement in the languages that frame how we think about design.
Keeping a syntax just because it's comfortable will strap us to whatever limitations that syntax enforces. Keeping an OO-only model will tie us to its limitations, necessitating a new set of hacks (excuse me, "patterns") to get around those limitations, however clumsily.
The same goes for memory abstraction, calling conventions and typing -- all of which are encouraging rigid top-down planning that produces brittle software.
Common Lisp is not the "ultimate" language -- something better will replace it, but not anything that's less capable, as are the popular languages. Until that day, Common Lisp can get us MANY steps ahead of where we are, just by not limiting design ideas nearly as much as they currently are.
[1] simple, uniform syntax. Having programmed for $$ in C, Objective-C, Perl and Eiffel, it took me a while to get used to s-expressions, but once I did, I learned new ways of thinking about programs as data that can be manipulated. Now my old friends (ObjC, etc) seem clumsy by comparison.
[2] Common Lisp can be interpreted for fast prototypes, compiled for speed, and mixed -- core code compiled, and scripts that seemlessly interact with the core.
[3] It's dynamic. Design targets evolve quickly, and statically typed languages make one waste time deciding if a value should be a float or int or whatever, and re-writing if they didn't guess the future correctly. Once a type can be fixed, a simple declaration allows the compiler to optimize. Clean and quick.
[4] Common Lisp has macros far beyond the C-family, which makes for code that writes code in a seamless pre-processing stage. Macros are unbelievably powerful, and are possible a result of the syntax of s-expressions.
[5] Common Lisp is a multi-paradigm language, rather than a "one trick pony". It is object-oriented via CLOS, and more powerfully so than C++/Java/Eiffel. It has multimethods that capture more object paradigms. It is functional when you want that. It can be made declarative by writing a mini-language (e.g. Prolog) via the macro system, and procedural and reflective and whatever else you want. All with one simple syntax, though you can even alter that if you want.
[6] Common Lisp is fast -- it writes fast, builds fast, and even compiles to good machine code.
Unfortunately, corporations are people(-like), by virtue of Santa Clara County Vs. Southern Pacific Railroad, 1886. It's a bad thing, as it lets them do bad things like sue someone for blowing the whistle. Check out (among others):
http://reclaimdemocracy.org/personhood/santa_cla ra _vs_southern_pacific.html
Slashdot Mirror
Sure. But get this. I tried to post my code as "Code" and the spam filter on slashdot tells me I have too many "junk" characters. That's anti-Lisp bigotry! ;P
;)
Email me at ericmoss@inebraska.com and I'll send it to you. Maybe you can get it to post correctly.
Oy! There's an easier way. I wrote 110 lines of Common Lisp code that interprets strings like "cat /etc/passwd | sort > foo" and captures any results that sh would normally print to stdout.
/etc/passwd | sort") and then manipulate the results inside Lisp. If all you need is the side-effect, that's ok too: (capture "cat /etc/passwd | sort > foo").
Thus, you can be inside Common Lisp (a script or a listener), call (capture "cat
Eventually I might add the option of declaring aliases that can call a mix of sh and Lisp code; who knows, maybe even a way to let you put in a BNF to declare your own preferred mini-language.
So anyway, you can now use Lisp syntax where it's best, and revert to sh syntax when you have to. This lets you leverage existing scripts and files.
Plus... this interpreter doesn't invoke sh to run the Unix commands, thus reducing that overhead.
Plus... by using Lisp, you can load other Lisp code into the current image. That saves excess spawning of processes, lets you use the Lisp debugger's full power, and gives you more global knowledge about what's happening.
I'm afraid I'm going to have to agree with you on this, Eric. However, you were selective in your endorsements. What about the following, huh???
(a) the variety of argument types: If you write a library function that takes two args in version 1.0, and you add a third in version 1.1, all you have to do is make the new argument an optional arg, and all the old code calling this function WON'T break. Or you can make it a keyword argument, so you can add all the new args you want and not break old code calling the new function. In other words, libraries can evolve more gracefully.
(b) dynamic runtime: If a function breaks, you are sent into an interactive environment where you can query the program state, fix an improperly set value, create a new function or fix a broken one, compile it and continue. It's like having gdb always available, but even better.
(c) Free implementations -- CMUCL for native code compiling, CLISP for scripts, Vanilla Lisp Shell for interacting with them in an emacs session.
(d) You didn't even mention garbage collection. Sheesh.
OK, joking aside. Why am I the only one responding to my own post? Does noone care enough to agree or disagree with these assertions? Did everyone have a bad first experience with a teacher that didn't really care about Lisp enough to teach it well? Are we going to use whatever an InfoWorld-reading suit tells us is the "best"? Is the look and feel of Lisp just "too different" to even contemplate? I hope not, because a revolution in results will need a revolution in thought and approach and tools. This is important, so I'll repeat it:
If we want a fundamental improvement in functionality, we will need a fundamental improvement in how we design, and that requires a fundamental improvement in the languages that frame how we think about design.
Keeping a syntax just because it's comfortable will strap us to whatever limitations that syntax enforces. Keeping an OO-only model will tie us to its limitations, necessitating a new set of hacks (excuse me, "patterns") to get around those limitations, however clumsily.
The same goes for memory abstraction, calling conventions and typing -- all of which are encouraging rigid top-down planning that produces brittle software.
Common Lisp is not the "ultimate" language -- something better will replace it, but not anything that's less capable, as are the popular languages. Until that day, Common Lisp can get us MANY steps ahead of where we are, just by not limiting design ideas nearly as much as they currently are.
Why, yes! That's a great idea. Here's why:
[1] simple, uniform syntax. Having programmed for $$ in C, Objective-C, Perl and Eiffel, it took me a while to get used to s-expressions, but once I did, I learned new ways of thinking about programs as data that can be manipulated. Now my old friends (ObjC, etc) seem clumsy by comparison.
[2] Common Lisp can be interpreted for fast prototypes, compiled for speed, and mixed -- core code compiled, and scripts that seemlessly interact with the core.
[3] It's dynamic. Design targets evolve quickly, and statically typed languages make one waste time deciding if a value should be a float or int or whatever, and re-writing if they didn't guess the future correctly. Once a type can be fixed, a simple declaration allows the compiler to optimize. Clean and quick.
[4] Common Lisp has macros far beyond the C-family, which makes for code that writes code in a seamless pre-processing stage. Macros are unbelievably powerful, and are possible a result of the syntax of s-expressions.
[5] Common Lisp is a multi-paradigm language, rather than a "one trick pony". It is object-oriented via CLOS, and more powerfully so than C++/Java/Eiffel. It has multimethods that capture more object paradigms. It is functional when you want that. It can be made declarative by writing a mini-language (e.g. Prolog) via the macro system, and procedural and reflective and whatever else you want. All with one simple syntax, though you can even alter that if you want.
[6] Common Lisp is fast -- it writes fast, builds fast, and even compiles to good machine code.
Unfortunately, corporations are people(-like), by virtue of Santa Clara County Vs. Southern Pacific Railroad, 1886. It's a bad thing, as it lets them do bad things like sue someone for blowing the whistle. Check out (among others):
a ra _vs_southern_pacific.html
http://reclaimdemocracy.org/personhood/santa_cl