3 ms·

If you find yourself in such a scenario, then you haven't reached the enlightenment level. Reaching for a "safe and familiar" procedural/imperative language is

If you find yourself in such a scenario, then you haven't reached the enlightenment level. Reaching for a "safe and familiar" procedural/imperative language is like most people reaching for a claw hammer when they wish to hammer and nail something in. To most people, it's the same, they are just hitting something. To a pro, they know when they reach for their claw hammer, a sledge hammer, a mallet, a ball pein, club hammer or cross and straight pein. If you have a text file that you just need to slice and dice. The tool to use is awk/sed/tr/cut, or perl. Got rules? prolog. Got massive array data? APL. Got multiple massive array data that you wish to combine and separate in various ways? SQL. Surely, you can use python for all those things. But should you?

dragonwriter 9y ago
> If you have a text file that you just need to slice and dice. The tool to use is awk/sed/tr/cut, or perl. Got rules? prolog. Got massive array data? APL. Got multiple massive array data that you wish to combine and separate in various ways? SQL. Surely, you can use python for all those things. But should you? Arguably, yes, most especially when several of them apply to the same process, rather than to separate pieces of data.
- allthesethings 9y ago
  Likewise, an argument can be made that developers should reach for Excel more often, because Excel is what the business world knows and uses. We have so many great, specialized tools. But the act of development often bifurcates into "problems that don't have to scale, or even present a great interface" and "problems that need extensive customization at every layer and support millions of users" and our stacks reflect that. So tooling choice is often more dependent on maximizing leverage while setting appropriate cutoff points for scalability - in almost all production scenarios you are better off simply to design the system down to the featureset of available off-the-shelf tooling and anticipate a hard break where it migrates upwards, versus thinking you have to boil the oceans immediately so that all facets can be transitioned smoothly and all features are possible right now.
  - coding123 9y ago
    I'll definitely agree there - especially for admin interfaces. I'm so sick of developers creating extremely rich admin interfaces that use insane amounts or REST services to save and load settings that can really just be an Excel file in the git repo that is loaded by a library. I've seen companies that build $40,000 worth of admin interfaces that ended up being used by a temp to populate some back-end settings. The temp that was hired was probably paid $3000 to do the work, and now the admin interface is going to be retired.

dragonwriter 9y ago

> If you have a text file that you just need to slice and dice. The tool to use is awk/sed/tr/cut, or perl. Got rules? prolog. Got massive array data? APL. Got multiple massive array data that you wish to combine and separate in various ways? SQL. Surely, you can use python for all those things. But should you? Arguably, yes, most especially when several of them apply to the same process, rather than to separate pieces of data.

allthesethings 9y ago
Likewise, an argument can be made that developers should reach for Excel more often, because Excel is what the business world knows and uses. We have so many great, specialized tools. But the act of development often bifurcates into "problems that don't have to scale, or even present a great interface" and "problems that need extensive customization at every layer and support millions of users" and our stacks reflect that. So tooling choice is often more dependent on maximizing leverage while setting appropriate cutoff points for scalability - in almost all production scenarios you are better off simply to design the system down to the featureset of available off-the-shelf tooling and anticipate a hard break where it migrates upwards, versus thinking you have to boil the oceans immediately so that all facets can be transitioned smoothly and all features are possible right now.
- coding123 9y ago
  I'll definitely agree there - especially for admin interfaces. I'm so sick of developers creating extremely rich admin interfaces that use insane amounts or REST services to save and load settings that can really just be an Excel file in the git repo that is loaded by a library. I've seen companies that build $40,000 worth of admin interfaces that ended up being used by a temp to populate some back-end settings. The temp that was hired was probably paid $3000 to do the work, and now the admin interface is going to be retired.