Earlier quoted context omitted.
I'm stunned that you're stunned that people generally don't use text files as data stores.
How do you deal with concurrent write access, do you lock the file?
He probably uses flock(2)
Ask HN: Are we overcomplicating software development?
291–300 of 378 posts
Re: Ask HN: Are we overcomplicating software development?
#292There's this book that I've been mentioning around here called Elements of Programming https://www.amazon.com/Elements-Programming-Alexander-Stepan... that makes exactly this claim, that we are writing too much code. It proposes how to write C++-ish (it's an extremely minimal subset of C++ proper) code in a mathematical way that makes all your code terse. In this talk, Sean Parent, at that time working on Adobe Photo…
[deleted]
Re: Ask HN: Are we overcomplicating software development?
#293Earlier quoted context omitted.
If you still use Rails and jQuery, why both with Polymer or Vue? What is the benefit they give you? Promise I'm not giving you a hard time. I'm honestly curious if there's something I'm overlooking.
My experience is with c# and knockout, which is pretty similar to rails and vue. I've found the sweet spot to avoid SPA's (which I'm pretty sure you can do with vue). Generate the html server side and only use javascript for the dynamic parts where it makes sense.
Absolutely! Unfortunately, this is very hard to sell to teammates on the SPA bandwagon and management who require all developers to be buzzword-compliant.
Re: Ask HN: Are we overcomplicating software development?
#294Earlier quoted context omitted.
I tend to start with a monolithic service. Sooner or later you get a feel for which bits are becoming at least API stable and could run independently. That's when I split them out. Do it too soon and you end up choosing the wrong boundaries and tying yourself up in knots, do it too late and your monolith can become a mess that's difficult to detach the pieces of.
I tend to try to write monolithic services in such a way that they could be broken up into microservices if that were ever desired. I don't go too far with this, just avoid things like shared static state and other anti-patterns.
You mean you follow good software development practices? Heresy!
Re: Ask HN: Are we overcomplicating software development?
#295Earlier quoted context omitted.
> Microservices probably reduces the asymptotic cost of scaling but add a huge constant factor. If this were Medium , I'd highlight the hell out of that. That's so true, and so nicely, succinctly put - it ought to be the reply to end every argument about whether microservices are good or bad.
I believe, for small shops, the real benefit of microservices is the logic split that forces good design and reduces cognitive load. You reap the scaling benefits way later, if ever.
"Logic" is vague and there a several layers you can implement this before even thinking about microservices.
It can be as simple as a simple class, or maybe a larger class as a single-file service, or an entire namespace with a several classes, or a separate library easily referenced. All the "logic" split benefits without the ridiculous hassle of microservices.
Re: Ask HN: Are we overcomplicating software development?
#296Earlier quoted context omitted.
How do you deal with concurrent write access, do you lock the file?
He probably uses flock(2)
But isn't that hard to get right? At least if you using something like sqlite you get consistency guarantees.
Consider your process writing to the file and dying during write() - do you recover and repair the file after you reschedule?
Re: Ask HN: Are we overcomplicating software development?
#297It's all about long-term vs short-term. Everyone architects software for the short term, I'd say the industry at large has collectively lost/never had the vision and wisdom to do anything else. Now maybe if you are a tiny-ass start-up, sure, but for a big established company, this is just bad economics. Why do we talk about "disrupting" the "behemoths"? Why is everything done in tiny-ass largely-parallel teams? Very…
> Everyone architects software for the short term, I'd say the industry at large has collectively lost/never had the vision and wisdom to do anything else. I think everyone architects for the long term, they just do so poorly. The problem is that architecture has become synonymous with "more layers".
OK, so in the beginning there were no layers. People occasionally wrote a layer but it was common to just say "fuck it", and through it away. As late as the 90s, you read about C programmers writing hash tables all the time, wtf.
Then, somewhere along the way I don't know exactly when, we hit an inflection point where there were some layers that didn't work quite right, but were hard to do without, so we'd try to shim it.
Really good long-term engineering means also ripping up the under-performing layers, attacking the unneeded complexity. This does not mean giving up on abstractions altogether.
Re: Ask HN: Are we overcomplicating software development?
#298Could also be interpreted as: "devops is not yet mature/lacking tooling".
Don't get me wrong, complexity has grown. Agile is a joke. But, e.g., build systems have been maturing for 30+ years. Their cousins, deploy systems, have a long way to go.
Re: Ask HN: Are we overcomplicating software development?
#299Choose languages and frameworks that developers are familiar with.
Microservices are fine if you can rely on shared CI/CD infrastructure and automate execution properly, maintaining rapid build/test cycle times. They start to suck if people aren't familiar and everyone's laptop has to hold their own parallel multi-topology service prom regression test (^releases) every time you change a line of code... developer focus, flow and efficacy will be reduced.
I agree that redundant HA systems are usually not required. In the past it was expensive to get. However, tooling is now so good that with reasonable developers and reasonable infrastructure design, you can get it very, very cheaply if your services are packaged reasonably (CD-capable) with basically sane architecture and your infrastructure is halfway modern. This truly is excellent, because gone are the 1990s of everyone-relies-on-grizzled-sysadmin-and-two-overpriced-boxes-with-failover.
I don't think CI is a plaster, it is a great way to work, but like any tool or workflow is not appropriate in all situations.
We do over-complicate. Methodologies are too meta: programmers are already operating at max concurrent levels of abstraction. Better to incrementally adjust workflow (CI/CD on the workflow for the CI/CD of the workflow!). That's not to say that there's no value to some people thinking at this level some of the time, but Yoda told me "desk with agile literature much, sign of untidy mind be". I think he was right.
Re: Ask HN: Are we overcomplicating software development?
#300Earlier quoted context omitted.
Things such as joins, transactions, and means of enforcing data integrity are useful when solving a whole slew of problems. Not to mention the tooling and community you benefit from when you use a common RDBMS. I never found data translation/serialization to be a big pain (just rely on a framework/lib that does it for you). It's a bigger pain to hand-roll joins that would be a one-liner in SQL or deal with issues tha…
I hear this data-integrity thing a lot but I don't run into these problems myself. I think it might be a functional-programming thing. It's much easier and safer to declare your constraints rather than trying to enforce them. If you aren't in a functional language I can see why you'd want to reach out to one but SQL in a separate process is just one of the options. > Things such as joins, transactions, and means of e…
> If the domain needs transactions [...]
Considering we speak about daemon software (services exposing some API to readers and writers) that provides CRUD behavior to the user (end-user or other developer), isn't that nearly always the case to guarantee write access to concurrent writers without the risk of crippling your data?
Furthermore I am not sure how this relates to FP.
> It's much easier and safer to declare your constraints rather than trying to enforce them.
But that is a strong point of RDBMs implementing SQL. You have some kind of schema (think type) and use selected functions (select, update, delete, create, etc.) to transform the data.