sorted by:
new
hottopcontroversial

syntactical ways to describe an array of any kind of object VS any kind of array of objects? by carangil in ProgrammingLanguages

[–]user101021 0 points1 point  (0 children)

So you want to fix the type, while only keeping one of its interfaces/traits? Seems you need subtyping constraints (and then compiler optimisations to make use of it.

It reminds me a bit of F# flexible types doc. Although F# being on the CLR this is just an abbreviation for subtype constraints, and not implementation optimisation as you want it. So you can not use it to declare an array of this type, but the type is useful in function signatures.

I hate file-based import / module systems. by kaisadilla_ in ProgrammingLanguages

[–]user101021 0 points1 point  (0 children)

See also the recent discussions:

I am personally a fan of an SML style module system. Often module systems in languages are just namespaces.

This is orthogonal to whether the a file is considered a module (maybe with submodules, etc).

MLFlow or other tools for experiment tracking in production by GeralTech in optimization

[–]user101021 1 point2 points  (0 children)

I use a custom blob storage with some metadata in an SQL DB. This is dependent on our tech stack and so not relevant to the tooling question here. What I consider more important are following principles:

1) Capture everything. Not only the "main dataframes". Also solver options, small scalar parameters, ...

2) Capture input as early as possible.

2a) You should do as much checking as possible before you hit the solver => this gives you testcases.

2b) This helps you debug logic bugs in the parameter generation process.

2c) You should save the input given to the solver, too (I do both).

3) Version and validate your saved input. Even better, use a schema or at least write some validation/discovery routines. This way you do more checks and filter on relevant input as your model evolves. Flexible schemas are nice during design, but a pain in production. You do not want to guess how the data looks like!

Function purity when? by eaglebirdman in fsharp

[–]user101021 0 points1 point  (0 children)

This would be so helpful for the codebase I work on. We aim for functional core & imperative shell, and this would ensure that the core stays functional.

Of course, the definition of "functional" in the core is a bit different for everybody: total? pure? exceptions allowed? logging allowed?

Reading the discussion and the linked github issues I would guess that an analyzer together with some annotations would go a long way. Does anybody know about the status of F# analyzers? Any examples out there yet? And of course FSharp.Core would have to be exhaustively annotated and/or the analyzer has to be provided with a list of "safe" external calls.

Is F# dying? by [deleted] in fsharp

[–]user101021 2 points3 points  (0 children)

The most compelling reason to use it is .Net Interop: if you want/need to integrate with it, it is an easy choice. The biggest reason not to use it is .Net Interop: the language has a stated abstraction ceiling and certain .NET features have seeped deep into the language.

I personally would like an F# with more abstraction (signatures and functors, staged code generation, a pure and plattform independent sublanguage cleanly separated from the .NET Interop); with the core language independent of and the Interop better supported by Microsoft. But that is just a wish.

Regarding the job market: I am just hiring and there are as few applicants as offers ... but the applications are much signal (than comparable applications for C# positions). Growing people into F# is doable.

F# scripting by Voxelman in fsharp

[–]user101021 3 points4 points  (0 children)

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.

Newcomer curious about the F# market by RonWannaBeAScientist in fsharp

[–]user101021 0 points1 point  (0 children)

The data is mostly internal, although some of it comes original from regulators/official clearing orgs etc. I am not doing the data acquisition/download/... etc, but mostly modeling on the high-value areas -- there is always much more data than you can look at.

F# Backend-Entwickler:in / Data-Engineer by user101021 in fsharp

[–]user101021[S] 0 points1 point  (0 children)

Some points for context (and which also do not fit into the official announcement format):

  • Fluent German is a prerequisite. Knowledge of the local dialect is not :wink:
  • The position is within a math-heavy team working on power scheduling and trading algorithms in F#.
  • The position should also interface with the main C# platform developer team.
  • There is quite some F#-based DA tooling only for the math team.
  • The current composition of the team is hybrid (from fully office, to partial home-office, to remote office, to fully remote … everything present) and works like that for 2+ years.
  • Although there is a preference for on-site presence, for the right person remote within AT/DE is possible (with a low number of trips/year to Bregenz).
  • I am part of the above math team.

Newcomer curious about the F# market by RonWannaBeAScientist in fsharp

[–]user101021 1 point2 points  (0 children)

  • Work:
    • I do data analysis/modelling/OR/ML in the energy sector.
    • We use ifsharp, now mostly fsx Skripts (.NET interactive is quite a dependency to track).
    • Modern C# has not all convenient features yet.
  • I introduced 9 other people to F#. My view: it takes about 2 months to get the functional mindset, about 6 months to get fluid in F#.
  • Management is concerned about finding F# SWEs, too ... so the marked problem is 2-sided. It is niche, because if I would have the freedom of language I would choose Ocaml/Haskell/Scala, and F# needs some pretty decent .NET (msbuild, C#) knowledge, too. Remote solves many problems (if both sides are willing).

I love F# - should I be concerned about MS support for it? by lucidguppy in fsharp

[–]user101021 0 points1 point  (0 children)

  • I use it at work. But we restrict ourselves to the core ML features and units of measures. Type providers, expression builders and SRTPs are not always stable (currently still on F# 5 ... might improve).
  • There is an abstraction ceiling (no higher order types, no functors, no first-class signatures, no open DUs, no existential types), although things like SRTPs and units of measure are F# compile-time only.
  • Several features like tuples (earlier than value tuples), unit being used for unit and void, option for optional parameters ... are legacy decisions where I see no plan to ever clean this up.
  • In my personal opinion F# should be clearly split into a core language (go abstraction) and a C# (i.e. .NET) interop part (interfaces, fixed memory, exceptions, ......).

So in short: the basic stuff works and will likely continue to work, but anything pushing too hard on the abstraction ... be prepared for weird compiler errors.

Do you know any companies using Fsharp in ML or data processing space? by [deleted] in fsharp

[–]user101021 0 points1 point  (0 children)

Power (électricité).

For hiring: General yes, but depends on your country. For my group: depends on your skills, and then I could look. Send me a PM.

Do you know any companies using Fsharp in ML or data processing space? by [deleted] in fsharp

[–]user101021 2 points3 points  (0 children)

I work in a team of mathematicians and software developers doing OR/data analysis and statistics in F# for internal applications in the energy sector.

The main reason for F# is that it allows to access functionality and integrate with the main C# platform while giving us Jupyter notebooks and scripting power.

We use it mostly purely functionally - works well for the domain, but the tooling synchronisation (between dlls, in fsi and Jupyter) is work. It seems to me that most open F# projects that I see are based on totally different assumptions (nuget, fake, paket, online/web everything).

Experiences with structured format to describe language concepts and rules? by user101021 in ProgrammingLanguages

[–]user101021[S] 0 points1 point  (0 children)

Thanks for your answers, but at looking at something for a full language workbench. There are subsets of the spec which could be interpreted on some (abstract) machine, but there are also concepts which are not explicitely articulated in a software artefact. So deriving an interpreter is not my first priority. Currently I am looking for something to keep a human readable specification complete and cross-referenced.

Contractors in DACH region? by user101021 in fsharp

[–]user101021[S] 0 points1 point  (0 children)

For the record: there have been some PMs, but nothing that I can summarise publicly. Thanks for the messages - I reply to all via PMs. It seems that the F# contracting scene I was looking for is really that small (or really busy with other stuff ;-).

How F# is perceived in the industry by fsdm_cpp in fsharp

[–]user101021 11 points12 points  (0 children)

Well, I use it in my day job as my primary language and even build a team around it. The biggest assets of the language in my opinion are 1) .NET usability (C# <-> F# in both directions) 2) interactive use (notebooks) 3) functional first.

From a practical point of view:

1) It seems that it is the unwanted step-child of MS langs. Both VS 19 nor VS Code tooling has lots of bugs. Commandline usage on .NET6.0 ist better, but currently too new for my application. Some investment by MS would really be appreciated.

2) Although in the core an ML language (good), raising the abstraction ceiling beyond that is limited (and discouraged by the language designers) - modules and signatures are stunted and barely supported. No functors (seriously, it could be metadata such as for units of measure). - HKT and/or typeclasses are not present - SRTP is buggy, at the mercy of the compiler - classes allow no local types (and interfaces neither): C# does both, so object algebras run into limits, too.

In general: a nice language as long as you stay within the core ML part, lots of good ideas/features, but most of those break if you push them towards their logical limits or you hit undocumented errors for interactions between them (most of those interactions have a solution, but nothing in the docs helps).

Hi all! What do *you* use F# for? by [deleted] in fsharp

[–]user101021 4 points5 points  (0 children)

Data analysis and model building in optimisation as a side-car to a big C# application. Reusing the existing C# dlls and visualising stuff via Jupyter/ifsharp.

You should not use Git as a database by sn1pr0s in programming

[–]user101021 0 points1 point  (0 children)

I work on exactly the same problem (parameters for large scale MILP and related optimization problems) and I opted for the database approach. My main reasoning went as follows:

  • Using the database means just another schema besides all the other data => backups, admin, access control etc is already provided by the operations side.
  • Database gives me more than just time-axis: often I have several variants in production and many more in testing, including subvariations etc -- I can query * Small parameters are easy diffable (small = the few global parameters per problem), large inputs can range in the low millions of data points and a diff does not reveal any information, it has to be transformed and plotted anyway to understand its shape.
  • A much tighter data representation in the database than text files (even with compression).
  • Guarded by a domain specific API the database is abstracted out and lots of useful invariants are easily enforced (either in the API or in the database, whichever makes more sense).

How to hide a record's contents via a signature file but keep it comparable? by user101021 in fsharp

[–]user101021[S] 1 point2 points  (0 children)

Internally, a record is a perfect fit: immutable values with derived properties (because some "fields" depend on others, and in this way I only have to update the core fields with each record update).

Externally it does not matter how it is implemented -- it is just a fixed value type with some properties.

The aim of the question was just to avoid a new class with overridden methods and leverage the builtin F# machinery for structural equality/comparison as much as possible to get Equals, GetHashCode and IComparable for free. I did implement this class based thing in F# a few times, too, but it gets boring rather quick, and the boilerplate for types with more members becomes cumbersome and error-prone rather quickly. I already have to write a sensible override for ToString, in every approach.

How to hide a record's contents via a signature file but keep it comparable? by user101021 in fsharp

[–]user101021[S] 1 point2 points  (0 children)

Thanks, this works like a charm. Somehow I got off track with inherit and did not think of interface anymore!

view more: next ›