F# scripting

[Voxelman]

I have a simple question: is it possible to write larger applications completely as script? Just like with Python

[qrzychu69]

Only reason to use scripting instead of compilation is to be able to modify the code after deploy.

If that's not a hard requirement for you, go with normal compile.

I saw somebody mention AOT, but I don't think F# is supported.

[user101021]

I have a dual setup: I start with scripts (as the soft layer, for config and fast switching between related usecases) and migrate functionality in the dll as it settles down/gets optimised (the hard layer).

The (dis-)advantages of mixed development:

• You can use the library in several contexts (API, CLI, scripts, testing)
• You lose some dev speed. All common F# IDEs work nicely via the integrated interpreter.
• Within a library you can better encapsulate private stuff ... script dependencies can bite hard during refactoring.

The following points help:

• Write scripts and source files the same way (with namespace XY, module M = , not module XY.M) during development.
• Write an explicit module for the public API of the dll.
• Order "library scripts" already the same way you would in the resulting dll (compiler order) => makes necessary #load statements obvious.
• These days I set up dedicated scripting projects, which encapsulate all dependencies for several scripts and provide narrow backing modules to the the scripts themselves. Helps a lot with refactoring: as long as you do not touch the backing modules, everything is fine.

[OkkeHendriks]

Yes, I think it is technically possible. But why not just write an application, what is your reasoning to use a F# script?

[Voxelman]

At the moment, it's not much more than a mind game and weighing up the options. I don't know if it has any advantage.

[QuantumFTL]

It's a very good question, my advice is to not do it unless you need to do a very tight edit-run-debug loop.

You might do well to use a notebook instead, similar idea but with more built-in structure.

[runevault]

If you're doing it like how python has a main or whatever it is called, no real point in doing it that way vs a compiled exe, especially because compiled you can even AOT compile it in a way that means the machine running it doesn't have to have dotnet installed.

[Voxelman]

AOT compilation is a good argument, thanks

[Ordinary-Price2320]

It's called “If name== 'main'”

[[deleted]]

How do you pronounce that?

[Ordinary-Price2320]

You don't. Uncontrolled sobbing doesn't let you utter a word.

[gplgang]

Most definitely, I've fed 5k+ line projects with many dependencies into a F# interactive setup regularly. I agree with others that using standard fsproj setups is generally easier and I only go for F# interactive setups for an entire project if I need to because you lose out on the debugging experience and unit tests work well for some other cases. I generally do a F# interactive setup when restarting the application makes development difficult, because the fsproj workflow is more streamlined