bad advertising for F#: making projects contained in FSharp top level namespace?

[Gauthier Segay]

Hello,

It's often we see F# projects reaching significant quality or critical
mass landing under github.com/fsprojects organization.

I noticed that many of those projects used FSharp as the top level
namespace, which I think is a bad idea for advertising of the language
or the library (or catering the project to wider .net audience who in
general can consume it).

Concerns related to doing so:
* increase of probability to see FSharp on many lines in stacktraces
* projects get lower adoption rate from .net community
* confusion between F# and libraries

I know many projects have this namespace for historical reason, but I
recently saw this new project added (which is a great thing on it's
own):

https://github.com/fsprojects/FSharp.AWS.DynamoDB

I'm sure even if projects are mostly F# centric, they can still
benefit the .net community to some extent, and that can tend to grow
if people using the library from other language contributes issues to
the project.

I think the community should make an effort (albeit breaking change)
toward fixing those namespaces / assembly names whenever there is
opportunity (release of next major version of library?), and maybe the
recommendation to not use FSharp in naming will be more effective if
we see mature projects fix that issue.


Sorry to bring a difficult topic.

[Steffen Forkmann]

Hi,

we already did that for things like ProjectScaffold.
Maybe FSharp.Formatting is another candidate, but I don't think it needs to be done everywhere.

Anyways there is a guideline: https://fsharp.github.io/2014/09/19/fsharp-libraries.html

Cheers,
Steffen

-----Ursprüngliche Nachricht-----
Von: fsharp-o...@googlegroups.com [mailto:fsharp-o...@googlegroups.com] Im Auftrag von Gauthier Segay
Gesendet: Donnerstag, 17. März 2016 06:45
An: fsharp-o...@googlegroups.com
Betreff: bad advertising for F#: making projects contained in FSharp top level namespace?([Spam-Wahrscheinlichkeit=52])

--
--
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.

[Isaac Abraham]

Where it's a library designed specifically for F# (typically wrapping an already-existing .NET library) e.g. the AWS library you refer to, the two Azure ones, type providers etc. I see no probably having FSharp at the top level. The only alternative might (should?) be would be to piggy-back on the namespace of the wrapped library e.g. Microsoft.WindowsAzure.Storage.TypeProvider instead of FSharp.Azure.TypeProvider etc. etc.

For non-FSharp specific libs that happen to be written In F# I agree that there's no specific need to put FSharp at the start.

[Don Syme]

Hi all,

For this topic I'd encourage everyone to read and contribute to the guidelines Steffen linked to: https://fsharp.github.io/2014/09/19/fsharp-libraries.html . If there's a library-design topic that's not covered then please raise an issue in that repo or send a PR.

There are many, many cases where F#-facing libraries can give a lot of extra value, DynamoDB and other data access technologies are great examples of such a case. In the case of FSharp.AWS.DynamoDB, the library is definitely an F#-facing library - it is not particularly designed for use from C#.

One thing to note is that when adding technologies A and B often there is a choice between which technology comes first, e.g.

FSharp.AWS.DynamoDB or
AWS.DynamoDB.FSharp

Likewise

FSharp.Deployment.Topshelf
Topshelf.FSharp

Using the latter formulation can be great as it helps spread F# support into other communities. However in the case of FSharp.AWS.DynamoDB it may be tricky given the need to use the "AWS" top-level namespace.

Cheers
Don

[Andrew Cherry]

I thought i'd briefly chip in here, just as someone who's chosen to the do the opposite and not adopt an FSharp.* namespace for any projects. My concern around people doing so widely is that it could potentially have the side-effect of stifling competition/emergence of better alternatives. As a hypothetical, if I created a new optics library and called it FSharp.Optics, i've not taken that concept in a fairly major way. Nothing is likely to look quite as official as FSharp.Optics and the only way to release a "competitor" in the marketplace of ideas will be to name it something entirely unrelated, and suffer any perceived penalty of being "less official" or "less supported" (although neither of those things would be true, the perception is likely).

If someone came along now and wrote a *better* implementation of Dynamo DB bindings for F#, I think it would now be less likely to be adopted, despite potentially being an objective improvement.

There's an interesting community point about whether we want to be a community that replaces the built in and default with better as we learn how to, or whether we want to be a community with a growing "stable core". Of course, there's pros and cons either way... 

[Gauthier Segay]

Thanks all for sharing your thoughts and reference to the
comprehensive guideline.

One thing which lays in my mind though is that I haven't encountered
much this redundancy in library names containing implementation
language name in other environments. This seems kind of redundant
(when the library is meant for F# consumption only) or doesn't help
adoption (when library is for wider .NET space consumption).

[Isaac Abraham]

Yes, good point.

 

I think having a common story for doing many use cases is a good thing – but obviously not at the expense of variety and “competition” which can drive improvement etc..

 

A good example here might be F# SQL data access – there are two popular TPs for SQL, both with different approaches. There’s one-size-fits-all, although I generally use one of those two for projects I work on, and having the diversity helps.

 

But it’s important IMHO that there’s a good set of stories that are easily accessible and give confidence and security in using a particular package. The FSharp namespace does help does with that, but you’re right, it shouldn’t be at the expense of another package that uses a different namespace (or the package shouldn’t be too high up the namespace chain to preclude the possibility of other packages).