https://github.com/andreas-gone-wild/snackis/blob/master/sna...
548 karma · joined September 2, 2014
https://github.com/andreas-gone-wild/snackis/blob/master/sna...
But then I grew tired of waiting and just did it already :)
Ah well, at least it serves as a warning sign for budding language composers as myself. Snabel did full threading before it walked or talked:
https://github.com/andreas-gone-wild/snackis/blob/master/sna...
And to any Pythoneers with sore toes out there: pick a better language or learn to live with it, down-voting me will do nothing to solve your problems. It's a tool, we're supposed to pick the best one for the job; not decide on one for life and defend it to death. Imagine what could happen if language communities started working together rather than competing. There is no price to be won, we're all being taken for a ride.
When doing Forth-style languages for example; I've found that it's not very helpful to parse to trees, since I can't tell the structure of function calls before seeing the actual running stack anyway. Which in turn affects the compiler, since all it has to work with is a sequential stream of tokens.
And not all languages are stand-alone, or compile all the way down to machine code. Compiling to byte-code for running immediately, with the backup of a runtime library; is an attractive option for more specialized languages; and this means that it's possible to carry more information straight over from compilation to runtime.
I've been working on a scripting language that raised some of these questions lately:
https://github.com/andreas-gone-wild/snackis/blob/master/sna...
https://github.com/andreas-gone-wild/snackis
Whatever you do, opt out before it's too late...
Event Kent Beck admits skipping tests when he feels like it, no big deal.
I hereby confess; I don't give a shit about icons, worship and obedience; I am creating.
It's about time we started considering other, more constructive ways of cleaning up our collective mess.
For your collection example, at some point you need to introduce some kind of polymorphism to get back to concrete types; but once you're back, overloading works just fine again. The best strategy to recover types depends too much on specifics to be formalized.
The more you give, the more you get; might not be awesome profits, might be even better. The secret with giving is to not expect anything in return, the very definition of Karma Yoga; real Yogis practice that all the time.
There's nothing wrong with you, we're being carefully programmed to reason just like this; to mistrust and compete with everyone but our fabulous authorities. Cut down on the mainstream media and social networking if you want the power over your mind back.
An ORM is a simplification; it offers a single, convenient, but ultimately limiting perspective with most complexity swept under the rug. Anyone who's actually tried migrating between different databases or spent a week or so chasing down nasty coherency/performance-problems in their chosen framework knows what I'm talking about.
A more constructive approach that's rarely taken is providing storage/indexing as first class abstractions within the language to build your storage logic on top of.
Embedding raw SQL in a piece of software makes it much harder to reason about and maintain. Since storage/indexing are often fundamental, they deserve a more sophisticated interface than simply passing written notes back and forth on cocktail napkins.
Lately, I've been implementing my own, special purpose storage/indexing (https://github.com/andreas-gone-wild/snackis/tree/master/src...) to cut down on the complexity and get a tighter fit with the application.