181–190 of 240 posts
Earlier quoted context omitted.
I feel like functional programming is pretty trivial. It's pure programming that is very difficult. They're often conflated because Haskell is pure and functional and probably the most talked about heavily functional language. I certainly didn't know that impure functional languages like OCaml existed for ages.
Is Haskell pure? It has exceptions You can divide by zero It has unsafe IO primitives
Exceptions aren't impure anyway.
Cute. All kidding aside, though, functional programming is worth the effort to learn, and it doesn't actually take 15 years. The payoff is at the end of the article: "It’s quite natural to program in Haskell by building a declarative model of your domain data, writing pure functions over that data, and interacting with the real world at the program’s boundaries. That’s my favorite way to work, Haskell or not." Haskel…
I would recommend neither of those. Haskell has very bad syntax (with extensive backing from Microsoft, iirc the guy who writes the compiler is a Microsoft's Research employee). F# is a straight-up Microsoft's language. It doesn't matter what other benefits it has. Just don't touch anything created by that company, and you will have one fewer regrets in your life. But, if you still want a language from that category:…
Earlier quoted context omitted.
Pandoc seems useful, but maybe "mass market" is a bit of an overstatement? And since many programmers like myself had to learn Haskell, I think Haskell should have a better head start and be in a better position, if it would be so useful for "real world" use cases. But please don't take this as an attack on haskell. I have nothing against the language, or its users and I did not suffered because of it in university,…
I am not a user of the language (although I learned it like you). I just came to chime in that (a) there is at least one very popular software written in Haskell and (b) Haskell seems to ship a good amount of software for its popularity. Haskell never got the “killer framework” like Rails or Spark that allowed to become more mainstream, even if it was teached in Universities all over the world.
There’s also scotty and servant for web server stuff.
There’s Esqueleto and Persistent for doing postgreSQL database queries.
And so on.
I adore these sentences.:)When I read it,it feels like I met myself.
Earlier quoted context omitted.
So, another definition of a pure function is that, for a particular input it will always return the same output. Your example respects the rule: f({x=1}) == 1 f({x=2}) == 2 But it's true that the two rules I gave are not enough to make a function pure. Because I didn't say anything about I/O. So, a function that follows the rules about inputs and outputs, could still do I/O and change its outputs based on that. Start…
> Your example respects the rule: Every definition of purity I can find that talks about objects/references says that if you pass in the same object/reference with different contents then that's not pure. Your version differs from mine on that aspect. It passes two unrelated objects. > Starting from the question that gave birth to this whole thread: "What's the benefit of learning a PURE functional programming langua…
I now believe that learning a language like Haskell (or Elm or PureScript) forces you to see your program as pipes that you fuse together.
It's not just functions. Haskell has only expressions and declarations. That means, for example, that you are forced to provide an `else`, when you use `if`. The idea is that you have to keep the data flowing. If a function doesn't provide a meaningful value (so it returns nil, None), you have to handle that explicitly.
And, btw
> Your version differs from mine on that aspect. It passes two unrelated objects.
Those two objects are not unrelated. They have the exact same structure (an attribute named "x"). So they could be considered two values of the same type.
Earlier quoted context omitted.
SPJ has left MSR and is now at Epic games, working on a new PL. However, even while he was at MSR, MS didn't really have a say in how Haskell was developed.
Well, MS didn't have to do anything. It's enough that they have (or had) the opportunity to do something. There isn't an Overmind in MS that in a creepy voice tells you to spawn more overlords. Less than that, there doesn't need to be a written document that tells you to give money to MS or your data etc. There's just a general accepted understanding among the people who run that company that ends justify the means.…
Earlier quoted context omitted.
> Your example respects the rule: Every definition of purity I can find that talks about objects/references says that if you pass in the same object/reference with different contents then that's not pure. Your version differs from mine on that aspect. It passes two unrelated objects. > Starting from the question that gave birth to this whole thread: "What's the benefit of learning a PURE functional programming langua…
I gave it some more thought. I now believe that learning a language like Haskell (or Elm or PureScript) forces you to see your program as pipes that you fuse together. It's not just functions. Haskell has only expressions and declarations. That means, for example, that you are forced to provide an `else`, when you use `if`. The idea is that you have to keep the data flowing. If a function doesn't provide a meaningful…
define f(o): return o.x
let a = {x=1}
n = f(a) // n is not evaluated yet
a.x = 2
m = f(a)
return n + m // returns 4Earlier quoted context omitted.
An execution pipeline in a functional language is just half a relation in Prolog. Prolog allows you to also run it 'backwards', you can provide the output and have it figure out what the inputs would need to be.
Run in backwards, so they say, but not really. Most things you'll write can't run backwards. You have to write them in a special way for that to be possible, and even then what it means is that you can do a depth first search to find the value. There are some useful extensions like clpfd and asp but really if what you're doing is solving a constraint programming problem, you're much better of with OR-tools or MiniZin…
I kind of feel that clpfd, clpz and so on are just libraries, in what way do you consider them extensions to the language?
For me it's a neat way to model problems, and when I have I've commonly learned something new about the problem domain. Performance might not be great, interoperability and FFI might not be great, but as a tool for thought I really think it is.
Earlier quoted context omitted.
The problem with Haskell is that it's slow and memory-heavy (and OCaml is the same, but worse). F# and Scala (and Clojure?) are pretty much the only reasonably usable FP languages.
Where are you getting your info from? Typical OCaml programs, when compared to similar C++ would be slower but use less memory. F# and Scala are both OCaml in disuse. I don't know what you mean by "reasonable"... but, if the idea is "easy to reason about", then these two don't particularly stand out much. Languages that are easy to reason about would be generally in the category where you need to do fewer translation…
This is a very interesting definition of "easy to reason about".
To me, "easy to reason about" means that it's easy for me to figure out what the intent of the code is, and how likely it is that the code does what it was intended to do.
How it translates to the machine is irrelevant.
Now, if you work in an environment where getting the most out of the machine is crucial, then I understand. In my domain, though, dealing with things like allocating and freeing memory makes it harder to see what the code is supposed to do. As a human, I don't think about which memory to store where and when that memory should be forgotten, I just act on memories.
Functional languages, then, tend to be high level enough to not expose you to the workings of the machine, which let's me focus on what I actually want to do.