Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

F# Not just for finance

fsharp.tv

Post reply on HN
Print view View original

131–138 of 138 posts

Re: F# Not just for finance

#131

Post by eulerfx234 »

bad_user wrote: post #128
eulerfx234 wrote: post #54

Earlier quoted context omitted.

I'm an engineer at Jet and hopefully I'll be able to answer your question. The concurrency model within F# is based on continuations. The type Async = (('a -> unit) -> unit) - its a function which accepts a callback to be notified when the async operation completes. The existing .NET ThreadPool is used to schedule these continuations across OS threads. It uses a trampoline to tame the stack. The ThreadPool itself is…

> async channels are special cases of sync channels You got it the other way around - synchronous is a special case of asynchronous, because any synchronous result or stream can be processed asynchronously, but for having guaranteed synchronous results you're adding restrictions. And going the other way, from async to sync is not possible without blocking threads, which is an error prone, platform specific hack. Take…

In CML/Hopac, async channels (buffers) are implemented in terms of sync channels - there is not async channel primitive built in. Synchronization is the essence of this model. When an operation is waiting on a matching communication through a channel, it is suspended, but no OS thread is blocked.

But yes, going from async to sync requires blocking, which is why CML/Hopac takes the approach of making sync the core primitive.

Re: F# Not just for finance

#132

Post by ZenoArrow »

tome wrote: post #130
ZenoArrow wrote: post #129

Earlier quoted context omitted.

> "Whatever you want the term to mean, it shouldn't be that, because that distinguishes nothing." It's not extremely useless when you consider most programming languages cover multiple PL paradigms. Functional languages are a spectrum. On one end you have pure functional languages like Haskell where you're forced to use functional algorithms for all computation, but there are languages in the middle of that spectrum…

> functional languages like Haskell where you're forced to use functional algorithms for all computation No you're not. Haskell supports mutable, imperative, algorithms just fine. https://hackage.haskell.org/package/base-4.9.0.0/docs/Data-I... https://hackage.haskell.org/package/base-4.9.0.0/docs/Contro... https://hackage.haskell.org/package/stm-2.4.4.1/docs/Control...

Thanks. If anything that backs up my main point that most programming languages are multi-paradigm.

Re: F# Not just for finance

#133

Post by eggy »

louthy wrote: post #111
eggy wrote: post #106

Earlier quoted context omitted.

Thanks for the information. Any mobile dev with F#, or is it all desk-based?

All our mobile stuff is thin web-layers that consume our core APIs, so it's all js. I started looking at WebSharper and FunScript for a more strongly-typed and robust web-development experience, but they're all a bit too 'awkward'. I keep meaning to look into Elm as it appears to be a more thoughtful approach to functional programming on the client.

I avoid JS, not because I don't like it, but there are other choices. Then again, it's much easier to find JS devs than Elm devs.

I've played with Elm, but not made anything of note with it yet. The Elixir/Phoenix crowd are getting hopped up about it lately as a good fit for them.

Re: F# Not just for finance

#134

Post by codygman »

ZenoArrow wrote: post #132
tome wrote: post #130

Earlier quoted context omitted.

> functional languages like Haskell where you're forced to use functional algorithms for all computation No you're not. Haskell supports mutable, imperative, algorithms just fine. https://hackage.haskell.org/package/base-4.9.0.0/docs/Data-I... https://hackage.haskell.org/package/base-4.9.0.0/docs/Contro... https://hackage.haskell.org/package/stm-2.4.4.1/docs/Control...

Thanks. If anything that backs up my main point that most programming languages are multi-paradigm.

Yes, but it doesn't bolster your argument as much as you think. The state monad in Haskell offers a more principled (some say annoying) way of dealing with mutation.

IORef's if I recall correctly offer the type of mutation similar to what is colloquially thought of as mutation.

These add to your argument a bit, but they're usually seen more of a last resort

Re: F# Not just for finance

#135

Post by eggy »

pmarreck wrote: post #127
eggy wrote: post #104

Earlier quoted context omitted.

As commented by others, F# was part of Microsoft Research, and not taken up by MS or other corporations when it was started. Erlang started out in Ericsson, a corporation. Elixir and LFE (Lisp Flavored Erlang) started out opensource and are still opensource. The term 'corporate self-interest' seems misplaced here, with the parenthetical remark turning it into the antonym of 'open-source'. The term proprietary, commer…

I agree with everything here except for the Pony promotion because after working on OO codebases for 15 years now, I am mostly convinced that OO has fundamental design flaws, at least when it comes to the long-term scalability and maintainability of codebases. Unfortunately it is difficult to "prove" this definitively currently, until someone comes up with a "complexity polynomial metric over time" for code, except t…

I heartily agree with what you have said. It is the reason I am not really biting at Pony. Maybe if I needed everything else it offered, or fully understood everything else it offered?

The problem I see now is that the entire functional domain is so spread out - Clojure, F#, OCaml, Haskell, Idris, Erlang/Elixir/LFE, and even the APL/J/K/Q crowd and Java's attempt to go functional. I'm not complaining about the number of functional languages to choose from, which is good. It's whether there will be enough critical mass in any one of the functional languages given a new non-functional language popping up every week. I don't know.

Now that MS has opensourced so much, and Xamarin's stuff is free, F# is looking better to me (again).

I also find myself dropping to C. C was my third language (after 6502 assembly and CPM Basic). Haskell/Idris/Elm are my toys of the year. I never fully dove into Haskell, but the concise, readable and very mathematical syntax agrees with my sensibilities.

Old! I'm 52, but I didn't stay with programming for a living, so my age doesn't reflect my programming experience. I did start with a CPM PET in 1978/79, but then went on years later to do other things.

Re: F# Not just for finance

#136

Post by tome »

ZenoArrow wrote: post #132
tome wrote: post #130

Earlier quoted context omitted.

> functional languages like Haskell where you're forced to use functional algorithms for all computation No you're not. Haskell supports mutable, imperative, algorithms just fine. https://hackage.haskell.org/package/base-4.9.0.0/docs/Data-I... https://hackage.haskell.org/package/base-4.9.0.0/docs/Contro... https://hackage.haskell.org/package/stm-2.4.4.1/docs/Control...

Thanks. If anything that backs up my main point that most programming languages are multi-paradigm.

Sort of. My very opinionated point of view would be that Haskell demonstrates that the functional paradigm is the correct setting for the imperative style.

Re: F# Not just for finance

#137

Post by Drup »

vessenes wrote: post #116
Drup wrote: post #85

Earlier quoted context omitted.

You should read the first two blog posts in detail. He didn't knew OCaml at all at the time, and answers your remark about Go directly in the second post.

I did read those. I think it comes down to speed on boot, which seems like a legit concern, and a matter of taste. To wit: Should os.Getenv return an empty string or an error if the environment variable is not set? -- The answer to this depends on how unix-y you are, I suspect. We might disagree, but it's not wrong to say that you're going to do what bash does, which is, after all the fundamental place these are kept…

If you read more carefully, you would see he would prefer that the language would not allow him to ignore errors.

You say "The idiomatic answer to this is that you should check error status", yes, that's a Go design pattern, but nothing enforces that. In other languages, thanks to Option/Result types, this is enforced, hence his opinion.

Such kind of safety and security concerns should not be enforced by conventions.

Re: F# Not just for finance

#138

Post by NovelSpinGames »

ProfChronos wrote: post #33

Just tried F# on https://www.codingame.com/games/puzzles Don't really see the use case for me, but fun to try smthg new => "one new language a day keeps the boredom away"

That's an awesome website! I made it through the first three puzzles using F#. It's too bad that there's nothing like IntelliSense there, but you can use Visual Studio or www.tryfsharp.org for typing and CodinGame for testing. It looks neat, but might not be the best for learning a new language. You can see some clever solutions after solving a puzzle at least. How familiar are you with F# and functional programming?
Post reply on HN