pedasmith

Using source code control. Ever so many things become easier, and yet there are still teams that have never heard of it.

If only my non-statistical peers would recognize that sampled=fast and fast=more checks and explorations. It's like they recognize that fast compile times are a great thing (I've had to wait in line with punchcards, and it sucks), but they are completely oblivious to the exact same argument when it comes to data.

I dipped my toe into the "online glasses" market -- and let me say it's a game-changer. The eyeglass store wanted about $300 per frame, meaning that I'd grudgingly get one pair.

The online purchase was only $75 for high-end frames and coatings, plus $27 for three pairs of prescription "computer monitor" glasses (one for the office, one for the home office, one for the other home office!). And by having more pairs, I can bring a pair on trips, just in case the main ones get broken!

(Personally, I've also never had any useful help in picking out frames. I'm not very fashion conscious, and every time the help doesn't seem to want to actually help be find frames that would look good on my face)

Another ditto -- I now have one pair of regular glasses and four pairs of computer/reading glasses, all prescription (one for each computer I sit at!). The last 3 computer glasses cost $27 for all three. At those prices, I can trivially "just get" spares for vacations and hiking.

After reading his posts, I'm pretty sure I wouldn't much care to work with Norbert, either. Being a volunteer isn't free reign to be unpleasant and argumentative, and Debian, like any organization, is free to shut the door to people they don't really care for.

AFAICT, the headline is wrong. He's been asked multiple times (the Debian team was nice enough to have clear links about emails) to shape up, and he's not being teachable.

I have to both agree and disagree here.

I love the idea of a language that has the absolute fewest number of decisions between "I need a little program" and being able to share the program with a friend. The current trend where there's a seemingly bazillion steps before you can write a trivial utility is unfortunate.

However, the microcomputer BASICs had big usability problems. Us modern programmers are so used to block oriented languages that we assume every language just had them. For example, in C you can replace any statement with a list of statements enclosed in { }. In Python where blocks are indented statements, or Pascal where you can make a block of statements with a BEGIN/END.

But many microcomputer BASICs don't have that at all. The IFs often don't have the concept of an ELSE, and often the only thing you can do from an IF is a GOTO.

The end result is a mess of jumps where the programmer is "emulating" real blocks with GOTOs. I've had the recent fun of transcribing programs from a bunch of different early BASIC languages. The complaint that BASIC leads to spaghetti code is real. There are bazillions of GOTOs, and it's a real drain on your mental processing to keep them all straight.

Exactly. It's a perfectly reasonable concept with a completely outlandish syntax. I don't know of any current programming language where the RHS of an assignment will even know what the LHS is.

New versions of BASIC are surprisingly common (heck, I even have one that's gotten some super-nice comments).

Mind-blowing BASIC example from the 1970's:

    100 A$="ABCDEF"
    110 A$ = REP ("123", 4, 0)
    120 PRINT A$

The result is ABC123DEF -- at position 4 (strings start at 1), replace 0 characters with "123". So the REP function looks at the statement it's part of, finds the variable that is being assigned to, and uses that as the starting string (!). It's kind of like a function, only with a weird implied variable that only works in an assignment.

You can't just PRINT the result directly, because then how would REP know what the string to change is?

Nowadays "weird" syntax has some solid foundational reason why it's useful or important. This not-really-a-function, though, simply has no justification whatsoever.

(This example is from the BASIC embedded in the Tektronix 4050 terminal).

There are enough variants of BASIC that there's a really nifty handbook with the differences at https://archive.org/details/Basic_Handbook_2nd_Edition_1981_...

As long as we're arguing statistics with personal anecdotes: the dairy queen my younger kid worked at was about 80% teenager, with an attrition rate of wow!. The older kids' jobs at an upscale fast food is also easily 50%+ teenager. Both kids were pretty much hired on the spot with no previous employment.

OTOH: it's a high-profile company with exacting requirements for its pieces. If they can convert, companies that might have been on the fence ("it's too hard! our requirements are special! nobody else is doing it") might jump in, too.

Maybe BCD because otherwise converting from binary to decimal is too painful? Lots of these were used in instrumentation with the classic 7-segment displays.

Why one time? Why can't I get an "alternate" IDs from the IRS where the IRS knows the "real" number it's associated with, and provide the charity with that?

Or heck, let me just tell the charity my email address, and then tell the IRS that all the donations for that email should be credited to me. People who want more privacy can "just" sign up for bespoke email addresses.

You might remember that Bush agreed to making a brand-new "Office of the President-Elect" just so that there could be a single plan of action.

The title was disappointing: the researcher might well want to know why insurance companies don't ask about gun ownership, but if the companies answered, it's not the article.

What the article does do is present a survey of what the known data shows, and compares it to other risks that are asked about (e.g., scuba diving),and demonstrating that on it's face, gun ownership is higher risk.

Our vax cost $500,000. It's not something you just get more of :-)

Twenty programmers on one vax and actually doing the simulations is CPU intensive. The VT240 is what our customers had (and they are expensive enough all by themselves; a single VT340 in 1991 was $3600.

The advice i got from an observation for a big presentation was invaluable. I talk too fast and, somewhat weirdly, hardly move my jaw

Where I worked (a digital electronics simulation company in the late 1980's), we said that PC's had "user interface MIPs" but not "CPU MIPs".

A VAX 11/780 (size of a refrigerator) had more CPU power, but access was via RS232 link to a VT100 terminal. These could be pretty slow: it wasn't unusual to type a command line and wait up to 10 seconds (or a minute, in really bad times) to get a response. And a graph could easily take a minute to fully display on a VT240 graphics terminal.

A PC on the other hand had "user interface MIPs" and could display a graph instantly. What the PC couldn't do is run our very large, 32-bit required simulation code.

(As far as how easy it was to add a hard drive: at the time, to add a new disk to a sun station, you had to recompile the kernel)

A documented behavior which causes many security and crash issues is, almost be definition, effectively broken.

Can you come up with an example of an API which you would consider to be effectively broken and yet is not actually broken? Presumably, it would be an API that's easier to misuse than strncpy.

And the link directly takes you to a "how to buy". There are multiple copies available. A bigger question is why we in the computer field let important histories of our profession go out of print so quickly.

How about a different example entirely? Memory nowadays is either CPU (and the GPU can access it) or GPU (and the CPU has a window into it). It's terribly important to use the right one: if a chunk of memory is mostly used by the CPU, it needs to be CPU memory, and if it's mostly used by the GPU, it needs to be GPU memory. But there's no good way to specify that.

You might argue that a modern computer is more like programming a tightly-bound, nonuniform multi-processor system. And I'd agree. But C doesn't much to help program such a thing.

How about Σ Sigma notation for summation? It's often written with something like i=1 at the bottom and 1000 at the top to denote the summation from 1 to 1000. The Wikipedia article at https://en.wikipedia.org/wiki/Summation has some examples.

I've owned a leaf for some time as the family second car. Except for long trips, it's the one car we always prefer. Any short drive will be done in the leaf (unless someone's already taken it).

Its easily the best car I've owned because it's reliable, cheap to operate, dead quiet, and has a nice amount of get-up-and-go.

So no, the current crop of EVs are not undesirable. They may not meet everyone's needs (e.g., in rural Idaho where the nearest town is 40 miles away). But if they do meet your needs, the current set is great.

I'm not surprised it's not the Air Force or NASA. As a civilian, there's no activity I undertake that any military person has any jurisdiction over at all (I suppose unless I go onto a military base). NASA, of course, is more of a research and launching facility; they don't really have investigators or the ability fine people.

Thanks. My browser was acting up. Dups should be removed, and the one good comment saved.

Project Gutenberg has a copy of the Victorian-era (The Municipal and Sanitary Engineer's Handbook)[http://www.gutenberg.org/ebooks/55935]. There's a good discussion on how to write a paving contract on about page 35, including a quick discussion of using machinery to crush rocks for the road surface. It turns out that different machines produce wildly better or worse crushed stone, and that it makes a difference.

And there's a snarky comment on page 163 about companies that have to fix roads after ripping them up ("breaking"): if they do condescend to cart anything away it is generally the metal, which they think will come in nicely for the repairs of the trench during their liability for such repairs.

TL/DR: your town engineer just needs to specify the right stuff in the contract, and the road paving companies will just have to adapt.

If you think about it, the same thing holds true for any large, bespoke contract. What you get at the end depends in part on the supervision you put in.

Or, the town engineer can simply add it in to the contracts. An example from the Project Gutenberg copy of [The Municipal and Sanitary Engineer's Handbook](http://www.gutenberg.org/files/55935/55935-h/55935-h.htm#Pag...), page 35, there's a considerable discussion of how to specify a road paving contract. And later on page 57 or thereabouts there's talk about specifying the machinery needed to break the stones for a roadway (some produce much better road stones than others). And page 163 (about) has a super interesting diversion on how awful most companies are about replacing the road surface after ripping it up:

Well, you can spend 5 months writing your software in C++, and a month fixing your bugs and doing a bit of optimization. Or you can spend 3 months writing C# or other modern language and have another 3 months to optimize, all the while enjoying substantially faster compile times and super easy refactoring.

Indeed, I'm looking at my copy of "The C Program Language", second edition (ANSI C). Page 241: A text stream is a sequence of lines; each line has zero or more characters and is terminated by a \n. [\n was defined earlier as ASCII 10 and designated either as NL or LF.] An environment may need to convert a text stream to or from some other representation (such as mapping '\n' to a carriage return and linefeed)"

Because we're talking about how end-of-line is marked in a file, not in a terminal. DOS specifies the end-of-line in a file as CR/LF.