Great post! Thanks for sharing. "If YAML was rough for infrastructure, imagine how bad it is at business logic?" had me laughing. The combination of CloudFormation deployment times and the .$s etc can be really tedious.
One thing that's scary for me with abstractions like this is what if an edge case isn't supported? With the raw language you know you have the full set of features. And the edge cases might not be that rare. What do you do when (if?) you hit that bump?
I'm not sure if I'm understanding your question properly, so if my answer sounds like nonsense please help me out :)
Part of the reason we want SPR's is to enjoy the benefit of abstractions, but yeah, it's always scary to embrace a new abstraction (or set of them) because we know we are giving up control, and potentially the ability to account for edge cases.
I like Swyx's comparison to programming languages. We used to have to manage memory ourselves, but now we have garbage-collected languages that abstract away the burden for us. Yeah, we lose some control, and even some efficiency, but in the end, we finally embrace the productivity and safety (and security, sometimes) of the abstraction and accept the minor performance tradeoffs.
Those tradeoffs then become some else's optimization problem (which is probably best!). Someone over on the C# team gets to be the one to optimize garbage collection to be smarter, and I don't have to do it.
Back to SPR's -- I think the key to successful abstractions will be to provide reasonable, overridable, defaults. An SPR won't be successful (or even usable, in some cases) if it doesn't provide a mechanism to peel back a layer and make some fine adjustments and/or some extensibility model that allows for custom abstractions to cover specialized use cases.
Meanwhile, having provided developers with the tools to do what they need to do, whomever is responsible for developing the SPR becomes responsible for making the abstractions smarter, thereby gradually reducing the need for "special" code to customize the behavior of the available abstractions.
In a future post I want to explore the ideal characteristics of an SPR and how it would address concerns like this one. I'd be happy to hear any other thoughts you have on the topic, including other potential "bumps" that an SPR might face.
The comparison with programming languages is good. Abstractions like that are exactly what I would be looking for in an SPR.
I came to think of another comparison. It might not make sense. What if instead of creating a higher level programming language, we are creating an ORM but for the cloud? Going into this I should say that I am not a big fan of ORMs. Day 1 the productivity gained is great. Fast forward a couple of years and you have slow queries you don't know how where they come from. Maybe you should have spent some time reading, learning SQL, and modeling instead.
As I said I'm not sure if this comparison makes sense, or if it's a fair one to make. Anyway this is something I would look out for in a SPR.
I haven't thought of comparing it to an ORM, but I think that's a fair comparison of one abstraction tool to another.
While ORM's may not always output an optimized query, they usually do provide some mechanism for hinting (like Entity Framework's .Include()). I think abstraction tools that offer that productivity boost but still provide a hinting/customization/override mechanism are the least risky to adopt.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Great post! Thanks for sharing. "If YAML was rough for infrastructure, imagine how bad it is at business logic?" had me laughing. The combination of CloudFormation deployment times and the .$s etc can be really tedious.
One thing that's scary for me with abstractions like this is what if an edge case isn't supported? With the raw language you know you have the full set of features. And the edge cases might not be that rare. What do you do when (if?) you hit that bump?
Hi Daniel, thanks for sharing your thoughts!
I'm not sure if I'm understanding your question properly, so if my answer sounds like nonsense please help me out :)
Part of the reason we want SPR's is to enjoy the benefit of abstractions, but yeah, it's always scary to embrace a new abstraction (or set of them) because we know we are giving up control, and potentially the ability to account for edge cases.
I like Swyx's comparison to programming languages. We used to have to manage memory ourselves, but now we have garbage-collected languages that abstract away the burden for us. Yeah, we lose some control, and even some efficiency, but in the end, we finally embrace the productivity and safety (and security, sometimes) of the abstraction and accept the minor performance tradeoffs.
Those tradeoffs then become some else's optimization problem (which is probably best!). Someone over on the C# team gets to be the one to optimize garbage collection to be smarter, and I don't have to do it.
Back to SPR's -- I think the key to successful abstractions will be to provide reasonable, overridable, defaults. An SPR won't be successful (or even usable, in some cases) if it doesn't provide a mechanism to peel back a layer and make some fine adjustments and/or some extensibility model that allows for custom abstractions to cover specialized use cases.
Meanwhile, having provided developers with the tools to do what they need to do, whomever is responsible for developing the SPR becomes responsible for making the abstractions smarter, thereby gradually reducing the need for "special" code to customize the behavior of the available abstractions.
In a future post I want to explore the ideal characteristics of an SPR and how it would address concerns like this one. I'd be happy to hear any other thoughts you have on the topic, including other potential "bumps" that an SPR might face.
Hello again!
The comparison with programming languages is good. Abstractions like that are exactly what I would be looking for in an SPR.
I came to think of another comparison. It might not make sense. What if instead of creating a higher level programming language, we are creating an ORM but for the cloud? Going into this I should say that I am not a big fan of ORMs. Day 1 the productivity gained is great. Fast forward a couple of years and you have slow queries you don't know how where they come from. Maybe you should have spent some time reading, learning SQL, and modeling instead.
As I said I'm not sure if this comparison makes sense, or if it's a fair one to make. Anyway this is something I would look out for in a SPR.
I haven't thought of comparing it to an ORM, but I think that's a fair comparison of one abstraction tool to another.
While ORM's may not always output an optimized query, they usually do provide some mechanism for hinting (like Entity Framework's
.Include()). I think abstraction tools that offer that productivity boost but still provide a hinting/customization/override mechanism are the least risky to adopt.