I was just explaining this to someone the other day that thought AWS was going to save them money. It's not cheaper than running your own shop. The only advantage I see is that you don't have to house/cool/maintain hardware. You can just move your application to higher capacity, faster servers. You get additional power and network reliability.

If your dev/test platform is already off-site and working, then what is the compelling reason to interrupt everything and do the move? Where I am working today, the tried to move from AWS to Google's cloud and had tons of issues of reliability. We're back on AWS. Our usage model though, lends itself to AWS. We sell "application instances" which are deployed for customers to AWS for its up-time reliability. All our development happens in-house though.

It's not a magic bullet. If you're looking to save money and your place already has a cooled closet and redundant network and power, then it offers no incentive for you to move.

Good to know. Now I just need to find a way because my state makes it illegal for labs to sell directly to consumers.

With the shuttering of 23andme.com, forced by the FDA, we no longer have the ability to have our genes sequenced on our own prerogative.

Thanks federal government.

Yes. If I use IMAP, then why use gmail at all?

I don't actually like to read my gmail. Its a horrid interface. No folders (no, I'm not going to search, TYVM) and the "folder" work around is a kludge doesn't cut it for me. Yahoo up until recently had the most powerful interface. But no SSL after login. Then they started limiting page sizes rather than continuous.

I'm thinking Horde Mail/GroupWare on a reliable cloud provider would be the way to go. But you can't leave google behind because of the drive, docs and all that stuff.

You can't experiment on kids like that. They are too resilient and you won't get good data. It's not soud. Use midgets instead, ginger midgets.

Your miles credit would be subject to bartering and fair market valuation provisions, if they can be considered property.
However you might be able to argue that it's a negotiable instrument and has no fair market value. This would then require you to haggle ("sure, I'll take you 8 miles for 15 miles of credit" as enforcing it at 1:1 would support the idea of it being property. This means now, you have to auction the miles, this complicating the whole process, making it more unattractive.

Thanks for the clarification. But this just reinforces me point. We are choosing fragmentation. You can sign any binary, executable or DLL, C++/CLI or C#. MS is forcing people to develop a C# code base to lock them in. Again, further fragmenting the market.

Oh, I'm all for getting the job done. That's why I want consolidation. Since you run a consulting firm, how much of your code is actually customer specific? Like I said, schemas and logic changes, but I bet if you look across your customers, you'll find about 20% of your function is duplicated between unrelated projects. You don't care because its billable hours. Maybe you copy and paste? I don't meant hat in a bad way. But when you stop looking at billable hours, and focus just on getting the job done, I don't want to duplicate other people's work.

Let me give you an example from this very weekend. I needed to get the distance between two GPS coordinates. Googling for it I found javascript code that I then copied and converted to C/C++. In an ideal world, I'd just get the library and be done. But there are different implementations. There's Haversine, and 2 other ways to calculate the distance, each with nuances of implementation. Now, in my ideal world, I wouldn't matter what language it was done in (this was .Net's promise) Instead me and everyone else does the same conversion from the JS to our language. You as a consultant should love the idea that the body of programmed knowledge is available to your developers regardless of choice of language.

I want to make it clear that I am not arguing that we should only have C++. I was arguing that everything we've come up with since C++ (Java and .NET) have only served to fragment and divide. Now we have 3 major ecosystems all being maintained separately. Who wants to maintain 3 code bases that do the same thing? Billions of dollars poured into the maintenance of these toolkits a year. Hibernate and NHibernate. Dozens of SQL drivers on dozens of systems. The work expands exponentially. All to do the same thing. To keep their ecosystems on par with each other. Imagine if we just poured the same into one project, how much more we could accomplish. I don't suggest C++, though it has a fantastic track record. Managed memory systems are all the rage. I've done Java, Python and C#. I don't want to pick one. I but I want all of them to use the same platform. I'm hinting that C++ is it, because Java has JNI, .Net has the C++/CLI and Python has C/C++ wrappers. Imagine if we promoted the common stuff to a common universally maintained C++ package.

I also think we need side projects to experiment. NodeJS is very cool. And we need to explore our itches. But by t he time we start to develop these things into ecosystems, we should focus on consolidation so that everyone can benefit. Yes, it'll be an effort, but less effort than continually maintaining separate code bases.

Anyone who tells you that is lying.
C++ even works on Windows Phone. You can't really ban a language that compiles to CPU opcodes. Furthermore, do you think that every title that is released on PS4 and 360 is completely re-coded into .Net for the 360? No. It's the same as what people do for the phones. Common C++ code, wrapped in platform specifics.

What would Qt add to Arduino? Maybe signals slots, but it's too limited. Now Qt runs nicely on a RasberryPi or BeagleBone. So for a few dollars more you get a GUI...

C++ doesn't manage memory. Your or your toolkit are responsible for deleteing instances. Qt makes this easy for QObjects because it accepts a parent, and all children are deleted when the parent is deleted. The rest of the classes, generally, are implicitly shared. But if you use new on an unparented object, then you must delete it.

If you're only using the stack, then this is also taken care of for you.

I actually agree with you. I *want* that stuff to be irrelevant. When I describe a rectangle, I don't really care if its a Java rect, a .Net rect or what. I'm talking about a 2d object with orthogonal sides.

However I worry about your literate programming. Definately, it should be readable without an IDE as I end up using nano a lot :-) But where i get concerned is when you say "cannot keep the required number of methods and members". The API calls are very specific, not general things and something like a const parameter is a very important decoration that conveys a specific behavior. I'm not saying I like "const" (it's rather confusing at times) but it's needed to tell the computer exactly what to do. We're not going to get to using natural languages to program computers, it'd be like esperanto, because we lack the specificity required for digital computers.

But I do agree we can make big advancements towards literate programming for the better.

Because we no longer solve original problems. Because we all repeatedly solve the same problem that was solved by someone else years before. The only new thing to come out of computing in the last 30 years is the highly parallel general purpose GPU. The rest of it is data schema, transforms to the schema and logic.

Ask yourself this: How many Rectangle implementations do we need? As in X,Y, Height, and Width. Why do we have a Java version, multiple C++ versions, a .Net version, and Obective-C version.... Each time we reimplement the thing it isn't new. Ok so Qt has QRect::translate()... but why can't we just add translate to all languages and implementations when we decide we need a translate() function. Why are the Java and .Net ones seperate, with different methods and signatures despite it being one concept.

To bring in you construction analogy, we are not worried about tools (it's an ill fitting parallel) but rather contruction materials. Tools do the operations in the materials. Here I argue that the libraries are materials like the 2x4s. 2x4s come in 2 basic favors: steel (commercial construction) and wood. They all are 1.5x3.5", and cut to length. We use them to solve walling and supporting problems. We arrange them as needed. We call the API as needed.

VPSs are cheap. besides, it's an illogical computing unit since it is so abstracted.

Native apps are a run around on android... that's what Qt is. Native.

You still don't get it. Android reinvented the wheel yet again, in a context that is not re-usable outside of android.

The fact that C++ can still be used on any platform, and effectively at that, proves that nothing has been added since C++.

It's not me that knows so little. What the fuck do I care where the division is between language and framework? You're the one that is short sighted. These are all mechanisms to achieve an end. Sometimes its language, sometimes its framework. I would have thought that someone who witnessed C++11 (assumed by your UID) that you would see that they are adding elements to the language that had previously been implemented as libraries or frameworks.