-
Notifications
You must be signed in to change notification settings - Fork 1
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Happy path for newcomers (beginners and immigrants) #6
Comments
I think your vision for the experience is spot-on. Thanks for the input! (and for the idea in the first place!) Experience goalsI'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, InstallerIt 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.
What to include
CommandsI like that list! I think Thanks! |
@swlaschin What do you think about what @enricosada details in dotnet/fsharp#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 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. what we need i think is the same as The user stories @swlaschin wrote are good, I'll help writing if possibile these with the |
I like the idea of dotnet-cli, but I'm worried that it will be heavily C# focused. The |
@swlaschin the dotnet cli is not really focused on csharp, is cross language. i am atm discussing about default of The worst case is having to do And btw, |
btw @swlaschin maybe i am moving discussion too much in the dotnet cli side. Program types ( who care about tools, it's fsc all the way down )
Tooling options (who care about the problem, it's source files and fsc arguments all the way down):
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, the idea is not switch c# f#, it's have:
csharp and fsharp are really similar (i speak about tooling) . 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. 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: coreclrminimal (xplat):
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 or you can install coreclr with http://dotnet.github.io/docs/getting-started/installing/installing-core-windows.html full mono/visualfsharpFor 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!
The text was updated successfully, but these errors were encountered: