OSNews

F# is more of a "retrofitted" language being an adaptation of CAML to the CLR.

Its wrong to make a sweeping statement like the guy who said it sucks but functional languages to me are only really useful or successful when they address a very narrow target (take for instance XSL or SQL etc). In these cases the syntax can often be highly expressive towards the target and thus deliver excellent productivity over imperative languages.

General purpose functional languages are however quite difficult to master when they have a broad scope as they lack the expressive advantage of their "narrow target" cousins. They dont generally offer enough extra benefits over imperative languages in those cases to make them worthwhile.

Expressive advantage? Have you ever looked at Haskell code?

Try writing a compiler in a functional style versus an imperative style, in a language that just justice to the functional style. Indeed, try writing any "logic heavy" code in such a language. Algorithms that are very difficult to express in terms of 'for' and 'while' loops become much more simple to express in terms of 'map' and 'reduce'.

SML .NET is still developed, has Visual Studio integration, etc. I can't say that there's much of an actual need for functional languages on the .NET platform, and really most of the work seems to be imperative programming in multiparadigm languages, like ML derivatives. That isn't to say that there's anything wrong with developing languages that target the CLR.

Now you're IMHO insulting Lisp quite a bit. Sure, C# is more modern in several respects, not the least built-in threading and a modern library set, but otherwise it's not a reference manual. Lisp has tons of features that C# can't even dream of.

To be on-topic, Nemerle looks like a cool revamped OCaml for the CLR.

That's why I said it was for C# 4.0 C# seems to slowly, yet enexorably, be moving in that direction.

With regards to the topic, this is somewhat of a dual post, as it announces both Nemerle 0.9.0 and the release of the C# 3.0 preview spec.

You're right, that does sound pretty bitter. How is that Common Lisp standard revision going? Is it pushing any boundaries? Did it turn into a statically-typed language that relies on manifest typing in order to need local-variable type inference to annoy programmers less? Perhaps it's switched to single-dispatch and inflexibly coupled methods to type definitions so that it needs "extension methods?" Those retarded collection initializers don't exactly look like Common Lisp to me, perhaps they're new?

Actually upon looking at this specification, Microsoft appears to be doing some things to make their language less retarded, and others to just make it needlessly complicated (such as query expression translation).

Heh. My comment was, of course, somewhat tongue in cheek, but my point was that C# is trying to solve the same problems as Common Lisp, and going about it in the same general way. Now, that might be like saying that the engineering behind a Porche and a Yugo is "generally similar", but issues of quality aside, they're both cars, right?

Completely static typing is annoying. CL solved it by making use of type declarations optional. C# attempts to solve it by making omission of type declarations optional. Methods coupled to classes is annoying. CL solves it by using generic methods, C# is trying to solve it by using extension methods. And collection initializers, well, do remind me a bit of CL. The example on page 16 could be mapped quite cleanly to LIST plus a defclass with initargs (or a defstruct).

My point is that C# takes the short bus to school every day, and as such to remain within its conceptual framework while still providing improvements to the people that use it every day for whatever it is people use .NET for, it requires things that aren't like Common Lisp even if they alleviate problems that Common Lisp doesn't have.

When every third-party language for the CLR adds local type inference, why should C# not do it and instead worry about merging research work, or otherwise add any other experimental functionality right this second? When they see a clear need, or are confident that their work can be merged into the mainline language you can rest assured that C# ?.0 will be released. They aren't going to develop Alice# overnight; they're going to do it over the course of the next decade.

>and others to just make it needlessly complicated (such as query expression translation).
Redmond has always excelled at taking existing, standardized things and specializing them to their platform. You can argue in a positive sense that this helps build the brand and free them from copyright worries. Or you can argue otherwise, but the day is too nice to troll.

Define "failure". If a "failed" language is one that influenced the design of dozens if not hundreds of languages over the years, remains state of the art despite its age, is still a required part of the top university programs, and still has an active user community half a century after its introduction, then Lisp is a glorious failure.

With regards to syntax --- John McCarthy did have common sense. He originally intended to define a syntax for Lisp. He just never got around to adding it because his "common sense" proved to be wrong --- the language's users liked it the way it was. That's the thing about common sense --- sometimes it blinds you to possibilities outside the common experience. Ultimately, the prefix syntax proved to be a mixed blessing. It simultaniously made it one of the most powerful languages ever designed, because it was completely and cleanly extensible, yet made it inaccessible to the closed-minded nitwits that make up most of the computer industry.

That looks exciting! Do you have a link to the 3.0 examples?

Nope. Type declarations are a part of the language, and a good compiler will issue the requisite errors and warnings. SBCL/CMUCL is particularly good about this, and will do enough type inference to catch many type errors even without declarations. I don't usually bother to put type-declarations in my code, yet the only type errors (that I make, anyway), and that the compiler misses are polymorphism-related errors that wouldn't be caught 'till runtime in C# anyway.

That´s not true. Common Lisp enables type declaration and there are a lot of Lips with type inference.

"goto was removed or suppressed in procedural languages - these languages lost a bit of expressivity, but gained clarity."

care to explain how "GOTO :FOOBAR" or, worse, "GOTO 26765", could possibly be any more "expressive" than "foobar()"?

BTW, threading support isn't builtin to C#: it's part of something bigger called .NET -- a huge library, accessible by any language targetting the CLI runtime...

Nemerle is ok, as far as .net languages go, but it's just like Paul Graham once said: modern languages look more like Lisp everyday...

Personally, i believe Haskell to be a pretty parenthesesless, statically-typed Scheme with type inference...

"care to explain how "GOTO :FOOBAR" or, worse, "GOTO 26765", could possibly be any more "expressive" than "foobar()"?"

Are you confusing goto with gosub ? Goto is not used for functions calls, and it cannot be replaced with function calls.

Consider a language without exceptions, then goto can be useful to jump on error handling code at the end of a function.

Ah yes, the quintessential argument in favor of C#: "yes, it might be completely derivative and unoriginal, but at least we'll get Joe Blow programmer to use it!"

For the kind of money they are able to pour into this project, and the kind of talent I'm sure they are capable of hiring, I expect a wee bit more than "well, at least our marketing is first-rate!"

As for your endline, I believe you meant:

The future of programming looks very... much like the past.

It's more like, "Whatever the future holds, it will probably look something like Java." It's not even a matter of a limitless marketing budget. AWK begets Perl which begets PHP. People like PHP. They use it every day for a large piece of web development, and it didn't even have the "PHP to destroy Windows?" like Java did from 1996-2001. Perl too, and unless you consider O'Reilly to be more powerful than every university on the face of the Earth (lisp and scheme were rather popular for a while), I don't think it's because programmers have been mindlessly programmed by their marketing into using it. Even in PLT, more effort is spent on ML derivatives or Java/JVM work.

I agree, they are not truly original but they are bringing very nice ideas to mainstream. The C# team obviously does't fear to bring not-so-usual features to their language, and there are several Microsoft Research teams working on programming language projects, and their work has nice chance to be used in MS tools. Unlike Java, which is just stuck in standard OOP, ignoring all the nice Lispy stuff ;-) inventing horrors like anonymous inner classes instead.

> The future of programming looks very exciting!

I have the same feeling, I would just specify that to future of _mainstream_ programming

LOL. My first exposure to Lisp was via a contractor who (being eccentric yet indispensible), would do all her simultions in Lisp. It's very hard to find college-aged people doing Lisp, because the in-thing to do these days seems to be to churn out code monkies rather than cultivate real computer scientists. But that's a different rant entirely...

"easy to use and learn, and easy to read, maintain, and so on. Lisp fails..."

I don't think there are many languages that come close to Scheme ( a Lisp dialect ) in the "easy to use and learn, and easy to read, maintain" department while at the same time providing powerful and flexibility like no other.

yet, for practical matters, i guess too much minimalism does harm a tad bit... of course, you can always use an environment rich Scheme implementation, like PLT's or tap into an existing one, with Kawa for instance, which is Scheme targetting JVM and making good use of its resources...

I don't see how Lisp is less practically useful than Java, if you consider linguistical issues only and forget the other stuff like lack of libraries, implementations, small user base etc. Unfortunately, most Lisp critics don't try to explain this and they just very vaguely talk about inpracticality, academia, smug teenagers, stupid parentheses etc. IMHO base of CL is simple (function application with special forms and macros), fairly easy to read (really high level code, conciseness instead of repeating boilerplate code, DSLs), easier to maintain (short code with less duplications).

"And what about this silly query expression stuff?"

yeah! instead of "select foo from bar", you now can write "from bar select bar.foo". innovation at M$'s best!

Query expressions are syntactic sugar that are not worth it, but c# seems to be more extensible now thanks to closures and expression trees. If I understand it correctly, then part of the query expressions ("where ......") is not hardwired into the language, but built on the expression trees feature - the code after "where" is DSL that is translated to e.g. SQL by a library that analyzes its expression tree.