Starting to hate Google...

Started by
44 comments, last by swiftcoder 12 years, 6 months ago
Building all of your cars one molecule at a time allows everything without restrictions. Why the hell would those stupid car companies want robotic factories and pre-assembled components? Morons. ;-)


All snark aside, Dart's mistakes in concurrency are not a fundamental weakness of no-shared-state models. They are a Dart-specific flub, and should be treated as such. The correct way to parallel-process large data sets without copying is to pass a reference to disjoint subsets of the data to each worker node; the fact that you cannot do this efficiently in Dart (from my understanding) is a foible of the language, not the parallelism model.

Shared state concurrency is disgusting, and non-shared models are almost uniformly far superior. Yes, you have to change your way of thinking, but then again, Henry Ford's assembly line changed a lot of thinking, too. New mental modes of operation are not inherently evil.

Wielder of the Sacred Wands
[Work - ArenaNet] [Epoch Language] [Scribblings]

Advertisement
Just to add my voice to the already given sentiment. After using MSDN pretty much any open source product designed for developers to extend pales in comparison. I do think a lot of people get unjustly mad at Microsoft without really giving them credit for how balls out amazing their developer tools/support/documentation are; even their free ones. It's a shame it isn't always better translated to the public through the products the developers make.

Regarding Google itself: meh. I'm going to be excessively frank about my opinions, so if you're easily offended, skip this post.




This is just a hype bubble in the process of collapsing. People got ludicrously inflated images of Google's sophistication, engineering prowess, hiring standards, processes, you name it. Frankly it was just a giant marketing campaign to help with their IPO and with recruitment drives. Everyone seems to have this almost messianic picture of Google, as if they're going to save mankind or some nonsense.

They're just another large tech company.


Seriously. Where's the hate for Hewlett-Packard? IBM? Sun? Oracle? Yahoo, for that matter? Amazon? Nah, those guys are already seen for what they are - large tech companies - and the shiny has worn off years ago. It isn't hip enough to hate them anymore - even though it once was the height of being "with it" to rag on each of those firms. The target of unjustified loathing for this month is Google, and that's purely a backlash against a very successful brand-building campaign. Yeah, so they're not going to solve world hunger and bring about eternal peace, but if you believed the hype in the first place, I've got some nice waterfront property to sell you.


Google is just a large tech company. That means they will have a few brilliant products, a few abject failures, and a handful of mediocre fluff in-between. They will try many things in an effort to expand their revenue streams and remain relevant in the rapidly-moving tech markets, and they will fail at most of them, because most business ventures are failures, even when they are started by successful firms. People seem to forget that with alarming regularity when criticizing companies in general.

Dart is just jostling for position in a market that's poised to shift radically, provided someone with enough elbow grease can shove it off the cliff. No big shocks there.

Android is frankly a far better platform to develop for than iOS (yeah, yeah, cue the flames) and arguably one of the most accessible platforms for mobile development in existence. I don't share the sentiment that it's poorly managed, aside from Hardware Hell, which was a regrettable gaffe on Google's part early on. Most of the crappy management of Android tech comes from actual cell phone vendors, who are notoriously greedy, stupid, short-sighted in technical matters, and slow to change. They inherited that legacy from the land-line phone empires of the 20th century. No surprises there, either.

Google themselves has recently realized that they've spread themselves too thin, and have started cutting back on various stuff in a transparent effort to trim the fat. Witness all the products that have been end-of-life'd in the past few months; consider the features that have been axed from surviving products; look at the (frankly respectable) re-focus on their core strengths of search and targeted advertising. The only surprise here is that an otherwise "large tech company" is self-aware enough to make such radical moves in the first place.


Hating Google is just the tech fad of the year. The in crowd all has to do it to retain their street cred.

Yawn.

Wielder of the Sacred Wands
[Work - ArenaNet] [Epoch Language] [Scribblings]


[quote name='swiftcoder' timestamp='1320187516' post='4879430']
[quote name='Sirisian' timestamp='1320181677' post='4879386']
Regarding concurrency:
An isolate is a unit of concurrency. It has its own memory and its own thread of control. Isolates communicate by message passing (10.14.4). No state is ever shared between isolates.

They're just taking the stupid idea of webworkers which was a useless feature and just throwing it into their language instead of implementing actual language locks and mutices.[/quote]
I can't agree with you there. The locks & mutices threading model you are talking about is vastly inferior to Erlang-style concurrency (i.e. message passing, no shared mutable state).

Dart's Isolate is likely the result of the work they have done on coroutines in Google's Go - they quite closely resemble one another, although isolate appears to be a little more general (can spawn OS threads as well coroutines).
[/quote]
Seems like a good idea in theory until you actually do it. Pretend you have a set of data you want to work on with multiple threads. Like for multithreaded pathfinding or image processing. Suddenly you're forced to copy data. (In webworker's case you can't copy more than 1 MB of data). Doesn't matter really though since the time waste copying is so expensive that you've effectively negated any performance increase. That's not even counting the copying of the data back. The alternative is to just pass in a reference and go "hey you 2 threads work on half the data each and get back to me when you're done". No copying overhead. You'll notice in that situation that neither thread even had to touch the other's data at the same time so no lock was needed.[/quote]Care to clarify why you believe references and message passing are mutually exclusive?

The only time it makes sense is when your passing off like a few values or a small array for heavy processing. Then again you lock out the bigger uses of threads that way. The lock and mutex allows everything without restrictions.
[/quote]Concurrency is an abstraction, not an optimization; the basic bronze age concurrency primitives are quite obviously useless in this regard, when compared to Erlang-style message passing.

[quote name='Sirisian' timestamp='1320193865' post='4879467']
[quote name='swiftcoder' timestamp='1320187516' post='4879430']
[quote name='Sirisian' timestamp='1320181677' post='4879386']
Regarding concurrency:
An isolate is a unit of concurrency. It has its own memory and its own thread of control. Isolates communicate by message passing (10.14.4). No state is ever shared between isolates.

They're just taking the stupid idea of webworkers which was a useless feature and just throwing it into their language instead of implementing actual language locks and mutices.[/quote]
I can't agree with you there. The locks & mutices threading model you are talking about is vastly inferior to Erlang-style concurrency (i.e. message passing, no shared mutable state).

Dart's Isolate is likely the result of the work they have done on coroutines in Google's Go - they quite closely resemble one another, although isolate appears to be a little more general (can spawn OS threads as well coroutines).
[/quote]
Seems like a good idea in theory until you actually do it. Pretend you have a set of data you want to work on with multiple threads. Like for multithreaded pathfinding or image processing. Suddenly you're forced to copy data. (In webworker's case you can't copy more than 1 MB of data). Doesn't matter really though since the time waste copying is so expensive that you've effectively negated any performance increase. That's not even counting the copying of the data back. The alternative is to just pass in a reference and go "hey you 2 threads work on half the data each and get back to me when you're done". No copying overhead. You'll notice in that situation that neither thread even had to touch the other's data at the same time so no lock was needed.[/quote]Care to clarify why you believe references and message passing are mutually exclusive?
[/quote]
I was referring to the common implementation of web workers which under the definition of no shared mutable state usually requires the data be duplicated so that it isn't changed on the original thread while the new thread works with it. The alternative is to use a lock statement and lock the resource while it's being used so only one thread may work with it at a time without any overhead. It's usually much more flexible and has higher performance when working with large data sets.

In regard to passing references in a message to a thread I'm not sure what your question is. I never said they're mutually exclusive. How did you imagine working with a reference in a concurrent thread? Say you don't have locks and you just access it then it's no different than what I described as a more flexible system to allow. Placing the constraint on data that whatever you access is immutable between threads is the unnecessary constraint I'm not a fan of. Especially since it doesn't reflect any native hardware limitation. Accessing referenced data from a thread without a lock for instance should be a decision left to the programmer. Sure it can be unpredictable with registers and such, but as long as it doesn't allow scripting security holes then it's fine. (Implementing it so it doesn't have security flaws is fairly trivial in that respect).


[quote name='Sirisian' timestamp='1320193865' post='4879467']
The only time it makes sense is when your passing off like a few values or a small array for heavy processing. Then again you lock out the bigger uses of threads that way. The lock and mutex allows everything without restrictions.
Concurrency is an abstraction, not an optimization; the basic bronze age concurrency primitives are quite obviously useless in this regard, when compared to Erlang-style message passing.
[/quote]
That's an extremely naive view of parallel processing. When used correctly the speedup is rather impressive especially on dual and quad-core systems. Using it only as an abstraction is kind of missing the big picture especially when those threads are mapped to kernel threads like in most languages.
Yes I do hate the way that gmail shows email in its webmail - I have no idea if I've received a new email or not, so I keep having to look at the email, only to find it's an old thread that hasn't received a new email yet.

Yes, threading has its uses, and a threaded email client would be great, but it should be easily switchable between different views, and not done the gmail way.

(I see that Android does text messages/email this way? If there's no way to turn that off, I'll have to keep clear of Android for my phone.)

http://erebusrpg.sourceforge.net/ - Erebus, Open Source RPG for Windows/Linux/Android
http://conquests.sourceforge.net/ - Conquests, Open Source Civ-like Game for Windows/Linux


Javascript needs to be replaced. I along with others online have mentioned this for a long long time.


I'm quite new to JS, but from what I've seen, the language itself is "fine" (plus or minus personal preferences or offbeat requirements).

What needs to be replaced is its integration in browsers, mostly


  1. The overly shitty execution model that allows for "fun" things like just executing stuff by appending it to the document, and
  2. The supremely half-assed brainless DOM API that just does some things wrong (ever tried using an onclick handler on a submit button?) and is generally decoupled from what the DOM is really looking and acting like.


Both are not language-, but integration issues.

This is just a hype bubble in the process of collapsing. People got ludicrously inflated images of Google's sophistication, engineering prowess, hiring standards, processes, you name it. Frankly it was just a giant marketing campaign to help with their IPO and with recruitment drives. Everyone seems to have this almost messianic picture of Google, as if they're going to save mankind or some nonsense.

They're just another large tech company.


Seriously. Where's the hate for Hewlett-Packard? IBM? Sun? Oracle? Yahoo, for that matter? Amazon? Nah, those guys are already seen for what they are - large tech companies - and the shiny has worn off years ago. It isn't hip enough to hate them anymore - even though it once was the height of being "with it" to rag on each of those firms. The target of unjustified loathing for this month is Google, and that's purely a backlash against a very successful brand-building campaign. Yeah, so they're not going to solve world hunger and bring about eternal peace, but if you believed the hype in the first place, I've got some nice waterfront property to sell you
I agee that Google (and Apple for that matter, and even more overhyped company) are just yet another company. But I think this sort of "hate" is inevitable - the reason we don't see the hype for HP, IBM, etc, is because they're never overhyped by the media and its fans to the point of ridiculousness in the first place.

I don't think it's the people criticising Google being hip - they're just responding to the hip crowd that go on about them all the time.

http://erebusrpg.sourceforge.net/ - Erebus, Open Source RPG for Windows/Linux/Android
http://conquests.sourceforge.net/ - Conquests, Open Source Civ-like Game for Windows/Linux


the reason we don't see the hype for HP, IBM, etc, is because they're never overhyped by the media and its fans to the point of ridiculousness in the first place.
Maybe not recently, but they have all created vast hype at one time or another...

Remember when Gateway was going to 'revolutionise the world through low-cost computing' (their computers were shoddy, and not terribly cheap)? Or when they ran ads on every media channel claiming to the world that they had an 'iMac killer' (the iMac is alive and well)? Remember when Dell had the 'best customer service in the world' (but it took an hour to speak to a human)?

Tristam MacDonald. Ex-BigTech Software Engineer. Future farmer. [https://trist.am]

I am not talking at all about end user products like GMail, Android or any other Google product.

I am talking about their developer products, the horrendous lack of support and the shoddy state they are shipped in. I don't talk about IBM, because frankly their developer support is absolutely stellar. Actually in my brief exposure to Yahoo's developer support it was incredibly good too, although I only worked with their UI toolkit and BOSS search engine technology, but both were exceedingly well documented and packaged in a way that made it extremely easy to get up an running. I have dealt with Amazon as a developer, working with their S3 and EC2 technologies and though the experience wasn't amazing ( it has improved ), it was vastly superior to any time I have dealt with Google products. It at least had timely, thorough and accurate documentation, which is the baseline of what I expect.


I use Google as my primary search engine, I am typing this in Chrome, my phone is an Xperia X10 ( not that I am happy about it over all ) and I own a Asus Transformer. I have no particular hate over Google products, but their developer support is absolutely and overwhelmingly shit.

This topic is closed to new replies.

Advertisement