4 ms·
What kind of bad SQL? Most forms of bad SQL can be ruled out by a well typed DSL. JS silliness is also a type safety issue. You can use Fay, Elm, GHCJs or Roy
by Peaker 13y ago
What kind of bad SQL? Most forms of bad SQL can be ruled out by a well typed DSL. JS silliness is also a type safety issue. You can use Fay, Elm, GHCJs or Roy to generate Javascript from a type-safe language.
Some NPE's take just 10 minutes (not negligible) but there are also some that are expensive.
Figuring out the reason is sometimes hard, when the code and its assumptions are badly documented.
Fixing NPE's is sometimes hard because of silly reasons such as touching third party or "frozen" code.
Also, NPE's can become extremely difficult when the code is bad in the first place.
Things like rate limiting and queue lengths can be encoded in types. You can use type tagging on connection sources/destinations to make sure you only hook up things that match rates/etc.
- jbooth 13y agoMan, just when I thought we might agree on something. A DSL? SQL IS a freakin DSL. Why would I put another layer of abstraction between me and it? Just more places for things to go wrong. http://en.wikipedia.org/wiki/Inner-platform_effect http://en.wikipedia.org/wiki/Inner-platform_effect Anyways that particular problem yesterday wasn't a compilation problem, it was due to my own misunderstanding of some pre-existing data. You're proposing a more-complicated way of doing things with the idea that eventually we'll get to the promised land and things get simple again. I've just never seen it happen. Seen the opposite plenty of times.
- Peaker 13y agoSQL is a DSL indeed, but building SQL strings programmatically is an awful idea. You should build SQL queries structurally. The DSL to build SQL should basically be a mirror of the SQL DSL in the host language. The DSL will guarantee that you cannot build malformed queries. It can also give guarantees you design it to give. I'm not talking about replicating a database -- but just wrapping its API nicely in a type-safe manner. I am proposing wrapping type-unsafe APIs with type-safe API's. This adds complexity in the sense of enlarging the implementation. But it also adds safety and guarantees to all user code.