Selecting a powerful programming language for a project

I have an ill-defined project, whose precise definition will need help from powerful concepts provided by strange and/or powerful programming languages such as Haskell, LISP/Scheme, O’Caml, or Prolog.
To be fluent with such a language, I need to invest some time learning and mastering it. Only then will I be able to determine whether it is really useful for my project.

So my Wish of the Day for today is for a selection guide, which lists a series of questions about the project and then makes a reasoned recommendation for one of the powerful languages for that project. For example, if one of those languages is indeed beautifully abstract but is poor in having runtime libraries and does not provide for linking to alien libraries (imported from mundane languages such as C, Perl or Python), then the language is ruled out for a project, which needs extensive support for manipulating XML files, playing with sockets and doing direct file I/O.

RSS feed | Trackback URI

2 Comments

Comment by moshez
2005-11-10 07:47:13

Haskell: Pattern matching, C++-like templates which actually work correctly.

Lisp family: macros, programs-as-data

Scheme: continuations

Common Lisp: Incredibly powerful object system (multi-dispatch and more)

Prolog: Automatic deduction (which includes inverting and composing relations)

I don't know much about O'Caml, though.

Other languages which have constructs you did not mention: Sather and Icon have semi-co-routines (kind of like non-pre-emptive threads except less powerful and more intuitive).

(You can think of the above as almost a selection-guide, for the specific subset you mentioned: “if you need continuations, select Scheme”, etc.)

Can you say what kind of constructs you had in mind, if it's not a secret? :)
(http://livejournal.com/users/moshez)

 
Comment by tddpirate
2005-11-10 08:05:21

Pattern matching, with the following complications:

  1. General rules apply only most of the time, not all the time - there are special cases.
  2. Whether a pattern matches at one place depends upon the context (i.e. whether another pattern matches at another place).
  3. The system involves also human feedback - when mismatch occurs at one place, the human user adds a new rule which caters to this special case and other similar special cases.

Think, for example, of retrieving a body of text and splitting it into sentences (taking into account complications due to quotes and text in parentheses (including nested quotes and nested parenthetical text (as in this example))).

(http://livejournal.com/users/tddpirate)

 

Sorry, the comment form is closed at this time.