4 ms·

in programming, a good abstraction is kind of like automation. programming is automation, and creating abstraction is automation of programming. (on the stupide

in programming, a good abstraction is kind of like automation. programming is automation, and creating abstraction is automation of programming. (on the stupidest level, think C++ templates). if all programming is automation, automation of programming is still programming. (there’s no real difference between a program that will automatically write program out of my specifications, and a DSL). so programming is the fixed point of automation, kinda like exponent is the fixed point of differentiation in reality it works in a negative way. programmers hunt for un-automated stuff to automate. it’s like the state violence, that hunts for other kinds of violence. if you destroy all non-state violence, you end up with a lot of state violence to constantly perpetuate. if you automate all that is not automated, the only not-automated activity will be the activity of automation (programming)

geoduck14 5y ago
>programmers hunt for un-automated stuff to automate Yup. This is pretty much how I describe my work to my wife. I find hard things and make them simple (using computers) - that makes "impossible things" hard, and inturn (eventually), I will make those things simple
petra 5y ago
That last line isn't true . There may be things that are too difficult or expensive to automate, so they won't be automated. Also if software development tools reach high enough levels, it may be that domain experts, or business analysts will do the development, and not software engineers.
- ethbr0 5y ago
  The missing component in parent's description is the imperfectness of abstraction. A good abstraction, written for and suited to the task at hand, adds little complexity. Reusing a previous abstraction, written for a slightly different purpose, incurs some complexity. Having to use an abstraction, inappropriate for the purpose, incurs substantial complexity. This results in three outcomes respectively: (1) increased productivity, (2) stable productivity, (3) decreased productivity. Most of programming, in my experience, has been figuring out which one of those roads you're on, and when to eat the cost of switching to another.
- valyagolev 5y ago
  quite often the under-automated things are not "higher-level", but the missed details about the lower levels. think of all of the random bugs
deleted 5y ago
[deleted]

geoduck14 5y ago

>programmers hunt for un-automated stuff to automate Yup. This is pretty much how I describe my work to my wife. I find hard things and make them simple (using computers) - that makes "impossible things" hard, and inturn (eventually), I will make those things simple

petra 5y ago

That last line isn't true . There may be things that are too difficult or expensive to automate, so they won't be automated. Also if software development tools reach high enough levels, it may be that domain experts, or business analysts will do the development, and not software engineers.

ethbr0 5y ago
The missing component in parent's description is the imperfectness of abstraction. A good abstraction, written for and suited to the task at hand, adds little complexity. Reusing a previous abstraction, written for a slightly different purpose, incurs some complexity. Having to use an abstraction, inappropriate for the purpose, incurs substantial complexity. This results in three outcomes respectively: (1) increased productivity, (2) stable productivity, (3) decreased productivity. Most of programming, in my experience, has been figuring out which one of those roads you're on, and when to eat the cost of switching to another.
valyagolev 5y ago
quite often the under-automated things are not "higher-level", but the missed details about the lower levels. think of all of the random bugs

deleted 5y ago

[deleted]