I always thought of 1+N as a thing that you just keep in your head, catch on code reviews or via performance regressions. This worked well for a long time, however, the less control we have over our SQL queries the more likely it will sneak through those guards.
(This is second part of my PiterPy talk adaptation, first part is available here)
Python gives us deep introspecting and metaprogramming capabilities including bytecode and AST support in the standard library. This facilitates unobvious ways to write code that writes code or otherwise alters its behavior. I will show several different examples of how it could be used for fun and profit.
You probably heard something like how React is awesome ‘cause it makes UI a pure function of application state? But even before you started to get that it was complemented with something like how that works on top of immutability and virtual DOM? And then you get free save, load, undo and something insane called time-travel debugging on top of that. Guess what? None of these are necessary to use core React idea and reap its benefits. And I’ll show that in a few lines in jQuery.
Every language needs to grow. It needs to evolve. However, there is a certain barrier it builds around itself over time called “Backward compatibility”. Backward compatibility means you can’t just change the thing in a best way possible, you need to comply to older design decisions, coincidences and even bugs.
So what should conscious designer do?
Cache invalidation is probably one of the hardest things in computer programming. I understand it as finding a subtle compromise between completeness, redundancy and complexity. I would like to tap into this topic in a context of caching queries built via ORM.
Decorators are joy to use. Write? Not so much. One needs to mess with wrappers, function metadata and a fair amount of bookkeeping. Enough things to bury any useful semantics under them. There got to be a better way.
Let’s find that out.
There are a lot of buzz about Haskell, Lisp, Erlang and other languages few people code in. But while they play their role as banners, functional programming sneaks into our code in multi-paradigm languages.
I was going to continue this way and later introduce my library of a variety of functional tricks, but suddenly realized it’s not about FP, it’s about utility. And that’s what I will focus on below trying to show you real-life value of funcy.
Any programmer, even if she doesn’t see it this way, constantly creates abstractions. The most common things we abstract are calculations (caught into functions) or behavior (procedures and classes), but there are other recurring patterns in our work, especially in error handling, resource management and optimizations.
Those recurring patterns usually involve rules like “close everything you open”, “free resources then pass error farther”, “if that succeeded go on else …”, which commonly look like repetitive
if ... else or
try ... catch code. How about abstracting all that control flow?