4 ms·

> how to do this common thing that I already did 100 times You don't do it 100 times - you do it once, test it thoroughly, and put it in a library.

medstrom 5y ago
Easy to say. Of course you do that when you can. What afflicts me is all the cases when the task is subtly different, with different requirements, but still feels like something I've done before.
- indigochill 5y ago
  At the code level, that's parameters in a library function. At the infrastructure level, currently my team is using Terraform templates. I feel like we will probably restructure that "soon" to be more about composing infrastructure out of common blocks rather than inheriting from an entire template, but either way, this does seem to be a solvable problem at the infrastructure layer as well. As you imply, it is significantly easier to say than to do effectively, but I've yet to see any situation where it -can't- be done (but I'm curious what one looks like if someone's run into this).
  - medstrom 5y ago
    Keeping in mind I'm a hobbyist, not a professional, but it seems to me much of coding boils down to this process of refactoring, spinning out libraries and restructuring to use Terraform or whatever, and at some point the process itself is what's repetitive.
  - cortesoft 5y ago
    > At the code level, that's parameters in a library function Sure, so you keep adding more parameters to the library function and then pretty soon you can’t remember all the parameters so you have to look them up every time you want to invoke it from your code… which is exactly the perfect use case for AI like this to help you remember the correct parameters to call.
    - ipaddr 5y ago
      AI can make you write horrible code if you ask it to. Don't keep adding parameters endlessly and use the AI to somehow make sense of it. But what you want is: Dependary injection.
    - JetSpiegel 5y ago
      It's turtles all the way down. Write another library with the original library as a dependency.
elcomet 5y ago
When you use libraries or frameworks, you often write the same or very similar lines.
- blunte 5y ago
  That to me is an indication of a need for an even higher level abstraction. At this point we should be able to go through a questionnaire, and software (not an AI, but definitely algorithm with rich knowledge and rules) would generate a quality starting system. $ I need an app Q1. do you need it to be available on the web? A1. yes Q2. do you need users with accounts? A2. yes Q3. do you want local passwords, and/or third party connections such as Github, Google, Facebook, etc.? A3. local and third party ... Qm. Do you have a programming language preference? [Ruby, Java, Python, ...] Am. Ruby Qn. Do you have a database preference? [MySQL, PostgreSQL, ...] An. PostgreSQL ... Add some theme options and other goodies, and you essentially have an app starter kit. Granted, you still have to know the technologies and plumbing since inevitably you'll need to change something that was preconfigured, but this would save a lot of time (and result in more consistent foundations across apps. Ultimately I hope this goes even higher level to no-code or nearly no-code solutions. It might mean fewer choices, but that can also be a good thing. I imagine a majority of all software needs can be met with just a few predefined configurations. Then you can decide if you want to change your needs to fit the easy solutions, or if it's really worth going custom.
  - ptx 5y ago
    Such starter kits exist, e.g. JHipster[1]. The problem is that after you've generated the starter code, this big heap of code (that you're not familiar with the details of) is now yours to maintain and upgrade. [1] https://www.jhipster.tech/ https://www.jhipster.tech/
    - blunte 5y ago
      Indeed. So the last mile is how to reconfigure after the fact. This has been a problem for a long time with builders. Perhaps one solution is to compartmentalize additional changes and configurations so they can be managed a bit easier while the foundation is updated. It’s not an easy problem to solve, but I think we might be better off if the great minds worked on this problem instead of the low level code AI.
twodave 5y ago
Not OP but I think the gist was more about solving the same/similar class of problem in a different context. You’re not going to build a library to abstract away certain things, for lots of good reasons. E.g. in OOP you may intentionally not use inheritance between a few similar (but distinct) business cases because of the overall maintenance burden/rigidness it would introduce. So you end up with more boilerplate, but your codebase is overall more flexible.

medstrom 5y ago

Easy to say. Of course you do that when you can. What afflicts me is all the cases when the task is subtly different, with different requirements, but still feels like something I've done before.

indigochill 5y ago
At the code level, that's parameters in a library function. At the infrastructure level, currently my team is using Terraform templates. I feel like we will probably restructure that "soon" to be more about composing infrastructure out of common blocks rather than inheriting from an entire template, but either way, this does seem to be a solvable problem at the infrastructure layer as well. As you imply, it is significantly easier to say than to do effectively, but I've yet to see any situation where it -can't- be done (but I'm curious what one looks like if someone's run into this).
- medstrom 5y ago
  Keeping in mind I'm a hobbyist, not a professional, but it seems to me much of coding boils down to this process of refactoring, spinning out libraries and restructuring to use Terraform or whatever, and at some point the process itself is what's repetitive.
- cortesoft 5y ago
  > At the code level, that's parameters in a library function Sure, so you keep adding more parameters to the library function and then pretty soon you can’t remember all the parameters so you have to look them up every time you want to invoke it from your code… which is exactly the perfect use case for AI like this to help you remember the correct parameters to call.
  - ipaddr 5y ago
    AI can make you write horrible code if you ask it to. Don't keep adding parameters endlessly and use the AI to somehow make sense of it. But what you want is: Dependary injection.
  - JetSpiegel 5y ago
    It's turtles all the way down. Write another library with the original library as a dependency.

elcomet 5y ago

When you use libraries or frameworks, you often write the same or very similar lines.

blunte 5y ago
That to me is an indication of a need for an even higher level abstraction. At this point we should be able to go through a questionnaire, and software (not an AI, but definitely algorithm with rich knowledge and rules) would generate a quality starting system. $ I need an app Q1. do you need it to be available on the web? A1. yes Q2. do you need users with accounts? A2. yes Q3. do you want local passwords, and/or third party connections such as Github, Google, Facebook, etc.? A3. local and third party ... Qm. Do you have a programming language preference? [Ruby, Java, Python, ...] Am. Ruby Qn. Do you have a database preference? [MySQL, PostgreSQL, ...] An. PostgreSQL ... Add some theme options and other goodies, and you essentially have an app starter kit. Granted, you still have to know the technologies and plumbing since inevitably you'll need to change something that was preconfigured, but this would save a lot of time (and result in more consistent foundations across apps. Ultimately I hope this goes even higher level to no-code or nearly no-code solutions. It might mean fewer choices, but that can also be a good thing. I imagine a majority of all software needs can be met with just a few predefined configurations. Then you can decide if you want to change your needs to fit the easy solutions, or if it's really worth going custom.
- ptx 5y ago
  Such starter kits exist, e.g. JHipster[1]. The problem is that after you've generated the starter code, this big heap of code (that you're not familiar with the details of) is now yours to maintain and upgrade. [1] https://www.jhipster.tech/ https://www.jhipster.tech/
  - blunte 5y ago
    Indeed. So the last mile is how to reconfigure after the fact. This has been a problem for a long time with builders. Perhaps one solution is to compartmentalize additional changes and configurations so they can be managed a bit easier while the foundation is updated. It’s not an easy problem to solve, but I think we might be better off if the great minds worked on this problem instead of the low level code AI.

twodave 5y ago

Not OP but I think the gist was more about solving the same/similar class of problem in a different context. You’re not going to build a library to abstract away certain things, for lots of good reasons. E.g. in OOP you may intentionally not use inheritance between a few similar (but distinct) business cases because of the overall maintenance burden/rigidness it would introduce. So you end up with more boilerplate, but your codebase is overall more flexible.