Rhombus massively advances the state of the art for macro systems in infix languages. Macros in Scala, Rust, and Elixer are extremely limited compared to Rhombus macros. The enforestation-based approach that Rhombus uses and the underlying Racket macro machinery means that things like Rhombus's class system, pattern matching system, annotation system, infix operator system, etc. are all implementable as macros. That's definitely not the case in Scala, Rust, or Elixir. Imagine if the base Rust language included only a macro system and `unsafe` code and the borrow checker could be implemented as a regular library in `std`.
Are you familiar with `syntax-rules` based macros? Because this is roughly the same logic here.
It's trying to unify how macros produce syntax objects via `syntax-rules`-style pattern matching and ellipses with how regular pattern matching on values works, so there aren't two separate pattern languages (one for macros and one for everything else).
I like the explanation there, and I think it gets me closer to my objection. I'm quite happy with the Kleene Star as a concept, but I don't think it corresponds to any usual use of ellipsis, nor is it really a list element on equal footing with the others.
This is not a disagreement on political positions, this is a belief that women are inherently less capable than men at software engineering. It's a direct attack on the legitimacy and humanity of his coworkers. A disagreement over political positions would be if the author wrote a manifesto about the efficacy of sin taxes or nuclear treaties, not that his teammate Sandra is biologically inferior at her job and undeserving of it.
It's no different than a guy in the NBA wondering out loud if the bias towards men might have a biological component, so that even if the systemic barriers are removed, we might expect far different than 50/50 female/male in the NBA. But no one thinks that - it's obviously silly because physical attributes are so obvious.
"significantly higher variance in male scores, resulting in more than twice as many men as women scoring in the top 2%."
But certainly that study and all the others are just wrong, or they're measuring the wrong thing and it's not applicable to software.
I dunno, perhaps the ratio should be 45/55 once the systemic bias is removed. Or maybe it's 55/45 - maybe the systemic bias is beyond terrible and males are worse at software and we've got it all backwards. Doesn't seem like there's anything supporting 50/50 other than some weird notion that everyone's not physically equal at all, but somehow our brains are.
I hate the high end examples, because people want to argue them. The case is also true the other way - there are more men at the bottom of the IQ scale. Can someone come up with a reason why an IQ test would make men appear more often in the bottom of IQ distributions?
I have no evidence, only speculation, but it could be because boys do not receive the same type of nurture and care growing up compared to girls. As well as, anecdotally, being more likely to engage in dangerous (for the brain) activities and take less care of themselves. The last point manifests itself in many ways, but the most important one I can think of is diet.
Again, this is all conjecture and I don't know how I would go about finding the studies to link it together.
It's completely unreasonable to take a critique on hiring practices or a broad statement about demographics personally. I'm not going to take offense to the statement that men tend to be more aggressive than women. Likewise, if someone claims that Google's policy of favoring elite schools leads to hiring underqualified candidates, would Googlers from MIT suddenly be offended? Of course not. However, that's precisely what you're suggesting with women.
Would you take it personally if those statements were commonly used to explain why you don't make as much money as your co-workers? Why you're more likely to be neurotic?
Those sorts of demographic statements might be fine to you, because they're not being used to explain why any current discrimination practiced against you is actually fine.
It still shouldn't be offensive. If anything, it is more offensive to suggest that wage discrimination is caused by sexism because that's an attack on character. Indeed, a lot of men are hurt by the suggestion that they may be sexist. However, it obvious that such discussions are necessary.
These statements might be hurtful and counterproductive, but they are a reaction to other statements which are perceived as being simply disregarding the reality of things. I can understand somebody making them just for the sake of reminding others what he thinks reality is. You can imagine plenty of situation in which the truth is ugly and hurts everybody- is that a good reason to let people do all sorts of intellectual contortionism just to avoid mentioning it?
On the other hand, any female engineer in Google earns more than I do, and deservedly so. I don't work at Google and I strongly doubt I'd pass their interviews.
> this is a belief that women are inherently less capable than men at software engineering
Should we therefore assume that women are equally capable as men at running the 100 meters, or at playing football? Don't get me wrong, I'm a male and probably half the women my age run faster than me or play football better than I do. But you know that this doesn't generalise: on average, men are faster runners and better football players. And you're ready to admit that because the thing is unequivocally measurable. Nonetheless, you consider any statement about gender differences that are not as easily measured as unthinkable and unacceptable. How is that?
edit: downvoters, please care to answer my question. I'm interested in your opinion.
Would you please not post this sort of meta dross? That includes adding references to downvotes in your comments. For a substantive comment, all of this stuff needs to be edited out.
Other programming ecosystems are at least an order of magnitude smaller and not intrinsically tied to technology that's in relatively extreme flux with a massive amount of users (browsers).
It's true that NPM is the biggest package repository by some way, but it's only ~2x the count of the Maven repository (492135 vs 194954). PHP and Ruby also have the same order of magnitude.
tied to technology that's in relatively extreme flux with a massive amount of users
Maven/Java has similar challenges to some extent with both Android and server side development being extremely common in the same language. The large number of users and the extreme technology flux is also similar.
The "Racket VM" is designed from the ground up for other languages to be built on top of it (hence the #lang line at the beginning of every file) so it would likely be much better. Hackett[1] is a Haskell-like lang built on top of racket, for a nontrivial example.
> We did what we always do when there's a problem without a clear solution: we waited. Waiting gives us more time to add experience and understanding of the problem and also more time to find a good solution. In this case, waiting added to our understanding of the significance of the problem, in the form of a thankfully minor outage at Cloudflare. Their Go code timed DNS requests during the end-of-2016 leap second as taking around negative 990 milliseconds, which caused simultaneous panics across their servers, breaking 0.2% of DNS queries at peak.
This is absurd. Waiting to fix a known language design issue until a production outage of a major customer is a failure of process, not an achievement. The fact that the post presents this as a positive aspect of Go's development process is beyond comprehension to me.
They did the same thing with adding a “round” function. As a result, there are myriad implementations of round() in the wild in Go, and almost every single one is broken in several ways.
It's not absurd. This methodology may not be best for everyone, but imo it's best for the language its self, and seeing as Go is one of todays fastest growing languages the developers must be doing something right.
Note that at no point in the post whatsoever were any contributions to these specific issues from outside the core maintainers thanked or even acknowledged.
FWIW I think this is a fair criticism. We've had so much help from the Go community, not just for those two issues but also for essentially all the work we've done since the release in 2009. Go simply wouldn't exist without the community, and we're very grateful for it.
I couldn't fit any kinds of thank yous into the talk, except for the credit to the overall community in the first few minutes, because I had a lot to say and only 25 minutes. It's possible I should have written an extended blog post that was more than just the talk, but I didn't - the blog post is just the talk, as it says.
It's worth noting that the argument against call/cc is specifically against undelimited continuations. Delimited continuations, such as those created by the `shift` and `reset` control operators, do not suffer from the problems of call/cc.
Then why does their behavior disproportionately affect women, who have less power to complain about their behavior? If this were entirely an aspect of their character or personality they'd be an asshole to everyone equally, not opportunistically take advantage of people who have less ability to stop them.
I think they often are. But you don't hear about it, because almost no one cares about males at the bottom of the social ladder. At the bottom, men are "valued" (for a lack of a better word) even less than women.
Or perhaps being an asshole to someone in the mailroom because you didn't like the way round a letter was put on your table is not in the same scale of things as trying to coerce someone to have sex with you
>Then why does their behavior disproportionately affect women
I'm sure they use their positions of power in many different ways that affect both men and women, but their sexual advances obviously target women because most of them are straight.
Part of poor character is picking on people from a position of power, when they have something you want. Part of poor character is putting your urges ahead of your empathy.
Generally, when guys get screwed over by a terrible VCs it's "well they're a terrible vc ... you know them." But when it's by women "they crossed this boundry? I'm shocked!"
> These people are assholes because they know they can get away with it.
So yes, openly bigoted people are assholes. But if they knew their bigotry wouldn't fly, they would at least not be open about it and not be assholes to people.
>women, who have less power to complain about their behavior
The exact opposite is true. Almost nobody would take a man who complains about sexual harassment seriously. Just look at the night and day difference in response to teacher student abuse when the student is a guy or a girl.
I do not understand what world people live in where constant special concern is twisted into a lack of it. I mean, I do, in so far as it's just benevolent sexism masquerading as equality, but I can't wrap my head around those people considering themselves rational.
Some property testing tools like Python's Hypothesis[1] allow specifying specific example values for properties in addition to a general set of values so you get some specific deterministic tests. Hypothesis also saves falsifying values it found previously in a database that it reads from the next time you run it.
I'm curious how the database works with, say, external CI systems like Travis and on multi-developer projects? Is it (or can it be, sensibly) committed to the repository or otherwise persistent with/near the code so that it transfers across machines and everyone gets the same testing environment?
Of course, with randomised testing, there's an inherent non-reproducibility, so maybe this isn't as unfortunate as it sounds?
For CI systems like Travis, people add it to the cached directories, and it's shared between runs. I know Travis, Circle and AppVeyor all have some way to cache data between runs – nominally for dependencies, but .hypothesis works too.
According to our docs (http://hypothesis.readthedocs.io/en/latest/database.html?hig...), you can check the examples DB into a VCS and it handles merges, deletes, etc. I don't know anybody who actually does this, and I've never looked at the code for handling the examples database, so I have no idea how (well) this works.
If tests do throw up a particularly interesting and unusual example, we recommend explicitly adding it to the tests with an `@example` decorator, which causes us to retest that value every time. Easier to find on a code read, and won't be lost if the database goes away.
I think the default storage format Hypothesis uses is a flat file with a diff-friendly format so it's easy for developers to check it into source control, and it's easy for patches to update the database without exploding the git repo size due to giant binary diffs. Sqlite3 might also be an option but I'm not up to date on the details. As a neat side effect of the diff-friendly format, it's easy to review new falsifying inputs added to the database in pull requests.
