Why Don't You Use F#?

[Jamie Dixon]

I did a presentation at codestock on Saturday about building the business case for using F#.  There was some resistance both during and after the talk.  I did my best to solicit opinions from different people in the audience about why they don't use F#.  Here is my collection of answers.  I am aggregating the questions first before trying to come up answers (if there are any).  Please add any other criticisms/reasons to not use F#.  Note that I am not passing judgments on the validity of the responses, just collecting them.

Thanks

Microsoft Specific

• Anything you do in F# and can I do in C#

• C# has much more Microsoft support

• It is easy to get C# jobs.  There are no F# jobs

• C# is the language of choice for Microsoft

• I am 100% productive in C#.  I don’t have the time to learn a new thing

• Microsoft is going to kill F#

• It is too hard to learn

• Intellisense sucks.  It makes no sense

• MSDN can’t help

• I tried a couple of F# books and they don’t help

• Linq is good enough for me

   

Non-Microsoft

• F# and/or functional programming is not all that is cracked up to be

• It is a fringe language without traction. 

• Erlang, Scala, Haskill, Lisp are better functional langauges

• Python is a better functional language

• Functional people are too ivy-tower

[Morgan Persson]

2014-07-13 22:33 GMT+02:00 Jamie Dixon <james...@gmail.com>:

I did a presentation at codestock on Saturday about building the business case for using F#.  There was some resistance both during and after the talk.  I did my best to solicit opinions from different people in the audience about why they don't use F#.  Here is my collection of answers.  I am aggregating the questions first before trying to come up answers (if there are any).  Please add any other criticisms/reasons to not use F#.  Note that I am not passing judgments on the validity of the responses, just collecting them.

Thanks

Microsoft Specific

• Anything you do in F# and can I do in C#

• C# has much more Microsoft support

• It is easy to get C# jobs.  There are no F# jobs

• C# is the language of choice for Microsoft

• I am 100% productive in C#.  I don’t have the time to learn a new thing

Made me think of this.

/Morgan

[round crisis]

Can I add:

-  I love F# (tho I haven't used it) but I have no time to learn it properly

I found myself in  similar situations, tho there was always the one or two who get really excited about F#, so you win some and some others tell you stuff like that
I am with Morgan on how it feels like when you hear these excuses

[Jack Fox]

The business case for F# can be condensed to one word, "correctness". At Tachyus (we are hiring F# engineers) we aim to disrupt an entrenched industry with this advantage. While it will take years for some to see the advantage, internally we are satisfied that a full F# stack is desirable. There is another company on the east coast also going after big entrenched competition that has apparently drawn a similar conclusion, and is also hiring F# engineers.

What is the business case for writing incorrect software?

[Victor Baybekov]

I could strike through each point you mentioned, but .NET's open-source universe in inferior to JVM's (and Python's) - for me this is the main reason not to use F# exclusively. I have spent almost 2 years learning/using F# and I enjoy it. Other things being equal, I would use it in most cases (and C# in others). However, other things are not equal. Five days ago I started learning Scala and JVM in general, because I do not like the idea of reinventing the wheel (probably the wheels from the Morgan's picture are not squared at all, or the road is more developed for the squared wheels), I cannot ignore the huge number of good libraries (Twitter libs/Apache/ElasticSearch/Datomic) and IKVM is not a silver bullet.

The good thing with Scala is that I feel I already know it: it is something in between of C# and F#. Instead of a religious war on which language is better, I just want to leverage the best parts from the best two platforms (.NET, JVM), and I started working on convenient interop between the two worlds using JSON-serialized message passing. F#, and the whole .NET, is definitely not enough now, but one is not obliged to choose either one or another.

I think the back-door strategy (i.e. promoting F# for non-production code or for small parts where F# is best as the first step, e.g. latest Tomas's talk at NY meetup) is much better than telling other smart people that their wheels are squared (which is effectively telling them they are stupid). I am attending Hacker School in NYC now, and I am the only .NET and F# guy here. I tried to be vocal about how good in F#... but I prefer to make friends than to be right - when there is no universal truth and others are also right in their own way.

To my surprise, many people at Hacker School do not know that F# is open source, cross platform, has good free tooling other than VS, allows to write cross-platform mobile apps, has great community and documentation, adopted in industry. Despite the fact that they are younger and more open-minded/curious than an average enterprise programmer... They know that MSFT = M$FT and is (used to be) evil, and stop at that point. Last week there was a flame war about F# vs. OCaml, and the major point was that F# is not ready for "high-scale production" and there is no single example, but OCaml has *1* example - Jane Street, and "1 > 0". After pointing to the testimonials page/Tachyus, the argumentation became mostly irrational. For some reason, Jane Street is hot, and MSFT & Co are not.

[Michael Langford]

Newbie perception:

I originally looked at F# because I'm a (Objective-C) iOS dev looking to have a good server language that I MIGHT also be able to use to program on Android (that is also functional; I love FRP on iOS). 

 Almost all mobile dev's who target iOS as even part of their workflow use macs due to the Apple based compilation requirement. This is coming from a developer who doesn't write the language his main package manager for his job is written in (Ruby, Cocoapods, I program in Objective C), but can read it well enough to find out what's wrong.

The development case for mac based development is lacking.

Even the Try F# pages don't work on the popular browsers on Mac. (Go here http://www.tryfsharp.org/Learn/getting-started#chaining-functions, in safari, try to type the code in in the top box. Nope). Pretty sure they didn't work well at all on iPad either.

Trying F#:

Nuget and Xamarin were coming up with errors, repos weren't there, what is and isn't open source, didn't feel like it was there. F# support on popular hosted platforms is lacking (such as Heroku and AWS), preferring to ghettoize back to baas platforms that the .NET community prefers over the OSS community, platforms that feel like they lock in rather than open up to someone who's worked mainly with ruby, php, node and python devs.

When I'd do tutorials, read books (of which I purchased several), or otherwise work through examples, they almost NEVER actually ran by the end. It feels like massive tool rot/code rot. Like people inherited a big mansion but can't pay the bills to keep it up so it's falling apart.

(For Clojure and Haskell I  got further with less effort).

Nuget feels opaque and communities feel corporate and APIs relatively undocumented.

By comparison, the Clojure books I'd read: Some of them were clearly wrong, but there were multiple working examples out there that DID work, and featured prominently in google searches on the matter.  There were *relatively* few broken examples. There were clear concise opinions about the reason why X or Y was a better framework for different

Everything is still so VS/.NET/Windows only service oriented, you can rarely find a tutorial that doesn't require figuring out how the tech works independent of it. And the language is directed so heavily at IDE based usage, when it doesn't work, it really really doesn't work.

It feels like lots of "Directions have been set" in the F# community that in 2-3 years, it'll be in a place to compete with the other OSS languages out there, but right now, from an independent developer learning it perspective: It still feels incredibly corporate and windows oriented stack, especially for the dev machine. 

You need some strong outreach to the linux and mac communities who make up the php/ruby/python programmers of the world, and first class tool support for them to move F# to "tasting like OSS" instead of "tasting very microsofty". Part of this may need to be a "Move out of IDEs" : Those platforms have a huge history of using things other than VS style IDEs to do their work.

I am certain with X time spent, F# would be working well enough a web product or web and mobile project could launch. But I feel like other languages in a similar (functional) space have a X/2 and X/3 deployment story today due to the tooling available, for the platforms I (and many others) have to work from. 

I really hope F# gets there soon. It doesn't feel like it's there now.

--
--
To post, send email to fsharp-o...@googlegroups.com
To unsubscribe, send email to
fsharp-opensou...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/fsharp-opensource
---
You received this message because you are subscribed to the Google Groups "F# Discussions" group.
To unsubscribe from this group and stop receiving emails from it, send an email to fsharp-opensou...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Michael Langford
404-647-4643

[Chris Marinos]

IMO, the resistance isn't about F# specifically. Each bullet points is more of a symptom than root cause. I think that a majority of developers have a natural resistance to *any* new language that you try to sell them, and many times this is a healthy resistance. The remaining developers are the ones you're more likely to run into at conferences, user groups, etc. These are the ones who are eager to learn about and adopt new technologies- sometimes to their detriment. It's not difficult to convince these devs to learn about F#.

I think the key to converting the other developers is not as much about removing the resistance as it is about finding an overwhelming reason for change. This reason has to be compelling enough to offset the cost of rewrites, team retraining, developer investment, etc. This is not an easy thing to accomplish.

-Chris

[Isaac Abraham]

All true. However, for entrenched C# houses, it's very much a case of "I can write code with C# effectively. There's no need to change". Obviously there's an element of lack of knowledge there, but it is what it is.

I'm not worried in a sense that people think that Microsoft are about to ditch F#. This tells me more about how the language is currently perceived.

---

From: Jack Fox
Sent: ‎14/‎07/‎2014 16:38
To: fsharp-o...@googlegroups.com
Subject: Re: Why Don't You Use F#?

The business case for F# can be condensed to one word, "correctness". At Tachyus (we are hiring F# engineers) we aim to disrupt an entrenched industry with this advantage. While it will take years for some to see the advantage, internally we are satisfied that a full F# stack is desirable. There is another company on the east coast also going after big entrenched competition that has apparently drawn a similar conclusion, and is also hiring F# engineers.

What is the business case for writing incorrect software?

[Ryan Riley]

Thank you, Michael, for the excellent feedback.

---

From: Michael Langford
Sent: ‎7/‎14/‎2014 11:51 AM

To: fsharp-o...@googlegroups.com
Subject: Re: Why Don't You Use F#?

Newbie perception:

I originally looked at F# because I'm a (Objective-C) iOS dev looking to have a good server language that I MIGHT also be able to use to program on Android (that is also functional; I love FRP on iOS). 

 Almost all mobile dev's who target iOS as even part of their workflow use macs due to the Apple based compilation requirement. This is coming from a developer who doesn't write the language his main package manager for his job is written in (Ruby, Cocoapods, I program in Objective C), but can read it well enough to find out what's wrong.

The development case for mac based development is lacking.

Even the Try F# pages don't work on the popular browsers on Mac. (Go here http://www.tryfsharp.org/Learn/getting-started#chaining-functions, in safari, try to type the code in in the top box. Nope). Pretty sure they didn't work well at all on iPad either.

Trying F#:

Nuget and Xamarin were coming up with errors, repos weren't there, what is and isn't open source, didn't feel like it was there. F# support on popular hosted platforms is lacking (such as Heroku and AWS), preferring to ghettoize back to baas platforms that the .NET community prefers over the OSS community, platforms that feel like they lock in rather than open up to someone who's worked mainly with ruby, php, node and python devs.

When I'd do tutorials, read books (of which I purchased several), or otherwise work through examples, they almost NEVER actually ran by the end. It feels like massive tool rot/code rot. Like people inherited a big mansion but can't pay the bills to keep it up so it's falling apart.

(For Clojure and Haskell I  got further with less effort).

Nuget feels opaque and communities feel corporate and APIs relatively undocumented.

By comparison, the Clojure books I'd read: Some of them were clearly wrong, but there were multiple working examples out there that DID work, and featured prominently in google searches on the matter.  There were *relatively* few broken examples. There were clear concise opinions about the reason why X or Y was a better framework for different

Everything is still so VS/.NET/Windows only service oriented, you can rarely find a tutorial that doesn't require figuring out how the tech works independent of it. And the language is directed so heavily at IDE based usage, when it doesn't work, it really really doesn't work.

It feels like lots of "Directions have been set" in the F# community that in 2-3 years, it'll be in a place to compete with the other OSS languages out there, but right now, from an independent developer learning it perspective: It still feels incredibly corporate and windows oriented stack, especially for the dev machine. 

You need some strong outreach to the linux and mac communities who make up the php/ruby/python programmers of the world, and first class tool support for them to move F# to "tasting like OSS" instead of "tasting very microsofty". Part of this may need to be a "Move out of IDEs" : Those platforms have a huge history of using things other than VS style IDEs to do their work.

I am certain with X time spent, F# would be working well enough a web product or web and mobile project could launch. But I feel like other languages in a similar (functional) space have a X/2 and X/3 deployment story today due to the tooling available, for the platforms I (and many others) have to work from. 

I really hope F# gets there soon. It doesn't feel like it's there now.

On Mon, Jul 14, 2014 at 11:55 AM, Victor Baybekov <vbay...@gmail.com> wrote:

I could strike through each point you mentioned, but .NET's open-source universe in inferior to JVM's (and Python's) - for me this is the main reason not to use F# exclusively. I have spent almost 2 years learning/using F# and I enjoy it. Other things being equal, I would use it in most cases (and C# in others). However, other things are not equal. Five days ago I started learning Scala and JVM in general, because I do not like the idea of reinventing the wheel (probably the wheels from the Morgan's picture are not squared at all, or the road is more developed for the squared wheels), I cannot ignore the huge number of good libraries (Twitter libs/Apache/ElasticSearch/Datomic) and IKVM is not a silver bullet.

The good thing with Scala is that I feel I already know it: it is something in between of C# and F#. Instead of a religious war on which language is better, I just want to leverage the best parts from the best two platforms (.NET, JVM), and I started working on convenient interop between the two worlds using JSON-serialized message passing. F#, and the whole .NET, is definitely not enough now, but one is not obliged to choose either one or another.

I think the back-door strategy (i.e. promoting F# for non-production code or for small parts where F# is best as the first step, e.g. latest Tomas's talk at NY meetup) is much better than telling other smart people that their wheels are squared (which is effectively telling them they are stupid). I am attending Hacker School in NYC now, and I am the only .NET and F# guy here. I tried to be vocal about how good in F#... but I prefer to make friends than to be right - when there is no universal truth and others are also right in their own way.

To my surprise, many people at Hacker School do not know that F# is open source, cross platform, has good free tooling other than VS, allows to write cross-platform mobile apps, has great community and documentation, adopted in industry. Despite the fact that they are younger and more open-minded/curious than an average enterprise programmer... They know that MSFT = M$FT and is (used to be) evil, and stop at that point. Last week there was a flame war about F# vs. OCaml, and the major point was that F# is not ready for "high-scale production" and there is no single example, but OCaml has *1* example - Jane Street, and "1 > 0". After pointing to the testimonials page/Tachyus, the argumentation became mostly irrational. For some reason, Jane Street is hot, and MSFT & Co are not.

On Monday, July 14, 2014 5:37:53 AM UTC-4, Morgan Persson wrote:

2014-07-13 22:33 GMT+02:00 Jamie Dixon <james...@gmail.com>:

I did a presentation at codestock on Saturday about building the business case for using F#.  There was some resistance both during and after the talk.  I did my best to solicit opinions from different people in the audience about why they don't use F#.  Here is my collection of answers.  I am aggregating the questions first before trying to come up answers (if there are any).  Please add any other criticisms/reasons to not use F#.  Note that I am not passing judgments on the validity of the responses, just collecting them.

Thanks

Microsoft Specific

• Anything you do in F# and can I do in C#

• C# has much more Microsoft support

• It is easy to get C# jobs.  There are no F# jobs

• C# is the language of choice for Microsoft

• I am 100% productive in C#.  I don’t have the time to learn a new thing

Made me think of this.

/Morgan

--

--
To post, send email to fsharp-o...@googlegroups.com
To unsubscribe, send email to
fsharp-opensou...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/fsharp-opensource
---
You received this message because you are subscribed to the Google Groups "F# Discussions" group.
To unsubscribe from this group and stop receiving emails from it, send an email to fsharp-opensou...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Michael Langford
404-647-4643

[Kristopher Johnson]

I recently wrote a small iOS app in F#. This was partly for personal education/interest, but also partly to give recommendations to a client.

The experience was "fun" for me because I enjoy learning new programming languages and experimenting with functional programming. However, it is hard to recommend F# as a general-purpose iOS development language to clients/bosses for these reasons:

- Learning curve would be considered steep by most developers without experience with FP or F#.

- While it provides access to the native iOS APIs, the differences in the names of functions, types, and other identifiers led to a lot more need to refer to the documentation than I expected. I understand the desire to provide an API that seems more natural for F#, but it was frustrating to feel like an iOS developer newbie again.

- Dependency on Xamarin is a risk that you wouldn't have if you stick with Apple's tools.

- Xamarin's license cost isn't unreasonable, but it's not ignorable either.

- Apple's new Swift language provides many of the benefits of F# (in comparison to Objective-C). It may not be as good as F#, but it may be "good enough", and it is a more natural migration path for current and future iOS developers.

- Cross-platform development for iOS and Android (and other platforms) is an attractive feature, but it doesn't seem to be as easy to accomplish in real-life as the documentation suggests.

I'd echo many of the things that Michael Langford wrote. Books, documentation, and tutorials are not up to date, and if you aren't using the Microsoft stack then a lot of what is out there is irrelevant.

I like F#, and if I was completely independent I might use it for my apps. But it's hard for me to recommend to somebody else who just wants to get iOS apps written as efficiently and expediently as possible.

-- Kris

[don...@fastmail.fm]

Hi all,

 

I'm quite pleased with this discussion, because instead of discussing "is it even possible to write an F# app for iOS/Android/...", you're discussing when it would be the right choice vis.a.vis much more established approaches on those platforms.  Considering that Xamarin only recently released their integrated support for F# that seems like a pretty normal phase in the socialization of a new programming language on a platform.

 

For those involved in bringing F# to those platforms, even getting to this point where you're having this discussion is a huge win. F#-on-iOS/Android currently allows F# developers (or those inclined towards it) to use F# on these very major platforms. That's great, especially since half the world still seem to think that F# is for Windows only.

 

I don't really think anyone claims that F# is the undeniable-go-to-language-of-choice for these platforms - though it's viability will continue to improve.  F# today is now a reasonable choice for these platforms, especially if you already know the language, want the benefits it brings, have code assets in it, or are inclined to teach or learn it, but the choice must certainly be placed in context.  

 

Cheers,

Don

 

 

On Tue, Jul 15, 2014, at 06:39 PM, Kristopher Johnson wrote:

I recently wrote a small iOS app in F#. This was partly for personal education/interest, but also partly to give recommendations to a client.

 

The experience was "fun" for me because I enjoy learning new programming languages and experimenting with functional programming. However, it is hard to recommend F# as a general-purpose iOS development language to clients/bosses for these reasons:

 

- Learning curve would be considered steep by most developers without experience with FP or F#.

 

- While it provides access to the native iOS APIs, the differences in the names of functions, types, and other identifiers led to a lot more need to refer to the documentation than I expected. I understand the desire to provide an API that seems more natural for F#, but it was frustrating to feel like an iOS developer newbie again.

 

- Dependency on Xamarin is a risk that you wouldn't have if you stick with Apple's tools.

 

- Xamarin's license cost isn't unreasonable, but it's not ignorable either.

 

- Apple's new Swift language provides many of the benefits of F# (in comparison to Objective-C). It may not be as good as F#, but it may be "good enough", and it is a more natural migration path for current and future iOS developers.

 

- Cross-platform development for iOS and Android (and other platforms) is an attractive feature, but it doesn't seem to be as easy to accomplish in real-life as the documentation suggests.

 

I'd echo many of the things that Michael Langford wrote. Books, documentation, and tutorials are not up to date, and if you aren't using the Microsoft stack then a lot of what is out there is irrelevant.

 

I like F#, and if I was completely independent I might use it for my apps. But it's hard for me to recommend to somebody else who just wants to get iOS apps written as efficiently and expediently as possible.

 

-- Kris

 

 

On Sunday, July 13, 2014 4:33:14 PM UTC-4, Jamie Dixon wrote:

I did a presentation at codestock on Saturday about building the business case for using F#.  There was some resistance both during and after the talk.  I did my best to solicit opinions from different people in the audience about why they don't use F#.  Here is my collection of answers.  I am aggregating the questions first before trying to come up answers (if there are any).  Please add any other criticisms/reasons to not use F#.  Note that I am not passing judgments on the validity of the responses, just collecting them.

 

Thanks

 

Microsoft Specific

• Anything you do in F# and can I do in C#
  

• C# has much more Microsoft support
  

• It is easy to get C# jobs.There are no F# jobs
  

• C# is the language of choice for Microsoft
  

• I am 100% productive in C#.I don’t have the time to learn a new thing
  

• Microsoft is going to kill F#
  

• It is too hard to learn
  

• Intellisense sucks.It makes no sense
  

• MSDN can’t help
  

• I tried a couple of F# books and they don’t help
  

• Linq is good enough for me
  

  
  

Non-Microsoft

• F# and/or functional programming is not all that is cracked up to be
  

• It is a fringe language without traction.
  

• Erlang, Scala, Haskill, Lisp are better functional langauges
  

• Python is a better functional language
  

• Functional people are too ivy-tower
  

[Vasily Kalugin]

I Have used f# since 2010. First time , I was thinking like C# group, after 2 years f# became my favorite language,  clear logic, vey easy understand, smaller code. Now I would say not all my f# code , can translate to C# (it will be in 2 or more  times more code then F# code). Just need to something build and go thru headache some days .... and brain will be rebuilt for f#)

[Warren Young]

> On Jul 15, 2014, at 11:39 AM, Kristopher Johnson <kristophe...@gmail.com> wrote:
>
> - Xamarin's license cost isn't unreasonable, but it's not ignorable either.

Obsolete: https://en.wikipedia.org/wiki/Xamarin#Microsoft_subsidiary_.282016-present.29

[Warren Young]

“You” in my responses below refers to the objector, not to the post author.


On Jul 13, 2014, at 2:33 PM, Jamie Dixon <james...@gmail.com> wrote:
>
> • Anything you do in F# and can I do in C#

Anything you can do in F#, I can do by injecting charge carriers into the DRAM with a particle accelerator and a precision X-Y table.

Possible is not the same thing as sensible.

> • C# has much more Microsoft support

Tooling arguments always amuse me. If the tooling argument were valid, no good software would have come out before 5 years ago, because no one could write it, lacking “good tools.”

Since I know from personal experience that I can write voluminous amounts of good software using only command line compilers, Vim and GNU make (and consider myself lucky because I’m not using BSD vi and AT&T make!) I believe all tooling arguments are superficial.

Don’t get me wrong, I like nice tooling. I also like leather seats in my car.

These people are saying that they cannot drive to their destination because their car is in the shop and the local car rental agency only has models with cloth and vinyl seats. There’s a Somali man out there sneering at you from atop his junk bicycle.

I don’t meant to discourage our benefactors from improving the F# tooling, but they should only be doing it to please those of us already using F#, not to vainly try to win new converts. No amount of improvement in the F# tooling will solve that problem, because tooling isn’t the actual problem.

> • It is easy to get C# jobs. There are no F# jobs

All C# jobs are potentially F# jobs.

Yes, I know, there are managers who refuse to let the developers doing the work choose their own tools regardless of justification. You don’t want to work there anyway.

> • C# is the language of choice for Microsoft

I guess we’d better kill off Visual C++, TypeScript, VB.net, and VBA, then. There can be only one!

Wikipedia lists 743 “notable” programming languages, by their lights:

https://en.wikipedia.org/wiki/List_of_programming_languages

And that list is conservative, since I’ve written significant code in at least one language not on the list, which has more deployed seats than several others I see on that list.

This is *Microsoft* guys, the company famous for supporting technologies long past the point where most other companies would have killed them off.

What was the last programming language Microsoft really killed off, anyway? Visual J# doesn’t quite count, since it lives on in the modern web stack. Maybe it’s VB6, nearly 2 decades ago?

You don’t get to dither for another decade or two, then cry “success” when Microsoft does eventually EOL F#. The proper response is, “Wow, I could have been using it for a decade or two.”

> • I am 100% productive in C#. I don’t have the time to learn a new thing

This is either the first section of your programming career, or you were 100% productive in the *prior* language of choice before C#, too.

Very few people get to use just one language through their entire careers.

(And many, like me, wouldn’t want to even if we could!)

> • Microsoft is going to kill F#

The only thing they can do at this point is pull their resources, and that wouldn’t kill F# by itself.

How many languages can you name with healthy open source communities, and why can there not be one more?

Even if Microsoft pulled all resources it gives to F# today and the community stopped improving it the day after, F# 4.1 is still a highly useful language today. Enough so to get you through your next project at least, by which point you might want to be looking at something else anyway.

> • It is too hard to learn

On a scale of 1 to 10, with 10 being the most difficult programming language to learn, I’d put C# at 5 and F# at 6. If that’s all it takes to push you to your point of incompetence, you should probably back off from C# as well.

I’m quite serious about that. Debugging code is about twice as difficult as writing it, so if you’re writing code at the limit of your technical capability, you cannot successfully debug it except by accident, logically speaking.

> • Intellisense sucks. It makes no sense

That’s the tooling argument again.

> • MSDN can’t help

Anyone who thinks the F# material in MSDN is insufficient is utterly spoiled.

> • I tried a couple of F# books and they don’t help

Argument from incompetence again. Better switch to Python.

> • Linq is good enough for me

Excel is functional in a very pure sense, but I think most of us here know what happens when people try to turn it into a software development environment.

> • F# and/or functional programming is not all that is cracked up to be

Let me get this straight: F# is too difficult to learn, so you’re going to go back to debugging data races and thread synchronization hairballs?

Or is the argument that it’s all just a fad? If so, I guess the objector isn’t aware that LISP was introduced to the world between FORTRAN and COBOL, arguably making it one of the three oldest high-level programming languages still in widespread use.

…or that ML, F#’s most direct ancestor, goes back to the early 1970s.

> • It is a fringe language without traction.

I think we disagree on the definition of “fringe.” In my world, *Sather* is a fringe language.

(Admit it, you had to Google it!)

In my world, PL/SQL is not a fringe language, but I wouldn’t want to bet on whether there are more PL/SQL programmers than F# programmers.

> • Erlang, Scala, Haskill, Lisp are better functional langauges

[citation needed] :)

> • Python is a better functional language

[flamebait]

> • Functional people are too ivy-tower

Maybe 15 years ago, sure.

That stopped once Moore’s Law^W Business Rule started to be pushed along mainly by multicore architectures, forcing programmers to write parallelizable programs if they wanted new computers to run their programs faster at the rate we got used to in the preceding three decades or so.


====================


I believe there is only one good argument against using F#: “I don’t like the language.” You can’t argue with taste.

[Jamie Dixon]

Warren:

Are you part of the FSharp Foundation?  If so, you might want to consider signing up:  http://foundation.fsharp.org/join

Nice replies, thanks for taking the time

[Casper Bollen]

Add tooling to this list. I love the F# language, but I hate the tooling and project management. When developing javascript, Elm, purescript project management is so much easier compared to the incredible complexity of project management of the net environment (mono, netcore, .net, all awful).

I tried Xamarin, Atom, VSCode, VS2015 and only VS2015 in the windows environment delivers a stable project management experience, but is limited to the windows environment. 

NetCore looked like the light on the horizon with a 'normal' json project file, and then they abandoned this in favor of really ugly and unreadable xml format ;-(

I still do not know how to do proper project management with F# in a environment agnostic way. I just can't get it in my head. Using the node environment this seems a no brainer, one json project file. Install dependencies using something like install name --save and that's it! 

So, I think, a much simpler project management system would really be helpful to lure people into using F#.

[Warren Young]

On Jul 29, 2017, at 2:07 AM, Casper Bollen <hal...@gmail.com> wrote:
>
> I hate the tooling and project management.

I wish people wouldn’t blame F# for individual IDE/editor shortcomings.

If you don’t like how Xamarin, VSCode, or Atom manage F# projects, blame the editor or IDE, don’t blame F#.

> When developing javascript, Elm, purescript project management is so much easier

Of those three, I only use JavaScript, and my reaction to that is *what* JavaScript project management? Unlike with F#, there are no canonical tools for it, other than the browsers, and the browsers don’t have project management.

It sounds like you’re comparing My Favorite Text Editor to all of the F# tools. If so, be clear about it.

Personally, my “JavaScript project management” is a Makefile, and that only because I need something to drive the validation, merging, and minification process, which I hand-built back in the days before we had all-in-one tools that do that.

The current F# tool alternatives are a bit of a mess at the moment, as we’re at a point of transition, what with the Xamarin buyout, the .NET Core transition, etc. But, I still think the JavaScript world is in a far messier state:

https://hackernoon.com/how-it-feels-to-learn-javascript-in-2016-d3a717dd577f

> mono, netcore, .net, all awful

Let’s take those in order:

1. Mono: “awful” why? Be specific. Personally, this is my first choice when it comes to cross-platform development. Just write a Makefile and you’re done. If you don’t like GNU make, pick one of the many build systems available that you like better. FAKE is the F# world’s first-class tool; I just haven’t bothered to learn it.

2. .NET Core: Yes, awful for F# today, but if there were any justice in the world, it would still be called a beta platform, even for C#. I think this is going to be yet another of those Microsoft products that doesn’t become widely usable in production environments until 3.0 ships. Meanwhile, expect to be a pioneer; you can tell them by all the arrows sticking out of their backs.

3. .NET: *What* project management in .NET? It’s just a library and runtime. Do you mean MSBuild? I can understand not liking MSBuild XML files, but they’re not meant to be hand-written. If you want a hand-written “project file”, I again recommend Makefiles. There’s a reason Makefiles are still in use ~40 years after the tool was first shipped.

> I tried Xamarin

I don’t think it’s a good idea to start new projects with Xamarin Studio today. My reading of the tea leaves is that it’s going to merge into Visual Studio on Windows.

The current “Visual Studio for Mac” is an updated version of the old Xamarin Studio, and that *is* a good choice going forward. It will generate and consume the same MSBuild files that Visual Studio for Windows does.

Maybe we’ll get a similar “Visual Studio for Linux” at some point. Until then, you can run msbuild.exe via Mono on Linux to build using the MSBuild files generated by Visual Studio on the other two platforms. Any decent Linux programmer’s text editor can be taught how to run an external build tool and interpret its error messages.

> Atom, VSCode

Some people like to layer these with Ionide + Fake + Paket and such. If that’s the toolchain you’re not happy with, I get that. It feels rather messy to me as well.

For some reason, Vim + gmake + Paket feels less messy, but maybe that’s just my generation showing.

> VS2015

VS2017’s been out for months now. :)

> is limited to the windows environment.

Not unless you consider “Visual Studio for Mac” to not be “Visual Studio.” It’s arguable, since it’s not the same code base, but at the project level, they’re compatible, so I don’t see why the differences would affect this thread.

> NetCore looked like the light on the horizon with a 'normal' json project file, and then they abandoned this in favor of really ugly and unreadable xml format ;-(

project.json was *too* simple. You couldn’t do very basic things with it easily, and some of the things it could do only worked if you structured your project *just so*. Way, way too much effin’ magic, IMHO. Good riddance.

This is one of the many reasons I wished Microsoft had called .NET Core 1.0 “.NET Core Developer Preview 1”. 1.1 is DP 2 in my view, and 2.0 will be DP 3.

About a year from now, I expect to have the feature-complete stable version that I’d be willing to call .NET Core 1.0, and it’ll probably actually be called .NET Core 3.0.

> Using the node environment this seems a no brainer, one json project file.

One key difference with Node is that you don’t have to compile anything. Sure, there are transpilers and minifiers and such, but you don’t *have* to do any of that stuff, so that what goes into “run project” amounts to “start node with main.js”.

Statically-compiled languages require that you think about things like dependencies, build order, linkage, executable deployment, etc. It’s always going to be more involved. If you want a fair comparison, compare F# to Haskell or OCaml, not to JavaScript.

Here’s a simple, readable F# Makefile, intended for use with GNU make on macOS and Linux, or under Cygwin on Windows:


#### Directories
BINDIR = bin/Release
PRGNAME = program
PROGRAM = $(BINDIR)/$(PRGNAME).exe
DISTDIR = $(PRGNAME)-$(shell $(PROGRAM) --version)


#### Tools
FSC = fsharpc


#### PROGRAM sources in *dependency* order, leaves first
SOURCES = \
src/helper.fs \
src/main.fs


#### Top-level build rules

all: $(PROGRAM)

clean:
rm -rf bin obj


#### File-level build rules

$(BINDIR):
mkdir -p $@

$(PROGRAM): $(BINDIR) $(SOURCES)
$(FSC) -o $(PROGRAM) $(SOURCES)

[Daniel Beer]

On Mon, Jul 31, 2017 at 10:57:17AM -0600, Warren Young wrote:
> $(BINDIR):
> mkdir -p $@
>
> $(PROGRAM): $(BINDIR) $(SOURCES)
> $(FSC) -o $(PROGRAM) $(SOURCES)

One slight quirk with rules like this is that when you create $(PROGRAM)
for the first time, you will alter the timestamp on $(BINDIR), and a
second run of "make" will think that $(PROGRAM) needs to be rebuilt.

It's a little bit ugly, but I normally work around this with something
like:

$(BINDIR)/.dummy:
mkdir -p $(BINDIR)
touch $(BINDIR)/.dummy

$(PROGRAM): $(BINDIR)/.dummy $(SOURCES)
$(FSC) -o $(PROGRAM) $(SOURCES)

Otherwise, I agree with the recommendation to use make. Maybe I'm
missing something, but I don't really understand the motivation for
language-specific build tools in the first place. Every non-trivial
project I've worked on has used multiple languages anyway.

Cheers,
Daniel

--
Daniel Beer <dlb...@gmail.com> http://dlbeer.co.nz/
PGP: BA6E 0B26 1F89 246C E3F3 C910 1E58 C43A 160A 553B

[Casper Bollen]

Thanks for the elaborate reply. I admit I was, purposely, a bit provocative. But I think that what this thread was all about, explore reasons not to use F#. Also, my complaints are indeed focused on a specific use case, where I aim to develop in an environment agnostic way.

On Monday, July 31, 2017 at 6:57:24 PM UTC+2, Warren Young wrote:

On Jul 29, 2017, at 2:07 AM, Casper Bollen <hal...@gmail.com> wrote:
>
> I hate the tooling and project management.

I wish people wouldn’t blame F# for individual IDE/editor shortcomings.

If you don’t like how Xamarin, VSCode, or Atom manage F# projects, blame the editor or IDE, don’t blame F#.

F# cannot be blamed, I agree. I really like the F# language, but as every language, you need the tooling. 

> When developing javascript, Elm, purescript project management is so much easier

Of those three, I only use JavaScript, and my reaction to that is *what* JavaScript project management?  Unlike with F#, there are no canonical tools for it, other than the browsers, and the browsers don’t have project management.

It sounds like you’re comparing My Favorite Text Editor to all of the F# tools.  If so, be clear about it.

Personally, my “JavaScript project management” is a Makefile, and that only because I need something to drive the validation, merging, and minification process, which I hand-built back in the days before we had all-in-one tools that do that.

The current F# tool alternatives are a bit of a mess at the moment, as we’re at a point of transition, what with the Xamarin buyout, the .NET Core transition, etc.  But, I still think the JavaScript world is in a far messier state:

   https://hackernoon.com/how-it-feels-to-learn-javascript-in-2016-d3a717dd577f

Maybe, I should have omitted javascript. You should take a look at Elm and Purescript. 

> mono, netcore, .net, all awful

Let’s take those in order:

1. Mono: “awful” why?  Be specific.  Personally, this is my first choice when it comes to cross-platform development.  Just write a Makefile and you’re done.  If you don’t like GNU make, pick one of the many build systems available that you like better.  FAKE is the F# world’s first-class tool; I just haven’t bothered to learn it.

2. .NET Core: Yes, awful for F# today, but if there were any justice in the world, it would still be called a beta platform, even for C#.  I think this is going to be yet another of those Microsoft products that doesn’t become widely usable in production environments until 3.0 ships.  Meanwhile, expect to be a pioneer; you can tell them by all the arrows sticking out of their backs.

3. .NET: *What* project management in .NET?  It’s just a library and runtime. Do you mean MSBuild?  I can understand not liking MSBuild XML files, but they’re not meant to be hand-written.  If you want a hand-written “project file”, I again recommend Makefiles.  There’s a reason Makefiles are still in use ~40 years after the tool was first shipped.

Ok, I was not clear on this. I didn't meant the mono, netcore, .net runtimes or libraries. Indeed it was the project management and the ability to have a local specific runtime and SDK. That would enable setting up or deploying to environments without any prior prerequisites other than it should be windows, osx or linux. I think Fake 5 is going into that direction. And for project management indeed the setup like you use with a Makefile. I think every prerequisite to start installing specific runtimes, SDK's, etc.. is both a vulnerability and an obstacle to easily start developing and deploying your applications (when the os doesn't matter). 

> I tried Xamarin

I don’t think it’s a good idea to start new projects with Xamarin Studio today.  My reading of the tea leaves is that it’s going to merge into Visual Studio on Windows.

The current “Visual Studio for Mac” is an updated version of the old Xamarin Studio, and that *is* a good choice going forward.  It will generate and consume the same MSBuild files that Visual Studio for Windows does.

Maybe we’ll get a similar “Visual Studio for Linux” at some point.  Until then, you can run msbuild.exe via Mono on Linux to build using the MSBuild files generated by Visual Studio on the other two platforms.  Any decent Linux programmer’s text editor can be taught how to run an external build tool and interpret its error messages.

 

I don't know if it's a good idea to couple project management and code editing into a single tool whereby you lose control over the project management part. I much prefer a CLI for project management. 

> Atom, VSCode

Some people like to layer these with Ionide + Fake + Paket and such.  If that’s the toolchain you’re not happy with, I get that.  It feels rather messy to me as well.

For some reason, Vim + gmake + Paket feels less messy, but maybe that’s just my generation showing.

Agree, but gmake and Vim requires specific knowledge. And I think these are quite specific Unix tools. But I think that there should be a clear separation between code editing, project management and building the project.  

> VS2015

VS2017’s been out for months now. :)

> is limited to the windows environment.

Not unless you consider “Visual Studio for Mac” to not be “Visual Studio.”  It’s arguable, since it’s not the same code base, but at the project level, they’re compatible, so I don’t see why the differences would affect this thread.

> NetCore looked like the light on the horizon with a 'normal' json project file, and then they abandoned this in favor of really ugly and unreadable xml format ;-(

project.json was *too* simple.  You couldn’t do very basic things with it easily, and some of the things it could do only worked if you structured your project *just so*.  Way, way too much effin’ magic, IMHO.  Good riddance.

This is one of the many reasons I wished Microsoft had called .NET Core 1.0 “.NET Core Developer Preview 1”.  1.1 is DP 2 in my view, and 2.0 will be DP 3.

About a year from now, I expect to have the feature-complete stable version that I’d be willing to call .NET Core 1.0, and it’ll probably actually be called .NET Core 3.0.

It seems I have to be patient. 

> Using the node environment this seems a no brainer, one json project file.

One key difference with Node is that you don’t have to compile anything.  Sure, there are transpilers and minifiers and such, but you don’t *have* to do any of that stuff, so that what goes into “run project” amounts to “start node with main.js”.

Statically-compiled languages require that you think about things like dependencies, build order, linkage, executable deployment, etc.  It’s always going to be more involved.  If you want a fair comparison, compare F# to Haskell or OCaml, not to JavaScript.

Here’s a simple, readable F# Makefile, intended for use with GNU make on macOS and Linux, or under Cygwin on Windows:

Hmm, doesn't look that 'simple' to me, having no Make knowledge what's so ever. Also, and what is the difference between the 'node runtime' and for example the 'mono environment'? If you look at purescript and Elm, these are both statically typed languages.