Well, tracking users by cookies or fingerprinting or whatever can tell you that by combining data from different sources. Now we've looped back around to being in favor of the most intrusive methods.
As I said that is a "piece of information", not the whole story. Making an axing decision with ONLY that information would be outright idiotic.
Telemetry has to be designed as well, to piece as much as you can, and then you complete the full picture with other sources. Maybe not everybody does this, but I don't think that this practice should be "shocking" for anybody.
yea you sound like someone who is competent and will actually thing things through and make a rational decision. Many people are not and will latch on to the information "only 1% of people use it!" and refuse to listen to why that may not matter"
Well, in Europe, if you want to know how much a user pays, you need to tie telemetry to their account containing personal information, which is forbidden by GPRD unless they give their explicit consent and they have a process to delete/rectify/download all of it.
Since most telemetry are optout and don't bother about giving users access to their data, they can't legally do it.
That's my point really: useful telemetry is really, really invasive. So just ask consent, and accept most users will tell you no.
If you chose what's convenient instead, you will not only have a mixed bag of data, but also you have decide to basically force yourself on people, in an age where a part of your userbase is getting upset over things like using the wrong pronoun on them.
I tell yes to Firefox and VLC to report on my usage. It tell no to Google and Microsoft. They want their cake and it it: behave badly, and then have we trust them.
Right. A mention in the ToS does not equal real consent. I would only add that it also has to be informed consent. Saying something like "can we collect data from you to improve our products and services?" is also not soliciting real consent, because it tells the user basically nothing about what is being asked of them and how it will be used.
You think that keeping track of "This paying user uses this and that feature, and is thus on the correct price plan" is a violation of the GDPR, assuming it's mentioned in the privacy police and maybe ToS?
I don't know what does or does not violate the GDPR, and I'm not talking about metering services. I'm talking about telemetry for installed software.
I'm not even talking about what the law says, because the law is very inadequate on these matters (in the US, anyway). I'm talking about, from a common-sense point of view, what "consent" is.
In my view, it can only be counted as "consent" if I have been informed exactly what it is that I'm consenting to, and I am asked for that consent.
ToS don't count for a number of reasons, starting with the fact that nobody reads them, it's unrealistic to expect people to read them (because everything comes with lengthy ToS documents and if you really read them all, little time would be left to do anything else), they are generally difficult to properly understand if you're not a lawyer, and they are are usually intentionally vague of this issue -- which means the "informed" part of "informed consent" isn't satisfied even if you do read them.
I think the Principle of Least Surprise should apply here. If software is going to do something that users won't notice happening, is intrusive, and isn't pretty obvious from the nature of the software, the right thing to do is to tell the user about it and ask for permission.
Software that doesn't do this is adversarial to the user.
That seems interesting, when thinking about pro rated subscription fees -- if a feature isn't being used, it'd cost nothing. But with telemetry disabled by default, the company couldn't detect that the feature wasn't being used, and thus the customer would pay more. And if opting in to telemetry, the customer pays less and the company gets telemetry.
The first one is French dubbed in russian. If you speak russian, I would recommend it as it as the slides clearly in view.
However, the second one, in English doesn't show most of the slides, and they are really necessary to get the full picture. However, it's a playlist, and there are better ones in there.
If you don't mind, I will update my comment to include one of them.
It's been the case for python for a while and nothing bad happened. Nobody started to use accentuated variables. But I finally could put my name in comments without having to put a # coding header, which is nice.
Genepi production is pretty limited itself because of the heavy restrictions on the plant harvest, espacially since it grows mainly in the Alps. And the Mercantour rangers are not tolerant of people picking more than their share.
That's basically what the Academie Francaise have been doing all along for French and why we have words like "courriel" instead of email in the dictionary despite the fact most people never use them.
A bit of consistency is good, I find, but not actually in actual words.
The real consistency you should aim for is pronunciation. Especially for loanwords. Yes, the first time you encounter "CD" spelled out in your native language, it's jarring, but over time the benefits of this add up.
If you aim to make your language as phonetic as possible, suddenly acquiring the language is much easier. Still very hard, but a degree of difficulty easier.
I actually prefer "goto-less alternative 2". It's more verbose, but more explicit. No magic, I know exactly what happen. If you suddenly have more functions, you should have an array of functions with a clean_up_level variable.
Of course, you probably should not have a global state that some clean up function with a side effect deals with in the first place, but it's the c linux kernel so I assume there is something I don't know.
Even with custom query, using escape hatch bring a lot to the table because you benefit from the ORM core handling system for configuration, serialization, pooling, etc.
Not to mention some core (like sqla core) in fact include a functional query language that is capable of representing low level sql in any form. In which case you benefit even more, and you can do your report perfectly.
Unless you access the database only and don't have the reports accessed through an end-user application, you usually have some language involved to call your SQL queries, normalize input, abstract them away, etc.
You do have to learn an additional API, but as a programmer, that's something I have to do every day anyway.
At the very least you should know SQL. The purpose of having a query dsl in some other language isn't to avoid understanding sql, it's because sql isn't easily composable.
"SQL isn't easily composable" is a pernicious lie. Does it compose like your favorite functional language? No.
SQL is not nor has ever been a functional or object-oriented or generic or procedural language. It's a fourth-generation declarative set-oriented language, so the composability is going to be based on sets. Period.
Until you think of SQL as a set-oriented declarative language, you will be perpetually trying to push water uphill, ORM or no.
It's not a pernicious lie at all. You can't just say, it's composable so long as you only compose with the special mentality that you consider to be blessed. Also the fact that SQL acts on sets is completely irrelevant to the syntax being composable or not. JSON is programmatically composable. XML is programmatically composable. S-expressions are programmatically composable. Most programming language syntax's are not.
If you build a UI or reporting mechanism that wraps around an SQL engine and has multiple configuration options that combine to determine the SQL expression that should be used, the fact of the matter is that you will either abstract the combination of the configuration into a DSL that then gets converted to SQL, or you will have a mess of string concatenation that isn't type-safe and isn't verifiably correct until runtime.
Show me the code you'd write to generate an SQL expression with ten optional filters, where each filter is comparing a different column to a set, and if the set is empty the filter should be ignored. I'll show you a DSL that does the same thing, is readable and statically verifiable, and ensures that if anybody else ever writes a similar query guarantee's that parameters will be the same so that the execution plan can be cached.
S-Expressions are not a set-based construct. Neither is JSON nor XML. Those are all document-oriented and/or hierarchical tree structures.
I did not "bless" SQL as a set-based language. It's literally a 4th generation, declarative DSL for set theory. That was its design goal. That's the lens through which every change to the language and the engines that implement it are discussed and adopted.
If I said LISP sucked at object-oriented programming and OO design patterns, how would you react? How about if they said LISP shouldn't be solely through the lens of functional programming just because that's your "blessed mentality" for it.
I don't even know how to respond to that assertion. "It's not even wrong."
All three of these are "4th generation, declarative DSLs for set theory" as you like to brandish around.
> If I said LISP sucked at object-oriented programming and OO design patterns, how would you react? How about if they said LISP shouldn't be solely through the lens of functional programming just because that's your "blessed mentality" for it.
S-Expressions are just a syntax. It's quite normal to see Lisps that are functional, declarative, object-oriented or procedural. The only thing that differentiates Lisps from other programming language is the simplicity of the syntax enabling meta-programming, which is specifically the problem with SQL syntax and it's composability.
JSON, and XML are data structures, not programming languages. Can you loop or iterate in JSON or does some other language do the iterating? Can XML execute instructions (without a script tag or processing instruction, which is just punting to an external 3rd-gen language)? S-Expressions blur the line a bit, but clearly not in the direction of 4GL.
A 4th-gen language is specifically one that describes what you want, not how to get it. S-Expressions fail this metric in that they can describe the logic for retrieval in addition to the data (where the data portion is not conducive to it being a programming language).
SELECT a.id
, a.name
, p.name
FROM alien a
JOIN planet p ON a.planet = p.id
WHERE a.name = 'Kaminoan'
;
Now here I'd completely agree that things might have been better with some non-implicit syntax bounds, eg.:
SELECT [ a.id
, a.name
, p.name
]
FROM [ alien a ]
JOIN [ planet p, (a.planet = p.id) ]
WHERE [ a.name = 'Kaminoan' ]
;
As it stands today, SQL has some pretty gnarly EBNR to describe it. But that is still missing the point. Where are the datasets for "alien" and "planet"? Are they on the same disk? The same server? The same cluster? The same kind of database?
Are there a lot of aliens? Would a btree index lookup be more appropriate, a sequential search, a bloom index, or some other algorithm? Is alien name enforced to be unique or not so that we can be sure to return either optional one, exactly one, zero or more, or one or more?
Is "planet" a single table, a view into one or more tables, a materialized view that caches its results, or a foreign table accessing the data from another source that isn't even relational?
A 3rd-gen language would need to know these things. It would require telling the system HOW to get the data rather than just describing WHAT data subsets are desired based on other known data sets. It doesn't just transform one or more sets into a new set without any consideration as to what serialization format those data sets are stored in—on disk or in memory.
Here we have the need for separation between DDL and DML. Yet DDL still only describes the structure and makes access patterns available. Creating an index does not mandate use of that index. It merely puts that data access pattern on the menu. DML (as seen above) makes the query result set definition but has nothing to do with telling the engine how it should go about doing it.
Ergo: 4th-gen declarative language
This doesn't mean SQL is the best language or even better than all 3rd-gen languages simply because it's a 4th-gen language. But if you're going to engage in this topic, I strongly encourage you to learn what a 4th-gen language actually is and how laughable calling JSON, XML, or S-Expressions one is.
I could give you HTML as a 4th-gen language in that it describes layout and general behavior without reference to how the layout engine renders it or implements its linking, form-handling, and embedding behavior. HTML+CSS make a compelling case for a composite 4th-gen language, describing what you want, not how to render it. Whether it be links, Firefox, or Mobile Safari, the description is the same and the desired behavior is well-defined despite wildly different implementations from the engines.
I keep replying to you by the way because I'm really hoping you are going to have the aha moment that is holding you back here. Again, you are misunderstanding the difference between syntax and how it is used. Json and xml aren't data structures. They are syntaxes, which are commonly serialised into a data structure. (Usally a tree). S-expressions are also syntaxes that can be parsed into a data structure.
Did you know that C# is also a syntax that can be parsed into a data structure? The Roslyn compiler does this, which allows for symbolic code manipulation and generation.
Did you know that's how almost every programming language parser works? They will tokenise a syntax into a symbolic data structure which will then either be interpreted and executed or output a binary. You can quite easily write a parser for xml that uses it as a programming language. Two well known examples of this include xslt and xhtml. Xhtml is even one of your lauded 4th gen declarative languages.
Whether or not the language is popular enough to have multiple parsers isn't relevant to the class of language that it is. In the example of a c++ program that reads xml into a tree, and then converts that xml into sql to be executed on a database, that xml syntax has become a 4th gen domain specific language.
The important distinction between languages and data structures is the the implementation of the parser/evaluator and what it does with the text or symbols that it reads. A language implies execution and a datastruture implies serialisation.
Oh come on. You are basically arguing that Python is just syntax, not a programming language; it's just the interpreter that parses the text and makes it go. No duh! You've made a distinction without a difference.
If an XML dialect were to be parsed by a processor to declaratively perform a sequence of tasks, the AST is not relevant to this discussion, only the tasks being performed. The XML dialect—the semantic structure behind it—is what I'm discussing.
JSON and XML as they are used today are "just syntax", but they are examples of syntax that almost universally are parsed directly into data structures. The Liquibase XML dialect on the other hand moves beyond a simple data structure into a declarative language for migrating database structures from one form to another by virtue of the Liquibase engine.
SQL is not "just syntax" any more than your speech is "just phonemes". Yes, English, Xhosa, and Mandarin are all just collections of phonemes. All written languages are "just syntax" waiting to be processed by smart meat.
It is needlessly reductive.
SQL absolutely implies execution in a way that JSON/XML do not. However, the style of execution is clearly different between SQL and C#. That style can accurately be described as set-oriented execution, at a higher level than 3rd-gen languages such as Python or C#.
Writing a parser for SQL (or XHTML) is a very different exercise from processing the AST from that parsed SQL/XHTML if that processing happens immediately after the parsing step and is largely driven by that AST.
Relational database engines are interpreters for SQL.
But knowing that only 1% of users use this feature is not enough to make that decision:
- maybe 1% of your users only use it, but they are the ones that pay the most money
- or it's the most prolific users so it generates half of your content
- or it's a niche feature used by power users, but those users are the ones bringing other users, introducing you to companies and doing free support
- or it needs to be used by only 1% of the users by design, and it's enough to be useful (E.G: bug report form)
- or your report it wrong, it's one percent of all accounts, but 10% of actually active users
etc.
Most telemetry will not tell you that of course.