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

121–130 of 138 posts

Re: F# Not just for finance

#121

Post by chc »

vram22 wrote: post #117
louthy wrote: post #82

Earlier quoted context omitted.

Most OO languages can do this now, and they wouldn't be classed as functional languages. I know this is always a sticky subject, but for me I prefer to think of functional languages as 'expression oriented' rather than 'statement oriented'.

I'm not an expert on this subject (have only dabbled in a few FP languages over the years), but what I've read in various sources leads me to think that the term "functional programming" itself is not very well-defined, or, to put it another way, different people may have different definitions of it, each including and excluding various language features or capabilities. Is that right? Any experts care to comment?

Yes, but you could say the same about "object-oriented programming" (is it about inheritance? message passing? N/A?) and even something as well-defined as "pass by reference" (many people apply this term to Java, many others think that is completely wrong).

Ultimately, we have to live in a world where words are kind of ambiguous, but I think we should try to avoid useless definitions. The definition where "a functional programming language is one that can pass functions around" is extremely useless, because it applies to every modern programming language including C and C++. Whatever you want the term to mean, it shouldn't be that, because that distinguishes nothing.

Re: F# Not just for finance

#122

Post by hurricaneSlider »

louthy wrote: post #58
hurricaneSlider wrote: post #29

Earlier quoted context omitted.

Hey Louthy. Just wanted to say that I really appreciated your framework.

Thank you :) Out of interest, what are you using it for?

All over the place. :) I'm busy writing a federated subscription resolution framework, and I was finding it difficult to maintain a coherent dependency graph with mutable data structures.

Re: F# Not just for finance

#123

Post by louthy »

hurricaneSlider wrote: post #122
louthy wrote: post #58

Earlier quoted context omitted.

Thank you :) Out of interest, what are you using it for?

All over the place. :) I'm busy writing a federated subscription resolution framework, and I was finding it difficult to maintain a coherent dependency graph with mutable data structures.

Awesome. That's great to hear. If you have suggestions on improvements I'm always open to feedback, so feel free to shout on the issues page.

Re: F# Not just for finance

#124

Post by vram22 »

phyllostachys wrote: post #120
vram22 wrote: post #118

Earlier quoted context omitted.

Are there any terms/concepts in math/CS that are related to or similar to "idempotence"?

I think in this case, referential transparency means the same thing. That is, produce the same output given the same input, every time.

Got it, thanks.

Re: F# Not just for finance

#125

Post by vram22 »

chc wrote: post #121
vram22 wrote: post #117

Earlier quoted context omitted.

I'm not an expert on this subject (have only dabbled in a few FP languages over the years), but what I've read in various sources leads me to think that the term "functional programming" itself is not very well-defined, or, to put it another way, different people may have different definitions of it, each including and excluding various language features or capabilities. Is that right? Any experts care to comment?

Yes, but you could say the same about "object-oriented programming" (is it about inheritance? message passing? N/A?) and even something as well-defined as "pass by reference" (many people apply this term to Java, many others think that is completely wrong). Ultimately, we have to live in a world where words are kind of ambiguous, but I think we should try to avoid useless definitions. The definition where "a function…

Agreed.

Re: F# Not just for finance

#126

Post by [deleted] »

chc wrote: post #121
vram22 wrote: post #117

Earlier quoted context omitted.

I'm not an expert on this subject (have only dabbled in a few FP languages over the years), but what I've read in various sources leads me to think that the term "functional programming" itself is not very well-defined, or, to put it another way, different people may have different definitions of it, each including and excluding various language features or capabilities. Is that right? Any experts care to comment?

Yes, but you could say the same about "object-oriented programming" (is it about inheritance? message passing? N/A?) and even something as well-defined as "pass by reference" (many people apply this term to Java, many others think that is completely wrong). Ultimately, we have to live in a world where words are kind of ambiguous, but I think we should try to avoid useless definitions. The definition where "a function…

[deleted]

Re: F# Not just for finance

#127

Post by pmarreck »

eggy wrote: post #104
pmarreck wrote: post #72

I want to suggest looking at a language like Erlang/Elixir that didn't start out from corporate self-interest (i.e., was open-source from the get-go) but a rising functional tide floats all boats. (And besides, Elixir "borrowed" a few good ideas from F#.) I've had nothing but good experiences during my forays into functional langs. Here's to a more functional, immutable, easily-concurrent, easily-unit-tested future

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 to talk to old programmers like myself (44) who have done this for a long while and gotten disillusioned due to all the time spent repairing OO complexity/tech debt bugs, and have become entranced by functional langs and the way they avoid inheritance, use immutable values and are super careful with state, all of which contributes to better long term code life

Fortunately I'm not the only old OO guy proclaiming this, I have John Carmack on my side:

http://www.gamasutra.com/view/news/169296/Indepth_Functional...

"My pragmatic summary: A large fraction of the flaws in software development are due to programmers not fully understanding all the possible states their code may execute in. In a multithreaded environment, the lack of understanding and the resulting problems are greatly amplified, almost to the point of panic if you are paying attention. Programming in a functional style makes the state presented to your code explicit, which makes it much easier to reason about, and, in a completely pure system, makes thread race conditions impossible."

"No matter what language you work in, programming in a functional style provides benefits. You should do it whenever it is convenient, and you should think hard about the decision when it isn't convenient."

Re: F# Not just for finance

#128

Post by bad_user »

eulerfx234 wrote: post #54
cm3 wrote: post #35

Earlier quoted context omitted.

I should have been more specific in the question. I'm used to Erlang and Haskell (GHC) concurrency primitives and frameworks. To reformulate: what concurrency models can you employ in F# that don't involve manually managing threads/processes?

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 the possibility of blocking threads away and you'll notice the true nature of these models.

Re: F# Not just for finance

#129

Post by ZenoArrow »

chc wrote: post #121
vram22 wrote: post #117

Earlier quoted context omitted.

I'm not an expert on this subject (have only dabbled in a few FP languages over the years), but what I've read in various sources leads me to think that the term "functional programming" itself is not very well-defined, or, to put it another way, different people may have different definitions of it, each including and excluding various language features or capabilities. Is that right? Any experts care to comment?

Yes, but you could say the same about "object-oriented programming" (is it about inheritance? message passing? N/A?) and even something as well-defined as "pass by reference" (many people apply this term to Java, many others think that is completely wrong). Ultimately, we have to live in a world where words are kind of ambiguous, but I think we should try to avoid useless definitions. The definition where "a function…

> "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 like C# which support a bunch of functional language constructs (take a look here for a selection: http://www.codeaddiction.net/articles/13/lambda-expressions-... ) even if they aren't purely functional.

My argument is, any definition of functional programming that ignores the mid part of the spectrum is useless, as it ignores that most languages do not strictly follow a single approach like Haskell but allow you to adapt to different styles (i.e. most programming languages are multi-paradigm). Even F# and Ocaml allow you to write in an imperative style if you so choose, and many people would class them as 'functional' languages.

Re: F# Not just for finance

#130

Post by tome »

ZenoArrow wrote: post #129
chc wrote: post #121

Earlier quoted context omitted.

Yes, but you could say the same about "object-oriented programming" (is it about inheritance? message passing? N/A?) and even something as well-defined as "pass by reference" (many people apply this term to Java, many others think that is completely wrong). Ultimately, we have to live in a world where words are kind of ambiguous, but I think we should try to avoid useless definitions. The definition where "a function…

> "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...

Post reply on HN