91–100 of 243 posts
I'm already thrilled waiting for an addition with "Kubernetes everywhere" ice shower.
Earlier quoted context omitted.
I can assure you that I live on the same planet as everyone else posting here. Whether or not I could perform this miracle depends entirely on your specific use cases. Many people who have this sort of reaction are coming from a place where there is heavy use of the vendor lock-in features such as SSIS and stored procedures. If you are ultimately just trying to get structured business data to/from disk in a consisten…
This is a great answer. The details REALLY matter. One of my best early tech success stories was rewriting a SQL query that took 27 hours to one that took ~5 seconds. This was running on a very large Oracle cluster. They had poured more and more money into hardware and licensing trying solve this. In the end, it was a matter of turning a cursor-based query into a set-based query.
I can think of a couple of places I've worked where they had simple problems that could have been solved by some thinking and coding but instead were solved* by more expensive hardware.
A Cold Shower for (early) testing of software, maybe: There used to be an often cited paper by Boehm about the cost of catching bugs early vs late on production, usually mentioned by advocates of testing early, where the quoted conclusion was something like "studies show it's 10 times more costly to catch bugs late on production" or something like that. This is a very well known study, I'm likely misquoting it (the i…
Laurent Bossavit tears the Boehm paper apart in his book "Leprechauns of Software Engineering"[1]. It's a good read for anyone interested in the empirical side of software research. [1]: https://leanpub.com/leprechauns
I wish it would be possible to have better studies for that. I believe that static typing has huge benefits as software scales. I also believe that the type system of TypeScript is actually stronger in practice than the Java or C# one (despite theoretical weaknesses). It has the right tradeoffs (e.g. structural equivalence, being able to type strings, being able to check that all cases are handled, etc.) It would be…
The study IMHO is reality. Every large, actively maintained system I've ever heard of uses a strongly typed language, or was written in a dynamically typed language but has converted to a gradually typed language. You can't safely refactor without compile time type checking, and you can't maintain a non-trivial system over the long-term if you can't refactor it.
I'm already thrilled waiting for an addition with "Kubernetes everywhere" ice shower.
I don't have the necessary background to find a good "Kubernetes everywhere" ice shower, but if someone else found one and submitted it I think I could evaluate it.
The hype is huge in that train, but I'm sure there must be lots of professionals that have already learned about its shortcomings. Not sure if proper studies exist about Kubernetes yet, though. Hopefully you'll get a PR with some content.
I read this and thought, "oh, the author is calling out formal verification as overhyped? Hillel Wayne ( https://hillelwayne.com/ ) is going to be angry! Wait, who wrote this..."
We software engineers are still more like alchimists rather than chemists. That list reminds me of [1], which rants about this state of affairs and [2] that puts many beliefs to the test. [1] https://youtu.be/WELBnE33dpY [2] https://www.oreilly.com/library/view/making-software/9780596...
In addition to that, I also feel calling ourselves engineers is a stretch.
The hardest part of most projects is taking unrealistic and ever changing client demands and trying to turn them into something that will actually work in reality; a process which is probably all too familiar to many software developers.
Earlier quoted context omitted.
This is a great answer. The details REALLY matter. One of my best early tech success stories was rewriting a SQL query that took 27 hours to one that took ~5 seconds. This was running on a very large Oracle cluster. They had poured more and more money into hardware and licensing trying solve this. In the end, it was a matter of turning a cursor-based query into a set-based query.
In some respects, I think the constraints of something like SQLite can focus people's attention on making things work properly rather than throwing hardware at the problem. I can think of a couple of places I've worked where they had simple problems that could have been solved by some thinking and coding but instead were solved* by more expensive hardware.
Earlier quoted context omitted.
We aren't running any reports on our databases like this. I would argue it is a bad practice in general to mix OLTP and OLAP workloads on a single database instance, regardless of the specific technology involved. If we wanted to run an aggregate that could potentially impact live transactions, we would just copy the SQLite db to another server and perform the analysis there. We have some telemetry services which ope…
> At the end of the day, you still have to go to disk on writes, and this must be serialized against reads for basic consistency reasons. No, absolutely not. That's why modern databases use a thing called multi version concurrency control. You can run (multiple) queries on the same table that is updated by multiple transactions at the same time without one blocking the others (assuming the write transactions don't bl…
Earlier quoted context omitted.
People who like static typing seem to really like static typing. I'm honestly not convinced it helps that much. And it seems to cost a lot to me. I like database and API schemas though. And I like clojure.spec and function preconditions a lot.
I think it gives people a sense of satisfaction in modeling real world in the relations between classes. The assertion seems to be that if to solve a problem it has to be correctly modelled into the type system of the language. Once the modelling is done correctly solution will arise by itself. On the other end people who prefer weakly typed languages see problems as primarily that of data transformation. For example…