But anyway no point in this. Python can match the terseness of JavaScript.
The only reason my implementation was long was because I used types and recursion. Python can have the same terseness as your old style untyped javascript if needed:
remember the reduce function can be built out of recursion. What you see in JS is just a convenience function for reduce, if a language has recursion, reduce can easily be built in one line.
def reduce(f, xs, x):
return x if len(xs) == 0 else reduce(f, xs[1:], f(xs[0], x))
Thus reduce isn't really a "feature".
Python is superior to JS for FP because it can match the expressiveness of JS while adding the additional feature of exhaustive pattern matching and list comprehensions, which JS or TS can't do. This makes JS explicitly inferior.
Recursion in Python suffers from limited utility due to the lack of TCO and the strict (but adjustable) recursion depth limit. JS, for all its problems, at least includes TCO these days. Shame Python has decided to stay on the worse path there.
You're seriously misinformed. All of what you're saying is categorically false on all counts and exhibits fundamental misunderstanding about the topic at hand. You are not just wrong from one perspective, you are wrong from every possible valid perspective conceivable.
First of all the discussion at hand is not the language implementation, the discussion at hand is about the language specification. TCO is a implementation feature, whether the engine/compiler/interpreter implements said feature is irrelevant to the conversation which is about the specification NOT the implementation. So on this count you are wrong. More accurately off topic.
Second there are several python interpreters. The most popular is CPython. CPython does not include TCO deliberately because Guido specified he wanted stack traces at all times for easier debugging. However PYPY which uses a JIT does use TCO. Stackless python another interpreter by it's very name also does something very similar to TCO. So additionally you are completely wrong again from this angle.
Third there are two popular JavaScript engines in use by browsers and nodejs today. V8 and spider monkey. Spider monkey Does not implement TCO. V8 Did implement TCO for a small amount of time, however, this was later removed due to complexities when debugging practical issues. Thus V8/Spidermonkey and therefore Nodejs and Chrome and Firefox do NOT support TCO. Edge supported TCO with chakra but after a shift to V8 edge also no longer supports TCO. So on this count you are wrong again.
Overall to sum up everything here, you are just wrong, wrong, wrong.
The statement still stands, as a language specification python is more superior feature-wise for FP then JS or TS.
> First of all the discussion at hand is not the language implementation, the discussion at hand is about the language specification. TCO is a implementation feature, whether the engine/compiler/interpreter implements said feature is irrelevant to the conversation which is about the specification NOT the implementation. So on this count you are wrong. More accurately off topic.
But anyway no point in this. Python can match the terseness of JavaScript.
The only reason my implementation was long was because I used types and recursion. Python can have the same terseness as your old style untyped javascript if needed:
remember the reduce function can be built out of recursion. What you see in JS is just a convenience function for reduce, if a language has recursion, reduce can easily be built in one line. Thus reduce isn't really a "feature".Python is superior to JS for FP because it can match the expressiveness of JS while adding the additional feature of exhaustive pattern matching and list comprehensions, which JS or TS can't do. This makes JS explicitly inferior.