copascetic

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.

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.

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".

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.

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.

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

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.

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.

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.

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.

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".

The type of a string literal is array of char, and like other arrays, they decay to pointers to the first element when used in expression context, with three exceptions: sizeof, taking the address with &, and when used as a string initializer. "test2" in your example is not a const char *, it's an initializer, since this is one of the exceptions to array-to-pointer decay.

http://c-faq.com/aryptr/aryptrequiv.html http://c-faq.com/decl/strlitinit.html

Because a macro in C/C++ is just text expansion, the given implementation will evaluate its arguments more than once, which will not be obvious at the "call" site and could have unintended consequences if the expressions have side-effects.

This is entertaining. I've used Xilinx's tools for a while, almost exclusively on Linux (CentOS usually). I thought that renaming/symlinking libraries to get things to work was something only Linux users needed to do, and I figured this was just because Xilinx tests more on Windows (makes sense). If these kinds of problems also affect the Windows versions, then, I don't even know what to say. At some point you just can't make excuses for this stuff anymore.

See my other response, but I don't think you're giving the question enough credit. The other responses don't mention the fact that the line would likely be different if we swapped the variables. The question tests both whether you know what a line of best fit represents, and also whether you know that the correlation in one direction is not necessarily equal to the correlation in the other direction. This is something that could be covered in an algebra class with a unit on linear regression. I remember seeing a demonstration and explanation of this in mine.

The line of best fit changes depending on the choice of independent variable, even for the same data. The quantity being minimized is different for the two cases. (sum of squares of vertical distances between the line and the data points vs. the same for the horizontal distance)

The question is very specifically about the interpretation of the slope, and because the slope would be different for the other case, only one of the answers is correct.

When you specify the types of the numbers used, so that you are testing the transitivity of a single instance of Eq, you will find that transitivity does hold in this case.

  a :: Double
  a = 2^53

  b :: Double
  b = 2.0^53

  c :: Double
  c = 2^53 + 1

  main :: IO ()
  main = do
    print $ a == b -- True
    print $ b == c -- True
    print $ a == c -- True

This example is misleading, and I don't think the article addresses the subtleties.

Basically, the third line is not like the other two. Because none of the numbers involved in #3 are Doubles, Haskell will actually use the Integer type, which is basically a bignum (like integers in Python).

The first two are comparing values of type Double, so the instance of Eq for Double is used, which necessarily has some inaccuracies, as shown in the second line, while the last one is using the instance of Eq for Integer. Therefore, the statement that (==) is not transitive for these types is false, because we are talking about different versions of (==) in the first two examples vs. the last one.

The trick is that bare numeric literals have type Num a => a, and have their type inferred by their use. The first two examples cause the 2^53 to take on type Double, otherwise it wouldn't type check (literals with decimals in them have type Fractional a => a, of which Double is the default). The last one doesn't have any expressions with decimals, so it uses the Integer type.

Linearity of expectation applies to any two random variables, not just ones that are independent. The issue is that these games are not random variables, they are random processes (sequences of random variables) with state affected by the choices you make and previous outcomes. Linearity of expectation is irrelevant.