9 ms·

Awesome to see F# supported, based on OSS F# for Jupyter Notebooks (https://github.com/fsprojects/IfSharp https://github.com/fsprojects/IfSharp) work. It's rea

Awesome to see F# supported, based on OSS F# for Jupyter Notebooks (https://github.com/fsprojects/IfSharp https://github.com/fsprojects/IfSharp) work. It's really lovely when a tool written in another tech (Python there) can be used/extended with others stack/tech, because was written as language agnostic. That should be a rule for good design in oss tooling. Not starting using language specific communication, but extensibile from day0 in design (obv default language can be bundled)

nnq 10y ago
Seeing APIs that look like: Chart.Line(data) |> Chart.WithTitle("smth") |> ... ...makes anyone say "yuck" and avoiding F# for any exploratory work. And even after you understand how the pipe operator works and how useful it can be in other contexts. I mean, ugh... Even putting up with superfluous verbosity like `List.Map(myList)` instead of a `map(myList, ...)` or `myList.map(...)` because "that's how F#/OCaml does it, stfu" is ok, but this seems like purposeful obsfucation. No wonder R and Python are the only languages popular in ML. They are the only ones leading to sane readable code by people having other stuff to keep loaded in their head than language details. I mean, yeah, syntax that doesn't matter, unless it's so f annoying and ugly that you simply can't put up with it as much as you try!
- KirinDave 10y ago
  I'm... confused what you're upset about. Are you upset about the leading "Chart?" This is very, very easy stuff for functional programming. Most of the people I know in ML, talented ML folks doing data science within the org I work for to do exciting things... they actually aren't huge fans of the way Python does things. They're huge fans of the libraries Python has to speed up ML work. F# has a real lack there (surprisingly!). But like, saying that you like: Chart.Line(data).WithTitle("smth").render() as opposed to: Chart.Line(data) |> Chart.WithTitle("smdh") seems to me like 6 of one or half a dozen of the other. Especially since when you're reusing any given part of the pipeline, the ML way is alot more terse. And it's not like Python is devoid of hideous examples of poor language design. For example, self parameters. All we're told is some new age mysticism about how "explicit is better than implicit", but somehow that doesn't apply when we need higher order functions and we're using private function with lambda names to try and signal to readers that, "Sorry I needed 2 statements in my list comprehension and Python talks down to me like that guy from Timecube because of it." Why is explicitness valuable there but not on tuple construction? And it's not like Python doesn't make you arbitrarily choose between List.function and list.method with no seeming decisions to make. Which is not to say Python is especially bad. It is to say that you may have normalized Python so much that you forget all computer languages are somewhat arbitrary.
  - jaegerpicker 10y ago
    Yeah, I'm fairly certain that guy was trolling, but to make this post actually worthwhile, there are a ton of ML libs accessible from F#, http://fsharp.org/guides/data-science/ http://fsharp.org/guides/data-science/ Lists a bunch though the R interop is probably the best/most fully formed IMO.
  - nnq 10y ago
    > all computer languages are somewhat arbitrary No, avoiding unnecessary repetition (god damn DRY at the syntax level) and avoiding visual noise is not arbitrary. It's just good practical taste. I don't live in houses where doors have 2 knobs that need to be pressed at the same time to open a door. And I don't eat steak with a fork that has a knife as a handle. Both of those could work and make sense for some, but overall they are bad taste and awkward for 99% of people. Python gets it right. Ruby gets it right. Julia gets it right. Most lisps get it right etc. (Even Java and C# get them "as right as they could" considering all their history and past choices that seriously limited what kinds of languages they could be.) And my issue is that I like the semantics of languages like F# and OCaml and Haskell after having played a bit with them but by god, they couldn't have chosen more infuriating syntaxes and name resolution systems or module systems or tools for them... like they tried as hard as they could to piss off "the plebs in the industry" who actually care about syntax and other such little details, because, ya know, when what you're developing is not that interesting, you should at least have the pleasure of writing code that you aesthetically enjoy to read! And it's hard to convince fellow industry plebs of the usefulness of advanced type systems when the first code sample they see elicits an "ugh" or "yuck" reaction. Most of us programmers are shallow and lazy and we should be proud of this and build tools that cater to our "virtues". Or maybe I'm in the minority by liking dense and non-repetitive notations and finding them easier to read too...
    - KirinDave 10y ago
      > Python gets it right. Ruby gets it right. Julia gets it right. Most lisps get it right etc. What. I ship Clojure all day, got CL in my past. Was a full time ruby dev. I got a list of ugh and eck for all of them. I can name 30 more issues with Python. Truth be told, I think Python is a rancid language and I think people who love it are basically eating barf pancakes every day and thanking people who look down on then for it. GVR doesn't do that bs "I don't get lambdas" garbage in the company of other language designers, that's for sure. What you consider visual noise is arbitrary. It's like what color paper you prefer to note take on. Every language has issues. Python is riddled with syntactic noise and artifacts that you've normalized. Ruby's syntax is better, but still full of quirks and surprises. Don't even get me started on Scala. "I am used to this" and "this is objectively better unless you are some academic" is a classic example of industry insecurity. You shouldn't avoid Haskell because you are irritated with a bit of syntax, you should avoid it because you can't ship or maintain the kind of deliverables you need to write. > Most of us programmers are shallow and lazy and we should be proud of this and build tools that cater to our "virtues". Pride is one of the ugliest sins of our industry, I agree. Too many developers refuse to accept that there might be progress in the industry outside of what they experienced in their first 2 years in the industry.
- 16bytes 10y ago
  > No wonder R and Python are the only languages popular in ML R is a curious counter-example, given that the '%>%'[1] operator in dplyr is nearly identical to the '|>' operator in F#. Given dplyr's ubiquity, it would seem that people coming from R would have no issue with F#. [1] https://cran.rstudio.com/web/packages/dplyr/vignettes/introduction.html#chaining https://cran.rstudio.com/web/packages/dplyr/vignettes/introd...
chupapuma 10y ago
Thanks enricsosada. I am a dev on Azure Notebooks and I spent time working with a couple of people in Microsoft Research to get this going and we are very happy with the result. The F# community has been very helpful in getting this going. If there are other languages you would like to see, or other features or issues, reach out to us on https://github.com/microsoft/azurenotebooks https://github.com/microsoft/azurenotebooks or nbhelp@microsoft.com

nnq 10y ago

Seeing APIs that look like: Chart.Line(data) |> Chart.WithTitle("smth") |> ... ...makes anyone say "yuck" and avoiding F# for any exploratory work. And even after you understand how the pipe operator works and how useful it can be in other contexts. I mean, ugh... Even putting up with superfluous verbosity like `List.Map(myList)` instead of a `map(myList, ...)` or `myList.map(...)` because "that's how F#/OCaml does it, stfu" is ok, but this seems like purposeful obsfucation. No wonder R and Python are the only languages popular in ML. They are the only ones leading to sane readable code by people having other stuff to keep loaded in their head than language details. I mean, yeah, syntax that doesn't matter, unless it's so f annoying and ugly that you simply can't put up with it as much as you try!

KirinDave 10y ago
I'm... confused what you're upset about. Are you upset about the leading "Chart?" This is very, very easy stuff for functional programming. Most of the people I know in ML, talented ML folks doing data science within the org I work for to do exciting things... they actually aren't huge fans of the way Python does things. They're huge fans of the libraries Python has to speed up ML work. F# has a real lack there (surprisingly!). But like, saying that you like: Chart.Line(data).WithTitle("smth").render() as opposed to: Chart.Line(data) |> Chart.WithTitle("smdh") seems to me like 6 of one or half a dozen of the other. Especially since when you're reusing any given part of the pipeline, the ML way is alot more terse. And it's not like Python is devoid of hideous examples of poor language design. For example, self parameters. All we're told is some new age mysticism about how "explicit is better than implicit", but somehow that doesn't apply when we need higher order functions and we're using private function with lambda names to try and signal to readers that, "Sorry I needed 2 statements in my list comprehension and Python talks down to me like that guy from Timecube because of it." Why is explicitness valuable there but not on tuple construction? And it's not like Python doesn't make you arbitrarily choose between List.function and list.method with no seeming decisions to make. Which is not to say Python is especially bad. It is to say that you may have normalized Python so much that you forget all computer languages are somewhat arbitrary.
- jaegerpicker 10y ago
  Yeah, I'm fairly certain that guy was trolling, but to make this post actually worthwhile, there are a ton of ML libs accessible from F#, http://fsharp.org/guides/data-science/ http://fsharp.org/guides/data-science/ Lists a bunch though the R interop is probably the best/most fully formed IMO.
- nnq 10y ago
  > all computer languages are somewhat arbitrary No, avoiding unnecessary repetition (god damn DRY at the syntax level) and avoiding visual noise is not arbitrary. It's just good practical taste. I don't live in houses where doors have 2 knobs that need to be pressed at the same time to open a door. And I don't eat steak with a fork that has a knife as a handle. Both of those could work and make sense for some, but overall they are bad taste and awkward for 99% of people. Python gets it right. Ruby gets it right. Julia gets it right. Most lisps get it right etc. (Even Java and C# get them "as right as they could" considering all their history and past choices that seriously limited what kinds of languages they could be.) And my issue is that I like the semantics of languages like F# and OCaml and Haskell after having played a bit with them but by god, they couldn't have chosen more infuriating syntaxes and name resolution systems or module systems or tools for them... like they tried as hard as they could to piss off "the plebs in the industry" who actually care about syntax and other such little details, because, ya know, when what you're developing is not that interesting, you should at least have the pleasure of writing code that you aesthetically enjoy to read! And it's hard to convince fellow industry plebs of the usefulness of advanced type systems when the first code sample they see elicits an "ugh" or "yuck" reaction. Most of us programmers are shallow and lazy and we should be proud of this and build tools that cater to our "virtues". Or maybe I'm in the minority by liking dense and non-repetitive notations and finding them easier to read too...
  - KirinDave 10y ago
    > Python gets it right. Ruby gets it right. Julia gets it right. Most lisps get it right etc. What. I ship Clojure all day, got CL in my past. Was a full time ruby dev. I got a list of ugh and eck for all of them. I can name 30 more issues with Python. Truth be told, I think Python is a rancid language and I think people who love it are basically eating barf pancakes every day and thanking people who look down on then for it. GVR doesn't do that bs "I don't get lambdas" garbage in the company of other language designers, that's for sure. What you consider visual noise is arbitrary. It's like what color paper you prefer to note take on. Every language has issues. Python is riddled with syntactic noise and artifacts that you've normalized. Ruby's syntax is better, but still full of quirks and surprises. Don't even get me started on Scala. "I am used to this" and "this is objectively better unless you are some academic" is a classic example of industry insecurity. You shouldn't avoid Haskell because you are irritated with a bit of syntax, you should avoid it because you can't ship or maintain the kind of deliverables you need to write. > Most of us programmers are shallow and lazy and we should be proud of this and build tools that cater to our "virtues". Pride is one of the ugliest sins of our industry, I agree. Too many developers refuse to accept that there might be progress in the industry outside of what they experienced in their first 2 years in the industry.
16bytes 10y ago
> No wonder R and Python are the only languages popular in ML R is a curious counter-example, given that the '%>%'[1] operator in dplyr is nearly identical to the '|>' operator in F#. Given dplyr's ubiquity, it would seem that people coming from R would have no issue with F#. [1] https://cran.rstudio.com/web/packages/dplyr/vignettes/introduction.html#chaining https://cran.rstudio.com/web/packages/dplyr/vignettes/introd...

chupapuma 10y ago

Thanks enricsosada. I am a dev on Azure Notebooks and I spent time working with a couple of people in Microsoft Research to get this going and we are very happy with the result. The F# community has been very helpful in getting this going. If there are other languages you would like to see, or other features or issues, reach out to us on https://github.com/microsoft/azurenotebooks https://github.com/microsoft/azurenotebooks or nbhelp@microsoft.com