Live data from Hacker News

I thought I understood recursion

functional.christmas

51–60 of 124 posts

Re: I thought I understood recursion

#51
post #32
post #25

Earlier quoted context omitted.

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

That has not been my experience. In a C# shop, if you want to do something not-C#, best is to switch employers. I don't say that placing such high value just into what tool you use is smart; but changing tools in a company is often a total no-go.

Yes totally that.

I have been told many times in the last 20 years that the only thing that gets used comes from Microsoft. Literally the same shops end up with several piles of unmaintained crap which is either "not invented here" stuff, abandoned microsoft frameworks and all the staff have left to go find another job because it's not shiny any more.

Also a bad outcome.

Re: I thought I understood recursion

#52
post #31

Earlier quoted context omitted.

Saying a language makes you "miserable" does not forcibly mean you literally want to kill yourself because of it. I can totally see myself having more or less fun executing the exact same programming job, depending on the language I'm asked to used. And yes, to some extent, some projects (especially the ones where you have to start from an old codebase in a deprecated and ancient language) make me "miserable". That d…

I agree. I used to be a C++ programmer. I was good at it. I could do advanced template magic. I understood multiple inheritance and used it correctly, for the right purpose. I literally had dreams in C++. Then I started using Java, and realised that I could be 5x as productive with far fewer headaches chasing down yet another linker error with some unintelligible error message. What do you mean __malloc is undefined!…

traitor

Re: I thought I understood recursion

#53

Earlier quoted context omitted.

The first rule of recursion is we do not talk about recursion. The second rule of recursion is we do not talk about recursion. The third rule of recursion is without a base case, you have no recursion. The fourth rule of recursion is it breaks you in two or more pieces.

The fifth rule of recursion is that it is not really recursion if it isn't tail-call optimised.

So a recursive tree search is not really recursive?

Re: I thought I understood recursion

#54
I was thinking about this recently: is there ever a reason to put recursion in an everyday “workman” code base?

Seems like it would be so out of place in a real industry code base, like a infinite loop waiting to happen. There are always better more readable and maintainable ways to accomplish the same thing.

Re: I thought I understood recursion

#55
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…

So if you consider some stack to be inferior (maybe because its highly inconsistent in its design or it only runs on closed and locked down platforms or whatever) you still should just dismiss it as 'oh its just a tool' instead of accepting that it's shitty and makes you miserable when working with it? Why wouldn't I want to work with best thing ever if it helps me keep my sanity every day? Do you want to use somethi…

It's not that simple.

First you can't always choose the stack you work with. You work with other people, who may have expertise in different languages. You may have to reuse existing code written in different languages. And it's rarely the case that some stack is better than another on every aspects, there is usually some form of compromises to be made.

Re: I thought I understood recursion

#56
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?

I think it is easier, but I don't think that is important or the right question. We live in a world that evolves and problems (Jobs) change all the time. It is to everyone's best interest to teach themselves new tools both to stay relevant and also to find interesting new problems to solve. So yes we need to change from the mindset of religious worship of a certain tool by only searching problems that tool can solve to researching the best tool for the problem we need to solve and learning it if necessary.

Re: I thought I understood recursion

#57
post #38

Earlier quoted context omitted.

I think an analogy would be the following: You need to hammer a nail in a piece of wood. You could do this with a screwdriver but hammer is better suited for the job. However, a hammer made out of glass is less useful than the screwdriver. In other words, some kinds of tools are better suited for a problem than others, but there exist tools that inferior even though they were designed to solve your original problem .…

I take your point, but can we avoid this analogy please? Let’s talk about actual code if we’re going to talk about the best tool for a job that requires it. It reminds me of something early in my career that irked me like few work-related things things have: “Building software is like building a house” — No, it isn’t. Not even a little bit.

I think it is more like growing a garden.

Re: I thought I understood recursion

#58
post #51
post #32

Earlier quoted context omitted.

That has not been my experience. In a C# shop, if you want to do something not-C#, best is to switch employers. I don't say that placing such high value just into what tool you use is smart; but changing tools in a company is often a total no-go.

Yes totally that. I have been told many times in the last 20 years that the only thing that gets used comes from Microsoft. Literally the same shops end up with several piles of unmaintained crap which is either "not invented here" stuff, abandoned microsoft frameworks and all the staff have left to go find another job because it's not shiny any more. Also a bad outcome.

Behind the enterprise tooling propaganda, there is the real programming endeavor with whatever tools are appropriate for the tasks (given the constraints of time, team size, developer expertise, maturity of libraries, etc.)

A software development business is not really about programming languages, libraries, or tools, but about the game of power in the organization (even when the end user doesn't care how the product was developed). Anything that threatens that power is easily dismissed.

Re: I thought I understood recursion

#59
post #57
post #38

Earlier quoted context omitted.

I take your point, but can we avoid this analogy please? Let’s talk about actual code if we’re going to talk about the best tool for a job that requires it. It reminds me of something early in my career that irked me like few work-related things things have: “Building software is like building a house” — No, it isn’t. Not even a little bit.

I think it is more like growing a garden.

I prefer making the distributed club sandwich analogy ...

Re: I thought I understood recursion

#60
Here's my code golf attempt in C#.

    public static List Sieve(int n)
    {
        bool[] arr = Enumerable.Range(0, n).Select(i => true).ToArray();

        Enumerable
            .Range(2, (int) Math.Sqrt(n) - 2)
            .ToList()
            .ForEach(i => { if (arr[i]) Enumerable.Range(0, (n - (i * i)) / i).ToList().ForEach(j => arr[j * i + (i * i)] = false); });
    
        return arr.Select((b, i) => b ? i : 0).Where(i => i > 0).ToList();
    }
Post reply on HN