bilboa's comments

I suppose the main reason I think it's hyperbolic is because I disagree with you that this is a critical feature. First of all, I've written lots of scores with MuseScore and Sibelius and I don't remember ever missing this feature. It's possible at some point I tried to drag a note around and realized I couldn't, but if so I've forgotten because it's not remotely close to being a critical feature for writing scores, at least not with my workflow.

Second, I'd point out that Sibelius also doesn't allow dragging notes around, and now that I think of it, I haven't seen any GUI notation software that does. Either the developers of all of these apps made the same oversight and haven't realized how obviously critical and non-problematic this feature is, or, maybe the people who responded to you on MuseScore forums explaining that it actually would be a problematic feature are right.

I downvoted your comment, not because I'm a MuseScore apologist, but just because calling an extraordinarily complex piece of software like this "trash" just because it's missing an obviously-useful-but-non-critical feature, seems extremely hyperbolic.

Exactly. I did get the impression that the author is more familiar with OCaml than Rust. However I don't think they were claiming Rust's greater low-level control makes it inferior to OCaml in general. They're just saying it makes it less suitable for writing compilers, since (in the author's opinion) this level of low-level control isn't necessary for that task.

It seems too early to say "no one else is able to replicate it", given that the claim was only posted to Twitter yesterday, and the Gizmodo article linked to here was only posted 4 hours ago.

It's the opposite for me. Typing seems to have gotten easier. Especially now that Apple added their own swype-like functionality, I've found I'm more willing to type longer pieces of text on the phone, where I previously would have waited until I could type it on a computer.

The point though is that the tone of his article seems to suggest that this is some scary "gotcha" of the language, whereas some of us consider this to just be the expected behavior.

I'm puzzled by your statement that "Coaxing the engine to use an index is much harder, if not impossible in postgres so far". If this were true it would make Postgres pretty much unusable for any non-toy applications, which is clearly not the case. I'm assuming there are some qualifiers missing from this statement.

You're interpreting the headline too literally if you what you took from it was that people care about the actual color of the messages. The point is that they care about preserving the advantages of everyone in a group chat being on iMessage. As soon as even one participant in the conversion is on a non-Apple device, the chat switches to SMS, and you lose some of the fancy iMessage features. There also may be a status component where some kids think iPhones are cooler.

Of course this doesn't apply to every group of people. As you say, in some circles other non-Apple chat platforms are more popular so this isn't an issue. But don't make the mistake of thinking that just because iMessage isn't popular in your friend circle that it's not popular in general.

While you may not have to directly call malloc and free in Rust, the memory management still feels very manual compared to a language with GC. When I want to pass an object around I have to decide whether to pass a &_, a Box<_>, Rc<_>, or Rc<RefCell<_>>, or a &Rc<RefCell<_>>, etc. And then there are lifetime parameters, and having to constantly be aware of relative lifetimes of objects. Those are all manual decisions related to memory management that you have to constantly make in Rust that you wouldn't need to think about in Go or Python or Java.

Similarly, idiomatic modern C++ rarely needs new and delete calls, but I'd still say it has manual memory management.

I suppose it's reasonable to talk about degrees of manual-ness, and say that memory management in Rust or modern C++ is less manual than C, but more manual than Go/Python/Java.

Sounds like you want jsonschema.

There are other reasons for deciding not to sell a house after advertising it other than pulling a bait-and-switch scam. Maybe the seller changed their mind about selling it, or realized the house is worth more than they advertised it for. The mere fact that someone placed an ad for their house doesn't legally obligate them to sell it. I'm not a lawyer so don't know what exactly would legally be considered a bait-and-switch, but I presume you'd have to show that the plan all along was to use the initial offer as bait in order to draw a buyer into some other deal.

Yes, the variable names in the case patterns are treated like variables on the left hand side of an assignment statement. Whatever value they may have had before is irrelevant. A pattern which consists solely of a variable name is a wildcard pattern that matches anything, just as it would be on the left side of an assignment.

Edit: It is possible to use constants or variables in a case pattern, but they have to be dotted names to not be treated like a capture pattern. So this would work for your example:

  class HttpStatus(Enum):
      NOT_FOUND = 404

  match status:
     case HttpStatus.NOT_FOUND:
         return "Not found"

>> This comes from the Ada design philosophy to be explicit in everything and to prefer the use of keywords over symbols.

This may be true, but it doesn't contradict the claim that Ada is old-fashioned in this regard. It was an old fashion in programming languages to prefer words over symbols, and to try to make programming languages look more natural language-like to make them more readable. See Ada, Cobol, Pascal or AppleScript for some examples. This is much less common with newer programming languages, where it's much more common to favor terseness and shortcut syntax. It's debatable whether this is better, but it seems undeniable that Ada-style verbosity is no longer in fashion.

Python's time.time() call is also going to be affected by system time changes and thus not guaranteed to increase uniformly. So Date() in Swift and time.time() in Python are the same in that regard.

I agree with you. I'm actually a big fan of both Haskell and F#, and use Haskell especially for a lot of my hobby projects. However the idea that either of them make a better scripting language than Python seems laughable to me.

I found the official docs on how python special methods are looked up.

https://docs.python.org/3/reference/datamodel.html#special-l...

Apparently the runtime is even more picky than I showed. The method has to be defined on the object's type, not in the object's instance dictionary. So, really the lookup is something like:

  if hasattr(type(a), '__add__'):

The link I provided explains the rationale for bypassing the instance dictionary and `__getattribute__` method.

This is because the actual translation of `a + b` is a little more complicated. It's something like this:

  if '__add__' in a.__dict__:
      try:
          return a.__add__(b)
      except NotImplemented:
          if '__radd__' in b.__dict__:
            return b.__radd__(a)
  elif '__radd__' in b.__dict__:
      return b.__radd__(a)
  
  raise TypeError('unsupported operand type(s) for +: '{}' and '{}'.format(type(a), type(b))

In particular, the runtime seems to directly look for '__add__' in the object's __dict__, rather than just trying to invoke `__add__`, so your `__getattribute__` method isn't enough to make it work. If you add an actual `__add__` method to A your example will work.

Agreed. I've read accounts from several elite players who were told they wouldn't be taken as seriously if they played a contemporary instrument compared to if they played a Strad or Guarneri, independent of their playing ability.

I think most people understand that rarity and antiquity have an intrinsic value to many people, including for violins. If someone said they value their Stradivarius because it's a piece of history, I don't think there would be much debate. What some people are skeptical of are the claims that antique violins also have better acoustic and playing characteristics than violins made by the best contemporary makers.

The other problem that T solves and nested doesn't is being able to reuse a spec. Once you have a spec, whether created with T or directly, you can call glom multiple times with the same spec, pass the spec to another function, tc.