Re: F# fsharp

On Jun 11, 2010, at 12:14 AM, Brandon Van Every wrote:

> On Fri, Jun 11, 2010 at 12:45 AM, Jon Frisby <[email protected]> wrote:
>> 
>> On Jun 10, 2010, at 10:45 PM, Brandon Van Every wrote:
>> 
>>> On Thu, Jun 10, 2010 at 11:37 PM, Jon Frisby <[email protected]> wrote:
>>>> Perl, Python, PHP, and Ruby all share the characteristic of being the product of a handful of individuals that became sufficiently widely used through purely 'organic' growth that they are now taken seriously at many large companies
>>> 
>>> nitpicks:
>>> - Google hired Guido
>>> - nobody takes Perl 6 seriously
>> 
>> They hired Guido AFTER Python had already become widely used.
> 
> But the marketing of Python to corporations under Guido and the PSF
> was a joke.  Once Guido was in Google's employ, "adult things" were
> made to happen with Python.  Things that open source volunteers tried
> to get to happen earlier, but were blocked.  My point is, it took
> corporate backing to get Python to its next stage of growth and
> mainstream acceptance.

"Adult things"?  I'd say that hundreds or thousands of companies building their infrastructure on Python was fairly "adult".  Once again you're using vague, loaded terminology to be dismissive.  

What "adult things" are you referring to?


>> And Perl falling flat on its face does not change the fact that for a good long time, Perl 5 was commercially significant (and still sees wide usage today).
> 
> It says that there are evolutionary dead ends in open source.  Also,
> that a "better language" (Ruby) can pick up where a stagnating
> technology left off.

That there are evolutionary dead-ends in open source is a non-argument.  There are evolutionary dead-ends in closed-source too.  Of course the difference is that an open source project doesn't necessarily die just because a particular corporation did -- but when a corporation dies (or gets out of a line of business), its technology almost always dies (unless they spin it off into a new company of course).


> I suppose you're waiting for the Second Coming Of Lisp?  ;-)

No, but I do find it amusing that so many of the "innovations" of newer languages have been in Lisp since as far back as 1958.  Garbage collection, first-order functions, yadda yadda yadda.  However, that's not terribly relevant here.  My point is that the age of the tool is not *solely* a determinant of whether it has succeeded or failed.


>> It wasn't until Rails came along that people 'noticed' that Ruby was actually quite well suited to 'the web'.
> 
> We could all do with another Next Big Thing on the order of the
> dot.com boom.  Would be nice for all programmers to be treated like
> gods and rock stars again.

Actually, the attitudes at VC-backed startups tended to be incredibly parochial.  There was little or no tolerance for being on the cutting edge with respect to tools, because of the hiring difficulties.  A VC backed company was expected to *grow*grow*grow*.  That didn't just mean eyeballs and pageviews, but also headcount.  If you went to a VC and made a pitch that they liked you still had to make it through due-dilligence and finding out that you were using something OTHER than what everyone else was using -- Ruby/Haskell/whatever instead of Perl/PHP/Java or *maybe* Python towards the end of that era -- would easily be viewed as a huge risk.  Consequently, that attitude pervaded the companies that DID get funding.

Ruby became popular in the web world long AFTER the dot-com boom ended, and it did so entirely because of Rails which was the product of one head-strong engineer at a tiny little self-funded startup (37 Signals).  Rails wasn't open sourced until 2004.


>> Ruby did not need to change to be better for 'the web', it just needed to overcome peoples tendency to be dismissive of the unfamiliar and to utterly lack any imagination/foresight/etc.
> 
> On the other hand, techies are poor marketers and generally can't rise

That actually only serves to strengthen my point.


> once did.  Rather, in another 10 years, mainstream programming
> languages will have finished co-opting anything of value in Lisp.

Of course.  I'm not saying technologies DON'T die, or become permanently crippled.  I'm asserting that there is enough variance in adoption rates that a technology as young as Haskell can't exactly be written off just yet solely on the basis of its age.  Now, if you'd care to be more specific about why Haskell is doooooooooomed, rather than just being hand-wavy about it, that might be an interesting discussion.


>>> The clear explanation is there were easy gains to be made in open
>>> source Unix clones, Unix admin tools, and web apps.  Pretty much all
>>> of the "O'Reilly languages" grew because of the web.  Haskell worried
>>> about academic stuff, and consequently nobody cared.
>> 
>> Or perhaps people who aren't using Haskell have made deep assumptions about how it must be grossly unsuited to anything but 'academia' and have thus chosen to ignore it.
>> 
>> You've made a bunch of statements hand-waving Haskell away with the slander of 'academia', but have not once pointed to a specific behavior/feature (or lack thereof) that makes it unsuitable for real world use -- other than the fact that it ISN'T being used widely.
> 
> Sure I have, but you'd have to read back a few posts.  "Pure"
> functional programming is anathema to getting things done in the real

So here's the high-level assertion...

> world.  It has few users and consequent low implementation quality,
> for basic support issues like getting the compiler working, finding
> well maintained libraries, etc.

... and we're back to the circular argument that the tool is a poor choice because nobody uses.  (Nobody uses it, because it's a poor choice, wash, rinse, repeat.)

This is an argument from *practicality* and perfectly valid when making real choices for real tools in the real world, but it says nothing fundamental about the tool itself.  As a consequence, it does not provoke thought that might lead to better tools.

WHY do "pure" functional programming languages suffer this fate?  Is it that they are badly suited to real-world problems, or is it that they break the brains of programmers just enough to impose a high barrier to adoption in light of our finite amount of time/attention?  If the former, then perhaps FP isn't worth discussing at all.  If the latter (but NOT the former -- could be an AND, not an OR situation...) then what benefits do such tools provide and how can those be put into a more readily consumable form?

I'm unconvinced, for example, that F# has a sufficiently low learning curve to escape the ghetto of companies whose decision-making process centers around "Nobody ever got fired for buying Microsoft" -- even with first-class support for Mono.  While the imprimatur of the Microsoft branding may force programmers to swallow the bitter pill of learning something considerably foreign to what they are used to, that's far less useful than if it was so interesting that people who aren't saddled with C++ (or even C#) coveted it.

-JF

_______________________________________________
Sweng-Gamedev mailing list
[email protected]
http://lists.midnightryder.com/listinfo.cgi/sweng-gamedev-midnightryder.com