copascetic

5 年前議論

If you look closely at how that data was collected, what it's actually measuring is whether a binary links against the ObjC runtime library, which will be the case if a binary transitively depends on any ObjC framework, so even if all new frameworks and executables were written in Swift, we would still expect to see the number presented in that post to continue to grow until most or all of the important frameworks using ObjC are rewritten entirely in Swift. I don't think this data is sufficient to say one way or the other to what degree that is occurring.

copascetic

6 年前議論

If you just bought a new Intel MBP then you got a horrible deal by comparison. I also didn't say the review was nonfactual, just that it contains within it an inaccurate framing and conflation of M1 as a processor and the overall product. It's worth noting though that many others' experiences with it, and Rosetta 2 specifically, were quite different than Moorhead's, so unless you're using the specific set of software Moorhead mentioned in his review, it's very possible you would have been better served by an M1, even today.

copascetic

6 年前議論

Yes, and if you wrote such a review, and many have I'm sure, you wouldn't say that the electric drivetrain itself "has warts".

copascetic

6 年前議論

It's easy to rewrite that sentence to make that separation clear, and he doesn't. Gruber goes into detail about the author's history of being wrong and misleading in the past regarding Apple's processors, so in that context I think it's fair to take that part of the review in bad faith.

copascetic

6 年前議論

> Morehead's allegiances and work are relevant biases, as are Gruber's. But Morehead's review wasn't of the M1 processor or architecture as a technology. It was a review of the 13" M1 MacBook Pro as an end-user device.

Moorhead's review literally contains this sentence:

> The new M1 processor is impressive, but far from perfect- it has many warts, that nearly nobody is discussing.

He then proceeds to describe not warts of the M1 as a processor, but rather warts of the 3rd party software ecosystem. I think overall the review is fine and not in bad faith, but it's easy to see how people are latching on to that sentence. If he were honest about making it a review about the overall product experience, rather than the silicon, he wouldn't need to write that sentence.

copascetic

6 年前議論

C, C++, Java, and Rust all have shift as lower precedence than addition/subtraction. Edit: and Javascript, Python.

copascetic

6 年前議論

If you'd carefully reread the post you'll see that your first assertion is false. It contains this sentence: "But it is a meaningfully distinct kind of type safety from the one I highlighted a year ago, one that is far weaker." The antecedent of "one" is "type safety", which is being provided, just, weaker, not "not type safety" as you claim.

As for whether the example is being "dismissed" or not, I also think that's manifestly false. See: "[this tradeoff] is often a very good one!" while still diving into exactly what the tradeoff is.

copascetic

6 年前議論

Again, you are conflating newtypes per se with approaches using newtype as part of an overall abstraction and interface design including constructor hiding. The post makes this quite clear and the author and others have pointed out this distinction to you multiple times here. Just because you made an inference and argued against it doesn't mean the article was making such an implication.

Your second point is certainly arguable and does represent a substantive disagreement with the post unlike your first comment. I think the post makes a solid case that gratuitous use of newtype absent any abstraction boundary is an anti-pattern that provides little benefit if conversions are done ad hoc. Sprinkling on some newtype can certainly help some cases, but the post encourages critical thinking about these issues and explores where this reasoning falls down. If your claim is that critical thinking gets in the way of cargo-culting approaches that lead to "nominal" type safety then you would be right. Your last parenthetical doesn't seem like a reasonable response of someone who has read and understood this post. The post specifically encourages the use of newtype with abstraction boundaries where practical and works through an example.

copascetic

6 年前議論

I think the request is rather justified given your response, which is engaging with a strawman version of the thesis presented in the post. What you wrote about the virtues of newtype was explained quite well in the post itself, but you seem to want to disagree about something. You present another strawman in this reply:

> the claim that newtype-based approaches are not type safety

To use your phrasing, the claim is that newtypes do not in and of themselves provide type safety, but that "newtype-based approaches" can and do provide a weaker form of safety than constructive modeling. Further, it's important to understand what the critical additional steps are in such approaches to achieving that safety and avoid cargo-culting "newtypes make things type-safe", and to understand the ways this safety can be violated.

copascetic

6 年前議論

If Timescale were AGPL Amazon would be free to just run it as a service for profit and all they need to do is publish their modifications to it, if they make any. Amazon has no problem running all kinds of other open source software for profit, and this is what TSL is specifically designed to prevent.

copascetic

6 年前議論

How so? Corporations can use and sell software and run services for money that use copyleft software if they want to if they abide by the terms of the license, and some do, whereas the TSL specifically disallows this. How does AGPL exclude "all non-OSS companies"? These companies are choosing not to use AGPL software; that doesn't make AGPL not an open source license. The AGPL doesn't even require source code publication when run over the network unless you modified the code, so if Timescale were licensed with AGPL, Amazon could directly offer Timescale as a service and not even need to provide a source code download link. AGPL obviously does not exclude other companies from merely using the software in other ways, so I really don't see how the TSL is "strictly more permissive".

コメント