Anyone read that book? It's from Pragmatic Programmers
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.
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.
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).
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.
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...").
It seems counterintuitive to use multiple languages, but aren't programming languages designed to tackle specific types of tasks?
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.