Why aren't HN comments collapsible? - <AUTHOR>

I find it difficult to read comments on HN, and I think this mostly comes from the inability to collapse comments.
1) The top comment on a post gets hugely inflated with discussion.
2) Since scores aren't shown, I'm not sure what comments have value, so I tend to not read anything besides the first few comments.
Given that most other sites I have visited have this ability, I wonder if it was a conscious design decision, and why? <comment><USER2> I'm attempting to solve this, at least for iOS devices. My technique is to collapse everything first. If you want to continue in that discussion, you tap to expand. I think it helps mitigate the need to comment on the top thread, and should make for more diverse discussion.

I think every platform needs its own interface for this, and I suppose the thought behind the web interface is that you can always just scroll down. It's suboptimal on long threads, though. I found my technique worked best on mobile, since you can quickly tap the entire comment to expand it. With a little JS, this might also work on the web.

(If interested, the app is called Pivit, and is in review -- follow @alariccole if you want to know when it drops in the next few days.)

</comment><comment><USER3> I don't understand what your issue is with a browser ext. The one I use just works -- so well that I forget and had to stop and think about your headline that comments aren't collapsible.

[https://chrome.google.com/webstore/detail/hacker-news- collap...](https://chrome.google.com/webstore/detail/hacker-news- collapsible-c/hockhafcdegocajmjhafgjncjpodihkd)

<comment><USER4> Are you saying that his points about how non-collapsible comments shape the discussion topography are not valid?

<comment><USER3> I said no such thing. I said I didn't understand. I take he is saying top comments tend to get more up votes? I dismissed that because it's obvious and wondered if he had another issue. I assume everyone is using a browser ext to collapse expand.

reddit has hot/new/rising/controversial/top but I've haven't found a great need for that personally.

<comment><AUTHOR> Actually I'm saying that top comments _don 't_ get more upvotes. Once the single top comment has enough discussion underneath it, the comment votes become skewed and inaccurate. At that point, the "top" comment (which may or may not be the "top" comment anymore) gets an unproportional amount of votes with respect to it's vertical location on the page.

The second, third, and fourth comments may be great or even better than the comment at the top of the page, but they don't get any discussion because they are too far down the page.

Sure, using a browser extension fixes that issue for _me_ , but it doesn't change the fact that 80% of the discussion and exposure is only going to happen on the first thread.

I expect there is a good reason why HN has chosen not to implement comment collapse. I posted this question in hopes of getting an answer as to what that reason is. Maybe if I understand the system better then I will be able to use it more efficiently.

</comment></comment></comment></comment><comment><AUTHOR> Also, I know that there exist browser extensions to allow comment collapsing, but the problem extends beyond a mere functionality problem - since comments can't be collapsed, the actual comment structure changes, and that is something no browser extension can fix.

</comment><comment><USER5> I wrote an userscript to solve this: [http://userscripts.org/scripts/show/138037](http://userscripts.org/scripts/show/138037)

</comment><comment><USER6> > Since scores aren't shown, I'm not sure what comments have value, so I tend > to not read anything besides the first few comments.

Maybe you should browse Reddit instead if you're used to reading the top comment (usually one liner) and collapse to the next without engaging in any real discussion.

<comment><AUTHOR> What if the top comment is a line of discussion I'm not interested in? Too bad, because that is the only line of discussion anybody will engage in, because you never see the second comment.

I know _I_ could scroll down 7 pages and find the second comment and discuss there if that line of discussion interests me, but who else would talk with me? Nobody, because noone wants to scroll down 7 pages.</comment></comment>


"customer support":"like this": "the world":"better place" - <AUTHOR> http://groups.google.com/group/google-ajax-search-api/msg/9ecc48340852c3ac?hl=en

<comment><AUTHOR> For more great customer support responses by same Google product manager, check out [http://google.com/search?q=%22adam+feldman%22+site%3Agroups....](http://google.com/search?q=%22adam+feldman%22+site%3Agroups.google.com%2Fgroup%2Fgoogle- ajax-search-api)</comment>


[Python-Dev] Another case for frozendict - <AUTHOR> https://mail.python.org/pipermail/python-dev/2014-July/135469.html

<comment><USER2> I don't understand how that use case leads to a need for a frozendict.

The use case is to get the unique dictionaries from a list of dictiories

        >>> res = [db.cases.remove({'_id': doc['_id']}) for doc in fives]
        >>> res[0]
        {'n': 1, 'err': None, 'ok': 1.0}
        >>> res[1]
        {'n': 1, 'err': None, 'ok': 1.0}
        >>> set(map(frozendict, res))

Won't that fail if the res[] elements themselves happen to contain dictionaries, as in:

        {'n': 1, 'err': None, 'ok': 1.0, 'extra': {'a': 1, 'b': 2}}

That is, hash of the 'extra' value will fail, because dictionaries are unhashable, therefore a frozendict of the above can't have a good hash.

I say "good hash" because it's possible to define a dictionary hash based only on the keys, but in this use case all of the entries have the same keys, so are in the same position in the hash table, causing frozendict operations to switch from amortized O(1) to O(n) operations.

<comment><AUTHOR> Correct. But the idea is probably that the dicts in the frozendicts themselves should be frozendicts.

<comment><USER2> Certainly. The question is really who is in charge of carrying out the "should". Currently it's the programmer, who needs to write an adapater. That adapter needs to know to convert any mutable values (dict, list, set, etc) to immutable form (frozendict, tuple, frozenset, etc.)

I personally think the use case is better handled with the unique_everseen in [https://docs.python.org/2/library/itertools.html](https://docs.python.org/2/library/itertools.html) :

        uniq_res = unique_everseen(res, lambda d: sorted(d.items()))</comment></comment></comment>


Does one have to be a genius to do maths? (2007) - <AUTHOR> https://terrytao.wordpress.com/career-advice/does-one-have-to-be-a-genius-to-do-maths/

<comment><USER2> Math sort of has to be learned in the opposite way from how it's written. It's best written "short and sweet", compressing as much meaning as one can handle precisely into a single theorem for maximum generality. Human minds, though, learn mental models of how things work from relatively concrete examples, ones which require only a little new information to be absorbed in order to gain the new concept.

A lot of things you thought were separate and overly-elaborate start seeming simple and small once you actually work your way up enough levels, to have seen enough examples, that the generalizations _make sense_ to you. But that requires a lot of work!

<comment><USER3> Agreed.

I remember being a freshman and having my first real exposure to proofs and pure math, a calculus class. We used the text "Calculus" by Spivak. The first actual calculus topic was one of, if not the most difficult concepts in the course: the epsilon-delta definition of a limit. That was a struggle. I had no idea about the significance of logical qualifiers and precise mathematical language like "for all" and "there exists," or what it meant to "choose" or "fix" a value, much less the ability to parse all of the those things combined in a complex statement. Even familiar and elementary concepts like absolute value and inequalities were sort of difficult in that context. We very briefly covered basic proof techniques and formal logic, but overall it was intractable at first. But one by one, you learn individual concepts and notation, such that you are eventually able to understand their fully significance without really having to think. Looking back, and after taking other courses and studying proofs/logic/sets/functions more in depth, epsilon- delta makes perfect sense.

I've learned to tackle theorems and proofs (or any kind of problem, really - in math or otherwise) by starting with working out a few of the simplest possible meaningful example(s), or just any valid example if you can't quickly determine that. If you are learning a new formal concept or idea, I find that it's often very helpful to do a few applied problems first if you have any trouble. If you can identify individual concepts used in a theorem, try to master them first in isolation before tackling the overall problem, if need be. The key idea is to break things down to their smallest units of understanding.

I find this comment by Terry Tao fascinating:

>"Ramanujan, for instance, apparently performed a tremendous number of numerical computations, and derived much of his intuition from the patterns he observed from those computations."

I think I used to assume that most of the best mathematicians could read a new theorem or idea, and internalize all of the significance and intuition by simply using logic and working only with the abstractions. People have different ways of thinking, but now I'm not sure if anyone, even a genius, can do that on a truly difficult problem. One needs to avoid blindly "plugging in numbers" or over-generalizing from examples, but working out concrete things and then asking questions, considering cases, inferring, and making hypotheses based on examples seems to generally be the most efficient way to tackle a new problem or idea.

</comment></comment><comment><USER4> I believe, not per se a genius, but very discipline to practice a lot.

<comment><USER5> And a taste for this generic beauty, twisted compaction, underneath mathematics.

</comment></comment><comment><USER6> needs a (2007) tag.

<comment><USER7> I think year tags are only for technology related articles, since they tend to become outdated quickly.

<comment><USER8> I disagree; I clicked this to read it and was dismayed to learn that I had read this YEARS ago. Most posts are brand new content, so all old content should be marked, I think.</comment></comment></comment>


Akatsuki arrives at Venus, mission's fate uncertain - <AUTHOR> http://www.spaceflightnow.com/news/n1012/06akatsuki/

<comment><AUTHOR> Looks like the probe didn't make it:

[http://translate.google.com/translate?hl=en&sl=ja&tl...](http://translate.google.com/translate?hl=en&sl=ja&tl=en&u=http%3A%2F%2Fwww.jaxa.jp%2Fpress%2F2010%2F12%2F20101208_akatsuki_j.html)

<comment><USER2> [http://en.wikipedia.org/wiki/Akatsuki_%28probe%29#Orbit_inse...](http://en.wikipedia.org/wiki/Akatsuki_%28probe%29#Orbit_insertion):

" _The orbit insertion maneuver was confirmed to have started on time. But after the expected blackout due to occultation by Venus, the communication with the probe did not recover as planned. The probe was found to be in safe- hold mode, spin-stabilized state with 10 minutes per rotation._ "

Due to the low data rate in this mode (low gain, I assume unaimed antenna) it'll take a while to figure out what happened.</comment></comment>


SwiftUI Defaults Considered Harmful - <AUTHOR> https://tonsky.me/blog/swiftui/ <comment><USER2> SwiftUI has defaults because nobody knew what UIKit's were supposed to be. Some of them were fiddly secret layout guides in Interface Builder, and some were accessed through the magic "-" in a VFL constraint, but overall it was very difficult to actually know how much spacing things _should_ have. And on Apple's platforms, this matters: users know what things should look like, and if you're off you just look out of place. And if they change in the future, which they have on occasion due to new iOS versions or hardware (iPhone X, anyone?) you might end up off even if you didn't change anything in your code.

SwiftUI _intentionally_ abstracts all of these things away from you so you don't have to deal with it, or even know about it. You're used to programming on the web? Well, the web has no standard. And anyways, people looking for magic defaults is how "8" and "44" show up seemingly randomly in iOS apps. Let the system decide for you…if you _really_ need to override it, you can add your own explicit value.

<comment><USER3> Yea, well said. There are some awkward bits, but if I were writing an article on my first 4 months with SwiftUI it would look totally different.

There are tons of bugs, random issues, and a lack of controllable properties in areas. There's a lack of documentation, performance, etc.

But the language, defaults, components? All wonderfully done.

In fact I'd spend years building a UI kit in React attempting to standardize on things like that, and on seeing and using SwiftUI I was constantly impressed by how well done it all feels when the language (Swift) is robust and designed to work alongside the framework.

Count me as basically optimistic, just hoping they iron out all the beta-y aspects quick!

</comment></comment><comment><USER4> There are definitely a few things it does that are weird, and this article hits on a few of them.

But, I'll call special attention to the whole "adaptive padding thing" as a broader signal for something I feel that SwiftUI does very, very right and more UI frameworks need to start thinking about. Its made to design iOS apps. iOS has a design language that (1) is relatively consistent, (2) changes over time, and (3) changes across the many devices Apple supports.

In this era of many, many devices (don't just think Apple here; think any device; think VR, think TVs, etc), we need to operate at a higher layer of abstraction than most UI systems operate at. Most websites are pure garbage on 35" ultra-ultra-wide displays. It took a decade before mobile web entered the "generally useable" state it is in today. Ever tried to enable an ultra-high DPI setting on, say, Ubuntu or Windows?

All of these are getting better, but they only get better because the underlying technologies are becoming more generic.

> If I forgot to put padding between HStack elements, well, shame on me, there > should be no padding! All mistakes are mine.

Wrong, and Apple has the data to prove it. When you release a poorly designed app to the App Store, the mistake is your's; your customers suffer because of it; and, it hurts the optics of application quality on the App Store, and thus Apple suffers.

This is relatively easy to draw a comparison to, say, manual memory management in C++. "If I forgot to properly bounds check a memory segment, well, shame on me, there should be no bounds checking! All mistakes are mine". Sure; and now your customers are vulnerable to hackers. You have a higher responsibility than just your Pride.

The defaults should be Safe. There should be options to override them when I feel confident I know what I'm doing (and SwiftUI has this, not the least of which being, you don't have to use SwiftUI, you can mix-and-match SwiftUI components with traditional iOS components).

<comment><USER5> Haven't we been going in the other direction in recent years?

With integrated title bars in browsers, custom css, fonts etc.. Chrome on Windows, Mac, Linux etc. always looks like chrome but not native. Similarly webpages look "exactly like the designer intended" even if it is a very bad fit for your device.

We used to do things generically, but changed to prescribing every little detail and this now breaks when our assumptions change.

<comment><USER4> We did use to do things generically, but more-or-less the wrong kind of generic.

Android is a great example of this. I don't know how things are done now, but for its first few years, they had screen size classifiers; ldpi (low dpi), mdpi, hdpi, etc.

Of course, devices got better. That set grew to ldpi, mdpi, hdpi, xhdpi, xxhpdi, and xxxhdpi. There's also tvdpi for televisions.

It was supposed to be generic. It became a mess, because they were operating at the wrong level of abstraction. But whats more; in the beginning, the `dpi` of a device was actually a consistent way to determine the screen size! I saw many apps in the day rely on this; they'd change the text sizes and paddings and even high level UI organization upon render by conditionally checking the dpi of the device. Its generic, right? Its not like I'm saying "if screen width is above 750px, render X" (cough css).

I know less about android as we approach closer to today, but I'm familiar with another problem they had concerning foldables. Android apps were never designed, from the start, to be able to respond to changes in screen size! So that required some new frameworks to be put in place, and old apps had to update.

Point being; our UIs have gotten more complex, because the problems they're solving have gotten more complex. We had HTML; a truly pure form of "generic UI design". But, it was designed for documents, not applications, so we built CSS and JS and wrote ourselves into the mess we're in today. Android had some ideas around generic UIs, but they too did not predict what people would actually be using their platform for and where technology was going.

SwiftUI is another stab at this, and maybe they'll get it right. I don't know. But, I think technology is settling a bit, and with that settling comes a greater understanding of what UI designers need from their frameworks.

<comment><USER6> > Android is a great example of this. I don't know how things are done now, > but for its first few years, they had screen size classifiers; ldpi (low > dpi), mdpi, hdpi, etc.

This example doesn't really work. Those buckets have always been primarily for image asset selection, not UI declaration/layout. It's comparable to the 1x, 2x, 3x that exists in iOS land.

Nothing has ever actually replaced those. In any UI toolkit. Vector assets finally took a chunk out of their usage, but there's still plenty of assets that are not vectors.

The density support in Android largely remains the gold standard. The only UI toolkit that actually achieved robust density independence. There's plenty broken about Android's UI toolkit, just this isn't one of them.

<comment><USER4> Yeah, that was a misprint on my part; I should have referred to them as density classifiers, which is what they are. My brain got jumbled because my broader point came later on, in how there was a time years ago when many apps were elying on them as a signal for screen size, to the point where I saw apps place layout files in a specific mdpi or xxhdpi folder.

Of course, today, I'm sure the Android landscape is more mature and different; I have less context about the thinking around a modern android app today.

</comment></comment></comment></comment></comment><comment><USER7> This website's background color is considered harmful, and "considered harmful" essays are considered harmful.

<comment><USER8> Site is also non-responsive with <meta name="viewport" content="width=640" />, looks horrifying on the 12.9'' iPad Pro even without taking color scheme into account. I know complaining about blog design is out of scope, but if @tonsky is reading this thread, please consider fixing your meta viewport tag.

<comment><USER2> > I hope you have a wide enough monitor to read this.

Perhaps they're merely unaware of how their website looks?

<comment><USER9> Yeah, I did think it was amusing reading that on my 27" 2550px wide monitor monitor that the site formatted it so narrowly. [https://i.imgur.com/VG31Kpj.png](https://i.imgur.com/VG31Kpj.png)

<comment><USER10> For body copy that line length is pretty much ideal (for readability), but the code blocks could definitely benefit from being as wide as possible...

<comment><USER9> Yeah, the reading experience was pretty comfortable. Just thought it was amusing that the author hoped I had a big monitor when the author constrains the code blocks to such a narrow width.

</comment></comment></comment></comment></comment></comment><comment><USER11> Just when I thought Lisp had been ransacked for every last feature that language designers were willing to steal, the "War on commas" pops up -- complete with discussion of the essential differences might exist between "(" and "{", the pain of needing another way to say "if", and the lack of support for the rest of the language.

And the last couple interesting Swift libraries I saw had .gyb files and #if directives.

Apple tried _really hard_ to make a fully static language that was visually elegant (and looked like C), but in the end we need so many dynamic features that what we ended up with seems much more complex than just having had well- designed macros from the start.

The cynic in me suspects that they know this would be worse, but has the advantage that only Apple can add such features, not the common programmer. OTOH, the cynic in me knows that staying far away from Lisp is par for the course, and every new language needs their code to look like an example from the designer's tattered copy of "K&R".

At least they managed to drop C-style for-loops in a mainstream language, so next time a company decides to design a new language, we can hopefully start there. I predict we're about 3 generations of corporate languages away from seeing macros get "invented" again.

<comment><USER12> many modern languages have macros: rust, crystal, elixir, nim not very corporate though, but getting there? with rust(mozilla a bit and others)

<comment><USER13> Java and .NET languages also have them, although a bit cumbersome via attributes, compiler plugins and on .NET's case, expression trees.

</comment></comment></comment><comment><USER14> I really don't think this is a good criticism of SwiftUI.

The author is confused about the whole approach to SwiftUI and spends a lot of words complaining about issues arising out of that confusion. E.g., SwiftUI doesn't use Swift's DSL capability to avoid commas. It uses it to have a declarative DSL integrated into Swift programs. You could argue about the entire approach, but instead the author complains about commas and ifs. The things about the ifs and other potential control flow constructs makes it clear that the author doesn't get what a declarative approach really means.

Likewise, the section about "wraps" where the author feels the SwiftUI API is inconsistent because stacks "wrap" and padding "wraps" so they should use the same syntax. But I think that's just a misunderstanding of the author's. "wrapping" isn't a fundamental concept of SwiftUI so there's no particular reason for the API to be organized around it. (I would say stacks arrange a list of views and padding pads a view. Also, bold() operates on Text and returns Text because Text holds styled text and bolded Text is still Text. padding operates on any View and returns some View. The types flow naturally from the problem domain, so that's good.)

Also the conclusion: "The solution…is to be dumb and explicit!" That's really asking for a completely different framework. It seems a little off to criticism SwiftUI for not being what it was never intended to be.

I think there is good criticism in here, though. SwiftUI introduces a LOT of patterns, concepts, many of which will not already be familiar to many developers. It's concise and reads pretty intuitively, but many developers won't get far before hitting a lot of new stuff... that means steep learning curves and confusion, like the author. I don't know if that makes it bad, but it's certainly anyone consider using it needs to be aware of.

<comment><USER15> The author is also the author of Clojure/script libraries Rum snd Datascript. He knows what declarative means very well.

Swift UI creates a mess of special cases pretending to be declarative, and does a poor job of it.

<comment><USER14> He's suggesting he ought to be able to use imperative Swift control flow constructs in the declarative SwiftUI DSL. I suppose I can't really know exactly what his confusion is, but that just doesn't make sense.

<comment><USER15> It does make sense. Because SwiftUI creates special constructs for regular language features (if, foreach) despite those features, you know, being available in the language.

<comment><USER14> It doesn't make sense because SwiftUI is a declarative language. I understand the confusion, since it uses Swift's DSL feature and is tightly integrated with Swift, but it is distinct and has it's own design that isn't directly compatible with Swift's imperative control flow constructs.

Now, you can argue that Apple should have created a new imperative Swift- integrated UI framework, and if they had, it would be a good criticism if all the normal Swift control-flow mechanisms weren't available natively. But the author and you aren't objecting to SwiftUI's declarative nature.

BTW, If you manage to map all the kinds of loops, breaks, etc, into SwiftUI it isn't declarative anymore. You've managed to go back from describing the UI in terms of "what" (declarative) to "how" (imperative).

Since the author expresses approval of the declarative nature of SwiftUI and complains about it, I know he's confused.

<comment><USER15> No. I, and the author, argue that _nothing_ prevents Swift from having declarative foreach/if.

SwiftUI _already_ introduces severely underdesigned awkward structures to replicate _existing_ behavior, and it _shouldn 't_.

SwiftUI's ForEach and If are ugly unnecessary hacks that replicate existing behavior and raise the question: why aren't other constructs there?

</comment></comment></comment></comment></comment></comment><comment><USER16> I'm guessing the magic layout things are intentional because SwiftUI is designed to make it easy to have one app feel native on iPhone, iPad, Apple Watch, Mac and AppleTV, which all have their own design language and ergonomics.

As long as it provides ways to override defaults and take full control where needed, this seems reasonable. I'm guessing you can drop a Metal view into your SwiftUI app, so quit complaining :)

<comment><USER17> Exactly, if you just want to bang something out that looks like an "apple app" across all those devices I think the auto spacing and sizing stuff works pretty well. You can always tighten it up and override it later.

</comment></comment><comment><USER18> I was really excited about SwiftUI after having done a lot of React development recently. The declarative style is so much nicer than the MVC/procedural code that regular UIKit code becomes.

After 30 minutes of updating Xcode I was able to start writing SwiftUI code. Then another 2 hours upgrading our Swift project to the latest version of Swift. I googled for documentation, found barely anything and the code samples on developer.apple.com were already outdated. I finally got something up and running, but _nothing_ in the semantics worked as expected. Getting a button to render nicely was insanely complex (which view should have the background color? font? trying different things didn't work at all). Oh and recompiling took a minimum of 30 seconds each time.

All this prompted me to finally give react-native a try. In under 15 minutes I had a working example. After making a change I saved the file, alt-tabbed to the simulator and the changes were already applied. And it works instantly on Android, I can try it out on my phone using expo without any hassle.

I just can't comprehend if and how Apple will catch up with that experience?

<comment><USER19> I suspect Apple knows the developer experience for Swift is terrible (even if the Apple developer community at large is in mass denial about this).

The number 2 item on Swift Core Teams goals for Swift 6 is "Create a fantastic development experience". See: [https://forums.swift.org/t/on-the-road-to- swift-6/32862](https://forums.swift.org/t/on-the-road-to-swift-6/32862)

Whether anyone at Apple cares about documentation any more is another matter. A really sad state of affairs, because once upon a time, Apple had some of the best documentation out there. Of course, that was when they actively needed to court a developer community, and couldn't just announce something half-baked at WWDC and get mass adoption from enthusiastic developers.

<comment><USER17> I don't know, maybe some of the die hards are in denial. I really enjoy the language and the platforms but I'd readily admit it's pretty far behind in terms of DX. I think at this point Apple is going to have to make this a really big priority if they want to remain relevant and it's going to take a lot of effort on their part.

<comment><USER20> While I certainly can't speak for all diehards, I hear a lot of complaints about the state of Apple's documentation from long-time developers these days. (In my experience, the true Apple diehards are often _very_ critical of the company, but they tend to have specific trenchant critiques.)

</comment></comment></comment></comment><comment><USER21> While I don't yet have great confidence in my mental model of SwiftUI's type system, my understanding is that the DSL builders exist for more reasons than just to eliminate commas.

The new Function Builder and `some` return type features of Swift allow you to return a complex, nested type describing not just that it's a View but rather also all the structure within.

This means that at _runtime_ you can have a (non-erased!) type describing the contents of your `var body` like this:

        Button<Group<_ConditionalContent<Text, Image>>>

This particular body displays a Text if a state boolean is true, and an image if not.

Super interesting - and having types this descriptive can potentially enable a host of interesting features and optimizations. For example, across evaluations of your UI SwiftUI needs to track the identity (and location in your view graph) of all of your views, in order to keep their state, bindings, and other stuff that needs to remain consistent across time. The position if your view in a type hierarchy is the default way SwiftUI does so. This starts to blur the line between code and the type system, which I think the Functional Programming folks have been exploring for years.

One more nitpick: the use of View Modifiers on children noticed by parents (like the `navigationBarTitle` example he uses (as discussed in the "Child Privacy Invasion" section), is to allow for children to specify metadata that the parent might care about. This is actually pretty nice, because then you can nicely compose together the various parts of your app without having to spread around the configuration for your tab bars and such (which is a bit messy in UIKit).

edit: formatting. I always trip up with it on HN due to the lack of a Preview feature.

<comment><USER22> > One more nitpick: the use of View Modifiers on children noticed by parents > (like the `navigationBarTitle` example he uses (as discussed in the "Child > Privacy Invasion" section), is to allow for children to specify metadata > that the parent might care about. This is actually pretty nice, because then > you can nicely compose together the various parts of your app without having > to spread around the configuration for your tab bars and such (which is a > bit messy in UIKit).

I wouldn't say it's too messy in UIKit but I agree with the motivation. To add some more context here's how you configure the title of the navigation bar in UIKit

        navigationItem.title = "My Title"
        navigationItem.largeTitleDisplayMode = .always

This does not happen in the class that renders the navigation bar(UINavigationController) nor does it happen in the navigation bar view itself(UINavigationBar) it happens in the view controller that is currently on screen and is the "active" child of UINavigationController.

</comment></comment><comment><USER23> Observing the launch of SwiftUI as a bystander (I'm not developing for any Apple platform), it seems that people are very excited about SwiftUI, but also get burned by it a lot. This is mostly Apple's fault by releasing this framework without any caveats. But the framework is more like an early alpha, not to be used in production. Tooling is not yet ready, documentation is not yet ready, heck even Swift –the language and compiler– aren't even ready yet. Apple should've put a big warning notice on any SwiftUI related website to set the correct expectations.

<comment><USER17> I agree for the most part however I have put a simple app in the store with it and it works fine, it's usable for small apps. I had to wrap a few UIKit elements and a few other workarounds that I can't think of right now. But overall I'm happy they released it early and can benefit from the communities feedback and usage rather than building the whole thing in secret and releasing something finished that we might not even want. I hope that this is the beginning of them improving DX on their platforms as they have a lot of catching up to do to be competitive with other platforms.

<comment><USER24> Yeah, my sentiments exactly. I'm in the process of finishing a small app for a client, and it's been a blast. As you said, a number of workarounds are necessary due to the fact that UIKit is so rich, and SwiftUI is rather sparse at the moment.

However the fact that it's so easy to build new UI components, at this phase partly makes up for it.

</comment></comment></comment><comment><USER25> I tried out SwiftUI a couple of months ago and it was buggy even when sticking to the standard Navigation components..

But now it seems like a lot of problems have been solved

[https://stackoverflow.com/questions/59279176/navigationlink-...](https://stackoverflow.com/questions/59279176/navigationlink- works-only-for-once)

<comment><USER2> > even when sticking to the standard Navigation components.

The standard navigation components have _always_ been the buggiest part of UIKit. Don't even get me started on how UISearchController and UINavigationController interact on iOS 13…I have an app that's been sitting on the back burner, with full dark mode support, but unreleased for over six months because I haven't taken the time to figure out why the search bar decides it wants to be _above_ the large title.

<comment><USER25> Didn't know this! Am very much an amateur with iOS development and thought that sticking with the Swift "happy path" would've been a good idea

<comment><USER2> It's gotten better, it will probably work if you're not doing anything complicated. My view is set up from a five-year old storyboard and is dual UINavigationViews with UISearchControllers inside a UISplitView inside a UITabViewController :/ I'd still suggest sticking to the happy path, the other ones are even worse…

</comment></comment></comment></comment><comment><USER26> > Some things are probably just plain mistakes (very funny though). E.g. > NavigationView takes its properties not from its constructor or via > modifiers, but instead from the properties of its first child. WHY?

This sounds like it's just inheriting the default iOS behaviour? The current ViewController sets the Navigation View's properties.

I haven't touched SwiftUI yet, but I'd imagine the existing NavigationController setup still exists within the SwiftUI framework, and this weirdness exists due to legacy reasons essentially.

</comment><comment><USER9> Reading through the syntax changes they made makes me really appreciate the decisions made around JSX and how that works, syntactically. It's _just javascript_ , and none of these weird constructs need to be added into some DSL to support it. There's the reasonably minimal html-ish syntax, then "escape to javascript" to add in conditionals or loops or whatever.

I wonder if there was (or still is) a way to do something similar for Swift and SwiftUI.

<comment><USER27> Surely JSX is ... well it's something that looks a lot like XML, hence the name. It's not just JavaScript, is it? It's pretty much the definition of embedding a DSL.

I've not used SwiftUI but I've used TornadoFX which is similar, but with Kotlin instead of Swift. There's no weird syntax or DSLs (even though they call it that). It's all just functions and lambdas, so the language is always there and the syntax is always consistent with what you use elsewhere. It's not like React/JSX where UI code syntactically looks different.

<comment><USER9> JSX is 'just' an XML-like syntactic sugar for making nesting function calls nicer in Javascript. Yes, its a DSL, but it keeps the "domain" extremely small and it transpiles in a very straightforward way down plain javascript

        <Container>
          <Text weight="bold">madeofpalk</Text>
          <Image src={profilePic} />
        </Container>

        // is syntactic sugar for
        React.createElement(Container, null,
          React.createElement(Text, { weight: "bold" }, "madeofpalk"),
          React.createElement(Image, { src: profilePic })
        );

Whenever you need 'logic', you just escape out to javascript with braces

        <Container>
          { isVerified ? <Tick /> : null }
          <Text weight="bold">madeofpalk</Text>
          <Image src={profilePic} />
        </Container>

JSX has no conditional syntax, no ternaries or any extra constructs apart from how to nest children. This is I think a simplicity that would have been nicer to see in SwiftUI.

<comment><USER27> I guess I'm not sure why this is better than the Kotlin/Tornado/SwiftUI approach of allowing you to move a lambda in the last parameter visually out of the function. So:

        container {
            text(weight = "bold") { "madeofpalk" }
            image(src = profilePic)
        }

It seems more logical and consistent with the rest of the language. The only reason for the HTML-like syntax is JavaScript's tight connection to the web, after all.

<comment><USER9> I apologise for not being clear, but the point I'm trying to make is not around the angle bracket syntax, but with how light the DSL is and for any sort of logic syntax, you just escape back to Javascript.

JSX does not have conditionals or loops in its syntax. SwiftUI does.

</comment></comment></comment></comment></comment><comment><USER28> This is a very myopic view of UI development. The library is built to give you sane, well designed defaults that is lay together well when following the HIG, and which you should rarely attempt to override. Case in point, HStack, whose sole purpose is to _stack items horizontally with proper spacing_ and is quite hard to achieve correctly on the web. If you want "dumb and explicit" why use a UI kit?

</comment><comment><USER29> _> When fixing broken layout, it is always easier to add stuff that you forgot than removing stuff that your framework did for you and you that can't see._

This paragraph reminded me of this old Jargon File koan:

\---

In the days when Sussman was a novice, Minsky once came to him as he sat hacking at the PDP-6.

 _"What are you doing?"_ , asked Minsky.

 _"I am training a randomly wired neural net to play Tic-Tac-Toe"_ Sussman replied.

 _"Why is the net wired randomly?"_ , asked Minsky.

 _"I do not want it to have any preconceptions of how to play"_ , Sussman said.

Minsky then shut his eyes.

 _"Why do you close your eyes?"_ , Sussman asked his teacher.

 _"So that the room will be empty."_

At that moment, Sussman was enlightened.

<comment><USER30> I've never understood this one. Initialized randomly and then trained is accurate; Minsky is the one who comes off as ignorant, when the last line is supposed to indicate the opposite.

<comment><USER29> That's not ignorant on his part, it's just a silly analogy to get the point across; and I think you're missing the point by thinking of what happens _after_ the network is trained; the point made is about the _initial_ state of the network, not the outcome.

The neural network will have preconceptions on how to play no matter how, even if you wire them randomly; the difference of making them random is that you'll have no idea what those preconceptions are, not that they don't exist. The original story on which the koan is based might make it clearer.

[1] [https://simple.wikipedia.org/wiki/Hacker_koan#Uncarved_block](https://simple.wikipedia.org/wiki/Hacker_koan#Uncarved_block)

If you still want this to be about the final state, the point would be that, if the training process works well, it shouldn't make any difference whether the net was wired randomly or orderly.

</comment></comment></comment><comment><USER31> The "X considered harmful" trope for deliberately strident technical screeds that quibble about what are mainly niche concerns has tired me out.

"'X considered harmful' considered harmful", I guess.

<comment><USER32> You're going to love this essay by Eric Meyers.

[https://meyerweb.com/eric/comment/chech.html](https://meyerweb.com/eric/comment/chech.html)

Now I await "Comments linking to the 'considered harmful essays considered harmful' essay on 'x considered harmful' discussions considered harmful".

</comment></comment><comment><USER33> I think everything after the first gripe is a fair point, but I don't get what the problem is with the first code chunks... it seems like the author is saying "this is weird to me, and I don't like that," but I have no idea how else it'd work properly.

For example, explicitly defining out function arguments is exactly what Scala does for function, check out this bad mofo, defining a function with 22 arguments (that I fell in love with years ago): [https://www.scala- lang.org/api/current/scala/Function22.html](https://www.scala- lang.org/api/current/scala/Function22.html)

Why'd I fall in love with it? Because it makes sense, that's how it should work right? I don't see how defining out 10 items explicitly; so, that each can have it's own type, is a problem. It's pretty damn nice they did it out to ten arguments, if you want more, extend the object... /shrug

If you used a list instead, e.g. `T[A]` you'd take a hot-fat erasure-shit on the type information of each item in the list (or at least you would last time I used Swift extensively)... this way you keep that type information around.

P.S. To be honest, explicitly defining things out like that can give you HUGE wins in languages like Swift because you give the compiler so much more information. It just doesn't usually pop onto most folks radar because it looks obtuse... with most modern code editors though it's easy enough to write in a couple minutes, if there's no macro system.

</comment><comment><USER22> I really don't agree with most of this post but I do find the function builder[0] feature that was introduced to support SwiftUI fairly overkill. I don't fully understand why they didn't use a lighter abstraction based on arrays and normal return values like React does instead of adding all this "magic", maybe there's a really good reason that I am not seeing.

All the other "magic" and defaults are excellent ideas because they encode Apple's Human Interface Guidelines[1] straight into the framework which helps you create apps for the different Apple platforms that will fit in and feel at home. With a web or React Native/Flutter/Cordova/... context this might seem jarring but the whole point is that an app it shouldn't be a completely free form canvas and the frameworks should make it easy to build a best in class HIG compliant Apple app.

0: [https://www.swiftbysundell.com/articles/the- swift-51-feature...](https://www.swiftbysundell.com/articles/the- swift-51-features-that-power-swiftuis-api/)

1: [https://developer.apple.com/design/human-interface- guideline...](https://developer.apple.com/design/human-interface-guidelines/)

</comment><comment><USER34> > I mean, the only difference before the two is whether you have to put a > comma between elements or not.

Personally, I vastly prefer minimizing punctuation in code. Most punctuation like this only lends itself to creating places where additional errors and bugs can creep in. Listing elements on separate lines gives you the separation needed so it's clear it's a list of things, the comma at the end of the line is needless.

> All because someone in charge of API design was afraid of lists and had more > power than someone in charge of Swift language.

I suspect the people in charge of designing the Swift language have a similar aversion to needless punctuation in the language. They made a point of calling out the lack of a semi-colon in the original Swift launch announcement. This isn't some API designer pushing the issue, it's part of the philosophy of the language.

</comment><comment><USER35> I recently started a SwiftUI project and this is a very accurate take based on my experience.

How I spend my time in SwiftUI: 1\. Wondering how I can get some conditional logic. Coming from React, this is a major issue that needs to be addressed. 2\. Figuring out where and what the error actually is. 3\. Restarting Xcode for my view to magically start working again.

The two-way data binding is a blessing and a curse. I like React's method of passing callback functions to keep the state logic separated. This comes up with me when working with sheets.

I see the potential. I like having an all-in-one experience that IDE + framework integration provides but the poor defaults and breaking bugs really make me question the execution.

</comment><comment><USER36> I'm in no hurry to start using SwiftUI. I'm giving it another year.

That doesn't mean that I don't like it. I think it's a great idea. It's just having a hard time clambering out of the bassinet.

<comment><USER24> > It's just having a hard time clambering out of the bassinet

What are the reasons for you to have this opinion?

<comment><USER36> Mostly the limited uptake (I anticipated that), and the maturity of the tools. I despise IB/Storyboard Editor, but it gives some serious control over a lot of stuff.

I don't mind doing programmatic tweaking, but on my machine, at least, I don't get very reliable previewing. I have to run the app to get an idea of how my tweaks are working (to be fair, IBE is similar, but the preview is somewhat more reliable).

I really want this to work. I'm glad to see KVO getting some love on iOS.

<comment><USER24> Limited uptake by developers you mean? How do you determine that?

I had two instances where the preview turned out to be a hassle (crashing, or hard to get it to work).

First was a test project with Core Data. It was a hassle to set up the preview. So much so, that I often skipped it.

Second instance was crashing; I'd created a View but the layout was based on something in UserDefaults, and I forgot about that. So when I created another view that incorporated that first view, I got crashes. So bad, in fact, that a restart of Xcode didn't help. I had to close Xcode, then on the commandline, find and kill the daemon responsible for previews.

Were you able to point to causes of the unreliable previewing in your case?

<comment><USER36> Aw..heck. I'm not gonna get into back-and-forth.

I will say that I have been developing Apple software for 34 years, so I tend to be a little on the.."hard-boiled cynic" side.

I have taken OpenDoc and QuickDraw GX classes, because they were "The Next Big Thing."

I also busted my butt, making sure that my apps were "Copeland-ready" _(Darn it, now I have to do fifty push-ups)_.

I've learned that it's a good idea to stand back a little, and let the eager beavers soak up the bullets.

I love Apple (see "34 years," above), but they are absolute Charisma 18 hype machine masters.

<comment><USER24> Leaning towards the careful end of the spectrum, I can respect that. Especially once you're fast with UIKit, and Auto Layout. And Auto Layout kinda proves your last point; there's absolutely nothing "auto" about it.

<comment><USER36> Auto Layout is a nightmare. I won't be sad to see the back of it.

It took me a couple of years to figure out how to use it properly.

Like I said, we're on the right track, and I doubt that Apple will let this fall by the wayside. I think they were planning this at about the same time that they started dreaming up Swift.

</comment></comment></comment></comment></comment></comment></comment><comment><USER37> > I hope you have a wide enough monitor to read this. Not only does this seem > ad-hoc and unpretty, but it also doesn't allow you to put more than 10 > elements in a container! All because someone in charge of API design was > afraid of lists and had more power than someone in charge of Swift language.

This explanation doesn't sound right to me coming from other statically typed languages where you're stuck either using codegen or arity hardcoding. Currying also gives a nice solution where your DSL simply builds up a function A->B->C->...

Hard-coding each level of arity is done so that your generics keep upstream type knowledge.

Here's an example in Elm, though it has to keep renaming the function due to lack of arity overloading.

[https://github.com/elm/json/blob/063aaf05e0dc5a642bacbdaae59...](https://github.com/elm/json/blob/063aaf05e0dc5a642bacbdaae59c33dcfd116898/src/Json/Decode.elm#L420-L450)

You can't use variadic functions because then you function doesn't even know how many arguments it has at compile time much less any specifics about them.

That Swift doesn't require commas between closure returns seems like a different point.

You'd still need this solution even if you were just spitting out generic TupleView<(View, View)>, TupleView<(View, View, View)>, etc.

Unless, of course, you don't actually care about type info the same way you don't care how many arguments are passed to a variadic max(1, 4, 66) function.

Another comment says there will be a variadic viewbuilder function once Swift gets variadic generic functions which will still throw away type info, so this seems to be the case. Still, I don't see the relationship with commas.

</comment><comment><USER38> Just to point something out: his first complaint is over needing to have up to 10 generics, this will be going away with variadic ViewBuilders that should be coming soon, towards swift 6 perhaps. And will also remove the limit for number of children. This is mostly a limitation in swift generics, not swiftui it self

</comment><comment><USER39> Honestly, just use UIKit. SwiftUI is a bolt-on framework on top of UIKit to provide a React-like experience for web devs so they won't rage too much when Apple inevitably bans ReactNative and Flutter.

<comment><USER17> SwiftUI is raising the abstraction layer and aiming to provide something much more productive than what UIKit currently offers. You've framed your comment as if web developers are cargo-culters who only know how to use React. The web has already experimented with classic MVC approaches (backbone etc.) and moved beyond it. Android's Compose is taking a similar approach, as is Flutter which as far as I can tell is not necessarily aimed at web developers. Also why would Apple ban React Native and Flutter?

<comment><USER40> I don't believe they'll ban it. I do believe they'll increase friction to the point that it becomes a huge pain to use either for anything but prototyping.

<comment><USER17> I can't see really why they care that much how the app is written, if it adhears to the app store guidelines and makes them money then I doubt they're that interested in banning it or increasing friction. Nearly all the current top selling iOS games are likely written in Unity and I can't see them banning that.

<comment><USER41> Platform coherence, but also look & feel come to my mind.

While the guidelines are what the word says, vague guidelines with a lot of room for interpretation, they don't necessarily dictate any details. When you look at it from a more technical point of view, it's harder to do something nonconforming with Apple's frameworks than with 3rd party alternatives.

Games are a different thing. They are more like their own operating system within iOS and usually have their own quirks (to make them playful).

</comment></comment></comment></comment></comment><comment><USER42> Would it be possible to wrap SwiftUI such that we don't have to use that DSL, don't have that 10 child limit (how many hours wasted figuring that one out?), and don't have bizarre non-localized error messages?

My guess is the answer is no because SwiftUI builds view hierarchies using parameterized types, so you're always stuck with `some View` and the associated complexity.

</comment><comment><USER43> Is SwiftUI only compatible with the newest iOS versions? Will using SwiftUI mean only people running iOS 13+ can use it?

<comment><USER2> Yes.

<comment><USER44> That said, current iOS 13 adoption rate is already at 93%...

<comment><USER45> Citation?

I just checked <[https://mixpanel.com/trends/#report/ios_13>](https://mixpanel.com/trends/#report/ios_13>) and it shows iOS at 85%.

About a month ago, I started releasing versions of our app on iOS 13 in TestFlight (I wanted to use the new SF Symbols) only to discover there are a lot of iPhone6 models out there. My first reaction, was "c'mon, that's a 6 year old iPhone, time to move on!" until I found that Apple kept selling the 6 all the way through 2017. A lot of "budget" buyers purchased iPhone 6's up through that period. So I've come to be skeptical about these claims of adoption rate. I subsequently reverted to iOS 12. :(

<comment><USER43> I asked this question because I still use an iPhone 6, and can't update past iOS 12. My MacBook Pro from 2013 can upgrade to Catalina and handle developing with it, but I'd rather have a compatible device than rely on the phone simulators.

</comment></comment></comment></comment></comment><comment><USER46> Interesting how most of his points are exactly how Flutter is implemented. For example the trailing commas, and no assumed defaults.

</comment><comment><USER47> Things with "considered harmful" in the title should be considered harmful.

<comment><USER48> Considered Harmful essays considered harmful: [https://meyerweb.com/eric/comment/chech.html](https://meyerweb.com/eric/comment/chech.html)

</comment></comment><comment><USER49> I am not sure it's a good idea to take advice from someone that picks such a background color

</comment><comment><USER50> To the person who wrote this, I would suggest SwiftUI is not for you. Please just go back to writing Objective-C or learn some good ol' UIKit. You can then have full control over whatever color you want your buttons to show up as, and where to have them show up, and with whatever padding you like, and as a bonus you can use commas and all kinds of great additional syntax all over the place. (I think what SwiftUI is for, has largely flown over your head).swiftly</comment>


A Discussion of Li-Meng Yan's Paper on SARS-CoV-2 - <AUTHOR> https://www.randombio.com/ratg132.html <comment><USER2> Don't worry Twitter already suspended her account, all good. Just keep going and smile

</comment><comment><USER3> _" It would be premature to draw any conclusion about the origins of the virus from this paper. But what is not premature is that social media giants deciding for us what is true and what is false may turn out to be as big a threat as the virus. It is unfair to dismiss ideas that one doesn't want to hear as "conspiracy theories" as many people are doing."_

</comment><comment><USER4> This Week in Virology, Episode 664, where virologists discuss this paper. Get an expert opinion. ([https://www.microbe.tv/twiv/](https://www.microbe.tv/twiv/))

<comment><USER5> >another bogus claim that the virus was produced in a laboratory (it came from Nature)

Seems the "expert" opinion is entirely dismissive of any claims contradicting the narrative that it came entirely from nature/naturally selected. Despite the fact that this week, there's research showing the pangolin was ruled out as an intermediate, and the bat theory is totally absurd.

I find other discussions[1] surrounding this far more compelling than an outright dismissal. Jumping to any conclusion, either way, is premature. But I'd hope we'd all agree that if it escaped from a lab when researchers were doing GoF research, that such research should be banned worldwide. And this apparently being the third lab escape in a decade from Chinese labs, that they are far more scrutinized.

[1] [https://www.reddit.com/r/COVID19/comments/ismdn7/unusual_fea...](https://www.reddit.com/r/COVID19/comments/ismdn7/unusual_features_of_the_sarscov2_genome/g5dcgw6/?utm_source=reddit&utm_medium=web2x&context=3)

</comment></comment><comment><USER6> It strikes me as somewhat disingenuous to not mention why this article was "cancelled" in the first place.

<comment><USER3> It strikes me as disingenuous to "cancel" the article based on who funded it, as opposed to the arguments and the evidence that is presented, especially considering that publications that are ultimately funded through the Communist Party of China are not receiving that kind of scrutiny.</comment></comment>


What's the Matter with Dem? (interview with author Thomas Frank) - <AUTHOR> http://www.salon.com/2016/04/02/whats_the_matter_with_dem_thomas_frank_talks_bill_clinton_barack_obama_and_everything_in_between_partner/ <comment><AUTHOR> His critiques on American notions of meritocracy and Silicon Valley are what's relevant to HN.</comment>


Show HN: Chat with people around you - <AUTHOR> https://oyoy.app <comment><USER2> If I understand correctly the "people around you" is decided purely by distance. In that case is there anything done to avoid seemingly nonsensical conversations for a random observer? With this I mean if two people are in distance close enough to chat and the third one (the "observer") is only in range to one of them would the observer only see half of the conversation.

<comment><USER3> Interesting. The hidden node problem for people.

</comment></comment><comment><USER4> NSFW - embedded images are references to other websites. My local chat was mostly shock images. Not great if your internet is not your own.

</comment><comment><USER5> Perfect for the dinner table.

</comment><comment><USER6> Last time a "Show HN" was posted with a similar nearby chat app, I was in Disney World and there was not much engagement ( [https://news.ycombinator.com/item?id=16976287](https://news.ycombinator.com/item?id=16976287)).

I'm in Disneyland now, and I've tried it out now, but not much engagement. I will check it throughout the day, but I mirror the suggestions made, either increase the 1 km radius (the park here is longer than 1 km) or include the closest 10 users.

<comment><AUTHOR> This is the rebranded and improved version of Ping.gy. [https://medium.com/@vasanthv/introducing- oy-2664a5c95d75](https://medium.com/@vasanthv/introducing-oy-2664a5c95d75) reply "either increase the 1 km radius" \- I understand the problem you are facing, will try to address them.

</comment></comment><comment><USER7> There should be an option to change how far 'here' is.

<comment><USER8> Agreed. I'm in Maine - not many of us 'here' to begin with :)

<comment><USER9> The network effect needs to come into play and yes, one should get the opportunity to expand the geographical boundaries.

</comment></comment></comment><comment><USER10> oh, I like it! specially that poetic moment when you find out that you are all alone. waiting for someone is nice. no, seriously, I think the idea is great. in general, I like the idea of using internet to bring closer people who are already geographically close, so they actually have a decent chance to share something outside the screen. a chat might be the most dangerous way to do this, but anyway, still cool.

a "simple" idea to dynamically adjust areas, if you aren't doing it already, at least for lonely people, is setting a timer and progressively expand/reduce the "here" area, up to a more generous limit? (basically, automatic population density control, _in an evil way_ )

<comment><AUTHOR> Thanks for the suggestion. Will add to the todo.

</comment></comment><comment><USER11> Got this error with Firefox 61 (latest release) when I tried it, but it seems as if it can continue. No one else around though.

> Messaging: This browser doesn't support the API's required to use the > firebase SDK. (messaging/unsupported-browser).

<comment><USER12> same on Safari Version 12.0 (14606.1.36.1.9)

</comment></comment><comment><USER13> All the nerds in Brooklyn are still asleep I guess. :'(

</comment><comment><AUTHOR> Hi all, I am the maker of the this product. Covered some use cases here [https://medium.com/@vasanthv/introducing- oy-2664a5c95d75](https://medium.com/@vasanthv/introducing-oy-2664a5c95d75)

<comment><USER13> It would be interesting to be able to have a view-only mode for chats going on in places you're not located. I'd be curious to see what London or Sao Paulo are chatting about, even if I can't join in. :)

<comment><AUTHOR> Ok. Something like Peek feature in YikYak.

</comment></comment></comment><comment><USER14> Wechat has that feature (but none of the other standard chat apps I'm aware of).

<comment><USER15> And it seems to be used mostly for hook-ups. Most people probably can't think of any other reason to look for strangers nearby.

</comment></comment><comment> d--b Nice design. I'm the only one there though ;_;.

</comment><comment><USER16> The same thing with directional voice would be cool.

<comment><AUTHOR> I didn't get the point. Can you please explain little more detailed?

<comment><USER17> An audio version of this app - maybe with push to talk. It's essentially be a walkie-talkie. Though without the bluetooth range limitation that typically comes with that flavor of app.

<comment><USER16> Yeah, with the schizophrenic twist that you can listen in and talk to voices from very far away, from the direction they come from.

</comment></comment></comment></comment><comment><USER18> it would have been nice if the text box would have remained focused after the message is sent

<comment><AUTHOR> Nice suggestion.

</comment></comment><comment><USER12> not working on safari?</comment>


CloudFlare hurt our SEO, so we built our own half-assed CDN using AWS+Nginx - <AUTHOR> https://www.jitbit.com/alexblog/281-cloudflare-seo-and-building-my-own-caching-proxy-with-nginx/ <comment><USER2> Ah yes, sex work jokes in 2019. That's going to resonate well.</comment>


USGS Interactive Earthquake Map - <AUTHOR> https://earthquake.usgs.gov/earthquakes/map/#%7B%22autoUpdate%22%3A%5B%22autoUpdate%22%5D%2C%22basemap%22%3A%22grayscale%22%2C%22feed%22%3A%227day_all%22%2C%22listFormat%22%3A%22default%22%2C%22mapposition%22%3A%5B%5B7.798078531355303%2C-138.515625%5D%2C%5B60.02095215374802%2C-51.50390625%5D%5D%2C%22overlays%22%3A%5B%22plates%22%5D%2C%22restrictListToMap%22%3A%5B%22restrictListToMap%22%5D%2C%22search%22%3Anull%2C%22sort%22%3A%22newest%22%2C%22timezone%22%3A%22utc%22%2C%22viewModes%22%3A%5B%22list%22%2C%22map%22%2C%22settings%22%5D%2C%22event%22%3Anull%7D <comment><USER2> Was surprising to see so many quakes in Oklahoma, which led me down the rabbit hole to this:

quote "The 2009–19 Oklahoma earthquake swarms are a series of human activity- induced earthquakes"

[https://en.wikipedia.org/wiki/2009%E2%80%9319_Oklahoma_earth...](https://en.wikipedia.org/wiki/2009%E2%80%9319_Oklahoma_earthquake_swarms)

<comment><USER3> 'human activity', aka fracking.

</comment></comment><comment><USER4> If you're in an earthquake-prone area, I suggest signing up for the Notification Service ([https://earthquake.usgs.gov/ens/](https://earthquake.usgs.gov/ens/)). Based on the radius from a given location, they can text and e-mail you when there's a minimum magnitude quake detected.</comment>


Why buying used cars could put your safety at risk - <AUTHOR> http://money.cnn.com/2017/02/17/technology/used-car-hack-safety-location/ <comment><USER2> This clearly applies to all new cars as well. I wonder why they chose to frame it this way. Its not as if the auto industry was famous for paying for better treatment in the press or anything. This is what happens when you don't control what you own...</comment>


What If Apple Is Wrong? - <AUTHOR> https://www.technologyreview.com/s/601145/what-if-apple-is-wrong/ <comment><USER2> I guess nobody ever solved a crime before the iPhone was invented.</comment>


Ideas subreddit: submit your ideas here and see what others think of them - <AUTHOR> http://reddit.com/r/ideas/

<comment><USER2> Sounds like a good way to brainstorm.</comment>


Ask HN: Should Browsers load explicit content in Incognito mode automatically? - <AUTHOR> That way explicit content urls won't land in browsing history accidentally. Should browsers do that automatically or ask user every time domain known for explicit content gets detected? <comment><USER2> It's an interesting idea, but I think that it'd have to tell users the current page is considered 'explicit', give them a clear opt out and maybe make it an optional feature you can opt in to instead.

That's because actually detecting a piece of content is explicit is much trickier than it seems, and if the browser makes a mistake... well the user is going to end up with a page they may want to revisit being excluded from their browsing history, and potentially impossible to find again. That's not going to go down well.

Add to how different people are when it comes to deciding what they count as explicit (and what they do/don't want to be visible to friends/family/coworkers/etc), and this seems like a feature that'd have to be opt in to work well.

</comment><comment><USER3> That is a interesting idea, but if implemented it should be user-configurable what URL patterns (and sources of URL patterns, so that you do not have to enter all of them by yourself if you do not want to) and to enable/disable such function, and maybe should be an extension. Anyways there are other purposes for Incognito mode too that you might want such a thing (which is possible whether it is "explicit content" or not).</comment>


Sleep Sort - <AUTHOR> http://dis.4chan.org/read/prog/1295544154 <comment><USER2> 4chan discussion aside, the concept here is that you 'sleep' _n_ units of time for each element, where _n_ is linearly related to the lexical relationship of the element to the other elements in the list. The 'aha' was that the resulting threads will 'wake up' or 'return' in lexical order.

Basically if you transform set L into the time domain, when collecting it back you get it back sorted.

Its a fun result, and as an exercise in systems analysis it can be enlightening to look at the impact of timer resolution, thread creation, and ordering, but ultimately the 'trick' is that you've exploited the 'insertion sort' that the kernel does on sleep events. You could try its close cousin "priority sort" where you create threads where you set the priority of each to be related to the value 'n' of the element, and all fractionally lower than the parent thread (most UNIXes are not that flexible but some realtime OSes are) then as the last step you 'yield' and the threads print out their contents in priority order and poof they are sorted. But again, the sorting happened in the kernel when they got inserted into the runq in priority order.

</comment><comment><USER3> I was impressed by the brevity of the C solution using OpenMP (comment #81), especially compared to significantly more verbose Erlang and Haskell examples. I kept reading it, thinking, "Where's the fork?" and seeing nothing but a simple for...and then remembered that # is a preprocessor directive, rather than a comment, in C, and then googled for "parallel omp for". So, I actually learned something today from that ridiculous thread: <http://en.wikipedia.org/wiki/OpenMP>

Also, the Perl 6 one-liner is sort of laughably cute . I'm not sure I believe it would actually work, but if it does, the conciseness of Perl 6 is even higher than I'd realized; dropping about 9 words from the Perl 5 one-liner (which is already very small). But, I learned about the hyper operators in Perl 6, which is also cool: [http://perl6advent.wordpress.com/2009/12/06/day-6-going- into...](http://perl6advent.wordpress.com/2009/12/06/day-6-going-into- hyperspace/)

In short, that was awesome reading over my morning tea.

<comment><USER4> There's a few short implementations of this algorithm on CodeGolf.SE: [http://codegolf.stackexchange.com/questions/2722/implement-s...](http://codegolf.stackexchange.com/questions/2722/implement- sleep-sort)

<comment><USER3> I'm relieved to note that Haskell and Erlang _don't_ have to be ridiculously verbose. There's even an Erlang one-liner that is competitive with the Perl and Ruby implementations for brevity. I was amused to note that Perl is still the shortest implementation, and could be shorter (though the frighteningly short Perl 6 implementation mentioned in the 4chan thread is either wrong, or the implementation of the <<. operator is still unfinished in Rakudo Star, because it does not actually do the job; I don't understand the hyperoperators well enough yet to know which is true).

</comment></comment></comment><comment><USER5> It finally happened.

HN cut out the middle man. Instead of linking to something on Reddit about 4chan, we finally just linked straight to 4chan.

<comment><USER6> problem with 4chan is that it's blocked at work (probably for good reason). Now I need to find the reddit summary.

<comment><USER7> Sleepsort: For each item in a list of items, create a thread that sleeps as long as its number, then prints its number.

E.g. 5,3,2,1,10 makes five threads, one sleeps for one second and prints 1, one sleeps for two seconds and prints 2, one sleeps for three seconds and prints 3, one sleeps for five seconds and prints 5 and the last one sleeps for 10 seconds and prints 10.

</comment></comment></comment><comment><USER8> That was a brilliant joke, hardest I've laughed all day. Some choice comments:

      I don't like to wait 218382 seconds to sort '(0 218382)

      If you slept exp(n) instead of n it could easily include
      negative integers too*!*

      Oh shit, we're busted, there's a REALISTICALLY THINKING
      PERSON in this thread!

</comment><comment><USER9> For those few of you not conversant with 4chan, the _dis_ subdomain is text only, like the original 2ch. The textboards tend to be disdainful of the imageboards, and incidentally, they get much less traffic, since it's impossible to post porn on them.

The mailto:sage links in some of the posts are essentially public downvotes; from the Japanese "下げ", meaning "down", and pronounced "sah ge".

<comment><USER10> I consider myself conversant with 4chan, and I had no idea that the dis subdomain existed.

I always wondered if there was a chan for hackers...now I realize there is. And oh boy, what a chan it is.

<comment><USER11> Most decent sized chans have their /prog/ board. See shii's Overchan[1] for a comprehensive list of chans on the WWW.

Shii personally runs a pretty nice chan called 4-ch[2] with a large and decent DQN[3] textboard. (S)he founded this chan after being banned from 4chan and SomethingAwful. I don't know whether shii still frequents 2ch or Futaba.

I don't consider the English chans online for programming to be all that great. Most (if not all) are textboards with few postings and lots of trolling over the last 3 years. I don't know the state of the huge Japanese ones however, as I do not frequent them or read the language.

[1] <http://shii.org/2ch/>

[2] <http://4-ch.net/4ch>

[3] 4-ch.net/dqn/

<comment><USER12> Squeeks runs 4-ch, not shii.

edit:

also, shii doesn't run overchan either--Mohey Pori does

from what I remember, someone DDoS'd it in their war against all imageboards (can't remember who) and shii ended up hosting it

</comment></comment></comment></comment><comment><USER13> Many of the posts here and on 4chan have deconstructed the algorithm and proven that it is actually O(n^2) or O(n * lg n) when you include the work done by the operating system's scheduler.

However, here's a different perspective to look at this from: What if this were implemented on an FPGA?

Let's ignore for a moment that the number of gates needed would increase linearly with the size of the input. I'll also simplify the math by assuming that a list of n numbers contains only values in the range [0 .. n] .

Let's further assume that we're only sorting positive integers, and that each job sleeps for x clock cycles (where x in the input number). We could sort a list in O(n) time.

Digging even deeper: Quicksort performs an integer comparison followed by a branch O(n lg n) times. Even if your processor can compare two integers in one clock cycle, a branch is probably going to screw up your processor's pipelining and take quite a few clock cycles to execute. So, we're possibly looking at a significant speed increase even before we consider the difference in order of growth.

So, assuming a predefined upper bound on the number of items in a list, this just might be a great way to perform hardware-assisted sorts.

Thoughts?

<comment><USER13> I just realized: We would need a circuit polling each of the jobs to see when they finish, and I don't see how it could poll all of jobs every clock cycle. So I don't see it being possible to achieve the per-cycle resolution I suggested above.

Furthermore, the polling circuit would have to poll each of the n tasks n times, leading us finally back to a running time of O(n^2).

Still a fun thought experiment, though.

<comment><USER14> Why would you poll the tasks? Cant the tasks wake up after their time is done, just fire an interrupt witht he number of the task.

</comment></comment></comment><comment><USER15> Reminds me of "ListBox sort" story I heard once; it was about a programmer who, wanting to sort strings and not knowing how to do this, put strings into a hidden ListBox GUI control and then read them back in sorted order.

<comment><USER16> When I was, like, 10, I wanted to find the distance between two points in a Visual Basic program but didn't know how, so I created a Line control between the points and tried to read back the Width. (It didn't work, since Width was just the thickness of the line.)

</comment></comment><comment><USER17> It's actually an interesting solution. If you reduced the time waited to a microsecond, then it would take about a second to sort 1M elements. Definitely not an optimal solution, and has a bit of potential for race conditions (if one thread/process got hung up on I/O), but interesting none the less.

<comment><USER18> At that resolution a modern OS is likely to round up the delay to some energy- saving number, and the run queue is going to be so contended that even if the timers fired at the right time, there would be little guarantee the processes awoke in the desired order.

I think on Linux the granularity thing is true for e.g. nanosleep(), but there is also the POSIX clock_*() functions, which I think guarantee higher resolution.

<comment><USER19> higher resolution, but I don't think precision (especially in the face of I/O)

</comment></comment></comment><comment><USER20> This isn't interesting at all. every thread sleeps for that long. When you sleep, something like this happens:

The OS is told to wake up your thread after x time has elapsed. It puts this request into some data structure which it does something like poll from time to time so it knows what thread to wake up at what time. You are offloading your sort to the OS, which is probably then doing something like putting it into a linked list of timeouts that have been registered (maybe a heap?). After approximately the allotted time, some mechanism akin to a signal is used to tell your thread to wake up.

Also, usually the thread will just sleep AT LEAST as long as you tell it to sleep, but if the system is busy it could sleep a long time more. Threads can be woken up at the same time or slightly out of order, or 'woken up' only to find that all the cpu's are working on something else, and thus waiting for a time slice, getting one, then waiting again, and not getting to use stdout for _weeks_. It's uncommon to see machines with really high load these days, but a 1 core computer with 25000 processes all competing for CPU time, and which is swapping heavily, will potentially run each process millions of times slower than running one process.

TLDR; This is curious, but will fail much of the time, has huge memory overhead. Lots of good sorts are in place, this one requires something like 8mb per thread on linux due to the stack allocated for the thread. At best this takes millions of years potentially, and just does some other sort anyway.

<comment><USER21> 8mb per thread is just constant overhead.

<comment><USER19> constant in the number of elements, sub-constant in the size of the input

<comment><USER22> I think maybe it's been too long since I last did analysis of algorithms … the only sensible meaning that I can assign to 'sub-constant' is that the contribution tends to `0` as the input grows; but it seems to me that `8 mb/thread * ≥ 1 thread` is certainly `Ω(1)`. (Or maybe I just missed a dry joke?)

<comment><USER19> 8 MB is constant, but the number of bits in the input grows like log of the largest input value, so the 8mb overhead contribution goes down as the input grows.

Of course, the kernel isn't going to support more than 64 bits of sleep times any time soon, so it's okay if you want to say it's constant. ;-)

<comment><USER22> I'm sorry … surely that just means that the _relative_ overhead tends to `0`, which one should express by saying that the _absolute_ overhead is sub-linear (constant, in this case)?

<comment><USER19> the absolute overhead is linear in the number of elements, sub-linear in the size of input

</comment></comment></comment></comment></comment></comment></comment><comment><USER23> I used to work as an editor for freshmeat.net and we would get hilarious submissions like this quite frequently. For example, the "revolutionary new file compression algorithm" that quite literally converted a file into binary and removed all the 0s. Such a shame that the author "hadn't gotten around to" writing a de-compression tool!

We were often quite sad that we _couldn't_ publish some of these gems, they were brilliant.

</comment><comment><USER24> Would someone please summarize the article?

There's no way I'm clicking a 4chan link from here at work.

<comment><USER3> It is currently SFW (it seems to have images disabled).

But, the post that started it all is:

Man, am I a genius. Check out this sorting algorithm I just invented.

      #!/bin/bash
      function f() {
          sleep "$1"
          echo "$1"
      }
      while [ -n "$1" ]
      do
          f "$1" &
          shift
      done
      wait

      example usage:
      ./sleepsort.bash 5 3 6 3 6 3 1 4 7

<comment><USER25> _It is currently SFW (it seems to have images disabled)._

/prog/ is a text-only board.

<comment><USER26> There is an ASCII swastike with racist slur in the thread now.

</comment></comment></comment></comment><comment><USER27> One of my less well received interview questions is: "Okay, we both know theoretical lower limits on sorting. Can you come up with a terminating algorithm that is most /pessimal/?"

Usually I get a blank stare. Sometimes I get a great answer.

<comment><USER28> I always like the "shaking box" algorithm:

1\. Check if list ordered. If it is, we're done!

2\. Randomize order of list. Go back to step 1.

N!

<comment><USER15> Worst case O(\inf), it's known as 'random sort' or 'bogosort'.

Funny thing, it can theoretically be O(1) on quantum computers, assuming the multiple-universe interpretation of quantum mechanics: <http://en.wikipedia.org/wiki/Bogosort#Quantum_bogosort> ;).

<comment><USER29> Is randomizing a list of n entities once is an O(n) operation. not sure how it would be done in O(1) on quantum computers.

<comment><USER15> The link that Dove gave suggests there's an idea of quantum randomization that will split our universe into n! universes in constant time.

</comment></comment></comment></comment></comment><comment><USER30> What's interesting is that in theory, assuming an appropriate scaling factor to divide the input by, the time and space complexity for Sleep sort are O(1). This is basically like hashing numbers, then iterating the buckets -- except that the iteration is done over time. Given that, one could envision degenerative cases for which Sleep sort could in theory outperform a standard algorithms like quicksort.

</comment><comment><USER31> Interesting idea I hadn't seen before. It's basically bucket sort, but using the scheduler to hold the bins.

<comment><USER31> Correcting myself: while that's what I think of it conceptually (everything is placed into integer-valued "bins" via the integer parameter taken by sleep()), implementation-wise it's probably equivalent to heapsort or something similar, depending on whether the scheduler stores sleeping threads in a heap or some other data structure.

</comment></comment><comment><USER32> Optimize it by making the sleep time be log(x) instead of x or a fraction of x. That makes it O(log n) complexity :). Use any monotone increasing function really.

</comment><comment><USER33> Of course it's brilliant, it just delegates the sorting to the scheduler. The OP on 4chan is ready for a PHB position at a large corporation.

</comment><comment><USER34> Hilarious, though not strictly correct. There is no guarantee 'sleep n' sleeps for n seconds, or that 'sleep n' wakes up before 'sleep n+1'. Granted, in reality if scheduling is so far off that things like this on the order of seconds become a problem, you've probably got bigger problems...

</comment><comment><USER35> Guys, isn't this just another sorting problem? Aren't you just relying on the thread scheduler to sort them?

</comment><comment><USER20> Are those of you whom are saying there is _anything at all_ good or usable about this approach just trolling? _Pleaaase_ just be trolling, if my opinion of humanity goes any lower I'll have to start building a 'compound'.

<comment><USER36> Note to future historians: In the age before commercialized internet access humans found humor in _absurdism_ , _irony_ , _satire_ and sometimes even _sarcasm_. Today these forms are no longer considered humorous but malicious and offensive, and are now classified under the blanket term _trolling_.

<comment><USER37> Yikes, I guess you got me. I didn't realize that attempting to piss someone off anonymously for your own amusement was _satire_. Your ideas intrigue me and I am interested in subscribing to your newsletter.

<comment><USER36> I was hoping you'd see the irony in my reply. I didn't mean any offense. (Thanks for illustrating my point though.)

</comment></comment></comment></comment><comment><USER38> I think the more interesting solutions are deeper in the thread mainly #43, #44, #83.

Mostly just for fun but its neat to see an Erlang solution since this should be right up its alley.

<comment><USER39> Please share for the net-nannied among us.

<comment><USER40> javascript version for you:

       var numbers  = process.argv.slice(2)
         , output   = []
         , negative = []

       for (var i=0, ln=numbers.length; i<ln; i++){
          var n = +numbers[i]
          setTimeout((function(n){ return function(){
             if (n<0) negative.unshift(n)
             else output.push(n)
             if (output.length + negative.length === numbers.length) {
                return console.log(negative.concat(output))
             }
          }})(n), Math.abs(n)/1000)
       }

Works with negative numbers.

        $ node sleepsort -2 1 0.1 4 -1 7 -3 9
        [ -3, -2, -1, 0.1, 1, 4, 7, 9 ]

<comment><USER41> your code can be simplified a bit:

        function sleep_sort (inputs) {
          function child (number) {
            setTimeout(function () {console.log(number)}, Math.pow(2,number))
          }

          for (var i = 0; i < inputs.length; ++i)
            child(inputs[i])
        }

        sleep_sort(process.argv.slice(2));

<comment><USER40> That won't work for numbers < -5 and has a much longer worst case.

</comment></comment></comment></comment></comment><comment><USER42> Python version: <http://code.activestate.com/recipes/577756-sleepsort/>

</comment><comment><USER43> I don't think this is meant to be serious.

Maybe on a quantum computer...

</comment><comment><USER44> Wow, 4chan on HN frontpage is a milestone. I recall reading somewhere 4chan (among few other sites) articles are auto-flagged when submitted.

</comment><comment><USER45> It's a joke, guys.

<comment><USER46> Too bad it's not a funny one

</comment></comment><comment><USER7> Wow. An order 0 sorting algorithm (it is O(0) not O(n) because it doesn't make _any_ comparisons). Amazing.

<comment><USER47> Just because a sorting algorithm doesn't use any comparisons doesn't make it O(0).

For example Radix Sort (<http://en.wikipedia.org/wiki/Radix_sort>) is not a comparison based sort and its complexity is O(k.n) where k is the max size of elements.

</comment></comment><comment><USER29> I dont think this sort is dependable for sorting floats in close ranges. I tried it with, ./sleepsort.bash 1 1.01 1.01 1.02

and output was

1

1.01

1.02

1.01

Clever hack, nonetheless.

</comment><comment><USER48> my first reaction was it's going to be O(9^n) worst case - but there is & after f "$1" which spawns its own process for each number. Not bad - maybe its a good algo if all are single digits

<comment><USER49> Of course, the proper algorithm, when all are single digits, is to use an array [10]int.

</comment></comment><comment><USER50> Sorry, can't open the link here (blocked). May anyone please give a cached version? (or even a link to a full page screenshot, a la 4chan). \- Thanks

</comment><comment><USER51> Do you see the hidden narrative?</comment>


How does the cleverbot work? - <AUTHOR>

Does anyone know how does Cleverbot work? If you have not, try talking to him on cleverbot.com It is amazing! It may not pass for human most of the time, but it is quite humanlike and entertaining as it is.
It got me interested in how those things work, but unfortunately it's source code is not available.
So how does it work? <comment><USER2> its horrible....i asked. "watsup?" it said. "in science"

<comment><AUTHOR> It fails sometimes, but it can produce very humanlike conversations too. There is a whole thread of conversations with cleverbot on reddit : <http://www.reddit.com/r/cleverbot></comment></comment>