These days I'm much more taken with the "scripting" languages, particularly Ruby.  Very practical, cleanly organized, none of the complexity of static typing etc.

That's pretty much what I expected.  Yes, Scheme is less practical than CL, if only for the library support.  I admit I tend to like the design of Scheme a hell of a lot better than CL on a number of points though.

But it is interesting that you consider CL functional -- most of my LISP using friends tell me(and from what I infer from many other places) CL is rarely used functionally.  Although you can do it, most people don't.  Scheme is often used more functionally (obviously), but on the whole its usage is still less pure than ML, and the same for ML vs. Haskell or other purely functional languages.

Quote

People always say this but I'm not sure I believe it.  Surely in an absolute sense duck typing is far more *flexible* than any static typing system could be.

It's flexible in the sense that "anything goes", sure.  But in the sense of doing something complex in a safe way that's easy to reason about (usually important for complex things!) and easy to maintain, it's not.

Someone has written a web browser in Haskell FWIW, and probably OCaml.  The latter you are probably correct about.  But this I believe is not so much due to the languages as it is due to API issues.  The applications you list are quite typically heavily dependent upon OS specific API's for network code, image code, audio code, and GUI toolkit.  Most functional languages have bindings for large parts (or even all) of those, but they do not match what is often provided as the "native" implementation language for the OS, and this is the reason I believe you don't see those types of programs in fp often.  Again, this isn't really a mark against fp though, because aside from Java, most of the world is still stuck in C or C++ mode on that regard.  The situation is pretty similar for most of the "scripting" languages as well, although not quite as bad since there is a little more interest in supporting them (I believe this is due to the fact that they are on the whole quite similar to languages most people are already familiar with).

I've read a couple of books on C# and like it, but haven't actually tried to use it. I've done a couple of things (not professionally) in Smalltalk and think it would be the Only Language in a Just World.

While i as well am mostly interested in this kind of languages, i disagree that ruby is cleanly organized - sure, it has achieved alot without a single revamp, but even matt now agrees that it is suffering from growing pains, that some of its behaviour (like local vars) is weird and that some of its syntax for advanced features like hashes, keyword-arguments, etc. are plainly unnecessary complicated. I'm very interested in how RITE/ruby2 will turn out - but then again, currently they seem to lack the necessary manpower to do it.... and i fear ruby2 may become something like duke nukem forever

The keyword syntax for functions is a hack, and I do hope they do something about it for Ruby 2.

CL's syntactic flexibility makes it a truly multi-paradigm language.  You can write oo, functional, imperative or logic code with CL.  I think it's probably true that most CL code isn't particularly functional, but I'd argue that it's because the functional paradigm isn't really all that practical for a lot of things.  Mutable state is just usually more straightforward for than a more elegant but less tractable functional implementation.  Have you read Okasaki's "Furely Functional Data Structures"?  Some very clever stuff in there but I found myself shaking my head halfway through it at the convolutions he has to go through to do relatively simple things.  I like the functional, expression-oriented style in the small but I think it breaks down when you start trying to treat big complex aggregates in a functional way.
[{POST_SNAPBACK}][/a]

It seems that this point always gets argued in a vacuum.   Large and complex programs have been written in statically and dynamically typed languages, so I think it's not really clear which one has the advantage.  Perhaps other factors are more important?

Somebody's got to write all the essential but unglamorous libraries and documentation and I think it's instructive that Ruby's made more progress in two years than OCaml or Haskell has in toto.

If you want to see an extreme example of Haskell flexibility when dealing with big complex aggregate data types, you should check out the "Scrap your Boilerplate" papers on generic programming with Haskell.  I posted a link to it ealier, but for reference, you can find them here.

Typing, however, will remain a rather religious point, and I don't expect there will be much agreement on strong static vs. dynamic anytime soon

What do you mean by progress?  Are you talking about userbase adoption?  Well, then yes, Ruby has made more progress.  Are you talking about language maturity and library maturity?  If so, I'd have to disagree that Ruby has made more progress.
[a href="index.php?act=findpost&pid=340787"][{POST_SNAPBACK}][/a]

I wonder what do you think about Lisp, especially opinions closely and loosely related to it that are posted on Paul Graham's site...
[a href="index.php?act=findpost&pid=347504"][{POST_SNAPBACK}][/a]

I wonder what do you think about Lisp, especially opinions closely and loosely related to it that are posted on Paul Graham's site...

Also I'm curious about views on Objective C and Cocoa/Gnustep.

BTW, do you think Python, perhaps even with Pythoncard is good for a start?

Mostly "toying" activity - that's why there's no rush - apps that could be desribed as interfaces to functionalities that already exist/glueing of ready libraries.

Well, perhaps in the long run something in area of cognitive science, hence my slight interest in Lisp   .

My only experience is very short, basic contact with C, and also somehow C++, though used like C - I don't even have an understanding of the concept of object oriented programming 
[a href="index.php?act=findpost&pid=347504"][{POST_SNAPBACK}][/a]

I wonder what do you think about Lisp, especially opinions closely and loosely related to it that are posted on Paul Graham's site...

• Very lightweight and non-obtrusive syntax (i.e., not cluttered with numerous unnecessary keywords or other fluff)
• Strong static typing with type inference
• Parametric polymorphism (think like Generics or Templates) and ad-hoc polymorphism with subtyping (OO inheritance, dynamic dispatch)
• Everything is an object, including "primitive values" (similar to Ruby, and unlike Java) and functions
• Lambda abstractions (e.g., x:Int => x * x)
• Thus functions are first class (e.g., val xs:List[Int] = ...; xs.map(x:Int => x * x);)
• Functions can then also be nested
• Functions can also be curried (i.e., methods can be partially applied to parameters, which then returns a new method taking the remaining unbound parameters -- good for proper higher order programming)
• "Object" abstraction in addition to Classes (Objects are instantiated singleton classes, requiring no special design pattern or multiple extra keywords to establish)
• Traits (i.e., similar to Java interfaces, except can contain default implementations, but no mutable state)
• Mixin in addition to standard inheritance (e.g., somewhat complex to explain here, but it's a way to layer class composition more flexibly than with straight inheritance)
• Pattern matching (e.g., str match { case "foo" => ... case "bar" => ... } )
• Case classes (i.e., classes with an automatically provided constructor that is pattern matchable, in addition to having automatically created display functions.  Case classes do not require "new SomeClass()" either, but appear more like functions: Tree(Tree(Leaf(1),Leaf(2)),Tree(Tree(Leaf(3),Leaf(4)),Leaf(5))) )
• Advanced type control such as Variance (allows one to control covariants and contravariants), compound types, etc.
• Views (i.e., a facility that lets one "view" existing classes under a new abstraction.  For example, one can use a view to abstract a string class as a class representing a sequence of characters.  Another example would be "viewing" a complex number type through an angular representation rather than a rectangular.)
• Regular expression like patterns for general sequential data (seems like a *very* powerful idea)
• Ability to operate on raw XML directly in the code, which is then treated as a nested data type which one can pattern match on, or inject scala computations into specific portions of (think kind of like php in reverse).  One can use a tool to transform XML DTD's into a series of classes to make the resulting data structure richly typed, rather than essentially operating on it as an untyped ADT.  This seems incredibly powerful and is probably the best facility for working with XML than I have seen from any language ever.
• Automatic type dependent closures (i.e., you can use this with currying and the languages ability to use single parameter methods as infix operators to create arbitrary flow control constructs, but without resorting to a metaprogramming facility that requires direct manipulation of the language AST.  Think of it kind of like C++ template expression metaprogramming but without the ugliness, and designed from the start to produce natural looking syntax).
• Arbitrary operator specification (i.e., any combination of non-alphabetic symbols that do not start with . may be used to create an operator, like ":*!@@@" for example.  Used with the infix notation mentioned above, this is incredibly powerful)
• Full unicode support (i.e., you can use non-latin unicode characters for *identifiers*, such as symbols for lambda, gamma, omega, etc. for variables or objects. Strings are also unicode).
• Compiles to either the JVM or the MS .NET CLR (defaults to JVM), which means not only does it run seamlessly on those platforms, but libraries from those platforms can be called transparently and used as native scala code, instantly giving access to a huge variety of industrial grade libraries.
• Parser combinator library support (i.e., a way of parsing that operates upon the idea of building up a parser through a sequence of functions representing abstract operations on streams.. kind of like regular expressions through function composition)

Thought I'd add a little something more to this thread...

There was a time when I would have looked at that list of features and thought "Wow!  What a cool language".  Now I read it and think "Wow!  Another research language I'll never get to use at work!".

That stuff might all sound great on paper but I'm not convinced it has that much real-world programming value.  Ruby is simple, mostly fits all in my head at once, and is straightforward enough that I have some chance of persuading my coworkers to try it.

We could have round 7999 of the static vs. dynamic typing debate, but it's impossible to argue that large complex systems *can't* be built in dynamic languages and I think the burden of proof really likes with strong typing advocates.

It's kind of like 20th century orchestral music.  Schoenberg and Xenakis' music sounds great from a theoretical point of view, but nobody listens to it and their most persuasive ideas have been cherry-picked and reworked into something more palatable to the general public.  So maybe the functional programmers are the 12 tone serialists of the software world?
[a href="index.php?act=findpost&pid=348729"][{POST_SNAPBACK}][/a]

This means that Java programmers (of which there are many) are going to be much more comfortable trying it because they don't have to rely on another VM and they can use all of their existing libraries and all of the libraries they've grown accustomed to over the years.

The second big advantage is that from reading the Scala documentation, it's very clear that they are targetting the language at people from traditional OO backgrounds.  Almost every example is explained in a way an OO programmer would understand, rather than how a functional programmer would look at the situation.

Complex systems can be built with dynamic typing, I never said otherwise.  But I find it strange that people don't seem to see the advantage in having the compiler doing the heavy lifting with regards to safety, rather than having to sprinkle type checking predicates all throughout their code and cross their fingers after they've deployed the product.

And that's just it.  Scala is the cherry-picked, reworked-into-something-more-palatable version of functional programming for the OO generation.

You should take a look at it before assuming outright that it's useless.

Lots of languages have tried this but so far it doesn't seem to have helped Jython, Nemerle, or any of the JVM-targeting Schemes.  Again, sounds great in theory but so far in practice it's been a dud.

Quote

The second big advantage is that from reading the Scala documentation, it's very clear that they are targetting the language at people from traditional OO backgrounds.  Almost every example is explained in a way an OO programmer would understand, rather than how a functional programmer would look at the situation.

I think most OO programmers will run screaming away from the gnarly type errors.

The sad fact of this Paul Graham-ish "design for smart programmers" is that most programmers aren't really very good and a language needs these people to really thrive.

Notice that the main reason they switch to Python, despite the fact that they consider Lisp to be superior, is that they didn't have to do nearly as much grunt work because so many support libraries had already been written by the "average" programmers that never got around to doing the same thing for Lisp.

Trotting out the standard counter-argument: static typing only catches certain kinds of errors, you still have to do proper unit testing and q.a., and it's not clear that static typing doesn't cause as many problems as it solves via increased language complexity and conceptual overhead.

It looks to me like they're still clinging to most of the functional communities most cherished and untested assumptions, but I'll give it a closer look.

The burden on all language designers is to demonstrate that their language solves some important problem much better than existing alternatives.  Ruby's grown more in the last six months than in it's entire previous existence thanks to Rails.  The ball is in the functional community's court to do the same.
[a href="index.php?act=findpost&pid=348735"][{POST_SNAPBACK}][/a]

There is a huge difference between downloading Scala and using System.out.println in your first hello world program, and downloading a special, non-popular dialect or other poorly supported language extension facility to get the same functionality.

Quote

Notice that the main reason they switch to Python, despite the fact that they consider Lisp to be superior, is that they didn't have to do nearly as much grunt work because so many support libraries had already been written by the "average" programmers that never got around to doing the same thing for Lisp.

This seems to be a good argument in support of Scala with regards to its backwards compatibility with the JVM and .NET, doesn't it?

Catching half the errors is better than catching none of them.  The half that isn't caught is usually easier to prevent also -- most of the remaining errors in my Haskell programs after everything has been type checked are algorithmic errors.

Quote

It looks to me like they're still clinging to most of the functional communities most cherished and untested assumptions, but I'll give it a closer look.

Out of curiosity, which untested assumptions are you referring to?

On the other hand, it's somewhat amusing how most major OO languages these days are now adding quite a few functional style features after years of people saying how useless fp is.  Strange isn't it?

One look at their XML support and the rest of the language features that operate well with this approach (the regex stuff I mentioned, pattern matching, etc.) should make it obvious to just about anyone with serious programming experience just how useful some of those things could be for "real world" programs.

What I think is important is whether a language is both capable and practical.  I think Scala meets both of those criterion.  Whether it will become a major player in the language community lies more with the random whims of the Language Gods than it does with other factors; Scala, I think, has those covered already.

A lot of the other JVM-targeting languages integrate very nicely with the rest of the Java runtime but it didn't seem to help them much.  Maybe things will be different for Scala but the precedents aren't encouraging.

Quote

Catching half the errors is better than catching none of them.  The half that isn't caught is usually easier to prevent also -- most of the remaining errors in my Haskell programs after everything has been type checked are algorithmic errors.

Most of the bugs I find in my code are things that a type-checker wouldn't catch, but this is a hard point to argue in a vacuum.  I think it's interesting that really exceptional programmers come down on both sides of this issue.  I think it's one of those engineering things where it's not a question of which one is "better" in any absolute sense but more of a question of what the tradeoffs of each approach are.

Quote

Quote

It looks to me like they're still clinging to most of the functional communities most cherished and untested assumptions, but I'll give it a closer look.

Out of curiosity, which untested assumptions are you referring to?

The whole idea that some kind of rigourous mathematical theoretical grounding is important and valuable for typical programming tasks.  All this type theory and analysis and lambda calculus and graph rewriting yadda yadda makes for interesting research papers but I still don't think anyone's demonstrated that it translates to more productive languages.  Personally I think Larry Wall was closer to the truth with his idea of programming languages that borrow from natural languages.  He went so far off the deep end with it in Perl that he's largely discredited it but I think he was on to something.  Ultimately it's the programmer that makes the biggest difference and the more you can do to lower the barriers between how they he about code and how they write code the more you'll do to make him more productive.

I certainly wouldn't say fp is useless.  Higher-order functions have proven their worth in many contexts.  I'd say the jury's still out on some other fp ideas like lazy evaluation and non-mutability.

- i have not seen any references to prototyping. Personally, i like the idea of using prototypes instead of classes very much. Does Scala offer some way to "simulate" prototypes without the need to deepcopy?

- Compiling: AOT-only or also JIT? I would miss JIT quite alot, because especially in the beginning stages of projects, i prefer to be able to make just a few changes in the code, and then check the result immediatelly.
[a href="index.php?act=findpost&pid=348870"][{POST_SNAPBACK}][/a]