Programming languages worth checking out (h3rald.com) |
Programming languages worth checking out (h3rald.com) |
F# is a mixture of C#, OCaml and Haskell. F# will be included in the next version of Visual Studio so it's no longer just a research language. Performance is similar to C# but coding in it is faster in my experience and above all a lot nicer if you like functional programming. Because it runs on the .NET VM or Mono VM it has good multicore support unlike OCaml. Haskell is more powerful as a language, but also has it's weak aspects. The main thing F# is missing imo in comparison to Haskell is type classes. And of course the Haskell community.
Having said that, Windows is cheaper than RHEL already...
Don Syme (the creator of F#) has said that Microsoft will release the F# compiler under an open source license. I think that the future of the language will depend on it. If the F# compiler cannot be included in Linux distributions then the uptake from Linux and OS X users will be low. That would seriously hinder the (open source) community aspect of the language. I don't think that a young advanced language can survive without it.
With regards to Smalltalk and its incredible reflective abilities, this video from OOPSLA'08 ("Smalltalk Superpowers") is particularly amusing: http://www.veoh.com/videos/v163138695pJEMGmk. Unger even does a pretty neat demo of Self.
I could imagine a deployment process where code can't be deployed unless it's all statically typed. This lets you do very fluid rapid prototyping, but then firm up parts of the system once they go into production.
There's also work on a linux port at http://www.gliebe.de/self/download.html, but I think it might be relatively defunct as well.
Its unusual, minimalist and yet elegant and powerful syntax reminds of Smalltalk, but the language goes far beyond that. Io is an object-oriented, prototype-based, message-based and fully-reflective programming language. This means that you use messages like in Smalltalk, you create objects like in Javascript and every bit of your code can be inspected and passed around as you see fit.
http://dekorte.com/projects/shareware/SoundConverter/
The interface talks to an Io "server" which handles business logic.
We're currently working on a shopping aggregation startup. The crawler is written in Io.
Pixar's RenderMan image tool uses Io as its scripting language:
https://renderman.pixar.com/products/tools/it.html
Io is still under development so you might run into the occasional bug. Bugs are encountered more often in the addons than in the core interpreter (which is stable).
This author doesn't seem to know his subject very well, though. To say that an object-oriented, message-based, fully-reflective programming language goes "far beyond" Smalltalk suggests ignorance of how far Smalltalk goes.
And GCC-based implementation is lagging behind in features, and also scores consistently 10-30% slower than C/C++ in benchmarks, which kills D's appeal as a performant replacement for C.
What Walter needs to do, IMO, is to abandon his own implementation completely and closely work with GCC/Linux community to include high-quality D into standard GCC package. Then we may start seeing decent software written in it.
the issue that i have (imho ofcourse) is that of 2 incompatible standard libraries phobos and tango, which makes it quite painful to work at anything significant/non-trivial. iirc, there was an effort to have an stl kind of thing for D, not sure how far (or in what state) it is.
also, it seems to me (i can be wrong about it) that D is being marketed towards corpo-drones doing win32 (c++) stuff, rather than to linux C devs. most likely, they (corpo-drones) are moving towads C#/.net and i doubt that they are interested...
I guess I should have paid that guy on elance his $1,000 to code it up in C for me.
Here I stopped reading.
1. It has the simplicity fo Scheme. 2. It has literals for datastructures. Hashmap: {"BANK" 122323 "TRANSFER" 212001} . That's it, I created one. Oh, here's a vector for you: [1 2 3 4 5]. Veru convenient, not revolutionary by any measure, just very convenient. And it doesn't sacrifice any power for that practicability. 3. It is more functional than common lisp. 4. Access to all the Java libraries. Whatever you want to do, there is a library. And yes the excessive amount of documentation you have to read to just do something simple might frustrate you but it's a lot more effective than re-solving a problem that has been solved a hundred times before.
I think these things together make it an excellent language.
My first big project in LISP was making a Sudoku solver for a school project. Could only use basic instructions and lambdas. It was not pleasant trip :P
Also, Common Lisp (CLOS, in particular) supports multimethods (defmethod), contrary to what the author claims. And all of the special forms I saw in clojure have a counterpart in common lisp.
In fact, a lot of common lisp implementations (I like SBCL) have support for threading/asynchronous action built in. The one problem is that none of that is part of the ansi spec, so most multithreaded code won't be portable between implementations.
It isn't the language's fault that your teacher wouldn't let you use all these features.
I ended up concieving my algorithms without thinking about Prolog's backtracking, and then coding: bending the Prolog interpreter to my will by getting the backtracking to implement the control flow called for by my algorithm. It seemed a bit indirect and a bit clumsy.
My attempts at writing a parser in Prolog were absurdly slow. Later I read that there are ways of writing parsers in Prolog that work well, and writing parsers was one of the killer apps for Prolog, so I guess I never really understood programming in Prolog properly. On the other hand it is troubling that I failed at one of the things the language is supposed to make easy. I'm in no hurry to give it a second look.
I'm pretty sure Prolog is still being used, but it doesn't have the buzz of, say, Fortran or COBOL or Pascal.
It also has tail-call optimization, closures, coroutines, and other aspects that are interesting from a pure CS standpoint, such as the way the table datatype is implemented and its register-based VM.
For a good taste of Lua, skim "The Implementation of Lua 5.0" (http://www.tecgraf.puc-rio.br/~lhf/ftp/doc/jucs05.pdf), the quick intro to Lua in the LPEG paper (http://www.inf.puc-rio.br/~roberto/lpeg/lpeg.html , around page 6 of the PDF), or _Programming in Lua_ (http://www.inf.puc-rio.br/~roberto/pil2/). The first edition of the latter is online, though the second edition has a bunch of added material, and IMHO is well-worth buying if you get into Lua. Also, check out LuaJIT (http://luajit.org/), if you're using i386 hardware -- it's a FAST JIT.
The C++ bindings aren't so great, last time I checked. The documentation is not of a consistently high quality, but it doesn't matter much because, once again, the language isn't very complex.
I prefer lua to any other embeddable language, including Python.
There are some parts that I did find annoying, however, like the fact that in the standard libraries array indexing starts at 1 instead of 0 and that it gets a bit kludgy when you try and add lots of things that are not part of standard language features, but nothing you can't overcome.
Nice to have all the up-and-coming languages lined-up in an internal comparison. I like Lua, Haskell and Io. I think that future languages will have to have a cleaner rather than an uglier look and syntax. For that reason, I have a visceral reaction to scala and factor. Even the one-line examples I've seen of these language have look like gibberish. I'm sure they are great in many ways but don't want them to succeed since they will make my brain hurt more. Also, I think that they won't succeed for similar reasons.
$ sudo port install fsharp
When you're doing prototyping, you want to delay that decision as long as you can, so you are making the most informed decision possible. And nothing informs your decisions like the act of developing and getting feedback from users.
Optional static typing gives you the best of both worlds. But I don't know how you'd get the equivalent with Design By Contract/Unit Testing. Both of those feel a little unnatural to me. I'd rather just tinker, and not have to set up extra stuff before or after I code.
Edit: I realize this is probably obvious, but let's not confuse what this guy says about Clojure with what Hickey has to say. He's well aware of CL and doesn't make silly claims about it.
Hickey does make a lot of valid points about the advantages/differences of clojure (http://clojure.org/lisps) though.
I'm not sure about vim. I use TextMate (there is an Io bundle).
So which (if any) of all these languages will you use to do a real project?
As a matter of fact, I work as a technical writer, so I'm not going to use any of these for any big project. However, I do code in my spare time and prepare small programs to automate tasks at work, when my boss lets me.
At the moment (literally) I'd like to try learning Haskell again, but it feels very difficult.
You're likely to just get people recommending their favorite.
If I were you I'd apply some combination of two criteria: which is the most fun, and what do I want to try to build?
It's great that you've done some broad experimentation (much more than I have). I suggest that you'll get a different and rewarding view if you try to use one of these languages to do something real that you care about.
CUDA yes. Cg yes. HLSL yes. Verilog yes. VHDL yes. C++ or Java with MapReduce yes. PHP and MySQL with memcached yes. Erlang yes — and it really is functional, inside each process, anyway — that is, the level where you aren't getting any parallelism. Octave or R, potentially, but not today, as far as I know. Mathematica yes, and it, too, is mostly functional.
In theory, side effects are what make parallelism hard, and so languages whose semantics are side-effect-free (unlike F# or Mathematica or Erlang) should make it easy. So we all thought in 1980. Since then we spent 20 years or so trying to make that happen, and it basically didn't work.
There are basically four kinds of parallelism within easy reach today. There's SIMD, like MMX, SSE, 3DNow, AltiVec, and the like; you'd think that data-parallel languages and libraries like Numpy and Octave would be all over this, but except for Mathematica, that doesn't seem to be happening. There's running imperative code on a bunch of tiny independent processors that share no data; AFAIK that's what the shader languages are doing. There's instruction-level parallelism on a superscalar processor, which largely benefits from things like contiguous arrays in memory, or maybe what Sun is doing with Niagara, where the processor pretends to be a bunch of tiny independent slow processors. And then there's splitting up your data across a shared-nothing cluster, which is how every high-traffic web site works, and that's what MapReduce makes simpler.
Uh, and then there's designing your own hardware or programming FPGAs, which is what Verilog and VHDL are for.
Languages like OCaml (I don't know anything about F# except that it's like OCaml, but for the CLR) have no special advantage for any of these scenarios. They don't even have the theoretical advantage that they have no side effects and therefore you can speculatively multithread them without breaking the language semantics. They do have the massive practical disadvantage, in most of the scenarios I described, of needing unpredictable amounts of memory, having massive libraries, and using pointers all over the place. Using pointers all over the place kills your locality of reference and your ILP. Having massive libraries and using unpredictable amounts of memory makes it impossible to run them inside your GPU and means they can't run on an FPGA (except by using external memory, like the awesome Reduceron). And nothing about the language semantics helps with SIMD either.
So, sheesh, go read Alan Bawden's dissertation or whatever, but don't go around claiming that ML (or even Haskell) is going to magically make your algorithms parallel. We tried that. It didn't work. We're trying something else now.
And please, PHP and MySQL? For computation? Are you serious?
But it would be awesome if someone came along and proved me wrong.
And please, PHP and MySQL? For computation? Are you serious?
What do you think people use PHP and MySQL for, fertilizing flowerpots? Computation is all they do! Obviously the PHP5 interpreter isn't the most computationally efficient medium in the world, but it's where it's at when it comes to horizontal web site scaling, i.e. parallelism.
I'm aware of that; I wasn't suggesting that people should be programming their websites in Verilog, after all. But running websites is part of computing.
I completely concede your point that F#/OCaml/FP in general has little to offer when it comes to serving up web pages more quickly.
That wasn't my point; I think functional programming might have a lot to offer when it comes to serving up web pages more quickly, and especially programming web-server software more easily. My point was that functional programming doesn't have a lot to offer when it comes to making your code more parallel.
Formatting records from a database for display on a client device isn't all that different since the 80s anyway.
I cannot imagine in what sense this sentence could be true. The database architectures, the languages used, the required level of efficiency, the CPU architectures, the scale of operations, the kinds of failure we expect from components, the structure of the machines (then SMP mainframes, now shared-nothing clusters of thousands of computers), the type of people doing it, the client devices, the networks, the formatting, and the nature of the data have all changed dramatically since the 80s.
I care about, for example, people not trying to do Monte Carlo work in Java because that's the organization's "standard" language. A language like F# that it is acceptable to use in a large organization with arbitrary standards made by non-technical people is a huge deal.
Do you think doing Monte Carlo work in Java is bad? Because of performance? Last I heard, the optimizations in the CLR's JIT were pretty minimal, while the Java JITs had pretty much reached parity with GCC and were breathing down icc's neck. (What Fortran compilers do people use these days?) Maybe you should get excited about people doing Monte Carlo work in Scala instead?
Anyway, whether a language is pleasant to program in or has a good compiler has very little to do with whether it helps you take advantage of available hardware parallelism — unless the way in which the compiler is good is that it auto-vectorizes your loops or supports HPF directives or something. As far as I know, F# and Java are equally abysmal at that.