4 ms·

The no-code people imagine that we are on the verge of living in a world where that catalog's equivalent in software is just a few months away. If they were ri

by dsr_ 5y ago

The no-code people imagine that we are on the verge of living in a world where that catalog's equivalent in software is just a few months away. If they were right, it still wouldn't solve the problem analysis problem, but it would certainly help out the parts problem. It would also help move software into a professional engineering phase.

BiteCode_dev 5y ago
Well, they are going to be disapointed when they'll realize we haven't even figured out the catalog yet. Software is half a century old, we are still using flint to produce it. The only reason it looks fancy is because it makes more sparks, and a lot faster.
- Verdex 5y ago
  We're just starting to get out of the alchemy stage right now. Wise men and magicians everywhere telling royalty that if they only pay them treasures that they will reveal the future and show them miracles. Meanwhile it turns out that NSS has a straight-forward vulnerability that everyone just somehow missed. If you look at the history of chemistry, mechanical engineering, or astronomy then you kind of get the impression that we're probably 150-300 years away from software development working the way everyone already imagines it working.
  - BiteCode_dev 5y ago
    I swear my lord, this Python oil will do miracles with your data ailments.
    - ineedasername 5y ago
      Lord: I doth smeared mine data with thine Python and lo, it persists in having holes and errors even unto duplicates. Guards! Execute this man!
  - htrp 5y ago
    You remind me of a quote I heard at a conference (paraphrased badly). The Data Revolution is like going from the bronze age to the iron age. It will get industrialized eventually, but that time frame will take much longer and will look completely different from what you expect.
  - antod 5y ago
    > If you look at the history of chemistry, mechanical engineering, or astronomy then you kind of get the impression that we're probably 150-300 years away from software development working the way everyone already imagines it working. If it is to happen, a serious plateauing of "progress" will need to happen all the way up the layers of the tech stack to the point where app developers or data engineers are now working with tools stable enough that previous generations would at least recognise let alone even be able to work with. Engineering maturity "nirvana" for software will happen not by us getting more experienced/better at it, but by "progress" stalling in all the tools we use. Software changes a lot basically because it is easy to change. And because we as an industry value constant work towards making it even easier to keep changing - eg cloud, containers, devops, agile etc etc In the physical world, things have stabilised and reached a kind of local optimum across the vast majority of areas. Sure there are still incremental improvements happening, and occasional revolutionary improvements in different areas. Mostly the main bits being radically changed are the bits that coincidentally touch computers downstream from the constant churn happening to software. Also another factor is when I think of physical engineering (and I used to work in civil/structural engineering in the 90s), for nearly all work going on, the scale of the problems being solved hasn't changed. Most building sites are the same size they were, most materials are the same, some regulations have changed, but ubiquitous CAD tools etc seems to be the major change. So maybe, when we can't make transistors smaller, and we can't make cpus faster, and can't increase memory or storage things will slow down. eg as each layer up the stack plateaus, each layer above it eventually changes from working on new capabilities to making what it already does more efficient, that will eventually (it will take a while) bubble all the way up. Progress slows down a lot and us end developers and engineers are working on a stable set of tools very much in a local (or even global) optimum. Also maybe when/if the worlds population stabilises (in decades/centuries/whenever), that might lead to an eventual limit on how much user data can be mined from people and the scale of the data we deal with might stabilise too even beyond the limit reached where we've stopped collecting more because of capacity limits talked about above. Heh, I started off trying to disagree with your quoted statement by saying I don't think it would ever stabilise like other disciplines. But by laying out one way it could happen, I think I may have ended up agreeing with you :)
  - rini17 5y ago
    I believe we miss solid common ontology - an agreement what individual pieces of data mean. Then individual pieces of software are either incompatible or inconsistent and must be constantly built anew, resulting in all kinds of bugs.
  - ineedasername 5y ago
    Heck, chemistry is practically a baby compared to the 1,000+ years of engineering
Verdex 5y ago
I've got a phrase for when I see people trying to "abstract" over certain types of problems by writing absurdly complicated code that ultimately saves negative time. "Data abstraction is impossible." You can abstract an algorithm. Like, how you sort. Merge sort, bubble sort, etc. Normally it doesn't matter to the rest of the code, you just want a sorted list. You can abstract a type or an object. Hey, given some type T and some function T -> int, you can get an int. You CAN'T abstract a chunk of data which has semantically distinct members inside of it. If someone sends you a structure that has a field in it called "name", then you have no idea what that actually means. You have to get them to tell you what they mean by "name". The hard part being that inevitably "name" means one thing unless the "aux" field is set to a number that evenly divides the "misc" field at which point "name" has to be filtered by some arcane rules. This is why we have lists like "falsehoods programmers believe about time|names|etc". Time means different things for different applications. Names mean different things to different contexts and cultures. You have to find someone to tell you what all of the individual pieces of the object's internals means to them. no-code will probably see some success in niche domains where things have been fixed for years. Ultimately, many applications will need hand written code to handle all of the meaningful sub-components of the data being interacted with.
- closeparen 5y ago
  On the other hand some of the most powerful and widely used programs are those that operate on byte arrays with schemas in-band (the web) or otherwise specified at runtime (SQL). Imagine if you needed to write C structs in Nginx or Postgres corresponding to all the business objects and data types they’re going to touch. Worse, imagine you need to thread them through all the implementation! Many business applications are written that way. I think there are opportunities on the table to stop doing it.
  - Verdex 5y ago
    So. There's json parsers, serde, row polymorphism, anon structs, macros, monads, and dictionaries. They all do the same type of thing, but that isn't abstracting data. That's abstracting the population of data or the serializing of it. However none of that is ever going to know that the name field needs to strip out the first three characters, rot 13, and then parse as a guid. Someone still needs to know what the data you're getting means. And there's no way to shake that. Although people do try and then we get lists like: things programmers don't understand about names.
xwolfi 5y ago
Yeah when most people end up working cutting hair, driving cars, carrying bricks and so on... I feel this is going to remain a pipe dream to replace the people copy pasting stack overflow in creative ways (productive developers) any time soon.
post-it 5y ago
That catalog is here, in the form of libraries. What no-code people miss is that by the time a piece of functionality is available as a no-code widget, it's been available as a library for years. No-code solutions will never replace developers. They instead free up developer time, allowing them to create more niche or more technically challenging things. Wix and other website builders have completely replaced developers who make static HTML pages, but those developers have moved on to making more complex things with React and canvas and WebSockets. Business requirements grow to match these advances. Twenty years ago, an independent store was ahead of its time if it had a website. Today, a store without online shopping - or at least an online catalog with stock information - is at risk. No-code solutions will never be enough, because competitors will use no-code and also pay developers to code better functionality.

by dsr_ 5y ago

BiteCode_dev 5y ago

Well, they are going to be disapointed when they'll realize we haven't even figured out the catalog yet. Software is half a century old, we are still using flint to produce it. The only reason it looks fancy is because it makes more sparks, and a lot faster.

Verdex 5y ago
We're just starting to get out of the alchemy stage right now. Wise men and magicians everywhere telling royalty that if they only pay them treasures that they will reveal the future and show them miracles. Meanwhile it turns out that NSS has a straight-forward vulnerability that everyone just somehow missed. If you look at the history of chemistry, mechanical engineering, or astronomy then you kind of get the impression that we're probably 150-300 years away from software development working the way everyone already imagines it working.
- BiteCode_dev 5y ago
  I swear my lord, this Python oil will do miracles with your data ailments.
  - ineedasername 5y ago
    Lord: I doth smeared mine data with thine Python and lo, it persists in having holes and errors even unto duplicates. Guards! Execute this man!
- htrp 5y ago
  You remind me of a quote I heard at a conference (paraphrased badly). The Data Revolution is like going from the bronze age to the iron age. It will get industrialized eventually, but that time frame will take much longer and will look completely different from what you expect.
- antod 5y ago
  > If you look at the history of chemistry, mechanical engineering, or astronomy then you kind of get the impression that we're probably 150-300 years away from software development working the way everyone already imagines it working. If it is to happen, a serious plateauing of "progress" will need to happen all the way up the layers of the tech stack to the point where app developers or data engineers are now working with tools stable enough that previous generations would at least recognise let alone even be able to work with. Engineering maturity "nirvana" for software will happen not by us getting more experienced/better at it, but by "progress" stalling in all the tools we use. Software changes a lot basically because it is easy to change. And because we as an industry value constant work towards making it even easier to keep changing - eg cloud, containers, devops, agile etc etc In the physical world, things have stabilised and reached a kind of local optimum across the vast majority of areas. Sure there are still incremental improvements happening, and occasional revolutionary improvements in different areas. Mostly the main bits being radically changed are the bits that coincidentally touch computers downstream from the constant churn happening to software. Also another factor is when I think of physical engineering (and I used to work in civil/structural engineering in the 90s), for nearly all work going on, the scale of the problems being solved hasn't changed. Most building sites are the same size they were, most materials are the same, some regulations have changed, but ubiquitous CAD tools etc seems to be the major change. So maybe, when we can't make transistors smaller, and we can't make cpus faster, and can't increase memory or storage things will slow down. eg as each layer up the stack plateaus, each layer above it eventually changes from working on new capabilities to making what it already does more efficient, that will eventually (it will take a while) bubble all the way up. Progress slows down a lot and us end developers and engineers are working on a stable set of tools very much in a local (or even global) optimum. Also maybe when/if the worlds population stabilises (in decades/centuries/whenever), that might lead to an eventual limit on how much user data can be mined from people and the scale of the data we deal with might stabilise too even beyond the limit reached where we've stopped collecting more because of capacity limits talked about above. Heh, I started off trying to disagree with your quoted statement by saying I don't think it would ever stabilise like other disciplines. But by laying out one way it could happen, I think I may have ended up agreeing with you :)
- rini17 5y ago
  I believe we miss solid common ontology - an agreement what individual pieces of data mean. Then individual pieces of software are either incompatible or inconsistent and must be constantly built anew, resulting in all kinds of bugs.
- ineedasername 5y ago
  Heck, chemistry is practically a baby compared to the 1,000+ years of engineering

Verdex 5y ago

I've got a phrase for when I see people trying to "abstract" over certain types of problems by writing absurdly complicated code that ultimately saves negative time. "Data abstraction is impossible." You can abstract an algorithm. Like, how you sort. Merge sort, bubble sort, etc. Normally it doesn't matter to the rest of the code, you just want a sorted list. You can abstract a type or an object. Hey, given some type T and some function T -> int, you can get an int. You CAN'T abstract a chunk of data which has semantically distinct members inside of it. If someone sends you a structure that has a field in it called "name", then you have no idea what that actually means. You have to get them to tell you what they mean by "name". The hard part being that inevitably "name" means one thing unless the "aux" field is set to a number that evenly divides the "misc" field at which point "name" has to be filtered by some arcane rules. This is why we have lists like "falsehoods programmers believe about time|names|etc". Time means different things for different applications. Names mean different things to different contexts and cultures. You have to find someone to tell you what all of the individual pieces of the object's internals means to them. no-code will probably see some success in niche domains where things have been fixed for years. Ultimately, many applications will need hand written code to handle all of the meaningful sub-components of the data being interacted with.

closeparen 5y ago
On the other hand some of the most powerful and widely used programs are those that operate on byte arrays with schemas in-band (the web) or otherwise specified at runtime (SQL). Imagine if you needed to write C structs in Nginx or Postgres corresponding to all the business objects and data types they’re going to touch. Worse, imagine you need to thread them through all the implementation! Many business applications are written that way. I think there are opportunities on the table to stop doing it.
- Verdex 5y ago
  So. There's json parsers, serde, row polymorphism, anon structs, macros, monads, and dictionaries. They all do the same type of thing, but that isn't abstracting data. That's abstracting the population of data or the serializing of it. However none of that is ever going to know that the name field needs to strip out the first three characters, rot 13, and then parse as a guid. Someone still needs to know what the data you're getting means. And there's no way to shake that. Although people do try and then we get lists like: things programmers don't understand about names.

xwolfi 5y ago

Yeah when most people end up working cutting hair, driving cars, carrying bricks and so on... I feel this is going to remain a pipe dream to replace the people copy pasting stack overflow in creative ways (productive developers) any time soon.

post-it 5y ago

That catalog is here, in the form of libraries. What no-code people miss is that by the time a piece of functionality is available as a no-code widget, it's been available as a library for years. No-code solutions will never replace developers. They instead free up developer time, allowing them to create more niche or more technically challenging things. Wix and other website builders have completely replaced developers who make static HTML pages, but those developers have moved on to making more complex things with React and canvas and WebSockets. Business requirements grow to match these advances. Twenty years ago, an independent store was ahead of its time if it had a website. Today, a store without online shopping - or at least an online catalog with stock information - is at risk. No-code solutions will never be enough, because competitors will use no-code and also pay developers to code better functionality.