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

Why F# evangelism isn't working (2015)

ericsink.com

Post reply on HN
Print view View original

191–200 of 333 posts

Re: Why F# evangelism isn't working (2015)

#191

Post by thesz »

c00lio wrote: post #128
epgui wrote: post #102

Earlier quoted context omitted.

> without being prone to floating off into abstraction orbit What do you mean by this?

"Oh, you _also_ need to print something? Lets stack a few monad transformers..." "But remember that you need the TemplateExplicative and NullUnderstanding compiler extensions!"

You can use eventlog traces, from Debug.Trace [1]. You can (traceEvent $ "look: " ++show bazinga) everywhere you need and then stare at the log to your heart content.

[1] https://hackage.haskell.org/package/base-4.18.0.0/docs/Debug...

No need for extensions, just compile and run your program slightly differently. That's the power of declarative languages.

Re: Why F# evangelism isn't working (2015)

#192

Post by smcl »

pjmlp wrote: post #158
cjbgkagh wrote: post #31

Earlier quoted context omitted.

I think F# programmers lack that gamut because they get comfortable in the eager execution type safe world and stay there with no particular reason to learn dynamic programming techniques. There is also the effect that it allows less advanced functional programmers to be productive so that in randomly sampling currently active functional programmers the F# programmer is less likely to be advanced. Scala developers we…

They keep trying to kill .NET, just check how much WinDev keeps doubling on COM and pushing subpar frameworks like C++/WinRT. One would expect that by now, out-of-process COM would be supported across all OS extension points, instead it is still pretty much in-process COM, with the related .NET restrictions. Then there is the whole issue that since Longhorn, most OS APIs are based on COM (or WinRT), not always with .…

Doesn't look to me like they're trying to kill .NET at all. Maybe F# in particular isn't getting the love and attention it deserves but they'd have to be mental to be actively trying to kill off something as popular as .NET

Re: Why F# evangelism isn't working (2015)

#193

Post by ak_111 »

gemstones wrote: post #3

This is a nicely written essay and, I think, completely wrong. (One person's experience here, just as a disclaimer.) I've interviewed a lot of functional candidates in a decade-long stint of functional programming professionally. My interview approach is always the same. All practical exercises, no leetcode here. You can do the exercises in the language you're most comfortable in. If I had to pick a language that pre…

Just curious what kind of career did you have that enabled you to have a long stint as function programmer? The fact that you don't use Leet code makes it also sound you are not FAANG so makes it more intriguing.

Re: Why F# evangelism isn't working (2015)

#194

Post by zogrodea »

keithnz wrote: post #65
KurtMueller wrote: post #17

Earlier quoted context omitted.

... or units of measure

while I like it, it doesn't actually seem that useful.... and given I work on IoT systems measuring all kinds of things in all kinds of units, it isn't at all useful for that. Kind of cool for when you are using F# as a calculator though

I haven't found them useful in my experience either, but they seem to have a real indispensable utility in some cases like algebra for simulations. At least, that is what I gathered from Matthew Crews who has the "FastFSharp" channel on YouTube and a Twitter account with the same name. (He employs mutability heavily for performance, so not what I think of as an average F# developer.)

Re: Why F# evangelism isn't working (2015)

#195

Post by e12e »

gemstones wrote: post #3

This is a nicely written essay and, I think, completely wrong. (One person's experience here, just as a disclaimer.) I've interviewed a lot of functional candidates in a decade-long stint of functional programming professionally. My interview approach is always the same. All practical exercises, no leetcode here. You can do the exercises in the language you're most comfortable in. If I had to pick a language that pre…

Curious about what one of your typical "practical exercises" looks like?

I'm not a great fan of f# (it's not rational - but every time I've tried to dip my toes, something in the syntax has felt... Tedious? In a way that for example StandardML does not). But it still seems like an eminently powerful and pragmatic language, so I'm surprised by your experience.

Ed: I see this was addressed downthread:

https://news.ycombinator.com/item?id=36133560

https://news.ycombinator.com/item?id=36133578

Fascinating that fsharpers trip up on ad- hoc json wrangling - to be fair i used to agonize over nested lists/association lists in lisp - rather than doing the "professional" thing and YOLO assume that three levels down, behind :user - there's a fifth element :email...

Re: Why F# evangelism isn't working (2015)

#196

Post by otto-edgar »

rgbgraph wrote: post #141
ThinkBeat wrote: post #126

Earlier quoted context omitted.

Every system if allowed to become too complex. No single paradigm of programming is perfect for all cases. OO is one way to structure and model a system. No matter what language you use will end up with some form of a struct, a set of values that belong together Then you will have list of some structs and trees of some structs You will almost certainly have to create list/collections/groupings of structs. Because tho…

Just like every language is able to be slow/non-performant -- but OO in this case would be Python in a web context; it doesn't invalidate that a good amount of OO codebases in the wild devolve into incomprehensible black boxes, where no one has any idea what anything does or how to make meaningful changes that fulfill the intent of (compare that to iterative programming, where you can atleast read it) A list: I give…

What do you find insane about the C# `List` source code?

I'm not a C# programmer, but the public API looks sound, and the entire thing is like 1K LOC including docstrings (I guess the inherited code would add to that).

Re: Why F# evangelism isn't working (2015)

#197

Post by scotty79 »

thesz wrote: post #191
c00lio wrote: post #128

Earlier quoted context omitted.

"Oh, you _also_ need to print something? Lets stack a few monad transformers..." "But remember that you need the TemplateExplicative and NullUnderstanding compiler extensions!"

You can use eventlog traces, from Debug.Trace [1]. You can (traceEvent $ "look: " ++show bazinga) everywhere you need and then stare at the log to your heart content. [1] https://hackage.haskell.org/package/base-4.18.0.0/docs/Debug... No need for extensions, just compile and run your program slightly differently. That's the power of declarative languages.

I can't tell if you are trying to defend those languages or just piling up absurdities on the previous post in the style of "yes, and ..." improv.

Re: Why F# evangelism isn't working (2015)

#198

Post by frozenlettuce »

c00lio wrote: post #128
epgui wrote: post #102

Earlier quoted context omitted.

> without being prone to floating off into abstraction orbit What do you mean by this?

"Oh, you _also_ need to print something? Lets stack a few monad transformers..." "But remember that you need the TemplateExplicative and NullUnderstanding compiler extensions!"

"now just sprinkle some `map . sequence . map`'s here and there and you are done. who said this was difficult?"

Re: Why F# evangelism isn't working (2015)

#199

Post by c00lio »

thesz wrote: post #191
c00lio wrote: post #128

Earlier quoted context omitted.

"Oh, you _also_ need to print something? Lets stack a few monad transformers..." "But remember that you need the TemplateExplicative and NullUnderstanding compiler extensions!"

You can use eventlog traces, from Debug.Trace [1]. You can (traceEvent $ "look: " ++show bazinga) everywhere you need and then stare at the log to your heart content. [1] https://hackage.haskell.org/package/base-4.18.0.0/docs/Debug... No need for extensions, just compile and run your program slightly differently. That's the power of declarative languages.

Not everything is tracing and debugging, sometimes you really need to output intermediate results for "normal", "production" purposes. One could still abuse Debug::Trace, but that would really be ugly.

I also object to that "everywhere". It is far easier to just dump an extra 'print' line somewhere inside a for-loop than into a `foldl (*) 1 $ map (+ 3) [17, 11, 19, 23]`. And that is an easy one...

Re: Why F# evangelism isn't working (2015)

#200

Post by thesz »

scotty79 wrote: post #197
thesz wrote: post #191

Earlier quoted context omitted.

You can use eventlog traces, from Debug.Trace [1]. You can (traceEvent $ "look: " ++show bazinga) everywhere you need and then stare at the log to your heart content. [1] https://hackage.haskell.org/package/base-4.18.0.0/docs/Debug... No need for extensions, just compile and run your program slightly differently. That's the power of declarative languages.

I can't tell if you are trying to defend those languages or just piling up absurdities on the previous post in the style of "yes, and ..." improv.

I am trying to offer counterpoint to what seems to me as an unjust critique from a person who, at first sight, does not know much about Haskell.

Also, a link to a useful library is not a bad thing for anyone curious about Haskell. Thus, there's a bit of education there.

If it looks like improv, I am here every evening till Friday.

Post reply on HN