HN user
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:
There’s no privacy agreement to sign when setting up the fridge? I had to click on the Agree button several times when I started with my LG TV!
100% click bait title and opening statement. Is journalism that bad these days? Ironically I quite like some of the points in the main content.
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 agree for the most part. However, IMHO using these words (just, simply, etc) occasionally can make the doc more lively and fun to read.
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?
Building queries in a programming language is more flexible and the data operation is explicit. You rely on good programmers to do it right.
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.
Congrats! Thanks for sharing. I think one of the best decisions you made was the choice of the domain name. It feels authentic.
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.
I love SQS but it isn't quite comparable to Kafka because it is poll-based. It's a solid queue but not suitable for streaming.
How is Kinesis crappy?
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"?
This discourse post seems useful https://discourse.julialang.org/t/writing-a-parser-in-julia/...
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.
It’s also rather annoying to type them, but that’s also probably because I just haven’t developed a workflow for it.
That's true. I remember hitting C-c and C-v a lot... XD
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.
You've just introduced an exponential explosion into your testing burden. The pay-off: additional functionality that might be useful later. edit On reflection I suppose it's not a 'exponential explosion', it's merely a 'multiplicative explosion'.
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'm delighted to learn about this perspective. Appreciate the note.
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.
OP here. Thanks for the note.
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.
OP here. The code presented in the blog post was just an example although your points above are well taken. Practically, the decision to do abstraction or not depends on the use case and requirements.
Right, there is also difference between short-term value and long-term value.
Another way to express semantics is the use of Unicode in source code. For example, I have this Julia package that performs Box-Cox transformation, and I was able to use bold face for vector data and greek letters for the parameters as found in research paper and literatures.
https://github.com/tk3369/BoxCoxTrans.jl/blob/master/src/Box...
Interesting. Thanks for the share.
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.
Appreciate the upvote anyways LOL
OP here. What you said is very true. Visual impression isn't the only dimension. Nowadays, it seems that most people (especially the younger generation) just want to watch a video than reading a book. There is bounded to be something missing with a different medium.
You can probably leave the sorry part out. There’s nothing to be sorry about :-)