SwiftUI - <AUTHOR> https://developer.apple.com/xcode/swiftui/ <comment><USER2> I'm one of the engineers that spearheaded this initiative inside of Apple. I just wanted to thank the HN community—I've been reading HN for 10 years now and it's been formative in my development as a software engineer.

If you're at WWDC stop by the labs and say hi!

<comment><USER3> I just wanted to say thank you - I'm a web developer who has been learning iOS dev in his spare time and made the decision pretty early on to build my views programmatically.

It seemed crazy and old school to me to have the UI stuff that IB generates stored in XML - I definitely thought it should generate the same code that you would write to do it programmatically.

Also, the code for building UIs programmatically has been so unnecessarily complicated. Like building a collection view with all the functions needed and boilerplate code compared to the few lines we saw in the demo.

This seems so simple and declarative. It makes me feel a lot better about my future as an app developer. Thanks again!

<comment><USER4> > It seemed crazy and old school to me to have the UI stuff that IB generates > stored in XML - I definitely thought it should generate the same code that > you would write to do it programmatically.

Most good ideas are old school. Data is more powerful than code because it can be analyzed in more ways - for instance, you can extract all the UI and text from an app, localize and re-insert it, then verify the UI won't break, all without having to execute the app.

If it's all in code you may not be able to get to some of the views or even know it's there. This is called the rule of least power - an example of getting it wrong is C++ iostreams.

Of course I'm sure SwiftUI has solved this.

<comment><USER5> Bullshit, any language with a macro system can do this. LISPs in particular are known for being code and data at the same time and this idea is way more old school than XML. You could also make a DSL that builds something like an AST of your UI in a similar fashion to free monads.

It's no surprise that XML seemed more attractive when your alternatives were Java or, even worse, Objective C. But really both options are absolutely terrible.

Thankfully we are very slowly making some steps forward again with Swift.

<comment><USER4> But we don't want the data and code to be the same, we want the data to be less dynamic than the code. You can't find out what the UI of a Lisp program would be without executing the program. It has everything available all the time, which is bad and turns you into a Lisp weenie.

SwiftUI is using new Swift features sort of similar to Haskell's "do" notation, which isn't actually itself monads.

</comment></comment></comment></comment></comment><comment><USER6> Lots of engineers are suggesting that SwiftUI, plus other declarative frameworks, might be "the future" of app development. However, I can't help but feel that this paradigm would work best when your app is a fairly basic CRUD thing. If you're working with highly interactive interfaces, complex animations, or dense, layered documents (DAWs, video editors), it seems that you would _need_ explicit state and imperative code at the center of it all, and that a declarative approach would require hacks and workarounds at every turn. In my humble opinion, some of the most interesting, ground-breaking, and creative software has these properties; whereas this reactive stuff seems tailored to bog-standard utility software.

However: I've never used React or any of its derivatives, so this is mostly inference. Is this take accurate or not? In theory, could you scale SwiftUI to build something like Logic, Blender, or Photoshop (for example)?

Also, have any declarative UI frameworks been released that feature a "platform" layer, where you get to define how your declarative code actually turns into UI, widgets, and behaviors? It seems that SwiftUI relies on (encoded) assumptions of what an ideal UIKit or AppKit app is supposed to look and feel like, and it would be really powerful if we could mess with this foundation or even swap it out entirely.

(It's very possible I'm mixing up reactive/declarative/reactive-UI concepts since I'm not too familiar with the territory.)

<comment><USER7> "However, I can't help but feel that this paradigm would work best when your app is a fairly basic CRUD thing"

Honestly, this is something I've been struggling with coming to terms to for a while.

Really, what mobile app _isn 't_ just a CRUD thing? Literally every 3rd party app I can think of on my phone talks to some REST service in some way. Even the video games, photo editors, notes apps, etc. They all use the cloud where the cloud contains most of the business logic and the app is a thin visual client proxying the data.

You could argue that, for example, a first person shooter is not CRUD heavy. But after the match, when you're looking at leaderboards or sending friend requests or chatting with your friends in the lobby...guess where that UI is updating from?

Yep, another CRUD API. It's everywhere. I really want someone to prove me wrong because I want to expand my horizons - what the hell isn't a CRUD thing these days, other than completely offline apps?

<comment><USER8> I feel like CRUD can be a simplistic categorisation at times. Take a look at the Slack app, for example. It's got chat messages. Also rich media. And threading. And user profiles. And notifications. But each of those is "just" CRUD. That doesn't mean it's a walk in the park. By broad definition just about every piece of software ever created is CRUD.

</comment></comment></comment><comment><AUTHOR> Personally, as an iOS developer, this is by far the biggest announcement.

Haven't had the chance to dig deeper, but the comparison between the UITableViewController and that snippet containing just declarative code looks absolutely promising.

The only downside is that we'll have to wait one or two years before we can use it if older iOS versions still need to be supported. Let's hope for extra quick adoption of iOS 13.

<comment><USER9> Unfortunately, iOS 13 drops support for iPhone 5s and iPhone 6.[1] Last year, iOS 12 didn't drop support for any devices. The iPhone 6 is a very popular device, and was still sold by Apple less than two years ago.

[1]: [https://iosref.com/ios/](https://iosref.com/ios/)

<comment><USER10> I smell a low-cost iPhone offering late Summer.

<comment><USER9> Frankly I think they'll just keep selling iPhone 8 for another year but drop the price down by $50 or so to $549. Or maybe if we're lucky $499. Either way they won't release a serious budget phone like the iPhone SE for $399 like they did in 2016. That year, Apple's flagship phone was $649. This year the flagship is $999.

</comment></comment></comment></comment><comment><USER11> I've been working on a very similar framework[1], but wasn't satisfied with the ergonomics enough to release it.

My plans were to extend the Swift compiler with JSX-like syntax[2] that makes use of the declarative framework. Of course that's still possible, especially now with a canonical "Apple" way of building declarative interfaces in Swift.

I'm a bit sad that with the announcement of SwiftUI my implementation will not stand a chance anymore, but I definitely learned a lot along the way how declarative rendering and reconcilation works in detail.

Bottom line - this is very great news for native app development, declarative UI makes it vastly more easy to reason about code.

[1] [https://github.com/PabloSichert/Sx/blob/master/Example/Incre...](https://github.com/PabloSichert/Sx/blob/master/Example/Incrementer.swift)

[2] [https://facebook.github.io/jsx/](https://facebook.github.io/jsx/)

</comment><comment><USER12> This is fantastic, and I am almost upset by how little info the keynote address included. Obviously there will be a ton of detail coming out this week with the labs and documentation being released, looking forward to that.

As an iOS developer, this is by _far_ the biggest announcement. This has huge potential to provide value to me and my team. I'm looking forward to ripping out programmatic NSLayoutConstraint and Interface Builder from my projects ASAP. This seems like it includes much more than that, however.

<comment><USER13> The "real" developer keynote is "Platforms State of the Union" which will surely cover a lot more of it. The morning keynote is for the press and executives to highlight latest releases with some dev stuff thrown in.

<comment><USER14> Yeah, it's similar to I/O where there's a separate developer keynote, and specific "State of the Union" talks for each platform/framework.

</comment></comment></comment><comment><USER8> I'd be curious to know how many React Native devs work on cross-platform apps. In casual conversation I've had it actually isn't that high, despite it being one of the central promises of RN.

Given that SwiftUI has live reloading and a sensible template interface I could absolutely see it winning over some RN devs. There's something to be said (particularly with Apple) for using the native toolset rather than RN, Flutter and the like.

<comment><USER15> > In casual conversation I've had it actually isn't that high, despite it > being one of the central promises of RN.

But applications written in React Native aren't cross platform, are they? You have different components depending on the platform. My understanding is that they claimed you wouldn't have to learn a different framework when switching to a new platform, not that your apps would be portable.

<comment><USER16> Applications written in React Native typically _are_ cross-platform; saying that they are not is a pretty large misrepresentation of the framework.

At its base React Native provides a common set of native components with the same API on both iOS and Android such as View, Image & Text which can all be styled and laid out through common APIs. These APIs pretty much give you most of what you need to make an entire APP. Sometimes you may want to have different behavior per platfrom and for that you can use the Platform API (provided by React Native) to switch for each platform. This would allow you to do things like change the styling on each platform or the native components you use.

React Native makes it pretty easy to expose native components to JavaScript. It is also up to the native component author if they want to create a common API for all platforms that they support. In the case of Views & styling it makes a lot of sense to have the same API on iOS and Android, but sometimes they are some platform features that are only available on one platform.

Wile Swift Layout is not cross-platform, it may soon be and I think it does a lot for promoting declarative UI & maybe they did take some inspiration from React!

View docs: [https://facebook.github.io/react- native/docs/view.html](https://facebook.github.io/react-native/docs/view.html) Styling: [https://facebook.github.io/react- native/docs/style](https://facebook.github.io/react-native/docs/style) Layout: [https://facebook.github.io/react- native/docs/flexbox](https://facebook.github.io/react-native/docs/flexbox)

<comment><USER17> Maybe we need to coin a new term.

React Native is for cross-platform. SwiftUI is for cross-device.

Does that work?

<comment><USER18> Cross-ecosystem vs. cross-platform maybe.

</comment></comment></comment></comment></comment><comment><USER19> I'm sure SwiftUI has been in development for a long time, but it seems to me to be Apple's response to frameworks like React Native and Electron.

We get a simple way to make UIs for multiple platforms, we get a nice batteries-included language, and Swift 5.1's dynamic method offers a similar functionality to hot reloading.

Of course, it can't answer everybody's needs (no Windows, Linux, or Android support) but combine SwiftUI with Project Catalyst, and I'm really hoping to see plenty of high-quality cross-platform apps that don't have a whole instance of Chrome underlying them.

<comment><USER20> >Of course, it can't answer everybody's needs (no Windows, Linux, or Android support)

I don't understand how my fellow developers could ever tolerate Apple doing this.

This goes one way, and its been like this for decades.

<comment><USER19> Because not all of your "fellow developers" have the same priorities as you.

For a lot of developers, targeting _just_ the Apple platforms is still a worthwhile investment in itself: Apple's customers tend to pay higher prices for quality Mac software — yes, outside the Mac App Store, too — and they will very often be happy to pay for the accompanying iOS app if it's worth doing so.

There have been Apple-only development houses since the year dot and this won't change just because Apple decided to release a platform to make it a little easier for its developers; they're not beholden to the rest of the world and it's ridiculous to believe so.

<comment><USER20> Given the high cost, high cost options exist on other platforms that are also fantastic.

So if everyone can spend 3,000 dollars and get best in class computing, what are you paying for with Apple?

They have lots of marketing that psychologically makes you feel good?

<comment><USER19> The notion that all of Apple's users are just fools for good PR is not one to which I bother to respond because I choose not to be called a pawn.

Treating other people like that is, to my mind, a shallow dismissal of an opinion you did not have the good patience to discover in the first place.

</comment></comment></comment></comment></comment><comment><USER21> To me this looks very similar to what Google is doing with Flutter.

<comment><USER22> Jetpack Composer you mean.

I bet by next IO, Flutter will get replaced by it, specially after the #KotlinEverywhere announcement and Kotlin/Native effort for iOS.

<comment><USER23> It looks like Jetpack Compose is not really done yet. It's pre-alpha and the Jetpack Compose doc page says don't use it for production. [https://developer.android.com/jetpack/compose/](https://developer.android.com/jetpack/compose/)

I may be missing something, but SwiftUI seems to be pretty much ready to go today.

<comment><USER24> Ready to go today if you're only supporting iOS 13+

Which for most companies is 2+ years away

<comment><USER23> To add a bit more detail: the required level for other Apple OSs are macOS 15+, tvOS 13+ and watchOS 6+.

</comment></comment></comment></comment></comment><comment><USER25> I'm laughing at all the handwringing over Marzipan in the lead-up to this year's WWDC.

The future of MacOS development is not Marzipan and never was. The future is SwiftUI.

<comment><USER26> SwiftUI running through Catalyst, surely?

<comment><USER25> SwiftUI isn't confined to Catalyst. It's available to native Mac AppKit apps as well as UIKit apps.

(At least it appears that way, going by the WWDC session descriptions. We'll know more in a couple of hours)

<comment><USER26> Yeah, or once I can finish unarchiving Xcode…

</comment></comment></comment></comment><comment><USER27> Thank you so much for this. I was learning iOS again for the fourth time. This time is different. I learned about programmatic UI from Brian LBTA guy which has been so much easier than IB. Now this update just makes my learning iOS a whole lot easier for me. I'm so thrilled. Thank you thank you thank you Apple!!!!!!!!

<comment><USER27> Why am I being downvoted simply for being happy about this update and that it brings down the learning curve for other engineers?

<comment><USER28> Unfortunately, many geek forums accept cynicism, negativity, sarcasm and snark, and downvote a happy post, usually with some excuse like "doesn't contribute to the discussion".

</comment></comment></comment><comment><USER29> This reminds me Visual Studio back in 2001 when I discovered programming. Everything was so easy to prototype. I'm so happy to see Apple is taking this direction. Thank you guys!

<comment><USER30> I assume you mean Visual Basic, since Visual Studio was geared towards C/C++. Unless you actually used the MFC designer in VS5/6, which never really worked that well for me.

<comment><USER29> Actually I had VB6 in mind yes, but after a few months playing with it I made the switch to .NET (which was still in beta I believe at the time) so I was using Visual Studio ".NET" :)

</comment></comment></comment><comment><USER31> Reminds me a bit of QML, though less declarative. Qt creator also has some pretty good IDE support.

</comment><comment><USER32> This is definitely an overly ambitious project idea, but now that Google has Jetpack Compose and Apple has SwiftUI, and the web has React, I wonder if it would be possible to make a "meta-framework" that uses a single code-base to compile user written code into source code written in those 3 frameworks respectively.

Then you would get truly native, cross-platform development.

Now, the probability this would ever work is 1%, but it's something that has lingered in my mind anyway.

<comment><USER33> _> I wonder if it would be possible to make a "meta-framework" that uses a single code-base to compile user written code into source code written in those 3 frameworks respectively._

Flutter targets native code on Android and iOS and JavaScript for the web. It has very mature compilers for all three.

</comment></comment><comment><USER34> I was waiting for Apple to react to Flutter. It was a threat. They couldn't bluntly forbid Flutter apps. Now it seems this is their answer.

Soon you'll be able to compile SwiftUI to Flutter and reach all platforms it reaches. Their play: to get the best experience, you'd still need to buy an iPhone.

<comment><USER35> Who said anything about compiling SwiftUI to Flutter?

</comment></comment><comment><USER36> there were lots of Swift holdouts. In fact, there has been a resurgence of Objective C

Objective C is much higher than Swift: 11 vs 18.

[https://www.tiobe.com/tiobe-index/](https://www.tiobe.com/tiobe-index/)

This should reverse the rankings and might push Swift into a top 10 language.

<comment><USER37> > Objective C is much higher than Swift: 11 vs 18.

And Apache Groovy rose from number 91 to number 17 in the past 12 months also according to that same Tiobe page (May 2019). Quoting Tiobe for anything only discredits what you're trying to prove.

</comment></comment><comment><USER38> Do the trailing closures implicitly return arrays of child elements? Or what kind of syntax is that?

<comment><USER26> Single-expression functions can now return a value without the "return" keyword: [https://github.com/apple/swift- evolution/blob/master/proposa...](https://github.com/apple/swift- evolution/blob/master/proposals/0255-omit-return.md)

<comment><USER38> Yeah but the example code looks like multiple expressions?

<comment><USER26> Those might be functions that alter context of the closure rather than being returned. Or it might be some Swift compiler magic?

<comment><USER38> So far I found out it's implemented via parameter attribute [1]

[1]: [https://developer.apple.com/documentation/swiftui/viewbuilde...](https://developer.apple.com/documentation/swiftui/viewbuilder)

<comment><USER38> More details in the proposal [1]:

> the basic idea is that we take the "ignored" expression results of a block > of statements — including in nested positions like the bodies of if and > switch statements — and build them into a single result value that becomes > the return value of the current function.

[1]: [https://forums.swift.org/t/pitch-function- builders/25167](https://forums.swift.org/t/pitch-function-builders/25167)

</comment></comment></comment></comment></comment></comment><comment><USER39> Looks a lot like Flutter

</comment><comment><USER40> Interesting move we see from the big players to more declarative UI toolkits. First Flutter, now this.

<comment><USER41> You have to give credit to react time which seems that started this paradigm of declarative _and_ reactive ui frameworks. After that you got react native, flutter, jetpack compose and now swift ui. As for declarative (but not reactive) ui prior art is also Qt qml.

<comment><USER42> Also have a look at [https://fsprojects.github.io/Fabulous/](https://fsprojects.github.io/Fabulous/)

</comment></comment></comment><comment><USER43> I hope it still supports low-level control when you need it.

<comment><USER44> Yeah, I have the same concern. This is great for those situations where declarative works but sometimes you really want to get low-level and do some custom stuff with imperative code. I suppose we can use the old frameworks for that?

</comment></comment><comment><USER45> Does the syntax sort of kind of remind anyone else of Shoes?[1]

[http://shoesrb.com/](http://shoesrb.com/)

<comment><USER46> Yes, I wonder what framework Apple engineers looked at for inspiration, and if they looked at shoes. Although I doubt they are allowed to answer this question.

<comment><USER47> Here's one comment about inspiration:

[https://twitter.com/jckarter/status/1135666944273571840](https://twitter.com/jckarter/status/1135666944273571840)

</comment></comment></comment><comment><USER48> The syntax example is still not as clean as QML, which is already a ten-year- old language (examples: [http://qmlbook.github.io/ch04-qmlstart/qmlstart.html](http://qmlbook.github.io/ch04-qmlstart/qmlstart.html)).

<comment><USER8> But it is Swift, which (at the risk of stating the obvious) QML is not. And you can't write an entire app in QML.

There's something to be said for being able to use one language for all things.

<comment><USER49> Well, you can almost surely write entire apps in QML if you take the C++ entrypoint for granted.

Just a couple examples: you can do Bluetooth discovery scans in QML without writing any C++ [1], you can read from ~20 sensors without writing any C++ [2], you can write complete 3D scenes declaratively in QML [3], and the list goes on.

[1] [https://doc.qt.io/qt-5/qml-qtbluetooth- bluetoothdiscoverymod...](https://doc.qt.io/qt-5/qml-qtbluetooth- bluetoothdiscoverymodel.html)

[2] [https://doc.qt.io/qt-5/qtsensors- qmlmodule.html](https://doc.qt.io/qt-5/qtsensors-qmlmodule.html)

[3] [https://doc.qt.io/qt-5/qt3d-wireframe- example.html](https://doc.qt.io/qt-5/qt3d-wireframe-example.html)

</comment></comment></comment><comment><USER50> Now, will someone be a sweetheart and write a transpiler that will transpile AndroidXML to SwiftyUI and SwiftyUI to AndroidXML. Also, while you're at it, please write a transpiler for Flutter to SwiftyUI and SwiftyUI to Flutter. K. Thx.

</comment><comment><USER51> One more blow to the head for objective-c. Wonder if this the final nail in the coffin.

<comment><USER52> Given that Craig Federighi basically said this type of migration only comes around every 20 years, I would imagine Objective-C is dead. I do hope they actually take the time and fix the Swift examples so they are updated.

This does hurt. I've been programming Objective-C since NeXTSTEP and love it. Swift is still like Perl for me. Something I will use for programming for money, but not enjoy for one minute. I loved the clarity of selector syntax, but Javascript clones rule the world. I still don't understand the love of commas or why they are needed.

<comment><USER53> How is swift a javascript clone?

Objective c is insanely verbose.

<comment><USER52> _How is swift a javascript clone?_

They ditched the selector syntax and went to a Javascript / C++ like syntax. There were so many ways to keep the selector syntax, but they went conformist.

 _Objective c is insanely verbose._

well, no - Swift's call syntax actually results in the same or more characters:

      somePoint.moveBy(x: 2.0, y: 3.0)

      [somePoint moveByX: 2.0 y: 3.0];

      somePoint.moveBy(x: 2.0, y: 3.0, z: 4.0)

      [somePoint moveByX: 2.0 y: 3.0 z: 4.0];

Swift benefited from some shortening of the method names that can be equally applied to Objective-C. Plus, why the whole split by a left parentheses and comma thing?

</comment></comment></comment></comment><comment><USER54> So React.js but native and in Swift? I'm hesitant but hopeful.

Tutorial: [https://developer.apple.com/tutorials/swiftui/](https://developer.apple.com/tutorials/swiftui/)

</comment><comment><USER55> I didn't catch it. Is Xcode 11 (beta) available already? Do I need macOS Catalina (beta) to run it? I seem to have missed the crucial information and cannot find it on apples developers pages...

<comment><USER56> The direct download is here:

[https://developer.apple.com/services- account/download?path=/...](https://developer.apple.com/services- account/download?path=/WWDC_2019/Xcode_11_Beta/Xcode_11_Beta.xip)

for some reason my account only shows "There's currently no beta software available for download."

<comment><USER57> [https://xcodereleases.com](https://xcodereleases.com)

Best-kept secret with direct download links (from apple.com)

</comment></comment></comment><comment><USER58>
      var body: some View {

Wait, what? When was `some` a keyword?

<comment><USER59> I am still scratching my head why the 'some' keyword is needed/required for opaque types.

Eg. SquareButton and RoundButton are implementations of the Button (protocol).

You want to create a function that returns the button, but you don't want to specify to the user exactly what type of button is it (as it doesn't matter). Your function could just declare the top level protocol as the return type without needed to specify the word "some"

createPlayButton -> Button

instead of createPlayButton -> some Button

Am I missing something? It feels like the 'some' keyword is just there to help the compiler and not the users necessary

it seems like the equivalent of id <MyProtocol> in Objective-C. Basically just a surface re-arranging of names, but keeping the same concepts as in Objective-C

I feel Golang did better in this regards... (eg. not necessary distinguishing between protocols and super class-es, it is quacks like a duck, it is a duck)

<comment><USER43> The difference is subtle but it's there.

The "some" keyword indicates that the function returns a specific type, even if that type isn't known to the caller.

One place where this is meaningful is if you have to _use_ the result of that function in a generic function. For instance if my functions are defined like this:

        func createPlayButton() -> Button { ... }

        func doSomething<T: Button>(_ button: T) { ... }

And I try to call this:

        doSomething(createPlayButton())

I will get an error, because the protocol Button does not conform to itself. However If I use opaque types:

        func createPlayButton() -> some Button { ... }

this works just fine because the compiler is able to determine the concrete type returned by `createPlayButton`

<comment><USER60> Why doesn't a protocol conform to itself?

<comment><USER43> In many cases it doesn't make sense. For instance, what if your protocol contains a static member?

        protocol P {
            static var x: Int { get }
        }

Here `let x = P.x` doesn't make any sense, because it's only the type implementing the protocol which has that member. However this would be possible:

        func f() -> some P { ... }
        let p = f()
        let x = type(of:p).x

because in this case p has a concrete type, we just don't know what it is.

</comment></comment></comment></comment></comment><comment><USER61> I'm wondering what this could mean for replacing React Native. Obviously SwiftUI is geared for Apple's platforms but overall it seems pretty high level and perhaps amenable to being adapted to Android by somebody. Swift is open source after all.

This would solve a problem a lot of devs have in deciding how to build a cross platform app. We don't want to give up first class support for each platform but it's silly to have completely separate codebases.

I hear even Apple has React Native dev groups.

</comment><comment><USER62> Can this retroactively support apps targeting iOS 12 and older?

<comment><USER63> The only devices you lose by supporting iOS 13 and not iOS 12 are the iPhone 5s from 2013 and the 6th generation iPod Touch from 2014.

iOS users update pretty rapidly.

<comment><USER26> iPhone 6 does not have an iOS 13 IPSW on the developer downloads site. iPad Air and the second and third generation iPad Mini were dropped as well.

<comment><USER63> Didn't realize that they dropped the 6 and 6 Plus.

</comment></comment></comment></comment><comment><USER64> .color(.gray))

What object is .gray acting on?

<comment><USER65> That'd be standard swift type inference. The .color function takes a single unnammed parameter of type Color (or similar, idk exactly). Color.gray is a static constant value. So .color(Color.gray) can be simplified to .color(.gray)

<comment><USER66> Huh, that's actually a great way to do type inference. Swift seems like an excellent language.

</comment></comment></comment><comment><USER67> For more information, there's a much more in-depth demo in the "Platforms State of the Union" session, which is now posted at [https://developer.apple.com/videos/play/wwdc2019/103/](https://developer.apple.com/videos/play/wwdc2019/103/)

</comment><comment><USER68> Where does this leave View Controllers? Is this available for those too? How does composition of multiple custom views work?

</comment><comment><USER69> This is exactly what we did with Creo a couple of years ago: design, preview and development in a single tool. We rewritten UIKit from scratch in order to be able to preview iOS code on MacOS. Looks like we did it right. [https://creolabs.com](https://creolabs.com)

</comment><comment><USER70> It doesn't matter that it looks like flutter. It matters that flutter will be able take advantage of it.

<comment><USER26> Flutter draws its own controls, so no, it cannot take advantage of SwiftUI.

</comment></comment><comment><USER71> It reminded me of Scaloid [https://github.com/pocorall/scaloid](https://github.com/pocorall/scaloid)

</comment><comment><USER72> Thinking about starting a new project over the summer. But seeing the demos it seems just starting something in UIKit now is a bad idea?

</comment><comment><USER73> So it look like react but it doesn't seems to be immediate mode GUI, still retained ? The body is a property not a function.

<comment><USER74> That's a "computed property," ie. a getter method pretending to be an instance variable.

</comment></comment><comment><USER75> Something like this available in C++ would be so great for cross platform applications!

<comment><USER76> There is Boden (native apps from a single C++17 codebase)

[https://www.boden.io/](https://www.boden.io/)

<comment><USER75> As far as I understand Boden is still a work in progress, far from being ready for prime time.

</comment></comment></comment><comment><USER77> fmr founder of Pagedraw here... this looks amazing. I wish we'd built it! :)

</comment><comment><USER78> Looks nice like Flutter.

</comment><comment><USER79> Am I the only one thinking "SwiftUI compile to WASM"?

</comment><comment><USER80> First-call declarative UI support is amazing!

</comment><comment><USER81> Will there be a similar API for Objective-C?

</comment><comment><USER82> OMG, has anyone noticed the device icons on the bottom of the SwiftUI page? Steve will be turning in his grave...

</comment><comment><USER83> The question the whole web asks now: what does this mean for React Native devs

<comment><USER84> I bet it's going to stay relatively the same, for now. React Native still works across iOS and Android, which is one of the key features. SwiftUI is iOS only.

<comment><USER83> It's my understanding that a lot of the appeal of RN is also that it allows web devs who are fluent in JS to make mobile apps, so I guess that's not really comparable in SwiftUI either.

<comment><USER85> I'm not sure about that. SwiftUI code looks an awful lot like React code. And IMO (as a web dev), it was always learning the UI framework that seemed like it would be the difficult part of learning iOS dev. Data manipulation APIs are pretty similar in most languages, but learning a new UI paradigm is a pain...

<comment><USER86> Yes, but alongside learning SwiftUI they will also have to learn whatever is going on in Android land because it's not cross platform.

</comment></comment></comment></comment></comment><comment><USER87> > across all Apple platforms

</comment><comment><USER88> It's nice to finally see a FRP framework for iOS like React/Elm. MVC must die already.

<comment><USER66> FRP and MVC seem like different types of patterns to me. Functional reactive is about how you manage state and flow while MVC is largely about separation of concerns. In my (possibly poor) understanding, you could actually use them together.

I'm interested in your take on that though. I'm self taught and I've got some weird ideas about things.

</comment></comment><comment><USER89> It smells a little like dart UI as code(flutterish may i say)

</comment><comment><USER24> So frustrating this wont be usable for most apps for at least 2 years.

Meanwhile Android, which yeah only 5% of users or something crazy small are on the latest version, will get to use the latest libraries on versions released 5+ years ago.

</comment><comment><USER90> I was fully expecting something along the lines of "Oh, and SwiftUI will compile to WebAssembly allowing your apps to look just as awesome and run just as fast in Safari."

Probably still in alpha...

<comment><USER26> Why would Apple want these apps to run in Safari? They have a platform to run these already.

<comment><USER90> Safari isn't the point -- running on other platforms is. Market share for iOS globally is nowhere close to Android; in India iOS is only about 10% so if your SwiftUI app could run in Chrome on Android and is installable as a PWA, you open up the rest of the handset market.

<comment><USER26> Apple doesn't really care about you being able to run your UI code on those platforms.

<comment><USER91> True. in fact they have a vested interest in not making this happen, but someone will. This looks really impressive and i've grown to like swift quite a bit.

</comment></comment></comment></comment></comment><comment><USER92> Ahhh, I don't get it. XCode already does all of this, and has done for very many years. Y'all are excited because you can see the code?

</comment><comment><USER93> Other than a few-hour intro seminar on building iOS apps, almost 10 years ago, I've never written anything in Swift. The announcements around it today got the biggest reactions from the crowd. Is is really great, blasé, or too early to tell?

<comment><USER94> You were not using Swift 10 years ago, or even almost 10 years ago. It was released in 2014.

<comment><USER93> Ah, now I see the reason for the downvotes. I just meant "Apple's language for doing iPhone apps," and, of course, that was Obj-C back then. I haven't thought about it since.

</comment></comment></comment><comment><USER95> Apple developers will be glad they get to rewrite their entire application with a new UI framework and paradigm or risk their apps looking garbage on the platform (and stop working by next release). This must be the .. fifth entirely new UI framework from Apple?

<comment><USER96> This isn't true at all. Since iOS launched there has been UIKit and then this SwiftUI.

<comment> grey-area _This must be the .. fifth entirely new UI framework from Apple?_

 _This isn 't true at all. Since iOS launched there has been UIKit and then this SwiftUI._

They didn't say anything about iOS. There have been lots of UI frameworks from Apple, some abandoned before they were even finished:

QuickDraw, Quickdraw GX, HIToolbox, AppKit, Cocoa Touch/UIKit, Playgrounds/IB, SwiftUI

The constantly changing frameworks and languages are a useful strategy from platform vendors - they _do_ help provide platform lockin, and make it very very difficult to provide cross platform apps. That is a real threat to Apple with offerings like flutter from Google. Of course there are other reasons to make a clean break with the past, but there is a lot of work just to stand still in developing for a platform like Mac OS or IOS - they don't highly value backwards compatibility and often introduce sweeping changes. Constant change is in the platform vendor's financial interest, and I don't think it's unfair to point that out.

Just to take one example - apps built for the original iOS are now almost entirely obsolete, and it's not worth reusing any of their code in a modern swift app.

<comment><USER97> QuickDraw and Quickdraw GX aren't UI frameworks (like PowerPlant, AppKit or UIKit), and they aren't a widget library (like HIToolbox). They're much more lower-level than that; drawing libraries on the level of Quartz, Cairo, Skia, or GDI.

<comment> grey-area Ooh, that mention of PowerPlant that takes me back, I remember CodeWarrior too back in the day.

Yes you're right there are various levels here - sometimes it's hard to distinguish them. There have definitely been at least 5 UI toolkits though, and probably more, though of course over the life of Mac OS that is not terribly unexpected. For those who lived through the transition to OS X, this sort of churn is not unusual, and I do think it does benefit platform vendors - they have zero incentive to keep supporting their technologies over decades and every incentive to increase churn.

Quickdraw GX I remember particularly because there was such fan-fair about it as a replacement for all your graphical needs (such as drawing text), and yet it was dropped before it could even really be used (same with Quickdraw 3D). I can't remember what apple called their UI toolkit at the time, which was based on Quickdraw, then GX, but I don't think it was Carbon, that came later didn't it? I think I've found it now, was it MacApp?

<comment><USER98> MacApp was a framework that ran on top of HIToolkit, similar to PowerPlant. Originally it was written for Object Pascal, but later it moved to C++.</comment></comment></comment></comment></comment></comment>


Privacy Inequality: The Most Brutal Form of Inequality You've Ever Imagined - <AUTHOR> https://medium.com/privateid-blog/privacy-inequality-the-most-brutal-form-of-inequality-youve-ever-imagined-e674d4f3cd42 <comment><USER2> I'd say actual human slavery - which I can easily imagine from extensive historical records - is probably worse.

Yeah, mysterious data centers logging everything you do is scary, but have you ever been beaten bloody because you lacked the physical ability to pick the required cotton quota? Whoever wrote this title needs a serious dose of perspective. And to rewrite the title.

<comment><USER3> One can argue deprivarion of privacy for the powerless masses can lead to a society so hopelessly controlled and manipulated by the elite class that return of slavery with an even worse level of brutality suddenly becomes a practical possibility.

Slavery as you portrayed it went away but people who possess the desire to see it back in place are still alive and well.

I don't mean lack of democracy but lack of ability for the masses to have their voice heard or will respected

<comment><USER4> What you're talking about is not slavery. It might be loosely termed "institutional oppression". Basically, an oligarchic dictatorship.

Money and information are used to coerce your conformity and obedience. _BUT_ , a person can _legally_ opt out and just live with nothing.

Slavery is when brute physical _force_ is used to coerce conformity and obedience. A slave can _NEVER_ legally opt out. and the slave _ALWAYS_ lives with nothing, because he _IS_ property.

I'd imagine most humans would choose to live with being forced to behave in society to get money, and then going home, rather than to have to live with cradle to grave slavery. To equate them is just, kind of, being a little sensationalist.

<comment><USER3> No,i meant slavery as in 1800s whiplashing and lynching slavery.

Institutional oppression is what you think I meant,what i meant was a dystopian future where privacy erosion has lead to a world where your every move and intention is analyzed for conformity by the elite class. You can optin and opt out,elect leaders or overhtrow dictators because you can organize in groups,think and plan without your adversary knowing your every move.

If someone controls what information you consume and every reaction you have to a given scenario or information then they can control you to the point where even the brutal form of slavery can be thought of as acceptable.

<comment><USER4> But in your hypothetical future you can _still_ legally opt out, and live with nothing.

A slave can _never_ legally opt out and choose to live on his own with nothing.

You are saying that there exists a level of information control that would justify slavery in the minds of the masses. I'm saying there is no such level of information control. (In fact, it would never even be justified in the minds of all the elites.)

We just need to agree to disagree. But I really think you're doing a serious reach in order to make a connection from privacy to slavery. And the sensationalism around this issue is what is keeping the masses right now from taking it seriously. We need to be explaining _actual_ consequences to the masses, not shouting alarmist nonsense at them and then calling them stupid for not listening.

</comment></comment></comment></comment></comment><comment><USER4> The article paints a pretty bleak picture, but it's even worse when we consider that even the author has bought in to privacy destroying narratives and technologies. I mean, the guy just posted an article on privacy inequality on a site that requires a third party login to discuss said article??? Don't even get me started on his belief that Elon Musk and companies like Tesla will be bulwarks against privacy inequality???

Keep in mind, this is a guy who, at least, knows that privacy inequality _exists_. And even he is given to almost naturally accepting narratives and technologies that are a direct threat to equality in this regard. So if even guys like the author are able to be seamlessly integrated into the future system of asymmetric privacy we're creating, then there really isn't much hope for most of the world's population who are liable to be a good deal less thoughtful.

All that said, HN User slfnflctd is correct, privacy inequality is bad, but there are much worse causes of suffering for humanity. Slavery does spring immediately to mind. Rape, Genocides. Etc. Privacy inequality _might_ help to enable some of those things, but those things certainly exist with no help from privacy inequality at all.

<comment><AUTHOR> I can log in with my email on Medium... You just sign in, they send you an email confirmation, and you're in.

<comment><USER5> I guess the third party might be "A Medium Corporation"

</comment></comment></comment><comment><USER6> This took too long to get to the point. Even with aggressive skimming and a big interest in the subject I gave up

<comment><USER7> Indeed. Too much non-revant background before getting to the points, and even those were bloated. The most brutal form of inequality for this piece is concision. Not to mention the tone-deaf headline.

</comment></comment><comment><USER8> This is mostly a whiny article followed by an ad for the author's site which starts by wanting either your email or your money.

There are better advocates for stronger privacy. A good starting position is that the US needs something as strong as the EU's GDPR. With teeth. Might happen. See this Register article.[1]

We need a good event involving the privacy of some political official, preferably one on the right. The US got the Video Rental Privacy Act because Robert Bork's porno videotape rentals became public knowledge. Although that was weakened in 2013 due to Netflix lobbying.

[1] [https://www.theregister.co.uk/2018/11/08/gdpr_usa_congressma...](https://www.theregister.co.uk/2018/11/08/gdpr_usa_congressman/)

<comment><USER9> > The issue first surfaced during Bork`s confirmation hearings, when a > Washington newspaper published lists of the judge`s video rentals during the > last several years. The films were general releases such as ''Ruthless > People,'' ''The Man Who Knew Too Much'' and ''A Day at the Races''; there > were no X-rated rentals.

~Chicago Tribune, November 20, 1987 (source: [https://www.chicagotribune.com/news/ct- xpm-1987-11-20-870327...](https://www.chicagotribune.com/news/ct- xpm-1987-11-20-8703270590-story.html))

</comment></comment><comment> GuB-42 Privacy inequality exists, and it goes the other way, at least in the west. In practice, the richer and more famous you are, the less privacy you have.

If you are rich, you are a target for everyone who wants a part of your money, from criminals to opportunists. Stars have their paparazzis. And even in their inside world, the rich typically have many people working for them. If you don't drive by yourself, your chauffeur knows where you are going, your accountant knows how you spend your money, your cook knows when and what you are eating, etc...

It has serious consequences. It very famously killed Diana for instance.

And think about "the fappening", where celebrity nudes leaked out. It is not the king of things that happen to average girls. I know someone who "revenge porned" his ex girlfriend, it didn't go far. She is pretty but average, and no one took interest. That's what protected her privacy.

The author mentioned things like targeted ads, where only the rich can opt out. Sure, but if you aren't rich, where is the big deal. Advertisers aren't after the money you don't have. Maybe some company have a lot of details about your life, but no one will really care. OTOH, the rich and famous have actual people tracking them constantly. The fortunes they spend for their privacy and security only gets them what we naturally have just by being average.

It is interesting to note that in 1984, the ones who enjoy the most privacy are the proles, the lower class.

</comment><comment><USER10> When you're 40% through the piece and the author still hasn't gotten around to the point mentioned in the title, you've got yourself a badly written article.

Don't waste your time. Author should have incubated this thought more.

</comment><comment><USER11> The idea that you can pay for privacy is a fantasy.

Just like in every surveillance state in the past, the people with the most privacy will be the people who are in charge of the surveillance. The people who will be the most monitored are the people who individuals in the surveillance apparatus want something from, or are offended and annoyed by. The civilian government reports to the surveillance apparatus in a surveillance state, not the other way around; and you probably won't even know the name of the person who really runs the country.

If you can see everything that people do, you can destroy them at will. If you can't find anything they've done, you can figure out something they _could have done_ , and extortion easily provides eyewitnesses and covert agents in order to set people up. If necessary, you can extort necessary elements of the justice system to make the decisions you want, or just blatantly do what you want in total daylight, and make sure that nobody ever reports on it, no one is arrested, and witnesses are either securely threatened or disposed of in the same way.

It's depressing that we're arguing about whether public or private surveillance is worse, whether convenience or discounts are worth the exchange, or in this sadly gone awry "left" critique, whether there will be differences between the privacy of the rich and the poor.

Instead, maybe argue about why we've installed microphones every 10 feet that report to central servers in a way that cannot be audited. The technology is the enemy, it's just waiting for the right user.

</comment><comment><USER12> Is it just me, or is this terribly written?

<comment><USER13> Reads like an un-edited rambling blog post

Catchy title though.

<comment><USER14> Yes, absolutely horrible.

Are people upvoting this on title alone?

</comment></comment></comment><comment><USER15> hyperbole: our deadliest foible

</comment><comment><USER16> I can imagine much more brutal things.

</comment><comment><USER17> the irony of writing it in medium.com

</comment><comment><USER18> TL;DR - author watched too much sci-fi and decided to write his (bad) own dystopia with castes etc.

</comment><comment><USER19> Some highlights for people having a hard time reading the article:

"Simply put, your raw data is everything about you: your age, location, preferences, how tall you are, go down the list. But the tricky one is the predictability of your data. And what people when say that Facebook knows people better than they significant other (and themselves), is that they can predict what you're going to do before you, or your significant other, are aware of it. That's so powerful. When you get tons of data from a person and put the right algorithms to work, you can start getting interesting (or scary) results."

"Privacy becomes a human right in the moment someone or something invades your personal space (either physically or digitally) in order to extract monetary value from you. That's our value as human beings, and companies and governments steal that value from us. What do we do? We just give away because we've got no idea of our own value as human beings." (great point: it's extraction)

"There are so many things you can do with data. Today. But, what could be done tomorrow with that same data? If today we can predict the mental health of an individual through a voice recording, what will we be able to do with that same data five years from now?"

Employers and governments are either considering or already doing stuff like that in ways that will surely impact workers.

"Here's my prediction: At some point this situation will create two castes of people: The Protected and The Predictables... The Protected are the ones who can afford to pay for privacy. These group understand that their privacy is their very human value and want to protect it. However, The Predictables are the ones who can't pay for privacy. These are ones who live in a Matrix style algorithm. Maybe they know privacy should be a human right, but probably will fail to understand its value and the impact it has on them. The ones who have lots of opportunities and resources will be given more. And the ones with few opportunities and resources will be taken away, even more"

"...it's easy to see how this inequality is going to hit us: overpriced insurance, bank loans denial (or high interest), unaffordable healthcare, highly targeted advertising, political manipulation, and simple opportunity cost of opportunity."

"Because companies are too busy making money and we're too busy using their "free" stuff. So it's not surprising that they end up getting away with it. Consider Facebook. Since 2005 Facebook has been involved in all sorts of scandals, and every single time they get away with it. They masquerade their way out, telling one story to the investor and another to the public."

"Privacy inequality will take everything to the edges. Some kids will be lucky and might be able to afford privacy protection. Maybe that will be paying for products that watch their privacy or a kind of antivirus, who knows. But other kids won't be able to pay for it and will choose the "free" option — others just won't understand their value as human beings and will pick the free version, because it's a bargain, right? Alas, they will grow up with inequalities worse that the one I had at school, or any other you have had in your entire life."

"We seem to forget that for decades we've been fighting for freedom and equality. Now we're throwing it all away, and for what, free dumbass apps?"

</comment><comment><USER20> tl;dr, anybody? What makes privacy inequality so bad? And is the inequality the problem, or the lack of privacy? (A parallel question can often be asked of wealth inequality.)

<comment><USER20> Found a collection of such, albeit not necessarily specifically in response to this article:

[https://news.ycombinator.com/item?id=18829422](https://news.ycombinator.com/item?id=18829422)</comment></comment>


It's unconstitutional for cops to force phone unlocking, court rules - <AUTHOR> https://arstechnica.com/tech-policy/2020/06/indiana-supreme-court-its-unconstitutional-to-force-phone-unlocking/ <comment><USER2> Things in this case went wrong a lot earlier. What judge signed off on a warrant for this fishing expedition? The cops openly admitted they had no idea what they were looking for in that phone. They just wanted to look around and see if they find something incriminating.

That is NOT how search warrants are supposed to work. You are supposed to know exactly what you're looking for and where you intend to find it. You present that information to a judge to get the warrant. "We just want to rummage about" is not generally accepted.

<comment><USER3> 100%. I feel like this is an area where the technical literacy gap between generations has the potential to be incredibly damaging. If a judge's signature is blessing enough for police to take whatever action, and the judge has very little understanding of computers, there's quite a bit of leeway here for disaster.

<comment><USER4> It seems to me that technical literacy is irrelevant for this purpose -- even a judge who knows next to nothing about computers should be capable of thinking: search is search.

Unless they thought of computers/phones as equivalent to a garbage can, I don't see how the mistake would be made

</comment></comment></comment><comment><USER5> Neat. But this is hardly a settled issue. Each time it comes up, it seems the court flips a coin to decide the answer.

</comment><comment><USER6> What's shocking is that this even had to go to court in order for it to be recognized as a 4th Amendment issue (and 1st and 5th... and probably more).

<comment><USER7> This article is about the Fifth Amendment, and at least as the article describes them, the different situations and resulting precedents are more nuanced than your comment seems to imply.</comment></comment>


Neopets - <AUTHOR> http://www.neopets.com/

<comment><USER2> Oh man! My kids got sucked into Neopets and soon I had joined them. Back in the late 90's, it was a lot of fun actually. The economy was reasonable, and the kids learned a lot of very basic economic ideas. Neopets was pretty good, "do Internet with the kids" time. We would figure the site out, make plans, do stuff, make friends. Honestly, for a family experience, it was damn tough to beat Neopets! And the marketing worked. We bought a fair number of these damn pets, which the cats would shred, and we would buy more, etc... pure gold for somebody, somewhere.

Then something happened.

We were running shops. Everybody did. You put stuff in your shop and you try and sell it for more than you paid for it. A common item was lottery tickets. Get one, don't scratch it off, and sell it.

People really liked scratching these to win, and distribution was limited enough that they were always in demand. For a good price somewhere between ticket cost and the potential pay off, they sold quick!

The competition for neopoints reached a peak, and we were all going for it. So then I did something I still feel bad about...

Turns out, there was some latency in pricing updates in the shops. Mostly didn't matter, but on a high demand item that would sell quickly, it did matter. It could matter a lot.

I put a lottery ticket in the shop for 1800 neopoints, say. It gets purchased in seconds. Cool. Paid 600.

I do another one, decide to change my mind, and I changed the price. It also sold, and in fact was sold before I could get the page refresh to even confirm the edit, but it sold for the edited price, and the buyer never would know, until after the transaction completed.

The question became, "just how many neopoints are people walking around with?"

There were banks, with interest, etc... People who used them could get a nice income stream going, but I noticed not too many people used them, so...

I list a lottery ticket for the low price of 888! Going rate was about double that, and the cost of the ticket was 600. Sure sale. Won't last 10 seconds.

Right after listing it, I edit the price to 8888.

SOLD!

Did it again: 88888.

SOLD! What? No worries!

I had visions of completely, totally dominating my kids on this neopoints thing. It would only take one more successful transaction...

Listed the ticket for 1020, or something like that. I worried about the 888 thing and word getting around.

The edit? 1020000. Surely there was no way.

And there wasn't. It didn't sell. So I toggled it back and forth. 1020, 1020000, etc...

SOLD!

Just like that, I was RICH!!

Then I got an ominous message: "If you don't give me my points back, I'm gonna tell." Then a few more, most along the lines of it took me X to get all those points, cheater, you suck, etc...

I felt completely terrible.

Of course, I returned the points and then some. Didn't tell the kids, and stepped away, the guilty adult working the kiddies over big.

Neopets was awesome. Then it wasn't.</comment>


Report: millions of Uber's China rides are faked - <AUTHOR> https://www.techinasia.com/report-millions-ubers-china-rides-faked/

<comment><USER2> hmm

How do the driver and rider that are in cahoots ensure that they are paired together for the ride?

How much more money does one make using this method vs regular uber driving?

Why do accounts need to be bought and sold? is it a small minority that are doing this in bulk on one account at a time until it gets banned?

I have a lot of remaining questions that I feel like this article did not adequately explain... (or maybe it did and my comprehension is just low)

<comment><USER3> Agreed. That was basically a poor click bait article missing a lot of really good facts.</comment></comment>


Samsung takes smartphone crown in Q3 as shipments top Apple, Nokia - <AUTHOR> http://www.bgr.com/2011/10/20/samsung-takes-smartphone-crown-in-q3-as-shipments-top-apple-nokia/

<comment><USER2> The smartphone crown of shipments? What's that worth?</comment>


How The Syrian Electronic Army Hacked Us: A Detailed Timeline - <AUTHOR> http://www.forbes.com/sites/andygreenberg/2014/02/20/how-the-syrian-electronic-army-hacked-us-a-detailed-timeline/

<comment><USER2> Forbes mail server doesn't have a good spam and phishing filter?</comment>


Haskell is beautiful in practice - <AUTHOR> http://monkey.org/~marius/haskell-is-beautiful-in-practice.html

<comment><USER2> This article reads like an april fools joke. In one code block, he shows the most complex, incomprehensible haskell code (with special characters sprinkled in all over the place), then the next paragraph he confidently explains how it's so readable and straightforward to understand.

Haskell is cool, but it's one of those languages I'm going to have to accept that I'm not smart enough to program in.

<comment><USER2> A hilarious example from the post:

        p_term :: Parser Term
        p_term = t <* spaces
          where
            t =     IntTerm               <$> p_num (readSigned readDec)
                <|> FloatTerm             <$> p_num (readSigned readFloat)
                <|> AtomTerm              <$> p_atom
                <|> TupleTerm             <$> p_tuple
                <|> BytelistTerm . C.pack <$> p_string
                <|> ListTerm              <$> p_list
                <|> BinaryTerm   . B.pack <$> p_binary

"Again, reading very naturally"

<comment><USER3> Seems pretty good to me. (I know a little Haskell, but only a little.) I think you and the original author are using different standards of readability. Yours: "If I look at this code, starting without knowing anything about it, does it look familiar?" His: "Once I've taken a few minutes to get the hang of this, is it easy to read and write?".

Here, the <|> and <$> and <* are unfamiliar and weird-looking: fair enough. But once you know that <|> means "or", and <$> means "try to parse some of the input using the thing on the right, and then the thing on the left is the resulting value", and <* means "try to parse both of these, and return the result of parsing the first one", it's hard to see how it could be much simpler.

<comment><USER4> Even in that code block, <|> and <$> both have roughly the common meanings of | and $ elsewhere in Haskell, which is the "next case" operator for pattern matching expressions and the strictness operator for ensuring that a function is applied to a value correctly.

Only <* is a really new construction.

<comment><USER5> _...and the strictness operator for ensuring that a function is applied to a value correctly._

($) isn't any kind of strictness operator -- maybe you're thinking of ($!). ($) is a plain old function application operator.

<comment><USER6> It's strictness for applicative precedence, as ($) is the least of the operators, like a greedy open-paren.

</comment></comment></comment></comment></comment></comment><comment><USER7> Well, I liked the article - I have worked through the real world haskell book just enough to sort-of understand this article :-)

That said, I gave up on Haskell. I spend a lot of time semi-learning languages because it is fun. But, for practicality, I really concentrate on knowing just Ruby, Common Lisp, and Java very well.

Striking a good balance between practicality and having fun is not so easy to do.

</comment><comment><USER8> Some people say mathematics is beautiful. After several years, unfortunately, I could never see that beauty. There was a point, long ago, where I could see the beauty of Forth.

Ditto with Bach. On the other hand, I 'get' the beauty of Beethoven and the Boards. To each his own ... but 'beauty' is _de gustibus_ , and mere functionality does not qualify.</comment>


FSudoku: a fast Sudoku solver in less than 300 lines of Python - <AUTHOR> https://github.com/jcoffland/fsudoku <comment><AUTHOR> Back in 2008 while stuck over night in the Lima airport I decided to crush Sudoku once and for all. Here is my implementation of a fast Sudoku solver using _no_ fancy tools, such as NNs or SAT solvers, in less than 300 lines of Python.</comment>


Apple to Deprecate Scripting Languages in Future Versions of macOS - <AUTHOR> https://tidbits.com/2019/06/25/apple-to-deprecate-scripting-languages-in-future-versions-of-macos/ <comment><AUTHOR> This is already old news, but the article elaborates a bit on some interesting details.

</comment><comment><USER2> They are so many things that I would have removed out of macOS over this, Oh well.</comment>


The new DocuSign experience, all in JavaScript - <AUTHOR> http://engineering.docusign.com/articles/the-new-docusign-experience-all-in-javascript/

<comment><USER2> When we started this project there was some pushback about using Node.js instead of Python or Rails, but we went with Node.js and it's been a great choice.</comment>


Made this app to manage my stress - <AUTHOR> It uses the smartphone camera to read pulse, and calculate stress metrics (called Photoplethysmography). This is definitely a "rough draft", and my first android app, but I would love any and all constructive feedback. Also, because I originally built this as a personal utility, I will likely continue development for a long time coming. So anybody who finds it useful and helps me generalize its utility by providing feedback overtime will be my new best friend :)
Thanks!
P.S. Part of my goal is to the the peak detection, and eventually motion artifact reduction algorithms very transparent. This is to say I want it to be very obvious how raw data turned into the higher level biomarkers. If you have ideas on how to achieve this, I'm all ears.
https://play.google.com/apps/testing/com.martianwearables.hrv_flowt <comment><USER2> Congratulations on building something and putting it out in the world for feedback. That reflects effort and a willingness to take risk.

Getting community engagement is going to be harder. Consider my user experience. I'm on my laptop, but I figured I'd look in the play store and see what it is. But because it's in testing, I have to log in with my Google account. So between catching my attention and getting me involved, I would have to switch devices, login from Android, navigate to Play, install the app, use it, and only then if I cared enough about the app to provide feedback I might be bothered to provide it.

If there is a 50% chance that a person will do each of these things then 1:32 will convert. I doubt it is anywhere near that high. Making things easier for people to see your idea will make building a community easier (but not easy).

Good luck.

<comment><AUTHOR> Thanks for the encouragement. I plan on putting up a blog where I document algorithm development and other such news. I certainly have a lot to learn with regards to marketing.

Cheers</comment></comment>


The Holistic Engineer - <AUTHOR> http://dtrace.org/blogs/ahl/2013/02/06/the-holistic-engineer/

<comment><AUTHOR> I worked with Adam at Fishworks, and when bringing engineers into our way of thinking, I used to describe this as engineering from "shower to support call" (I do too much thinking in the shower) -- but I stopped when I realized that this sounded a bit creepy if one views a shower only as hygiene. Adam's nomenclature is much better -- and captures everything I have ever aspired for in myself and sought out in others.</comment>


Introducing Timeline: See how your project plan fits together - <AUTHOR> https://blog.asana.com/2018/03/new-asana-timeline-view/ <comment><USER2> Hey, I was the program lead for this project. Let me know if you have any questions!

<comment><AUTHOR> What were some of the technical challenges you faced during this project?

<comment><USER2> In the timeline view, multiple tasks can be displayed in the same row. The position in the row is determined by the start or due date of the task. One challenge we encountered was in just maintaining the data model because users can set dates in multiple ways. For example, a user can set a due date on a task through the list view, mobile apps, or even the API. Since every task with a date is displayed in the timeline, when a user sets a date on a task, we pick a position to display the task in the view. One interesting thing is that when a user changes the date, we automatically resolve conflicts so that in the Timeline view, two tasks in the same row would not overlap. We had to think through most of these scenarios before we picked a data model representation so to ensure these operations are efficient. On the UI side, our biggest challenge was in implementing one of the most interactive views in Asana that supports multiple zoom levels. We spent a long time thinking about component structure and hierarchy to allow us to build them.</comment></comment></comment>


Show HN: Stop inviting me to stuff on FB - <AUTHOR> http://stopinvites.herokuapp.com Someone on twitter complained about getting too many 'I want to add your birthday' app invitations. So I made an app that allows you to yell at them. The question is, do you have the balls to do it? <comment><AUTHOR> Someone on twitter complained about getting too many notifications for 'I want to add your birthday' app on FB. I made an app that allows you to yell at those friends. The question is, do you have the balls to do it?</comment>


The Art of Insight in Science and Engineering: Mastering Complexity (2014) [pdf] - <AUTHOR> http://ocw.mit.edu/resources/res-6-011-the-art-of-insight-in-science-and-engineering-mastering-complexity-fall-2014/online-textbook/MITRES_6-011F14_art_insfin.pdf <comment><USER2> I took a version of this class (called The Art of Approximation) with Dr. Mahajan when he was a visiting professor at Olin College. The course helped me become fearless about tackling a broad range of math problems I knew little about, and has helped me in countless real life situations from financial planning to major work decisions.

Also, it's a great intro on good ways to nail PM interviews, at least at Google (where I now work, thanks in no small part to the lessons from this class).

If you have a spare few hours, read this book or take his classes on edX. It'll absolutely change your intuition for numbers.

<comment><USER3> Oh cool. I'm actually in Olin now, and even better, taking his class as I type this post.

Art of approximation [https://imgur.com/a/OvDzl](https://imgur.com/a/OvDzl)

I'll pass along any cool questions.

</comment></comment><comment><USER4> An earlier book from the same author: [https://mitpress.mit.edu/books/street- fighting-mathematics](https://mitpress.mit.edu/books/street-fighting- mathematics)

<comment><USER5> In fact he has a course on edx for this: [https://www.edx.org/course/street- fighting-math-mitx-6-sfmx](https://www.edx.org/course/street-fighting-math- mitx-6-sfmx)

<comment><USER6> Thank you very much for posting this.

</comment></comment></comment><comment><USER7> I went to graduate school at Caltech; my time there intersected with SM for about a year, but I only learned about that when he had already graduated.

In one of the rooms in the physics building (E. Bridge), there used to be a few shelves with old theses. While checking them out one day (probably trying to kill time before a seminar), I came across Sanjoy's thesis. It was a curious little thing, unlike any of the other theses I had seen---a bit of a hybrid between a PhD thesis and a textbook, and remarkably, very readable.

That thesis was, apparently, the first version of his now famous book, Street- Fighting Mathematics. After getting lost in it for a while, I went and asked the administrative assistant if I could get a copy, and she said nobody cares about those volumes on the shelves, and I could just take it if I wanted. I still have that copy with me.

One year I attempted to audit the (somewhat legendary) class that the book part of SM's thesis was based on---"Order of magnitude physics", taught by P. Goldreich and S. Phinney. Unfortunately, the lectures were in the morning, and I managed to wake up early enough only a few times, and dropped out afterwards.

I continued to collect material on related topics over the years, and am still hoping to use them some day in a course, together with SM's books.

<comment><USER8> After a bit of Googling, I believe I have found a copy of this thesis [0].

[0] [http://www.inference.phy.cam.ac.uk/sanjoy/thesis/thesis- lett...](http://www.inference.phy.cam.ac.uk/sanjoy/thesis/thesis-letter.pdf)

</comment></comment><comment><USER9> What a great find! I didn't even dream of a book like this. Thank you for sharing!

</comment><comment><USER10> How come this book is available on download I mean what about copyright?

<comment><USER11> It's under a license that allows freely sharing it for non-commercial purposes.

<comment><USER12> I've wondered about this: when it says non-commercial purposes, does that mean me downloading a copy to read for my work, or me printing and selling?

I haven't any problem buying it, since it's useful for my job, but that distinction has been a bit fuzzy to me (and I'll normally just err on the side of buy, just to be safe).

<comment><USER13> Commercial would mean you make a gain from distribution of the book. Money can be one of the gains.

<comment><USER12> Thanks - distribution vs consumption always mix me up with the copyright rules.

</comment></comment></comment></comment></comment><comment><USER14> What are the prerequisites to understand this book? I feel very intimidated by some equations.

<comment><USER8> Comfort with freshman physics and math is really all that's required.

You can always review those first.

</comment></comment><comment><USER15> The irony of a an article claiming to master complexity while using one of the worst choices of information dissemination. PDF's. Palpable.

<comment><USER16> Besides it being a book, not sure what the irony is here. PDF is a poor way to disseminate information via the web, but excellent for distributing information in a container that you envision as uniform and universal -- in this case, paper. The responsive variable nature of a browser window can sometimes do screwy things to a well planned layout.</comment></comment>


Old WiFi: $1 cup of coffee. New Mesh WiFi: $5 latte - <AUTHOR> https://backchannel.com/a-gourmet-guide-to-wifi-b9a308e662a9#.r6poknza6 <comment><USER2> I'm actually happy you didn't use the original title: "A Gourmet Guide to Wifi" because I wouldn't have clicked on it.</comment>


VNect: Real-Time 3D Human Pose Estimation with a Single RGB Camera - <AUTHOR> https://arxiv.org/abs/1705.01583 <comment><USER2> Excellent work! I think as deep learning gets more mainstream and easier to use computer graphics are gonna have a huge boost from it and we are going to see a lot more crazy stuff in conferences like SIGGRAPH.</comment>


Justice Dept.'s Latest Legal Filing in Apple Case - <AUTHOR> http://www.nytimes.com/interactive/2016/02/19/business/document-motion-to-compel-apple-compliance.html <comment><USER2> This seems like a well crafted attack on Apple (perhaps the highest profile tech company publicly supporting consumer encryption). The revelation earlier this week that the pass code changed while under government custody seems to point to this being a witch hunt.

The "just this one time" argument doesn't hold up for me. This is a battle over public opinion and government powers. That they picked the San Bernardino case to issue this order on is not a coincidence.

There is essentially no way to win this for privacy. If Apple wins, government will make the case for more funding to break into devices tech companies refuse to assist on. If the government wins this will be the tip of the ice berg on the government compelling corporations to whatever ends.

<comment><USER3> I've never believed in a conspiracy theory except for this case.

The government clearly wants to hack more than this one phone. The government clearly waited for the next terror attack to launch this attack on privacy and encryption.

</comment></comment><comment><USER4> The document is fairly easy to parse, even for us non-lawyers. The filing reiterates the government's position, that Apple has unlocked phones in other cases, has the ability to comply with the court order, and Apple's marketing or business concerns or effect on shareholders are irrelevant to the matter.

In reading the document it seemed to me that the outcome may hinge on whether compliance would be considered "burdensome" to Apple. The government asserts that modifying the software (for this one instance and no other) is more or less trivial, therefore Apple really has no grounds for refusal.

Some comments on HN have suggested the software isn't so simple to produce, but not something I know enough about to speculate. Perhaps Apple's reply to the court will shed some light on this aspect. Fascinating to watch this chess match play out.

I'm guessing in the end the court order will stand and Apple will need to comply. Maybe Apple surmises the same. It's reasonable to believe their protests will garner ongoing public sympathy while cooperating with the FBI under compulsion of the court.

<comment><USER5> For those of us that aren't aware, do you know much about the instances where apple has unlocked phones in the past? I was not aware of this!

<comment><USER6> It's been reported that Apple unlocked phones 70 times in the past. But all those instances were for phones with older versions of iOS that were pre- encryption.

<comment><USER7> It's been _falsely_ reported that Apple unlocked phones 70 times in the past. See Matthew Panzarino's article in TechCrunch: [http://techcrunch.com/2016/02/18/no-apple-has-not- unlocked-7...](http://techcrunch.com/2016/02/18/no-apple-has-not- unlocked-70-iphones-for-law-enforcement/)

</comment></comment></comment></comment><comment><USER8> Why doesn't Apple simply write some "buggy" software that "accidentally" wipes the contents of the phone?

<comment><USER9> Because that'd be extremely transparent and cheating the U.S. Government in a legal matter isn't going to help anyone long term. They'd just use it as more evidence that they need more control.

<comment><USER8> How could they ever prove the difference between a bug and malicious intent? If they want control over the process then don't ask Apple to do it for you.

Also, Apple wouldn't be able to test it well because the custom OS was written to only work on that specific phone (not the model of phone, the defendant's phone).

</comment></comment></comment><comment><USER10> This does appear to undermine Apple's argument that the Order could have wider security implications. As such Apple is allowed to do what is necessary to retrieve the passcode in-house, and destroy all software/hardware related to the process thereafter. It of course sets a unwelcome precedent, but that appears to be it.

<comment><USER11> Sounds like if that process were followed a defense attorney would be free to argue that there was no way to prove any evidence produced from the decryption had not been completely invented in the process.

<comment><USER10> Why would that be? If they are handed the passcode, the device could be decrypted in the presence of the defence, and verified by their experts.

<comment><USER12> Who exactly is "the defense" right now?

<comment><USER10> Good point. The defence would be the defence for anyone implicated by the recovered information. The government would be prudent to undertake the decryption in a way that would not permit such a defence to question its authenticity.</comment></comment></comment></comment></comment>