Quote: "I am not a programmer, so if anything stated above is incorrect, please, please send me corrections. I would also greatly appreciate any clarifying comments, which were one of my primary motivations for writing this piece." Essentially a bunch of nonsense, in other words.
Google’s not-so-secret new OS
211–220 of 561 posts
Re: Google’s not-so-secret new OS
#212Earlier quoted context omitted.
I would say that Google is trying to replace JavaScript with dart in any way they possibly can. The reason is simple, JavaScript is an open standard, dart is owned by google. Their reasons that "dart is better" is the typical google koolaid before they attempt a market takeover. As we've seen over and over with Android, chrome, and AMP especially. Google loves to make glass house open source projects you can't touch.…
JavaScript sucks because it has a weak standard library, ugly syntax, and its monopoly in web development has the industry stuck in a state of mediocrity, in my opinion. I have a VERY hard time believing that the apex of engineering intelligence and ingenuity is found in JavaScript. Also, as much as I love Elm, for instance, languages that transpile to JavaScript are just lipstick on a pig, and do little to solve the…
I agree with you that JavaScript sucks balls in far more ways than is reasonable for such a widely used language. The design is seriously shit when compared directly to really any popular language, even PHP.
I disagree with transpilers not being a reasonable answer. Eventually JavaScript will be okay to work with, some day. Until then, transpilers offer nearly unlimited freedom in redesigning the bad parts of the language while maintaining 100% fowards and backwards compatibility. It's really as good as it can get.
Since they compile down to a Turing complete language there's really no limit to the heaps of dog shit they can abstract away. Historically, c++ is nothing more than an insanely complicated C preprocessor and it has more than proven that such a strategy can be viable long term. In fact, the first c++ compiler made, cfront, is still available and literally outputs raw C code from c++.
Typescript is easily my favorite since it's designed to compile down to very human friendly JS. Getting typescript out of your stack requires nothing more than one last compilation with optimizations turned off. Unlike most transpilers (looking at you babel) the output JavaScript uses standard JS workarounds like the crockerford privacy pattern for classes. This gives typescript fairly practical fowards and backwards compatibility. You can always target output to a newer version of js or convert your codebase out of typescript back to js at any time.
If it catches enough traction, browsers will begin implementing native typescript parsing since it offers many potential performance optimizations on top of what js is capable of. At this point you just maintain your typescript codebase and use some library to give your legacy clients some transpiled J S on the fly.
If typescript gets enough adoption it will fix JavaScript for good, in the same way the original c++ compiler (which just transformed to c) led to native support, so I'm really rooting for it.
Re: Google’s not-so-secret new OS
#213Earlier quoted context omitted.
I don't know. I think many "tablet" apps would work fine on the Surface 4 (if they got scaling right). I still think touch screens is the future - also on desktops (there either in tablet form or "drafting table" form). I think editors more like acme and less like vim might rise up. Along with new input types like the power bar and surface wheel.
> I think editors more like acme and less like vim might rise up. Acme, and anything like it, would be completely horrendous on a touch interface. I use it regularly (although I find that I prefer Sam). Edit: Then again, I have touchscreeens on many of my laptops. I don't find them useful. With the exception of drawing art, I wouldn't miss them if they disappeared.
I'm no so sure about "anything like it". A pen for easily selecting text, a one-two-three finger tap and/or a wheel/secondary input might work with a similar interface to ACME?
Re: Google’s not-so-secret new OS
#214Earlier quoted context omitted.
I remember two issues with Java Applets: * Java itself was slow for a long time * The Browser would hang while loading an Applet The first is no longer an issue. They can just use a modern just in time compiler and it wont run slower than Java on Android. Chrome already has one to deal with JavaScript powered Web 2.0 applications. The second was as far as I can tell an API issue. Applets would block everything by def…
You missed the biggest issue: "write once, mediocre everywhere." Windows, Mac, and X were all different, and Java Applets were necessarily bad at emulating all of them. While there are fewer Unices today, there are more GUIs, and cross-platform apps suck at least as much.
I never understood the need to "emulate" all of them. Linux has always been a mess of tools written against different UI styles ( GNOME, KDE, MOTIF, ... ), Microsoft also reinvents its UI with every release leading to outdated application UIs and I don't know how consistent Apple was. I think the best you can do is choose one and stick with it, its not like most websites look and feel native.
Re: Google’s not-so-secret new OS
#215Earlier quoted context omitted.
> Maintaining existing software for customers costs handset manufacturers $$$, and disincentives consumers purchasing new phones (their cash cow). Maybe Google should split play store/app ad income with manufacturers, adding some incentives (50/50 profit split for phones on latest Android, 20/80 for one trailing major version - and then nothing. Or something along those lines). That might have the added benefit (for…
Unintended consequence #1: phones that are too slow to adequately run the latest version will be force-upgraded Windows-10-style even if it degrades the user experience.
Well, maybe be more lenient on trailing versions if, and only if there are timely security updates?
I'm not sure the alternative is much better - lots of unpatched insecure phones in use?
Re: Google’s not-so-secret new OS
#216It bothers me that Google does not seem particularly interested in doing the one thing that would make their Android platform absolutely dominant: Allow Chrome to run Android apps on Mac and Windows. Google has already done 90% of the necessary work by adding Android apps to ChromeOS. Two and a half years ago it created "App Runtime for Chrome" which demonstrated that Android apps could run on Windows and Mac in a li…
There are products that already allow the running of Android apps on Windows: http://www.greenbot.com/article/3129740/android/the-best-pro...
I've never tried it or seen anyone do it though.
Re: Google’s not-so-secret new OS
#217Earlier quoted context omitted.
Not totally. We support a number of java applets at work. The clients still take "way too long" to load and feel bloated. "Way too long" is a subjective measure based on the current hardware/OS. For a JVM to not feel slow it would have to speed up relative to itself...and I haven't seen them do that.
If it's specific apps, usually it is just bad coding. 'Enterprise Java' style coding where performance is not even tested for, let alone designed into the algorithms. Usually culprits are things like downloading multiple data files in a single threaded block, or insanely deep object graphs with thousands of memory fetches per real operation. That's not really anything to do with the technique (code in browsers) or th…
They're not really enterprise apps. They're just betting odds displays. But I hear you on the criticism of enterprise software still. I just don't think it's the thing here.
Re: Google’s not-so-secret new OS
#218Earlier quoted context omitted.
You may "definitely need" a universal OS but I'm far from convinced I do. I don't buy that a finger and a mouse/trackpad pointer are equivalent input devices. One obscures the display and is imprecise. The other, well, isn't. I'm fine with a different server OS than desktop. I see no compelling reason why I need a single OS for all of my personal devices.
You listed windowing/UI concerns. And, while they may commonly come bundled with the OS, they're not the same thing.
They're a platform concern.
Not only does the OS UI reflect the input method, every single application you run does as well. A touch-optimized application will be clumsy and primitive when using a mouse; a mouse-optimized application will be miserable when using a finger.
If an application can be written once for both, often it'll be a poor compromise or only properly support one of the two input methods.
Look at how awful early Java "write once run everywhere" applications were. Yes, some of that was the Java platform itself, but developers were given the opportunity to ignore platform-specific UX concerns and many eagerly embraced it.
Re: Google’s not-so-secret new OS
#219How credible is this source? I don't understand half the decisions outlined in the article. > I also have to imagine the Android update problem (a symptom of Linux’s modularity) I seriously doubt the Linux kernel is anything but a minor contributor to Android's update problem. Handset developers make their money by selling physical phones. In two years, your average consumer probably doesn't care if their device is s…
> I seriously doubt the Linux kernel is anything but a minor contributor to Android's update problem The Linux kernel is at the very heart of Android's update problem - not because of "modularity" but because it lacks a stable ABI. Because of this, Android requires handset makers and SoC manufacturers like Qualcomm to provide updated drivers; these parties are perversely disincentivized to do so as they would rather…
> The Linux kernel is at the very heart of Android's update problem - not because of "modularity" but because it lacks a stable ABI.
What are you referring to when you say the Linux kernel ABI is not stable? I ask because the A in ABI means application, and Linux has maintained a consistent ABI for decades.
I have a suspicion that you're trying to suggest that in-kernel interfaces be kept rigid and unchanging to satisfy some unspecified number of out-of-kernel driver developers. The simpler solution would be for out-of-kernel driver developers to get their code up to quality and merged into mainline so that they'd be ported automatically whenever there's an in-kernel api change.
Re: Google’s not-so-secret new OS
#220Earlier quoted context omitted.
You missed the biggest difference: Chrome is the same everywhere.
So were Java Applets with AWT. Users hated that, so Sun tried PLAF, a half-assed emulation of each platform. That didn't work either, so Applets died. If Chrome manages to provide better versions of most applications on most platforms, it may win. Otherwise, people who use those applications will hate it with the heat of a thousand Suns, and it will go the way of the Java Applet.
> So were Java Applets with AWT. Users hated that, so Sun tried PLAF
Uh, Java AWT was the native toolkit. Swing was the non native UI with the ugly METAL default Look and Feel. There are some nice custom Look and Feel implementations that don't try to emulate a platform, I think Matlab uses one for its UI.