Is there any way to disagree with this comment without being disregarded as resentful?

Good work is the key to good fortune / Winners take that praise / Losers seldom take that blame

Disagree? It's ad copy promoting a self-help book.

I have no affiliation with the author of the book and stand to gain nothing from helping others. I still stand by my choice of The Daily Stoic. I resented the thought of reading self help books because my pride led me to believe that if I read a self help book, I was admitting I was weak. That said, the reason for the book is simple: the book is intended to take a year to read, one page at a time. I wake up each day and the first thing I do is open the Books app on my iPhone, load up The Daily Stoic and read the days entry. It takes me 2-3 minutes and reminds me why I am chasing self-discipline. I have done this every day faithfully for three years. I hate to admit, but a page was as much as I was personally able to commit myself to, a full book was too much for my pride to handle at first. So if you’re like me and can’t make time for a full book, I ask you to make time for a single page per day.

In fact I will double down on this book so much, that I will personally buy a copy for anyone who sends me an email cory@linux.com. No one will know you asked for a copy and I ask for nothing in return.

Nice offer! I would also be very interested in how many people have taken you up on your generous offer. I myself would edit your offer to include the caveat: "emails within a week" to prevent all future orders for the book being funneled through you :).

Good call. The author of this book is a marketer and "media strategist," with an obvious focus on social media. He was great at plastering subtle ads all over relevant threads and subs over on reddit. Nice to know that he too has figure out reddit has gone to shit and is also looking for greener pastures..

Internet 'stoics' are ruining stoicism as they are ruining most other forms of philosophy by bastardising it and regurgitating it in the form of easily-consumable self-help pablum

A huge amount of which appears to be consumed and re-re-gurgitated by adolescent gamers

Good quote from Neil Peart. Roll the bones

I guess that’s yet another reason to make a HN account.

> That's right, to get a democratic web you will need to raise a tax and have the government run (or otherwise subsidize) the infrastructure.

Is this the terrible conclusion that you were building up to? I see no problem with that compared to the alternatives (existing or non-existing).

Untenable? You kind of resolved it yourself by saying that “democracies” of today are just “so-called” but are effectively oligarchies. So it’s not an untenable statement.

Criticizing democracy because of majoritarianism is like criticizing programming itself because of how Perl, Ruby, or any other particular programming language works. Democratic governance can be implemented using consensus, majoritarianism, majoritarianism with a 60% threshold, or whatever other rule or stipulation. A constitution is of course also possible; then the people would decide on some ground rules which will be very hard to change for the foreseeable future. Which might be a blessing or a curse for the future people.

> Just saying, 'the will of the majority controls' is a recipe for mob rule — which is exactly what 'democracy' means.

You are not saying anything. Mob rule is indeed a pejorative term which is often used as a synonym for democracy. What of it? I could call you by some insult or other but I wouldn’t be making a point or an argument.

In a democracy of three, two people can vote to kill the third. That's why democracy is a problem, and that's why the bill of rights is amazing. Call it what you want.

edit: democracy as a governance method must be built on consent, an agreement to abide by the outcome of the vote. No one would consent to a democracy without limitations. They're not even stable; they keep peeling off minorities until there are only two members left.

> In a democracy of three, two people can vote to kill the third.

It depends on the specific rules of their democracy.

Majority democracy would allow the majority to kill the minority, as in your example. I heard this goes back to Roman legions, who knew that the 51% could kill the 49% if it came to battle.

Democracy by consent would not allow for that, because that third person would (presumably) not consent to being killed. This requires that people respect each other enough not to impose on minorities.

You’re conflating a more general problem of foundations with democracy. How can a form of governance even be started? On what grounds? How has the mandate to put forth the ground rules? Has nothing to do with democracy per se.

It has something to do with a group of people having votes in order to decide things, where the action that the majority approves of is taken. Democracy may mean something different to you.

What does dplyr syntax look like?

Let's say you have a data frame

    df = tibble(a = c(1, 2))

and you want to use a dplyr verb to modify it

    mutate(df, b = a + 1)

the `a` in the above expression refers to the column in `df`, but this means it's hard to reference a variable in the outer scope named `a`. Furthermore, if you have a string referring to the column name `"a"`, you can't simply write

    mutate(df, b = a_var + 1)

Contrast this with DataFramesMeta.jl, which is a dply-like library for Julia, written with macros.

    df = DataFrame(a = [1, 2])
    @transform df :b = :a .+ 1 

Because of the use of Symbols, there is no ambiguity about scopes. To work with a variable referring to column `a` you can write

    a_str = "a"
    @transform df :b = $a_str .+ 1

I won't pretend this isn't more complicated or harder to learn. Some of the complexity is due to Julia's high performance limiting non-standard evaluation in subtle ways. But a core strength of Julia's macros is that it's easy to inspect these expressions and understand exactly what's going on, with `@macroexpand` as shown in the blog post.

DataFramesMeta.jl repo: https://github.com/JuliaData/DataFramesMeta.jl

To reference variables in the outer scope, you would do

    mutate(df, b = .env$a + 1)

And if you have a string (contained in a_var) which identifies a variable you can do

    mutate(df, b = .data[[a_var]] + 1)

You could argue these feel clumsy, but I wouldn’t say it’s “hard” to do either of these things with dplyr.

I don't think it's just about whether it's hard to do, your syntax example looks short enough and one can memorize these two patterns relatively quickly.

However, both patterns are another special case how identifiers are resolved in the expression. Aren't `.env` and `.data` both valid variable and column names? So what happens if I have a column named `.data`?

Another example, which is the reason why we chose the `:column` style to refer to columns in `DataFramesMeta.jl` and `DataFrameMacros.jl`:

What happens if you have the expression `mutate(df, b = log(a))`. Both `log` and `a` are symbols, but `log` is not treated as a column. Maybe that's because it's used in a function-like fashion? Maybe because R looks at the value of `log` and `a` in their scope and sees that `log` is a function an `a` isn't?

In Julia DataFrames, it's totally valid to have a column that stores different functions. With the dplyr like syntax rules it would not be possible to express a function call with a function stored in a column, if the pattern really is that function syntax means a symbol is not looked up in the dataframe anymore.

In Julia DataFrameMacros.jl for example, if you had a column named `:func` you could do `@transform(df, :b = :func(:a))` and it would be clear that `:func` resolves to a column.

This particular example might seem like a niche problem, but it's just one of these tradeoffs that you have to make when overloading syntax with a different meaning. I personally like it if there's a small rule set which is then consistently applied. I'd argue that's not always the case with dplyr.

I hadn't thought of that tradeoff. After testing just now, if you have a column named `.data` or `.env` those constructs work as if there was no such column, and actually in that case `mutate(df, b = .data + 1)` is an error.

Personally I'll happily take not being able to use those as column names if it means I can avoid always typing : before every in-data variable, but your comment gave me a better understanding of why it would be bad for some other person or scenario, perhaps where short term ease-of-use is lower on the list of priorities.

For your second example, it doesn't come up in R because a data frame column cannot be a function. Columns must be vectors (including lists) and you could have a vector where one or all elements are functions, but the column itself cannot not be a function (functions are not vectors), so there's no ambiguity there. To call a function stored in your data frame you'd have to access an element of the column, and any access method, e.g. `[[` or `$` would make the resulting set of characters invalid as the name of an object (without backticks, which would then disambiguate the intent)

    df <- tibble(x = list(function(x) x + 1))
    df %>% 
      mutate(y = x[[1]](3))

Separate from dplyr, in R when you use `(` to call a function it searches only for functions by that name.

    log <- 3
    log(1)
    # 0

    frog <- 3
    frog(3)
    # Error in frog(3) : could not find function "frog"
    
    log <- function(x) x^2
    log(1)
    # 1

In Julia you could have an `AbstractVector` type also be callable, or more likely a vector of callable objects (and the operation is performed row-wise).

I agree it's unlikely that a user will name their column `.data`. But it certainly saves developer effort from thinking about these issues.

The larger concern, really, is that Julia needs to know which things are columns and which things are variables in an expression at parse time in order to generate fast code for a DataFrame. It needs to do this without inspecting the data frame, since the data frame's contents aren't known at parse time.

One option would be to make all literals columns. But then you run into issues with things like `missing`, which would have to be escaped or not recognized as a column. Its hard to predict all the problems there, and any escaping rules would definitely have to be more complicated than R's. So we require `:` and take the easy way out, which has the added benefit for new users who might get confused about the variable-column distinction.

It would be interesting to profile the 2nd version though. Assuming the non-standard evaluation has performance benefits (which they do in DataFramesMeta.jl), are you eliminating those benefits when you use

    .data[[a_var]]

?

It's even better when you have the "." variable which get populated.

But in general yeah, R plays pretty fast and loose with scopes, and lets you capture expressions as arguments and execute them in a different scope from the outside one