11–20 of 55 posts
- Strings are not names. Names help tooling, strings make tooling harder.
- A function which takes a string to switch on where behavior radically differs between cases is an anti-pattern.
- Imports should be explicit and well organized, not magic and scattered throughout the code.
What's the target audience? Looks convenient for notebook/repl style use (assuming the the editing environment still supports autocomplete/correct and other niceties). I might just be stodgy and change averse, but I'd be a bit less willing to try things like this in production. Landing page or FAQ could possibly benefit from an explanation along these lines.
Hi friend, Yes, do not try this in production yet. Currently, this library works only on Repl.it for the exact reason. This is why you see the headline with "an attempt". :)
With the mass migration of Python developers into Go, this is the last thing that Python needs.
Think of it like lego blocks for your next tech-toys and hopefully (in the future) for your next big-thing ^_^.
If you love tinkering with new toys then give it a try with Repl.it: https://dev.to/t/functorflow.
If you want to meet cool kids like you then join our club at Discord by subscribing to our email-list.
...and follow updates at https://twitter.com/functorflow
Together, we will re-imagine and re-invent how Python apps should be developed.
Lemme know what you think!
Have fun!
- Sam
Absolutely terrible. I can see why data science types who use / produce a lot of (typically throwaway) Python code might be enamored with this, but as far as the Python language goes, functorflow will be another nail in its coffin if it ever gains mass-acceptance. It will turn the already messy and inconsistent ecosystem into shambles that no sane person will want to build anything robust on top of. With the mass mig…
Please don't give these functions simple names like "f". I often use these names as generic function names locally. I know I can use "import ... as" but doing so shouldn't be necessary and will result in everybody using different names, which will hurt consistency, readability and searchability of code.
Absolutely terrible. I can see why data science types who use / produce a lot of (typically throwaway) Python code might be enamored with this, but as far as the Python language goes, functorflow will be another nail in its coffin if it ever gains mass-acceptance. It will turn the already messy and inconsistent ecosystem into shambles that no sane person will want to build anything robust on top of. With the mass mig…
1. What's the difference between this and just packaging a function as a pip package? The only one I see is just shaving off a few seconds and one less command.
2. Where is the code running from for each plugin? Eval'ing random code just seems like a bad idea. You can argue that it's the same as blindly installing a pip package, but this apparently happens each time on runtime and I see no option to check the code beforehand.
3. f and ff are pretty bad function names. I see what you're doing, but why?
4. Dep management issues aren't as common as you think they are.
5. Lots of these plugins are already in the standard library. XML to JSON is already possible quite trivially with a pip package. Not only that, but this seems like a less flexible version of that - and more obscure. (how to map xml to json?)
I'm giving this a hard pass for me, but looking forward to seeing my doubts cleared. Cheers.
Hi HN! Meet FunctorFlow ^_^ Think of it like lego blocks for your next tech-toys and hopefully (in the future) for your next big-thing ^_^. If you love tinkering with new toys then give it a try with Repl.it: https://dev.to/t/functorflow . If you want to meet cool kids like you then join our club at Discord by subscribing to our email-list. ...and follow updates at https://twitter.com/functorflow Together, we will re…
It's not until I get to the twitter account that I see that it looks like you're trying to create not just a different python package manager, but a new ecosystem that's not backwards compatible. I don't think this is a good idea. The Python package ecosystem is gigantic and one of the largest, most mature language ecosystems out there. If you're trying to make the way Python apps are developed better, try taking a look at alternate Python package managers like `pipenv`, `poetry` and `anaconda` and figure out what you like and dislike about them. Try making changes to them before you reinvent the wheel.
As it stands right now, this isn't even a wheel. It's an uninspired marketing page on twitter that is not doing a great job of convincing anyone it's better than the alternatives. In fact, it's not even clear that you're even aware of the alternatives.
Absolutely terrible. I can see why data science types who use / produce a lot of (typically throwaway) Python code might be enamored with this, but as far as the Python language goes, functorflow will be another nail in its coffin if it ever gains mass-acceptance. It will turn the already messy and inconsistent ecosystem into shambles that no sane person will want to build anything robust on top of. With the mass mig…
I mean, data science is really the thing that people should be using Python for.
Then the language itself offers trivial iteration, possibly in real time with tools like jupyter, and requires substantially less bootstrapping knowledge than something like C/C++, which creates a low barrier of entry for non-programmers, who are less likely to shoot themselves in their feet with memory management and such. And if you're concerned about performance, most of the standard data science packages are just wrapped C/C++ anyway.
Sure, it's not perfect, but it's practically the lingua franca of data science right now, and it fits the role quite well.