skysight-inc/HackerNews huggingface dataset:
Snow can be removed from rotating solar arrays by simply turning them sideways at sunrise, perfectly clearing them as the sun warms them up. If you're really enterprising you can turn them upside down at night. Can't say the same for the roads anywhere I've lived. Also, those dull grey cement highways used to be gleaming white when they were poured but alas, car tires are black and turn everything they touch black as well.
I'm really curious how they could adapt Foundation to TV, I really liked the books but I think the Robot Series (Caves of Steel, Naked Sun, Robots of Dawn) lend more to a TV adaptation.
In any normal jurisdiction, a prima facie mistrial would've resulted in an automatic disqualification and disbarment of a presiding judge.

America admits no legal liability of court employees over anything except gross miscariage of justice, and even for such cases Americans invented insane legal theories that let few judges walk away from charges ranging from corruption and bribery to selling "freedom for blowjob"

Push for personal liability of judges in mistrials and violations of court protocols
Just any text editor and reloading the file one's editing works fine as well:

shell$ sbcl
[... some editing ...]
sbcl> (load "file.lisp")

As for which Lisp. I advise Common Lisp since it's the most practical of the lot. Doesn't force you into a particular paradigm.
Is it unethical for me to not tell my employer I’ve automated my job?
ABCL's interoperability with Java is not part of the CL spec, but an add-on. This can make it easy to quickly get things done in a situation where Java libraries are the best tool for the task, but at the cost of portability between CL implementations.
I think "exactly once" doesn't imply "non-reprocessing" (sorry for the double negative).

Meaning, you want "exactly once" and you don't want duplicates, yes. But you allow for reprocessing, provided that you have a way for deduplicating.

You want a guarantee that if the producer (at the top of your data processing pipeline) sends a message, then this message eventually corresponds to exactly 1 record in your final storage(s).

One easy-to-understand-yet-simplistic example is: send a message to kafka, use topic+partition+offset as primary key, store in a RDBMS. This is widely accepted as "exactly once", but clearly you may have multiple attempts to save the message into the db, which will fail due to the primary key integrity constrain.
Google hires Intel’s former head of diversity as VP of Diversity
Minoca OS 0.4: We love the eighties
In general, an attacker wouldn't be getting my password from my password manager, they'd be getting it through phishing, or brute force, or some other way. If they acquire my password in any way other than a total compromise of my password manager, then 2FA still protects the accounts.

If an attacker is able to compromise my password manager, then quite frankly, I have much bigger issues to worry about than my 2FA codes. But there are ways to make that harder, too. For example, some password managers also support 2FA (mine supports Yubikey).
Title should be: "TDD did not live up to MY expectations".

TDD is sort of an art more than a science. You have to know when and how to do it. You also have to know how much as the marginal utility diminishes very fast.
Ok I think that's fair and we're actually in alignment. Thanks for the well thought out response.
I would be staggered if Norvig's approach ever wasn't constraint propagation and backtracking.

Solving Sudoku is blindingly obvious even to mere mortals with even a iota of exposure to computer science and algorithms.
Typically premiums are equal to or less than the expected payout for a given policy. Insurance companies make most of their profit off of the float (return on investments made with premiums as the principal).

Health insurance really ought to be separated from a health plan which covers entirely predictable and expected expenses.
This (implied or not) seems to be the premise of many of these fads.

On the flipside: I think TDD is great for people who love writing code more than they love getting results. They get to write twice as much code!
I got front paged once a few years ago, it was about 15,000 page views in the course of a few hours. It's probably grown since then, but sure by what factor.
> there is no foolproof way of implementing that pseudocode's "has_seen(message.id)" method

Wait why? Just because you'd have to store the list of seen messages theoretically indefinitely?
When you look at the TDD evangelists, all of them share something: they are all very good – probably even great – at design and refactoring. They see issues in existing code and they know how to transform the code so it doesn’t have those issues, and specifically, they know how to separate concerns and reduce coupling.

I think one of the selling points of TDD, and something I hoped for from TDD, was that causation went the other way, and writing tests would result in code being refactored to separate concerns and reduce coupling. Sadly, I've seen that it is possible to write code that is highly testable but is still a confused mess. What's more, TDD as promoted encourages people to confuse the two, resulting in testability being used as a reliable indicator of good design, which produces poor results because it's much easier to make code testable than it is to make it well-designed.

I've also seen people mangle well-factored but untestable code in the process of writing tests, which can be a tragedy when dealing with a legacy codebase that was written with insufficient testing but is otherwise well-designed. A legacy codebase should always be approached with respect until you learn to inhabit the mental space of the people who wrote it (always an incomplete process yet very important), but TDD encourages people to treat untested code as crap and start randomly hacking it up as if it were impossible to make it worse.

This unfortunate (and lazy) habit of treating testability as identical with good design is not a mistake that good TDD practitioners would make, but I think they did make a mistake in the understanding of their process. My guess is that when those people invested effort into refactoring their code for testability, they were improving the design at the same time, as a side effect of the time and attention invested combined with their natural tendency to recognize and value good design. They misunderstood that process and gave too much credit to the pursuit of testability as naturally leading to better design.

I do think the idea of TDD is not entirely bankrupt, because the value of writing tests is more than just the value of having the tests afterwards, but I think its value is overblown, and people who believe in the magical effect of TDD end up having blind confidence in the quality of their code.
I think they misuse the word "critical" in the first paragraph. Surprising for Science.
TDD should not be taken as a religious dogma. The way I like it is, central business logic as pure functions, which have tonnes of unit test. While integration with other services and components sits on edge which do not have unit tests, instead integration tests. If I have a key piece of code, I wanna test, but would require lots of mocks, it is time to refactor.
Step 1, for success, is moving away from the Bay Area.
> I don't believe LE has an upper limit on its number of SANs.

The limit is 100, unless they removed that when I wasn't looking. Back in the beta I tried one domain, a handful and then, because I couldn't find a technical reason why SAN should be limited, I tried 500. It fails. I have many certs with up to 100 and would be happy if this changed.
Wow, the data point about rape is an interesting tangent. I guess with people like 45 and all the stories from Silicon Valley, it's not that surprising. But sad none the less.

Maybe we can follow the OP's lead and use technology to automate data collection around this and come up with better solutions.
Experiences as a female ceo
How to сreate a сity builder game in java
IIRC last time I saw a study on this it was pretty high. Well in the 95% range. But there would usually be a phone or two on every 737 or larger sized plane not in airplane mode.
What are some examples of X? I've never gotten the "because insurance" response so you've raised my curiosity!
I think what's happening is that your doctor will attempt to get as much money from the insurance company as he/she can.

My wife has experience of the doctor's office asking insurance company for $X, and the insurance company comes back and say "no, max $Y". So then the final "cost" all of a sudden becomes $Y. Pay attention to the claims that your doctors send to insurance company and you might be able to see that.

So instead of telling you, yes, whatever procedure is definitely just going to cost $Y. They can't tell you how much things are. It depends on maneuvers with other players in the industry.

This is very different than say in Canada. If I want to get a teeth filling in Canada, my dentist straight up tells me how much before the procedure. If I want to price shop that, I can. In the US, nobody is willing to say how much, because "it depends".

It's not because intrinsically there can't be price transparency. It's because of all the messed up incentives that the industry has that causes US health care to be as such.
I'm sorry, now when I'm re-reading the said article, it looks like what I meant were some related comments:
https://news.ycombinator.com/item?id=13650730
Several people complain that the voids space after Delphi[1] has never been filled in with something that would come close in the speed and easiness of development of desktop applications.
[1] not that it doesn't exist, but it doesn't count anymore, mostly because of its exorbitant price
I don't know much about it, but the answer to your last question definitely seems to be yes.
Ah. Exactly the misunderstanding I was labouring under.

Turns out we are all in agreement after all.
I think that he needs to improve his conversation skills first.
NYC dating: water water everywhere but none that I'll drink more than a sip of in anticipation of finding a better glass. paradox of choice indeed.
The whole thing at the time was 'test driven design' - the idea that by writing tests, you could iterate your way to algorithms that solve problems you couldn't solve by critical up-front thinking.

Test Driven Design fizzled and quietly died just after the Sudoku Fiasco ;)
Hah, this made me think of cooking Hamburger Helper - 20 minutes cook time with 3 minutes of my time spent in preparation.
That'd definitely be a pretty effective limitation.
This reminds me of a very humorous high frequency dating story https://web.archive.org/web/20170325010439/http://robrhineha...

(previously discussed here: https://news.ycombinator.com/item?id=6773841)
I have Kaiser insurance which is an HMO with straightforward pricing for most things. One fixed copay for doctor visit, one for specialist visit, one for outpatient care, etc. The problem is you are stuck using only Kaiser facilities and doctors.
>> I can't really choose whether or not I get psoriasis or have a heart attack.

Because being overweight can lead to adult onset diabetes, I'm choosing to slim down so as to have a better chance at living.
Health insurance is just broken. The only way it gets better is if something forces them to view the entire country as one actuarial pool.
Presumption of Stupidity
So, a combination of a best effort "at least once" messaging with deduplication near the receiving edge. Fairly standard, honestly.

There is still a potential for problems in the message delivery to the endpoints (malformed messages, Kafka errors, messages not being consumed fast enough and lost), or duplication at that level (restart a listener on the Kafka stream with the wrong message ID) as well.

This is based on my own pains with Kinesis and Lambda (which, I know, isn't Kafka).

In my experience, better to just allow raw "at least once" messaging and perform idempotant actions based off the messages. It's not always possible (and harder when it is possible), but its tradeoffs mean you're less likely to lose messages.
And SyFy. There is very little that comes out of them that is even watchable.
> some strange design decisions with basic list data structures

What are those?
Previous Discussion (~2 years ago) here: http://www.aaronkharris.com/presumption-of-stupitidy
It's not 100 million web sites, because Let's Encrypt certificates expire every 90 days, and you have to get a new certificate if you want to add or remove a domain name, and you can get duplicative certificates as long as they're within the rate limits.

As I said in my post at

https://www.eff.org/deeplinks/2017/06/lets-encrypt-has-issue...

it's probably between 17 million and 46 million web sites, although it could be a bit smaller than 17 million at the most restrictive notion of "web site" if you don't consider subdomains to be a separate web site even if they have different content and are operated by a different person.

You can see all of the certificates at

https://crt.sh/?Identity=%25&iCAID=7395
https://crt.sh/?Identity=%25&iCAID=16418

and you can also get a lot of the data from

https://scans.io/

or https://www.censys.io/ (registration required), although the people running it told me in connection with this that their Certificate Transparency data is not as current at the moment as crt.sh's data.
I agree, to me the second biggest industry acceptance that is counter intuitive is that insurers need to make money off of the float. Why can't an insurer come along who charges a fee for the service of ACTUALLY BEING ACCESSIBLE TO THE CUSTOMER. Intead of fax me this paper and wait two months. I am paying the insurer on the basis that they want to draw out any claim I have.

"All I've heard so far are physicians who don't accept insurance but instead have a straightforward "menu" for common items, which is interesting but not what I think most people want." - I think people want this but they are scared of going off of insurance in the event they need to see someone who doesn't offer this (chance occurance, expensive disease).
Because there is only so much talking is going to do, at some point you just need to build a prototype and see if it works and how it can be improved.

If pre-planning, talking and requirements solved this problem we wouldn't see failed (software) projects and companies. As a matter of fact, extensive requirement gathering before prototyping and iterating is a good way to fail a project as at some point you're just adding new towers to your castle in the air.
Community GPU research supercomputer
The heart of the statement is that he is denied standing on public interest grounds because they dug up a case law that effectively nullified public interest ground exception which comes from u.s. code.

Now if he is to proceed further, he needs to find ground to bust that case law and an insane legal doctrines it is based on
Well, your argument makes perfect sense ... just not as a reply to my rhetorical question ;-)
For components, bundling the CSS makes sense. For other use cases external CSS resources with inheritance are very beneficial.See for example Scalable and Modular Architecture for CSS or any modern CSS framework for lots of examples.
The House of Lords is an absolute mess of an institution but at least they can't actually pass or prevent the passage of legislation. Their powers are limited to amending bills, making recommendations, and delaying legislation.
Skip is hiring wireless systems/FPGA engineer to enable autonomous retail
It moves a lot of mass out the the end of the suspension system that comes with a lot of problems for handling. Also with the motor on the hub all of the shocks directly hit the electric motors where they don't in a normal car setup with motors and drive shafts and the bearings in the motor have to directly bear the weight of the vehicle.
If anyone has a suggestion on how to deal with that problem, I'd love to hear about it...

I am an Environmental Resource Management major who had plans to become an urban planner, and then life got in the way.

Have you attended any local board meetings? Do you know what the policies are? Have you looked up any not-for-profits or think tanks that have an interest in such issues?

This is going to tend to be solved by things like zoning laws, good review processes and advocates actively trying to preserve open space, build parks and protect neighborhood character.
The clever part is that the server doesn't know if the user has the setting on or off, so it can't cheat the security without risking detection.
Opens with the secretary problem and shows no evidence of actually following the algorithm.
> I'm guessing HHVM only really powers the API, business logic, etc.

So "only" everything except UI (which is run by the browser, not FB's servers), then. And that's only for browsers that use it at all, as they still need to render a lot of stuff from the servers both for speed and for people who turn off js or use older or limited browsers.

And this is a weird thing to say anyway, nothing runs "on" react; both the framework(s) and the business logic run on something else.
> Racket does not suffer from the issues of incompatibility

Just pick any language implementation exclusively -> no more incompatibilities.

> With Common Lisp it comes much earlier than is typically expected by programmers today. StackOverflow is more likely to be a first attempt at problem solving than Steele's Common Lisp the Language.

Well Steele's Common Lisp the Language is outdated anyway. Today one uses the ANSI CL standard, which is less confusing than CLtL2, which was documenting a language in flux.

Actually I don't think Common Lisp users will need to refer to documentation earlier than Racket or any other complex programming system (Java, Scala, Haskell, ...).

I have seen now a lot of people coding Java and I can tell you that documentation-less attempts at development don't work well. Many of the programs and coding styles I have seen are just horrible. It's actually kind of sad. I have seen senior Java developers not knowing how the language works at basic levels, even though they claim to work with complex frameworks.

Recently I have interviewed a professional Java programmer with a few years experience and he had lots of free time at work. He could have read some books to learn something instead of looking out of the window, but he said that he wasn't interested in computer science anyway... though it might have been a joke, I fear it was serious... Anyway, he was a nice person and had some potential.
That's already happening. Twitter bid for Thursday package of NFL in 2016 https://www.usatoday.com/story/tech/news/2016/04/05/report-t...

Then Amazon bid for the same package in 2017 https://www.usatoday.com/story/sports/nfl/2017/04/04/amazon-...

Facebook just signed up to stream select UEFA Champions League games, but sounds like they bought extra inventory from Fox, not entered a straight-out bidding war https://www.bloomberg.com/news/articles/2017-06-27/facebook-...
I work at Ericsson (one of the largest radio companies in the world) and we have towers that crank out 80w for 4g/5g. Mind you, I'm a software guy, not a hardware guy.

Elevation and line of sight are important but power is too!

Ctrl-f "watts" on this page to see what I'm talking about:

https://www.ericsson.com/en/networks/offerings/connecting-th...
Maybe learn how to treat another human like a human and step out of his own head for a second, might work better than 'engineering' love
For routine things, your responsibility is a flat amount, usually printed on your insurance card. So you know, for example, if you go to your general physician, you pay this much. Go to a specialist, pay this much. Go to emergency room, pay this much.

For more complex things, it's usually:

1. Not possible to know in advance everything that will need to be done. Many medical procedures are not things that just go identically every single time, and complications can occur during the procedure. Having to call it off, re-quote, re-schedule, etc. is not optimal.

2. The doctor likely doesn't actually know how the procedure will be billed. Medical billing is done using standardized codes to describe procedures, and the doctor will have someone who knows how to do that, but that person may not even work in the same building as the doctor. And the sets of allowed codes and how to use them can change quarterly, and that's without getting into the arms race of doctors trying to "up-code" (rather than the most obvious code for a procedure, find a way to bill it as multiple procedures or as a plausible but higher-paying code, since doctors and insurance companies are locked in an eternal battle of doctors trying to make as much money as they'd like and insurance companies trying to pay as little money as they'd like).
Would Common Lisp be Zerg or Protoss technology?
Totally agree. I'd really love to see Japan's ETWS system rolled out on the US west coast.

I was in Japan earlier this year, and happened to be watching TV when the earthquake warning system cut in. It gave about 5-10 seconds of advance warning before an earthquake hit. Enough time to move out of the way of anything heavy. It's quite impressive.

If anyone's curious, this is what it looks like:
https://www.youtube.com/watch?v=lAxxZkpV0HI

(The earthquake early warning cuts in at 0:15, and a tsunami warning automatically cuts in at 2:34... though most of the tsunami warning is cut off at the end. This is what the full earthquake+tsunami warning sequence looks like: https://www.youtube.com/watch?v=qMNu8Y1jIlU)
A mostly good thought experiment, IMO, if pointless since it's never going to happen.
To be blunt, you're the one who complained about the outcome in your blog post and the one who is angrily seeking validation in Hacker News comments by personally attacking critics and saying nobody understands your unicorn or your boldness in rolling the dice.

If your goal was to get some job offers, great. I got the impression that wasn't your goal, though. That you're fine, personally...well, I assumed that, given you bothered to blog about it. But yes, that's good. I hope that's true of everyone else involved.

But to answer your last question...it's the wrong question. The real question is whether it's smart to pin all your hopes on a really unlikely way to succeed when other approaches exist. Most people who write novels, become actors, etc. don't quit their day jobs until they actually start to make it. Food trucks that don't turn a profit don't tend to get investors to save them. Most new businesses aren't wannabe unicorns.
That's actually a response to the insurance company performing a type of information arbitrage with multiple other parties.

You could have health insurance with transparency, but there is too much profit potential in forcing information asymmetry between all of the parties involved in the system.

Every time that you think...doctors...hospitals...nurses...are up to something, most of the time it can be tracked back to insurance companies and the sway that they hold over congress with their money. I'm not saying that there aren't doctors, nurses, hospitals trying to gouge people. I'm just saying that insurance companies are worse. (With some very rare and egregious exceptions.)
The resignation letter is actually a great read. I think the author summarized the situation quite well :

"We see little benefit accruing to our community from a mechanism
that ensures revenue for a third party by restricting the communication
channel between authors and readers."
Could advances in this field be used to help blind people to "see" faces etc. by bypassing the eyes and instead directly communicating with the relevant neurons?

I would love to read the research paper but unfortunately it is Elseviered!!!
Sure, Norvig knew how to solve the problem from the start.

But that's another reason why the "TDD Sudoku Fiasco" blogpost isn't a terribly useful source of information (or, from another point of view, why it isn't a great way to persuade a TDD afficionado to change their mind).