There are some short comings about using email codes but I fail to see how this worse than passwords when the same exact kind of attack would work for passwords. The difference being that it would be worse with passwords which can be stored, reused later or sometimes changed directly on the service.
Readit NewsNevor commented on Emailing a one-time code is worse than passwords blog.danielh.cc/blog/pass... · Posted by u/max__dev
You can create content on tablets, and some of it is excellent content.
Development isn't done on tablets because the input devices we have to make code are limited to a keyboard, and most people think text files are code, rather than a serialisation/deserialisation format for an AST.
You could easily build an AST with gestures and speech rather than tapping buttons, and I think in 10-20 years time that's how we'll make software.
Actually AST edition with touch interface has been experimented by MS Research with Touch develop (https://www.touchdevelop.com/). In their editor you just insert/combine AST parts instead of typing them.
Nevor commented on Ten Years of Git: An Interview with Linus Torvalds linux.com/news/featured-b... · Posted by u/lclark
I thought that F# used type-inferencing? If not, then its not nearly as similar to Haskell and OCaml as I've been led to believe.
Unless you're referring to type-inferencing when you use the term static duck-typing. The term duck-typing was never meant to refer to type-inferencing - duck-typing is type-opacity right into the runtime. The whole point of duck-typing is that objects can be referred to generically even in cases where their underlying type would be undecidable.
Type-inferencing gives you some of the source-level flexibility of not having to refer directly to an object's type much like duck-typing, but without many of the crazy runtime disasters that you can get with duck-typing.
Parent comment is referencing the "let inline" construction that in addition to inline code allows to constrain generic types structurally over member definition[1] instead of by name as usual. This gives us poor's man type classes which is useful nonetheless.
I guess the conclusion is that the definition of duck typing is fuzzy and misleading.