I agree SQL is an interesting analogy but I draw the opposite conclusion, if I correctly remember what I did ~5 years ago.
There is an eval-ish way of using SQL, such as forming SQL code out of strings. This tends to perform slower and is extremely vulnerable to injection and other unexpected behavior. However you can also make stored procedures with explicit arguments. Not only is this safer, it usually performs better because the query execution plan can be precompiled (IIRC). As for 3, using a domain specific language can be helpful. Especially a "declarative" one: "Here's the data I want, you figure out exactly how to get it." (Even though real-world performant SQL maybe isn't 100% "declarative", that approach still works better than any ad hoc database engine I'd create :), and it's a useful division of labor.) -- You received this message because you are subscribed to the Google Groups "Racket Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
