magic_lobster_party

  • 0 Posts
  • 91 Comments
Joined 9 months ago
cake
Cake day: August 15th, 2024

help-circle



  • It wasn’t just this though; the tool itself lacks the intent, context, and limitations of what we’re doing. It doesn’t have other aspects of the project, influences, references, or personal experiences in the back of its mind, because it doesn’t have a mind.

    This describes the fundamental problem with AI. The chatbot will forever be like that new recruit to the team. Sure, they have the skills to make some contributions, but they lack the surrounding context to fully work autonomously. They need some guidance to get to the right path.

    The difference between the chatbot and the new recruit is that the chatbot won’t remember all the guidances it got. The chatbot won’t remember all the design decisions that were made. The chatbot won’t remember that time prod went down. The chatbot will forever be like the new recruit with no experience.





  • From a maintainability point of view consistency is important. I’d rather work with an consistent but incorrect code, than correct bit inconsistent code. With a consistent code base it’s easier to do something about the incorrectness, especially if it’s consistently incorrect. It’s also easier to delegate the work.

    Code is rarely correct forever. Sooner or later, requirements will change. What once was thought to be correct is no longer correct. It’s difficult to do anything about it if the code is inconsistent as well. It requires a lot of mental effort to understand the thought process behind some code.

    I agree that correctness is the goal, but consistency is one of the best ways to ensure this goal.






  • Waterfall only works if the programmer knows what the client needs. Usually it goes like:

    • Client has a need
    • Client describes what they think they need to a salesperson
    • Salesperson describes to the product manager what an amazing deal they just made
    • Product manager panics and tries to quickly specify the product they think sales just sold
    • Developers write the program they think product manager is describing
    • The program doesn’t think. It just does whatever buggy mess the programmer just wrote
    • The client is disappointed, because the program doesn’t solve their needs

  • They’re overlapping concepts, and can be used interchangeably. Sometimes a library can be all of them at the same time. In simple terms:

    • API is the interface to the library.
    • Library is code that is shared.
    • Package is how it’s distributed.
    • Framework is the methodology the library is used.

    Not all APIs are libraries. For example, all websites have some interface to interact with them. A website is not a library.

    Not all libraries are packages. A library don’t need to be distributed through a package manager.

    Framework is a bit blurry where the line is drawn. I think if the library is used in such way that your entire program revolves around it, then it’s a framework. If you’re just using it a handful of times, then it’s not a framework.

    React and Angular are frameworks in this regard. If you use them, then your entire programming is revolving around them. Any decision made is in regard to these frameworks.

    I would say OpenGL is API, library and framework. Maybe also package depending on how it’s distributed.