imagist

> One possible reason is that pre-baked primes can be designed to avoid certain pitfalls (e.g. primes close to powers of 2, which the article implies can be solved using the much faster algorithm) or otherwise to be resistant against certain cryptographic attacks.

Why can't those primes be calculated on the fly? Checking a number for being within a certain distance of a power of two is well within the programming capability of a freshman CS student.

> I don't know enough about DH to know if that's really the case here or if it's merely done to avoid having to compute fresh large primes, but I'm going to guess there's a good reason for it.

Given the incentives involved, I see strong reason to believe this is not the case.

Yeah, agreed, Viet Nam is more clear-cut because history has given time for the politicization to settle down. But Iraq is more relatable (or in the words of the OP title, "Fathomable").

> There are a lot of worthless measures we use out there. Body Mass Index (BMI) is another one. This scale was developed in the mid 1800s and you can do a simple search to find tons of criticism on it. If you're overweight/obese, you will have a high BMI, but not everyone with high BMI is overweight (especially if you're very tall or very short).

The metric system was developed in the 1800s and you can do a simple search to find tons of criticism on it.

Being tall or short is accounted for by BMI, as it's a component of BMI. So that is not a problem.

The actual problem with BMI is that it attempts to measure body composition, but it assumes that fat is the only variable component of body composition. It's not--muscle can also vary. So people with a lot of muscle mass can have a very high BMI even if they have very little fat.

However, in practice this isn't a problem--nobody looks at a body builder and says they're fat because they have a high BMI. It's obvious when a high BMI is caused by fat and when it's caused by muscle.

BMI is a pragmatic way to measure body composition, which is effective for estimating body composition when body composition isn't obvious, such as in the case of a body builder. Anyone who tells you otherwise is either misinformed, or has political reasons for saying otherwise.

This is not to disagree with your overall point--industry does grasp into measurements and make business models out of them. But in the case of BMI, political interests have become invested in discrediting the BMI measurement, not in overcrediting it.

15 years after we invaded Iraq, a country which had nothing to do with 9/11 and no WMDs, or at least fewer WMDs than the US.

It's easy to distance ourselves from things that didn't happen in our country or in our lifetimes, but the reality is that we're just as bloodthirsty as anyone else.

Meh, that's too passive-aggressive for me. I'm perfectly okay with clicking decline on an invite and not going--no need to hide it. I guess what I was really asking was how do I persuade my company to not try to waste my time with all-hands meetings.

> Well, if you take a 2000 word write-up about your own type, there may be some thought-provoking generalizations either about your own type or about patterns that are consistent when people of different types interact... things which derive from what you believed about yourself but are consequences of the MBTI's generalizations about human interactions.

Right, but how many of those generalizations are actually verified? The specifics are studied to be consistent, but there are very few generalizations backed up by data.

The problem here is that since the MBTI only collects your own perceptions, it is only as accurate as your own perceptions--it isn't going to tell you anything you don't already think. There's some value in bringing what you think of yourself into your conscious awareness, but I don't think that can be represented as increasing self-awareness--it only can cause you to think what you already think. There's even some risk that it may reinforce incorrect ideas you may have about yourself.

> As a Meyers Briggs ENTP I find the descriptions of an ENTP personality flattering and desirable.

Of course, they're your descriptions and therefore they're biased. (Incidentally, I'm an ENTP too).

All I wanted to know about all-hands meetings: how to avoid them.

This underscores the need for flexible security that doesn't rely on magic numbers. If an algorithm needs a number that can't be one of the obvious ones (0, 1, 2, 3, 2^x - 1, largest prime < 2^x) it should be generated.

That would pretty much defeat the entire goal of free software. Setting up a technical barrier to usage is counter to free software goals.

> 1. The proliferation of libraries enables devs to get very, very picky about their libraries - the slightest wart or lack of understanding will cause them to label a library "utterly crap". But anything they create to replace it will run afoul of another programmer's picky tastes even worse! (And to what degree they may have a point, exactly 0 devs will be previously familiar with the warts and misfeatures of this new code.)

Ah yes, the "it's all subjective" argument. The thing is, it's not subjective. Sure, it may be hard to objectively measure the qualities of a library, but that doesn't mean we should give up and assume there's no underlying objective truth.

My "picky tastes" are for libraries that are battle-tested, performant, and scalable. If that runs afoul of someone else's tastes, frankly, I don't care.

> 2. As I get better at project management, I realize that myself and my fellow devs are constantly underestimating the ongoing maintenance burdens of new code. It's hard enough getting us to make sufficiently pessimistic time estimates for the initial implementation that PMs don't have to smile and multiply by large integers - nevermind accounting for the next few years of adding additional debug logic, logging, fixing edge cases, supporting legacy decisions, adding a full set of fuzzing and regression tests, etc.

I definitely agree that the ongoing maintenance burden of new code is consistently underestimated, but it doesn't follow from that that we should prefer third-party libraries to our own code. A new third party library is still new code, and it's not often a reliable assumption that someone else will maintain that code forever. Further, general-purpose third party libraries aren't tailored to our needs, so they often contain more code than we would write. The result? We often end up with a larger maintenance burden by using a library. And finally, even if someone else maintains your library, that doesn't mean they will maintain the integration point between your code and theirs. Keeping up with changes in a library that doesn't value reverse compatibility highly can be just as costly as maintaining a library yourself.

> #2 I feel like is the trap. As beings with limited amounts of time on this planet, the test should not be about absolutes, but if what we would build is better given the time we would have to devote.

I don't think it's really about the time you have to devote. Integrating a library can take longer than writing the code yourself, and that doesn't change with respect to the time you have.

> And this isn't that strange of a phenomena when you think about it. Construction workers choose hammers rather than forging them on their own, we buy food from supermarkets instead of growing it on our own, etc. One of the principle elements of humanity is our ability to stand on their shoulders of giants, which shouldn't be lost

This fact isn't lost on me. My point is that there are actually relatively few giants who have solved an average arbitrarily-chosen problem, and even fewer who have shared their work. If you have 10+ years of programming experience, it shouldn't be hard to find an area where you are the giant.

Yeah, but that happened to late to help me. :/

> Of course, but one should be aware of a tendency to overestimate the effort required for tweaking third party code (understanding somebody else's code is always more difficult), and underestimate the effort required for writing the thing from scratch.

It's not just the cost of tweaking, it's the cost of keeping it up-to-date, too. I agree with the general gist of what you're saying, just wanted to point out there's more to it.

> I believe you, but I find it difficult to believe these would be the same people who tend to introspect on their profession a lot, eg. by following software engineering blogs, so the author is kind of preaching to the choir in my view.

On the contrary, I think people who don't introspect about what they're doing are more likely to read tech blogs. How else would they find out what the latest fad libraries are so they can treat them as best practices? :)

A case like this, which has a wide variety of exceptions that need to be updated as timezones change (yes, they do) is a perfect case for a library. The best I've ever found was JodaTime, but I no longer work in Java and no other language has an equivalent.

> 95% isn't "only". That's pretty darn high. I'd wish that in-house code covered 95% of requirements more often.

> If we're talking about open-source (I can't see why not), you can just fork the library in question and adjust it to fulfill the missing 5%.

The percentage isn't relevant if working around the design of the library to fulfill the missing 5% takes 30x as long as just writing the code yourself. Additionally, libraries often do a lot of things you don't need, so you get a bunch of bloat along with the stuff you want.

> Obviously noone sane would pick third party libraries based on how fancy some web page is. That's a strawman argument.

We can argue about the sanity of people, but the fact remains that people on teams I've worked on have chosen libraries based on the fanciness of their webpage.

The longer I work, the more NIH I get. There are two reasons for this:

1. The ease of creating a library these days is resulting in a proliferation of utterly crap libraries, so bringing on a new library is more and more of a liability, both to future reusability of code and to security.

2. As I get better at programming, I more and more often realize that I can write a better version of the library, or just one that better fits my needs.

These combine to create a situation where I'm less and less likely to want to import something.

> I don't really understand why people treat de Sade's writing as different than any other run-of-the-mill elaborate fetish fiction.

de Sade does spend a great amount of time expounding at length about philosophy and society in between the sex and torture, and if you took out the sex and torture, it looks a lot like a prediction (and criticism) of national syndicalism and fascism more than a century before those ideas became widespread. It's hard to look from 200 years later and see a prediction of something that happened 100 years ago as forward-thinking, but it was at the time.

I also think that his work has become more relevant today, not to the concept of the office, but to identity politics. But given the gratuitous imagery, esoteric style, and loss through translation, I'm not sure the benefit/cost ratio is high enough to warrant attention from an English-speaking reader.

I still don't see anything here which indicates to me that I should give a shit about NewLisp being called "NewLisp", or about referring to CL/Scheme/Racket/whatever as "Lisps".

> Only actual Lisp dialects have a claim to the name.

Frankly, I don't give a fuck about anyone's "claim". If people can use a word to move an idea accurately from their brain to other people's brains, communication has occurred and I'm happy.

If I say "NewLisp" and my audience knows what interpreter I'm talking about, I have succeeded in my goal.

> Naming a project in such a way as to troll people is not a matter of "terminology".

1. I see no reason to NewLisp was named to troll people. It only has the effect of trolling you because you have created a subset of the English language in your head which you view as "correct" without any basis in reality.

2. In the English language, "terminology" can be applied to the names of programming languages and people will know what you're talking about. It can also be applied to things like "list", "scope", etc.; generally people use context clues to figure out what you're talking about.

> To me, NewLisp is uninteresting. I already know how to avoid sharing issues in memory management in C programs by mallocing a copy of everything and duplicating it; that bores me.

Thank you for sharing. I'm sure you're very knowledgeable and smart and whatnot, have a cookie. Now can we who are interested and curious about this have a conversation without you butting in, please?

I'd like to know:

What are the performance implications of doing ORO universally? The tradeoff seems to be that copying takes time, but it also allows you to treat everything as stack-allocated, so it saves time on heap management. What's the average case performance like? In what cases is this a good tradeoff? In which cases is this a bad tradeoff?

But I don't think the project is trolling, and I don't have any problem with the project's behavior. I'm curious about ORO. You're the only one who's looking for a fight here.

I would rather we put the people who made this decision in jail. People make unethical decisions, not companies, and fining a company doesn't usually punish those people in any significant way.

That's simply not a correct analogy.

A more correct analogy, is that if you make $90K/year at your job, you rob a bank for $10K, you are then are fined $55K.

I'm a cynic and most of the time lawsuits penalizing companies are a joke, but this one is better than most.

The problem I have with this is that companies don't make unethical decisions, people do, and the people who made this unethical decision will probably see feel very little of the fine. Maybe they'll get fired, but they'll still walk away with massive amounts of pay and probably a contractually obligated bonus and severance.

Okay, true, but why should I care?

This is like one of those ad games: If you press the button, you fix spam calls, but Twilio goes out of business. I couldn't press the button fast enough.

For the record, I like Twilio and I literally have their API open in another tab right now because I'm writing code against it. But if they can't do business in an environment that doesn't allow spam calls, they don't deserve to be in business.

I'm not sure what you're trying to say here.

This could be fixed by fixing the broken telephone protocol so that phone numbers can't be spoofed so easily, and then implementing adblockers.

But that won't happen because:

1. It would cost money.

2. A proper implementation would be encrypted, breaking ubiquitous surveillance.

Cassandra is used by Reddit and Uber.

There's a word for unjustified confidence.

Twitter is analogous to ABC in the same sense that I'm analogous to Usain Bolt. We both run, but only one of us makes a profit doing it.

> Despite what the CLers say, we all have an equal claim to the name.

Agreed, but who cares? Is this what you want the Lisp community to spend our time on?

> It's important because we have to distinguish between many dialects. If any of them are just Lisp, it starts to get confusing.

I don't think it's important. I'm not confused, and if you understand what's going on enough to disagree with it, you aren't confused either.

More to the point, neither being confused about what dialect is being discussed nor arguing about semantics helps anyone, but at least confusion doesn't waste enormous amounts of time and energy, divide the community, and derail productive discussions.

Look at this thread. I'd like to talk about ORO memory management, which is pretty interesting, but instead we're talking about semantics. The top response is about terminology. Is this what you want?