Hacker Newsnew | past | comments | ask | show | jobs | submit | gwerbin's commentslogin

Yeah I personally found this to be a big part of the tactical and strategic challenge. It reminded me a lot of Pokemon where you have a similar challenge, of slotting "exposure to fighting" into a limited action and HP budget.

Edit: Now that I think about it, most turn-based games have this mechanic. It's almost an idiomatic balance/design decision in gaming.

Compare to Dota where support heroes have acquired more and more opportunities for assist gold/XP, it does in some sense make the game "easier" for the support players, but then the game is harder in other ways because now the supports are all way more farmed and dangerous than in older versions. It's the difference between controlling an army of many units and having to manage them all, versus controlling one unit and needing to work together within a team.


Dota/League does this because each hero is controlled by a human, and humans don't like playing low-impact, low-wealth, low-exp supports.

Also it's not like dplyr is anything close to a "port" of SQL. You could in theory collect dplyr verbs and compile them to SQL, sure. That's what ORMs typically do, and what the Spark API does (and its descendants such as Polars).

"Porting" SQL to your language usually means inventing a new API for relational and/or tabular data access that feels ergonomic in the host language, and then either compiling it to SQL or executing it in some kind of array processing backend, or DataFusion if you're fancy like that.


dplyr straightforwardly transpiles to SQL through the dbplyr package, so it's semantically pretty close to a port, even though the syntax is a bit different (better).

> There's no reason to invent a completely new API for them

Yes there is: SQL is one of many possible ways to interact with tabular data, why should it be the only one? R data frames literally pioneered an alternative API. Dplyr is fantastic for many reasons, one of those being that people like the verb-based approach

Furthermore I argue that dplyr is not particularly similar to SQL in the way you actually use it and how it's actually interpreted/executed.

As for the rest I feel like you're just stating your preferences as fact.


data.table "simplicity" is actually a huge set of features, they just have a clever and compact way to express those features in code. At the same time, there is effectively no standard-eval programmatic interface for it, which makes it a headache for building programs rather than scripting with. data.table is amazing, but it is anything but simple IMO.

> The pandas API is awful

I hate to be the "you're holding it wrong" guy but 90% of "Pandas bad!" posts I find are either outright misinformed or mischaracterizing one person's particular opinion as some kind of common truth. This one is both!

> That comes from the assumption that there is almost always a meaningful index (timestamps)

The index can be literally any unique row label or ID. It's idiosyncratic among "data frames" (SQL has no equivalent concept, and the R community has disowned theirs), but it's really not such a crazy thing to have row labels built into your data table. Excel supports this in several different ways (frozen columns, VLOOKUP) and users expect it in just about any table-oriented GUI tool.

> having to write index=False every single time you write to disk

If you're actually using the index as it's meant to be used, you'd see why this isn't the default setting.

> functions seemingly randomly returning dataframes with column data as the index

I assume you're talking about the behavior of .groupby() and .rolling()? It's never been random. Under-documented and hard to reason about group_keys= and related options, yes. But not random.

> appending the index to the Series numpy data leading to incredibly confusing bugs

I've been using Pandas professionally almost daily since 2015 and I have no idea what this means.


I think the commenter you are replying to might well understand these nuances. The point is not that Pandas is inscrutable, but instead that it‘s annoying to use in many common use-cases.

> but it's really not such a crazy thing to have row labels built into your data table.

Sometimes you need data in a certain order. Sometimes there is no primary key. And it is nuts how janky the pandas API is if you just want the index to mean the current order of the dataframe and nothing else. Oh you did a pivot? I'm just going to make those pivot columns a row label now if that's alright with you. I don't do that for all functions though, you're going to have to remember which ones. Oh you want to sort a dataframe? You better make damn sure you reindex if you're planning to use that with data from another dataframe (e.g. x + y on data from separate dataframes), otherwise I'm going to align the data on indices, and you can't stop me. Also - want to call pyplot.plot(df['column'])? Yeah I'm giving it the data in index order obviously I don't care about that sort you just did. Oh you want to port this data to excel? Well if your row labels aren't meaningful and you don't want "Unnamed: 0" you're going to have to tell me not to. You need to manipulate a multi-index? You're so cute. Have fun with that buddy.

There is a reason no other dataframe library does this - because it's confusing and cognitive overhead that doesn't need to exist. I've used pandas since ~2013, had this chat with colleagues and many recommend just giving in and maintaining an index throughout. Except I've read their pandas and it sucks because now _you_ need to reason about what is currently the index - because it actually needs to change a lot to do normal things with data. I just use .reset_index copiously and try to make it behave like a normal dataframe library because it's just easier to understand later. Pandas has not earned the right to redefine what a dataframe means.

At the absolute least, index behaviour should be opt-in, not something imposed on the user.


That is a very very very charitable interpretation of what he's saying.

Taking issue with this use of "problematic" says a lot about the speaker too.

"Problematic" is just vague. It's not that much more writing to specify the actual problems.

It's a rhetorical device that dates back to the ancient Greeks (meiosis). It's absolutely a lot more writing to enumerate the ways in which Elon Musk is problematic.

In a sane world it would read that way. Unfortunately, we live in a world where such nondescript descriptors (“problematic”, “objectionable”, “unprofessional”, “toxic”, “extremist”, “far-$SIDE”, a few others depending on usage) have been used, and overused, to accuse or smear people without taking on much of a burden of proof or making any statements specific enough to be falsifiable.

They now provoke instinctive revulsion when used in culture-war-adjacent contexts even when, as here, their usage is entirely legitimate (you presuppose a vague but mutually understood allegation rather than nebulously introducing a fresh one). I think only “controversial” has escaped this fate, but it might be too weak for your purposes.

(To be clear, I am only trying to explain why your phrasing might cause your interlocutor to momentarily recoil even when—as in my case—they don’t actually have any problem with the contents of your statement. What you do with this explanation is up to you: I don’t believe these terms are short-term salvageable at this point, but neither will I begrudge others their choice of hopeless cause; I certainly have my own fair share of those.)


There's more of it at least.

The problem is not that it's finite, the problem is that by the time prices rise enough to discourage people from using it frivolously, you might already be dangerously low on it.


Don't count on it. There's a lot of money in killing other businesses, or even just keeping prices high. Even if the high prices are an accident, there is always someone looking to take advantage of any situation for profit.

I have to agree. You only have to look at car and junk food inflation from after covid.

The prices make no sense, but that doesn't matter, they got away with it and are fighting to hold onto high prices, even as consumers balk. Their solution? Ditch poorer consumers. New cars and (branded) junk foods are luxury items now, apparently.


When weren't new cars luxury items exactly?

My last car was new and I bought it in for about $13,000 in late 2016. How is that a luxury?

It's one thing if they have a shadow profile on you (and dozens of companies almost certainly do), but it's another thing if you give them meaningful info about you to enrich that profile with. They can figure out roughly what block you live on, OK fine, but unless you're in a rural area with no neighbors they might not be able to do much better than that.

> They can figure out roughly what block you live on

Its nothing to do with the specific house you live in, and everything to do with the activity being grouped together with all other activity you have done, which they know from fingerprinting and IP addresses.

They dont need to know where you live to have a very accurate personal and psychological profile opn you, and switching browsers is not going to help that in the slightest Im afraid.


Yes and no. If you block Linkedin SDK scripts on 3rd party sites, it's likely that Linkedin specifically doesn't actually have a good profile on you.

Realistically you're probably exposed and identified. But if you're meticulous and careful, you might not be, or at least not as completely as someone who is unaware or not careful. But it's not at all the same as if, say, a state actor was motivated to spy on you specifically.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: