The whole article seems to be nothing but a transport vehicle for that ad. Spyware for even more editors.
Huh... that's weird
Something unexpected occurred. We'll investigate what happened
Refresh the page
Anyway, Python actually support limited functional programming so I only get it for that topic :-)
Edit: After scanning the kite.com article for a second time, I see the author actually links to Mary Rose Cook's article.
Sadly I would not be shocked if they managed to gather additional funding.
Otherwise if I'm accustomed to Python but feel the need of something functional and scheme/lisp are too hard well... I go for Nim...
Python is FANTASTIC as a simple language to tech programming these days and to glue stuff together, with the benefit of a respectful standard library but frankly if we go beyond we have other options perhaps with some sharp corners (less easy to code, less complete standard library, less documented etc).
That seems counter to my experience and understanding of things. Python has adequate support for functional programming. And bonus you can mix in some object oriented things as well.
What I think it captures well, though, is an unfortunate habit among many dynamic languages' communities to pretend that types don't matter. Python is getting better, but it used to be really bad about this. The standard library's documentation, for example, would give only the names of a function's parameters, and leave it to you to figure out, presumably by guess and check (and prayer), what kind of input it was prepared to accept. It's still really common for the documentation to force you to go to the REPL to ask a function's return value what its type is.
I've been looking at how other languages handle this, and I think typeclass / trait systems seem to strike a good balance, allowing flexibility without surprises.
If you do get surprised that X doesn't support Y, though, you have ability to provide your own implementation without resorting to monkey patching.
Strongly typed? Maybe you mean statically typed?
From "What To Know Before Debating Type Systems":
"Probably the most common way type systems are classified is "strong" or "weak." This is unfortunate, since these words have nearly no meaning at all..."
 - http://blog.steveklabnik.com/posts/2010-07-17-what-to-know-b...
- Use pure functions
- Avoid mutability
- Limit use of classes
- Strive for idempotency
- Use lambdas and higher order functions sparingly, only when they actually simplify the code
- Use generators where applicable
All in all, it's good advice which shouldn't be ignored just because she works at kite.
She should probably go back and proof read the article and fix the code and terminology errors, though.
Using first-class functions is great but I hesitate to call any serious use of Python "functional programming".
That said, I do agree that you probably shouldn't go crazy with FP in Python. At its core, it's a procedural language. It has some useful things from OO and FP, but you'll be more comfortable if you keep procedural techniques in the top tray of your toolbox.
Which isn't all that bad a thing. IMO, well-done modern procedural programming looks a lot like functional programming with more loops and less recursion.
That being said, I agree, there's nothing wrong with taking aspects that you like (first-class functions mainly) without having to be a purist. In fact, imo purely functional languages are tedious compared to procedural languages like Python.
I'd like to find a procedural language that allows for side effects (it is still procedural programming, after all), but encourages keeping them under control. I've been toying with Nim lately, and it's been a good experience. I think that it's possible to do even better, but it's already way ahead of anything else I've tried.
FP is great at the high-level for orchestrating workflows and in the lower-level processing/transforming/aggregating over streams of immutable records. OOP is great at the high-level for independent communicating services/life-cycles and fine-tuned memory bound algorithms and needing state machines lower down.
You generally know what parts of your code mutate and what don't well enough to get the nice side-effect free usage from your functional parts.
Someone smarter than me once said: OOP? FP? It's really all just about being principled about state. A closure is just an object with one function.
I’m not saying it’s bad to add FP bits to other languages. I just haven’t seen the same benefits as when I know what a called library/module can and can’t do with my data.