This is ignoring the fact that there are people who actually enjoy exchanging pleasantries. Make a list with 2 columns: 1) people that enjoy small talk 2) people that dislike small talk. Act accordingly.
The whole concept of OS integration across devices is a complete failure for Microsoft. Calling this new thing a "new OS" sounds like a failure to fulfill what the Windows brand used to mean: support across a large range of devices. Isn't Windows already supporting multiple display? Maybe not in the "tablet" sub-OS... which is clearly not up to the standard set by the "desktop" sub-OS.
Anyway, the only thing that keeps Windows relevant even today is its classic Win32 API applications. Everything else they tried to do has always been half-baked. I'm not optimist for the future of the platform.
Where are you getting that someone is calling this a "new OS"? From the article:
> The company stresses that this is not a new operating system but takes Windows 10 as you know it today and makes it more adaptable to other form factors.
Thank you for that comment. Don't get me started on "compliance". Even if you are following 100% the diet and rules (which is impossible, we are humans), type 1 diabetes is HARD. We need all the help we can get! A closed-loop system improved my quality of life a lot. I would be healthier now if this stuff was available when I was a kid.
I'm running an open source closed-loop system on my iPhone. It controls my insulin pump based on data from a continuous glucose monitor. Those of us that do this don't do it blindly. We see the blood sugar fluctuate and can react if something goes wrong.
Many parents use tools to do this monitoring remotely for their child's system. I believe that if you have access to the source code and possess the knowledge to understand it and debug it, the improvements to the child's life are greater than the risks you take.
The sentence about "emotions and activities" is a little misleading. It reacts to the data from the CGM. But yes, blood sugar changes with emotions and activities. That's the life of a type 1 diabetic, no matter if you use a closed-loop system or not!
I'd hate for the kid to be weeping over Titanic and get od'd with SUGAR.
This is not one of the weird things about Javascript. When you use a function (like map), always check the documentation to know its behaviour and don't assume it's similar to some similarly named function from another language. End of story.
The article makes it seem like the US is where people work the most. It is not. The selection of countries make their graph misleading. See https://en.wikipedia.org/wiki/Working_time
I am working on a compiler for my new language. I went from learning about Yacc at the university (reaction: disgust) to discovering PEG (reaction: I should build my own parser generator!) to wisdom (reaction: just write the damn thing by hand and be done with it!)
I have a few basic reasons why I now think parser generators are a mistake for my purpose:
1) It is hard to learn all the details of a particular parser generator that you need for a complex parsing project. 2) The mix of grammar and semantic actions one has to come up with is ugly and complex. 3) The output is both ugly and hard to debug.
The most complicated part of a compiler is not recognizing good input, put doing something with it. A hand-written recursive descent parser can be a thing of beauty and simplicity that increases the joy of working on the meat of the compiler, that is semantics!
Parser combinators for lazy streams can be written as recursive descent and perform as, more or less, generalized LR parsing (exploring all tree branches "simultaneously").
It is easy to add syntax error position reporting, also it is easy to add syntax error corrections. All this can be done in under a day.
For me it offers good things from both worlds - declarative specification of parser generators and easy modifications from "parse damn thing by hand".
I actually encountered one case where that approach shines incommensurably: supporting old languages like VHDL. VHDL fits every parser formalism almost without seams but still has one place where you cannot do things either efficiently or elegantly: character literals and attributes. 'a' is a character literal, a'a is an invocation of attribute a on the object a. The ambiguity is in the lexing level, needing feedback from parsing level. Usual parsing tools cannot do that good enough, with parsing combinators it is trivial.
