Comment Re:uh what (Score 1) 398
Yeppers, this guy is a shitbag. Most organic food hawkers are shitbags.
Yeppers, this guy is a shitbag. Most organic food hawkers are shitbags.
Because the rednecks would use them as target practice.
Hey, hold my beer!
No needs to âoefigure outâ how to do that. Anyone who builds DIY drones could do it without a second thought.
Petzold wrote a neat book called 'code' that spends a lot of time on telegraphs and how the relays they used became the transistors in modern computers.
No reason to have had hope Perl 6 works well. It may have come to late and thus is now an obscure language. But it works and is quite interesting and good.
I think the reason is the Perl community evolved out of multiple other communities who each brought with them distinctive styles. You had the shell people (system admins). You had the Sed/Awk people. You had C people. You had LISP people. Then starting with Perl 4 you picked up HTML/CSS people. Then you had the influence of early version of Javascript and VBScript. Finally starting with Perl5 you had the migration of C++/Java people. Perl allowed them all to keep writing the way they liked.
Seems to me that Perl6 has taken the whipuptitude that Perl originally did towards Bash/Sed/Awk and done it to Haskell / Clojure. You can fairly easily mix in self evaluating data structures while still being able to do a print statement. There are even more ways to do it
You are correct -- they don't give two shits about any party. They are just marketing towards the folks who will fall for this sort of thing.
So you honestly think that if I made you two bowls of whipped cream, one with your buzzword compliant HWC and the other with whatever crap I could get down at the poor people grocery store that you could actually tell the difference?
The average joe knows this one.
Ari Fleischer.
No idea if I spelled that right. I am a pretty average joe.
foldl in Erlang is tail recursive automatically. foldr is not by default tail recursive in Erlang, Though I should mention foldr is tail recursive in languages like Haskell, and there are implementations of foldr in terms of foldl and visa versa. The conversions between foldr & foldl (depending on which is tail recursive) make explicit what needs to be done to move from non-tail recursive to tail recursive for recursions. Yet another reason you want to use those.
And as for can't follow. Your claim was about the messiness that these imperative artifacts remained and were worse. To avoid the messiness, you have to use the looping structures of functional programming Doing functional programming imperatively, of course is going to be messy. Doing functional programming functionally and you get the benefits.
OK I gotcha. It is shockingly easy in lazy code to write algorithms that are quadratic in memory. Arguably that's one of the big advantages of using standard morphisms and not recursions.
I also agree it is often (very often) easier to write an explicit recursion; and only then if you have to create a morphism structure. That's a different claim though than with loops. Once the algorithm is written as a loop you have all the pieces for a standard design pattern using morphisms. Which was my point to grandparent. The classification of all possible recursions is coming along nicely but we still have about 50 types of morphisms that (at least in theory) can show up. In practice hylomorphism covers most cases for recursions, and how to do this can be non-obvious. But hylomorphism covers all cases, with simple transformations of for-loops. Having written a for-loop you have the structure you need to do the morphism transformation, its the same work. My point above was about the easy case, not the hard case of general recursion you are talking about.
As an aside, I believe (not an expert) the condition for a graph traversal to be hylomorphic is that the operations follow the distributive law. Assuming I'm right on this, that's not a whole lot of math you just check your operation and apply one of the standard graph traversals.
Here we disagree. I think the general way you program that sort of thing is via. a fold. I don't know Erlang but it has the classic folds:
foldl(Fun, Acc0, List) -> Acc1
foldr(Fun, Acc0, List) -> Acc1
Fun = fun((Elem
Acc0 = Acc1 = AccIn = AccOut = term()
List = [T]
T = term()
foldl is the preferred one for Erlang
I'm going to argue there are no special cases that don't fit.
Basically
the set of all possible for loops (no side effects) \subset the set of all possible hylomorphisms (generalizations of map reduce) \subset of all possible recursions.
That's why I wanted to see a real example, because of mathematically they can't exist.
As for accumulators over loops those can be usually handled via. a fold providing the reduction operation is associative. The initial and final state never present a problem.
___
I'll agree I was considering lazy part of functional. At this point I think purity allows for laziness and laziness demonstrates a lot of the advantages of purity. Otherwise you are backed to mixed paradigm which I dealt with other places in this thread. As for lazy with large amounts of data, Hadoop is lazy. So I'm not sure what you are saying.
I was treating (**) as your second case, ignoring the (**2) as a specific function. Remember the idea originally was to show a simple example of the concept for Python.
The game of life is a game of boomerangs. Our thoughts, deeds and words return to us sooner or later with astounding accuracy.