smoothdeveloper

For GPU, F# has prior art in targeting it, a notable one is https://developer.nvidia.com/blog/jet-gpu-powered-fulfillmen...

I believe it is mostly about intrinsic libraries and developing the code to stick to the idioms of using such libraries; in the context of Clef, maybe the author of this infrastructure is aiming at close interaction between the compiler frontend, a standard GPU programming library and the Clef backend, but I can't really comment on this.

What Clef seems to be doing is: * bringing semantics that are needed for native platform targeting, expressed with idioms familiar to F# developers (through the type system and the lowering during compilation stages, retaining target specific semantics) * making the broad F# programming idioms applicable to such targets (when applicable obviously)

The website contains a lots of detailed articles about aspects of translating F# constructs to the type of environment this compiler targets, but AFAIR, nothing specific to GPU programming.

Clef is a new backend for F# language aiming the language at concurrent systems use cases on native targets.

Are you contributing to FUD? :D

C# can't fix the wrong defaults, still lots more mutable by default, and statement oriented, as an example.

average C# codebase looks different depending language version idioms, not so in F# (because initial release already had >80% of things that C# today doesn't even have and won't be able to fix).

But C# is great too, nonetheless.

Never under-estimates wrong defaults in a language, for example:

C++, const modifier, verbose for more correct code (less mutable state, etc.) Rust, mut modifier, verbose for less correct code

C/C++, bothersome to have tight scopped values, due to split of expression & statement ML languages, nesting of let bound values, everything is tight scoped, even recycling local names non destructively via shadowing.

C#: mostly, all flaws of C/C++/Java F#: mostly all right things of ML, OCaml, Rust

F#: Structural comparison of ML types from day 1 C#: just adding records recently; most of libraries, idioms, and semantics geared towards reference comparison

idioms

C#: mainly OO, noisy syntax, low expressivity (constructing immutable values out of generators or expressions), lots of navigation due to adhoc things needed to be named, poor type inference F#: data & functions, concise end non noisy syntax, high expressivity (list expressions, computation expression values), less scrolling & navigation, object expression rather than defining type used once, great type inference (less noisy diff on refactorings)

etc.

So average F# codebase is by construct, more sound, than average C# codebase, however F# code quality may be poor, and C# great, still, more soundness in F#, IMHO.

You can read this suggestion, and upvote, comment, contribute: https://github.com/fsharp/fslang-suggestions/issues/1434

Just a polling of HN hive mind on this critical matter.

Worst case, let the "tried F# once/for real" ramblers unload their bag once more :)

One way to look at it, but consuming OOP libraries doesn't turn code into OOP.

Also, FSharp.Core (which most F# code leans heavily on) is not OOP at all.

F# promotes object programming, doesn't proscribe mutability, encourages function and data approach.

It offers simple access to the different paradigms, with some opinionated choices (e.g. preventing leaning on OOP beyond an arbitrary stretch, like no "protected", only explicit interface implementation, etc.).

In C#, you can't use the await keyword in a non async method, so I find the argument short sighted.

/!\ this is just my perspective /!\

would love to know why leaving it unbounded was decided upon. Might be I don't quite grok the culture of F#.

You may look at more context in the discussions pertaining to the RFC: https://github.com/fsharp/fslang-design/blob/main/FSharp-4.1...

I think those are the main factors:

* "Keep It Simple Stupid" principle

* community pressure so that F# libraries could standardise on better things that Choice1Of2 = Ok and Choice2Of2 = Error, or using a bare tuple (which is very not clean for APIs)

* F# ought to remain flexible in terms of not pretending of totally abstracting away the fact that most of the dotnet base class library or the overall dotnet ecosystem, uses exceptions, it is not like Result type was created to abstract runtime exceptions away.

For all other needs, one is just one wrapper / or abstraction (for library that don't "meet our standards" in terms of exception safety) away, along with a bit of adhoc tooling around leveraging FSharp.Compiler.Service for sake of adding static analysis, for architecture astronauts, dealing with behemoth or safety critical codebases, requiring even more screws turned, but even there, F# (and so many other languages) may not meet the bar if those are the critical properties for a project involving code.

Overall, F# is just pragmatic for the 99.99%, and not trying too hard beside the steady core language idioms, and how the organic community wants it over time, to satisfy hypothetical and intellectual pursuits of the highest abstraction and safety.

The culture of F# is mostly about throwing productivity parties and being done with it (while not suffering so many of the wrong choices done by C, C++, Java and it's famed sibbling, C#), rather than the higher conceptual type theory perfection that (sometimes ?) lead to code that is not less kludgy, or easier to maintain, in the grand scheme, for the masses of developers, that are not yet expert in Haskell, Scala, etc.

It is probably not too dissimilar to OCaml culture, while embracing some aspects that are familiar to more people, due to relationship with dotnet ecosystem.

In context of adding burden of having someone to translate for you in Japanese, the statement he made seems good enough and to the point.

Maybe you are far too pre-assumtpive that there was any ill effect, or even ill intent, in the statement being made, especially if the same fact is accounted for in gnuplot FAQ.

For people who understand french (or can use translation tool)

this is the only account back in 2019 of the events:

https://www.lemonde.fr/pixels/article/2019/09/17/richard-sta...

It scores much higher to me on journalism than whatever came in US press.

It seems people in US don't value defending free speech, and tend to get offended easily due to taking things only on first degree.

In that frame, they should care more about defending the first amendment of their constitution, and try to get other degree when interpreting words they have negative reaction to.

I don't know how to solve the issue, but I've started trying tackling some of this in context of code of conducts affecting many sofware communities:

https://github.com/ContributorCovenant/contributor_covenant/...

The closest thing is https://github.com/rspeele/Rezoom.SQL which once compiled in your F# project, can be used in C# by referencing the generated assembly.

Although this is nothing to do with string interpolation, the "typed string interpolation" refer to the F# printf format specifiers.

You could also build such tool separately using FSharp.Compiler.Service (possibly using the analyzer infrastructure for ionide: https://github.com/ionide/FSharp.Analyzers.SDK), AFAIU there will be consolidation of this type of tooling relying on FSharp.Compiler.Service in the future to make this integrated to all F# tooling.

Let the place remain tenantless few more months and they will.

https://fsprojects.github.io/Paket/paket-generate-load-scrip... is probably what you need if you enjoy using fsi and easily reference external libraries from script files.

And even more techniques in F# in it's type system and inlining

The reason is probably flowers (cannabis) versus leaves (tobacco)

How can they be considered a hack when they get baked in the BCL in so many places as well, not for interop purpose?

C# definitely will remain the number 1, and FP will remain used in a minority of places, until more people get exposed to it earlier in their cursus.

The advantages are in the idioms, immutability by default, null not being legit value by default, emphasis on correctness, advanced type system etc.

The issue is often that people doing C# won't gain enough FP practice to see where F# brings most advantages, try to use it as a OO language for really short time and ditch it because tooling and concepts are not the same as what they are used to.

I'm confident though that adoption is rising and that few years from now most .net shops will get exposure to some amount of F# code, and that people who have been doing C# for so long will eventually pick up any functional language, which in turn will make F# really appealing to them.

I'm happy C# is supporting constructs such as local functions and some basic pattern matching (although type tests are probably the worst use case of pattern matching as seen in ML languages), but I'm also concerned the language is evolving toward more and more complicated syntax and rules (see all the kinds of scoping rules for variables and switch statement) and so little things geared toward correctness (readonly locals, non nil references?).

C# focuses on alleviating developer pain, but sometimes making the choice of enabling to do the wrong thing more readily.

Have you learned to use it?

Sadly, JetBrains Rider is the sole .NET IDE without F# support.

It's very hard to do it along the way if you aren't familiar with C# either.

Which I keep overlooking with so many years of C#, I'm so sorry about that :(

That being said, looking at the .NET framework documentation and hanging out on fsharp.org's slack might be a good way to make up for what you are missing to get started.

What is needed is new blood among F# users, not coming from C# background and not too snob about F# not having most advanced type system when compared to Haskell or other similar ML languages.

Then, effort on making functionally orientated base libraries (without relying on baking those things in FSharp.Core, but as set of small libraries) wrapping undelrying .NET APIs, taking inspiration from what is there in Haskell and other similar languages.

Most F# users today are fine relying on mostly .NET libraries + fresher F# libraries, but most projects will be done with a mix of paradigms (which is manageable in F#) which is not most appealing to people with significant FP background.

It became easier recently with droping a dependency on libgdiplus.

IIRC you just need to install mono, python, jupyter and ifsharp: https://github.com/fsprojects/IfSharp

All but last one should be on brew, for last one, you should be able to build it out of box with mono installed.

Don't hesitate to report issue on the repository if that fails.

Thing is that putting together short helpers for the "nasty" bits often revolve around 1 line helpers.

You can do so along the way without focusing so much on doing idiomatic FP and achieve both pragmatic and palatable results.

Designing solutions with the type system enabled by F# and it's ability to interop with whole .NET ecosystem is really a powerful combination.

there is also http://try.websharper.com/ for toying with the language and websharper.

I see what you mean.

Really reduced codebase size and features like type provider which increase safety and saves from writing boiler plate code do save on the bottom line, especially in maintenance.

Also, if you are using vanilla C# for math computation, you can save CPU/energy by translating it to F#, it tends to run significantly faster, that also impacts the bottom line in some contexts.

See if testimonials help: http://fsharp.org/testimonials/

As for me, I also use the awareness of manager to the developer needs to be productive, give best ROI and would definitely use that to select a job.

The other thing is footprint of codebase, despite almost 15 years of using C#, after only two years, I consistently write F# which is 1/3 of equivalent C# code, writing idiomatic code that any F# developers would grasp.

There are ways a C# aficionado would take to try to not be so verbose, but those solutions won't be considered idiomatic by 99% of C# developers.

At the end of the day, codebase size matters a lot.

They will still remain generally more painful and more exposed to their issues and choices:

* mutable by default

* OO by default

* null by default

* structural equality a pain to implement

* immutable types a pain to implement

* verbose syntax / failing at the DRY principle

* statement based rather than expression based

* large codebase following those idioms

I don't think they'll not remain popular, but I think a more important share of people will eventually "get it" that there are alternative approaches which are sound, same or greater potential to achieve and thriving eco-system.