This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2023-01-05
Channels
- # announcements (1)
- # babashka (61)
- # babashka-sci-dev (1)
- # beginners (54)
- # biff (17)
- # cider (4)
- # circleci (1)
- # clj-commons (39)
- # clj-kondo (26)
- # cljdoc (40)
- # clojure (41)
- # clojure-europe (32)
- # clojure-norway (4)
- # clojure-portugal (1)
- # clojure-uk (2)
- # clojurescript (59)
- # clr (69)
- # conjure (7)
- # cursive (22)
- # data-science (16)
- # datalevin (1)
- # datomic (19)
- # docker (31)
- # funcool (1)
- # honeysql (6)
- # hoplon (1)
- # hyperfiddle (41)
- # introduce-yourself (1)
- # juxt (2)
- # leiningen (5)
- # nbb (14)
- # nextjournal (38)
- # off-topic (47)
- # polylith (2)
- # rdf (5)
- # re-frame (4)
- # reitit (27)
- # releases (6)
- # scittle (10)
- # shadow-cljs (24)
- # sql (11)
- # squint (1)
- # tools-build (33)
- # tree-sitter (4)
- # vim (39)
https://clojurians.slack.com/archives/C03S1KBA2/p1672934595731059?thread_ts=1672525151.957679&cid=C03S1KBA2 Not having looked at it, if it’s like Java, then the language is closely aligned with the capabilities of the CLR, so knowing the C# language would lead to a better understanding of the ecosystem that these languages play in
I’m expecting something similar, because the CLR grew out of the Visual J++ engine that MS released in the late 90s
(which led to them being sued by Sun, so they turned around, expanded on it, and introduced .Net)
Yes, that's true, I learned Clojure knowing some Java, but I've never known Clojure as well as Java. I did, however, do some research into the JVM and tried to get a baseline understanding of Java Bytecode
If F# is a good programming language, then you should be able to learn it proficiently without learning an entire other language (C#) in my opinion, which is not to say that knowing C# doesn't help in learning F# immensely
Nothing wrong with learning it, I just don't know that you need to if you're main goal is F# itself
But you can really do so much more when you know the ins-and-outs of the underlying system

But I'd argue you need to know almost nothing about Java to start learning Clojure
For instance, if I didn’t know Java, then I could not have built the memory mapped approach to Asami database files
To me the system is more the JVM than Java though
I think you could have learned that approach as needed though, right? Like you could have learned what Java knowledge you needed when you needed it for a particular library/application?
Yes, and I usually avoid Java. But Java is tied into the JVM, even if you don’t want to use it

I don't think we're disagreeing, but I guess I'm not convinced that the most efficient way to learn F# is to learn C# first or the most efficient way to learn Clojure is to learn Java first
I knew almost no Java when I first picked up Clojure and have found that it (Clojure) has taught me Java along the way, because I frequently write Java code by testing it in a REPL first
I don’t know… I can build things because I synthesize a broad array of knowledge from across the system. If I enter a system as a new user, then I don’t know what I don’t know.

> I don’t think we’re disagreeing, but I guess I’m not convinced that the most efficient way to learn F# is to learn C# first or the most efficient way to learn Clojure is to learn Java first I do agree with this!
Yeah, I think I'm coming from a similar angle to @U03QBKTVA0N in that my knowledge of Java was beginner level (understood syntax but hadn't used for more than a couple small projects) in learning Clojure, and interop in Clojure has taught me a lot about Java
But my style of learning has always been to start from first principles. It’s slower to learn, but more thorough. This is different to almost everyone I know
Similarly, I knew nothing about C# when I started learning ClojureCLR, and have picked up things about the language in the process
I wonder if the best way to learn F# is to know OCaml (this is a joke, but I wish I knew both)
For a bit of added context re: F#, I have read that F# version 1.0 was intended to be almost fully compatible with OCaml. Most of its fundamental deviations in subsequent releases were tailored around developer ergonomics. I think in learning F#, knowing C# would just give you a better feel for the overall ecosystem, what namespaces and functionality are available to you in the CLR and standard library, etc. Coming from another functional language, however, will give you an advantage in terms of learning its semantics.
First we learn ML to learn OCaml
@U02LTEZBQ0Z you have experience with C#, F#, and OCaml, right?
I was a C# dev for a number of years before moving to Clojure, and have been experimenting with F#. I have a tiny bit of familiarity with OCaml.
For context regarding my joke earlier: https://github.com/dmiller/clojure-clr-next
I should caveat: I don’t know OCaml very well at all. I’m also only proficient enough in StandardML so that I can read it. I would not try to write programs with it
There's a fintech company (which term I use out of total ignorance of anything to do with finance) that uses OCaml as their primary dev language
OCaml sadly has multiple competing standard libraries, one of which is Jane Street Core
Their podcast Signals and Threads is quite enlightening
Oh… back to an earlier point Emma: I want to get better at C# because I’m forever looking at the source code of the Clojure I’m writing 🙂
I’m always looking in https://github.com/clojure/clojure/tree/master/src/jvm/clojure/lang
@U051N6TTC so you want to be able to readily read the ClojureCLR source?
Was there https://twitter.com/quoll/status/1610886385401040897?s=20&t=W2eIPNZ4wWap00s9JSGxIw in fact
That's completely fair
Just stating my opinion here: I found C# to be a very solid and productive language to use, and over the years it's gained more and more functional features as well (acquired largely from F#)
Admittedly, I found it solid and productive to use compared to the language I was using before that, which was PHP 👀
If you're looking at ClojureCLR source and also thinking of F# down the line, take a look at the reconsidered
branch of the repo, specifically https://github.com/clojure/clojure-clr/tree/reconsidered/Clojure.New/Clojure.Numerics where I've been playing with reimplementing it in F#. That code is a bit of a mess at the moment because I'm doing some testing of implementation techniques, but it gives a flavor. I'm likely to move all that development over to https://github.com/dmiller/clojure-clr-next pretty soon. Hope to have some conversation over there.

@U45FQSBF1 what's the plan for clojure-clr-next
? Is this going to eventually replace the C# implementation of ClojureCLR as the default?
I imagine clojure-clr-next
should make F# interop easier, which would be nice
I have several conflicting thoughts in mind. I do want to do a serious rewrite of the compiler to make it do better type inferencing, handle structs and generics better. That includes all kinds of related goodies such as a better way to refer to things like generic types. Some of the thinking on type infernencing/structs has been done by Ramsey Nasser in the Arcadia project (ClojureCLR in Unity). And I'm really thinking about doing this in F#. I like the terseness and expressiveness of the code and a compiler is great place to show that off. A thought in my head is to just do it all in F#. Reconsider every decision made in the code and get it all annotated. for the next person.
I think F# is the right choice as well, unless there's some noticeable performance benefit to writing the compiler and interpreter in C# instead. I've written a couple compilers in C but only for pedagogical languages so I can't really give experienced advice unfortunately. There's definitely some bias on my part too, as someone who enjoys F# at a glance, but not C# at a glance.
Similar thoughts. I don't think there is a performance issue in the compiler. I'm more worried about the basic data structures. I'm going to be doing a lot of benchmarking.
F# has C# interop as well, if I'm not mistaken, so it may be that deferring certain performance intense operations to C# interop/data structures while writing the rest in F# is a reasonable compromise, but that's just a guess
I think that that interop is a possibility. But first I want to explore to see if I can get equivalent or better performance from F#.
Nothing like writing implementations for functional programming languages in other functional programming languages
If ClojureCLR is rewritten in F#, would C# interop from ClojureCLR still work the same as it does today?
I assume F# interop with ClojureCLR is already possible for certain F# libraries that are packaged for use by C#
Since they could be packaged as classes inside .dll
files that ClojureCLR can import, but maybe there are runtime issues with that
I'll probably explore this question when I have time, I really like F# so if I need to write something for interop I'd rather use F# than C#
I'm also interested in exploring calling ClojureCLR code from F#
I meant the other way around 🙂 If ClojureCLR is rewritten in F#, how would it affect C# interop from Clojure (CLR)? I guess since they share the same runtime, most things would just work as they did previously?
Well F# has C# interop so I'm sure it would still be possible, but I wonder if the syntax would change at all :thinking_face:
Since I guess there are a hundred C# developers per one F# developer, it seems important that the experience is great for the larger group 🙂
I agree with that, but I think we could appease both?
Maybe I'm overly optimistic
I hope you’re right 🙂
Re consuming F# from ClojureCLR right now: If it is packaged for C# consumption, should be straightforward. If it is pure F#, you could interact, but would have to understand more about how F# does its thing. Re implications of interop if ClojureCLR is in F#: I plan to make sure that all the interfaces that one uses to interact either from Clojure source itself or from C# will look as they do today.