RyanZAG

Complexity is something completely different and is well known in all products. I can design a calculator that adds numbers very easily. A calculator that does fractions is much harder to design and costs more. A car with a more complicated engine is much harder to build than a simple engine. This has nothing to do with the actual economies of scale of the calculator or car or you could say that cars have dis-economies of scale too - and obviously they don't. They're the poster child for economies of scale.

Building a truck that is 10km long is worse than building 100 trucks that are each 100m long, but this has nothing to do with 'diseconomies of scale' inherent in trucks.

Japan forcing overtime pay would probably be the single best way to boost their entire economy. I'm guessing they will never do it for unfortunate cultural reasons though.

Going off the usual price for apps ($2.99?), and a 'bunch' is probably about 25 apps, then replacing all your paid iOS apps with paid Fire apps would probably cost you $75.

So ignoring anything else, a lot of people would actually value their $75 sunk app costs greater than the $350 difference between that iPad and the Fire. It's a pretty interesting lesson in humanity.

Let me repeat it again - for you, nothing at all has changed except that other people around you are also suffering. Your attitude is awful.

If someone came tomorrow to your office and gave a million dollars to each of your team members and $10K to you, you would resent your team members for receiving more money than you, right? People like that are only happy to see others clawed down to their own level.

Seriously? Because your working conditions are terrible, remote engineers are bad for having good working conditions? Here's a hint - stop wasting your time hating others for being happy, and work out how to improve your own working conditions into something you enjoy.

When you remove the manual QA team and switch to staged rollout, you are moving the manual QA burden onto your users. You still have that manual QA team - they're the first bunch of users in your staged rollout plan - you just don't pay them anymore and gather their feedback through bug reports. Users are used to buggy software because of other companies who do this (Google, etc) so they carry on being users anyway.

Hang on, this should be the number 1 point of your entire blog post. Honestly, if your post was titled the obvious "Don't make mobile apps only for one region" then you'd be getting a lot of comments saying "Well, obviously".

Seriously your problem here is not that you made a mobile app. Your problem is very clearly that you excluded 99% of your user base. Any chance you can explain the reasoning behind this..? I can't even begin to understand it. Outside of government required tax applications, I cannot think of a single successful single-region productivity app ever.

At any rate, JSON is the transfer format used by RethinkDB so at some point it has to be JSON for RethinkDB to read it. You could always make your own data language and integrate it all yourself, but ultimately you can't transfer your POJO directly and will always have to transform it into something. JSON is pretty decent and very compatible.

So to answer your question: (RethinkDB -> JSON String) is a completely required part of the database communication. The additional POJO step is fairly efficient when using Jackson and unlikely to be a large part of your CPU usage - the simple and required byte copy may use more CPU on large POJOs. You could use some type of no-copy directly from the network buffer but then a complex database like RethinkDB would not be the right choice - you'd probably use local memmapped files in C..

In short: try using the driver and pojo conversion in a real world project and profile it. I think you'd be surprised how little overhead it really is. Computers are very good at this stuff, and the JVM's JIT is optimized for this stuff.

It's actually fairly interesting. These huge mega companies are just support teams for a few programmers. All the corporate vision and endless strategies mean nothing compared to one of those programmers having a good or bad day in their work. You honestly get the feeling something somewhere is very broken when you think about it.

The people making the decisions have no training in law at all, yet they have to decide if the law was broken. They get a brief spoken explanation of the law, but only after they have been given the testimony. Why would you not have someone trained in the law decide if the law was broken? Why would you not allow the jury to interrogate the witnesses when they must bear the responsibility of the decision? The idea seems to be that random people off the street will somehow be more willing to consider all angles and if they disagree, you get another random sampling and try again. Try enough times and eventually you'll get a bunch of people who are annoyed enough by being forced into jury duty to just agree so they can go home. Real justice right there.

You might say that the jury system allows for a justice even if the judge is compromised. But obviously it doesn't - the judge controls what information can be fed to the jury and the jury must make the decision based off that evidence. If the judge is biased, the jury will be forced into a particular decision anyway. Why not just have the judge do their job and have an appeals system and punishments on the judge for bad decisions? And yes, that system works fine. See the current Oscar Pistorius trial for a working system (imo).

In terms of construction scores (from 1 to 10 where 10 represents a perfectly built trolley), men averaged 8.9 with instructions, 7.6 without; the women averaged 7.5 with, and 5.7 without.

So men without instructions do slightly better than women with instructions, and men with instructions do far better..

Obviously the even bigger mistake was not doing a massive company wide re-organization and throwing out all middle management. Middle management is only an asset if it is helping the business, and as is obviously the case in Yahoo, it is not.

While going about your work, you suddenly disappear along with your universe and everything in it. Someone somewhere in the world drank a cup of coffee, which means that he now has an empty cup instead of a full cup. A new universe had to be created with the full cup replaced, and unfortunately your universe had to be thrown away. You continue life as a clone in a new universe with an empty coffee cup somewhere in Nebraska.

Why did this happen? Someone picked a copy-on-write map implementation because it had a slightly faster O(logN) delete behavior and unfortunately the re-use function of the map wasn't implemented yet because the author has gone on to do a series on the use of monads in baking the ultimate croissant.

You need transportation, so you define an engine and a set of wheels and a chair, and a whole universe. You define a way to have the engine, wheels and a chair work together. You try to sit in the chair, but it's too small. You can't change the chair because it's all immutable, so you create a new chair along with a new universe and build a new car with the new chair.

You need to get to work, but you don't want to pollute your universe with state, so you don't know where work is. So you put all of your state in your relational stateful database and forget that this part exists in your universe. Of course theoretically you could model your knowledge as a function based off the state of the universe, but you don't have budget to do that. You write comments about quick hacks to get around purity constraints. The hacks are never removed and you end up passing stateful maps of database tables around. You make a big todo note about how you should implement a new method for handling this that you've read in a new academic paper, but never get the 500 hours you need to implement it.

EDIT: For those not getting it, the article is describing the difference between the theory behind OO interaction between self contained actors and how this really plays out in actual code. Instead of doing the theoretical part of communication between actors, we have code which does getCoworker().getWallet(). In the same way above, I've tried to show the difference between theoretical functional programming where we can create pure functions and how this actually plays out in real functional code.

The analogy also opens up another difference. In clojure, you often end up passing around a lot of maps with string keys. What are those keys exactly? You have to crack open the clay brick to take a look at how it works. With the stick model, you can often see how the sticks work if the bundle of sticks has been color coded nicely - eg, well constructed generics. Luckily cracking open a Clojure brick is as simple as ctrl-clicking, so it's not nearly as bad as it sounds!

Programming parables are definitely weird though - programming does not have true analogies with the real world. It's more of a superset of the real world and the use of programming languages is more akin to defining physical laws than building bridges with clay or sticks. I don't think we as humans have really come to understand exactly what we are unlocking with the development of programming and how vast it really is.

However when you get 30 people working together to make a big model, the clay model is going to start looking very strange indeed. Different people will have different finger pressure and shape the clay differently. Some people will make more right angled parts with the clay which will clash with the parts of the clay that are carefully smoothed out. Someone might spend a week fixing a perfect parabola for a curve at the top of the model just for someone else to bend it off to the side with an ugly twist to fit with the other side of the model.

30 people on the stick model? Not really a problem. All the sticks look the same. Anybody who needs to attach one side of the stick model to something else just needs to grab a stick and tie it on. You won't see a perfect stick parabola, but then you also won't be stuck with a strangely twisted piece of clay.

You can always create a style guide for using the clay - always keep between a 30 and 60 degree angle on joins. Apply one finger of pressure when doing joins. And so on. Sometimes this works with very diligent reviews that keep everything in place, but as soon as a crisis comes up or the model needs to pivot urgently? Everyone rushes to touch up the model in the quickest way possible and your model starts to get a bit thinner on one side than the other, etc.

So there's nothing wrong with choosing a great clay model that fits well into your hand and you can shape effortlessly - but you need to remember that sometimes the 'painfulness' of using a model made out of sticks can be a big blessing when you're trying to massage a bit of clay that someone else pressed a bit too firmly on.

EDIT:

Also, when you've been making and using models for awhile, the stick models get an added benefit: you can browse through the stick models really fast based on only their outline and be able to understand very quickly how they work. Pretty clear why: the rigid sticks form a very distinct outline (think interfaces and forced directory structure in Java). Being a stick model expert therefore has very good job mobility and high demand.

Each clay model is generally more unique and requires some study to understand even if it does look nicer.

Honestly, why? Seems odd given Java's great track record for exactly this problem and huge library and developer share. The code itself is forced to be static and explicit which makes for easy onboarding for new developers.

It's a bit strange to just dismiss Java in the context of the rest of the article. You're kind of staking your company on decisions like these, and making them because of some unquantifiable 'strong aversion' seems like a poor choice.

That said, Clojure or other lisp base definitely seems like the correct choice for a query language / dsl. That's the shining point of lisps after all.

This feels like the first bullet in a new war that will occur in every parliament world wide.

Also looks strangely reminiscent of the industrial revolution. http://3219a2.medialib.glogster.com/jayytyler97/media/c6/c60...

However even more importantly - if you're going to create a language, it needs to be the ultimate language in your own eyes. You can't leave off novel features that you have experience in because it doesn't have mass appeal or has tooling issues. You need to create the best language you possibly can if you want to compete with others trying to create the best language. Hamstringing your enjoyment of the language by going in a direction you don't like because it has more apparently mass market appeal isn't any more likely to be successful, and it certainly isn't going to be enjoyable enough for you to slog through the tiny complexities.

While there is a tiny chance that your language becomes the next big thing, it probably won't. That means you need to make the language you want to make and hope it succeeds, not make the language that 'will succeed' but you don't want to make.