6 ms·
The obvious answer why F# wins over Clojure in many people's books is static typing.
by dimitrios1 5y ago
The obvious answer why F# wins over Clojure in many people's books is static typing.
- bmitc 5y agoI also get the impression that that F# sits on top of its host VM better than Clojure, although I haven't used Clojure to any great degree. F#'s error messages are actually pretty good, and integrates with .NET so well, you really don't even need to know the existence of C# when using it. I really wish .NET Core came earlier and would have enticed Clojure to stay as a .NET language.
- kaliszad 5y agoClojureCLR does support .NET (Core) but there isn't any support by Microsoft and a .NET language really need at least some support by Microsoft, to be viable at all. Clojure work great with JVM, it is very tightly integrated. Similarly ClojureScript and JavaScript, even though that is actually transpiling. With shadow-cljs, it really is quite integrated into the ecosystem.
- kaliszad 5y agoI haven't felt the need for static typing in Clojure at all. I don't understand, why people are so dogmatic about static typing. In my experience and other on the team share it too, static types really haven't (or wouldn't have) prevented any bugs. What is more important are good names for variables/ references/ functions, code that just speaks to you or is at least sufficiently clear, up-to-date and clear documentation with examples and links if needed and efficient testing/ sensible test coverage. If I really need to know the type of something, I can always use (type <something>) or more concrete e.g (string? <something>) if I want to use that information for something. If I don't know, how to use the function, I have to improve the name, the documentation and my understanding of the code perhaps. If I pass garbage to a clearly named function, I get garbage out as with the static type system. In both cases, I have to investigate and ask myself tough questions about how I understand code or whether our code-base is well maintained. I can see static typing helping e.g. with compilers, low level software where every clock cycle and byte matter and some specialized stuff. I don't see much point in static typing in a language like Clojure.
- grayrest 5y agoIf you're on a project every day and familiar with all the pieces, there's not a large advantage to static typing. Static typing allows people unfamiliar with the program to make changes and have a reasonably high degree of confidence that they got them right. This can be junior devs, people new to the project, you after 5 years away, or a project that's grown to the point where nobody knows all the pieces. I'm not saying this as a die-hard static typing fan. I wrote Python for years, have written JS professionally most of my career, and spent 2 years writing Clojure professionally. I'm comfortable with dynamic languages. The Clojure codebase was the most stable I've been on (including typed languages) largely due to the senior team and excellent QA. The only problem I had with it was when business shifted from a subscription model to an a-la-carte model, which required manually reworking a LOT of maps to match the new requirements. This is considerably more painful in a dynamic language than it is in a static one. There IS a downside to static typing in terms of verbosity. I've seen Java codebases where half the code was there basically because of the static typing. More advanced type systems do not suffer from that problem. I'm fine with OCaml / F# / Rust / Typescript.
- kaliszad 5y agoGreat points, thank you for sharing your experience. Manual rework of maps seems like something that a good IDE or a small script should be able to automate, that is the point of Clojure being a data structure (EDN) after all - you can do stuff to the code as if it was data. Maybe there were specifics not allowing such sweeping changes, would love to hear more if you can share more about it. I have a colleague which became 18 just a few days ago. He newer heard of Clojure(Script) or CSS before late last year and started actively learning it sometime after that. Jan is able to work on considerable amounts of code for our new landing page that will have some special interactive OrgPad embeds in it. He didn't have much difficulty navigating Clojure or our code base considering he did most of the work after school and on weekends basically as a learning exercise. Of course, he is getting solid guidance by the team. Our CTO Pavel has 20+ years of experience as a programmer/ software engineer and can do code reviews with Jan, so that helps. It also doesn't hurt that Jan is very smart, basically hand selected over multiple years by our CEO Vít who led a mathematics course for children/ teens and as such known Jan very well. Giving Jan a chance like this is basically a pilot combining normal education with practical, professional experience. Something like a very long internship on steroids :-) I would still stress that static types are much less valuable than good variable/ function names and documentation/ clear code in my opinion and that maybe the complexity static types introduce isn't worth it overall. I also don't think, that static types as seen in e.g. Java or C# add any discernible degree of confidence - else somebody on the team would notice already. Jan didn't have problems navigating the code base even though most of the technologies, the language and the code base were completely new for him. Yes, anecdotal but I think it really is a valid and very important point.
- Barrin92 5y agoI think that needs the qualifier 'many (vocal) people's'. Dynamic languages continue to be exceedingly popular. The preference for static typing is I think over-represented in online discourse. I would be very surprised if the amount of Clojure/Clojurescript out there in production isn't several times larger than the amount of F#. Not trying to start a language war but with the exception of Jet which I don't think is around any more I can't recall a single large company using F#.
- kaliszad 5y agoThat is a good point about the vocal minority and this is a valid argument. On the other hand, I wouldn't consider the amount of code that was written in a language to be an indicator of good design (that usually saves work/ lines of code) or other qualities. I find, I solve the same class of problems better with Clojure instead of e.g. C# or Java or even Python (when not some SysAdmin stuff written for and with Python in mind - basically a DSL for the specific task).
- Zababa 5y ago> Dynamic languages continue to be exceedingly popular. The preference for static typing is I think over-represented in online discourse. The most popular dynamic languages are all adding static typing though. Typescript became extremely popular very quickly, Python has been adding types annotations for a long time now, Ruby is adding them too, some team at Facebook is working on the same for Erlang. I've seen a few times Clojure users saying they don't need them, and considering Clojure has immutability, a strong REP and spec, I can understand that they don't feel the need. But Python, JavaScript, Ruby and even some Erlang/Elixir users think the opposite. > I would be very surprised if the amount of Clojure/Clojurescript out there in production isn't several times larger than the amount of F#. I think the same, but the thing is that I think the amount of Java for web apps is already several times larger than the amount of C# for web apps, which can skew things.
- kaliszad 5y agoAnnotations/ hints you can use optionally to convey extra metadata are a very different thing compared to types you have to use else nothing will really work. There were some optional type systems for Clojure but I cannot say how successful they are or were. I think the critical parts, e.g. APIs or code boundaries are specced out and that seems to be the recommended solution. Btw. just that people are adding something doesn't mean that it is good or helping in general. It is great, Python has the optional type annotations precisely because they are optional - you can use them when you think you are better off doing the extra work.