111–120 of 585 posts
Earlier quoted context omitted.
It's not like people don't find a way to screw up REST semantics and make that complicated anyway.
Absolutely. The lasting ideas are KISS and Occam's Razor.
I would argue that any apps written in Objective C are probably technical debt now"
I switched to Swift a few years ago after many years of obj-c, at first I was reluctant as there were still many things I liked about obj-c but Swift won me over. Thought I would never touch obj-c much until I had to integrate a cpp library, I can't believe how much I forgot in such a short time. It was interesting to find out how to structure the obj-c code to translate nicely to swift though.
Earlier quoted context omitted.
Absolutely. The lasting ideas are KISS and Occam's Razor.
Sure but there's such a thing as too simple. It is distressing to think of the number of manhours wasted on each and every application using JSON having to have its own standard for handling dates since that was one of those things too complicated for the spec to have an opinion about.
Earlier quoted context omitted.
Most people use pdfLaTeX or XeTeX, which may have some basis in the original Tex82 but have since moved on, at least in code.
aren't pdftex and xetex just patched versions of tex82
Everyone one that has counter examples thinking they prove the opposite, are just not waiting long enough. All the kids think they will be young forever. Can't blame MS for new JS libraries every month, or a new language released every month. This web site is dedicated to people showing off things they created, which replace something that turns into debt, and in turn also become flavor of the month. Yes, biased old…
It’s so weird, I used to be much more of STEM triumphalist, the kind of person who used to think the past was evil and the future can’t come fast enough. I wouldn’t consider myself conservative by any means but increasingly in 30s I’m beginning to think everyone needs to stop messing with stuff and accept imperfection.
For example, you spend years in school being instructed as efficiently as possible in the one right way to do things that was already discovered. You are only rarely or never shown the messy process of trial and error needed to get there, and many really big errors are hardly covered at all (the history of communism didn't even get a look-in when I was at school!).
Another: you're instructed near exclusively by specialists, who are definitionally always right (if you argue with the teacher, you lose).
Yet another: as you progress through the system, you're rewarded as the ideas you handle get more complex. You aren't rewarded for simplicity. You are also rewarded for bullshitting, because just like RLHF, exams don't award points for saying "I don't know" but they can award points for a lucky guess.
These sorts of systems inevitably lead to an assumption that progress is linear, mistakes rare, complexity intrinsically has value, that expertise is nearly infallible, that guessing is OK if you don't know and the situation seems important etc. The longer one spends in education the further from reality these intuitions become, until you reach academia and become a public intellectual who produces the most complex/radical ideas possible based on educated guessing and then ignores whether they work or not.
Life outside the training environment eventually starts to correct these false ideas. You see how many things are tried that fail, how nuanced and ambiguous the value of ideas really is, how complexity blows up in people's faces due to problems they didn't anticipate and so on. You start to value incrementalism, evolutionary processes, systems that gather and aggregate the wisdom of the crowds. You become less impressed with ivory tower intellectuals who think they got it all figured out in advance on a blackboard. You become conservative, and end up railing against the young radicals who have some bright idea for reshaping society by force.
The fun thing is that, until CS slows down, stuff gets better so fast that we get to reimplement the same thing, but 10x better every 5 years or so. First I wrote single threaded code code with automatic memory management, then single threaded synchronous with manual memory management, then synchronous multi-threaded, then async, and then async lock free. Now I am writing async lock free, and the compiler is helping…
I am writing async lock free code as well, but which compiler is helping you? Rust? As far as I know, it's cutting edge research to figure out a type system that fixes this for you. But maybe i'm not up to date.
> stuff gets better so fast that we get to reimplement the same thing
So you are leaving the API in-tact and just change the implementation with new techniques? Or even better, you just rewrite low-level libraries you are using? Sounds like the ideal job to me.
I will say that the core idea of SOAP/WCF services is honestly pretty sound. There is no sensible reason (imo, anyway) that everyone needs to be using stringly-typed data and manually parsing REST responses when the underlying code all has type definitions. I get that it came with headaches (and I suppose people wanted to work in untyped languages) but jettisoning the entire idea of generating the client feels like i…
But you know what happened to SOAP? It was smothered by its own success. The allure of interoperability and extensibility attracted everyone and their cat to the party. With so many stakeholders involved, it became a classic case of "too much design by committee." It's like trying to paint a masterpiece by having a thousand artists contribute strokes—chaos ensues. And let's not forget the influx of junior developers…
> I have projects at my company in the old version of Angular that is a major technical debt we must upgrade. My favorite job -- to refactor something old. If only businesses wanted to pay for it.
Products don't become technical debt, they merely depreciate along with any aassociated technical debt. This is why I don't like the term technical debt: it implies something that must be paid back. But you don't have to pay back the "debt" on product that will be completely replaced anyway.
When I have a long list of todo items to perfect my work for a client, and then they run out of money for the whole project and end my contract. I don't say "oh no, now I'll never dot those i's and cross those t's!" I say "yay, I will cross everything off my todo list forever."
Earlier quoted context omitted.
Queue rust apologists… I think C and its direct descendants will slowly fade away over the next 20 years as new developers want to get away from the legacy of language specifications that span existing codebases. There are so many sharp edges in C that have automatic fixes/detections/etc in newer languages and don’t get me started about multiprocessing complexity in C.
My coworker and I were pair programming some Rust today. We were working on a convenience wrapper whose whole purpose is to reduce boilerplate. So, by its nature there's a lot of internal generic traits, thread safety, etc. He knows Rust well but software design not so much. I know software design well but Rust not so much. My experience can be summed up with: let &mut writer = Writer ::writer::new( connection.clone(…
It's not difficult to arrive at the caricature of baroque generic code if you combine lack of knowledge with miscommunication. The knowledgeable coworker should be aware that a writable object implements the Write trait, and know, or find out, the signature of the Write::write() method. Even fully generic, a function accepting a connection and returning the result of writing a block of data is not too gnarly:
use std::io::{self, Write};
fn write_data>(connection: &mut W, data: D) -> io::Result {
connection.write(data.as_ref())
}