Note that you still need to get consent for the cookie in this case, as the cookie is being used for something which isn't strictly necessary to provide the service.
Something pretty similar to the AST example in another thread can be implemented in Typescript using sub typing (as it happens, trying to do something like that is how I first found out about GADTs). Looking into existential types, I see that one of the things they can be used for is OOP style subtype polymorphism [1]. Are there things you can do with existential types that can't be done with subtyping?
"You don't hear about doctors being given a mystery patient and forty-five minutes to save their life using only a whiteboard"
That's actually a pretty accurate description of what doctors have to do, at least in the UK. For the first nine years after finishing medical school, doctors have to take a series of exams, including written exams and practical tests, which are primarily diagnosing and proposing treatments for real ("mystery") patients. This is a centralised process, rather than ad-hoc tests at every interview, but doctors do have to continue demonstrating their competence during their careers.
You might want to have something like `String concatenate(List<String> strings)` and `List<T> concatenate(List<List<T>> lists)`.
Java won't let you do this because types are erased at compile time, and Java doesn't know exactly what function it's going to call until run time (in order to allow dynamically loading classes). Haskell does allow something similar to this kind of overloading, because Haskell determines what function is going to be called at compile time, before type erasure happens.
Everything in JavaScript is passed the same way, whether primitive values or objects. Trying to graft a distinction between pass-by-value and pass-by-reference on top of this single passing method is unlikely to do anything other than confuse people learning JavaScript.
It is inspired by SICP, but in the sense that it fixes what the authors consider to be problems with SICP's approach. They've published various papers on their criticisms of SICP, eg http://www.ccs.neu.edu/scheme/pubs/jfp2004-fffk.pdf
CP/M was surely the direct influence. Wikipedia says CP/M was itself influenced by TOPS-10, which I think also used the slash for options, so the ultimate origin may be with DEC.
It kind of is a type error, in that the error comes from the programmer incorrectly thinking that the function has type t => r, when it actually has type (t, s) => r. It's not a type error from TypeScript's point of view, because according to TypeScript's rules, both t => r and (t, s) => r are subtypes of (t, s, u) => r. The point of type systems is to detect cases where the programmer is wrong about the types of some value they're using, so it is a limitation of TypeScript that it wasn't able to detect the error in this case (I'm not sure if there's a good way to allow it to detect this particular error while also maintaining compatibility with JavaScript, but it is a cost that's being paid for that compatibility).
Indeed, I think this post ends up being a good argument against Lisp. The supposed negative for JS, as opposed to Lisp, is that "We’d need something like Babel to parse our file, and work on top of the AST to make sure we rewrite our code safely." And? Computers are good at parsing, and adding syntax to a language should be comparatively rare, so why would I choose a language that optimizes for this case, rather than one which optimizes for human readability?
I think some people will argue that macros shouldn't be rare, that you should define a custom DSL for each application so you can work at a higher level of abstraction. However, macros themselves operate at a fairly low level of abstraction (operating on the AST, rather than closer to the problem domain). I would argue that if you find yourself using macros frequently, that's a sign your language is lacking in higher-level abstraction capabilities.
I'm also on Android in Europe, with no YouTube Music subscription, and it lets me play music in the background, without ads, if it's either on the device or in the "Uploads" section (which is where it's put music I'd purchased on Google Play Music). So it looks like they haven't completely removed that functionality, although the interface for accessing it is significantly more annoying.
You can do this, but it's not ideal. A function can list multiple exceptions in its throws clause, which share no common type except Throwable, but this combination of exception types can't be represented by a single type parameter (except for the common base type). So in a lot of cases, you lose information about the specific exceptions your function can throw, which limits the value of using checked exceptions.
Wiring up dependencies via XML is indeed a bad idea for the reasons you specify. But if you're going to wire up dependencies in code, you don't need annotations. Java already has a method for declaring and providing dependencies for a class: writing and calling constructors, which is clearer and checked by the compiler.
This is a strange and IMO unsatisfying book review, as it's largely a summary without much in the way of analysis or evaluation (except for the explanation of which real-world critics Kaufman is targeting). But perhaps this is an attempt at a demonstration, by its absence, of the value of criticism - which would be an appropriately meta way of responding to Kaufman.
The point of ad tracking is not to show ads that you need. It's to show ads that are likely to make you take the actions the advertisers need you to take. If the trackers determine that you have a gambling addiction and serve you ads for gambling sites, they're working as intended, but they're not helping you. If advertisers determine that their overall profits are increased by not showing ads for houses in desirable neighbourhoods to certain demographic groups, that's not good for the people in those groups.
I don't think I've ever seen any purported examples of the expressiveness and flexibility of prototype-based OO where the advantage actually comes from being prototype based rather than class based. Rather, the flexibility comes from being a dynamic language with a first-class metamodel. Or, to put it more concretely: in what way is Self more expressive or flexible than Smalltalk?
There is an implementation of Haskell for the JVM[1], although I don't know how much its implementation has in common with the techniques discussed in this thesis.
"It's not practical to define a separate class for every query."
I'm not sure it's really impractical, at least in my experience. You may not need a separate type for every query, as long as you are willing to have some queries select a few more columns than you actually need right now; and you don't need separate classes, just separate interfaces, which makes the amount of extra code you need smaller.
I think you may be conflating two things here: C#/Java/etc style static OO vs Smalltalk/Python/etc dynamic OO, on the one hand, and class-based vs. prototype based OO, on the other. IMO most of the good bits of JavaScript's object system come from it being dynamic, not from it being prototype based (indeed, JS and Python's object systems are very similar, except that Python has language level support for treating some objects as representing types).
When Steamboat Willie enters the public domain, those aspects of the Mickey Mouse character that are in that film will also be in the public domain, so people will be able to use the Mickey Mouse character, as long as they don't use aspects of the character that were introduced in later (and so still copyright) works.
Something similar happened a few years ago with Sherlock Holmes [1]. The original Sherlock Holmes stories are public domain, and so the character can be used without the permission of the Conan Doyle estate. However, some of the later stories are still under copyright, so anything about the character which only appears in these later stories cannot be freely used.
The gobject system that underlies Vala is a language agnostic mechanism. Vala also produces gobject introspection information, so bindings can be automatically generated for many languages, including Python and Ruby. Obviously, that doesn't solve the problem of Vala being a barrier to entry for developers wanting to work on Elementary's core apps.
(I once offended some Dutch friends of mine by calling Dutch "German with a Geordie accent," although when you get down to it, "German with a Geordie accent" pretty much describes English, too.)
The magic is in all the code that interprets those annotations. So you have to understand a large and complex framework to understand which objects are being injected (in Spring, for example, you have to keep in mind the rules about which beans are instantiated and then which of the instantiated beans are chosen for injection into a particular class), and to understand what actually gets injected (is it actually the object returned from the annotated method, or some proxy or chain of proxies adding additional behaviour to those objects?).
The principle of dependency injection is a good one, but dependency injection frameworks are an unnecessary and overcomplicated way of achieving it. XML-based DI frameworks at least had a rationale - the idea was to externalise configuration, so you could change the dependencies without changing the code. It turns out this kind of externalisation isn't actually valuable in most cases (changing the dependencies is just as complicated and risky as changing code, and often needs to be coordinated with more substantive code changes, so the separation is artificial).
Once you determine that you should wire up your dependencies in code, though, there's no need for dependency injection frameworks - you can just directly write the code that wires up the dependencies.
Luckily, with modern dependency injection frameworks wrapping every object in layers of generated proxies, it's now impossible to understand it in the debugger, too.
"there were a lot of weird ideas (fluids, etc.) about in those days for what electricity was, but that's just because the set of observations was very limited, thus expanding the space of hypotheses beyond what we consider reason these days"
That's pretty much what Kuhn means by pre-paradigm science: when scientists don't know enough about an area to have come up with general principles to guide their research. And Kuhn certainly doesn't think pre-paradigm science is better than science within a paradigm. He's primarily interested in trying to describe how science operates, rather than saying I way of doing science is better than another, but he's pretty clear that most of what scientists accomplish happens when they are working within paradigms.
The custom query language I find most annoying (possibly just because it's the one I deal with the most), is JPQL, the query language of the Java Persistence Architecture. JPA explicitly targets relational databases, so there's no obvious reason why you couldn't just use SQL. You might think the advantage of a custom query language would be that it could abstract over differences between SQL implementations, but JPQL is underspecified and just gives you the underlying database behaviour in many cases. I spent a day trying to figure out why my tests passed but the staging environment was claiming that 0 was greater than 0; turns out there was a difference in rounding behaviour between the in-memory database used for tests, and the real database, which JPA was cheerfully glossing over.
This is a pretty frustrating read. Interpretability of automatic decision making processes is a genuine, important issue, but I'm not sure this issue is best explained by a writer who, as far as I can tell, has made no effort to understand basic questions like what an algorithm is. The generalized bafflement of the author is just mystification, a vague sense of spooky machines we can't understand, which doesn't help us understand the specific difficulties in understanding the decision making process that depend on processing huge quantities of data.
I think a better example to show why you might want a ?. operator would involve nested lookups. If you have something like node.child.attribute.value, handling potential Nones at each lookup with ifs would get very verbose very quickly (and that verbosity would be bad, as it would make it much harder to make out the main point of the code).
You could surround the nested lookups in try/except and catch the AttributeError, but that could mask other errors - for instance, if you misspelled the name of one of the nested attributes (arguably, it would be better if trying to look up an attribute on None raised a different exception, rather than AttributeError).
class C:
def __init__(self):
self.__private = 'Is it private?'
c = C()
c._C__private
Double underscore names aren't so much about access control (because access control isn't strongly enforced) as about limiting name collisions (by including the class name in the underlying field name).