Hacker Newsnew | comments | show | ask | jobs | submit | sirclueless's commentslogin

I think the parent comment is assuming ADT is short for "algebraic data types" and not "abstract data types", since the former is the subject of the rest of the thread. You used both long forms and the acronym without saying which you meant.

As to the meat of the discussion, algebraic data types imply that you can apply algebraic operators to types. Since this is traditionally a purely compile-time feature you can imagine why the parent comment is incredulous that you could implement this without language support.

Your specific statement, "data types and types are not the same thing," is particularly confusing. You are making assumptions that aren't warranted, for example that "data types" encompass both a compile-time type check and an interface allowing abstract operations, while "types" are simply static type guarantees on values. In fact, both terms can refer to either.

reply

e12e 6 days ago | link

Fair enough, but I didn't say "data types and types are not the same thing", I said "(abstract) data types and types are not the same thing" (unless I did for a moment before a quick edit, but I don't think so).

Anyway, I think we've cleared up what I apparently didn't put very clearly in the first place: Algebraic Data Types can help with implementing Abstract Data Types, but one doesn't need the former for the latter -- and I suspect the data structures of "Data dominates. If you've chosen the right data structures and organized things well, the algorithms will almost always be self-evident. Data structures, not algorithms, are central to programming." are indeed closer to using the right simple data structures along with the correct abstract data types -- so there's no direct contradiction between the 5th rule and Go not having (proper) Algebraic Types.

reply


The point is that if Netflix throttles Comcast customers, the customers stream from Comcast On-Demand instead. They don't switch away from Comcast because they can't, which is what makes this an unbalanced situation.

-----

sirclueless 110 days ago | link | parent | on: CSS Diner

I don't think it's meant to. The instructions are a bit ambiguous, but they mean just the pickles that are siblings to the bento, which you can see because only those are bouncing.

-----

sirclueless 110 days ago | link | parent | on: CSS Diner

It's simpler than that. You are supposed to select the plate and bento, not the pickles on the plate and bento.

-----

geerlingguy 110 days ago | link

I was thinking plate + pickle and bento + pickle, since all of them were dancing... took me coming back here to figure out that only the plate/bento should be selected.

-----


That may be true for familiar words, but a long, uncommon word is unavoidably going to take more processing. Flashing "unforgettable" is probably fine, but I'd want a split second pause on "periodontia" or "imbroglie".

-----

pkghost 122 days ago | link

This is a great observation. After reading Spritz' blog post, I've been thinking about using word shape uniqueness as the main signal for how long to pause--i.e., "soliloquy" would be quite unique thanks to its ascenders and descenders, whereas "excessive" is less unique, owing to its relatively featureless outline. Combining shape with word frequency (across language) seems even more promising.

-----

nopasswordreset 120 days ago | link

I'm not sure ascenders and descenders are the only things factoring in here. I guess doing a visual blur on an image of a word could help to spot characteristics of words. Admittedly, the ascenders and descenders would have a probably primary role in aiding classifying. So maybe it's an 80%/20% thing.

At a guess words with unique clusters of vowels would also stand out say 'Hawaiian'. Or other words like 'cameraman', 'minimum', 'consciousness', 'neuroscience', that all probably have a certain shape or density, even if they are flat.

This regex dictionary may be useful: http://www.visca.com/regexdict/ /^[aeiuocmnrsvwxz]*$/

-----

wavesounds 122 days ago | link

I agree, If the app could maintain a frequency table containing how common words are in normal usage and slow down more for the most uncommon words that would be awesome.

Until then slowing down for longer words at least would definitely help. This could at least be an option if the authors aren't convinced its a good idea yet, then A/B test the amount of usage for people who use the option compared with those that don't.

-----


> I mean could you ever imagine a fashion line modelling male PhD students?

Yes, I very well could imagine this. Geek chic is very much a thing and this would probably play just fine.

I think about this the opposite way from you: Why should having a PhD change the pressures one faces around fashionability and body image? Are you suggesting that people with PhDs have earned the right to be exempt from social pressure by virtue of succeeding in a graduate program?

Choosing some arbitrary and largely fashion-orthogonal dimension to slice up the population seems like a very reasonable way to try and advertise fashion to a wider audience. If you are decrying that the media is pigeonholing women as being more fashion-sensitive, or that they are cherry-picking some expected body type out of their chosen demographic, then that is a separate and perhaps valid issue. But I don't read this as having any bearing on the value of a PhD, except as a way to market to an audience that cares about intelligence.

-----


It is documented. That's the strongest argument against changing it: it's a documented piece of user-facing behavior. The python developers are changing it anyways because they're practical people who have decided it is more likely that people wrote bugs into their code, than that they wrote code that depended correctly on the falsiness of UTC midnight.

-----

einhverfr 128 days ago | link

This is true, but if it is documented it is still sufficiently oddball to be useless. Consider:

    Midnight UTC, timezone EST:  True
    Midnight UTC, timezone CET:  False
    Midnight UTC, timezone CST:  True
    Midnight UTC, timezone WIT:  False
    Midnight UTC, timezone PST:  True
Now the problem here is that it may well be documented but it is in fact unsafe to rely on in any context. The behavior is thus irretrievably broken, documented or not. It isn't even expert-friendly. The behavior, documented or not, is irretrievably broken. After all timezones west of GMT will never have false times.

If there is a use case for this behavior, I sure can't see it. Unless you like bugs appearing when you change timezones.

-----


It sounds like a very purposeful and directed "fuck you" to me. He's not being rude or crass, he's making the concise and vehement point that if you are a bad actor on Tor, you are harming everyone and he will hate you for it.

Enlightening debates don't come about when everyone mutes their politically incorrect emotions and speaks in platitudes, they come about when people respect each other and can speak simple truths as they would to their peers. Evidence is always useful, but rational argument is equally important.

-----

hawkharris 142 days ago | link

When I'm deciding if an online comment is civil and productive, I tend to ask the question, Would the commenter be willing to say this the same way in real life?

Plenty of people use the Internet's cloak of anonymity to say things that are inconsiderate. I use this simple test to determine if they would stand behind their remarks if accountability were in play and anonymity were not a factor.

I think it's well understood that "fuck you" is considered an offensive term in the context of a disagreement between two strangers. My morning commute has illustrated this point on a few occasions. :)

-----

true_religion 142 days ago | link

In real life you can frown to communicate your extreme disapproval. You can grit your teeth, kick the dirt, squeeze your fists, and do all sorts of non-verbal gyrations before having to spit out a simple 'fuck you' in order to communicate.

This isn't 'real life'. This is text-based communication.

-----

merkitt 142 days ago | link

It's possible OP didn't realize what he was proposing would have a negative impact. Rather than assuming that, we could've just said something like: "Do NOT do that! Because of {these things}. And {these other things} will happen to you and other people."

There are plenty of ways to say politically incorrect things without being rude. One thing I like about HN (as opposed to reddit) is the information density -- it's higher because jokes and snark are frowned upon.

-----

sirclueless 147 days ago | link | parent | on: A Case for Upserts

Doesn't this have the same problems as the DELETE+INSERT from OP? Namely, a concurrently executing transaction will see a brief moment in time where no valid (e.g. CreatedOn < NOW() < InvalidatedOn) UserProfile exists.

There's also a bunch of weird corner cases you need to expect. For example, you can have multiple valid UserProfile objects at once if two transactions insert concurrently. If you LIMIT 1 and sort by CreatedOn that may not be a huge issue, but it will look weird if you try to look at historical data.

-----

moron4hire 147 days ago | link

If you execute this in a transaction (as you should whenever dealing with any two queries that alter state and logically follow each other), then neither case creates a state in which some other transaction sees the first half of this sort of update complete without the second half. And if you don't, then it's not quite the same as DELETE+INSERT, because you haven't destroyed any data.

Also, even if one considered this "no better" than DELETE+INSERT, it has significant other benefits for other purposes. The history of data is worth it alone.

But you've made me consider the issue more, and I think perhaps a better way to run this would be:

    INSERT ... -- same as before
    
    DECLARE @ID int;
    SELECT @ID = SCOPE_IDENTITY();
    
    UPDATE the_table
    SET InvalidatedOn = CASE WHEN the_table.ID = @ID THEN MAX_DATE() ELSE NOW() END
    WHERE surrogate_key = @KEY
    AND InvalidatedOn > NOW();
then, even if you intentionally created a race condition, you should always end up with one and only one "definitive" record.

-----


In particular, the code snippet from the blog post,

    if (size && size > SIZE_MAX) {
        errno = ENOMEM;
        err(1, "overflow");
    }
is a total no-op. It can't ever be true, the compiler might as well just remove the whole thing.

-----

More

Guidelines | FAQ | Lists | Bookmarklet | DMCA | News News | Bugs and Feature Requests | Y Combinator | Apply | Library | Contact

Search: