Maximum PC

I almost forgot. Peter Norvig has written an excellent essay on Teaching Yourself Programming in Ten Years which is absolutely must read material IMO.

Peter has also written an EXCELLENT book called Paradigms on Artificial Intelligence Programming that is rightfully a classic in the field. You won't cover seven different programming languages in seven weeks; Almost everything is written in CL. You will cover significant programs (from AI history) and computing paradigms. For example, in the chapter on logic programming, you're shown how to create a Prolog implementation from surprisingly few lines of CL code, and then use it to do logic programming. The code is truly amazing and mind boggling dense. You will simply be amazed at how much is accomplished with so very little code (ie the code is truly DENSE). It also covers OOP, algebraic systems, natural language, knowledge bases, expert systems and a dozen other things. Code is data is chapter 3 stuff.

This isn't a book for newbies or part-timers; It is a book suitable for hotshot graduate students and professionals looking to expand their minds... it is humbling. Understanding this stuff WILL BREAK YOUR BRAIN. Seriously.

I finally reached my "aha" moment a few months ago, and I wish I hadn't. Now I'm a depressed programmer working with a screwdriver and a fruit peeler to build the titanic. Ruby embodies that LISP approach of 'write your own language to fit a problem domain' by introducing method_missing() or define_method(), whereby you can easily create a DSL (Domain Specific Language). You then fit Ruby to the domain, rather than the domain to Ruby.



I was spelling out my initial thoughts, glad I could read yours.

I think this is why Ruby is making a HUGE spiel in the development world. I just returned from EuRuKo (European Ruby Conference) in Berlin, Germany. One of my biggest take aways was that idea of a multi-paradigm language. Developer happiness stems from developer productivity: when we don't fight to solve a problem, we are happiest. The biggest reason why I'm starting to like LISP (yeah Crash, freak out, I like LISP) is that LISP is designed to solve multiple paradigms. Languages like Prolog freaked me the heck out because of its ability to do logic programming!


I think developers are cursed individuals in that, despite of our brilliance and imagination, we're cursed with management. However we also have to balance pragmatism. I'm not advocating that we write an app in eight different languages, but I advocate using the right tools for the right job. In my finance app example, the rules engine is pretty complicated (but we decided not to implement it anyways, well, at least I made that grand decision in front of the project managers) and the complexity stems from the dynamics behind the logic. Coding it in C# would have been a nightmare, with peanut butter...squared. Prolog would have allowed me to focus on different areas of the program. From a pragmatic standpoint, even if I could stick with a C# backend, HTML/CSS/JS front-end and keep the rules engine in Prolog - that's three paradigms, not eight. The largest piece of the puzzle - the rules engine - would have been a quick solution in Prolog than in C#!

I'm currently reading up on Erlang and Ruby (with the intention of going beyond just Rails).

Erlang shocks me in how the good folks at Erricson wrote a scalable, distributed language...and it even amazes me further how many people are re-inventing the wheel using C.

Whiskey
Tango
Foxtrot

I'm constantly reminded in C# that concurrent programming will melt my brain. The concepts behind shared memory, semaphores, mutexes and locks are mind numbing! When I began to look at concurrency in C#, it was practically deafening! It turns out, there's a better pattern to use, it's called the Actor Model. I really like the idea behind the actor model, whereby each 'thread' is self-contained. No shared memory, no mutexes, no semaphores - each actor can spawn other actors and pass messages to each other. Brilliant!

I'll have to dive deep into LISP and Prolog eventually, just not now, I'm busy.

I'll have to sit down and learn some Ruby someday. I've read a lot of commentary stating that Ruby is inspired by Lisp (among other languages), but I've also seen other say that it isn't really a Lisp language because it contains a lot of syntax, doesn't have the list structure and therefore the full capabilities of the Lisp macro system, and a couple of other reasons. Of course, some people argue that Common Lisp isn't really a true Lisp either.

Sometimes you just have to get dirty and write some code to see if you like working in a language or not. I do like this example of meta-programming on wikipedia. I might try doing the same thing in Java and Lisp later (for kicks).


It amazes me how often people who have no software development experience end up leading a software team; It also amazes me how often people from other disciplines end up writing software. Someday I'm going to put together a model car representing how a car that I designed would end up looking with a caption "Yes, your software DOES look worse than my car!", just to drive home the point.


When I was at Boeing, I wrote a rules engine to help ensure that spacecraft data was entered into a database correctly. I was on a small team at the time, so I didn't have a choice but to use Java which was the default language for all new projects. I sometimes wonder how the application would have turned out if I had written it in either Lisp or Prolog. Because my partner and I were fairly expert at Java (at least compared to everyone else there), we were able to turn a 30K to 40K SLOC mess into about 3600 SLOC of Java and 10K lines of XML by using reflection to process the rules in XML (and generate PDF for the system engineers), but I think we probably could have achieved more with the availability of different programming paradigms.

Even more so than with Ruby, I really really really need to spend a month or two writing code in Erlang. A concurrent Prolog system written in Erlang sounds like an interesting project! =)

I think that some people feel that they need to work in C/C++ in order to develop fast concurrent applications. I'm not sure why that is the case though. I think part of it stems from people's knowledge that OSes use concurrency and that most OSes are written in C. It seems kind of odd when you consider that the C language doesn't support concurrency directly.

Ruby is inspired by Lisp, but it wants to stand on its own accord. The meta-programming aspects of Ruby are really powerful. For example, ActiveRecord in Ruby on Rails uses method_missing() heavily. I found it to be a stumbling block initially as Rails allows you to create a Model object where in which it somehow knew its columns.

For example, if you have a table with a username and password but you named it LoginName and Passphrase, you could still call a method by:

User.find_by_loginname_and_passphrase @name, @pass

Rails uses meta-programming to invoke methods at run-time. Matz is a smart cookie (I know, I met him).

Ruby was never really designed for concurrency, it was designed for developer happiness. Ruby is good for building apps that focus on throughput over latency. If performance isn't an issue, Ruby can help you get things done quick.


[/quote]

C/C++ are fine languages but I don't understand why we must re-invent the wheel every time we need to build a large, scalable system. Your point about the OS seems daftly strange, isn't the whole point of the OS is to take advantage of native API's exposed for concurrency and parallelism? It just seems weird that they're not taking advantage of it.

Once you learn CL and spend some time with it, you start to realize that just about everything is inspired by it with the exception of C++ (which has actually started to come around to a more Lisp way over the past 5 or 6 years). Yay Lisp. =)


Does Ruby allow you to do meta-programming outside of the object system? I'm starting to wonder if it is like Java in that regard. Mentioning RoR reminds me that I should do a comparison between RoR and Grails sometime. I suspect that they're mostly similar, but I haven't really looked into either one of them for a long time now. The whole web framework/RDBMS paradigm bores me to death.

I'll probably start a RoR / Grails thread soon. I need to finish up some other things first though... always the same old story.

Lisp makes me want to throw kittens in a wood chipper...


**No kittens were harmed in the writing of this post

A friend of mine has been convincing me to learn LISP for a while now. He jumped on the open-source bandwagon (Ruby, initially) then went Lisp. His roommate currently programs in Clojure (which is Lisp inspired), and Lisp is making strides into the programming world all over again. I guess it's hard to kill that which is solid.

Oh, and unlike Crash, I want to learn Lisp but time is always against me. It seems that it's hard to balance a vibrant social life with coding.



I quickly looked up Grails on wikipedia. It was RoR inspired and there seems to be little deviation between RoR and Grails. For example, the mantra "coding over convention" is a similar mantra to Rails' "Convention over Configuration". I'm not sure if Grails lets you specify routes, RoR does. I'm pretty sure Grails supports Apache and other J2EE servers, whereas Rails tends to run on Rack but you can also use node.js and other http engines.



I don't think so. In Ruby, everything inherits from BasicObject (Ruby 1.9 or just Object in Ruby 1.. I wouldn't be surprised if the meta-programming model for Ruby doesn't extend outside of the object system. However, there are two main ways to do meta-programming in Ruby: method_missing() and define_method(). I'm not too sure on how both work, I'm still in the early chapters of Ruby, but from what I've seen, it's pretty powerful (Rails' ActiveRecord is built on method_missing()).

[quote="CrashTECH"]Lisp makes me want to throw kittens in a wood chipper...

hehehe

I'm impartial to languages and paradigms. Though Lisp does make me nauseous with all the parantheses, but honestly, curly braces aren't any better.

I say they are better.... you don't have to surround everything with braces like you do with parens in LISP.

LISP went overboard with that. It is annoying and insane.

Rereading this, I started to realize something... for programmers who predate threads, the only method for concurrency was to use multiple processes, shared memory, and other OS resources for concurrency. The OS was basically the only concurrency API that they had available. Now someone could (and probably did) write a better framework for handling concurrent apps, but these old-timers were also very concerned about compilers, APIs, etc. Just compare the size of the C std lib to C++ STL to have some idea about how many of the early Unix guys worked/thought.

Trust me... they quickly grow on you. =)

Lisp syntax is dead simple....
(fn arg1 arg2 arg3... )
The paren starts a function, followed by the function name and args then a closing paren. It couldn't be simpler. Type less, think more... =)

Also, the way that the parens are arranged actually saves TONS of vertical space compared to standard {} languages because you're not forced to have 30% of your code containing { or } on a single line. It is a feature... really.

Couldn't Lisp (and Python) programmers say the same thing about having to end every of code with a semi-colon?
How about having to separate args with a comma?
All of those lines that only contain a } are pretty annoying, right?

And if we're going to gripe about something _worthwhile_ ... =)

How about not having optional args with default values, args assigned keywords, or multiple length args?
Really... I can't define a function inside another function?
Or... pass a function as an arg?
Or... return a function either?
Or... about 50 other things... =)

Are you really sure about all of those gripes?

My IDE can insert opening and closing braces and parens for me. The semi-colon is really a non-issue. One keystroke with marginal distance from where my fingers are

I feel like we have talked about Lambda functions before.

Functions as parameters can also be done: http://stackoverflow.com/questions/3622 ... s-argument

Honestly, I don't come across a need for this most of the time. What do you mean by multiple length args? Like a varying number of them? List<T> will take care of that for you... you could even make a List<object> if you wanted to and then use typeof to get the type of data...

Why on earth would you return a function? Isn't the end result the value of the function? You can do that too, so long as the types match.

Sure, a little different, but whatever. It is basically the same.


The grip I have is the way you are required to put the parens around EVER statement. It gets hard to make sure you have the right number of parents in the right places. Ending each statement with a ; and putting it on its own line is much easier to debug (IMO).

Just out of curiosity, what is the largest LISP program you have had to maintain for a significant period of time? I just want to see if my experience can be comparable in terms of "size" (lines? Characters? I don't know how to make a "fair" comparison).

well you could you use the param keyword in a method argument, however, the argument converts



I didn't realize you can do that in C#? What are you doing, returning the delegate? Just curious.

Abbreviated code, returning the result of a function (Which I would imagine is the END result of a desire to return a function from a function). In any event, this is the most 'abstract' I see you needing?


Otherwise, you could just return a delegate. I don't see why you would really need that though?

I'm sure there's a need for it somewhere.

Unfortunately, I'm not that smart, so I'll leave it up to someone else to provide an example.

Uh, you do realize that a paren is a single keystroke too, right? =)


Yes, we did. But I didn't actually bring up lambdas this time either. You did.
Speaking of lambda functions, I don't think you provided the same links last time because I came away with the impression that C# lambda functions were basically just an alternate function definition syntax (now that I'm thinking about it, I believe it was someone else that was doing most of the 'talking' last time). In the stackoverflow examples an anonymous function was defined in the diff function. There was also an example of a delegate being defined and used inside of a function. Why does C# use two names for essentially the same thing? Delegates are functions, right?

I didn't see anyone returning functions (someone did mention that returning a Func<double,double>... I'm assuming that Func is the function meta-class in C#) or composing functions (eg write a function that given g(), f() and x returns the result [or function] g(f(x)) ) although I suspect both are possible, but slightly inelegant in C#. Perhaps we'll start a different thread doing this type of comparison sometime.


Sure, a list can hold the args. The problem with this is...
If I'm the API writer, I either have to create two functions... one using the list input and one without (or half-ass the API design and only write the list one).
If I'm the API user, I have to instantiate a list and populate it with the arg values in order to call the function (which is usually is time consuming in Java like languages*). I don't know about you, but ""I"" really prefer languages that WORK WITH ME, not AGAINST ME! =)
*Even Prolog has easier to use list facilities than Java & C++ (and I suspect C# as well).

Below is an example of optional/default argument values... You can achieve the same thing using method overloading, but I don't think it is nearly as elegant.


Well, your link had an excellent example... what if you're writing a Mathematica type application? You're going to need a function to return the 1st, 2nd, and nth derivatives of a function, right? You can't just return the value either. What if you're doing some really complicated distributed simulation. You might have one node responsible for creating (or preparing) 1000's of differential equations (or systems of equations) and using 20 other nodes to solve them.

Another example is something that DJ and I touched on earlier involves meta-programming. If I'm writing an API and can 'write' 10 functions by writing one function to create them, I think I'll go that route rather than writing all of them by hand. You can't do meta-programming if you're not able to return a function (or in 'static' OOP languages the method / class / interface / package equivalents).


A lot of people feel that way. The problem is that most people's only exposure to Lisp occurs in a AI class where the instructor 1) doesn't program in Lisp, and 2) doesn't have a good Lisp environment setup. Trust me, auto-paren matching has been around the Lisp community for a very long time. For an excellent exposure to the language, you should check out the SICP videos. I'll go out on a limb and say that by the fifth class, they're going to be doing things in Lisp (Scheme actually) that will have you stumped in C# (and keep in mind this was the very first CS class these students are taking).


Even more importantly than the apples/oranges problem of lines vs characters when comparing two (very) languages is the type of programming that we do. Most of the Lisp code that I've written while working for a company, which is the smallest portion in total, involves hooks into emacs and small utilities to save me time doing things by hand (yes, me... C programmers do an absurd amount of stuff by hand bc they don't have a large lib available). The code that I've written for my academic career extremely algorithmic in nature, which translates to very small in size compared to business apps, but far more difficult to comprehend (You'll probably recall our previous "big dumb apps" conversation"). Things like performing word sense disambiguation and computational geometry among others. Also, quite a few of those apps utilize multiple languages/environments (eg the WSD code parsed a dataset file and spit out a matrix in matlab syntax, I then took the SVD of the matrix in matlab, and read that back into a lisp env for doing the WSD). My poker software is probably my largest lisp project (I would estimate it is in the 4K neighborhood and w/o macros I'm sure that would explode to well over 10K).

The other big difference is the way people write applications. I tend to write far denser code and far more ambitious software than nearly everyone that I've worked with at companies (on business type apps). They just don't have nearly the algorithm/ai/meta-programming background (I don't know how many times that I had to explain the halting problem can't be solved at Boeing... maybe 6? Or that 'parsing a word doc is not AI'... 4?). When I first started working at Boeing, I 'inherited' a rules-engine application that was approaching 40K SLOC with ~60 XML files and ~60 Word docs (the spec docs for the XML files). Compared to some of the other business apps that I've seen, the code was actually pretty normal (ie written by people that scrapped through an average CS program getting by on Cs and Bs). After my buddy Andrew (who is working on his phd @ UNC now) and I had finished rewriting the application, we were down to 3600 SLOC, 60 XML files and 0 word docs (we generated pdf spec files from the xml). To top it off, we actually provided quite a bit more functionality than the previous version as well (and it actually worked correctly). I repeated the feat a little later with a smaller application that was actually a mess (this guys was a D student... I hope). The original took over three minutes to create a 'database delivery' whereas my version did the same thing in under 6 seconds (w/o using threads, they decided six seconds was good enough and cut the project short).

Just out of curiosity, what are you actually trying to compare? Lisp certainly has 'programming in the large' facilities like packages and system definition functionality if that is what you're wondering.