Maximum PC

Anyone read that book? It's from Pragmatic Programmers.

Essentially, the goal of the book is to expose you to different types of languages: static/dynamic typing, OOP/Functional, Prototyped/Non-Prototyped. You run through seven languages, one per week, for seven weeks. I'm contemplating buying the eBook and reading it in my spare time. The languages are very interesting:

- Erlang: I didn't realize that someone had already built a highly distributed, highly scalable language. I was like "WTF?" when I saw the description. Here I am, banging away on C# with concurrency and parallelism patterns. Erlang does it for free and has done so for years now.

- Prolog: The original OLAP. It seems prolog's less concerned about data and more about processing logic as data. It kind of builds on the idea of "code as data" whereby the logic is what needs to be addressed given a set of facts and inferences (sorta like OLAP).

Anyways, I'm currently working on a financial app here at work. I'm using C# and SQL Server to build this app. It didn't occur to me that the way we build apps is the following: we look at the problem domain and we try to make our tools fit around the solution. I came to think about this because I'm building a rules engine for this financial app (which I have the lovely opportunity to work on by myself). When I realize that I'm only inferring logic, not data, my head began spinning with the amount of work I need to do.

Anyways, if I were able to use the appropriate tool for the job, I would write the backend using Erlang, the rules engine in Prolog, the interface in Ruby on Rails and use Perl for operational glue. It seems counterintuitive to use multiple languages, but aren't programming languages designed to tackle specific types of tasks? Chime in, let me know what your thoughts are...tell me if you read this book. We need this part of the forum to have a spark of life!

I think programmers are taught to use a very limited set of tools and that is a hindrance to their ability to solve problems. You've outlined this very well.

Most problems are solved using a variety of tools. A car has an engine to provide propulsion, a hydraulic system to provide braking, a mechanical system with hydraulic assist to provide steering, etc.. Imagine if automotive engineers only used combustion engines to address all of the requirements of the modern vehicle?

I also think that the problem has a 'chicken v egg' component. Since programmers tend to use a single language or toolset to solve a given problem, interoperability between toolsets remains limited. You can use .NET and its various languages (as a complete toolset) .. but if you want to add Erlang or Prolog, you have to spend time designing an interface between the .NET toolset and your new tools. This .. is annoying.

Either way, either language or framework are limited. Plus I don't think management will let me run an Erlang/Prolog backend - they may get confused.

With this in mind, I've been looking into Ruby. There are languages that do message passing, like objective-c (objc). Objc has message passing; classes aren't necessarily bound to their methods, rather, they are resolved at run-time and messages are passed.

Ruby has a whole thing for meta-programming whereby you can dynamically generate methods in run-time. Looking at the Rails framework, it makes use of this method, for example, in ActiveRecord, you can create a virtual property:

:password = { :minlength => 6, :maxlength => 40, :requires_confirmation => true }

You literally create a property in run-time called "password" with a confirmation field called "password_confirmation". This kind of thing is not easily achievable in languages like Java or C#.

So now, the question remains: what would you use a language for? Why do you think it's suited for that kind of application?

I'd like to start a discussion.

If I was writing a game engine. I'd use C++ for the game engine and anything that needs raw speed. I'd use c# for loading and unloading files of any kind, perl for a dedicated server, Lisp for the ai, and straight assembly because I felt like it.

So your game would be a cluster fuck of garbage? Why on earth would you mix that many things together?

It would all interop really well until the Lisp comes in. Not sure how i'd get lisp to interop with C++ hmmm.

WTF? This is beyond clusterf***, it's even beyond garbage. I'd keep everything in C++, since we're talking raw speed here. Why would I use LISP for AI? The AI doesn't have to uber-sophisticated yet you're going to use LISP when:

1. LISP isn't known for speed
2. Using a secondary language will totally throw off the speed category you've been vying for in C++

C# for loading/unloading files? WTF? Do you even know how to code in C#? Perl for a dedicated server? Clearly you don't program.

Aside from C++, I'd use Erlang for dedicated servers (IIRC, WoW servers use Erlang). I don't understand why you'd code a highly available, fault tolerant system in Perl when Erlang can get the job done.

Oh, and thanks for totally sideswiping what would have been a relevant conversation. /rant

Because he has no clue as to what he's talking about.

There .. fixed that for ya bro.

Perl is great for parsing text and confusing undergrads.

Now .. I hate to get all 'moderator' on ya'll .. but try to keep the comments constructive and on point. No need for personal attacks .. you can just toss the fresh meat into the Break Room for that.

OK, will do captain.



You know, I wrote Perl back in college...it even confuses me, and I'm well passed undergrad days. Perl's great for operational glue, IMO. CRON + Perl = awesome. However, if I need something distributed, fault-tolerant and concurrent (like a dedicated server for a game), I'd definitely go Erlang.

Yeah .. as a 'glue' language, I've also found it quite useful.

I've never used Erlang but the more that you talk about it, the more I want to give it a go.

Indeed. I can see why the author of the book previously stated added Erlang to the list of languages. Prolog's another interesting one. It's a total break from your everyday language. My interest in programming language has grown. LISP is an interesting one as well, a programming language built entirely out of lists and other list-like data structures. It takes the concept of "code as data" into a whole new realm.

I am considering picking this book up as well...

I can see myself buying a lot from those guys... /sigh

Have you purchased any books from them in ebook/pdf form before?

Ebooks for reading on the bus! They are fantastic.

No, not yet. I have an iPad from which I can read ebook/mobi files from. I'll buy it, will let you know what I think!

Just got my Nook Color last night. Already booting Honeycomb off the SD card

So far, color me impressed. If you like the book I'll probably pick it up.

First, I know this thread is old, but I think it is by far one of the better ones posted on this forum (esp considering usual language discussions), so I've decided to throw in my 2 cents. I'll get to my thoughts on the book, author and similar material in a followup post. There is already enough material to keep me busy for a few minutes.


Yes! This is what old time LISPers call the "aha moment". One of the LISP approaches is to use language abstraction: write your own language that is suitable for the problem domain. Different languages favor different approaches and which is most appropriate is a big depends, but the critical insight is to not get sucked into the other way of doing things (ie using a hammer with screws). It is ironic. If you were to poll software engineers about why this happens, I think the most common response would be something like "this is just the way it is...". The vast majority of developers never get to this point and it really shows. They spend their whole lives trying to make a car using a hammer and chisel. Most never stray from the familiarity of writing procedures in a imperative language (except for SQL queries and shell scripts).


I totally agree with the spirit of the statement, but I think that it is very important to realize that it isn't using a certain language(s), but rather appropriate abstractions and concepts that is critical (eg "while the rules engine is well-suited to logic programming, the UI will require a web framework with the following features...").


I disagree. First, I don't think that is counter-intuitive. There is an old saying in the LISP community that inside of any reasonably complex C application is a badly written LISP implementation -- doing THAT is counter-intuitive to me! Use one or more appropriate languages as necessary... don't write crappy XML parsers in C like "the people of Boeing" do bc the only language you know is C (this should be the definition of dumb). Second, there is clearly a place in the world for "general" and multi-paradigm languages. Languages that tackle very specific domains are nice, but they obviously have their limitations (otherwise they'd be general languages). Just imagine if there weren't any general languages!

While the obvious real-world problem is our bosses often want us to "just write a rule based system in C# -- don't over think it egghead -- besides, all languages are the same because someone who once read the back cover in a software engineering book told me so" instead of using Prolog, it is also important not to fall off the other side of the cart because we'll end up having to glue together eight languages for every large app. Yes, I can be pragmatic. =)

I'll get to the actual book review, some thoughts on Prolog (amen!), and Norvig comments/essays after I whoop up on my brother at poker... he's a sucker-fish in high-low games.

Alright, the author of the book is Bruce Tate, who wrote a somewhat controversial book on Java a while back. It's been a LONG-TIME since I've read that book, so I don't remember the details, but I wasn't very impressed with his arguments (ie he didn't remind me of a Peter Norvig where it is just absolutely clear that this guy really knows his $h!t) or what I felt was an obvious attempt to sell books by causing a pointless flamewar. Yeah, small businesses don't need and shouldn't use the J2EE stack. It is overkill; We didn't need you to write a book telling us about it. That said, I'm willing to give him an honest try...

From the introductory chapter: Clojure’s multimethods will even let you implement your own paradigm.
Doesn't sound quite right. This is pretty far adrift from the usual C++/Java/C# concepts, so let me provide some background info. Multimethods have been around the Common Lisp community since CLOS (Common Lisp Object System) and are a mechanism for determining which generic function (similar to a method) is dispatched. I don't want to get into the differences in OOP between Smalltalk/CL and C++/Java ... trust me, they're very different... just know that "methods" are not encapsulated in an object in these languages.

What does this have to do with Clojure? Well, Clojure is a CL derivation running in Java (a loose, but accurate enough, description) and multimethods are the same concept/mechanism as in CL (I double checked). What I think the author meant to write was is that the Clojure macro system can be used to create your own paradigms like multimethods. This is how CLOS was added to CL; You could add AOP to CL using macros as well. Then again, maybe I'm not thinking hard enough about multimethods. Either way, it is a compelling read so far.

The intro chapter ends with a discussion of the seven languages and some comments on why they were chosen. Like most people, I would have probably chosen a slightly different subset of languages, but I can't fault his choices either. For example, I would like to have seen a mathematics oriented language included, but I guess that might be going into the DSL area a bit too far for most readers. Also, I think it is important to know programming language history/influences and would have loved to see Smalltalk and CL on the list; I hope he spends some time commenting on how these newer languages are influenced by their ancestors.

Io - day 1 is an interesting read. Being day one material, the examples are relatively basic with the promise of metaprogramming in the near future. Cool! The language is part Lisp, part Javascript, which I think most people would find to be a fairly unlikely combination. Could you imagine telling a friend that you were going to create this language: "Hey, I'm going to write this new language with a very simple syntax like Lisp, it'll have first-class lists and maps (like Lisp), dynamic types, and an object system similar to Javascript that passes messages like Smalltalk." I think the most likely response would be "DUDE, HOW MUCH ACID DID YOU TAKE LAST WEEKEND?!"

This is off to a better start than I expected and I'm looking forward to the Prolog chapter.

WRONG!!!! It takes your MIND into a whole new realm!!!! =)

Logic programming is equally fascinating. I've been programming in Prolog, off and on, probably a little more than a year now. I'm still amazed by the insight/realization that logical statements could be manipulated to achieve computation. I was planning on writing a post about Prolog earlier today, but this thread has me side-tracked. Maybe tomorrow.

Prolog - Ah, Prolog. Sometimes spectacularly smart, other times just as frustrating. You’ll get astounding answers only if you know how to ask the question. He absolutely nailed the introduction. In fact, I was going to start a post on Prolog with how everything seems to be either incredibly easy or frustrating (and then maddening when you realize how obvious the solution is).

Again, the intro material is very easy. I think that the map coloring problem was a very good problem choice. It captures much of the essence of logic programming and is easy to contrast with imperative programming languages. Day 1 is a good first introduction to the language; However, I know that all of the material covered here is available in Prolog tutorials on the web. Also, you can find plenty of used Prolog and logic programming books on Amazon for $4 (ie mostly free + S/H). If your goal is to learn Prolog or logic programming, I would suggest buying used books instead of this one. I suspect the same thing is true of any individual language or paradigm.

So did anyone purchase this book? If so, how complex are the day 7 examples? I read every review on Amazon, and not a single one lists them! It is certainly a better book than I expected, but I don't feel compelled to spend $20 plus on it when there are just so many great used books available. After all, a language like Smalltalk may be 20+ years old, but if you don't know it, then it is still new to you! I added it to my list and will look into getting a used version someday.