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.
I have learned to not worry about coding style anymore, not because I don’t care, but because too many people care about that. Having worked with one of the largest monorepo, I’m happy enough to align with others with a standard coding style that is supported by a formatter and just let the formatter do its job. Humans are amazing when it comes to learning new patterns, and coding style is one that can be easily adapted to.
> you just have to keep in your head all the methods that are expected to exist for a given type.
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:
First, I want to say that this is a great post. You always grow stronger when you make mistakes. Writing it up solidify understanding in the learning process.
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.
I started walking for at least 30 minutes every morning before work, and it has become a habit during this pandemic. I realized that the best ideas of solving problems came from this little exercise. Subsequently, I’ve learned to start tapping away on my phone so I can capture these ideas before I lose them since there are too many to remember well.
Storing larger data sets in CSV format is a recipe for disaster. As tech industry we should really come together With a standard binary format for data exchange. Maybe Arrow?
This statement is so wrong. I am using Julia for at least two mission-critical production systems by now (financial services industry). I have a complete dev ops workflow plus integration with enterprise databases, messaging systems, and cloud resources.
The power of multiple dispatch is an eye opener for me personally when I first learned about Julia.
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.
I have a working situation where I need to work with Python and Julia. I'd like to say that there are great interoperability between these runtimes, so you can easily call a Python function from Julia and vice versa.
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.
It’s more than that though. Once the list is sorted, the next time you come back to it, the list is still more or less in the right priority. So the work for prioritization becomes easier.
I don't know if there's any name about this specific refactoring change :-)
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.