9 ms·
On moving code from C# to F#
- iuyoynp 11y agoplease dont override default scrolling behaviour, the site is unusable
- terinjokes 11y agoYep, agreed. I can only scroll by using the scrollbar.
- xeromal 11y agoFor someone uninformed, what did they change? I'm able to scroll using the keyboard keys, scroll bar, and arrow keys on my keyboard. Is mobile scrolling what's broken?
- abiox 11y agoalso seems to work fine on my end. scroll wheel, middle mouse button work too. seems normal.
- alangpierce 11y agoI'm using Chrome on Mac OS and I can't scroll left and right in any of the code examples. This is particularly bad because the OS hides scroll bars by default under the assumption that you'll be able to scroll left and right with the trackpad. Also, it's hard to describe exactly what the problem is, but scrolling up and down definitely feels weird and frustrating. For example, a light push that normally goes down a few lines of text on any other page seems to go down a full page. It also seems "stickier", like any scrolling takes a split second to "kick in". As a more contrived example, if I hold two fingers down on the trackpad and scroll up and down in place, any other page will scroll up and down following my fingers, but this page seems to jump around in an inconsistent way. Something on the page is trying to intercept scroll events and do something smart, but at least on a trackpad on Mac OS in Chrome it makes scrolling feel much worse and less predictable. It looks like Chrome, Firefox, and Safari all behave differently here, with Chrome behaving the worst.
- superuser2 11y agoThey added a TON of "inertia." Flick the trackpad a tiny little bit and it keeps moving long after I take my fingers off, giving an entirely different screenful. Your users know better than you how fast they intend to scroll. Always.
- jaegerpicker 11y agoNot sure what issues you are seeing but I'm able to scroll completely normally.
- mintplant 11y agoThere's a "smoothscroll.js" loaded by the page. Looks like it only targets Chrome users. http://www.felienne.com/wp-content/themes/zerif-lite/js/smoothscroll.js?ver=20120206 http://www.felienne.com/wp-content/themes/zerif-lite/js/smoo...
- kristianp 11y agoAlso the text on the code samples is so large the typical code is twice as wide as the box it's written in. Painful.
- rtpg 11y agoIs it possible to call F# code easily from C#? Or vice versa?
- kyberias 11y agoYes, very easily. Both are compiled to .NET assemblies and can see types of each other.
- Delmania 11y agoYes, I have a WebAPI module written in C# that calls into an F# module for some file processing. From the C# project's perspective, the F# assembly is just another assembly with static methods. It was a great use case for me to highlight the benefits of mixed paradigm programming. By making the WebAPI module state based, it made certain operations easier, while the F# module can do the heavy lifting of processing the data. You can also do a pure WebAPI module in F#.
- UnoriginalGuy 11y agoThat's a confusing post. You talk about WebAPI which is all JSON/AJAX, of course you can cross communicate there, the above poster is talking about direct inter-CLR calls (which you can do but have nothing to do with WebAPI).
- wtetzner 11y ago> From the C# project's perspective, the F# assembly is just another assembly with static methods. It sounds like he's calling the F# functions directly.
- Delmania 11y agoYes, the C# WebAPI project receives a file, and then passes it off to an F# module for processing. The WebAPI takes care of authorization, authentication, and some basic checks against the file, whereas the F# library is responsible for data processing.
- lerax 11y agoEasy, only up 3 tones.
- recursive 11y agoIt's a perfect fourth, which is 5 semitones. In other words, it's 2.5 tones. If you're going to make a pun, at least make it correct.
- tigershark 11y agoI think that this code can be much simpler, it is really difficult for me to follow it up. I'm not at all an F# expert, I just studied it a bit for fun last year, but I remember that all the code that I looked at was much more readable..
- MichaelGG 11y agoI've been using F# for a while and it's been excellent. It's just so less frustrating than writing C# in all its verbosity. There's really no reason to not use F# other than legacy or poor management. (Some folks just don't "get it". Perhaps the same kind of people that use a 20 char variable name when 3 would do. Or that are cautious about using local type inference. I don't know. But too many people conflate verbosity with readability and get scared.) I tried porting a small demo program, a few hundred lines, directly from C# to F#. It required only 1/20th of the type annotations. I've written web APIs in F# and many took about half the lines of code. I particularly like the ease in which I can define local functions to reduce redundancy. In, say, C#, there's so much overhead involved that it's just not worth it. Going back to F# I've written years ago hasn't been hard either. Since the code is so compact, it's not difficult to figure things out. F# should be MS's flagship. While F# isn't perfect (could use more inference, traits or typeclasses, and macros), in terms of tooling, ecosystem, language features it come out near the top.
- douche 11y ago> use a 20 char variable name when 3 would do. I generally think functional programming is a smart idea, but knock it off with the short, generic function names. We're not writing Fortran on an 80-char terminal any more. Name shit what it is, it's going to auto-complete anyway after you type 3-4 characters, so you might as well give it a name that you won't have to puzzle about later.
- conceit 11y ago> short, generic function names fit the length of the functions. Long names might be indicative of some deeper problem with coding style.
- platz 11y agoI think the reason functional programmers like short, terse names is because they need to see the structure of the code more than the individual identifiers. More verbosity makes it hard to get a picture of whats going on locally. Pattern Matching and Recursion creates structures that are easier to understand if it fits on the screen.
- carlosnunez 11y agoI LOVE F#. I wish I could use it more often. I haven't used it since I worked at Jane Street three years ago, and Jet.com is the only other place that's using it seriously at the moment. It is such an expressive and clear language to write code in. That is until you start needing to use imperative .NET types :)
- chadzawistowski 11y agoI thought Jane Street used OCaml! (I know the two are similar.) Why did they need to target the CLR?
- thristian 11y agoJust a guess: even if your back-end is all OCaml, traders still want to get data into Excel to play with it.
- carlosnunez 11y agoYes, Jane Street uses OCaml for their trading systems but we also use(d?) F# for some (very important) odds and ends.
- jackfoxy 11y agoF# is our primary language at Tachyus.
- snizzitch 11y agoThe (potential) terseness of F# seems like a bit of a superficial benefit compared to other features of the language, such as discriminated unions and pattern matching, excellent support for immutable records, structural equality by default, computation expressions, etc. I'm a C# developer with almost a decade of experience, and am pretty enamored with F# as well, but like almost everyone else, am stuck using it solely in my own personal time. However, I'm not certain how much benefit most teams would gain from using F#, after seeing the average (poor) level to which most developers are able to leverage the C# type system to improve the design of their software. Too many developers are forever stuck in a purely imperative paradigm, only knowing how to type one line of code after another, relying exclusively in enums for "extensibility," etc. It seems a bit hopeful to convince the community at large to switch to a language with an improved type system in hope that it will be used to create better software.
- snizzitch 11y agoI still think it'd be great if the .NET world were to switch over, if only for the sake of us few F# aficionados. :-)
- MichaelGG 11y agoI recall reading that bugs are many times related to the size of the code, across languages. This SO answer has some citations: http://programmers.stackexchange.com/a/185684 http://programmers.stackexchange.com/a/185684 But I think somewhere I read that the number of bugs goes up once a function stops fitting on one screen. Or maybe that was Arthur Whitney - J and K seem to do that nicely, and even his C style does so. Edit: Of course all those other benefits of F# are huge, indeed. But don't underestimate the advantages and pure joy that excellent "programming in the small" provides. As far as teams being stuck, you're basically saying that mediocre programmers can't handle good things. That's fine, but then the problem is hiring mediocre programmers. I suppose for a lot of basic CRUD/LOB or "enterprisey" stuff, it's important you can take essentially a typist and have them add business rules (like in Wisconsin, if the user is over 50, remove a certain discount). I don't find this type of programming to be particularly interesting though, so who cares what they use?
- dgudkov 11y agoWe use both C# and F# in our application, using C# for UI (WPF) and F# for data processing with a lot of calls from C# to F# and vice verse. Using F# was crucial, because it allowed writing heavy processing and complex algorithms (e.g. parallel hash aggregation) in a very clean and concise way with higher-level abstractions which saved us a lot of time. Things like not having to deal with null reference exceptions were also a big time-saver. Without F# it would have taken us one more year to release a production-ready application, or even made it impossible at all given the time & budget constrains that we had. If I ever start another project of that scale I will do it using only F#.