Happy path for newcomers (beginners and immigrants)

[lambdakris]

What do you think about creating an node.js package (could be written in FunScript) called fs or fse (for F# Experience...oooohhh), with (roughly) the following capabilities.

Rough Package Description

Installation

1. parallel downloads
   • conditional download mono
   • conditional download gtk#
   • conditional download atom.io
2. conditional install mono
3. conditional install gtk#
4. conditional install atom.io
5. conditional install yeoman
6. conditional install generator-fsharp
7. conditional install ionide

* I'm putting Mono forward because I think it makes things more straightforward. My concern is not so much for a package developer (what's another couple of if statements), rather I believe that even when creating a tool that automates a process for a user, a tech user typically values simplicity and transparency. Using Mono would remove a good degree of conceptual overhead that would not exist on one of the other trending platforms/stacks. When the time is right, Mono can be replace with CoreCLR.

Commands

• fs about
  • Lists all installation locations, versions, etc.
• fs upgrade --exclude --include
  • Upgrades itself, meaning the installed system dependencies, giving the user the option to include or exclude particular dependencies
• fs downgrade --exclude --include
  • Downgrades itself, meaning the installed system dependencies, giving the user the option to include or exclude particular dependencies
• fs new --type --path --name
  • Creates and scaffolds a new project according to type which might include console, service, browser {signalr/suave/freya,etc.}, mobile {xamarin/onsen/cordova}, or something along those lines
• fs init --type --path
  • Creates and scaffolds a new project in an existing directory according to type which might include console, service, browser {signalr/suave/freya,etc.}, mobile {xamarin/onsen/cordova}, or something along those lines
• fs open --path
  • Opens the project in Atom.io
• fs test --watch
  • Runs tests...somehow
• fs dist --path
  • Builds and deploys the artifacts to some path using FAKE, including (if it can be managed) cloud endpoints.
• fs install --package
  • Installs application packages using Paket
• fs update --package
  • Updates application packages using Paket
• fs uninstall --package
  • Uninstalls application packages using Paket

    Rough User Instructions & Experience Description

    Install the F# Experience

    1. download the node.js installer from nodejs.org
    2. go to your download directory and run the node.js installer
    3. open a command line and run npm i -g fs

       Create your first app with the F# Experience (approximation)

    4. open a command line and run the following commands
    5. fs new suave MyApp
    6. cd MyApp
    7. fs install mbrace
    8. fs open --path MyApp
    9. ...atom.io launches...write code...tab back to command line
    10. fs dist azure servicefabric MyApp

        Rationale

Focusing on this narrow path first is a means of discovering or approximating the ideal UX. Once we feel a UX that promotes flow and imposes as little ritual and conceptual overhead as is practical has been attained. We can begin working on trying to align or complement the IDE and other editor scenarios as best as possible.

Caveats

Is npm the right installer/package manager for this? I'm honestly not sure how far we can get with npm in regards to installing system applications or even if we can publish an npm package to the official registry that essentially has nothing to do with Node.js or JavaScript. Perhaps 0installer might be better (although it has way less market/mindshare and it is unclear what system dependencies/prerequisites it has that might make it's installation an ordeal in itself). Or perhaps we should wait or start munging with dotnet-cli/CoreCLR instead? That also brings up the point of CoreCLR in it's prerelease stage instead of Mono, or even if we do want to introduce the decision tree of .NET and Windows SDK if on Windows or Mono if on Nix...

Please be forthcoming with your thoughts, questions, and expertise!

[swlaschin]

I think your vision for the experience is spot-on. Thanks for the input! (and for the idea in the first place!)

Experience goals

I'm taking your ideas and running with them :)

Each experience should be no more than 10-15 from start to end!

• The Web experience:
  • get a "hello world" website running locally in minutes
  • make a tweak and see the changes
  • deploy the same website to Azure painlessly
• The Big Data experience:
  • have a hard problem with map/reduce (steal an example from hadoop?).
  • run on local machine and see it take 10 minutes say.
  • deploy to Azure and see mbrace handle this painlessly in 30 seconds, say.
• The Desktop experience
  • get a "hello world" desktop app running locally in minutes
  • get a game running on desktop in minutes (to show that F# is fun, not boring)
• The Javascript experience
  • Convert the desktop game into a JS game using FunScript
  • Run locally using Suave
• The SQL Database experience
  • Run script to create a simple database on MySql, Postgres, SqlServer
  • Use type provider to make a query
  • Run web site locally that accesses the database
• The NoSql experience
  • Run script to set up MongoDb or similar
  • Use type provider as for the SQL version to access data
  • Run web site locally that accesses the database

Each of these experiences is made available as a well-commented pre-canned project with source that just works. There are some slots where you can change things, but not too much. This is what you use the first few times.

When you want to move on to the next step, there is a corresponding template project that you can tweak in more detail,

Installer

It would be great if there were no dependencies that have to be installed, so that puts me off using node.js.

Instead, I suggest using python for Mac/Linux and powershell for Windows, which are both preinstalled.

Alternatively, having a single installer might be the way.

• For Mac/Linux, 0install looks good, and it keeps things isolated, which is nice. AFAIK there are no dependencies at all. (Btw, the developer of 0install converted it from Python to OCaml and documented his journey in a fascinating series of posts ).
• And for Windows, InnoSetup or similar. (or 0install again)

What to include

• for non-Windows platforms:
  • Mono - yes, until CoreCLR is stable
  • Gtk# - yes, does this come with Mono?
• for Windows
  • .NET 4.5 needed
• don't forget F# itself!
• Maybe also Eto which is a .NET xplat forms library that works with both Gtk and WinForms
• yeoman - again I personally don't like depending on another language and having to install lots of other things just to do something simple :( I run into this with Ruby all the time! I remember when Logstash was delivered as a JAR file even though it was written in Ruby -- that made me happy! Anyway -- end of rant! -- for what we need, couldn't we write something simple -- we don't need a generic template manager. Also, we want to work with FAKE and paket rather than gulp and grunt. We already have Project Scaffold which needs a bit of tweaking for this purpose but is almost there.
• atom/ionide - yes. It might be nice to have other versions for VSCode and Vim, say. But start off with one editor only until the workflow is good.

Commands

I like that list!

I think fs may be already associated with filesystem tools, so why not use fsharp itself?

Thanks!

[lambdakris]

@swlaschin What do you think about what @enricosada details in https://github.com/Microsoft/visualfsharp/issues/834? Beyond getting dotnet-cli to support F#, I wonder how much work it would it take to get things like Ionide, fsharp-generator, and ProjectScaffold to work with dotnet-cli. A benefit of having an fsharp specific CLI is that it could wrap a pre-dotnet-cli shim with mono/net4.5 and later be an (opinionated) wrapper for dotnet-cli.

[enricosada]

no node pls, it's really a problem. OOTB should be native (pkg, etc) i have used ruby for rake+albacore build, was really nice and works better than nuget with bundler ~= packet, so repeteable builds after 5 years ). But ruby dependency ( like node ) seems an hack. but i really like ruby as build script.

I really support yeoman or tools like that for scaffold, or minify, etc, something i call in my build script to do things. If that require dependencies, ok.

But compilation experience should be the real thing, otherwise is a lie and not usefull to new people. It's better improve current tools we use to make things ( like @forki did with packet )

what we need i think is the same as dotnet cli. There is alot shared there and working xplat now, supported too. Previous attempt at this, was the fantastic works by @Alxander with github.com/fsprojects/fsharp-dnx/ but that's stopped because aspnet/dnx evolved in dotnet/cli

The user stories @swlaschin wrote are good, I'll help writing if possibile these with the dotnet cli, project.json etc ( the fsharp code is the same, i can use the WriteToDb.fs source ), because i think is a really good opportunity for f#. But we should provide examples with fake and msbuild too, because that' the current situation

[swlaschin]

I like the idea of dotnet-cli, but I'm worried that it will be heavily C# focused. The fs or fsharp cli tool discussed above would be the same kind of thing, but designed for F# integration specifically. I think that the "UI" (the cli options) should be compatible with dotnet-cli though, so that switching would be easy.

[enricosada]

@swlaschin the dotnet cli is not really focused on csharp, is cross language. Sometimes the default are csharp, but it's only a matter of add --lang=F# then needed. for compilation, that mean dotnet compile or dotnet run or dotnet pack is not a problem because compilerName a property is inside project.json. So from command line is the same

i am atm discussing about default of dotnet new in https://github.com/dotnet/cli/issues/647#issuecomment-167113853

The worst case is having to do dotnet new --lang=f#, it's not a real problem, a nice to have.

And btw, dotnet new is a basic scaffold It's possibile to use yeoman to create project.json ( yeoman should execute dotnet new and add files or create directly the project.json) After project is in place, experience is the same

[enricosada]

btw @swlaschin maybe i am moving discussion too much in the dotnet cli side. I think we should create more issues

Program types ( who care about tools, it's fsc all the way down )

• web story, suova/owin/aspnetvnext
• console, printfn is your friend, Argu for command line arguments
• native ui, xamaring forms/ecto/FsXaml

Tooling options (who care about the problem, it's source files and fsc arguments all the way down):

• bare fsc, call fsc with arguments
• msbuild, msbuild a fsproject file
• fake,
• dotnet cli

we can use packet to download deps, and use packet refs or file system path as reference or nuget ( depends on tool ).

[swlaschin]

I understand that dotnet-cli is cross language, but I'm not convinced that that makes for a good UX.

I think that tools should be designed from the users point of view, which means making it really easy to solve the specific goals that they have, and that in turn is easier if tools are designed specifically for an environment. How many users have a goal of switching between C# , F# and VB regularly? I'd rather have a tool for each language.

Also, I personally prefer to have as few dependencies as possible, especially if you want full control of the OOBE. So obviously fsc/fsi and mono/coleclr are core dependencies, but I would be happier if nothing else was!

But I don't see why there can't be two parallel systems? If the dotnet-cli system uses a plugin model, then any code can be shared, surely? If nothing else, we can move fast, and then integrate later once we understand the requirements better :)

[enricosada]

no plugin model, it's like git, dotnet compile call dotnet-compile.exe

the idea is not switch c# f#, it's have:

• a single coreclr package easy to install to setup coreclr environment and corerun ready to work
• a good project system ( project.json instead of fsproj, csproj )
• a way to restore dependecines from nuget or other project ( download and build )
• some utility commands. dotnet compile can be really fsc.exe + arguments, same for csc.

csharp and fsharp are really similar (i speak about tooling) . csc and fsc arguments are pretty much the same, each one require .dll ( from core libraries or nuget or local path ), output to cil, etc. Problem is, previous csharp tooling has lots of problems ( msbuild, nuget ), and more in ides because msbuild rules. It not easy to work with outsite windows, and also in windows has problems. I think dotnet cli and project.json fix lot of problem, but that's my feedback.

I think in parallel is a good idea, i'd like to mantain the dotnet cli examples if you want do it, paralllel ok, because it's going to be the same source files as the mono/fsc/fsi samples. different command line only. At some point you need to execute fsc with arguments.

I understand that may not be the best tooling, for example http://7sharpnine.com/Xebec/ it may be better than project.json, but project.json is really near to be production ready

There are as you said you ways:

coreclr

minimal (xplat):

• install coreclr.
• download fsc for coreclr
• execute corerun fsc arguments or use fsc.exe

you have xplat compiler ready to work ( no type providers atm, and some other bug, some stuff works )

to install coreclr and fsc easly xplat, you can install dotnet cli, after that you get coreclr, corerun, csc, fsc inside C:\Program Files\dotnet\bin\ as simple exe ( or another path in osx, etc, see .

or you can install coreclr with http://dotnet.github.io/docs/getting-started/installing/installing-core-windows.html

full mono/visualfsharp

For full mono fsc, windows fsc you install different mono or windows fsc binaries, and run fsc.