11–20 of 52 posts
I suppose that it's true that if you were coming from the item pointed to by 'prev' you could xor your previous address with the linked list pointer to get the value of 'next'. Is that from an actual implementation? Was anyone crazy enough to actually do that?
> xor the “next” and “prev” pointers of their linked list into a single DWORD to save 32 bits I suppose that it's true that if you were coming from the item pointed to by 'prev' you could xor your previous address with the linked list pointer to get the value of 'next'. Is that from an actual implementation? Was anyone crazy enough to actually do that?
Another crazy thing in Z88 is that the maximum amount you could allocate in one 'malloc' call was 256 bytes!
Duck tape programmers also produce code only one or a few persons can patch. The result is technical debt that lead Netscape to do a full rewrite to produce Mozilla/Firefox. The truth is in the middle with better tooling to make it easier to design good code and get it working faster with fewer bugs even while at the bleeding edge.
Netscape might be the worst example for your claim. Read why here: https://www.joelonsoftware.com/2000/04/06/things-you-should-...
Mozilla and Firefox are better products. Many other solutions use their code (e.g. TOR).
All bets are off when competing against a monopolist.
Netscape maybe died because the technical debt forced them to bet the company on making a better product...which they did.
Duck tape programmers also produce code only one or a few persons can patch. The result is technical debt that lead Netscape to do a full rewrite to produce Mozilla/Firefox. The truth is in the middle with better tooling to make it easier to design good code and get it working faster with fewer bugs even while at the bleeding edge.
Not really. You're assuming that ductape == bad. What your describing is someone writing bad code, not someone gaffertaping a bunch of modules together to make the _more important_ code work. (instead of re-writing a whole bunch of things to make stuff more "idiomatic" ) This is where innovation tokens come in. You have one innovation token per project, you can spend it on the thing you actually need, or some pointle…
Earlier quoted context omitted.
Netscape might be the worst example for your claim. Read why here: https://www.joelonsoftware.com/2000/04/06/things-you-should-...
Quoting from that article (which I remember reading when it came out): "It’s important to remember that when you start from scratch there is absolutely no reason to believe that you are going to do a better job than you did the first time." Mozilla and Firefox are better products. Many other solutions use their code (e.g. TOR). All bets are off when competing against a monopolist. Netscape maybe died because the tech…
Fine, COM and COBRA are baroque and complex and one can make the case that they merely make "simpler" things that can be done in other, more duct-tape-y ways. I'm fine with dismissing this sort of overgrown, overcooked-before-anyone-even-ate-it API/framework in favor of simpler approaches.
But ... just because Netscape didn't need threads in 1995 doesn't mean that nobody needs threads. And by threads, I'm not talking about "concurrency" in the way that is in vogue today in the context of Rust/Go/JS. Sometimes, you do actually need threads, and you just have to grapple with having multiple execution streams running simultaneously, with everything that implies.
That's just picking out the most prominent example from TFA, but there are other floating around too. Failure to properly identify "baroque over-designed nonsense" from "complex, hard to use but necessary stuff" is a common failure, and an important one to try to avoid.
Also, the "next and previous points xor'ed into a DWORD" hack mentioned at the end? This isn't duct tape programming. It's absurdly context-dependent premature optimization, useful only in insanely memory-constrained environments, and not likely useful in almost any of the scenarios that most programmers (especially duct-tapers) find themselves working.
Also, real programmers don't say DWORD.
Duck tape programmers also produce code only one or a few persons can patch. The result is technical debt that lead Netscape to do a full rewrite to produce Mozilla/Firefox. The truth is in the middle with better tooling to make it easier to design good code and get it working faster with fewer bugs even while at the bleeding edge.
A well designed solution doesn't feel like duct tape, nor should it be "too clever" with a crazy multiple-inheritance architecture that no one but the author can understand.
In fact, it sounds like the extremes described in this article are both crap developers, with different flavors of crap on the menu.
I insist on solid engineering. Nothing that feels like duct tape, but nothing that approaches over-engineering either. Easy to understand and easy to extend to the point of "OF COURSE this makes sense!"
It's not so much "in the middle" as "robust design vs one or another flavor of garbage." A strong designer is needed to get to that point, and maybe duct tape is better for shipping product than over-engineering, so if you HAVE to choose, the duct tape end of the spectrum is better. But even better to have a solid software architect who can come up with a good solution that people can use and extend and understand.
Still going back to Joel on Software for a good read. My favorite technical blog even though Joel has more or less stopped writing except for the occasional update.
"I know it’s kind of a cliché but it comes back to worse is better. If you spend the time to build the perfect framework…release 1.0 is going to take you three years to ship and your competitor is going to ship their 1.0 in six months and now you’re out of the game. You never shipped your 1.0 because someone else ate your lunch. Your competitor’s six-month 1.0 has crap code and they’re going to have to rewrite it in two years but, guess what: they can rewrite it because you don’t have a job anymore."