Artemidoros

What I wanted to confer was that, you _might_ have been wasting a lot of effort because I assumed that you might not have been informed about work of the Scala team that has a high likelihood of obsoleting your project in the near future. Obviously you were informed and my notice was inappropriate. Be assured it won't happen again.

If increasing the performance by about 1/4 for your use cases - compared to the current beta - is valuable for you, great! For me it wouldn't have been worth a few hours. 'A good learning experience' would have. But obviously your values are different.

I understand biz talk is a bit of a turnoff when primarily interested in the community aspects but I would expect somebody with limited technical understanding but responsibility on the biz side to prefer a site addressing their immediate concerns (which I think clojure.com does fine).

The only nitpick I would have is that it is not obvious to me if they're targeting startups or established businesses. In the later case "Training" (or "Coaching"?), "Development" (or "Seeding"?) and "Support" might be more on target than "Mentor", "Dev", and "Sustain". In the former (= startup) case I imagine their wording to be very good, but does anybody know if there is actually a market in Development and/or Mentoring consulting for startups?

I just wanted to point out the (for me at least) non obvious fact that the mind behind the theory of Clojure's persistent datastructures is working on Scala's collection library and that Scala's hash maps are already backed by hash tries - http://www.scala-lang.org/archives/downloads/distrib/files/n...

From my point of view 200 LoC giving me something I already have is a lot. From the point of view of your friend 200 LoC might be a very small price to pay for a good learning experience.

Could you give me a simple example how say filtering and mapping a collection received by a java library and pushing it back to a method expecting a collection of the original type would look like? (quite likely that I overcomplicate this in my own code)

Co/Contravariance (maybe View Bounds?) in Scala enable you to encode this relationship, but from my understanding are somewhat handicapped by type erasure.

Another problem Scala tackles is that using inheritance as a 'code sharing facility' is a bit tricky (e.g. tractability and fragile base class problem) and not composable. Scala's traits and Self Types are a real improvement in this regard. That the order of mixing in traits can have an influence the objects behavior while not its type can be seen as a problem though.

F# takes the .Net object system 'as is' and introduces 'types' more aligned to functional programming (aka. discriminated unions) as separate entities. It does not try to integrate both concepts as does Scala with its case classes.

To be more specific, when I want to transform a collection given by a Java library in a functional manner, I usually ended up with one or two localized import statements - to avoid e.g. scala.collection.mutable leaking into my other methods - and additional calls to convert the Java collection into a Scala specific and back again. This doesn't look like a big issue, but it increased the line count for a lot of cases from '1' to 3-5 ... which puts it uncomfortably close to 'dumb for loop territory'.

Admittedly, this is a small price to pay compared to the constant annoyance that is Java, but for my part I fear that there might be a slight tendency in Scala to fix interesting problems preferably to useful ones.

... lost any type information within the scala language at compile or link time...

How about this use case?

match { case x: List[Foo] => ... case x: List[Bar] => ... }

give me Scala any day of the week

Why do you have the preference for Scala? I'm curious because Scala is my language of choice for my personal projects, but I would ditch it the second a credible F# derivative would appear on the JVM (F#'s stronger emphasis on functional programming, cleaner syntax and abstaining from 'fixing typing' in OOP are the reasons for my preferences).

Is Mono actually usable with F#? The last time I checked (2 months ago) the F# plugin for MonoDevelop didn't work and the questions on how to getting it to work (by various people) went unanswered by the developer.

The runtime performance of F# code was shaky at best, the REPL had (on OS X at least) startup times to make it practically useless and without TCO the usefulness of F# really took a hit.

Not wanting to bash on Mono or F# (which is my favorite language), but writing production software with this combination is currently not something I would recommend.

In my experience this is a myth or a at least a stereotype more prevalent in the marketing of Rails than reality.

I had the strong impression during my stint in the Rails world that Ruby was mostly learned as a signaling device. Young developer slaving away at some random Java or PHP job dreaming of making it big in a startup, with the mistaken believe that simply hanging around the in-crowd will magically catapult him in the top 5% of their profession.

Sure there are good people in this community, but they became good by working hard for a very long time and not by writing a trivial Twitter client using the currently hot testing framework/NoSQL database on their MacBook Pro in a Starbucks after skimming through the pick axe book.

wanting to be a cool Rubyist like _why causes a lot less damage than wanting to have a high-paying job

Why should chasing fame be inherently better than chasing money?

Just speaking from my own experience, I learned way more from cynic mercenaries than from wannabe rockstars and I can't see why emulating e.g. Obie Fernandez will cause less damage than aiming for a position as a technical fellow.

Than you seem to have had much more luck than I did.

because:

a) You're awesome, as long as you're using Ruby no matter how ridiculous you look when seen without rainbow colored glasses - http://www.infoq.com/presentations/ford-large-rails

b) The "you're doing it wrong crowd" will shout you down the moment you admit having troubles - http://glu.ttono.us/articles/2007/04/15/on-twitter-rails-and...

c) Most failed Ruby (which in all fairness usually means Rails) projects never gain any publicity.

d) Ruby projects coming close to the gargantuan scope of some of the bigger Java projects are (thankfully) exceedingly rare (if not non existent).

Lastly I had no clue that Saeed al-Sahaf is now working for Object Mentor, awesome!

Disclaimer: I worked for 3 years as a Ruby developer, including on one of the bigger (> 50.000 loc) Rails projects out there and I encountered some crashing and burning myself (I know I did it wrong).

I only catch glimpses of the MS world when I have to use common libraries originally developed by our Windows experts, whose design decisions often leave me puzzled. I am curious about what you think about the idea, that OSS culture incentivized creating architectures conforming to fashion trends, while MS culture incentivized to finish feature X until Y - no matter what it takes (just do it Scotty).

e.g. in the OSS world beginning of 2000 J2EE spawned heavily over-engineered solutions, which were displaced by the convention over configuration trend exploding (mostly due to Rails) around 2006. And now the TDD/BDD crowd are fighting it out with the Architecture & Patterns gang with the DDD and DSL tribes assimilating the surviving concepts...

A member of a currently hip fashion trend will have a better staying power in a nasty flamewar caused by a random design decision about the color of a bike shed in an OSS project than a lone warrior. So you start having design styles competing for followers.

Meanwhile in the MS world (wild guess following) heavily funded 'central planning solutions' (from frameworks to design styles taught for certification purposes) offered by MS stymied competition of alternative approaches. A focus on - if I understood your correctly - usually very risk adverse business needs, while keeping the actual code of produced solutions hidden from outsiders additionally put developers under pressure to avoid experiments.

Would it be reasonable to say that we have an evolutionary system of small actors competing for developers interests (OSS) fueled by <insert book about OSS phenomenon> vs. a central planning approach of a major corporation backed by a huge war chest?

Do you have an idea why this is the case? Or the other way around why the architecture of OSS projects seems to be saner?

disclaimer: I have no exposure to the MS stack, with the exception of playing around with F# which in my opinion is a very well designed language.

Even with the better runtimes now available, suggesting that they come close to the stability (and performance and long term memory consumption and profiling + debugging capabilities) you'll find on the big JVMs is not really helpful (JRuby being the obvious exception but even here I am sceptic).

If you want to test the world beyond MS I would recommend (apart from Rails or Django) looking into the Scala/Lift (my preferred toolset), Clojure/Compojure or JavaScript/Node.js combos (depending upon you language preferences).

I would be careful with Rails, when you plan to do some heavy data processing and/or if you need your application processes to run for a long time without being restarted.

For small, straightforward applications or prototyping the Ruby/Sinatra/MongoDB combo is also really really nice.

edit: some of the "performance psychology" things I learned helped me passing some of the more hairy tests during for my b.sc. in bioinformatics

"The Mental Athlete" ( http://books.google.com/books?id=OVqMC9Zs3cAC&lpg=PP1... ) though seems to be closer to your intentions (I can't recommend it though as I haven't read it yet, but FWIW all books I read from this publisher turned out to be excellent and superficial skimming of it's google books page seems to confirm that).

i guess, germany as a whole (maybe berlin being the exception) is not very much into y combinator like founding and munich might be especially adverse to this kind of company seeding.