smoothdeveloper
Joined 10 years ago
Karma
153
Submissions
79
Member since
Apr 7
Recent submissions
Comment · 8 months ago
Comment · 8 months ago
Clef is a new backend for F# language aiming the language at concurrent systems use cases on native targets.
Comment · 1 year ago
Are you contributing to FUD? :D
Comment · 1 year ago
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.
Comment · 1 year ago
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.
Comment · 1 year ago
You can read this suggestion, and upvote, comment, contribute: https://github.com/fsharp/fslang-suggestions/issues/1434
Comment · 1 year ago
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 :)
Comment · 1 year ago
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.).
Comment · 1 year ago
In C#, you can't use the await keyword in a non async method, so I find the argument short sighted.
Comment · 1 year ago
/!\ 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.
Comment · 5 years ago
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.
Comment · 5 years ago
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/...
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.