Slashdot Mirror

All real Haskell code uses the "layout" rule, in which whitespace is meaningful, bit it's entirely optional, and defined by translation to the whitespace-free language. See section 2.7 of the Haskell 98 Report.

So, yes, Haskell is perfect, except: even if God plays dice, there is absolutely no way he uses n+k patterns.

All real Haskell code uses the "layout" rule, in which whitespace is meaningful, bit it's entirely optional, and defined by translation to the whitespace-free language. See section 2.7 of the Haskell 98 Report.

So, yes, Haskell is perfect, except: even if God plays dice, there is absolutely no way he uses n+k patterns.

1. Write simple code in a language that the course instructors had thought up themselves: SL (Simple Language)
   
2. Load an interpreter which was written using the UU_AG attribute grammar system, which in turn is written in Haskell (you first had to load UU_AG in Hugs98 (a Haskell interpreter).
   
3. The interpreter would produce SSM code.
   
4. You could then load the SSM code in a SSM java program, where you could see the result of your SL program.
   

I've been learning Haskell for my Computer Science degree (it's a purely functional language).
Having no looping structures (other than recursion) and embedded IFs has transferred to my sex life.

I get in fast, achieve my goal, and get the hell out...

All of those are much slower than the equivalent C code.

Proof? Of course, there cannot be one, but if you like benchmarks, compare the Great Computer Language Shootout. Though C "wins", I wouldn't exactly call it "much slower".

They all use byte-code or generate C code, then compile the C code.

Wrong. For all languages I mentioned there are native compilers available. For all (AFAIK, not sure about Standard ML), there are also bytecode compilers available, for some also compilers to C.

BTW, nobody would ever be so stupid to first generate bytecode, then C out of this (At least I hope so). Oh, and assembly isn't what you compile to in the end, thats why there are assemblers.

None that I know of generate assembly language directly.

If you talk of generating native binaries directly, you surely should try to get to know more. Here are a few:

• OCaml
• Standard ML of New Jersey
• MLton
• The Glasgow Haskell Compiler
• NHC 98
• CLisp
• CMUCL
• Stalin

It's not clear what kinds of areas you are working on, so its not easy to recommend a tool.

Personally, I use C/C++ for general purpose apps. Nevertheless, for text/scripts Perl is hard to beat, for objects/GUIs Python is amazing, and Haskell wipes the floor with all the other languages on numerical/functional work. (OK, I admit, I have no life).

In terms of tools,

DevC++and Cygwin, work well for C/C++ development, and together form a nice little set of tools.

Perl can be found at CPANwhich has links to various interpreters and IDEs. It is a language of crazed brilliance, and is wonderfully cross-platform.

Python is really great, comes with a very well-thought-out IDE (IDLE) and a very familiar syntax. It has standard modules which will link it to C++ and Windows.

And finally, Haskell is at Haskell.org, and offers Hugs, which is probably the most advanced open-source IDE available for any language.

With so many wondrous open source tools available, I feel pretty bad about saying this, but your best bet in a corporate environment might actually be Java. It's boring, it's a little slow, its overhyped. In short, it is the Devil and whenever I have used it, I have wanted to kill myself and my neighbours. Still, its free, popular and backed by a big old corporation, its very similar to C++ and you won't get fired for choosing it. Best go with Java.

You want overloading? Great, but type inference goes out the window.

Why do all industrial developpers stick with low-level languages like C and C++ (yes, a language where the programmer has to take care of memory management is a low-level language), or only use aberrations like Java (who got this freaking idea of using bytecode for real programs) ? These languages are among the heaviest and most bug-friendly ones.

My utopic advice to industrial developpers would be to use high-level reliable and humanly maintainable languages. I am especially talking about strongly-typed functional languages. These are actually the ones that take advantage if the strongest theoretical foundations, which provides them with a thourough understanding. For one thing, strong typing is an impressive way of getting rid of implementation bugs. And most importantly: pure functional languages make proofs of validity humanly affordable. Talking about object programming, several FP languages provide OO features in a really powerful way. The one language I am currently a huge fan of is Haskell. I actually made some middle-sized stuff myself with it, and I was impressed how fast I got clean and elegant results.

A frequent criticism towards these "academic" languages is the fact that they lack common libraries and that their standards are evolving. I think that if industrials dared to use such languages for real applications, this problmes would quickly disappear thanks to the work of a handful of pioneers, leaving a beautiful world of elegant and efficient languages to future generations.

Well, stop me now, I'm dreaming...

You should check out OCaml. It is a modern functional programming language. It has parametric polymorphism, as well as subtyping polymorphism and dynamic dispatch, is garbage collected, features an advanced module system to help you structure code, and ports are available for all the usual platforms.

In addition, OCaml interfaces well with Gtk (including using Glade to design GUIs), has database libraries, as well as all many other libraries that one would expect.

OCaml can be either compiled to a portable bytecode, or directly to machine code. It compiles to very efficient code, and it is popular folklore that it can easily match C in terms of execution speed in many circumstances.

The language is at a good point in its evolution right now to be used in commercial circumstances. It has been around long enough that it is well-understood and a lot of useful libraries are available, and its compiler is very robust, but at the same time it is not so old that a lot of the really new and interesting developments in language design haven't made their way into it. Although I prefer Haskell for small one-off programs, I would use OCaml for large projects.

Another language which has had great success in industry (especially telecom equipment, as it was developed at Ericsson to write million-line switching software) is Erlang. Although I have not used it myself, its proponents swear by it as the best tradeoff between elegant PL theory, and the reality of writing large software.

You will note that my recommendations all have a functional programming slant to them, and this is only due to my own preferences. I have not kept up with developments in OO language design, and so I cannot recommend one readily.

If I may step on a soapbox for a moment, however, I would like to say that especially for the design of large systems, a strongly-typed modern funcitonal programming language with a good module system is a very good solution, to rival OO Design Patterns. As modern type systems allow you to express very precise invariants about your modules' behavior, they can be used to help many programmers together write large pieces of code that can then be checked at compile time to behave in a consistent manner. This can save both development time and money. Those are good things.

Haskell, unlike Lisp, is a true functional programming language in that it only makes use of function abstraction and application for expressing computation, while Lisp uses sequencing of commands and assignments. Not only that, Lisp uses a form of evaluation which is not strongly normalizing, while Haskell uses lazy evaluation, which is commonly known to be strongly normalizing. This means that I could write the same function in either language, and the Lisp version would never hault (i.e. lockup, infinite loop, diverge, etc), while the Haskell version would run correctly to completion.

In addition, Haskell has an extremely powerful mechanism for catching software errors/bugs: a polymorphic type inference system. You don't even have to type the variables or functions yourself, the compiler can figure them all out automatically. This is a great form of software verification. Lisp is untyped. The point is that Lisp shouldn't be the poster-boy for Functional Programming. Haskell is far sexier. Haskell is free, well documented, and there are several good introductory books on it.

Basically my point is that Lisp should be taught as a language with a historical value, but when you want to teach someone functional programming, teach them a purely FP language like Haskell. http://www.haskell.org

Personally, I could give a damn about .NET/CLR and especially the appearence of FP or declarative languages on that platform. Most of the users of .NET/CLR are going to only know how to and only want to know how to program in one of two languages (C# or VB). I like to call that type of programmer "simple".

Haskell has no assignment to variables, because of one of the most important properties of functional languages (though not obeyed by all languages calling themselves functional):

• A function called with the same arguments will always yield the same result, no matter what.

I took a look around and found this link to a guy called Don Syme at Microsoft Research who appears to be working on just this.

There's also the Mondrian project, which implements Haskell.

I took a look around and found this link to a guy called Don Syme at Microsoft Research who appears to be working on just this.

There's also the Mondrian project, which implements Haskell.

Haskell and Hugs would be good choices: the wonderful thing about functional languages is you can create a very high level of abstraction, which is great for solving maths and engineering problems. Go to: http://www.haskell.org

Lisp/Scheme and ML would also be good choices.

Currently, there are two versions of Lava in use. One, Chalmers-Lava, developed at Chalmers University of Technology in Sweden, is mainly aimed at interfacing to automatic formal hardware verification tools. The other, Xilinx-Lava, developed at Xilinx Inc., is aimed at generating configurations for Xilinx' FPGAs. We hope to merge these two version soon.

Currently, there are two versions of Lava in use. One, Chalmers-Lava, developed at Chalmers University of Technology in Sweden, is mainly aimed at interfacing to automatic formal hardware verification tools. The other, Xilinx-Lava, developed at Xilinx Inc., is aimed at generating configurations for Xilinx' FPGAs. We hope to merge these two version soon.

For a fact, the exact implementation may be diferrent from one might imagine looking at the source, but it's the property of lazy pure functional languages with their equational reasoning and other optimizations that are possible under that paradigm -- but the optimizations never affect the halting property of the program or computation results.

Which, unfortunately, cannot be said about the old school languages like C, C++, .NET, Java, Fortran, Scheme etc. etc.

Feel encouraged to read about some functional languages semantics. The SMLofNJ homepage, and Haskell definition might be a good start.

It is not inconceivable that in decade or two we will be able to provide a program with a design document written in prose and have it generate the program.

We're damn close. Programs can already be written as specifications of their output in functional languages that approximate algebraic notation. In fact, a particular programmer's boss once confused a program written in the Haskell language with a design document, asking "Where's the implementation?"

"Umm..." (runs a Haskell compiler) (runs the binary it produces) (correct answer appears)

"I've heard of programming computers in English on Pick OS, but this is something else."

You may want to check out the extension library we (Sjoerd Visscher and I) have created. You can find it over at http://w3future.com/weblog/

This library, called Beyond JS, provides functional programming features for JavaScript language. Since JavaScript is based on Self, you get the benefit of both these "obscure" languages

We have yet to document this library, or QAed it sufficiently, but we are giving the source for free. You can get both the lib and some sample code from here.

An example of what can be done with beyond.js. First an example of some Haskell code, which is a used to explain some of the benefits of Haskell:

With beyond.js, this type of code can be done in javascript too. This is the code to add a qsort method to arrays:

Here is another sample:

Although both these samples use a version of the lib that is slightly newer than the one currently online, they do demonstrate its design and features.

We invite everyone to try it out. At the very least it should give new perspectives on what can be done with JavaScript.

I mean really, in Haskell, "factorial" looks like this:
fact 0 = 1
fact n = n * fact (n - 1)
Write that, and "fact 20" works just fine:
Examples> fact 20
2432902008176640000
Examples>

However, implementing Haskell (or Self) on a von Neumann architecture is non-trivial. Implementing an efficient compiler or interpreter is tres difficil. People get Ph. D. dissertations for that sort of thing. For someone deeply used to C, Haskell and Self are perverse.

To wit:

• In Haskell, nothing changes. Ever. State change is handled by creating a new state from the old one. Semantically clean, but about as far from C as you can get.
• In Self, anything can change at any time. Yes, Virginia, you can redefine "if-then" whenever you feel like it. Change the inheritance hierarchy? No problem! Whoops! I made a cycle in the inheritance hierarchy! No problem! (yes, A can inherit from B and B can inherit from A). Think of C without the reliability that any particular operation (function call, operator, whatever) maps to the same place more than once. This kind of thing gives most C-family compilers hives. It used to be that C++ was perceived as significantly slower than C - I don't see anyone complaining about it anymore, but Haskell and Self are more extreme examples. C++ made it easy to use jump tables. Haskell makes it easy to use recursion, lazy evaluation, and a bunch of other things. Self makes it easy to use dynamic inheritance, multiple inheritance, even cyclical inheritance.

• Full source-level debugging
• Garbage collection
• Checks for stack and integer overflow
• and the ability to change the "class" of any object at any time (I put class in quotes because Self is an object-oriented language without classes - part of the super-simple semantics)..

No way, Lisp is way outdated, and it isn't even a pure functional language. People will want to use Haskell, Erlang, or Goatsex instead.

Hugs is an easy to setup interpreter, ghc is a good compiler, with an accompanying interpreter.haskell.org is a good place to start.

Now another difference between Haskell and usual programming is that it's lazy, meaning that expressions are only evaluated only as needed to produce the result (think the behavior of && in C, applied to the whole language). This is a rather cool feature, but it makes wrapping your head around haskell even more difficult, because it's not easy to tell how a Haskell program executes.You can also try a more traditional strict functional language like Ocaml, for size!

Hugs is an easy to setup interpreter, ghc is a good compiler, with an accompanying interpreter.haskell.org is a good place to start.

Now another difference between Haskell and usual programming is that it's lazy, meaning that expressions are only evaluated only as needed to produce the result (think the behavior of && in C, applied to the whole language). This is a rather cool feature, but it makes wrapping your head around haskell even more difficult, because it's not easy to tell how a Haskell program executes.You can also try a more traditional strict functional language like Ocaml, for size!

Hugs is an easy to setup interpreter, ghc is a good compiler, with an accompanying interpreter.haskell.org is a good place to start.

Now another difference between Haskell and usual programming is that it's lazy, meaning that expressions are only evaluated only as needed to produce the result (think the behavior of && in C, applied to the whole language). This is a rather cool feature, but it makes wrapping your head around haskell even more difficult, because it's not easy to tell how a Haskell program executes.You can also try a more traditional strict functional language like Ocaml, for size!

For example, Haskell parses f 0 + f 1 as: f(0) + f(1) (In a less obvious way, it also parses f g x as f(g, x), but that's another story...)

You are pondering creating such a language or using one ? Anyway have a look at Haskell and other functional programming languages.

I really recommend that you do sit down with Haskell. IMO, the judges were correct in naming it language of choice for "discriminating hackers". It has:

• clean, simple syntax (parentheses are used only to override default infix operator precedences, nothing more), including excellent list construction and comprehension;
• a strong object-oriented type system which ensures that the vast majority of coding errors result in a type error (although it can take a little while to get used to Haskell's type system);
• lazy evaluation of expressions: only the parts of your program needed to produce a result are evaluated, which allows you to write programs that left to run would produce infinite computations (e.g. programs to calculate the Fibonnaci series or the sequence of primes) and only evaluate them for the subset of data you need; and
• partially applied (or curried) functions: you really need to see these in practice, particularly in conjunction with the standard list-processing functions (e.g. map, scan, and fold) to understand their true power (the ability to create lists of partially-applied functions is very cool, although I have no idea how such things might be used).

With regard to your qualms about lack of use, I understand Ericsson have created their own functional language for in-house use (the name escapes me). Arguably, since we've all got oodles of processor power to spare, there's no reason not to use functional languages in the general applications sector, given their greater reliability.

If you want more info on Haskell, check out the official website (especially the Ode to Haskell on the humour page, which should give you an idea as to the language's feature set ;)). There you will find interpreters, compilers and other tools for a variety of platforms (incl. Windows and Linux) as well as complete documentation.

There are a variety of languages that people recommend as a first language. My old university used Haskell. It was very effective in a university situation, but because it's kind of obscure you might find it hard to get anyone to help you with it. A lot of people recommend either Python or Java - Python is a nice language, and probably a good choice. Java is also nice, and also apparently in demand by employers, but while much cleaner than C++ has a fair bit of required "boilerplate code" which is required to write anything in the language but won't make any sense to you initially.

Perl is a wonderful language for non-programmers. It's very easy to get things to work in Perl. However, Perl makes it particularly easy to write messy code. If you're serious about programming, it's probably not a great language to start with.

Oh, and as a rule, avoid any book that ends in "for {idiots, dummies, complete fools}", or "in {time X}" - basically, if you're a dummy, you're not going to able to program effectively anyway, and it's not something you can be proficient in quickly. Once you pick your language, go see if there is a USENET FAQ on the language and see what's recommended. For instance, for C++, some commonly recommended books are The C++ Primer, by Lippman and Lajoie, or Stroustrup's The C++ Programming Language (written by the original designer of C++ - a decent book but probably a little dense for the newbie).

Go you big red fire engine!

Why don't I use Ruby?

I looked at it. It's only different from Python/Perl/TckTk in insignificant ways.

If readers really want to learn something different, try Haskell.

Oh sure you will come back and end up using Perl/Python/TclTk with C/C++ like I did, but you will at least know how expressive and elegant a programing language really can be! That is if you can make it past the front door...

In any event, dispite all that, I dont use Haskell either. The implementations that are available leave much to be desired. That is a shame, but it is a research language, and is not at all popular.

But its fun. After looking at it, I have never looked at language wars the same way again. Maybe someday someone will put together a usuable (by the masses) implementation...

Ruby ? Blah.

Cheers!

But it is very expressive, and probably unlike most languages you have used before. For example: It is strongly typed , but you (almost) never have to say what type your variables have! The system infers the types before checking them. And in addition to being OO, it is also functional. (Bindings can't be rebound, higher order functions, map ....)

OCaml is certainly not the 'language to end all languages', but you will learn something from learning it.

However, these languages are very difficult to learn and this can get in the way of learning other facets of programming and computer science. This learning curve impacts the learning of the general problem solving skills needed to work outside the limited world of discrete finite machines, such as in networking or inter-personal spaces. Java solves some of the problem in the OU cirricula by providing a "lite" language. It is a language that does impressive things very easily and that gaurds the programmer against some nasty complexities like platform/compile/library incompatabilities. These are also the reasons it is popular in industry. Languages such as Fortran and Cobol hold on in our Science and Business colleges because of legacy code and the personal perceptions of the faculty. Unfortunately you can improperly teach the problem solving ciritcal to progammin in any language, just as you can properly teach without a language. Classes that focus on getting design and thought about a problem started at least during if not before a project would be much more helpful. Systems such as OO pattern and tools like UML provide much help to the Software Engineer and Computer Scientist alike.

I've worked in the *real world* Perl, C, C++, Z80 assembler (in embedded and non-embedded environments) and Java. Each has a different goal and a different way of getting their. However, irregardless of the path taken, they achieve those golas to a limited degree. Oak, the language that became Java, was designed to be a simple extension of real OOP with a C syntax. Like other embedded languages, most of which are either assemblers or functional strangely enough, it has grown to include methods of getting at the machine and conecpts such as closures. If it adopted lamda calculus syntax extensions, you could use it to teach mathematical therom proving.

However you choose to view the language, as toy, irritant, the next wave, the last wave, et cetera, it is in our CompSci cirricula and it can be taught and taught well. When I went on to my second year of classes I was exposed to C++ for Data Structures and Java for a Programming Abstractions course. Data Structures became a waste of a class trying while to work with a professor who was new to the lanugage. The Programming Abstractions professor knew what was up with Java and so taught us a lot about OO design before delving into the language. I didn't get a lot of help from my time learning Haskel, wich in turn had severly limited my time working with C before moving onto C++.

For what it's worth, learning RCS, and later CVS and UML, helped with my programming more than any of the languages I in which I learned or worked. In the end, these languages proved that they are just tools. Like all tools - Craftsman, DeWALT, GNU liscenses, Sun.Java.*, there will be proponents and detractors and teachers and charlitans. You mileage may vary.

Here's to 5 years of CompSci and counting (with 1 year to go.)

Part of the confusion here is what we mean by "closed languague". I think of three separate things:

• Language has only one proprietary implementation. This is really only a problem if the language has no "standard" (as opposed to a "de facto standard"). Consider an open source implementation of Visual Basic, for example. Microsoft would play with the language definition so the open source implementors would forever chase a moving target. A smart proprietary language implementor, of course, would not do this, but rather would capitalise on the interest to push their own products.
• Kernighan's definition: The standard language is insufficiently expressive for practical use, therefore must be extended. Every vendor's extensions are different from everyone else's.
• The actual language definition is copyrighted and precludes open source implementations.

On the last one, does anyone use Miranda(TM) any more? We used to, back in the days when we had no choice if we wanted lazy functional programming. But now we have Haskell, with at least three solid open source implementations and a number of other research platforms. Even Microsoft has taken an interest (hiring half of the Cambridge University Haskell research group).

There's a lesson in here somewhere.

• ...is standardized - an open standard.
• ...also has free quality open source compilers and interpreters which adhere to the open standard.
• ...uses lazy reduction, which means that a wider variety of functions normalize, as opposed to strict reduction.
• ...is purely functional, which leads to more elegant and easier to understand programs. Formal analysis is allot easier when the language is purely functional as opposed to polluted.
• ...allows for imperative or procedural features through the use of monads. So you can have your cake (purity) and eat it too (imperative/procedural aspects).
• ...uses function currying to ease the use of higher order functions and to decrease the reliance of all those damn parenthesis!
• ...is statically typed and uses type inference too, so you don't even have to explicitly tell the compiler what types you are using. It can do all the dirty work for you, yet still give you very high automatic assurance of program correctness.
• ...is simply better designed. Its syntax, semantics, and APIs are more simple, consistant, and pure than Lisp and its many incarnations.

• ...is standardized - an open standard.
• ...also has free quality open source compilers and interpreters which adhere to the open standard.
• ...uses lazy reduction, which means that a wider variety of functions normalize, as opposed to strict reduction.
• ...is purely functional, which leads to more elegant and easier to understand programs. Formal analysis is allot easier when the language is purely functional as opposed to polluted.
• ...allows for imperative or procedural features through the use of monads. So you can have your cake (purity) and eat it too (imperative/procedural aspects).
• ...uses function currying to ease the use of higher order functions and to decrease the reliance of all those damn parenthesis!
• ...is statically typed and uses type inference too, so you don't even have to explicitly tell the compiler what types you are using. It can do all the dirty work for you, yet still give you very high automatic assurance of program correctness.
• ...is simply better designed. Its syntax, semantics, and APIs are more simple, consistant, and pure than Lisp and its many incarnations.

Many "modern" functional languages, like ML and Haskell, have strong-yet-polymorphic typing and all of the functional abilities of Lisp. Of course, these languages suffer from a derth of libraries, too.

Of course, this is a COM interface for Haskell called Haskell Direct, allowing your Haskell program to call COM and ActiveX controls. This work was done by someone in Microsoft Research and wrote a paper about it humorously titled "Calling Hell From Heaven And Heaven From Hell." ;-)

Many "modern" functional languages, like ML and Haskell, have strong-yet-polymorphic typing and all of the functional abilities of Lisp. Of course, these languages suffer from a derth of libraries, too.

Of course, this is a COM interface for Haskell called Haskell Direct, allowing your Haskell program to call COM and ActiveX controls. This work was done by someone in Microsoft Research and wrote a paper about it humorously titled "Calling Hell From Heaven And Heaven From Hell." ;-)

...then take a look at Eric Meijer's CGI library in Haskell. Using Haskell gives you all the power of a modern, pure, powerful, strongly-typed functional language [oh well, that's lost 99.9% of the audience.] Read the paper here and you can find the source here. With the forthcoming .NET integration this should become easy to integrate with all the other stuff a web site has to deal with.

Does everybody on slashdot think that the only salient feature of Python is that it doesn't use curly braces?

Get over it!

I am being quite serious. If that modest syntax change is enough to keep you from considering a language, you're doomed as a programmer to linguistic provencialism that will keep you from seeing some really elegant ways to simplify and modularize your code. Ever programmed in Erlang? Haskell? Scheme? Prolog? You might end up preferring a more mainstream language after all is said and done, but the experience of seeing the new ways of doing things will certainly make those mainstream programs better.

You'll never get that experience, though, if you get scared by the syntactic differences between those languages and C (which are vast). So do yourself a favor and try to see beyond a language's syntax.

Incidentally, Haskell can also use indentation to indicate structure.

This sounds like the kinds of problems that the concurrent functional programming people love. See Erlang or perhaps some concurrent variation of Haskell like Eden.

Regards,

Zooko

The concept of graphical/visual programming languages is not new, and anyone who claims that it is similar to certain LISP projects are most likely correct, because the Lambda-Calculus has had graphical representations long before LISP was created.

Graphical/Visual programming languages have been a hot area of research for the past 20 years, at least. However, this current approach seems a bit naïve. With any language, you will have representations. To say that a language is representation independent is a paradoxical statement at best. Whether your language represents meaning with three-dimensional graphics, or it represents it with a symbol-string based method, you will still have the same restrictions that all languages share. One of the benefits to generalized graphical languages is that your code can contain far more self-documentation, without the use of additional comments. In a language like the C programming language, self-documenting techniques consist of a few basic constructs like descriptive identifier names (variable names, function names, etc...) and a healthy use of white space (carriage returns and tabs for code blocking, etc...). In fact, it is often considered a bad programming practice to not use a good amount of self-documentation in C. So why not take self-documenting code a step or two further?

Well, just imagine a generalized version of "white space" for a programming language like C from something, which controls a very rigid 2D orientation to a generalized Cartesian 3-space, and you start moving towards a graphical/visual programming language. Generalize the concept of "identifier" from just a plain string of text to a full color 3D graphical object.

There are other more fundamental differences that most visual programming languages have over this simple generalization of the C programming language to a Graphical C., and those fundamental differences deal with the representation of computation. They could choose a von Neumann model, a functional model (lambda-calculus), a mobile model (pi-calculus), or maybe a constructive logic, etc... all of which are popular (read widely used) mathematical models of computation.

So, besides cramming a bunch of buzz words into their language description, and coming close to stating a complete paradox... I don't know why this is supposed to be so exciting.

Don't get me wrong, I love alternative programming languages, such as PICT (based on the pi-calculus) and Haskell (based on pure lazily evaluated lambda-calculus), and whenever a new post is made about a language attempt like Eidola, I laugh and I cry - asking myself, "Why doesn't slashdot ever post news about serious alternative programming languages?"

I am new to programming, so no flames please. Can something like this be ported to Perl? (I am trying to learn it.)

Yes, this can be ported to perl. Anything in C can be written in perl (and vice versa).

C is weakly typed, so I'm not sure what you're getting at here... Strong typing is to save the programmer from himself. I personally do not enjoy programming in languages that remove C's power to make non-sensical casts.

So, I guess what I am really asking is: Is this kind of program only able to be written well in something like C++ or Java?

Absolutely not. This is just an algorithm for calculating Pi. C is nice because it's portable and fast. Check out a functional programming language like Haskell. Selecting a programming language for a particular task involves clearly stating your goals. If I wanted to confuse you, I'd write it in Malbolge or BrainF*ck. If I wanted to calcuate pi quickly (millions of digits), I might write it in C, but I'd also do my homework. If I wanted something from the command line, I'd use:

$perl -e 'for(0..9999){$i=$_*8;$p+=(16**-$_)*(4/($i+1)-2/($ i+4)-1/($i+5)-1/($i+6))}print$p'

It's really a matter of "what gets the job done."

(Besides that I have a feeling that using an object-oriented language (like Visual C++) would reduce the amount of code you would have to write (due to increased code re-use.))

Simple algorithms like this one are fairly atomic. You're foo class isn't going to help you here. You really aren't going to resuse this either. That's what M_PI is for =).

fib 0 = 0
fib 1 = 1
fib (n+2) = fib n + fib (n+1)

Examples> fact 20
2432902008176640000
Examples>

primes :: Integral a => [a]
primes = map head (iterate sieve [2..])
sieve (p:xs) = [ x | x<-xs, x `rem` p /= 0 ]

Now, just in case you think Haskell is only used for dense mathematical expressions, note that it comes with literate programming functionality built in. And the Haskell Home Page has some examples of some quite meaty real-world examples.

I would suggest you download Hugs, start dabbling in Haskell, and read the Haskell Prelude. It is relatively easy reading and contains code that is very beautyful.

I would suggest you download Hugs, start dabbling in Haskell, and read the Haskell Prelude. It is relatively easy reading and contains code that is very beautyful.

qsort [] = []
qsort (x:xs) = elts_lt_x ++ [x] ++ elts_greq_x
where
elts_lt_x = [y | y <- xs, y < x]
elts_greq_x = [y | y <- xs, y >= x]

Don't get me wrong: those systems had their own share of problems, not the least of which was that they required expensive hardware to run well. They also lacked some of the niceties and safety check of modern programming languages (by which I mean languages like ML, not C++).

So, what can you do? Don't blindly use C/C++ for everything. Those languages have their place, but they require you to spend a lot of time on stuff that isn't related to getting the job done. Learn something new, and learn about the history of all this. Here are some suggestions:

• Learn about functional programming with Haskell and OCAML, and SML/NJ
• Learn about logic programming with one of the Prolog implementations.
• Read up on CommonLisp, Flavors, CLOS, and the Lisp Machine Window System. You can get CommonLisp implemenations at cons.org
• Read up on Scheme and get a Scheme programming environment. PLT Scheme looks pretty good.
• Read up on Smalltalk-80 and its programming environment (you can get a so-so Smalltalk-80 implementation at Squeak).

While those systems may or may not help you in your day-to-day work, they teach a lot about what programming can be.

For your day-to-day work, consider using languages and environments like Python, Perl, and Java. They aren't quite as convenient as the more academic systems I mention above, but they still let you focus much more on the problem rather than the mechanics of programming.

...oh, and I forgot to mention that ML nore LISP are purely functional languages, since both allow side-effects AND sequencing of statements, directly in the language. Haskell supplies all of the expressibility and performance gains associated with side-effects and statement sequencing through the categorical concept of monads, reinforcing the purity of the language.
So why not give the language a try? Its free and open! Got Haskell?

• OCaml is multithreaded (linuxthreads was born as a way to get it to work on linux), although a single program won't take advantage of a multiprocessor. Core dump is impossible using its static strong typing, and the optimizing native-code compiler provides with great performance.
• JOCaml is an extension of OCaml based on the Join-Calculus, the latest and greatest paradigm for distributed programming (can be seen as actor-based programming done right, as based on a well-understood algebra). Can take advantage not only of multiprocessors, but of processor farms, or any distributed architecture, even heterogeneous architectures. Only bytecode can migrate, native code modules and primitives must be compiled into the servers.
• Erlang is based on a paradigm quite similar to jocaml, but is designed for industrial applicability rather than hacker coolness; it has dynamic typing, a pure functional core (despite the logic programming syntax, it only has matching, not unification), enriched with explicit asynchronous communication primitives, and an implementation that every phone call you make depends on, if you use British Telecom. If you need tens of thousands of threads and/or lots of nodes, this is what you need.
• There is also Mozart, an distributed implementation of Oz, a real logic programming language (has unification).
• Haskell and Mercury also have extensions for concurrent and distributed programming in the works, but I admit I don't know how usable they are for real programming.

-- Faré @ TUNES.org

I'm sorry, but this is nuts. MFC is the worst example of OO UI that I have ever seen.

If you really buy into Object Oriented dogma, and you want to make an OO UI, you have two places to look for real examples:

1. NextStep. The NextStep system, a complete Object Oriented system from the ground up, Foundation Classes, gui builders, written in Objective-C (let me guess; you've never programmed in it... tut, tut...), is truly the paragon of Object Oriented User Interface design. So modular, customers can completely reshape the UI (appearance, layout, hot-keys) without changing a single line of code. It is breathtaking.
2. GTK+. GTK+ is the next best thing to NextStep's system, from what I have seen. I'll bet you've never used it. GTK+ has the same capability to modify the UI, provided that you use libglade (as you should, as mentioned in the article). If you don't like a GTK+ UI, you can open up glade, reshape the .glade file, and wha-lah, you have a rearranged UI. I'm not so certain that you can add new elements very easily without getting into the code (as you can with NextStep's system, but you can do quite a bit). Note that GTK+ is object oriented, even though it is not written in C++. (Guess what! There are languages out there that are not C++... Some of them are even something called "functional"... Unfortunately, functional concepts seem to be lost to the world...)

Unfortunately, I can't speak for QT; I've never used it. {:(}=

Now MFC..?! An object oriented system? It's the epitome of bad OO design. Good lord; when you use MFC, it generates these enormous files for you with macro blocks that say, "DO NOT TOUCH THESE!" around them. You can't add anything except through the grace of the UI builder. Is this "modular design"? This from people who mindlessly repeat the mantra "We must have type safety"?! It's nuts. Okay, now lets move beyond the macro blocks. When you are using MFC, it generates functions for you, and you are supposed to manually modify these functions. You can't register your functions; you have to manually go in and modify the code that it generates for you. And we are supposed to believe that this is "object oriented" design.

I'm not an OO bigot. But really; If you have determined to be an OO bigot, at leastbe a good OO bigot. Pull out your SmallTalk books, Simula, Design Patterns, Objective-C. Trace your roots. Read them. Read about NextStep. Study. Look at well documented, and well implemented, OO UI designs. Please. I'm begging you. As much as I despise OO facists, at least I want to talk with quality OO facists. Please don't align yourself with MFC.

(I generally hate writing flames, but some just have to be written...)