Eh. I mean, I don't have a piano, but I think a world in which no one ever does anything that can't be done on a laptop computer, would not be a better place.
I think it's an interesting approach. With, yes, caveats as people have pointed out, but there are caveats to everything, and this approach removes a huge barrier to 'try them and see'. If you want to talk specifics, contact info is in my profile.
ChatGPT allows you to download an archive of all the conversations you have had with it, so you can do things like search for past conversations with your choice of search tool. The archive is in JSON format, not quite usable directly, so I wrote a program to unpack it to plain text.
I do actually sympathize with that! I tried to keep a level tone, and maximize the ratio of useful information to flame-war ammunition, but that ratio unfortunately has an upper bound well short of infinity.
Right. To be clear, the purpose of the article is not 'zounds, C and C++ have footguns!' but 'C and C++ have footguns – yeah, this is not exactly breaking news – but here is a hopefully helpful summary of where they are, why they exist, and what you can do to avoid them'.
If you are already satisfied you know how to avoid them, and you don't need any more help with that, then you are not the target audience, and should by all means ignore the article.
Not the first discussion of this topic, by any means. In this case, I've tried to boil it down to the essential points a practical programmer needs to know, but the article still ended up longer than I initially aimed for.
Be careful what you hope for. For all we know, the answer might be, "Sorry, human, I'd love to chat, but I need to get your dish cleaned and racked up to dry before they close the lab for the eon. Now, how do you get the childproof cap off this bottle of antineutronium..."
I'm curious, what exactly would you redesign? Seems to me that it's intrinsically necessary to have DNS to translate between human-readable names and machine-efficient addresses. What am I missing?
I'm curious; I know the Sun workstations were generally well-regarded, but what was it about the Sun-3 specifically, that made it such an important quantum jump?1
In general of course you're right, and this is a very good point.
> Even doing work agilely with review every two weeks and the client only paying once they've reviewed and approved the work in that two week period, and approved your work plan for the next two week period, even with all that -- after a year or two they can still threaten or carry out legal action to try to claw back of some or all of the money they've paid you.
But I would've thought that way of doing things, sounded pretty ironclad. If in every fortnightly review of progress so far, they thought things were going well, how did they end up retroactively changing their mind after a year? Can you go into a little more detail about how things went wrong? Was it a case of 'they were a startup selling waterproof teabags, you built them an online store, turns out there is no market for waterproof teabags, and they were looking for someone to blame'?
Yes, and it's not just a binary. As a general rule – this has been verified in any number of cases – the more people are paying for something, the more respectful they are to the providers thereof, and the higher the perceived pay and status of the individual employee they are dealing with, the more respectful they are to that employee.
Sounds to me like a programming dream. The usual way of things these days is 'don't waste your employer's time trying to optimize; everything that can profitably be done has already been done by other people; you just have to accept that particular part of your skill set is useless'. Dojo would let you actually use a lot more of your skills.
Now I'm curious, 'Near 100% RH and temperatures in the 100s' should as the article says, be theoretically lethal; what are the precautions by which you avoid heatstroke, without air conditioning? (The one I thought of, if you have no air conditioning but you do have a fridge, was putting a bag of ice cubes on your head, but for some reason, people who live in hot countries, don't seem to do that.)
> The first benchmarks indicated the plain Archimedes had higher FP throughput than a 16MHz 386 with a 387.
I could imagine a plain Archimedes being competitive with a 386 in integer throughput, but an integer-only machine outdoing an FPU in floating-point performance would be very surprising. I don't suppose you remember which benchmarks they were?
I'm curious, what problems did you have with JavaScript math? I had the impression it was bog standard IEEE 754 same as every other language nowadays, but I have never tried doing any serious calculation in that language.
Thanks! Right, so the successful version was the one written in Lisp. Okay, that's actually understandable. At that time, managed languages were not widely used, and C is really not a good choice for that kind of project. If those are the two options, I can certainly see how Lisp would do better.
Okay, so what's the catch? If other manufacturers rely on the spyware and ads to finance the business, which is how they are able to sell such a high spec TV for $450, how is that vendor able to sell such a TV for $400 with no spyware and ads? Not a rhetorical question; I'm actually curious how they make it work.
> The IBM and DEC formats were really ugly and writing programs for them included many pitfalls. When I began to use an IBM PC, with its much more foolproof FP format, all problems disappeared.
I remember the IBM format was based on hexadecimal, and was thus criticized for wobbling precision. I thought the DEC format was pretty similar to the Intel one. What problems did you have with it, that disappeared when you switched to the IBM PC?
Are these actual numbers? If so, you've got me curious! How does it work? Do you really have billions of lines of code? How many of those 580k tables are auto generated?
In fairness, there would actually be much merit to this way of writing about an airline trip if the target audience were 19th-century people who had never heard of an airplane except in fanciful speculation. It explains a great deal about air travel and adjacent parts of the setting, that a story written for a 21st-century audience who are already familiar with the setting, naturally skips over.
I don't interpret Joel as saying 'never do architecture'. I interpret him as saying something more like:
- If your goal is to create great new architecture, that's fine, go for it.
- But if your goal is to ship a product to customers, on a tight schedule – say, you are a startup trying to get an MVP out the door before the end of your runway – then you should probably not be doing more than a fairly minimal amount of architecture, and you should beware of the temptation to do so.
Note that both your examples were created by people employed by large, wealthy organizations (MIT and AT&T respectively) that could afford to give them plenty of time to explore interesting new ideas. That's a great situation to be in, the world would be a better place if we put more people in that situation, and if you are in it, then you should take advantage of it. But if you are unfortunately not in it, then you should be aware of that fact.