Just "15 years" or Nothing
Are you saying they Maybe learned Haskell?
Either they have learned and Left the noob status, or they never really got it Right.
I learned Haskell in just 15 years
221–230 of 240 posts
Re: I learned Haskell in just 15 years
#222Earlier quoted context omitted.
> Yes - the value of functional programming isn't that working in OCAML, or F#, or Haskell is 10x as productive as other languages. This is not true in my personal experience. As has been famously said (paraphrased): Functional programming makes tough problems easy and easy problems tough. In other words the value of functional programming depends on your domain.
It’s only tough to change your way of thinking. Most people making the switch find it tough because they are trying to find imperative techniques to do something in a functional way and struggling because they can’t find an if else statement or a for loop. But if you were never taught to think in terms of conditional branching or looping indexes you’ll save a lot of time.
Exactly. I've long held the sentiment, that pure functional programming is easier than imperative programming. The only hard part, is switching from an imperative mindset.
Re: I learned Haskell in just 15 years
#223Earlier quoted context omitted.
I've been learning Unison [1] and I highly recommend. It's a Haskell-like language, but with some really interesting ideas around how code should be managed and distributed. They also use use algebraic effects (represented with "abilities" in Unison) instead of Monads, which gives some interesting advantages [2]. [1] https://www.unison-lang.org/ [2] https://www.unison-lang.org/docs/fundamentals/abilities/for-...
Have you written anything in Unison yet? To me Unison feels extremely ahead of its time. They clearly thought things through and aren't afraid to challenge the status quo. Maybe a bit too much ahead of its time even... I fear `ucm` a little. You mean I can't version my things with git? How do I... ehh, do anything? And how is the deployment story if one chooses not to use the Unison cloud?
To be honest, all I've done was try the weekly challenges that the Unison team publishes on Twitter :D
I just like the very light syntax that it got from Haskell, but without the need for Monads and the "ugly" monad operators you need to juggle, replaced by abilities which IMHO are much more elegant.
They are focusing on writing cloud-services and apparently their offering is already pretty good, so if I ever need a clouse service I am tempted to use Unison (for anything not very critical, at least until I gain confidence in it): https://www.unison.cloud/our-approach/
And I love ucm and think it may be very close to what the future will look like (which is why I do agree it's ahead of our time). It's already possible to work with Unison but still have proper code review: https://www.unison-lang.org/docs/tooling/project-workflows/#...
Here's an example change: https://share.unison-lang.org/@unison/base/contributions/42/...
But currently, I believe you do need to pull the branch locally and then load diffs with ucm into your favourite diff tool to properly see what's been changed (which is not ideal , and I believe they are working on making this easier, we'll see).
Re: I learned Haskell in just 15 years
#224Earlier quoted context omitted.
Even without laziness, you can get similar problems if f creates a closure or returns something that includes the parameter object.
Yeah, this is a common source of confusion with closures in Python. Example on Stack Overflow: https://stackoverflow.com/questions/233673/how-do-lexical-cl...
Doesn't that example also show a kind of laziness?
I say this because the second solution to that question offers the solution of using `i` as a default argument when defining the function. That forces its evaluation and fixes the problem.
Re: I learned Haskell in just 15 years
#225Earlier quoted context omitted.
Ok, you're probably proving the point that purity also requires immutability. I'm not sure, as I haven't considered all the implications of Haskell's design. My two rules about inputs and outputs are more like heuristics. They can improve code organisation and probably also decrease the likelihood of some errors, but they don't guarantee correctness, as you're pointing out. They're shortcuts, so they're not perfect.…
Even without laziness, you can get similar problems if f creates a closure or returns something that includes the parameter object.
Ok, the Wikipedia definition of pure function is more strict and than what I was saying and I think it covers the issues you mentioned:
Re: I learned Haskell in just 15 years
#226Earlier quoted context omitted.
Prolog is a logic programming language though, I wouldn't expect it to have a lot of overlap with functional programming?
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.
How would this work with the XOR operator? Would it give all possible inputs?
Re: I learned Haskell in just 15 years
#227Earlier quoted context omitted.
Yeah, this is a common source of confusion with closures in Python. Example on Stack Overflow: https://stackoverflow.com/questions/233673/how-do-lexical-cl...
Doesn't that example also show a kind of laziness? I say this because the second solution to that question offers the solution of using `i` as a default argument when defining the function. That forces its evaluation and fixes the problem.
It's just a name shadowing.
Copying the code they wrote:
for i in xrange(3):
def func(x, i=i): # the *value* of i is copied in func() environment
return x * i
flist.append(func)
It's not evaluating a thunk representing i, which is how lazy variables are evaluated in Haskell.
Re: I learned Haskell in just 15 years
#228Earlier quoted context omitted.
> I mean, how else would you call the arguments of > splitAt :: Eq a => a -> [a] -> [[a]] Those don't seem to be names of parameters, but rather of types. It's missing parameter names entirely. I spent a good 2 minutes looking at that signature trying to figure it out (and I've read some Haskell tutorials so I'm at least familiar with the syntax). This would've helped: def split_by (separator: T, list: List[T]) -> Li…
> Those don't seem to be names of parameters, but rather of types. It's missing parameter names entirely. The rest of the definition is at the end, to see it as a whole: splitAt :: Eq a => a -> [a] -> [[a]] splitAt x xs = ... To clarify, I assumed that by using the constraint `Eq a` and the name splitAt there was no need for extra clarification in the names of the parameters but apparently I was wrong.
No, you're right. It is perfectly clear from the type signature
Re: I learned Haskell in just 15 years
#229Earlier quoted context omitted.
Doesn't that example also show a kind of laziness? I say this because the second solution to that question offers the solution of using `i` as a default argument when defining the function. That forces its evaluation and fixes the problem.
It's just a name shadowing. Copying the code they wrote: for i in xrange(3): def func(x, i=i): # the *value* of i is copied in func() environment return x * i flist.append(func) That could also be written "def func(x, foo=i): return x * foo". It's just copying i's value to another variable. In the next line, i's value is still 1, 2, or 3, so when the function is called during the next line of the body of the loop, th…
Ok, I had a better look at the code and I realised that it doesn't follow the rule I was talking about, namely having the function only work on values it receives as inputs.
I think that's why I don't use closures, because they read values from the environment. Their only use case (that comes to mind) can be solved with partial application, which is safer.
Oh, and I wasn't using laziness in the Haskell sense, but more in the general sense of deferring evaluation.
Re: I learned Haskell in just 15 years
#230"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."
Are there any good resources you can share to learn this specific way of programming?