4 ms·

> You can be exceedingly clever with metaprogramming, but clever code is exceedingly hard to read and maintain. Give me boring, explicit code any day of the wee

• throwaway91111 9y ago
  I mean that's the point of tooling. Metaprogramming removes any advantage and IDE can give you to make sense of unknown code.
  • KirinDave 9y ago
    This is strictly false though. IDE integration can give insight into metaprogramming in many languages.
    • falcolas 9y ago
      Python, the language in question, does not easily offer this support, since all of the metaprogramming occurs at runtime. You have to run a debugger while creating the object to see what is actually happening. Lisps, C Preprocessor (within certain limits), and so forth are a bit different, since you can expand the macros without having to run the code itself. Does that indicate a strength of Python or a weakness? A complete value judgement there. In either case, metaprogramming in Python (and many other languages, even those with support for metaprogramming resolution in their IDEs) is still simply harder to understand and debug.
      • KirinDave 9y ago
        I feel no real problem shaming the entire design of Python as a long bet on failed premises. But other languages with similar properties can and do report their metaprogramming results to language servers.
        • throwaway91111 9y ago
          Agreed completely—this is the difference between metaprogramming and "black magic", which is familiar to any ruby programmer.
        • aoeusnth1 9y ago
          Yes, that explains why the language is failing.
  • kazinator 9y ago
    Even that IDE known as Vim + Ctags will jump to a "defmacro" definition if your cursor is on a macro call and you type Ctrl-] to chase a tag.
    • throwaway91111 9y ago
      This only works for metamagic identifiable macros. What if you refer to an identifier that doesn't exist anywhere in the code? What about ruby's method_missing? It's impossible to provide tooling for those cases without running the compilation or evaluating.
• falcolas 9y ago
  Well, I also commit the faux pas of recommending limiting external dependencies to the standard library in Python whenever possible, resulting in many fewer dependency issues than so many of my colleagues. So, while occasionally under specified, they are quite well supported and stable. I do miss out on the fun of sorting out the requests dependency chain with every release of my code, but I'm mostly OK with that.
• KirinDave 9y ago
  It's weird how people neg on some abstractions for Python but then brag about the absolutely intense degree of abstraction something like Tensorflow brings to the table. It's almost like the qualification is that the reader can't even imagine writing the abstraction and therefore they can ignore it.
  • ThrustVectoring 9y ago
    There's a huge difference between abstraction you have to write and debug yourself, and abstraction that you can use and debug through documentation and StackOverflow. Third-party resources are where it's at for taking advantage of things that require skills you don't have. I haven't written enough frameworks and abstract libraries to expertly debug, test, and write my own.
    • KirinDave 9y ago
      > There's a huge difference between abstraction you have to write and debug yourself, and abstraction that you can use and debug through documentation and StackOverflow. Indeed. You're more likely to be able to use and debug it if you wrote it yourself rather than relying on the weirdom of the crowd from SO. > I haven't written enough frameworks and abstract libraries to expertly debug, test, and write my own. I suspect you'd do just fine if you tried, assuming you don't try and displace django.
  • empthought 9y ago
    There is a material difference between syntactic abstraction and functional abstraction. It's analogous to the difference between someone learning to program a computer and someone learning to use a computer. The second is far easier to do and requires far less intellectual overhead. By the same token, if someone implements TensorFlow in a different language, there is little room for complaint assuming the same functional abstraction (and minimization of intellectual overhead) is present in that language's implementation.