Live data from Hacker News

I thought I understood recursion

functional.christmas

81–90 of 124 posts

Re: I thought I understood recursion

#81
This was such a nice read! I've only ever written Java & JavaScript really, and Haskell is always at the top of the list of things I want to learn!

When I got to the 7 line snippet at the end I was blown away by the elegance, and the fact that I couldn't really understand exactly what each thing did. So I decided to spend a few hours going through it character by character and documented my process here [1] in case it was useful to anyone else.

I'll continue by reading a book on Haskell, but open to any advice from anyone on good ways to get into it!

[1] https://aurbano.eu/note/2019-12-18-journey-into-haskell/

Re: I thought I understood recursion

#83

Earlier quoted context omitted.

I'm not sure that holds up. Real people working at real companies are writing real code in Haskell every day. I found several job postings in London that advertised Haskell as a requirement / nice to have. Haskell is also taught and used extensively at my alma matter, and is in fact the first language you will be introduced to at a CS/SE degree. How is that in any way, shape, or form comparable to Brainfuck?!

When was the last time you installed and/or ran a Haskell program? If the answer is more recent then "never", then what was it? It's possible that Haskell is like COBOL in that it's used in industry but not at all by the community. But I'm not sure how I would characterize it, then. Does industry use count as "practical"? I honestly don't know. Anyway, examples would be nice.

I installed and used Pandoc the other week, and you've likely used it without knowing it (e.g. via web backends) if you don't use it directly. I also use it for Elm (i.e. the Elm compiler) almost every day.

Re: I thought I understood recursion

#84
post #62
post #7

> My background is in OO programming, mostly using C#. C# being the versatile language it is, I have had the perception that whatever you do in other programming languages, you can with a little more code and hassle achieve in C# as well. If need be, I can program C# using a functional paradigm. And, of course I use recursion all the time. I know all there is to know about recursion. IME there are two kinds of progra…

In the end, it is all machine code. All that recursion, lazy evaluation, monads, lambdas, virtual methods and coroutines. In the end, they are all stack manipulation and jump instructions. High level languages are just a more convenient way of writing assembly. I like to take that approach when comparing languages. What a program might do in term of machine instructions, and see how I can make another language output…

>In the end, it is all machine code. All that recursion, lazy evaluation, monads, lambdas, virtual methods and coroutines. In the end, they are all stack manipulation and jump instructions. High level languages are just a more convenient way of writing assembly.

Well, in the end the universe dies in the heat death stage, and nothing matters.

But we're not "in the end", so this final analysis "it's all machine code anyway" is reductionistic.

It might be all machine code, but the abstraction at which we think and program matters, for the correctness, speed of writing, speed of understanding it later, and performance of the deliverable...

Re: I thought I understood recursion

#85
post #10

Earlier quoted context omitted.

It's not obvious to me why choosing the right tool for the job is better than choosing the right job for the tool.

Don't know if you're serious, but for the most devs, the job is chosen for, not by, you

Isn't that a slave mindset? You weren't born prebound to a specific job.

Most devs (heck, most workers in any industry), can try and look for appropriate jobs.

Re: I thought I understood recursion

#86
post #25
post #10

Earlier quoted context omitted.

It's not obvious to me why choosing the right tool for the job is better than choosing the right job for the tool.

Might it be easier to switch tools than jobs for most people?

This brings to mind the joke with the drunk looking for his car keys under a street light. A guy tries to help him, and after searching in vain for a while, asks him:

"Are you sure you lost them here?"

"No, I'm pretty sure I've dropped then somewhere in the other side of the parking lot",

"So why are we looking for them here?"

"Because there's more light here which makes it easier to search!"

So, what's easier is not always what best. E.g. it doesn't mean sticking to the job rather than the preferred tool is the optimal path to expertise, career success, or personal development.

Re: I thought I understood recursion

#87
post #81

This was such a nice read! I've only ever written Java & JavaScript really, and Haskell is always at the top of the list of things I want to learn! When I got to the 7 line snippet at the end I was blown away by the elegance, and the fact that I couldn't really understand exactly what each thing did. So I decided to spend a few hours going through it character by character and documented my process here [1] in case i…

Fun blog post! I know nothing about Haskell as well.

Quite casual, just what I needed. Thanks for writing it up!

One blogging tip (note: the rest was perfect): if you would've chopped the following in 2 or 3 lines, then the casual style would be perfect.

> primes n = take n $ sieve [2..] where sieve (p:xs) = p : sieve [x | x 0] sieve [] = []

I feel that it'd be really hard to do though.

Re: I thought I understood recursion

#88
post #85

Earlier quoted context omitted.

Don't know if you're serious, but for the most devs, the job is chosen for, not by, you

Isn't that a slave mindset? You weren't born prebound to a specific job. Most devs (heck, most workers in any industry), can try and look for appropriate jobs.

Sure, you can, but its usually not desirable to jump ship the moment a task comes along that is less suitable to your tools of choice.

I often find myself using languages I’d rather not (yaml for ansible/docker-compose or shell scripts are common). Or maybe you love everything else about the job, besides the language you must use. Or you love everything and the language, but now you’re asked to complete a task that’s not really suited to the language. Ir maybe you love everything about your job and then are asked to fix something in a legacy project.

Re: I thought I understood recursion

#89
post #81

This was such a nice read! I've only ever written Java & JavaScript really, and Haskell is always at the top of the list of things I want to learn! When I got to the 7 line snippet at the end I was blown away by the elegance, and the fact that I couldn't really understand exactly what each thing did. So I decided to spend a few hours going through it character by character and documented my process here [1] in case i…

Fun blog post! I know nothing about Haskell as well. Quite casual, just what I needed. Thanks for writing it up! One blogging tip (note: the rest was perfect): if you would've chopped the following in 2 or 3 lines, then the casual style would be perfect. > primes n = take n $ sieve [2..] where sieve (p:xs) = p : sieve [x | x 0] sieve [] = [] I feel that it'd be really hard to do though.

Thanks! And good idea, I just updated it breaking that down a bit more :)

Re: I thought I understood recursion

#90
post #44

C# equivalent: IEnumerable filter(int p, IEnumerable xs) { foreach(var j in xs) if (j % p > 0) yield return j; } IEnumerable sieve(IEnumerable s) { var p = s.First(); yield return p; foreach(var e in sieve(filter(p,s.Skip(1)))) yield return e; } var n = sieve(Enumerable.Range(2, 10000)).Skip(10).First();

Less readable in my opinion and I'm more used to C# code than Haskell.
Post reply on HN