There is the downside, that ruby's syntax is currently being reworked - thus, i'll have to idle a few months, until the most important syntax-changes are implemented into the CVS-trunk.
[{POST_SNAPBACK}][/a]

Languages tend to become less elegant as they evolve.

I think Ruby is a nice language, but I'm thinking it's going to continue to face more growing pains in the future, beyond even currently planned changes, particularly if it is ever planning to tackle increasing concerns in programming like security, concurrency, and distribution.  These are difficult problems, and as I said earlier, they are practically impossible to handle in a straightforward fashion without a deep, well-designed, and mathematically precise model of the language's behavior -- something that goes well beyond it's "implementation" in whatever compiler or VM is standard.

Why optimize for the hard case?  Most applications never need to deal with these issues in a serious way and it significantly complicates a language to try to address them all.   All language designs involve tradeoffs and compromises, so why not leave the really hard stuff for specialized tools?

The Common Lisp people trot this argument out all the time but I think the net result of all their work to handle the "hard" cases is that CL is just too much for the average programmer and nobody uses it.

• Do it like Haskell -- support domain specific languages, but do so by making the languages themselves much more idiomatic and self-contained by allowing arbitrary operator definitions and infix notation.  This makes a huge difference in usability.
  
  
  
• Support a couple of additional concepts directly in the language itself.  AliceML is a good example of adding thorough concurrency and distribution to a well-established syntax without adding huge amounts of complexity in average usage.  Yes, Alice can get complicated when you start using all of those new features at once.  But at the same time, it can look just like any other ML.  Oz, too, is an example of a language that is very simple, but also supports all of these advanced features.  Scala can do most of it also, although it does things more in the Haskell style (although Haskell also has support for concurrency in certain dialects).

Have you ever read Richard Gabriel's "Worse is Better" essay?  (http://www.jwz.org/doc/worse-is-better.html)  Some real wisdom borne of experience, I think.  There's a reason perl is 100 times as popular as all the exotic languages put together and I think it has a lot to do with this philosophy.

As for the evolution of Ruby, I think Matz has so far shown remarkably good taste and I trust him to handle it well.  Ruby has a mental ergonomic that just fits and could never be specified in a simple mathematical formalism and I don't think you can really appreciate it until you've actually worked in the language for a while.

I think Lyx's decision making process is going to be pretty common for the average programmer choosing between something like Python or Ruby and something like Haskell or Scala.
[a href="index.php?act=findpost&pid=350302"][{POST_SNAPBACK}][/a]

Most applications don't have to deal with these issues as much right now, but as I pointed out, they are going to have to do so much more commonly in the future.  In a language designed for the long haul, it makes sense to plan ahead, and a formal semantics and similar characteristics help immensely in this regard.  That was the point I was trying to make.

If you'd rather say: "well Ruby is a good language except I never expect it to handle those problems, and as those problems become more common, perhaps Ruby should be used less," well, OK

But actually, there's a twisted sort of truth there.  LISP's overly simplistic syntax, which lends itself to the sort of macro heaven that LISP users are so infatuated with, also make it less expressive in some sense.

Quote

As for the evolution of Ruby, I think Matz has so far shown remarkably good taste and I trust him to handle it well.  Ruby has a mental ergonomic that just fits and could never be specified in a simple mathematical formalism and I don't think you can really appreciate it until you've actually worked in the language for a while.

  That last sentence is a particularly profound statement.  Can you really support that?

Saying that Ruby has an "ergonomic" which cannot be specified in a simple mathematical formalism signifies to me that the design is simply inconsistent and not well understood.  Either that, or in fact it can be specified, but nobody has bothered to do it.  There is absolutely no need for a formal specification to conflict with an elegant "ergonomic" -- the two are not diametrically opposed.

Of course it is.  But that doesn't necessarily mean it's always the right decision making process...

Ruby is a fine choice for RAD, and it's probably true that it would "not get in the way" of your thinking as far as rapid implementation goes. But that's also a double-edged sword: dynamic typing and the sort of flexibility offered by a "loose" language like Ruby offers you many more opportunities for poor design (from all of a maintainability, safety, and performance p.o.v.), although kuniklo will probably disagree wink.gif

On the other hand, if you already have to wait "months," I don't see why you couldn't become a pro with Scala in that time easily.

Anyway, I'd be curious to hear what you think of the Gabriel essay.  I first read it in the middle of my functional language phase and thought it was moronic.  I keep re-reading it and appreciating the wisdom of it more ever time now.  I think the natural world mostly works this way because its the only way to manage complexity.
[a href="index.php?act=findpost&pid=350305"][{POST_SNAPBACK}][/a]

Maybe something like Haskell or Scala isn't as viral as C or Ruby either, but in the end I don't think this is because of the "MIT approach" or the "New Jersey Approach," but most likely because of more subtle issues like language education (and CS education in general).

Quote

Maybe something like Haskell or Scala isn't as viral as C or Ruby either, but in the end I don't think this is because of the "MIT approach" or the "New Jersey Approach," but most likely because of more subtle issues like language education (and CS education in general).

I think the analogy actually works pretty well, but I guess when we're speaking this abstractly it's going to be largely a matter of taste.

So, more concretely, one area where statically typed languages seem to fall really short is in metaprogramming - introspection, dynamic code generation, etc.  How do you accomplish these kinds of things in a language like Haskell?
[{POST_SNAPBACK}][/a]

For example, Rails dynamically adds methods to it's O/R mapping classes based on the structure of the database tables.  How would you handle this in a statically typed language?

Computer science was, and still should be a mathematical enterprise, as far as I'm concerned.  Engineering is something else, and while it's laudable in its own right, people too often associate CS nowadays directly with the latter and view the former as some sort of unnecessary legacy baggage.

Haskell actually has things like eval now, and can be used for dynamically loaded plugins (see: hs-plugins), so one way is simply to create a list or tuple or record or some other type which points to the structure of the database tables and evaluates the contents they represent.  "lambdabot" on #haskell for example, can both execute and give the type of arbitrary haskell code printed into the channel (e.g., @eval let fix f = f (fix f) in fix id).  It does this by using this dynamic approach.  This should give an idea of how you might be able to do something similar for the database problem.

Another way is to to specify a domain specific language for which the database contains snippets and then embed an evaluator in a monad in Haskell.  That might sound complex, but it's rather easy because of the way Haskell is already designed.  There are plenty of other approaches as well, but those are two that I think are more obvious.

This is assuming, by the way, that you mean that somehow the contents of the tables themselves contain something as rich as actual code snippets.  If not, then a much more basic approach is possible.

I agree.  I think the problems arise when people from a CS background start suggesting that their tools can magically solve engineering problems (a common claim on the functional language group).  If anyone wants to claim that their language or paradigm has significant advantages in the field then the burden falls on them to prove their claim.

I'm actually talking about the simple case of mapping database columns to attributes on objects, not executing arbitrary snippets of text as code.  How would you typecheck this kind of code?  For instance, in a typical rails program, you have lots of code manipulating attributes on objects that represent rows in database tables.  Since you don't know until runtime if all these attributes will actually be present, how do you statically check the correctness of the code?
[a href="index.php?act=findpost&pid=351132"][{POST_SNAPBACK}][/a]

Concurrency and distribution are two very difficult engineering problems, and functional languages lead the way here by far.  As far as I'm concerned, they've already proven their claims both mathematically and empirically.  People seem not to want to listen though, because it's not done in an imperative, OO way.

If you don't believe me, you're welcome to check out some of the state of the art languages and see how powerful they are and easy to use for these types of problems.  Erlang, Oz, Scala, or Alice are all good choices to try for something like that.

Hrmm.. I'm a little bit confused by this.  I assumed you meant the much more complex problem of dealing with actual code because the simpler case you described is a pretty basic problem.  I mean no offense by this, but I have to wonder: have you really actually done much functional programming?  You've implied you have, but I think the solution to this sort of problem is kind of obvious if you have.

As I already said, you basically use ADTs.

u = User.find(1)
u.login = 'foo'
u.phone = 'x3352'
u.save

If you're referring essentially just to the basic problem of how to deal with type safety with a computation that might fail (i.e., a property you expect not existing), well that's what monads are for.  For simple, non-IO cases you usually use Maybe (or if you want fancy non-deterministic computational support you can use lists, which are also monadic in haskell by default).  For example, a function that might fail would have a signature like this: elemExistsInList :: (a -> Bool) -> [a] -> Maybe a.  In the IO monad, you can do basically the same thing.  And you don't actually need full blown monad support to handle this problem.  OCaml can use other similar, but ultimately less general techniques to do the exact same thing.

I'm talking about a full blown O/R mapping layer like Hibernate for Java.  It maps table rows into first class objects with arbitrary attributes that then get passed around like any other Ruby object except mutations are passed transparently back on to the database.  For instance, if I have a user table like so:

id | login | phone | building
....
....
....

I can have code that uses a "User" object like this:

Code: [Select]

u = User.find(1)
u.login = 'foo'
u.phone = 'x3352'
u.save

How would you typecheck this if you can't tell if u.login is valid until runtime?

Quote

If you're referring essentially just to the basic problem of how to deal with type safety with a computation that might fail (i.e., a property you expect not existing), well that's what monads are for.  For simple, non-IO cases you usually use Maybe (or if you want fancy non-deterministic computational support you can use lists, which are also monadic in haskell by default).  For example, a function that might fail would have a signature like this: elemExistsInList :: (a -> Bool) -> [a] -> Maybe a.  In the IO monad, you can do basically the same thing.  And you don't actually need full blown monad support to handle this problem.  OCaml can use other similar, but ultimately less general techniques to do the exact same thing.

So what do you do if 95% of your code can "fail" like this?  What is static checking buying you if every function has to be decorated and checked like this?
[a href="index.php?act=findpost&pid=351139"][{POST_SNAPBACK}][/a]

Example:

Code: [Select]

getSomeDbaseProperty :: DbaseHandle -> Maybe TableProperty
getSomeDbaseProperty handle =
  case dosomething handle of
    Nothing -> ... {- failure case -}
    Just property -> {- success case -}

You can also tell the compiler to check and make sure all your pattern matching clauses are exhaustive, which adds another layer of safety.

And if you want something more powerful than just basic pattern matching, you can use an Error monad which basically gives you exceptions with the level of generality of continuations almost (or if you need that level, you can just use the continuation monad and get restartable errors even).

*shrug* Maybe at the end of the day we just have very different ideas about how to solve problems.  To me, it seems having a type system which allows one to make subtle semantic details about unsafe computations explicit in the type system, and then using that to make code very safe, is a good thing and not a hindrance.  I have a hard time seeing how the features I outlined above are not desirable for these types of problems.

I've never seen one person on either side of this argument persuaded in 100s of threads in far more detail than this one, so I guess it's unlikely we'll be the first.  Since the standard rebuttal to your standard defense of static typing above answers your points, I'll just roll it out again:

1. you have to unit test everything anyway since static typing can't catch all kinds of important errors

2. your code will work without checking for these maybe | maybe not types all over the place because you've unit tested it and all the extra checking code brings down readability.  it's like checking for a null pointer every time you access *anything*

niftyFunction =
  do obj <- retrieveObjFromDbase dbase
     building <- building obj
     if building == "someSpecialPlace" then ... else ...

3. type inference and static type safety add a layer of semantic complexity to code that a lot of programmers find confusing or at least distracting

Like I said, I used to be pretty excited by the idea of static type checking with type inference but I've personally grown to dislike it after working in languages with it and without it.   Maybe we can bet each other a six pack Haskell, Scala etc remain interesting research languages and not much more in 2015?  My other prediction is that the dynamic languages gradually start to resemble Dylan more with optional static type declarations as type assertions and aids to the compiler.
[a href="index.php?act=findpost&pid=351146"][{POST_SNAPBACK}][/a]

As for the kinds of "important errors" the type system isn't going to catch, they aren't going to be errors related to failed computations of the sort you've been describing.  The types of errors the type checker won't catch is incorrect algorithms, or doing things like checking the wrong fields perhaps (although in some cases it will catch it if the fields produce unexpected type mismatches).

Wrong.  Because of the way monads work, the failure checking is not made explicit in the syntax you are using.

I really don't know what the future of programming is going to look like, so I wouldn't make bets too heavily either way.  I do hope that there's still a place for what I feel is a good approach that so many people just seem to not understand for whatever reason, though.

Quote

As for the kinds of "important errors" the type system isn't going to catch, they aren't going to be errors related to failed computations of the sort you've been describing.  The types of errors the type checker won't catch is incorrect algorithms, or doing things like checking the wrong fields perhaps (although in some cases it will catch it if the fields produce unexpected type mismatches).

Right, but the tests you write to catch those problems will also catch the type mistakes because they won't get to point of exercising the algorithm if they don't.

Quote

Wrong.  Because of the way monads work, the failure checking is not made explicit in the syntax you are using.

I'll admit to still not really getting monads, and there's definitely some black magic possible there.  I guess I'll just say that the average ruby programmer understands the Ruby object and type system and basic metaprogramming tricks because it's really pretty simple.  I've seen a lot of very sharp and dedicated people struggle with monads.

It will be interesting to see how it all shakes out.  My guess is that the languages people are using 10 years from now will be hybrids of a lot of these ideas.
[a href="index.php?act=findpost&pid=351149"][{POST_SNAPBACK}][/a]

Quote

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

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]

Other personal observations:
I've noticed, is that for high-level tasks, there is an increasing demand for "simple" languages(LUA and Io come to mind). At the same time, industrial use requires a complex language. The current short-term trend is to have languages which specialize on being simple(LUA, Io), and languages which specialize on being complex(Python, Ruby).[a href="index.php?act=findpost&pid=361808"][{POST_SNAPBACK}][/a]

The other thing which i knew before, but noticed again, is the insanely high burden placed on development-resources by "eye-candy" - mainly regarding 3d-graphics. And the trend is for this burden to become worse and worse. Development-resources however are not infinite - so at some point it will more and more impact gameplay-design - especially regarding content-variety (the cost to add a feature to the game becomes higher and higher). Personally, i think this trend will crash and someday result in a counter-trend towards gameplay- and interaction-focussed gamedesign.