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

Why F#?

batsov.com

Post reply on HN
Print view View original

391–400 of 424 posts

Re: Why F#?

#391

Post by sparkie »

volemo wrote: post #367
baq wrote: post #298

Earlier quoted context omitted.

strong typing: 2 + "2" is an error (e.g. Python vs JS) static typing: 2 + "2" does not compile/parse (e.g. Python vs mypy, Typescript vs JS) this is a very simplistic example, but should get you to feel the difference.

> static typing: 2 + "2" does not compile/parse (e.g. Python vs mypy, Typescript vs JS) I think this example is not correct, because static typing doesn’t affect how values of different types interact. And while I don’t know of any staticly typed language where specifically `2 + “2”` is a valid expression, statically typed languages definitely can be weakly typed: the most prominent example is C where one can combine…

Dynamic typing can forbid the latter (at runtime), but it's implementation dependent. There's a further distinction, Latent typing, which is where types are associated with values rather than variables.

But a dynamic language can have types associated with variables, and it can forbid changing those types after their types have been checked the first time.

Re: Why F#?

#392

Post by aldanor »

dboreham wrote: post #336
kstrauser wrote: post #216

Earlier quoted context omitted.

I find Rust vastly simpler than C. If the code compiles, it's probably a valid expression of the business logic I encoded. I might've screwed up that logic, of course, and no language can prevent me from messing that up. I know! Many have tried, and I've defeated them with my ability to misrepresent my ideas! But at least with Rust, I'm reasonably confident that the code will actually do the thing I asked it to do. I…

This seems...a very contrarian sentiment. Imho while C might lead you to create slightly fragile code once in a while, Rust is something like two orders of magnitude more complex.

Rust is like two orders of magnitude more simple (if you're not going to delve into its darker corners).

You have a single line serialization into/from absolutely anything. You have logging, tracing, cli libraries, error handling - most of those are one liners.

You have enums. Enums are business logic. Enums are often the way the world works.

You press enter and it builds, no pre setups, sub modules, cmake files and whatnot.

Re: Why F#?

#393

Post by vips7L »

dkarl wrote: post #190
innocentoldguy wrote: post #148

Earlier quoted context omitted.

I think Clojure is the better option if you want to do FP using the JVM ecosystem. The problem (for me, anyway) I've run into with Scala is that it supports both functional programming and object-oriented programming. Every code base I've worked on in Scala has ended up being a hodgepodge of both, which I find annoying. However, the best functional programming language is, of course, Elixir. :D

> Every code base I've worked on in Scala has ended up being a hodgepodge of both Is there something about that that has bothered you? Working in Scala codebases, I've found the best ones to work in are the ones that embrace Scala's multiparadigm nature. When programmers try to solve every problem with OO, they end up adding more and more layers to get the job done. When programmers try to solve every problem with FP…

I really think this is where Kotlin is going to excel; multi-paradigm, multi-platform. Scala's community went too hard into FP and type-golfing to make it approachable.

Re: Why F#?

#394

Post by fire_lake »

Akronymus wrote: post #357
AnimalMuppet wrote: post #211

Earlier quoted context omitted.

> Static typing removes the downside of whitespace. How so? > Oh, and every language with line comments (so most of them) has significant whitespace. Technically true, but that's not what people mean by "significant whitespace" in this context. So you're being pedantic rather than saying anything meaningful. But you made me think. The ultimate nightmare would be significant trailing whitespace - the spaces and/or tab…

In f#'s case, there is the trifecta of everything being an expression, static typing and default immutability. This means you often write code like this: let foo = if bar then baz else someDefault Due to it being an expression you assign what the if evaluates to to foo. Due to static typing, the compiler checks that both branches return the same type. Due to the default immutability you don't declare and assign in se…

Pythons approach to variable declarations makes this doubly bad.

Re: Why F#?

#395

Post by sdsd »

shermantanktop wrote: post #111

> Trivia: F# is the language that made the pipeline operator (|>) popular. I’m not a dabbler in exotic languages, so this definition of “popular” was puzzling. I’ve literally never seen that operator before. Maybe I need to get out more.

I've used it in Racket, which is not exactly "popular" but common in universities as a teaching language. I actually built a fairly popular Tor hidden search engine in Racket nearly a decade ago, but I quickly shut it down when I ran some stats on the most common queries.

Re: Why F#?

#396

Post by Akronymus »

fire_lake wrote: post #394
Akronymus wrote: post #357

Earlier quoted context omitted.

In f#'s case, there is the trifecta of everything being an expression, static typing and default immutability. This means you often write code like this: let foo = if bar then baz else someDefault Due to it being an expression you assign what the if evaluates to to foo. Due to static typing, the compiler checks that both branches return the same type. Due to the default immutability you don't declare and assign in se…

Pythons approach to variable declarations makes this doubly bad.

Tbh, I've been successful enough in avoiding using python that I don't know the specifics of that.

Re: Why F#?

#397

Post by ddellacosta »

darksaints wrote: post #219

I'm completely convinced that F# (along with Scala, Haskell, and OCaml) adoption has stalled due to having ridiculously bad build systems. More significantly, they are being passed up in favor of Rust, which is a great language but nonetheless a bad fit for a lot of problem domains, simply because Rust has a superior build system. Hell, 80% of the reason I choose Rust over C++ for embedded work is because of the buil…

I don't really get this take, at least wrt Haskell--I know less about the others. I don't disagree that it's not ideal, but I still would compare the combination of nix+cabal in Haskell favorably with anything I've used in Python, JS, Ruby, Clojure...and other ecosystems I'm forgetting. Python and JS in particular I've always found absolutely miserable to work with when it comes to dealing with dependencies. So I don't believe that this is why folks aren't choosing Haskell (I think it has a lot more to do with how different it is from most people's programming language experience, and how so much of the documentation is aimed at non-beginners).

Re: Why F#?

#398

Post by shortrounddev2 »

cjbgkagh wrote: post #389
shortrounddev2 wrote: post #383

Earlier quoted context omitted.

> You're both complaining about extra keywords while trying to make the case of adding yet another one I did no such thing. async is already a keyword in F#, I'm just saying they should drop the brackets and remove the required return statement. > In language design there are always tradeoffs but I'm unable to see how your suggestions would improve the language in the general case or even in your specific case It wou…

'async' is not a keyword in F#, it's a builder instance no different to the ones that you can create. It's just built in to the standard library. The return statement is only required if you want to return something form the computation expression. In your example you use async { let! x = f(); return x}, which can be reduced to async { return! f()}, which can be reduced to f(). The rest is your opinion that I don't a…

The distinction in this case is utterly meaningless. This is about the ergonomics of the language. Which are lacking the minute to break out of pure functional land

Re: Why F#?

#399

Post by oriolid »

oblio wrote: post #314
throwaway2037 wrote: post #311

Earlier quoted context omitted.

> I'm completely convinced that F# (along with Scala, Haskell, and OCaml) adoption has stalled due to having ridiculously bad build systems. Scala? I am not trolling here: Are you joking? Scala is part of the Java ecosystem. Sure, Maven gets lots of hate on HN, but it is very mature and has excellent integration with IDEs and CI/CD systems (TeamCity, Jenkins, etc.). In the last 10 years, many Java developers have mov…

How long are Scala compilation times for a Hello World CLI, a Hello World basic webapp and for a reasonably sized production size code base? My guess is that it's much longer than for the equivalent Java apps. > What is wrong with CMake for C++? It doesn't manage dependencies.

CMake has fetch_content, and CPM is a package manager built on top of it. They are not great.

Re: Why F#?

#400

Post by cjbgkagh »

shortrounddev2 wrote: post #398
cjbgkagh wrote: post #389

Earlier quoted context omitted.

'async' is not a keyword in F#, it's a builder instance no different to the ones that you can create. It's just built in to the standard library. The return statement is only required if you want to return something form the computation expression. In your example you use async { let! x = f(); return x}, which can be reduced to async { return! f()}, which can be reduced to f(). The rest is your opinion that I don't a…

The distinction in this case is utterly meaningless. This is about the ergonomics of the language. Which are lacking the minute to break out of pure functional land

I disagree with both of your statements
Post reply on HN