101–110 of 124 posts
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();
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.
Earlier quoted context omitted.
Maybe you should look within yourself and fix up whatever part of your personality is making you miserable? I'm not being flippant. Programming languages don't make people miserable. There isn't really an argument, just an observation that the most efficient way of thinking about programming is in data structures and algorithms which are mostly language independent. Nobody should be spending most of their time levera…
> Programming languages don't make people miserable. Try coding in MUMPS then saying that again. Or Intercal. Or Whitespace.
Earlier quoted context omitted.
Lets extend this analogy to books: all books are just letters and words writen on a page. And some pictures too. It doesn’t matter how a book is written as long as it produces letters, words and paragraphs and pictures. It doesn’t sound right, does it?
That's not a fair extension of the analogy. An equivalent analogy would be that you can use any text editor or word processor to write a book.
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.
In practice, it is far more important to allow your team to function when you eventually leave. Otherwise, they'll just throw your code away. Fortunately, a lot of code is thrown-away. So maybe it doesn't matter. In this particular instance, I knew my C++ code was basically a throwaway script (and Python, the other language that my fellow coworkers use, was too slow to get the job done).
But if you ever create something that truly matters and needs long-term maintenance (which I have), it better be written in a way that the team can maintain that code. Writing it in the language your coworkers speak (that the managers are hiring / interviewing for, etc. etc) is very important.
Earlier quoted context omitted.
clearly O(n^2) for time. Well, perhaps O(n^2/log n) or something, but that is not much different. The thing is, every prime p gets passed through a filter that filters multiples of primes p' for all p' < p.
> The thing is, every prime p gets passed through a filter that filters multiples of primes p' for all p' But the filter for multiples of 3 only sees the values that weren't already filtered by 2. So if we have N filters we don't evaluate all N filters for each value. The 2 is applied to everything, the 3 filter is only applied to things that are not multiples of 2, the 5 filter is only applied to things that aren't…
Earlier quoted context omitted.
clearly O(n^2) for time. Well, perhaps O(n^2/log n) or something, but that is not much different. The thing is, every prime p gets passed through a filter that filters multiples of primes p' for all p' < p.
> The thing is, every prime p gets passed through a filter that filters multiples of primes p' for all p' But the filter for multiples of 3 only sees the values that weren't already filtered by 2. So if we have N filters we don't evaluate all N filters for each value. The 2 is applied to everything, the 3 filter is only applied to things that are not multiples of 2, the 5 filter is only applied to things that aren't…
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();
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.
Rather than `state := null; while condition do: mutate-state-and-recompute-condition`, you can do `let loop(state) = if shouldContinue(condition) then loop(newState) else resultOfTheLoop`. Rely on the tail-call optimiser to compile this to a genuine imperative loop.
This looks very odd the first few times you see it, but it's much harder to get wrong.
It’s the Sieve of Eratosthenes. Probably someone has written it in C#. Here is a python version. https://www.google.com/amp/s/www.geeksforgeeks.org/python-pr...
This is not the Sieve (despite its name). For just one reason, the Sieve does not ever require testing divisibility.