341–350 of 561 posts
Earlier quoted context omitted.
I have nothing constructive to add aside from that I appreciate the simple uncluttered design of your blog. The typography and glasses logo are very pleasing to my eyes as well. Good luck and I look forward to reading more.
Thanks a lot! Hope you like my future articles.
Is this an actual plan of Google as a company, or is this some sort of Microsoft-style war between divisions where the Chrome team has just decided on its own that the future is based on Chrome and Dart? Also, considering the way that the ARC runtime for Chromebooks was a failure and had to be replaced by a system that apparently essentially runs Android in a container, will it really be possible for a completely dif…
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.…
Earlier quoted context omitted.
Typescript and dart are completely different animals. I can leave typescript for good by compiling to js once and it's designed to output human readable code. The js it produces will be immediately usable as javascript, and I'm totally free from the semi open language that MS controls. Dart is a different language, it has no fallback to something familiar. I don't doubt that it's many years ahead of TS in every way b…
Your worries about being locked in may have been valid 2-3 years ago (1), but things have changed a lot since: Dart has an ongoing project (Dart Developer Compiler) which has a goal, among others, to produce readable, idiomatic EcmaScript 6. That is as close to your TypeScript fallback as it can get. (2) Somebody also demonstrated Dart to LLVM compilation is possible. The language has a decent library for parsing the…
For now Js fallback is the only realistic option for running code on the web. Even if we get native typescript or dart support tomorrow we will still need to put up with JavaScript for like 7-10 years. For this reason a readable JS fallback seems like a vital feature to me at least. It's depressing but reality for the majority of web projects.
Does dart have a pluggable compiler framework similar to Roslyn or Antlr AST's? That would make it a lot easier to write your own conversions.
One more point in Typescipt's favor though... It would be a lot easier to modify the JS VM in browsers to support native typescript than dart. In my mind it's a lot more likely to happen because of this(less work)
Why can't the pure web replace apps and programs? All the pieces are almost there: hardware acceleration, service workers, notifications, responsive design... I currently "add to home screen" for most things. I edit my images online, and develop code using cloud9 ide, etc. There are few things I need apps/programs for right now, and that's improving day by day. iPhone is dropping heavily in world wide market share, b…
I take photos miles from where there's cell signal. I write code on the bus while heading to doctors appointments. The web is about as far from a panacea as you can get. It's slow, it's bloated, falls apart when you don't have a connection, useful applications die when the company dies. Were some of the midi devices I use for music "web-based" they'd have probably become doorstops decades ago. A web-based IDE would b…
The way it works is to funnel all the profits into a few huge conglomerates that benefit from exclusive access to all personal data and train users to never depend on anything that isn't a core product of one of these conglomerates.
Using their 80% margins they can afford to at least give us some time before scrapping software that doesn't look it's ever going to reach 4bn consumers.
The result is stability. Until they all get toppled by the next technology revolution. Years later, regulators will crack down hard on some of the side issues of their former dominance and once again miss the currently relevant issues :)
Earlier quoted context omitted.
Not really, for simple apps you can use what we already have in place with some meta-programming rules prepared by humans (currently only a few companies posses this capability though). You can use ML like deep learning variations to learn association between your wishes and corresponding code blocks. Initially apps like that would be simple, i.e. "make a web page", done, "change background color to pink gradient", d…
I read a story years ago about a guy who changed careers from being a Programmer when Visual Basic was launched. He reasoned that anyone would be able to create applications so it wouldn't be a viable career anymore. > You can use ML like deep learning variations to learn association between your wishes and corresponding code blocks I suggest you read up on ML.
Earlier quoted context omitted.
> The only way they can get more of your money is to sell you a new phone which they hope to do between 1-2 years from now. The thing is, this only works on countries similar to US where most people are on contracts. In the rest of the world, where people are on pre-paid, we use our phones until they either die or get stolen, which is way more than just 1-2 years.
Bump it to 3-4 years then. Bloated manufacturer updates combine with bloat in most popular applications and the regular web bloat to make the phone unusably slow after few years. Between that and fragility of smartphones (mechanical damage, water damage), most people are bound to replace theirs every few years anyway.
My smartphone's getting on for 9 years old; I don't think I'm a key demographic ;)
Earlier quoted context omitted.
Bump it to 3-4 years then. Bloated manufacturer updates combine with bloat in most popular applications and the regular web bloat to make the phone unusably slow after few years. Between that and fragility of smartphones (mechanical damage, water damage), most people are bound to replace theirs every few years anyway.
> Bump it to 3-4 years then. Bloated manufacturer updates combine with bloat in most popular applications and the regular web bloat to make the phone unusably slow after few years. My S3 is 4 years old now, and it is works perfectly fine. When it dies, I will most likely adopt one of my Lumia devices as main one, or will buy a 2nd hand Android device, instead of giving money to support bad OEMs
Just spent it a new battery very easily for 7 € for the years coming.
Earlier quoted context omitted.
Looks like alternative facts have reached the tech world too? You can take as hard look at Google as you would like, but choosing Microsoft over Google (one for-profit company over another), while not caring how the technology, the licensing or the workflow compares is a bit hypocrite. (e.g.they are both open, and they both have rules of commits). I'm wondering, why do you need a throwaway for such heavily invested F…
>I think it is way ahead of the JS/TS stack in many regards. In what ways do you consider it ahead of Typescript? Personally as someone who's particularly fond of static type systems (Haskell and the like), Typescript's type system seems way more advanced and powerful than Dart's (union and intersection types, in particular, and non-nullable types). Map types (introduced in Typescript 2.1) also seem pretty interestin…
Personally I don't get the hype around union types: at the point where you need to check which type you are working with, you may as well use a generic object (and maybe an assert if you are pedantic).
Intersection types may be a nice subtlety in an API, but I haven't encountered any need for it yet. Definitely not a game-changer.
I longed for non-nullable types, but as soon as Dart had the Elvis-operator (e.g. a?.b?.c evaluates null if any of them is null), it is easy to work with nulls. Also, there is a lot of talk about them (either as an annotation for the dart analyzer or as a language feature), so it may happen.
Mapped types are interesting indeed. In certain cases it really helps if you are operating with immutable objects, and mapping helps with that (although does not entirely solves it, because the underlying runtimes does allow changes to the object).
It was unfortunately obvious that the writer had insufficient tech chops when use the phrase "a post-API programming model" But pressing on how somehow manages to blame the lack of updates to android phones on the modularity of the Linux kernel. The joke of course being that linux is monolithic and googles new OS is a microkernel ergo more modular. The quote is "...however. I also have to imagine the Android update p…
There's one design decision in Linux that makes this slightly harder than it needs to be in this situation: Linux's lack of a driver ABI. At the moment, phones include all sorts of custom drivers for very specific versions of the hardware. The OEMs ought to send these upstream, but don't want to. You can't build your own kernel and upgrade without breaking all the binary-only drivers. Android falls between two stools…
Isn't this a rampant GPL violation? Why do we put up with this?
We are about to lose the war for general purpose computing due to insufficient GPL enforcement.
Earlier quoted context omitted.
> There are tons of webapps which are very successful, despite being written 'once'. Actually they suffer from most of the same problems, only computers have gotten faster (masking performance issues) and our expectations have lowered. How many of these web apps obey the native OS themeing for instance?
1) The fact that webapps can run relatively well strikes me as hopeful, considering how much more inefficient using HTML/CSS/JS is compared to Java applets. Or is the latter not the case (honest question)? 2) I'm not sure if our expectations have lowered much. Perhaps it's more that mobile interfaces are generally simpler and thus easier to make 'native enough'? Although I think there's more going on in regards to 2.…
It's a really interesting question actually because it's so hard to compare the two. On any objective measure, today's web apps are much better than applets in terms of responsiveness, etc. But then again, an applet could run on machines with 16MB of RAM total. I think you'd be hard pressed to get plain html page in a modern browser to run on a machine like that. Either way, in both cases we had a much better solution in native apps.
> 2. I was never bothered so much by the UI of a java applet looking different. What bothered me was that even very fundamental stuff like input fields and scrolling felt both alien and shittier than native.
Modern web apps can score better here, but quite often they don't. The more complex the become the less native they get, scrolling, text input, etc are generally OK (unless your an arshole that overrides scroll behaviour), but html still doesn't have an equivalent for native table views and the goodies (navigation, resizing, performance) that comes with them.
For me the skinning does matter though, I have a beautiful, consistent desktop that browsers (not even electron apps) shit all over. When something doesn't look quite right from the second you open it it magnifies all the other differences.