Is anyone defending lisp at this GTALUG meeting?
abram
-------- Original Message -------- Subject: [tpm] [Fwd: The Upcoming Dynamic Language Smack Down] Date: Thu, 9 Dec 2010 13:33:32 -0500 From: arocker@Vex.Net To: Toronto PerlMongers tpm@to.pm.org
I'm going to be representing Perl at a GTALUG meeting (unless someone else wants the job :-)* ).
If anyone has any suggestions they would like to make about the points in the notice, please let me know.
The meeting notice follows:
We are about six days away from the **Dynamic Language Smack Down** at the upcoming GTALUG meeting (14th December, 2010 at 7:30pm).
We are going to start things off with a quick five minute introduction to your programming language.
We would like you to describe your languages programming syntax by showing us a pre-made demo of code. This is my example https://gist.github.com/720559.
Then we will have the following panel questions:
* How does your language access functionality from C libraries? * How does your language deal with modularization of common functionality? * How does your language handle scalability issues? * Applications that require many concurrent threads of execution? * How does the language interact with threading? * Does it offer other models for managing concurrent processing? * Applications that require loading large volumes of code? * Parsing and compiling can be expensive; is there a precompiled form? * Applications that process huge volumes of data
* If your dynamic programming language was not available, which of the other dynamic programming language would you recommend? * What is your languages biggest bug, problem, or limitation you are facing today? * How are you going to solve it?
* What's the "sweet spot" for your language? * Where can I find more information about your language? * What kind of community is using and support your language? * What **local** community is using and supporting your language? * What language features are notable and interesting? * What notable applications are using the language?
The address of our meeting is:
Room GB248, Galbraith Building, University of Toronto 35 St George St Toronto, Ontario M5S 3G8 University of Toronto
_______________________________________________ toronto-pm mailing list toronto-pm@pm.org http://mail.pm.org/mailman/listinfo/toronto-pm
That is one unlikely montage :)
Yes, I agreed to do the panel. I've been to a couple of GTALUG meetings before and I think it will be a lot of fun, talking about Lisp and also learning about the other languages being presented. Also, it may draw more people into our club.
If anyone would like to provide suggestions for how to reply to the points above, they would be quite welcome. Most of them seem straightforward, but I don't know quite what I'd say about "large volumes of code" or "huge amounts of data".
For the code presentation I may show a Mandelbrot set renderer: https://github.com/vishsingh/mandelbrot
Vish
On Thu, Dec 9, 2010 at 2:08 PM, Bryce Moore bryce.moore@gmail.com wrote:
Abram wrote:
Is anyone defending lisp at this GTALUG meeting?
Yes. Vish is.
(insert Rocky-style montage of Vish here.)
bryce
toronto-lisp mailing list toronto-lisp@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/toronto-lisp
On Thu, Dec 9, 2010 at 9:40 PM, Vish Singh vishvajitsingh@gmail.com wrote:
That is one unlikely montage :)
Yes, I agreed to do the panel. I've been to a couple of GTALUG meetings before and I think it will be a lot of fun, talking about Lisp and also learning about the other languages being presented. Also, it may draw more people into our club.
If anyone would like to provide suggestions for how to reply to the points above, they would be quite welcome. Most of them seem straightforward, but I don't know quite what I'd say about "large volumes of code" or "huge amounts of data".
Note that I'm the one to blame for virtually all of the questions! :-).
For "large code" I'd point at 4 Common Lisp answers, implementation dependent, but commonly available strategies: a) Tree shakers can shatter off unused code and construct loadable binaries. b) Bytecode compiled code is compact & quick to load c) Code compiled to machine code is less compact, but more heavily optimized d) Memory images can be dumped for fast reload (clisp -M, anyone?)
For "huge data" I suggest thinking about how you do equivalents to database access. There certainly are libraries allowing access to DBMSes and DBM-ish stuff. If there are other answers commonly used for serializing objects, that's good to comment on.
The questions were intended to be pretty open ended. Don't worry about perfect answers everywhere - there's not going to be time to explain every little detail, not with 7 people on the panel. Your share of the time isn't a LONG time.
Rather, having generally credible answers can encourage people to dig further.
I see, the questions are essentially jumping-off points to talk about various topics.
I particularly like the point about memory images. I was struggling to think about something Lisp-specific to say regarding huge codebases, especially since my Lisp code tends to be pretty compact. In fact, we were talking about SBCL's save-lisp-and-die functionality at the last meeting.
Certainly Lisp can interface to SQL databases, and that's a good topic to bring up. However, every language can do that, and I'm sure Andre (Erlang) will bring up Mnesia, their distributed database. That's a very strong point in favour of Erlang's ability to handle data. I wonder if the Lisp world has something similar, that integrates very tightly with Lisp.
I have not heard of this before, but it sounds quite powerful: http://common-lisp.net/project/elephant/
On Thu, Dec 9, 2010 at 10:46 PM, Christopher Browne cbbrowne@gmail.com wrote:
On Thu, Dec 9, 2010 at 9:40 PM, Vish Singh vishvajitsingh@gmail.com wrote:
That is one unlikely montage :)
Yes, I agreed to do the panel. I've been to a couple of GTALUG meetings before and I think it will be a lot of fun, talking about Lisp and also learning about the other languages being presented. Also, it may draw more people into our club.
If anyone would like to provide suggestions for how to reply to the points above, they would be quite welcome. Most of them seem straightforward, but I don't know quite what I'd say about "large volumes of code" or "huge amounts of data".
Note that I'm the one to blame for virtually all of the questions! :-).
For "large code" I'd point at 4 Common Lisp answers, implementation dependent, but commonly available strategies: a) Tree shakers can shatter off unused code and construct loadable binaries. b) Bytecode compiled code is compact & quick to load c) Code compiled to machine code is less compact, but more heavily optimized d) Memory images can be dumped for fast reload (clisp -M, anyone?)
For "huge data" I suggest thinking about how you do equivalents to database access. There certainly are libraries allowing access to DBMSes and DBM-ish stuff. If there are other answers commonly used for serializing objects, that's good to comment on.
The questions were intended to be pretty open ended. Don't worry about perfect answers everywhere - there's not going to be time to explain every little detail, not with 7 people on the panel. Your share of the time isn't a LONG time.
Rather, having generally credible answers can encourage people to dig further.
"I wonder if the Lisp world has something similar, that integrates very tightly with Lisp."
Unless I misunderstand your question, LispWorks Enterprise boasts something called "Common SQL". As usual, I know little about it. 8^/
19.1.1 Overview
Common SQL is designed to provide both embedded and transparent access to relational databases from the LispWorks environment. That is, SQL/relational data can be directly manipulated from within Lisp, and also used as necessary when instantiating or accessing particular Lisp objects.
The SQL interface allows the following: * Direct use of standard SQL statements as strings * Mixed symbolic SQL and Common Lisp expressions * Implicit SQL invocation when instantiating or accessing CLOS objects
The SQL interface provides these features through two complementary layers: * A functional SQL interface * An object-oriented SQL interface
The functional interface provides users with Lisp functions which map onto standard SQL DML and DDL commands. Special iteration constructs which utilize these functions are also provided. The object-oriented interface allows users to manipulate database views as CLOS classes via def-view-class<lw-1112.htm#47877>. The two interfaces may be flexibly combined in accordance with system requirements and user preference. For example, a select query can be used to initialize slots in a CLOS instance; conversely, accessing a CLOS slot may trigger an implicit functional query.
Note that I'm the one to blame for virtually all of the questions! :-).
Add some questions that lead to DSL's and industrial strength macros (e.g. if you want to add reasoning to your semantic web app, how do you embed a prolog compiler into your app?)
For "large code" I'd point at 4 Common Lisp answers, implementation dependent, but commonly available strategies:
What does "large code" even mean these days? This fingerprinting device is built in LispWorks:
www.secureoutcomes.net
Jack Harper just saves the lisp image and downloads it onto the embedded processor.
For "huge data" I suggest thinking about how you do equivalents to
Allegrograph "Expect a trillion triples in December" slide #78
http://www.slideshare.net/pbergerii/2010-semmeetupthebasics
Allegrograph is a database for the semantic web (i.e. web scale) done in lisp. The free edition is limited to 50 million triples.
pt
-
Abram Hindle -
Brian Connoy -
Bryce Moore -
Christopher Browne -
Paul Tarvydas -
Vish Singh