vickychijwani

Yes, but GP never claimed they're equal - instead the claim is that seeing the animal alive and talking to its seller to get more info is a better proxy to judge those things you listed (healthy, sanitary) than Whole Foods' endorsement is, the reliability of which over time depends strongly on their financial status, management ethics and a number of other variables outside your control. The Whole Foods approach is definitely more convenient for the buyer, at the cost of assurance.

Also, it's going to be a lot more difficult for a street-side vendor to cheat you compared to a behemoth like Whole Foods with deep pockets, the latest and greatest preservatives etc at its disposal to make meat look healthy, and a large, existing customer base that implicitly trusts its products.

I appreciate your point and I learned something new from it, but I disagree with the last part. By your GP's own admission, pesticide overuse doesn't threaten all of humanity like antibiotic overuse does. So no, they are not "as right as" someone trying to avoid contributing to the antibiotic overuse problem. Not all problems are equally important.

> Or is it that the problem would be greatly reduced if everyone stopped eating meat. I expect this is true but it is not going to happen.

This is a classic Tragedy of the Commons. No single individual is incentivized to sacrifice for the good of the group as a whole.

But it's not correct to say that "it's not going to happen" - there are many counter-examples. The most notable is the ozone layer depletion problem that has been largely mitigated over the last 3 decades through concerted action among govts, NGOs and with public education. From https://en.m.wikipedia.org/wiki/Ozone_depletion:

"The Montreal Protocol is considered the most successful international environmental agreement to date. ... The ozone hole was seen as a "hot issue" and imminent risk as lay people feared severe personal consequences such as skin cancer, cataracts, damage to plants, and reduction of plankton populations. ... Americans voluntarily switched away from aerosol sprays, resulting in a 50 percent sales loss even before legislation was enforced."

So yes, at some future point, if govts/NGOs do their part and the average human comes to believe they face imminent personal danger (which we already do but it's hidden), meat production may well become heavily regulated and large numbers of people may switch to vegetarianism.

While your comment is in good faith, I don't think the OP was trying to minimise the complexity of a distributed ledger. Instead they were trying to distinguish their mentioned use-case from the currency use-case.

> Am I wrong about that?

Sorry, but yes :)

The commit is immutable because when you "amend" a commit, git actually creates a new commit object, assigning it a new SHA1 hash. This means that the original contents from before the amend (i.e., the "old" commit) are still accessible via the old SHA1 hash - proving that an "amended" commit is actually a copy of the old one, not an in-place mutation.

Think of it like this - if I copy a text file and edit the copy, would you say that I've "mutated" the original file? No, right? That's what git does - it never actually mutates a commit :)

EDIT: to clarify further, git identifies each commit with a unique SHA1 hash which is assigned when the commit is created, and that hash depends on the contents of the files + the current timestamp + the SHA1 of its parent commit + some other things. Which means, if you try to edit the contents of the commit in any way at all (or even if you create another commit with the same exact files at a different time, or as a child of a different commit), its SHA1 hash will be different, i.e., it is a new commit by definition.

> (a) an argument helping my thesis by showing that you can program functional languages quite well by using mutable recourses

Let me preface this by revealing that I'm neither a functional programmer, nor am I convinced that functional programming or immutability is any sort of silver bullet.

Your original thesis was that "a data structure cannot be functional," which you later defended by saying "git is only immutable on the meta level, its implementation uses mutable files", which, while being 100% true, is also true of the category of programming languages we call "functional" as they rely on mutable RAM. That is what the GP has been trying to explain to you, but your obvious hate for anything labelled "functional" makes you blind to all this.

Sorry mate, you just have to concede the point here. This is not a discussion about whether functional programming is any good, which is what you seem to be treating it as.

While what you say is technically accurate, I think you're missing the bigger picture here. The author's point still stands: git's commit history (arguably the most important part of a version-control system) can be viewed as a purely-functional data structure, and that view has practical benefits too. I tried to explain more here: https://news.ycombinator.com/item?id=15892013

> "Look! It can be mutated! Therefore it cannot be functional!" And the response to that is, "Don't be so technical about how you define functional. Or immutable. You know it when you see it."

I think I can offer something to the discussion here, as I'm straddling the 2 camps - having a fairly intricate understanding of git (I've held training seminars at my company about it), and basic familiarity with functional (technically "persistent") data structures thanks to a long-standing interest in Clojure.

What the functional camp is talking about, when they refer to git as a "purely functional data structure", is the core of git's implementation - commits are immutable snapshots of the repository arranged in a directed acyclic graph (or a tree, if there are no merge commits), and branches are "just" movable pointers to some commit. In this view, everything other than this core model of history as a graph is extra details layered on top.

The other camp (let's call them the "git camp") looks at git in its entirety, including branches, tags, the index, the working tree, stashes, and so on, and they can't help but come to the conclusion you mentioned - "Branches are mutable references! The index is mutable! The working tree is mutable! How can git possibly be called a functional data structure?"

While this 2nd perspective is understandable and technically correct, I think it misses the point the other camp is trying to make: that the immutable commit is the "fundamental unit of git" so to speak, that we interact with everyday, and that most of git's history-manipulating commands (git commit, git commit --amend, git rebase, git merge, git cherry-pick) can be described in terms of purely-functional operations on the commit graph. Once you understand this, many complex git scenarios become easier to understand (rebase, and filter-branch, for example), so this view does have practical value. Then branches, tags, the index, stashes, etc can indeed be understood separately.

In fact, this perspective of git as a data structure is so useful, that I rarely use "git log" as it is, preferring these additional flags to view the entire graph instead:

git log --graph --all --decorate --oneline

I hope that helps, cheers!

Open DevTools > pop it out into a separate window > Ctrl+Shift+I (on Linux) > Ctrl+Shift+I ad infinitum > enjoy devtools-ception.

I see your point. But I'll take the liberty to use part of your comment as my own response: "You can certainly find snippets that are simpler in Ruby than in Python, and vice-versa". Now that is something I 100% agree with (I added the part after the comma btw).

Basically what I'm saying is that the differences are very minor compared to differences vs, for example, other languages (Java, Scala, C++, etc). So from that perspective there's not much to complain about. I just have a slight bias towards Ruby, I find it a little more readable (in a small way).

Care to elaborate with an example? I use Python day-to-day and did quite a bit of Ruby a few years ago, but I fail to see significant differences in verbosity.

What I do see is that Python is somewhat less consistent and readable (list comprehensions beyond the simplest ones are unreadable, Ruby's blocks allow cleaner DSLs, len(a) vs a.size, little things like "3.times", allowing "?" and "!" in identifiers). But Python has a bigger and more diverse ecosystem. So although I would prefer Ruby over Python, the ecosystem aspect makes the point moot.

Agree with Sujan, I found it very confusing too. At first glance it seems like the switch's 2 states are "Now UI Kit" and "White", which of course makes no sense. Only when I clicked it did I discover the other state.

I think you could add some space on the left side of the toggle and maybe show the "Orange" label there, or at least just add the space so it looks separated from the "Now UI kit" brand label.

In a different context, I would totally upvote your comment, but in Now UI's case the contrast is extremely low and gondo's argument is quite valid. See my comment elsewhere [1] for hard numbers on the contrast.

[1]: https://news.ycombinator.com/item?id=14540281

For the record, I have such a screen: a Samsung SyncMaster B2030, about 6 years old. Several of Now UI's widgets (form placeholders, disabled input labels, tab labels on white background) are nearly unreadable on this screen.

I actually checked (using [1]) the contrast ratio of some of these widgets, and they work out to very low numbers:

- Form placeholders - #ddd on #fff - contrast ratio 1.4:1

- Labels of disabled checkboxes - #9a9a9a on #fff - ratio 2.8:1

- Tab labels - #b8b8b8 on #fff - 2.0:1

This is far lower than the W3C's recommended minimum ratio of 4.5:1 [2] for text smaller than 24px. And since the font weight is often lower than normal, the perceived contrast ratio is even lower than the figures above suggest. I think the contrast needs major improvements for decent UX.

PS: http://contrastrebellion.com/

[1]: http://leaverou.github.io/contrast-ratio/#%23dddddd-on-white

[2]: https://www.w3.org/TR/WCAG/#visual-audio-contrast

> Semver is marketing, not engineering.

I agree with many of your points, but that casual dig at semver is unwarranted and reveals a misunderstanding of the motivation behind it [1]. Semver defines a contract between library authors and their clients, and is not meant for deployed applications of the kind being discussed here. Indeed, the semver spec [2] begins by stating:

> 1. Software using Semantic Versioning MUST declare a public API.

It has become fashionable to criticize semver at every turn. We as a community should be more mindful about off-the-cuff criticism in general, as this is exactly what perpetuates misconceptions over time.

[1]: https://news.ycombinator.com/item?id=13378637

[2]: http://semver.org/

As much as I want this, it's not going to happen for the simple reason that Clojure adds a big runtime and a huge startup cost on Android, which is unacceptable. It's fine for servers, but a total deal-breaker for mobile apps.

Kotlin on the other hand has a tiny runtime (< 1 MB before dead-code elimination etc with Proguard) and negligible startup cost - in fact several popular Android libraries have a bigger startup cost impact than Kotlin.

> Kotlin compiles to Java bytecode, so you don't need to deal with JavaScript engines, serialization/deserialization, etc.

I don't think the GP meant replacing JS with Kotlin, rather they're referring to implementing React Native modules in Kotlin instead of Java, keeping the JS part untouched. (As you may know, React Native modules/components require native implementations before they can be used in JS).

I hope that clears things up a bit!

Yes, this is the only reason IMO. GP is reading too much into this.

Source: I closely follow all developments in the Android ecosystem, and have been doing so for over 2 years.

I think you're reading too much into this. The only reason they adopted Kotlin was because Android devs were already using it. Jake Wharton, one of the most well-known Android developers, has also been a vocal supporter of the language for a long time, so much so that Google actually invited him to give a talk about it at I/O this year - I have never seen Google invite a community member like this before.

Source: I've been developing Android apps for 2 years and closely follow all developments in the community.

Moreover, if USCIS thought this would affect already-filed applications, I think they would've made a clear blog post stating it as opposed to dumping it in a hard-to-read memorandum. (I'm subscribed to their newsletter which I've observed sends out all pertinent news with no delays).

The way I think about this is: if not SpaceX, some govt or company will one day establish a base on another planet. Something like the stations we have in Antarctica. So SpaceX taking a shot at this isn't totally absurd - over-ambitious, sure, but not so ridiculous as to be out of the question. Maybe it won't happen for a few decades, or a century - but IMO it's very likely it will happen some time. And that's what ultimately matters. It doesn't have to be Elon Musk's company that does it.

Cities on Mars - it's not productive debating this at such an early stage, though it makes for an interesting discussion.

You're ignoring the possibility that cars may emit only tiny amounts of sulphur and nitrogen oxides, compared to ships whose emissions are largely made up of those gases. That would be consistent with both sentences, although I don't know if it's true. EDIT: Looks like that is indeed true, see this thread: https://news.ycombinator.com/item?id=10716251

Not sure why you've been down-voted. Twitter is so different from Facebook in terms of what it's primary use is, that it doesn't make sense to compare them, and while I wouldn't quite word my response this way, I agree with the sentiment that Facebook usage data doesn't tell us enough to predict Twitter usage under higher character limits.

I can see where that's coming from, but this is a one-sided view. It misses the obvious conclusion: interface agents (to use the article's terminology) are complementary to direct manipulation interfaces, not a replacement.

Direct manipulation is great at discoverability, when I'm exploring the choices available to me, but it sucks if I'm looking for something specific (for software with a minimum level of complexity, like Photoshop or Excel). Interface agents have the opposite characteristics, as the article explains. So, they're complementary techniques.

To provide a simpler example, not involving AI: if the user is a domain expert (say, a graphic designer), the ability to search for and perform a specific action quickly is far more important than discoverability. For example, the user may already know that GIMP provides a feature for drawing a path but have only used Photoshop in the past and now they just can't find that action.

Aside: it is telling that established design software like Photoshop / GIMP has such a bewildering maze of menus even today. But if you take Google Chrome, for instance, it provides a stellar searchable user interface [1].

[1]: http://vickychijwani.me/searchable-user-interfaces-are-the-f...

On the surface, yes. But calling it a launcher does it a disservice - it was more ambitious [1] than any other launcher I've seen, although they unfortunately stopped developing it. Their ultimate goal seems to have been to build something like Unix pipes for the web, e.g., see use-cases like [2]: "insert a map for the selected location into the email I'm writing, without leaving my current tab", and this without any help from the developers of Gmail or Google Maps.

Moreover, this was way back in 2008 [3] vs I think Alfred in 2011 and the others are recent clones. I think Ubiquity was a few years ahead of its time - with today's AI advancements, they might actually be able to achieve a large part of their original mission. This has got me thinking...

[1]: https://wiki.mozilla.org/Labs/Ubiquity

[2]: https://wiki.mozilla.org/Labs/Ubiquity/Latest_Ubiquity_User_...

[3]: https://en.wikipedia.org/wiki/Ubiquity_(Firefox)

Yep, The Humane Interface is already on my (apparently ever-growing) reading list! Should probably bump it up as I've seen it recommended so much. Thanks :)

I've been thinking, with all the huge advances in AI/ML in the last few years, now might be exactly the right time for an ambitious project like Ubiquity, since it relies heavily on natural-language processing. Thoughts?

> It means that you should be able to re-use (compose) interface elements, so that even a junior developer could create a great interface (UX-wise) by assembling one from parts that are made to work well together.

I don't think "compose" == "reuse" as you suggest. Reusing well-designed interface elements gets you very little in terms of usability, because the important parts of UX design - like page structure and navigation - cannot be handed to developers in ready-made toolkits.

I do agree with the second half of your comment though. Mozilla's Ubiquity project [1] is the best example I know (see [2]) of on-the-fly composability in modern GUIs. Admittedly Ubiquity is somewhat underdeveloped, but the core idea is solid, in my view.

There's also things like IFTTT, Zapier, and Slack integrations, but:

1. They involve up-front configuration, and,

2. You need to redo this configuration for every pair of apps you want to compose together, which is obviously not scalable.

[1]: https://wiki.mozilla.org/Labs/Ubiquity

[2]: https://wiki.mozilla.org/Labs/Ubiquity/Latest_Ubiquity_User_...

I'm late to this thread, but quite surprised to see nobody mentioned Mozilla's Ubiquity addon [1], which I think best demonstrates the idea of "composability" in a GUI you're trying to convey. I think adding a description/screenshot of Ubiquity or explaining one of its use-cases would explain your idea more clearly and actually put someone on the right path if they accept your call to action.

Incidentally, Aza Raskin, one of the main developers of Ubiquity is the son of Jef Raskin who led the work on Apple's Macintosh.

At one point in college I was fascinated enough with Ubiquity to try to continue the work on it (since the project was shelved), but my programming skills were just not up to it. Perhaps I'll get back to it sometime soon :)

[1]: https://wiki.mozilla.org/Labs/Ubiquity/Latest_Ubiquity_User_...

I have a theory on how CBP is trained to scan people, that seems more plausible without assuming malicious intent: they're not expecting you to know exactly how to balance a BST, but just enough to hold a conversation about it while they look for telltale signs. My guess is that even a reply like, "Look, I'm a self-taught web developer and I don't deal with algorithms day-to-day, sorry. But you can ask me web dev questions if you wish." would work.

Yes - I only found out about it after I had my app out there with a feather logo and everything.

However I don't think it will cause big issues, as quilljs is a JS library, while Quill (the app) is targeted directly at Ghost's users who will largely (presumably) be journalists. The slight name confusion within dev circles is something we'll just have to live with.