Open lambdakris opened 8 years ago
I think your vision for the experience is spot-on. Thanks for the input! (and for the idea in the first place!)
I'm taking your ideas and running with them :)
Each experience should be no more than 10-15 from start to end!
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,
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.
I like that list!
I think fs
may be already associated with filesystem tools, so why not use fsharp
itself?
Thanks!
@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.
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
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.
@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
btw @swlaschin maybe i am moving discussion too much in the dotnet cli side. I think we should create more issues
we can use packet to download deps, and use packet refs or file system path as reference or nuget ( depends on tool ).
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 :)
no plugin model, it's like git, dotnet compile
call dotnet-compile.exe
the idea is not switch c# f#, it's have:
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:
minimal (xplat):
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
For full mono fsc, windows fsc you install different mono or windows fsc binaries, and run fsc.
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
* 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
Rough User Instructions & Experience Description
Install the F# Experience
npm i -g fs
Create your first app with the F# Experience (approximation)
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!