I had done something slightly different. I would ask LLM to prepare a design doc, not code, and iterate on that doc before I ask them to start coding. That seems to have worked a little better as it’s less likely to go rogue.
143 karma · joined January 7, 2018
Technically, you don't need to keep that in your head :-) The general approach is to define generic functions and also write docs about how to extend those functions to satisfy interface requirements.
Perhaps not too surprisingly, many of the Julia community people also want to have some official interface support directly from the language. Before that, several open-source projects were spawned to address that gap e.g. here is a shameless plug about my package:
This story resonates with many people here because many experienced engineers had done something similar before. For me, destructive batch operations like this would be two distinct steps:
1. Identify files that need to be deleted; 2. Loop through the list and delete them one by one.
These steps are decoupled so that the list can be validated. Each step can be tested independently. And the scripts are idempotent and can be reused.
Production operations are always risky. A good practice is to always prepare an execution plan with detailed steps, a validation plan, and a rollback plan. And, review the plan with peers before the operation.
By contrast, SQL is more constrained about what it can do. It's declarative and you rely on the database engine to optimize the procedure.
Neither is perfect.
It's hard to get back to OOP once you're used to multiple dispatch. It's so natural and gets rid of the the question of "which class should I write this method in"?
Not sure about what kind of parser you're thinking about. If you like to do it in Julia, I suggest that you get on Julia Slack and Julia Discourse and get some help there.
Clearly, if you find Julia more productive and think that's the future, then that's great! There is no reason to hold back given that you can call out to legacy Python code as needed.
The downside, obviously, is that you have two languages to work with, which is not ideal. Depending on the size of your project and how much appetite you want to migrate code in your longer term roadmap, you can make a good judgment how to proceed.
I would have to say the world needs to move forward no matter what. COBOL used to be the best language for business applications and it clearly went out of favor. The recent events with COVID-19 brought up a clear technical debt issue. What I' trying to say is, sooner or later, the code will need to be rewritten.
Google tends to rewrite their software every few years to keep it fresh. That's not a bad model to have for any technology-centric company.
That's true. I remember hitting C-c and C-v a lot... XD
In general, it is best to create small functions that takes few dependent variables for the intended flexibility. The first judgment here is to decide whether a value should be a constant or variable. Constants would then be declared at the top, and variables come in as function arguments.
You reminded me that another pattern to handle this is to put some of these values as configuration parameters. For example, the email alert may need to be sent to different people for different environments - DEV, QA, and PROD.
This statement seems rather inaccurate and misleading. What you thought about 'multiplicative explosion' is the number of integration tests required. Generally, software testing focus more on unit tests, and so in this case, the number of tests is still linear.
> The article doesn't go into detail on what it means here, but the more serious the software work, the less the artistic mindset applies. [1]
This claim seems to be too opinionated. I doubt seriousness makes a difference. I have seen artistic/creative design in some very serious projects before.
I believe in reusability with software engineering. The reason why legos is so much fun is because you can compose and build things out of simple shapes.
I also agree with you and others in terms of simplicity. I guess what I failed to communicate in the original post was about the judgment that is required to make the right decision, and that caused quite a bit of opposing arguments.
I believe that the right level of abstraction is required for any non-trivial system. Life is full of balancing act - like yin and yang. Too little abstraction is also costly and leads to code bloating and maintenance nightmare.
The intention to illustrate the power of abstraction. Based upon yours and other people's comments below, perhaps it wasn't the best example.
I did correct the typo about 'url'. Best regards.
https://github.com/tk3369/BoxCoxTrans.jl/blob/master/src/Box...
I wonder if programming fonts could achieve that - like the original author could specify a font for a portion of the code eg. a “destroy_context” or “drop_connection” function could have a scary look.