React and Redux are a joke right? - <AUTHOR> https://games.greggman.com/game/react-and-redux-are-a-joke-right/ <comment><USER3> >In the react world though you can't _mutate_ your data.

Wrong, you're free to mutate your data. What's immutable is the virtual DOM fragment that a component maps the data onto. If you want to manipulate the DOM directly (and it can make sense), how about not choosing a virtual DOM/diffing library?

>If you get 3 people react will end up re-rendering 3 times because of the code above.

Yeah, because the code above is obviously not a good idea. If you receive a list of people and loop over the members, each time triggering a rerendering, it's your fault?

>So what about trees of data with redux? The docs tell you try not have nested data. Instead put things in flat arrays and use indices to reference things in other flat arrays.

I'm not sure what part of the docs this refers to, but state in Redux is literally organised in a _tree_ and you're free to choose data structures for the nodes that make sense. I've found that deeply nested structures make it more cumbersome to write reducers for.

>Why is the UI library dictating how we store and manipulate our data!!!

It does not do this, it's a virtual DOM/diffing library (!!!).

>Maybe someone needs to start the browser over.

This is a highly incoherent rant that mixes up criticism of immutable data structures, the Flow architecture, virtual DOMs and the Redux API. The quote above doesn't surprise me in the least.

Having said all this, the approach commonly taken by React/Redux is certainly not a silver bullet for every problem domain, but then what is?

<comment><USER4> I'm about 6 months into a React project (coming from Angular1) and honestly I find the OP's rant pretty coherent. React requires a preposterous amount of code to maintain state, and Redux doubles down on boilerplate.

In Angular-land you can just mutate some JS objects and the UI magically updates. I really miss that.

I picked React over Angular2 because the setup was simpler and I wanted to try out this new thing that everyone has been raving about. I have a lot of misgivings about the choice. There are some things I like about React, but I probably will not choose it for my next SPA. There's just too much _typing_.

<comment><USER5> Redux is not intended to be THE state management lib for every possible use case. It sure can cover pretty much every case though as people tend to notice, that requires quite some boilerplate. For typical CRUD apps that stay in sync with the backend, I'd recommend going with MobX or GraphQL (Relay or Apollo on the client side). There you can directly mutate objects just like you're used to.

To reiterate what other people have said. This it not a problem of React, this is a problem of people blindly jumping on the Redux hype train, without doing the required reading into Redux and its use case.

</comment></comment></comment><comment><USER6> I'm one of the laggards - Over the years, based on staying around tech communities (esp. HN) I've learned not to invest time / effort into the hype that surrounds a newly launched tech. I did burn my finger a couple of times, especially with MongoDB back then, so these days I'm pretty cautious.

I'm one of the very few who didn't invest in React. I waited it out and invested into Vue.JS, instead. This is no framework war, purely based on opinions.

My opinion is pretty simple and resonates with a lot of people, apparently[1]:

        ~15 years trying to make everyone separate HTML, JS & CSS. And then suddenly everything went south and we're writing code like this: [1]

This alone makes React a joke for me, let alone the author's post. If it resonates with you, then good for you. I may not be from Facebook or Google to have the authority, but I do know what's good in the long run and what isn't. I couldn't be happier with Vue.

[1] [https://twitter.com/thomasfuchs/status/810885087214637057?la...](https://twitter.com/thomasfuchs/status/810885087214637057?lang=en)

<comment><USER7> > _~15 years trying to make everyone separate HTML, JS & CSS. And then > suddenly everything went south and we're writing code like this:_

That's definitely not what's bad about React. In fact that's what great about React -- coherent widgets (components) that are defined in a single place. Not to mention that JSX in React it's all JS and properly parsed and checked -- the "HTML" there is just sugar.

Such separation of HTML/JS/CSS was misconceived. It makes sense for web documents and simple forms, but not for web apps with rich widgets etc (which is what we're trying to do). Tons of problems stemmed from cargo cult adherence to that.

Everybody else, including those that add JS instructions (or ad-hoc "templating language" instructions inside HTML tags) are getting it wrong.

<comment><USER8> I'd argue that back then, focusing on elegant CSS was also a mistake. Outside of well-done libraries, I've never really perceived code re-use as a big force multiplier.

Even now with React, I still don't see much code re-use outside of libraries. When you want your code to be re-used... you exercise the discipline that a library author would. You add typings, you add documentation, you add tests, you create a Github page where people can provide info. Taking someone else's code is a commitment, so you at least want the reassurance of library-quality code.

Otherwise when you write a component, whether in the old school html/css/js split, or in React, you're unlikely to write the component in a way that optimizes for generality, and optimizing for generality, as opposed to the narrow business case in front of you, is often a lot harder.

</comment></comment></comment><comment><USER9> I started working on a react native+redux project myself recently (after working with react on its own for about 1 year) and have been feeling the same way. And we've just been working on auth, data persistence, and screen navigation.

My problem with it is that there is so much abstraction that almost no prior knowledge from using other frameworks or libraries is useful. It seems like everything is magic.

Here is a chain of react tech things: React->Flux->Redux->Redux- Persist->PersistGate

The latter is talked about in documentation, i.e., "do it like PersistGate does", but I can't find PersistGate anywhere.

With so many react extensions and libraries all having their own helper functions to do everything it seems like we are no longer programming, but instead, we are tasked with stringing together configuration functions after searching for hours for the currently relevant documentation.

I think react does some pretty amazing things, but the learning curve is too steep because of fragmented documentation (mostly the community created how- tos are the problem here), confusing abstractions, and poor method naming (thinking about redux's `reducer` here).

Anyway, I, and several programmers at my company, share your sentiments; you are not alone. This will probably be my last greenfield react project.

<comment><USER10> This is exactly my experience. Eventually, I skipped redux/mobx/etc altogether by creating a singleton EventEmitter which can hold application state objects, emit events when the state changes and persist it to SQLite. For data that does not need to be in memory, I just access SQLite directly (and I can still use my appState singleton to let the rest of the app know when SQLite data has changed.)

Yesterday I spent probably 5-6 hours just trying to figure out how to _navigate_ easily with react-navigation. There are probably over 100 questions on their issue list asking the same thing: How do you easily navigate between nested navigators? They all have the same setup: A StackNavigator that contains a TabNavigator that contains one or more StackNavigators. Nobody knows how to do it without redux and users that do use redux have other complaints. The react-navigation examples all show a `path:` property, but they don't just have a global service that you can use to navigate to all those paths. Instead (I think) you have to wrap all of your navigators and pass around the `navigation` property. When I tried following their example of passing down the navigation property, I just get errors.

I blame the people who tried to force their stupid functional programming ideology onto the whole framework.

<comment><USER10> Just an update: I almost gave up on react-native today because the navigation story seemed so broken. I actually spent a few hours checking out Xamarin.Forms at one point. Then I took a break and I was about to play some Rocket League when I had a eureka moment - I finally understood the simplest way to make react-navigation work the way I needed it to and within an hour I had a working implementation!

(The trick that worked for me: Don't nest navigators directly within each other, instead wrap each one in a component class, get a ref to the wrapped navigator and then use that ref to handle navigation requests from a global navigation service that other components and services can use.)

So, my opinion of react-native has softened a bit this evening as I've gotten over my biggest hurdle yet. After trying Xamarin out and also comparing it with my previous Ionic/Cordova/PhoneGap experience...I'm glad to be back with react-native.

Also, Expo XDE has been a pleasure to work with - discovery of that tool is the reason I decided to re-investigate RN about 2 weeks ago. The first time I tried RN was like 6 months ago and I had spent a few days the first week just trying to get the environment working properly. This time everything just worked (and on multiple operating systems!)

</comment></comment></comment><comment><USER11> The article has a point. We tend to fix issues with state by avoiding mutability. That is like going to a doctor because it hurts when you laugh, and they just say "don't laugh". I wish there was a language that _embraced_ mutability instead [1]. Mutability is how the computer works at the lowest levels, and how we tend to think about the world.

You would use plain old data objects to store everything. Then you would have first class observers, meaning you could have callbacks react to any changes to any object. But you wouldn't use that low-level functionality often. Instead you would e.g. create a listview, and just set it to observe the array. This is like "list adapters" that are in many frameworks, but built into the language.

One thing that I'd love to be able to do is to have the data as plain-old- objects, updated frequently from one thread, and the gui living on another thread that observes it occasionally in a read-only fashion (and occasionally sends mutating messages to the backend thread). You could implement that with read-write locks, but as far as I know no framework supports it directly.

Maybe this language would have a special block that takes imperative, mutating code, and lifts it to implement the command pattern [2]. You then could "undo" these blocks, coalesce them, and so on. (That doesn't work with arbitrary code, but with most code that operates on business data.)

(Here are some questions I asked on StackExchange, trying to find out if something like that already exists:)

[1]: [https://softwareengineering.stackexchange.com/questions/2298...](https://softwareengineering.stackexchange.com/questions/229876/language- that-embraces-mutable-state) [2]: [https://softwareengineering.stackexchange.com/questions/3515...](https://softwareengineering.stackexchange.com/questions/351593/automatically- convert-mutations-in-imperative-code-into-functional-actions)

<comment><USER12> `One thing that I'd love to be able to do is to have the data as plain-old- objects, updated frequently from one thread, and the gui living on another thread that observes it occasionally in a read-only fashion`

Dojo-stores, observable-collections essentially, were like that. A Dojo-view was a monitor for this. A very simple, elegant model-view design.

I agree that we should embrace mutability. The JS-code most people write now has horrible performance characteristics since we do not take advantage of the benefits of mutating objects to manage state. Instead, in JS-world, we recreate and duplicate state all the time, spamming the heap. One library doing this is not too bad, but all libraries doing this is the main cause of slow web apps.

</comment></comment><comment><USER13> Stopped reading half-way through, as lots of incorrect stuff off the bat.

> In the react world though you can't _mutate_ your data

Sure you can.

> If you get 3 people react will end up re-rendering 3 times because of the > code above. Each call to `setState` triggers a re-render.

Nope, calls to setState are batched.

<comment><USER14> I think sometimes you need an outsider view to call out that the emperor isn't wearing any clothes, and that's going to result in botched details. I don't think it impacts the overall point the author is trying to make.

I teach web development at a part-time course, and we recently redesigned our curriculum to use React + Node instead of Rails with JQuery. With the new technologies, the students are profoundly less productive or effective by the end of the course - they're doing well if they have the barest skeleton of a CRUD app up, whereas the Rails apps were all fleshed out and far more engaging.

There's something rotten with the state of development these days - we're dealing with far more complexity and being less productive for what's usually the same result.

<comment><USER15> Then why don't you stick with Rails and jQuery? Modern frameworks like react (or even SPA alltogether) evolved for certain types of web applications (read that again: web applications, not websites). If your web application has requirements like offline funtionality (think mobile appstore deployment), very nice UI (think animations) or responsive UI (in terms of response times to clicks, drags etc.), you would not get far with Rails, or end up with a mixed backend/frontend code soup for HTML rendering and DOM manipulation.

Another aspect is enterprise grade websites, where jQuery just does not scale as well or will make your code end up in an unmaintainable state. "Get beginners going fast" is a nice feature, but sometimes its more favorable to have "scales for teams with >10 developers".

If you are making a simple website, blog or whatever, please do not use SPA but stick with the server-side frameworks we had for years.

<comment><USER16> > Then why don't you stick with Rails and jQuery?

They're teaching classes about web development and trying to react to the perceived market demands.

You're talking here about "if you're building X or Y, use ABC", but the class doesn't make that call, and they're trying to be attractive enough to students to choose them.

If I was a student, and was looking to "learn web development", and I search around for what I should learn to make myself attractive to employers... I'm _very_ likely going to find unbounded recommendations for Angular, React and Node, almost without exception. Probably not even 'likely' \- it really is what I see touted weekly in many groups that I'm a part of (user groups, online forums, etc).

The current situation for new folks trying to get in feels like a big echo chamber with bad recommendations reinforcing poor choices leading to more confused (and less productive) jr devs coming in to the field.

</comment></comment></comment></comment><comment><USER17> tl;dr of this blog post: "Oh no, I don't understand how immutable data structures work and need to rant about why it doesn't make sense!"

I don't want to be mean about it, but there's a lot of literature on functional programming and how mutable data complicates things as your states increase. The problem isn't how React forces you to write long code to get around immutability, the problem is the fact that you're trying to force your approach.

And no, this isn't because React is heavily opinionated -- it's because React's underlying philosophy is functional programming.

<comment><USER18> React feels like a library written for a language that's not JavaScript. JavaScript defaults to mutability by default - there are no immutable primitives that you can easily use, and even in ES6 just maintaining immutability without deep cloning everything takes a lot of effort. In that respect React _is_ heavily opinionated.

<comment><USER19> "there are no immutable primitives"

Many array prototype functions work in an immutable way like map and reduce

<comment><USER18> Updating an array element

      arr[3] = 'New content';

Updating an array element immutably

      arr = arr.map((element, index) => {
        if (index === 3) return 'New content';
        return element;
      });

It's possible, sure, but it feels terrible. JavaScript objects want to be mutated - it's the most idiomatic way of interacting with them. Whether functional programming paradigm is good (I certainly feel it is) is beside the point - JS wasn't designed for it.

When I think of immutable primitives, I think of Python's tuples, which will raise a big fat error when you try to mutate them, or even better, Swift's structs, which gives you a new copy with every mutation.

<comment><USER5> if you use ES2015:

      arr = [
        ...arr.slice(0, 2),
        'New Content',
        ...arr.slice(3)
      ]

<comment><USER20> In my eyes this slice of code is even worse than the array map one, where there is 2.5 pieces of logic (map, if, and 2 return that makes for the .5).

In the version you have 2 spread operators, an array construct and 3 hardcoded ints.

I might not use the correct academic terms, and I might not be yet fully accustomed to es2015, but this way of writing stuff always make me pause and double check the code.

<comment><USER21> In ES2017 this gets substantially better:

const arr2 = Object.values({...arr, 3: 'New Content'});

</comment></comment></comment></comment></comment></comment></comment><comment><USER7> Judging from the title I expected one of the usual BS posts like "OMG, React mixes code and html!!!" etc and was ready to post a "No, you just don't get it" comment.

But this actually makes several good points on accidental complexity imposed by React/Redux.

I know why they impose it, but there must (should) be a better way.

</comment><comment><USER22> There's a lot of comments in here addressing some of the conceptual misunderstandings of "how to use react" (i.e. "use immutable.js", etc). I started writing React within the last year and, while I still find parts of it strange, I've found its real strength comes from the fact that it's easy to reason about, particularly at scale. In a large project, I don't find myself digging around the codebase looking for the place where event listeners are being bound, or where a piece of the DOM is getting mutated. The unidirectional flow of data makes it very easy to jump into a piece of an app.

It's not without its complexities, however. Mainly:

1\. using JSX, instead of a more transparent templating language, means people with less technical knowledge (i.e. product designers) have a higher barrier to entry when trying to make simple UI changes (I'm looking at you, `className`).

2\. it is unclear at times whether a component should have its properties passed in directly from state through `mapStateToProps`, or from a parent component through `props`.

3\. there does seem to be an tiring amount of boilerplate when adding a new piece of interaction to a component (an action, an action type, a reducer case, and usually a piece of state all need to be added).

4\. to a newcomer, the benefits of immutable.js are apparent, but the benefits of a memoizing layer like reselect.js were less obvious. When you're still trying to wrap your head around How To Write React Things™, it's not apparent that you'd even _need_ memoization ("isn't React supposed to be good at diffing stuff?" you ask yourself after watching large pieces of your app redraw itself over and over).

I'm curious to hear how people deal with these particular issues. React was one of the more useful tools I learned about this year, and I'd love to see the process for newcomers to React become less frustrating.

 _Edit: formatting_

</comment><comment><USER23> If the author wishes to continue with js/react/redux then he needs to pick up a library like immutable.js to cut down that immutabiilty helper crap.

However, there is a better way ... lein new figwheel my-app, clojurescript+reframe gives you all the benefits of redux with an order of magnitude less boilerplate (also hot reloading and immutability by default without no extra setup or ceremony)

<comment><USER24> Immutable.js is just another complication with another 60k size penalty with a few new negative drawbacks that he would need more complexity to solve. Author is already arguing against this approach.

<comment><USER25> Yep.

I've been working with React for years now, over several large projects. I still feel like I'm not used to it, and I still hate it. That's not normal.

We need to either figure out how to do this shit with mutable data structures, or we need a new language that's immutable by default.

ImmutableJS blows chunks. Yeah it "saves" code until you start doing the data transformation dance trying to figure out when and where to convert between plain JS objects and Immutable ones. Then you end up with some real ugly shit that'll trip up every new hire you walk through it (we use a higher order component that converts a component's Immutable props to regular objects, which incidentally is _another_ import that like 800 unrelated files depend on...)

God help you if you don't use well commented code or Hungarian notation to differentiate between Immutable objects and regular ones. We all know how long good commenting practices last without thorough code reviews, and we all know how long _those_ last in fast-moving environments, which is where React is most useful.

I guess a typed language would solve that. No, Flow and Typescript don't count.

<comment><USER26> Why don't Flow or Typescript count? Our team uses TypeScript, mostly C# devs, it's been great. The main issue getting definitions for some less common libraries.

We haven't been using immutability.js because of the back and forth overhead between regular JS and immutable objects. Instead we use mutation checking of the Redux store during development you can make sure nobody is stomping on it by accident.

<comment><USER25> > The main issue getting definitions for some less common libraries.

That's one problem. The other is discipline. It's just way too easy to opt out of the type system. It shouldn't be a problem, but in the world of deadlines where every single front-end dev is intimately familiar with writing plain old Javascript, it is. All it takes is one manager that's a bit pushy, or one urgent production bug, and your codebase is on it's way to turning into a pile of shit.

I do love type systems, but IMO they have to be part of the language, it just doesn't work as an optional addon.

</comment></comment></comment></comment></comment><comment><USER27> I think the author may like to consider Vue.js + Vuex. In Vuex in particular the first argument of each mutation is the store state, which you can mutate how you wish and the framework takes care of the rest.

<comment><USER28> Yeah. VueJS is powerful, easy, and made based on Javascript principles itself. I recommend for sure for who thinks React overcomplicates stuff, like me.

</comment></comment><comment><USER29> Maybe this is stupid question, cause I don't know React or Redux, but why would anyone want the data structures holding page data to be immutable? Data can change any time due to user actions, immutability would only get in the way, wouldn't it?

<comment><USER30> The "redux" way is to make everything immutable to reduce side-effects, implement time-travel debugging and most importantly - make your code very complex.

<comment><USER23> Immutability in js is awful hence the complexity, a library like immutable.js can make it better, but the language is just not built for it.

Because imperative code and persistent, immutable data do not play nicely together.

<comment><USER30> Agree, but the problem is that you need unreal discipline because what I see in projects that are 1+ years old half of the code is using Immutable.JS and half is not - and that is even worse!

</comment></comment></comment></comment><comment><USER31> I get his point -- javascript object observation has been a pain, and causes the stated workaround.s

With new API like Proxy [1], we should not be able to just modify data as needed, and any observers can be notified by handlers in the object get/set. This will lead to data being fully mutable.

[1] [https://developer.mozilla.org/en- US/docs/Web/JavaScript/Refe...](https://developer.mozilla.org/en- US/docs/Web/JavaScript/Reference/Global_Objects/Proxy)

<comment><USER32> The Proxy API is how dot-dom[0] implements a React-like component API

[0]: [https://github.com/wavesoft/dot-dom](https://github.com/wavesoft/dot- dom)

</comment></comment><comment><USER33> Choose the tool which is suitable for you. When your web app grows to a certain scale, you will need "lots of code" to maintain state and prevent rendering.

</comment><comment><USER34> > This is probably an ill thought through rant but...

Everything after the "but" and all.

The whole point of Redux is to separate actions and state manipulation. An argument that, "well I want to manipulate variables feely," is not an argument. Just don't use Redux. End of story.

The pattern doesn't come from React. There are many patterns in React that are just Monads by a different name. Redux isn't much different.

</comment><comment><USER35> React does its job fine. I think the good part of the post is pointing out the verbosity of Redux and you don't accept it. According to me, it totally depends on your implementation, Redux is just a concept of data flow, you made your choice when using react-redux. By time and eventually, you will figure out how to minimize the boilerplate, because you didn't accept it.

</comment><comment><USER36> Without a big push in uniforming and standardizing ways to listen to property changes on both objects and components there won't ever be a sane UI framework in javascript, it's simple as that.

They'll either be too limited so that you cannot express the full featureset of html within their bindings without hacks or too convoluted to use and impossible to debug.

</comment><comment><USER37> I've tried to 'get' redux a couple of times and have reverted back to reflux each time because sanity is nice.

</comment><comment><USER38> Try using ES destructoring and spread operators plus a library like Kea ([https://kea.js.org](https://kea.js.org)) to provide a framework over Redux and most of these arguments become irrelevant.

<comment><USER9> Not the author, but my opinion on the matter is that react already has too many abstractions and helpers, which just adds to the problem. React is difficult to grok on its own. Adding another framework to the tech stack just makes it worse if you don't already have a fluent understanding of the layers beneath. This is my experience with it, at least.

<comment><USER38> But that's kind of the point with react: it's just a view library so you're forced to add things to the tech stack until they click together. Of course it helps a lot of you know how all the layers work on their own.

</comment></comment></comment><comment><USER39> Honestly, I don't recommend using React unless you're building realtime web applications. Otherwise, you're correct, React is too heavy. If you're not doing realtime, the idea of state is completely unnecessary. But if you are doing realtime web apps the idea of state and hoops that React make you jump through make sense. Is it hard? Yep. Is it worth it. Yep. Will there eventually be a better way? Yep. With that said I think some of the pain points you identified could be simplified. State is needed but immutability could be made easier.

</comment><comment><USER40> After reading so much about it and trying it several times, I think my problem with react (alongside the licensing issue anyway) is that it feels like the perfect example of the fundamental theorem of SE: Everything is full of indirections and, when that isn't enough, then more abstractions in the form of tangentially related libraries (such as immutablejs in this thread) are recommended.

I'm sticking with Vue, it's not perfect but it was at least designed to play with js's strengths instead of abstracting them to shoehorn functional principles.

</comment><comment><USER41> Could somebody outline how I can write an efficient rich text editor using the state management techniques of React and Redux?

(Not that I want to try this, but I'm interested in how that would work).

<comment><USER42> Tyr [https://draftjs.org/](https://draftjs.org/)

</comment></comment><comment><USER43> I agree that there is some amount of boiler plate code to Redux that doesn't seem to make sense and takes a long time to do when you're new. But I think it really helps with maintenance and scalability of projects down the road and saves you time later on.

Of course, as others have said, React and Redux is not a panacea - <USER2> on what you want to achieve and on your personal preferences there might be better tools.

<comment><USER44> > I think it really helps with maintenance and scalability of

> projects down the road and saves you time later on.

It's popular argument but I don't think it's completely correct.

On the one hand principles of Redux (immutability, message-passing approach, separation model from the view) can be helpful, on the other hand huge amount of boilerplate and moving parts can only spoil scalability.

Besides Redux is very low level with very little abstraction (this is why some many abstractions over Redux appear - because Redux alone has almost none).

I think Redux has good foundations but it's poorly designed as a library targeted to average developer working on real projects. It feels more like some academic experiment, something more like proof-of-concept that library that solves real problems in elegant way.

<comment><USER43> I see your points and don't disagree. However, Redux is a fairly young concept and I think it has some potential to grow (as is React).

</comment></comment></comment><comment><USER45> This guy expresses a lot of opinions about React/Redux that I share, but he doesn't understand something fundamental about web development. The look and feel of the page comes first, and the structure and coherence of the code comes second. And you don't really need complicated, fast UI for most web projects.

<comment><USER46> Yes, but I sense that he's in a similar boat as me right now. I just joined this team that's already using React/Redux, and the code quality is... very sad.

<comment><USER45> Code quality was the main issue driving a lot of folks _to_ React. Like lambs to the slaughter...

</comment></comment></comment><comment><USER47> WHY would you even considering composing your own diffing structure for updating a components state when that's entirely against the paradigm React proposes. Pass props from the parents and let the tool do the heavy lifting. State is an abused and misunderstood interface in React.

</comment><comment><USER15> Author complains about "lots of code" needed for changing his data, but at the same time refuses to use modern ES6 features.Most of his code would come down to 2-3 lines when using destructuring and object/array rest operator.

<comment><USER48> Agree. Some of the complaints get back to not really understanding the ES6-7 feature set that was created to allow JS to become more compact yet expressive in doing common tasks (like creating an object from an existing object, yet changing a few parts).

For the Redux issue, the light bulb went off for me at one point on how best to use it to solve specific issues. React is focused on component based development of the UX; everything in the small library is there to help with this including "state" (that is, the internal logic state of the component). Since React went with the simpler one-way flow of data updates (vs. Angular's two-way), Redux came along to help bridge the divide between clusters of components that share some data.

So when designing React apps, I almost always use React state. 80-90% of the time it's fine, works well and is easy to understand since everything about the component is there (along with the "props" or arguments to the component).

I use Redux when I occasionally need to do the following: 1) Share data between otherwise unrelated components 2) I need to setup "global" state that exists between page transitions, etc. 3) A child component needs to notify a parent of some event. This can also be done with a simple callback provided as a prop to avoid Redux in this situation.

So think of this in two levels - local component state within a nest of related components, and shared state within a set of unrelated components; the latter is where Redux can help.

I much prefer (and find simpler to understand) that state is local and changes one-way. It's similar to the issue whether a language supports reference types as parameters or sticks to value types. Reference types make it easy to pass along side effects to the caller, but it can also introduce hard to understand side effects.

</comment></comment><comment><USER49> yep, let's all just get back to mutating everything everywhere and generating dom elements in arbitrary places. because it has worked so well for us in past 12 years.

i get a feeling author had no prior experience with js ui whatsoever.

</comment><comment><USER50> Not the biggest JS fan but this is ill-informed and poorly written. Sounds about right for tech blog posts at least.

</comment><comment><USER30> Some people like immutability, some don't. It's the way of life.

</comment><comment><USER51> This example doesn't fit with the React style I've seen before, where state is rarely used. This data isn't flowing ([https://lobste.rs/s/ptfoib/yes_react_is_taking_over_front_en...](https://lobste.rs/s/ptfoib/yes_react_is_taking_over_front_end#c_1z3hjq)) like I've come to expect, but one of my biggest gripes with React is that the docs are no longer very good because they haven't been comprehensively rewritten for the current design and because the only sentence in the docs to address the crucial distinction between props and state is the distinctly unhelpful:

> If you imagine a component tree as a waterfall of props, each component's > state is like an additional water source that joins it at an arbitrary point > but also flows down.

In this post's example, I would expect to see a component for an individual Person with the props name and location, then a People component storing the ordered list in props. If the app does a lot of this general "maintain a sorted list with random insertions from over the net", People would be wrapped by a higher-order component ([https://facebook.github.io/react/docs/higher- order-component...](https://facebook.github.io/react/docs/higher-order- components.html)) managing that. Otherwise there'd probably be a page-level custom component or just random stateful javascript pulling in the data and passing it down to People for rerendering. (I don't know Redux to address the second half of his example.)

It's ironic that the author advocates for immediate mode GUIs, because normal React looks and works like an immediate mode GUI with memoization. A component is a function responsible for part of the page. Its props are the input to the function and it returns a render of part of the page (possibly by rendering more memoized components). The cache is busted when props changes. There's also a hack to be used sparingly called state so that small bits of UI state can be managed at a low-level instead of in their parent component.

</comment><comment><USER52> Somehow author jumps from the problem of convenient data structures updating and immutability to Redux which solves a different problem.

There are several things about React, Redux and React based tech stacks:

1\. React requires knowledge of basics of functional programming

React looks like it's easy to pick up but if you don't know or want to learn at least basics of functional programming then it's not for you. Without this knowledge, a lot of things will be a struggle and won't make any sense. You'll mess up pretty bad. React requires the understanding of its principles which require the understanding of FP essentials.

2\. React is not a framework and does only one thing well

It does only one thing well, turning your UI into a function of data. Yes, there is a virtual DOM but it's an implementation detail and not the purpose of React. If you think about it everything which is there is needed to make that UI=F(data) possible. However, it's enough for simple apps.

Immutability isn't always needed so it's optional. It's not built into JS, you'll have to use an additional library.

3\. Building non-trivial apps requires a lot of knowledge and experience

Building non-trivial apps with React only is a pain. That's expected because the only thing it does is making a UI a function of data. It's not a framework with a complete set of tools and practices for building a whole SPA. That means you have to assemble your own tech stack for your particular task. This requires a lot of experience but lets you have the tools which are a better fit for your app.

Redux is just one of the available choices for solving the problem of complex app's architecture. It isolates state from React components. UI interaction with the outer world is behind actions. Data access is behind selectors. State mutations are centralized in reducers. This is very convenient, you always know where to look for something. Business logic part is very clear because of actions and reducers. Not messing everything up requires knowledge and discipline though.

The funny thing is React+Redux isn't a complete framework. For case, there are several solutions for writing asynchronous actions.

The main idea is React is ok to use by itself for simple things. You don't need to know much except FP essentials. Using more advanced React based tech stacks requires much more knowledge and experience.

If you don't know which of your problems React solves you don't need it.

If you don't know which of your problems immutability solves you don't need it.

If you don't know which of your problems Redux solves you don't need it.

<comment><USER46> I completely agree here. and I think if most people followed these last 3 lines, there might be what, 6 projects using React?

I find the highlighted article on Facebook's "reason" for inventing Flux/Redux very laughable. - This message unread indicator kept saying (1). And how it went away with bug fixes and came back...

Did they ever stop to realize they just had some really bad devs working on the chat app? Any re-write, whether they had to invent flux or not would have fixed that indicator. It's a false story.

<comment><USER52> Much more than six projects for sure. Nice pun though. I started using React before the hype train. I couldn't care less about Facebook's reasons but I enjoy the fact they somehow built a library which is a good fit for some of my projects.

I don't like Redux that much. All React based frameworks I like are not even written in JavaScript.

</comment></comment></comment><comment><USER53> Seems like the source of his gripes are with functional programming, not ReactJS itself.

</comment><comment><USER54> TL;DR: Author confuses Redux for React and then rants about it.

</comment><comment><USER55> It doesn't feel op have done their homework well.

You should check immutable-js.</comment>


Kurt Gödel and the romance of logic - <AUTHOR> https://www.prospectmagazine.co.uk/magazine/kurt-godel-and-the-romance-of-logic <comment><USER2> Actually, Gödel's theory is fairly accessible compared to, say, the General Theory of Relativity.

All you have to know that the process of proving a statement is a fairly mechanical, step-by-step process. At that point, "statements that can be proven true" and "statements that be proven false" are two fairly defined sets. At that point, "there are some true statements that cannot be proven true" is moderately clear.

Then you introduce the idea of a model and make the concept fully exact.

The thing to remember is Gödel himself never really liked this simple view and wanted truth to be more transcendent. He shared with Einstein the quality of not liking the results of his discoveries, perhaps a source of their friendship.

<comment><USER3> The quality of being "true" is dependent on the model one is using. One can not talk about "truth" without being in a model. (Assuming we are talking about standard mathematical logic.). A statement in a first order system is provable if and only if it is true in all models for that system.

<comment><USER4> You either don't understand the point of the theorems or are being contrarian.

In the context for the Incompleteness theorems, there are two 'kinds' of truths: a more informal kind used by all of us everyday and the mathematical kind as in, proven true under a given system.

The entire purpose of the theorems is to establish that there exists theorems in the first set that are not in the second set, while being expressable in the system. To deny the existence of the first kind of true statements ignores the entire purpose of it all.

<comment><USER3> I used the term 'truth' as used in mathematical logic. In a given model a statement can be true or false. Under a given axiomatic system a statement is either provable or not. We don't use the word "true" when dealing with statement under an axiomatic system. We do use the word when dealing with a statement in a given model.

Your third paragraph doens't make sense. In first order logic a theorem is a statement that is true in all models and is one that is provable. This is a result of the Completeness Theorem.

</comment></comment></comment></comment><comment><USER5> " He announced that he had studied the US constitution in detail, and—no doubt, forensically examining its propositions one at a time and perhaps testing it against thought experiments against wild possible futures in which the president was allowed to get out of control—he had discovered how the US could legally be turned into a dictatorship."

<comment><USER6> sadly this article skips a lot of detail on what happened during and before the hearing and how Einstein tried to coach him. The New Yorker had a much better summary on this. Here in all its hilarity:

\----

from [https://www.newyorker.com/magazine/2005/02/28/time- bandits-2](https://www.newyorker.com/magazine/2005/02/28/time-bandits-2)

So naïve and otherworldly was the great logician that Einstein felt obliged to help look after the practical aspects of his life. One much retailed story concerns Gödel's decision after the war to become an American citizen. The character witnesses at his hearing were to be Einstein and Oskar Morgenstern, one of the founders of game theory. Gödel took the matter of citizenship with great solemnity, preparing for the exam by making a close study of the United States Constitution. On the eve of the hearing, he called Morgenstern in an agitated state, saying he had found an "inconsistency" in the Constitution, one that could allow a dictatorship to arise. Morgenstern was amused, but he realized that Gödel was serious and urged him not to mention it to the judge, fearing that it would jeopardize Gödel's citizenship bid. On the short drive to Trenton the next day, with Morgenstern serving as chauffeur, Einstein tried to distract Gödel with jokes. When they arrived at the courthouse, the judge was impressed by Gödel's eminent witnesses, and he invited the trio into his chambers. After some small talk, he said to Gödel, "Up to now you have held German citizenship."

No, Gödel corrected, Austrian.

"In any case, it was under an evil dictatorship," the judge continued. "Fortunately that's not possible in America."

"On the contrary, I can prove it is possible!" Gödel exclaimed, and he began describing the constitutional loophole he had descried. But the judge told the examinee that "he needn't go into that," and Einstein and Morgenstern succeeded in quieting him down. A few months later, Gödel took his oath of citizenship.

\----

Another one: [https://www.quickanddirtytips.com/education/science/when- g-d...](https://www.quickanddirtytips.com/education/science/when-g-del-almost- took-on-the-us-constitution)

\---

EDIT: something I also missed in this piece was that Gödel developed rheumatic fevers as a child and started reading medical books with the age of 8 to learn more about the condition. He concluded that he had a weak heart :D

Gödel is really worth studying closer and this article just leaves out a lot.

<comment><USER7> Coincidentally, I'm reading When Einstein Walked with Godel, and this anecdote is in there. Such an interesting man -- he's up there with Von Neumann for historical figures I'd like to learn more about, as the work they develop is a form of first principles that a lot of modern thought is derived from.

Any reccs on books to read, more focused on their theories than their lives?

</comment></comment></comment><comment><USER8> > rescued the idea that there are truths that humans can never prove

This is a gross misinterpretation of Gödel's actual theorem that helps perpetuate irrational superstitious attitudes against science, mathematics, and logic.

What Gödel showed was that proofs are relative to some underlying axiomatic model and that for _any particular axiomatic model_ there are always truths unprovable by it.

That doesn't mean "there are truths that humans can never prove", all it means is that we have to extend our axiomatic systems in order to prove some truths. (And whether they are true or false "in reality" is another question, to be determined empirically.)

A more accurate (and just-as-click-baity) way of interpreting Gödel's theorem is that "mathematicians and logicians will always have a job".

<comment><USER9> > That doesn't mean "there are truths that humans can never prove", all it > means is that we have to extend our axiomatic systems in order to prove some > truths.

If you believe that the only consequence to Gödel's theorem is we need to "extend our axiomatic system", I do think you've missed the point.

For one thing, I think Gödel's theorem and Gödel's proof are unfortunately conflated.

Gödel's proof is lovely and elegant, and can be understood with minimal knowledge of logic, but, ultimately, all it does is provide a counter example. So when people read his proof and understand it, they tend to be unimpressed with its power because the counter example is very generic and seems an uninteresting barrier to our ability to discern "truth". But that says nothing about there may be lots of other kinds of unprovable statements.

Ultimately, Gödel's theorem tells us one absolute kernel of truth by saying all but very basic axiomatic models are necessarily incomplete. However which way you want to make the philosophical leap to connect that to our notion of "truth" seems far more up to interpretation, but it annoys me when people disrespect the theorem because they're unimpressed with the counter examples the proof constructs.

<comment><USER3> An important nitpick. His Incompleteness Theorem deals with recursively enumerable axiomatic systems. The second order Peano Axioms are categorical. That is, they have only one model up to isomorphism. It's easy to come up with a complete axiomatic system for the standard model of the natural numbers. Just take as your axiomatic system the collection of all true statements. This ins't a useful system since there is no procedure for determining if a statement is an axiom or not.

<comment><USER10> How would you be able to take every true statement as an axiom? Without proving anything I don't see how you could identify any statements as true.

<comment><USER11> Whenever you have a structure M of some language L you can take the so called complete theory of the structure, denoted Th(M), which is just the set of all L-sentences true in M. In particular if L is the language of PA and M are the standard natural number with the standard operations Th(M) is a theory called true arithmetic. This theory is complete (that's because Th(M) is always complete) and clearly enough to talk about the integers, but it escapes Gödel's theorem since it's axioms are not recursively axiomatizable.

You seem to be confusing "true" and "provable", as far as first order logic is concerned those are equivalent (by another theorem of Gödel, the completeness theorem), but the first in defined in terms of models and the second is purely syntactic

<comment><USER12> You seem to be forgetting that constructive truth means provability.

Also, it doesn't seem right to use the informal "take" when the object in question is not computable.

<comment><USER11> I specified I'm working in standard first order logic. And I'm not sure what do you mean with the informal take.

Also intuitionist logic is not my area, but isn't it divided in inference rules for provability and (Heyting or Kripke) semantic for model theory and truth just like FOL?

<comment><USER12> You may be working in classical logic, but that doesn't mean the parent poster is. You asserted the parent poster seems to be confused, but what the parent poster said makes sense in a constructive setting. Please see my other comment:

[https://news.ycombinator.com/item?id=18756974](https://news.ycombinator.com/item?id=18756974)

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER13> Anyone interested in this article may also be interested in this discussion from a while back: [https://news.ycombinator.com/item?id=18115696](https://news.ycombinator.com/item?id=18115696)

Also of interest is Godel's AMS Gibbs Lecture, which unfortunately I have not been able to locate on-line. It can be found in Volume 3 of Godel's Collected Works, alongside his paper / lecture notes on closed time loops in general relativity.

</comment><comment><USER14> The biggest qualm that I have with the example for the incompleteness theorem, is the use of two-valued, Boolean/Aristotelian logic, in which "not true" automatically becomes "false".

If you allow the use of a three-valued logic, for example, with (true, undetermined, false), the Gödel statement, "I am not provable" amounts to saying "My provability is false or undetermined".

The same problem occurs in Russell's paradox, "Does the set of all sets that do NOT contain themselves, contain itself?"

The use of the NOT-operator is degenerated in a cyclic group Z2. It is the only situation in which the NOT-operator is not set-valued.

In my opinion, if the "isProvable()" predicate allowed for multi-valued logic, Gödel's incompleteness theorem would look much less paradoxical. In other words, the paradoxical outcome could simply be the result of Boolean shoehorning.

<comment><USER15> The incompleteness result does not even mention "true" and "false". It says that "there are statements of the language of F which can neither be proved nor disproved in F." Whether those statements are true/false is left unsaid.

</comment></comment><comment><USER6> > _The theoretical physicist and mathematician Roger Penrose, for example, has > argued that Gödel's theorem shows that "Strong AI" is false: our minds > cannot be computers, and that by extension the intelligence of computers > will never fully replicate them._

Note that there are camps that have been disputing this (e.g. McCullough's Objection):

[http://www.deepideas.net/godels-incompleteness-theorem- and-i...](http://www.deepideas.net/godels-incompleteness-theorem-and-its- implications-for-artificial-intelligence/)

and

[https://www.iep.utm.edu/lp-argue/#H3](https://www.iep.utm.edu/lp-argue/#H3)

sadly, I'm not even close to figuring out if the Roger-Penrose argument is valid. Nada, not even a gut-feeling!

</comment><comment><USER16> BBC podcast on the subject, interesting for historical background.

[https://www.bbc.co.uk/programmes/b00dshx3](https://www.bbc.co.uk/programmes/b00dshx3)</comment>


Ask HN: Tips on a website portfolio? - <AUTHOR>

I'm a current student and I've slowly put together a number of websites - class projects, personal projects, contract work, etc. What is the best way to display these for prospective employers? I see many of you have personal websites, what other things have you all done?<p>Edit: I was wondering much more basic things. For example, what mediums do you even use for a portfolio? Github? Can you just forward them a list of URLs? <comment><USER2> Make the portfolio reflect the job you want to get. Show your best 12 to 20 — put the best first, and the second best last. Most students don't have great real world projects to show off — so if those are second rate don't put them in. Give a one line description of each project: Don't worry about tech buzzwords so much as saying what problem you were solving. Don't be afraid to re-work and re-touch old projects. And lastly be ready to customize your presentation for a specific pitch.

</comment><comment><USER3> I just went through a job search a couple of months ago. The big thing to remember is everybody has like a ten second attention span. So you really need to limit what you say. Make sure the B items in your portfolio aren't stealing attention from the A items.</comment>


Toronto is gathering cellphone location data to find people congregating - <AUTHOR> https://business.financialpost.com/technology/city-of-toronto-gathering-cellphone-location-data-from-telecoms-in-bid-to-slow-spread-of-covid-19-tory <comment><USER2> You can dislike the behavior all you want, and call it out as being immoral and stupid. You can fine people if they take risks that cause harm to others. But if you get in the way of the freedom to assemble and communicate like human beings without being _straight up spied on_ that, to me, is crossing a very big red line.

Anyone who believes for a moment that the information they collect can't be deanonymized is deluding themselves. This is a precursor to some straight-up Orwellian evil.

<comment><USER3> No one is forcing you to carry a cellphone, and a cellphone really isn't an inalienable right. There's a pretty easy solution to this problem if you don't want to tracked. I'm not in support of what they are doing, but its a bit different than if it were being done with a government mandated biochip or ankle monitor rather than with a phone you voluntarily carry

<comment><USER4> Given that a cellphone is necessary for many people to conduct their daily lives/business now[0] and that necessity is increasing over time, your argument quickly boils down to "no one is forcing you to take part in society". Sure, it may true, but what a terrible standard to set or defend.

[0] e.g. If I didn't carry a cell phone, I would be fired because I am expected to be reachable while away from the office. This is not a unique situation.

<comment><USER5> > If I didn't carry a cell phone, I would be fired because I am expected to be > reachable while away from the office. This is not a unique situation.

I would argue that this is unique or at the very least, the minority of positions.

Only here to say that it's your choice to engage with an employer who makes that decision for you. In other words, find a new job.

<comment><USER4> That is just a single example from my personal situation and in my own circle of friends, I am not alone in that expectation.

We could look at another example, say the increasingly widespread use of mobile payments in China. How about people living in areas without other major services who need to keep in touch with family/friends/emergency services?

Regardless of the other situations, you're also making the assumption that I and others can just immediately find other employment. With the current massive number of layoffs, alternative employment prospects are dropping for a hell of a lot of people. So if this is the only job I can get right now, is it reasonable still to say that I can 'easily' give up my cell phone, for the low low price of not having enough money for rent/mortgage and food?

<comment><USER5> > Regardless of the other situations, you're also making the assumption that I > and others can just immediately find other employment.

Losing your job because you're "off the grid" is always terrible. This is not an excuse just because now there is more serious ramifications. Perhaps it's just now extra terrible.

</comment></comment></comment></comment></comment></comment><comment><USER6> I am Canadian, and I considered myself an advocate of privacy up until COVID-19 made me realize I'd pretty much give up all my civil liberties if it meant my immunocompromised parents were less likely to fall ill and potentially die as a consequence. Trudeau can enact marshal law for all I care, I just don't want my folks to die.

<comment><USER7> I think you have to accept that your parents are going to die one day, whether we contain COVID-19 or not. But you and your (future?) kids are going to have to live with the political consequences of this crisis for many years to come.

<comment><USER6> The other side of that argument being that people in the future can always fight for their rights, whereas we can never get back lost time with our loved ones.

<comment><USER8> Such a selfish argument

<comment><USER6> You're absolutely right. Thankfully, in reality, I don't think the measures taken will be as strong as dismantling our civil liberties. However, if the dichotomy was either our civil rights at large (expand this to the economy, whatever you want) or the lives of the sick and elderly, I'd opt for saving human lives every time. I even think there is a Trek episode about this. Not very utilitarian of me I realize, but it's a trade off I'd make without hesitation.

</comment></comment></comment></comment></comment><comment><USER9> >totally anonymous cellphone location information

that's a bold claim

[https://en.wikipedia.org/wiki/AOL_search_data_leak](https://en.wikipedia.org/wiki/AOL_search_data_leak)

|[https://en.wikipedia.org/wiki/Netflix_Prize#Privacy_concerns](https://en.wikipedia.org/wiki/Netflix_Prize#Privacy_concerns)

and so on and so forth, these data sets are hard to truly anonymize

<comment> ctrl-j Only because they capture a lot of data and keep the row level information.

If you just grabbed clustered coordinates without any device information there wouldn't be enough data to be able to reconstruct identity information.

<comment><USER10> There's a lot of ways it can go wrong though:

\- If they provide a unique ID with each coordinate. Now you can deanonymize by correlation

\- If they provide a coordinate for every used in the system. Now you know where everyone is

\- From the above, if the data is presented in frequent intervals, you can correlate coordinates with last know coordinates and start drawing paths

I'd be comfortable if the request is "give us a coordinate for every area that has more than N users in it" for some large N. Filtering out apartment buildings shouldn't be too difficult.

<comment><USER11> > every useD in the system

Funny typo, or perhaps not? Reminds me of Stallman talking about Facebook and switching out "users" with "useds".

</comment></comment></comment></comment><comment><USER11> Imagine this happening under normal circumstances. Now that they did it, the threshold will be lower to do it again next time, when they see it fit.

The future will show, whether it will be appropriate, when they do it next time.

<comment><USER12> People might accuse you of using a Slippery Slope fallacy, but in reality they're just establishing a precedent. And the justification will get weaker each time.

<comment><USER11> You are right, not water tight argumenting on my part. I wonder, whether slippery slope is OK, if the action in reality can be seen as a slippery slope that society is probably sliding down.

</comment></comment></comment><comment><USER13> I think part of the problem is that the hacker news community has to accept that we are in minority in terms of opinion on this. The general public is either okay with it or doesn't care. Anyone who has tried to explain this to a non-tech person knows what I mean.

</comment><comment><USER14> How long do they get this information, and who has access to it?

The privacy culture in Canada is different from that of the US or Germany, with some major privacy players today having close law enforcement and intelligence community backgrounds.

For example, the executive director of the Canadian Centre for Civil Liberties in the article also happens to be a former provincial attorney general responsible for some pretty hysterical anti-civil liberties regulations in regard to law enforcement discretion (automatic roadside vehicle seizure for speeding, "pit bull" ban), in addition to his ideological anti-firearms advocacy in a country with some of the strictest and most byzantine gun laws on the planet. The federal privacy commissioner is a former federal assistant deputy attorney general which arguably makes him a member of the intelligence community.

Regardless of your political leanings, it's hard to make the case that former prosecutors and intelligence community members make credible privacy advocates.

In Canada, there is a popular contempt for the notion of "freedom," in the American sense, as the concept implies there may be limits to bureaucratic remit and to the total sovereign power of the crown. Such freedom is a myth only the young or uneducated believe in. There are a few rights carved out of the total dominion of the crown, but those are exceptions. It's a very different culture here.

In terms of using cell tracking data to manage the pandemic, the case for what difference the data would makes needs to be clearer. Leveraging the crisis to get the data ("squeezing the toothpaste out of the tube") is standard bureaucracy playbook here, and everyone should be skeptical of it.

"Because crisis!" is not a reason or justification people should accept for anything, and we should push back on anyone who seems to be leveraging hysteria and who won't provide a sound and transparent rationale with clear limits.

</comment><comment><USER15> As the article says, this isn't legal, and violates Provincial Privacy law.

<comment><USER16> These laws have been violated by DOOH companies for the past decade. Yet no one really talks about the private sector tracking people without consent.

[https://news.ycombinator.com/item?id=22685912](https://news.ycombinator.com/item?id=22685912) [https://en.wikipedia.org/wiki/Out-of- home_advertising](https://en.wikipedia.org/wiki/Out-of-home_advertising)

<comment><USER17> People talk about the private sector violating privacy all the time.

The gov't doing it is even worse since they have the power to put you in jail and take all your possessions if they want to. Private companies don't.

</comment></comment></comment><comment><USER18> Similar / more invasive product being sold by NSO Group (yes, that NSO Group) to a dozen governments around the world:

[https://www.bloomberg.com/news/articles/2020-03-17/surveilla...](https://www.bloomberg.com/news/articles/2020-03-17/surveillance- company-nso-supplying-data-analysis-to-stop-virus)

</comment><comment><USER19> It should be noted that the city came out and denied that this was actually happening or that they've received any data

[Paywalled] [https://www.theglobeandmail.com/business/article-toronto- may...](https://www.theglobeandmail.com/business/article-toronto-mayors- office-denies-use-of-cellphone-tracking-data/)

<comment><USER20> Yeah Tory denied it on live TV as well.

Some things to be aware of are that Tory was the CEO of Rogers previously. Maybe he knew which data they have available and since it was a company owned by a family friend he could get whatever he wants.

Michael Bryant while allegeldy drunk rammed a bicycle off the road on purpose (self-defense) and killed the guy. His wife was in the car as well and they got separated a few months later. He was also the previous Attorney General in Ontario.

</comment></comment><comment><USER21> It feels like everyone here is treating it as an all or nothing thing. People are acting like if we allow the government to do this, then the next step surely can only be total state surveillance. Can't we come up with some reasonable balance where we can give up some privacy during extreme situations, but have strong safeguards in place to keep it emergency only?

<comment><USER22> If you allow a precedent to be set it can be very difficult to get the genie back in the bottle...

</comment></comment><comment><USER23> I am finding it very interesting to read the disparaging reaction to this measure by the Canadian government, and the reaction to a similar measure taken by the Israeli government.

[https://news.ycombinator.com/item?id=22592168](https://news.ycombinator.com/item?id=22592168)

</comment><comment><USER24> They should have taken timely precautions instead of trying to go all out after they found out the cat was out of the bag. I find it apalling that they took forever to cancel Chinese/Iranian/Italian flights, but now it's time to disregard all civil liberties.

</comment><comment><USER25> I do not have a cell phone; since some people do not have a cell phone (or may temporarily have loss of communication for whatever reason, including airplane mode, loss of battery power, leaving it at home, etc) it may not work. But what if someone has more than one cell phone?

</comment><comment><USER26> Obscene, the upsides of this are nothing compared to it's impact on freedom and in normalizing such behavior.

I have trouble comprehending how governements (and people) think so little of individual freedom that as soon as a crisis hits their first instinct is giving it all up

</comment><comment><USER27> > QA: What, as an ordinary citizen now, frightens you most, would you wish, > most could happen, to stop the panic at least.

> YH: I think the worse thing is the disunity we see in the world, the lack of > cooperation and coordination we see between different countries, and the > lack of trust, both between countries, and also between the population and > the government. ¶ This is basically the payday for what we've been seeing in > the last few years, with the epidemic of fake news, and with the > deterioration of international relations. ¶ If you compare this for example > with the 2008 financial crisis — which is of course a crisis of a different > kind, but there are similarities — in 2008 you had responsible adults in the > world which took a leadership position, rallied the world behind them, and > prevented the worst outcomes. But over the last four years basically we've > seen a rapid deterioration of trust in the international system. The country > which was the leader previously, both in the 2008 financial crisis and also > in the last big epidemic, the Ebola epidemic in 2014 — and that country is > the United States — now it is not taking any kind of leadership position. > Actually since 2016, the current administration has made it very clear that > the US has resigned its role as world leader, it made it very clear that the > US has no longer any friends in the world, it has only interests. And even > if now, the US — which is not doing so far — but even if it will try to > assume a leadership position, nobody would follow a leader who's motto is > "Me first." ¶ So what really frightens me is the lack of leadership and > cooperation, and what people should realize, is that the spread of the > epidemic in any one country threatens the entire world because of the danger > that if we don't contain this in time, the virus will evolve — that is maybe > one of the worse problems with this kind of epidemic — is actually a rapid > evolution of the virus. We saw it before with the 2014 Ebola epidemic. It > actually started, the Ebola epidemic started, with one genetic mutation in > one virus in one person in West Africa, which turned Ebola from a relatively > rare disease into a raging epidemic, because this single mutation increased > the contagiousness of the virus four times. ¶ Now this could be happening > right now, somewhere in Iran, or in Italy, or in anywhere else, and wherever > it happens, it endangers the entire world. ¶ Humanity needs to close ranks > against the viruses.

Yuval Harari then goes on to describe the second thing that scares him the most: The rise of authoritarianism through governments taking advantage of peoples' fear about the virus.

[https://www.youtube.com/watch?v=EwusbaOFr2Y](https://www.youtube.com/watch?v=EwusbaOFr2Y)

</comment><comment><USER28> Jokes on them.

Rogers struggles to make/receive phone calls during peak hours for the past week.

</comment><comment><USER29> As does Israel, as does Norway.</comment>


Charts About Climate Change - <AUTHOR> http://www.theatlantic.com/technology/archive/2012/11/5-charts-about-climate-change-that-should-have-you-very-very-worried/265554/

<comment><AUTHOR> If you accept even the possibility that it may already be too late to prevent global war, this talk by David Deutsch is well worth the time.

[http://www.ted.com/talks/david_deutsch_on_our_place_in_the_c...](http://www.ted.com/talks/david_deutsch_on_our_place_in_the_cosmos.html)</comment>


CAD program using GUI, procedural programming and inheritance - from 1963,  - <AUTHOR> http://www.youtube.com/watch?v=mOZqRJzE8xg

<comment><AUTHOR> here is the wikipedia page for the program: <http://en.wikipedia.org/wiki/Sketchpad>

Truly impressive and lightyears ahead of its time.

<comment><USER2> Beautiful

</comment></comment><comment><USER3> alan-kay: "how could you have possibly done the first interactive-graphics, the first non-procedural programming language, first object-oriented software- system all in 1 year" ?

ivan-s: "i didn't know it was hard" !!!</comment>


Is OpenTable Worth it? - <AUTHOR> http://incanto.biz/2010/10/22/is-opentable-worth-it/ <comment><USER2> One thing I've noticed about OpenTable is that usually when I can't make a reservation through their service (e.g. when it says there are no available times left) I can still call the restaurant and be accommodated. After doing this a few times now, it's made me wonder about the value-added for the restaurant-goer as well as for the restaurant. It seems like in these situations, OpenTable is just getting in the way of the restaurant-customer relationship to the detriment of both.

<comment><USER3> this is mostly speculation, but my guess based on experience is that most places only allow opentable to book one or two tables per time slot. i've been rejected several times by a few places and instead walked in to a not particularly crowded place.

<comment><USER4> Having found several restaurants with no OT availability to have reservations available upon calling, I think this is the case.

I'm pretty sure a lot of restaurants set aside a certain amount of tables/times as OT inventory.

</comment></comment></comment><comment><USER5> You know, Yelp should cut off its relationship with Opentable and just jump into this business itself and charge either no fee or a nominal fee to restaurants (basic vs. pro).

This would solve a big problem for Yelp; if Yelp could save restaurants from the crushing cost of reservations, restaurants would be more inclined to forgive Yelp for allowing us "bored, jobless layabouts" to trash them in a public forum ([http://blogs.westword.com/cafesociety/2010/11/people_hate_us...](http://blogs.westword.com/cafesociety/2010/11/people_hate_us_on_yelp_the_bac.php)).

<comment><USER6> The reason they have a special relationship is because Benchmark Capital is a investor in both.

It is a overvalued company when it IPOed and especially now since some of the metrics are ridiculous.

Its P/E ratio is 127.5. Time to short Open.

</comment></comment><comment><USER7> The crux of the argument made by the post is that a restaurant makes $10 profit on a $200 4-person cover yet OpenTable takes $10.40 for that booking _(I want to call BS on those figures but lets ride with it)_

In an earlier part of the piece, the author states that "[his restaurant owner friend] believes that if he stops offering it, his customers will revolt and many would stop coming to his restaurant. So he keeps paying, but carries a grudge and wishes for something better."

What's the problem if the customers stop coming if by servicing their business via OpenTable you either only break-even or even make a slight loss?

If that is the case, it's not worth servicing the customer in the first place.

GroupOn does this too - you loose money by servicing the business obtained via GroupOn, but the idea is that future business from each customer will be at market-price thus off-setting the initial customer acquisition cost (CAC) as future CAC is $0.

The difference here is that OpenTable customers continue to book via OpenTable, thus each booking creates further CAC that doesn't go down.

What I find sad is that for all the long winded post on this subject, the author gives no concrete quantitive specifics of the OpenTable tariff structure so everyone can get a clear understanding of the issue.

<comment><USER8> From OpenTable's info, the booking per diner is $1.00 if done via OpenTable's site, but only 25 cents per diner if done via the restaurant's site. This suggests certain approaches....

<comment><USER7> Yes, but that doesn't match what the post author says based on his figures.

It could be opentable cost = booking fee per diner + setup costs + monthly fees. I'd like to know more.

<comment><USER8> His $10.40 is the cost for an "incremental" 4-top, ie a group that wouldn't have booked without coming in via opentable since they were new to the place. Given that even OpenTable's info estimates only 50% of the bookings would be incremental, and that that's likely an overestimate in OT's favor, I can imagine $10.40 may be about right.

4-top via OT = $4

1/2 4-tops from OT "incremental", cost is now $8 per incremental.

If it's really 2/5 4-tops from OT are incremental, we're at $10 per incremental.

</comment></comment></comment></comment><comment><USER9> This is an interesting opportunity to profit from. This company has massive expectations baked into it's stock price (NASDAQ: OPEN), trading at over a hundred times earnings. It's being massively shorted by the hedge funds. Combine the fact that there's relatively no barrier to entry with the rumors that their customer base isn't very satisfied makes for a huge opportunity to profit in the short/medium term.

<comment><USER2> > It's being massively shorted by the hedge funds.

Just out of curiosity, who are "the hedge funds" and how do you know this? Is there some way of researching who is shorting what?

<comment><USER9> I've been following this company for awhile from a financial perspective, which is how I know. The most prominent hedge fund to short has been Whitney Tilson's T2 Partners', but they're just one among many -- 35% of the floated stock is short now.

I don't know of any way to research who is shorting what other than SEC filings. Mutual/Hedge funds have to report this information on a quarterly basis.

<comment><USER10> There are a few common signs in institutional shorting, that may be used to determine short interest in absence of official filings, share counts, or other data, but they mostly require a low-volume market to see clearly:

The accumulation/distribution line is strongly inverse to price(It's an indicator based on buy/sell volume. Normally, an accumulation precedes price rise while a distribution is in tandem with a selloff. When shorting, the long-term trend goes the opposite way - there's more buying than selling, yet price consistently drifts down. Caveat: being based on a composite of price/volume/time, it's not totally accurate and even changes dramatically across time scales. )

Market-maker quotes on Level II behave unusually in response to buys or sells(on small, low-volume stocks in particular, MMs are sometimes colluding forces and will "paint the chart" with tiny trades that, in a fair market, would not affect quotes).

Message boards for the ticker symbol suddenly see the appearance of paid bashers who will repeat negative news multiple times a day.

\---

With a lot of heavily shorted stocks, the company is fundamentally weak to begin with. However, even a very solid company is vulnerable if it's starting from a low market cap. So - in general - take the appearance of a large short position as a sign to either join them or get out. To see a short squeeze the float has to be very tight, and the stock needs to be forced into a speculative frenzy with good news or just big buyers. The long-run odds always favor companies failing.

OPEN is a big-board stock with a large valuation and volume right now, so I wouldn't expect shorts to be obvious enough that you can see these indicators. As well, their dirtiest tricks are reserved for pennies. They have the lowest risk there, since market cap is so small that they can absorb most price rises.

</comment></comment></comment></comment><comment><USER11>
        "[R]estaurants find that they themselves no longer own the customer relationship."

This is the dumbest thing I've read today. I am sitting in _your_ restaurant! I am voting with my dollars by choosing to show up at your establishment! If I like what you have to offer, odds are I'll be happy to give up some personal information.

If you want to know my email address to inform me of special events, or to give me a gift certificate for my birthday, then just ask me! It's not that hard.

Additionally, if I need a reservation to eat at your establishment, and you're not on Urbanspoon's Rez system or on OpenTable, you may as well not even exist. I'm not going to call you and a dozen other places looking for a last minute table. It's simply not worth my time.

<comment><USER12> _[If] you're not on Urbanspoon's Rez system or on OpenTable, you may as well not even exist._

Perhaps to you, but I think that attitude is rare. I think most people find a place where they'd like to eat, and then they choose the easiest way to make a reservation -- the difference in convenience between Opentable and the telephone is pretty small. If I'm going to spend $$ on a nice meal, finding a good place is my priority; if I need to call them or tolerate their shitty Flash website, so be it.

Personally, I rarely use Opentable: apart from the fact that they take some of the restaurant's revenue, they can also report false negatives. For at least one restaurant I go to often (Ad Hoc in Yountville), there is almost _never_ a good time available on Opentable, but there often is if you call the restaurant. Since I can't trust a "no availabilities" result from Opentable, it is easier to just call and speak to a live person.

<comment><USER11> Yes, that is my opinion. I don't doubt that I'm in the minority. Still, for me, OpenTable or Rez support is critical. My girlfriend and I will routinely pick a place to eat on a Friday or Saturday 30 minutes before we intend to eat. I don't like having to call a half-dozen places in order to get a table, and I wouldn't have much choice without these systems.

If the restaurant is unable or unwilling to report their true availability, then the value of OpenTable decreases dramatically.

<comment><USER13> > My girlfriend and I will routinely pick a place to eat on a Friday or > Saturday 30 minutes before we intend to eat. I don't like having to call a > half-dozen places in order to get a table, and I wouldn't have much choice > without these systems.

It never even occurred to me to try and make reservations _30 minutes_ before I want to go eat. Interesting concept. I usually just aim to only go places where I know I'll be seated very quickly, or else get take out.

</comment></comment></comment></comment><comment><USER14> The bottom line is squeezing an industry with 5% profit margins cannot possibly last. This is the basic point I took from the author's extremely well written and obviously experience-infused post.

5% margins??? Seriously???

My sympathies to anyone in this shithole of an industry. That's impossible. No wonder all the restauranteurs/restaurant-employees I know are unhappy or insane. Or both.

</comment><comment><USER15> My sense is the point of sale aspect of OpenTable is what makes them so entrenched... it's not easy to replace the hardware, retrain staff, etc, and the article doesn't touch on this.

Is there a startup competing in this space directly against OpenTable? Is Yelp the biggest potential contender (though i can't see them getting into the POS business)? Or Google?I could see google offering android-powered POS devices...

<comment><USER16> [ with 200$ 10.1' android multi-touch devices e.g. <http://goo.gl/S5JHs> (I would suspect that wholesale costs would be closer to 100$). ]

For seeding 10000 restaurants, you would barely need a million and half dollars (not counting android app development). I daresay that you could make the interface close enough without infringing on copyright issues.

The key is to lock down a hardware manufacturer who can supply the devices with a low failure rate.

<comment><USER17> Or, spend a little more money and provide an iPad app. You get a proven reliable hardware platform plus it becomes a marketing tool - "choose our platform and you get a free iPad."

</comment></comment></comment><comment><USER18> Not long ago I placed a reservation through OpenTable, and a couple minutes after we had been seated, I got an email from OpenTable telling me the reservation had been canceled from the restaurant's end.

Now I wonder if this was an honest mistake, or a strategic cancelation to try to stiff OpenTable on the per-reservation fees. Obviously they couldn't do that with every diner who walked in the door, but maybe they could sneak a cancelation in here and there to save a few bucks.

According to this, OpenTable charges (not counting equipment and fixed monthly costs) $1 per diner.

[http://online.barrons.com/article/SB500014240529702048786045...](http://online.barrons.com/article/SB50001424052970204878604575492014259852240.html)

<comment><USER3> depends on who is dining, but that might make the type of person who is trying to accumulate opentable points mad.

<comment><USER18> I'm that type of person, which is why it bothered me and it even sticks in my mind at all now.

The reservation that was canceled would have tipped me over the threshold to get a cashback reward, so I let OpenTable know and got my points.

The restaurant wasn't very good anyway, which was a factor in my decision as to whether or not I should've taken it up with OpenTable.

</comment></comment></comment><comment><USER19> I think a good idea for the restaurants would be to add 'OpenTable' as a line item on the bill. This would get the message to customers, but may only work if a significant portion of restaurants in an area follow suit.

</comment><comment><USER20> Many restaurant websites actually put an OpenTable link on their reservations page, directing traffic there.

That makes me think the restaurant _prefers_ reservations to come in that way. They don't just see it as a secondary reservation system to bring in more customers, but the primary channel.

The added efficiency of OpenTable cannot be underestimated. Especially when trying to book something for a large group or at the last minute, being able to see availability across many restaurants in a single glance is critical. I'm not going to bother calling.

</comment><comment><USER21> "That's ultimately the most perplexing thing about OpenTable: unlike so many other Web services, this one has actually driven up operating costs, not reduced them."

How much do restaurants pay to accept phone reservations? It seems the cost comes from running two reservation systems - hiring a person to accept traditional phone calls, and paying OpenTable for the online reservation system.

</comment><comment><USER22> I think there definitely is an opportunity to remove OpenTable from the equation. Look at restaurants like Momofuku Ko's annoying reservation system, where their in-house .NET reservation system books out within 3 seconds after 10am ET for 12 seats (24 covers a night), and seat inventories are only released 6 days in advance. Momofuku almost never starts a restaurant project without it now (e.g their buttermilk American free range fried chicken and Korean fried chicken).

It created lot of hype by becoming the anti-OpenTable. Read about the complaints of this reservation system on NYT, Departures, etc. Major food editors still have been unable to review the restaurant simply because their inventory allows for no special favors.

Of course, anyone with Mechanize and scripting language of choice can do high- frequency reservation bookings.

However, OpenTable does have a huge following, and its followers like to redeem OT points for cash. Which is why restaurants are hesitant to remove it for customers that will only eat at OT restaurants.

<comment><USER23> How big is the part where OT is used for business, but when the OT points are cashed out folks can keep that privately? Could be hard to sway that...

</comment></comment><comment><USER24> That reminded me of a recent Paul Graham tweet:

      You've found market price when buyers complain but still pay.

<http://twitter.com/#!/paulg/status/22576762202>

</comment><comment><USER25> I've looked at how OPEN's vulnerable a couple of times. What's not covered yet in these comments are the host's notes on each diner. When I make a reso, if the restaurant has made a note about me (tips great, gets pissy about being near the kitchen/lav, hard of hearing, whatever), it comes up when I check in. Those notes are _not_ shared between restaurants.

There seems to be no global diner profile in the system and there's certainly no social aspect to figuring out where your friends have reservations or like to eat. That's where I think OPEN can be undermined. I'm not an Urbanspoon user, but I don't think they've cracked that nut either.

<comment><USER4> this gets at something i am working on right now

<comment><USER25> Let me know if i can useful.

</comment></comment></comment><comment><USER26> think that Groupon and clones will go through the same strugles. I just fail to understand how "discount only" cn be a business. it just mean someone is paying for the service and giving up their profits and customer relations.

</comment><comment><USER27> My startup <http://sexbyfood.com> provides a web-based reservation book for restaurateurs. It works on any HTML 5 browser or iPad, keeps audit trails of changes to reservations, prints a proper guest-list, has real-time activity feeds, a flexible allocation algorithm, and provides a plugin that restaurants can add to their website.

</comment><comment><USER8> From OpenTable's own data, their revenue averages $600 a month from a given restaurant. Not a negligible cost, but doesn't seem outrageous.

Probably room for someone to undercut that, but it doesn't seem that the cost of restaurants controlling their own electronic reservations systems would be tremendously lower.

But maybe if restaurants did it on a cooperative basis. Hmm.

<comment><USER28> Seems like it would be hard for a competitor to gain a foothold. But it might be possible:

Contact all the restaurants in a given area. Propose them a service similar to OpenTable. Guarantee to them a lower price and greater control. Market yourself as restaurant owner friendly.

Launch the service and advertise in the selected area to reduce costs.

</comment></comment><comment><USER19> _"it was too expensive to keep, but letting it go could be harmful."_

which means that they have probably priced their product perfectly

</comment><comment><USER29> From this consumer's point of view he's wrong in saying everyone loses.

I use Opentable a lot and I like not waiting for a table.

</comment><comment><USER30> I want to call shenanigans on the profit margin in the restaurant business being 5%... OK, shenanigans.

<comment><USER31> _Based on the 2004 Restaurant Industry Operations Report published by Deloitte & Touche LLP, average pre-tax profit margins range from 4-7% (4% for Full..._

Literally in the article summary right there on the first result of the SERP [restaurant profit margin].

<comment><USER32> I have many restauranteur friends in my country, and their profit ranges between 50% to 60%. I have trouble believing that in the USA their profit margins are so crappy. I bet there's a lot of stuff going on under the table (pun intended).

<comment><USER33> Gross or Net ? - 50% gross profit is common, I doubt you could find any developed country where 50% net profit was the norm for restaurants.

<comment><USER32> Net. I didn't say this thinking the US should have similar percentages though. This is attributed to the fact that labor costs in my country is easily one third to one half as expensive as labor in the USA. Perhaps there is also less overhead in getting ingredients. I'd understand a 10% ~ 20% percentage net yearly profit, having most restaurants in the lower bracket of course, but 4% or 5% seems extremely low to me.

<comment><USER33> It's not about labour/ingredient costs, but rather the competitiveness of the market. A healthy competitive market drives profit margin to the lowest sustainable point.

Supermarkets often have profit margins as low as 3-4%.

</comment></comment></comment></comment></comment></comment><comment><USER34> Unrelated to the article, but I'm impressed with Incanto's clean and readable layout. Most restaurant sites are an ugly mess of flash.

</comment><comment><USER35> The question is not is opentable worth it, the question is this question worth it being posted on this site, or is it just completely irrelevent drivel? I'd say the latter is true.

<comment><USER23> Excellent business opportunity is not material for HN?</comment></comment>


Deep learning nanodegree foundation - <AUTHOR> https://www.udacity.com/course/deep-learning-nanodegree-foundation--nd101 <comment><USER2> Hi all,

My name is Dhruv and I work on the AI programs here at Udacity. If you have any questions, feel free to ask them here or email me at email@example.com. I'll do my best to answer everything! You can see our curriculum in depth here: [https://medium.com/udacity/deep-learning-nanodegree- foundati...](https://medium.com/udacity/deep-learning-nanodegree-foundation- program-syllabus-in-depth-2eb19d014533)

<comment><USER3> Would you say that this program is subset of material covered in car nano- degree program?

<comment><USER2> Hi @halite,

I'd say that covers a larger breadth of Deep Learning than the Self-Driving Car Nanodegree program. For instance, this program will cover Recurrent Neural Networks, Reinforcement Learning, Autoencoding, and other Deep Learning applications not covered in the Self-Driving Car Nanodegree. In the Self- Driving Car Nanodegree, we primarily focus on Deep Learning applications in Computer Vision. Here we'll cover applications in speech, computer vision, game-playing and other areas.

<comment><USER3> Thanks this is useful info. I'm currently selected in that program and was wondering how's this different from that. I'm probably going to do the self- driving program this year.

</comment></comment></comment></comment><comment><USER4> Siraj's videos are great! I'm excited to see him teaming up with my favorite Education company and creating a new ND!

</comment><comment><USER5> This program looks promising. I have a few questions:

1)It is mentioned that it takes about 3-4 hours per week. Does this mean that the course covers not many concepts. Also are the projects like- this code is given. Add a few lines to make it run?

2)Can I submit files directly using my own laptop, or is using AWS compulsory?

3)Are these projects too - Make a network that generates songs and poems?

4)Can I get my resume reviewed by the experts like in the other nanodegrees?

It would be great if you could answer these questions. I am definitely thinking of joining this amazing course.

</comment><comment><USER6> Can you provide details on what type of computing environment will be used in the course? Will it be based on something like Jupyter notebooks, GPUs on AWS, for example?

And will be there be some type of discussion forum, like the one in the other popular deep learning course fast.ai?

<comment><USER2> Hey @pchal,

We'll mainly use Python with Jupyter notebooks and will gear the program towards GPUs on AWS. We'll focus on using Tensorflow as our main tool. There will be a discourse forum as well as a slack channel for students to interact and help eachother.

</comment></comment><comment><USER7> Insta-buy! Currently doing Hinton's Neural Networks course on Coursera. Audited it when it was first offered, but am doing the assignments, for real, this time.

</comment><comment><USER8> What's good @dhruvp, I see that we have 6 months in total to complete the course. Does that start from the time of sign up or when we actually start the course? I ask because I'd like to take advantage of the great price but I know my workload won't permit me starting for at least a month.

<comment><USER2> What's happening @king_kerr (Go Dubs). It starts from the first day of class which is Jan 20th.

<comment><USER8> Thanks!

</comment></comment></comment><comment><USER9> How much of the course is ready to go? If a person could dedicate 20+ hours a week is the material all available or would you have to wait for the material to roll out? (i.e. is this binge-ready?)

</comment><comment><USER10> The "nanodegree."

If anybody ever tried to use that as a credential, they'd waste more words trying to explain what it is, and what it's worth, than if they just told you what they actually knew verbatim.

I have a nanodegree in microwaving hot pockets. Ask me to defend its intrinsic value.</comment>


The hidden history baked into a cooking pot - <AUTHOR> https://www.nytimes.com/2020/09/14/science/archaeology-food-pots.html <comment><AUTHOR> >Interpreting ancient food practices: stable isotope and molecular analyses of visible and absorbed residues from a year-long cooking experiment

[https://www.nature.com/articles/s41598-020-70109-8](https://www.nature.com/articles/s41598-020-70109-8)</comment>


Show HN: Walkie-Talkie voice to text messenger app while driving - <AUTHOR> Our app called GelaTalk! We are developing an instant message app designed specifically for drivers. We hope to make communication while driving become simple and safe. There are more new features going on!
Like in-app radio station!
Now we are on Google Play , and we really hope someone can try it and give us feedbacks! Download from Google Play:
https://goo.gl/UNkS3M
The following is a demo video for short intro. https://youtu.be/9NOX4YG9egQ
Please let us know any comments both for the app and our video. Thanks <comment></comment><comment>--
Like us on Facebook ↓↓↓ https://www.facebook.com/gelatalk/
Follow us on twitter ↓↓↓ https://twitter.com/GelaTalk </comment><comment><USER2> Hope there is iOS version!

<comment><AUTHOR> Yes, iOS version is coming soon! Thanks for your response!

<comment><USER2> That's great</comment></comment></comment>