ambulancechaser

that is a really weird and really wrong thing to think about contracts.

That doesn't seem particularly different that desktop software. Pretend s/he said that once they got to off of WinForms and onto WPF they could iterate on the UI design. or maybe once they upgraded GTK, or whatever.

You don't have any inherent right to arbitration. You _do_ have a right to access to a court. Arbitration _is_ only there if both parties agree to it.

Your perfect world is captured by current employment contracts. Both sides agree to arbitration and then both sides stick by that agreement.

Totally agree. This is why I'm going to get a T480 thinkpad with 32GB for my next linux laptop next week rather than this.

that's true, you can recreate it in some sense but you can't get to what F# can guarantee. A big promise of discriminated unions is the ability to make invalid state unrepresentable. Matching on the different type constructors is a fantastic way to only express coherent states.

We found it quite nice for properties of objects that appear over time. Think things like Order that might or might not have delivery details. In C# you are making classes with nullable delivery timestamps, delivery person, etc. And one or two properties isn't that bad but it gets a little onerous when you start to have constraints like "these four properties are either all null or all populated". In F# it is trivial to set up a new constructor for Delivery that includes all of these properties. There is no unspoken agreement about that, you can set it in the model.

this seems to be highly downvoted as i suppose people are reading it as a rude aside, but I read it as a feature worth highlighting. Microsoft has an excellent track record with language design, promotion, stability, and tooling.

A part to consider is whether the other party knew or should have known of a mistake.

It's not reasonable for FanDuel to assume a mistake there. However, if a customer purchased a bet on a game that had already happened it would be reasonable to assume a mistake had been made.

Mistakes happen and the law of contracts deals with them.

Can you point to a violation of this observation? Operating systems, CPUs, compilers, and software at large have all had bugs. Can you point to anything meaningful that has not been susceptible to bugs in production?

> good development practices, good requirements, good change control, and good testing can prevent the vast majority of bugs

prevention of the vast majority of bugs does not negate the claim that bugs will always happen in production.

I'm reading this paper to follow along with this excellent implementation in Clojure of regular expression matching of sexps: https://github.com/cgrand/seqexp

Ghadi also made a version to parse PEG grammars but the VM is done in java i believe. Great talk about it:

talk: https://www.youtube.com/watch?v=9Q--oX5muxw project: https://github.com/ghadishayban/pex

I think the more important thing might be the consent part. Check out clickwrap or clickthrough consent. The technical bits of this can become extremely tricky and extremely important.

you're extolling the benefits of USB-C not the lack of USB-A. The presence of a USB-A would not affect your listed benefits in the least.

My understanding is that diversity isn't a goal as much as lack of diversity is a symptom that something is wrong. The idea is these immutable characteristics have no bearing whatsoever on the quality of the candidate, so what in the process is removing the underrepresented groups.

spec is wholly independent of the pre/post conditions.

would this be CA territory?

> plagiarism is taking credit for someone else's ideas at their expense;

that seems like an unworkable definition. If I submit John Milton's Paradise Lost as my own work on an application to grad school, it certainly wouldn't be an "expense" to the long dead author.

Plagiarism is a fraud where you misrepresent the work of others as your own. In the academic world, what else is there but your own work?

I think "this industry" might be a bit broader than a bunch of CSS experts or even people competent in CSS. This seems to highlight his point rather than dismiss him as a developer. He's not a CSS guy so having people there with him gets his work done faster and helps him understand.

> "We sat down one morning," recalls Steele. "I was at the keyboard, and he was at my elbow," says Steele. "He was perfectly willing to let me type, but he was also telling me what to type.

> The programming session lasted 10 hours. Throughout that entire time, Steele says, neither he nor Stallman took a break or made any small talk. By the end of the session, they had managed to hack the pretty print source code to just under 100 lines. "My fingers were on the keyboard the whole time," Steele recalls, "but it felt like both of our ideas were flowing onto the screen. He told me what to type, and I typed it."

> The length of the session revealed itself when Steele finally left the AI Lab. Standing outside the building at 545 Tech Square, he was surprised to find himself surrounded by nighttime darkness. As a programmer, Steele was used to marathon coding sessions. Still, something about this session was different. Working with Stallman had forced Steele to block out all external stimuli and focus his entire mental energies on the task at hand. Looking back, Steele says he found the Stallman mind-meld both exhilarating and scary at the same time. "My first thought afterward was: it was a great experience, very intense, and that I never wanted to do it again in my life."

> - Guy Steele on a hacking session with RMS in the 1970s.

I always like this story. And I wish I had an experience like it.

i think people are interested in the lessons learned in the past. are you sceptical or hopeful? how did apple's stab at this work out in the past? is it fundamentally flawed or deeply overdue.

wouldn't the NDA in a case like this just be about the embargo? If this is the case, what strong argument against an NDA is there given that agreement not to disclose the bug is necessary until a good mitigation strategy is in place?

but removing branch prediction would be to restore those stalls and inefficiencies as the way things are when you don't use those strange data structures, right?

The effect of this seems to be "I wish everything was slower and then the naive implementation would be the best implementation".

i think they're talking about production run time versus development runtime. think of it as turning asserts off on production builds. but spec can conform data and explain the reason for non-conformance so some might leave some spec in production for logging, messages, etc.

I think that that is the person's point. This is several years of development which amounts to wasted resources in light of the manufacturing setbacks of their truly disruptive product.

I think the article was saying that the javascript version of the google closure library is slower than the jvm based version so this would actually be a little bit slower.

Further, it has a serious restriction in that the version of cljs used by lumo itself is now the version of cljs that your project must use.

The cljs version is a pretty serious caveat but this seems like a really nice milestone on quite a bit of work. kudos to anmonteiro

its as hidden as control-alt-delete.

undoubtedly that person was talking about LINQ and not var usage

I was there and you are right, he was very nervous. However his talk was excellent and approachable for everyone reading the above comment. Explains the differences quite well. Certainly worth a talk. I've asked on the clojure slack group if the proposal had gone anywhere and it seems to have stalled unfortunately.

> And as for its impact on you: Do you understand that at this point, I could not in good conscience assign anyone to work with you? I certainly couldn’t assign any women to deal with this, a good number of the people you might have to work with may simply punch you in the face, and even if there were a group of like-minded individuals I could put you with, nobody would be able to collaborate with them. You have just created a textbook hostile workplace environment.

https://medium.com/@yonatanzunger/so-about-this-googlers-man...

the 50:50 ratio is taken to mean there are no inhibitions or advantages for one or the other as this is the rough ratio of male to female in the general population. The skew of the ratio can be read as there are some factors we aren't seeing. So the question isn't "why do we need this ratio" but "why isn't this ratio present?"

No one cares who writes their code either, but certainly we can agree that if there are systematic reasons preventing women from participating as much we can try to remove them?

I've seen this logic about choosing a library but I think you are attributing a different rationale to it. I've seen it said if you find more than one library doing what you need, go through a hierarchy of criteria to choose and choose the first one that wins; in the event of a tie, evaluate the next point

1. pick the one with the most readable, understandable architecture 2. choose the one that focuses more on what you are looking for and not a slew of different things 3. choose the one with fewer lines of code

This third point is not "choose the more clever library" but more along the lines of choose the more straight forward and simple library. It's not code density you are evaluating but focus.