optionalparens

I often remark that people love reimplementing BBSs badly, and a fraction of the functionality. Of course it's not an entirely fair comparison because of the scope, different UI/nature of the web, audience size, and speed of communication to name a few issues.

It's important to note that your average decent BBS had most if not all of the following:

* Files - Often meticulously organized, with sometimes user voting or strict moderation. Unlike a lot of file sharing today, most boards also had things that would extract descriptions from archives or otherwise let you write them manually, along with providing other file metadata.

* User Management/Registration - Complete with idiot filters for the more underground boards (apps, voting on users, new user passwords)

* Mail - Even later, various versions of distributed mail including early email access for many people as well as things like FIDOnet

* Instant Messaging/Chat - There were entire huge multi-node boards entirely devoted to this, and even a single node board at least had sysop chat usually

* Games - Door games, mail/message games, offline sync'd games

* Timelines/Walls - Lots of plug-ins for this type stuff to leave short messages, shouts, etc.

* Time Management - Not necessarily a good thing, but on some boards you could bank time. Moreover, the fact there was time involved with your login on some boards created a sense of purpose and urgency.

* Keyboard Shortcuts - Godsend compared to your average web app, but also a drawback for some.

* Customizable UI - Most boards at least let you change menus, if not install plug-ins and other add-ons

* Distributed Content - Various boards would call each other or a sync service or otherwise download sync files to sync data such as games, not just mail.

* Groups/Subcultures

* No Frills - Despite being over modems primarily and thus slow, BBSs were pretty fast. In fact, I still feel like I got to more relevant information faster. It's not just a keyboard and mouse thing, it's about flow and the fact that the goal of the BBS was to deliver you some content quickly and efficiently. Navigation in web pages just sucks sometimes in so many ways - multi-page ads, long click funnels, huge percentages of random things I don't need on the screen like sidebars, etc.

I think for me the #1 thing about BBSs is at least for the better, BBSs, they tended to be more restrictive and served as great content filters. If you were an idiot, you simply could not join or got banned. There was a sense of excitement to get on a new BBS and see what it had, and with many, a status attached, especially in various undergrounds. There were always troublemakers, but they were limited and it was part of the fun usually to fight and have factions.

The small scale really made you feel like you knew everyone, even on large BBSs with tons of users. Sometimes this also meant that we all met up in real life and that changed how you interacted with people. It also sometimes deflated your view of certain people.

On the flip side, there were many things that were pains not limited to busy signals, slow speed, lots of bad BBS software that was popular, file transfers in the earlier days, limited to calling or receiving per number of phone lines unless you had expensive hardware/telco, and so on. I've often thought of writing some sort of newer, hybrid Internet modern BBS software. I am keenly aware of the many efforts to do things over SSH, telnet, web sockets, but they are mostly just unfinished rehashes of a lot of the less impressive parts of the old stuff. I have a list of many somewhere if anyone cares.

There are just so many things I could write about what we could learn from BBSs. Sadly, I still think the filtering aspect was really what tied it all together. Regardless, I would like to see someone build something new starting at the protocol level that isn't just sitting on top of what exists or at least is not just copying the old stuff. Some things like Hotline and other file sharing were close in a way, but lacked the same feel. I really wish at least the idea of getting to information fast and without bs would come back more. Gopher in the early days sometimes felt like this, and many web pages were like this to some degree.

Anyway, I am sure there are a lot of people who disagree and I believe there is a lot more good and bad things to say. I feel like BBSs are really ignored by a lot of people, and misunderstood by another large amount of people including former users. There are still some BBSs out there and the good news is most don't require a modem (just SSH or telnet), but it's just not the same.

Over-engineering is a tough thing to discuss and there's never going to be a suitable answer anyone agrees upon. It is also a huge topic with a scope far beyond this textbox or a medium article.

Anyway, among many of the big issues here are so many things are contextual - the problem domain, stakeholders, programmer abilities, business climate, etc. It's been my experience that you cannot apply judgement to a solution without understanding as many of the variables involved as possible. Shifting these variables even slightly can change everything.

For example, say I build a feature A at company Y and then I change jobs next week and to company Z which is much smaller. Company Z wants the same feature I just built at company X, but of course I can't steal it outright. Building the same thing at company Z requires different engineering decisions, given the different climate and probably different development team, programming language, and so on hypothetically. Even if I could just copy the solution, at company Y it might be perfect, while at company Z it might be considered over-engineered. It's a combination of both objective and subjective judgements.

As for the concrete implementations of features, I often am driven crazy by both over and under engineering. I worked with several people in positions of power above or horizontally to me that would routinely shoot down many well-engineered features and implementations by other people because they were, "Too complicated." I began to realize this was often shorthand in most cases for, "I know nothing about this, my ego or political stance is threatened, I lack talent, and/or I am simply a moron." Of course I also hit plenty of actually over-engineered things that were indeed exactly this, but in many of these cases it was obvious. Where it is less clear is anything of decent scope, challenge, subjectivity, or other hard to quantify measure. I think people can look at something like the FizzBuzz and see that the parody versions using OO 10 design patterns with abstract factories are obviously over-engineered, while it gets much harder in the context of a big project.

And this leads to another problem. Complexity is not over-engineering, nor vice-versa always. Nor is scope, or code size, or any of these related concepts that come to mind. A very small amount of code can be incredibly complex, a large amount of code can be simple, and so on. Either can be over or under engineered. Just look at math - some of the most useful tools are very difficult to understand, while others are incredibly simple with tons of layers, nuances, and so on. Programming is not that much different in this regard. We've all seen things done in a tiny amount of code we would have never thought of and maybe can't even understand. Likewise, we've encountered huge amount of code that someone complains about but is written clearly, thoughtfully, and cleanly. These's a good related talk on some of these ideas by Rich Hickey if I recall.

Another issue is that it is hard to quantify both knowing what and when justifies substantial engineering efforts. As I mentioned, context plays a big part, as does intuition and experience (in relation to ability, not just pure years). These are all nearly impossible to quantify, and yet must play a large role in cases where large engineering decision making. A lot of people see things they don't understand or are new to them and just throw out the over-engineered card. Likewise, a lot of people love pulling out their favorite tool (ex: SQL, Framework of choice) and try to use it as a golden hammer. Anything else is "over-engineered." These things can lead to over-engineering or at the very least, poor engineering.

Over-engineering is also something that is relative. It is really hard sometimes to work with someone else and to get them to understand especially those hard to quantify things such as intuition. Programming can also often highly be about ego and ownership. People will not hesitate to point at something not written by them as over-engineered because it was not done how they would do it.

Game programming for me again comes to mind as an area where this is a constant pain. The inexperienced game programmer will both under and over engineer things like you've never seen. First, they'll try to use their favorite language to write a game. They'll then do things when they learn a technique like OO programming and try to apply it everywhere, to everything. "A monster? Obviously I should make a monster base class, then subclass this for an Orc, then subclass it again for an Elite Orc." Everything must be designed around the tools they know instead of the problem. The minute this person does enough in their career to get any real authority or a real job, they take this unchecked mentality and try to impose it on the people around them. I see the same thing in web application and desktop programming. Someone learns lambdas, functors, currying, design patterns, IOC, monads, etc. and they must apply them to any situation that triggers this recognition. The "engineering" then comes from the solution and tools, perhaps the XY problem in many cases. Usually these people also fail to consider the aforementioned contextual concerns.

I know in game programming this happened often where some programmer would come in and replace some lengthy looking code that made heavy use of arrays and manual for loops. They'd then go in and replace it all with vectors, iterators, and all kinds of heavier stuff. They never considered that the code was engineered that way for performance or for portability or backward compatibility or some other reason. Moreover, they didn't actually know that the seemingly "simpler" solution was actually making things as a whole more difficult by pushing out these concerns to be fixed or handled elsewhere (ex: making up performance somewhere else).

On a personal note, I am often annoyed by the over-engineered finger pointing. There are so many things like XML messes and 200 steps to setup something for a simple purpose that are easy enough to agree on as over-engineered. Most of these come down to asking yourself, "What problem am I trying to solve" and perhaps repeating those steps aloud. If you feel ridiculous saying them, especially to another person, something might be wrong. But if it turns out that the problem you are trying to solve really does require something that is not a sound-bite, the problem explanation will also often have to be long and cannot be skirted around without ignoring the problem.

Too often I see things in this industry thrown out there to "fail hard," to be an MVP, to test the market, to disrupt, to fill a gap. That's all fine, but make sure you are solving the problem and not creating new ones like security, performance, misleading people, defrauding investors, or worse because you thought engineering a proper solution is too hard or takes too long. Find the sweet spot and make informed decisions. I recommend another talk about Rich Hickey (sorry two by the same person, just memorable talks) about Hammock-driven development and thinking before acting. If more people did that, it could swing either way and maybe we would have less short-term "stuff" but better long-term solutions, less over-engineered messes, and things that actually are worth building on top of as bases. As it stands now, this industry is littered with poorly engineered solutions we were stuck with because of both over and under engineering.

This is true, but in fun hypothetical talks with various tech friends over the decades, we often talked about in relation to Internet services in particular, taking down services and such can actually help with hacking (i.e. stealing data) efforts. How? Why? Firstly, probing as the article mentions does yield plenty of valuable intel which is the core for espionage.

Secondly, we often joked that companies have such flawed backup and response procedures that triggering these things has a funny effect. More specifically, a lot of times in our experiences, we saw things like backups, up-scaling servers, etc. go noticeably unmaintained or poorly attended. A lot of people, especially years ago never did a great job of testing their backup systems, failovers, scaling, etc. and kept them up-to-date and secured as well as the main stuff. It's more interesting in some ways in this world of containers and VMs. One would assume things are updated, patched, and deployed exactly inline with the mainline stuff, but that's not always the case. It often takes only one slip-up and this is where a ton of people make mistakes for so many reasons. And sometimes it's easier to manipulate the protection systems to be the vector itself than the systems they are protecting.

That is to say, messing around with services sometimes can be a way of creating an open front or back door. Especially if there's malware and things that can be planted that will be less likely to be caught in the panic or otherwise deployed as a result of the panic response.

Of course all of this is more unlikely, but it's fun to think about in the same way stupid schemes that are similar in heist movies are fun.

Thank you, missed this piece but it was interesting.

I disagree with him on the point of "Who would do that?" He might be right about state level actors, but I think he discounts the motivations of crazy/disillusioned people, bored and curious people, and especially teenagers.

When I was a teenager, the Internet wasn't a thing yet, but we sure dreamed of all kinds of crazy schemes for taking out the phone company, power, anything really. We talked about anarchy and many "taboo" topics I can't mention here. The thing is we were good kids at heart and we had the discretion and morals not to act on those things. All of this happened in a time where our instant communication was the phone or meeting up in person. Today, it is infinitely easier to seek out like-minded people and to replace those who drop out. The ability to seek out confirmation and push is easier than ever as well.

Unfortunately, there are plenty of people that don't have that. Just because someone is a misguided teenager or crazy person does not mean they do not have intelligence, organization, and skills. Many of us certainly did our share of things and had the power, but I wonder what might have happened if we didn't stop ourselves in some cases. While perhaps the organization and probing nature likely hints at something else, it's really not that unusual for people to just mess around. Some people as they say also just want to watch the world burn. A couple of rough years in my teens, I certainly felt that way at times. I did plenty of things I'm not proud of, many people just have no shame and will take it that much further.

In the end I probably agree in terms of who is most likely, but I am kind of surprised that there were not more possibilities mentioned. Even 20 years ago, attacking Internet infrastructure seemed an obvious thing to do to us and we used to love talking about fun ways to ruin things over a burger at lunch. I mean is it really that hard to fathom people would think about attacking targets other than some organization, government, or other kind of company's servers?

True to some degree, but rooting can be a pain on devices that make you do it again after an update.

For me, the bigger issue with a hosts file is that it doesn't cover conditional cases. For instance, there are times when I want to read some comments or play a video, or even unblock a single page element, but otherwise I want to block that stuff entirely. Facebook comments is one example.

My recommendation is still to do both. Hosts file covers other apps nicely like stupid in-app banner ads, while using Firefox or something with ad-blocking extensions still lets you browse the web without breaking some sites entirely.

Oh I agree with that notion, it's just hard to get a lot out of stats without a large volume of it and a lot of other types of math as tools. Some are pre-requisites, while others are simply useful for applying in conjunction/situationally.

I still feel like calculus is one of the more valuable types of math. It really does teach you a lot, but like anything, it requires a good teacher. I find it all ties together for me in the end, like when doing graphics programming and games, I use a lot of trig, geometry, algebra, and calculus even, and stats some (and even more for business-type stuff).

I agree, but I thought most lower level classes were often titled things like "Intro to Probability and Statistics." Further, it's been my experience meeting and being around a lot of people who thought they knew stats that they only learned some basics which included but not limited to some basics such as: factorials, normal distributions, coin flips, t-test, permutations, combinations, etc.

I think a good stats education requires heavy emphasis on doing real problems with what you learn. It's so easy to do and apply to the world around you. Unfortunately, most books that even touch on this have absurd text and problem sets that revolve around pulling jelly beans out of a bag or rolling a dice (I mean yeah, but super literal). Mostly the professors and teachers I knew that taught statistics at the lower levels always seemed bored and wanted to be elsewhere. A shame, really.

See my other post, but I have to agree stats is incredibly hard to teach at the high school level. I also see the problem with grandparent's failures at applying math.

The huge problem as I mentioned elsewhere is that stats is really applied math. You do learn a lot of regurgitation-style stuff - formulas, proofs, blah blah, but it's all useless without applying it. Moreover, stats draws from so many different areas in math and requires analytical skills that are closer to many of the things scientists emphasize in learning to conduct studies and experiments. This makes it almost unsuitable to teach the more valuable parts of stats at lower levels because the students can't possibly be prepared.

At best, I think you can teach some general things about stats and the mentality I described of being analytical and skeptical. Unfortunately, stats is just really hard for anyone to properly and comprehensively learn who isn't going to be able to invest a lot of time both learning pre-requisites and then all the different areas of stats. It's like learning to be a carpenter and only understanding how to work a hammer, but not a saw, measuring tape, or anything else.

One of my degrees is in statistics, and the others are in computer engineering, finance, and computer science. As such I not only took a ton of math, but studied and worked in the contexts you describe where stats is relevant.

The problem with statistics education is that it is generally heavily watered down, particularly the classes at the university level for business, psychology, and other majors that need the knowledge but aren't math or engineering majors. People heavily misunderstand the usage, difficulty, and nuances of stats education if they are only exposed on this level. It's better than nothing, but leads to serious issues that remind me a bit of the novice arrogant programmer vs. the grizzled veteran smart senior programmer. Generally, most people I see with limited stats education come out of it thinking mean, median, normal distributions, and at best linear regression are the whole of stats.

Another problem that also related to the parent with regard to stats vs. calculus is that calculus is actually a pre-requisite for most useful statistics work. It is true there are plenty of topics in stats you can cover without knowing calculus, but you are at a severe disadvantage and won't really understand the "why" and just be regurgitating the memorized method. I feel a lot of statistics is a combination of the "why" and "how" because so much of it is applying math at a more discretionary and opinionated level, like is done in science. Really learning stats requires a lot of math, from advanced algebra to diff eq possibly to matrices to calculus. To do good work in stats, you need a lot of tools to draw from, otherwise you're stuck with tools that often don't work (common example is people who only are familiar with normal distributions and nothing else).

Yet another problem with stats is that you can really make up whatever you want when you conduct statistical applications such as an analysis. The rule is that as long as you provide justification and proof for what you are doing - i.e. how and why, it is acceptable along with some text to explain. This is why good statisticians do things like describe and reveal their sampling methods, explain what did and did not work, and why they selected various tools. Obviously most dubious work can be quickly disputed and identified by someone who knows what they are doing, but the reality is that so many people never follow-up, fact check, or even read anything but the conclusion.

Stats is in so many ways about showing the process and justifying your answers than the quantitative answers. This is similar to financial forecasts as well for example which also use a lot of applied math, and people just believe what they read even though the evidence to disprove the report is right there. The science comparison applies here too. Just like with research studies, a lot of people don't check, verify, and re-run the results so people just believe what they read or rubber stamp it. I recall I had a very mean professor that once gave a final exam question that actually could not be solved at all using the methods we learned because the types of analysis and models we were asked to try to apply were invalid for the data. The simplest version of this familiar to many people is trying to create a best fit linear equation to non-linear data - simply draw it on paper against a data plot and you'll see it makes no sense.

If there's one important thing I learned in stats, it's to be skeptical and prove things with evidence. Nearly every time I watch the news, read an article, etc., I go nuts because they are making huge conclusions without giving you a way to understand who, what, where, why, and how about the study. The presidential elections in the US are an obvious example I see a lot with things like "Survey Monkey" passed off as scientific data in some contexts. Even represented as a casual, unscientific process, such things can be dangerous because people still accept statistics at face-value usually.

In summary, yes, people should learn statistics but it requires a lot of hard work to develop the tools and analytical skills to do it right. Like calculus, it can require many courses which can equate to years of study. Like anything, the skills involved also tend to get better with time and increased knowledge. At least an extra course or two beyond what is taught now would go a long way, but people really need to emphasize more than stats as repeating some processes of functions, formulas, proofs, and such, and more as a way of thinking and set of tools. Stats should teach you to be very paranoid and skeptical, and verify what you see in the world around you as best you can before you believe it. Once you do that, like the parent says, you will see so much clearer what is true, false, dubious, could be better, etc. in the world around you.

What kills me about a lot of the technology we use today is that few people, at least in positions of power are brave enough to pause every now and then and say, "WTF are we doing?" So many technologies live on because of so-called "critical mass," big investments, marketplace skills, and other things that are about anything other than the technology itself. These of course are mostly practical reasons and important ones at that, but at some point it becomes impractical to continue to cling to the practical reasons. IMO, the ability to do something truly different to make an advancement is often what separates innovators and intelligent people from the rest. When someone does try to act, the market essentially crushes them accordingly, making most efforts null and void, and dulling the senses and hope of everyone else watching, warning them not to try anything themselves.

x86 CPUs, web browsers, popular operating systems, and so on are all examples of this problem. At some point I really wish we could do something different, practical reasons be damned. It's sad that as many cool, "new" things we have, some of the core, basic ideas and goals are implemented so poorly and we are effectively stuck with them. This is one reason I hate that almost all software and hardware projects are so rushed, and that standards bodies are the opposite, but with only the bad things carried over. The cost of our bad decisions often weighs for much longer than anyone could imagine, just ask anyone who has designed a programming language or something major in software ecosystems.

As much as I enjoy all the new, shiny stuff, it makes me sad thinking about BBSs and old protocols Gopher that represented the old guard, alternate routes, and the fact that we really haven't come that far. Overall things of course are a lot better, but in many ways I often feel like we're treating the symptoms and not the cause or just going around in circles.

I could go on, but the rant would be novel length.

I have similar gripes with Go. I really love programming with CSP techniques and Go does a good job of implementing a lot of this at a lower-level. Clojure also draws from CSP and from Go's implementation of CSP, but lacks some of the nice things Go has going on here at lower-levels, however I end preferring Clojure for so many other reasons. I still would not shy away from Go, but it's far from a perfect language and doesn't really improve on a lot of things that similar languages don't do well.

I think it's not just Google, but the cult of Rob Pike, Ken Thompson, etc. I appreciate their work on so many things, so I don't mean any ill-will. I was a user of ACME editor and Plan9, but just like those projects, Go has so many polish issues in critical areas. The package management alone is ridiculous. The common theme in all these projects is for every good idea, there is an order of magnitude more critical mistakes or divisive ideas that cripple the end result in some way.

Go is alright, but it's not really that interesting to me or a monumental leap. There are a few ideas that others could cherry-pick and put into much better designed languages to take it all a step further in my opinion.

I have felt some of the pain and gripes you have with Clojure and while I am not denying that some of them are very real, I am not sure if you understand the mentality and philosophy behind Clojure as far as most of us who use it seem to have decided at least. Put succinctly, it is to balance practicality with features to get real work done.

Clojure is quite wisely based on the JVM because the idea was not to create a Lisp replacement or a new Lisp, but rather a practical Lisp. Some of the historical problems with Lisp and many other languages like Smalltalk were related to specialized hardware, development environments, and/or ecosystems. Clojure did away with most of these concerns by attaching itself to one of the largest existing environments.

Using the JVM was a wise decision that has/had many advantages not limited to:

- Ability to leverage an already huge ecosystem of libraries, tools, servers, etc. that are well-tested

- Already battle-tested and working package system - this is severely underestimated by some popular languages

- Justifying its existence as a tool along side other JVM languages within an organization, not a full replacement

- Existing, highly optimized JIT

- Reasonably fast, nearly for free

Originally there were some plans to expand more to other environments, for example the CLR, but the JVM got the most attention and in the end this was practical.

As for some of the real drawbacks:

- Clojure alienates Lisps zealots and people who could never grasp Lisp. IMO, this is a stupid person/psycho filter so I don't see it as a drawback but it's worth noting.

- Startup time as you note. Startup time sucks, but it has gotten better and there are workarounds that are the same ones you could use for Java apps traditionally. The mobile dev issue you note is somewhat wrong and without a huge explanation, one option is to more or less enjoy a huge part of Clojure via ClojureScript, or in other words, targeting JavaScript and using things like React Native.

- Garbage. This is an issue of a lot of things on the JVM and Clojure is no exception. You can work around this somewhat with specific coding practices if you need to, but yeah, Clojure isn't going to be good if you can't fathom an eventual garbage collection cycle.

- No TCO, which is mainly a JVM issue if I remember right. This would be great, but it's a tradeoff and Clojure has negotiated this somewhat by providing what I feel is more readable code than when I worked in certain Lisps.

- Some legacy baggage in the standard lib, for example Clojure.zip. Recently they've been more brutal about what can and cannot go into standard libs. Every language though suffers from this a bit.

Regarding developing its own VM, I think you again miss the point about practicality. If Clojure did this, it would have been even more years before its release. Moreover, comparing to Lua is a bad example as it is a very different language (yes, I used Lua professionally). Lua achieves a lot by really keeping it simple, and while there is merit to that, Lua leaves a ton to be desired which I won't get off-topic about here.

So Clojure could work better in its own VM, but then you'd lose the JVM ecosystem along with many other things. I personally would rather have the ability from the beginning to reach from a huge amount of libraries rather than have nothing but what other people writing the language provide or via crude things like calling back into C. There are many talks about all of this, many from Rich Hickey himself. I think you really missed the point of Clojure and I am more of the mindset that I am glad it exists and not in an ever state of flux so that I can use it today, get things done, and not have it relegated to some research language I could never justify in a workplace. And no, I am not a Clojure zealot, I used about a dozen languages in any given year depending on my project and interests. There's a lot I prefer in Lisp over Clojure, but I see Clojure as taking some lessons from various Lisps rather than trying to be the one true Lisp.

I agree with the parent about "new features" and I'll add a few things.

I can't stand the mentality of old = bad or not popular = bad. Most of the time, like anything in life, things don't "win" for being the "best" technically or for the most merit. There are usually many factors at play, and marketing, misinformation, stupid people, timing, and more have a huge role. While some of these factors may be good reasons, for programming, many of them are rubbish. We go down the bad paths more than the good ones in computer science it seems.

There are countless technologies that were way ahead of their time and for various reasons didn't end up market leaders today. Lisp is one, Smalltalk is another. Even Object Databases and various permutations of "NoSQL" databases existed for a long time. CSP is yet another that is being "rediscovered" via Go, Clojure, and some other languages. The list goes on for hours. Whether it was/is hardware or many other reasons, these things didn't "succeed." Despite that, it doesn't make a technology or idea useless if it's a good fit for the task, nor does it make it worth ignoring, not learning, or improving.

If there's one thing I've noticed from my considerable years in software dev, it is that most people are wrong most of the time about most things. Look at science - the field has historically been full of naysayers, people who cling to the past for their own agendas, saboteurs, fools, politically or religiously motivated morons, and so on. If we just always went with what the masses say or for that matter, even the so-called "experts," we wouldn't have any scientific advancement at all. Looking back in science, we can also see that many people had discovered or nearly discovered quite a lot. Although somehow we eventually unearthed some of these discoveries, the advancements they created never came in their lifetime or even century or eon.

There's a lot wrong with modern Lisp today, but most of the foundations are solid and it gets pretty tiring of people using Lisp like a pejorative, especially if it's because they lack knowledge about it or do not understand it, or perhaps worse, have never used it.

I agree with this completely. I started with assembler, moved on to C, Lisp, Fortran, BASIC, Pascal, and C++, and then many more from there. It never mattered. Sure, I sometimes used the wrong tool for the job and made life harder, but those experiences shaped me.

You can make mistakes and you will learn from mistakes. You can build a house out of cardboard and it might not be a good house, but if it provides you shelter and you call it a house, it is a house. Don't get caught up in the cult of programming language. The good thing about this cult is when you meet people who say, "I am an <insert language> guy," you can turn on your skepticism detector to an extreme level or pretty much ignore them by default because they are either stupid, inexperienced, naive, or living in some bubble that probably won't be the same for you. The tools analogy really does work rather well - you can pound in a nail with a set of plyers, but hey, why would you and why wouldn't you invest in buying more tools when you can afford it?

Getting things done, failing, learning, and problem solving are what you want to be doing among many other things that have little to do with language choice. Don't be too ambitious, just stick with it and get things done.

While I wish more people were better at programming, the truth is you don't even have to be good to succeed on some level. I wish it weren't true, but if you saw the source to most games, you'd cry. When you go up against time, budgets, other people, technical limitations, and more, the end product suffers, but to most people, as long as it succeeds doing whatever they deem valuable, then you won.

Parent really gives good advice to start small. You want your gratification loop to be as constant as you can make it. Trying to build Minecraft, Skyrim, Call of Duty, whatever as your first game might be an option for a few people, but for most it isn't. Don't try to do it, just get things done. If after awhile you see that maybe you can't seem to learn other languages, which does happen with a lot of people, I'd say that maybe it's time to look elsewhere for a career.

I'm going to be blunt, almost all the comments thus far suggesting a specific language are wrong. This happens everywhere, every time someone asks this question. I would instead pay much more attention to anyone speaking generally about problem solving and learning. I've learned countless programming languages and eventually you'll get to the point where learning a new one is just a matter of spending some time with it on a project. You're not married to any language ever unless you're a terrible programmer, so you can always switch to something else and at most, you've lost time.

My suggestion would be to pick a problem, analyze the problem deeper to see if it's even worth solving, then proceed from there. That alone is a huge subject, but it's really what you need to be comfortable with if your goal is to be a programmer. If you simply want to have a language or two as tools (ex: scientists), then sure, dive right in, but you will forever be stuck at a certain level if you approach things that way unless you are really lucky or really brilliant (most of us are not). Otherwise, take the time on the problem you want to solve, first and foremost, every time. The problem generally (obviously some exceptions) has little to do with language, computers, or anything technical, even if the problem is actually focused on a computing topic. If you still want to solve the problem after doing things like figuring out who/what/where/when/why, then try to pick the language(s) and tools that best fit the problem. Unfortunately it is hard to do this without having programmed in a language yet, but you can at least do some basic research, reading, and so on to find the best tool for the job.

You will fail in this your first time, and probably your first ten or even 20 times. Most programmers fail in this their whole careers, so do not get discouraged. The best you can do is learn from your mistakes when trying to solve problems with technology, and try to do better the next time. Even if you fail to pick the "best" tool for a job, making a mistake will teach you so much and you'll build on this going forward. This also means you can always change languages if you think it won't work for your next project or you just want to learn something new. Getting things done, learning patience, solving problems, critical thinking, balancing everything, and countless other non-technical things are really what it's all about and learning them will keep you going. Language choice can save you lots of time, lead to better results, and much more, but it often is just a distraction for the average problem.

You mentioned you wanted to make a game. I would say 99% of programmers I have ever met say this and very few of them have gone on to make games at all, and even less, professionally. Saying you want to program a game first is like saying your first race will be an ultra-marathon with no training. I am not trying to discourage you, rather I am trying to be real and help you think about what goals you want to set for yourself. For reference, yes, my first program was a game, but this was a long time ago and I'd say it's a miracle I continued.

I have worked on games and game engines professionally and would be happy to discuss more things related to the learning process. To avoid being "that guy" who never gives any specifics and is just a contrarian, I will tell you the honest truth as it has been for a long time in game programming -- If you want to be at all decent at game programming, you must learn C and C++, and eventually at least a decent understanding of assembler would really help you. Anyone who tells you otherwise is wasting your time, lying, and/or has never written a game (why this is would be a huge post). You can be productive and write good games in any language, but if you are anything like most of us, one day you will want to write a game that is not just a toy, text-based, or a glorified web page. There's nothing wrong with those games if that's your thing, but I've rarely met anyone who has the long-term goal of writing those games except for spammers, crazy people, or unscrupulous people (ex: Zynga). Again, that's not to say your game has to be written in C or C++ (you can write amazing games in C# using Unity for instance), but having command over those languages still teaches you so much of how a computer works, how to optimize games, and will save you when eventually you'll want to communicate with things written in those languages and not treat them like a magic black-box. For the goal of being a game programmer, it's a good use of time even if you never write anything professionally in C or C++. It's less about the mechanics of C or C++ and more about learning how things work at lower-levels and expanding the size of your "safe" zone mentally. Likewise, you'll want to learn quite a bit of math for most game programming, be in matrices, algebra, geometry, calculus, diff eq, etc. So you may not even want to learn C or C++ as your first language, and that's fine, just know that long-term if you are serious about games, you will have to do that. The message is that you need to focus on computer science skills, not language specifics in order to work towards that goal, even when working in other languages. In the process of doing this, you will learn a lot more about what I said earlier - picking the right tool for the job, which means not just languages, but libraries, editors, formats, algorithms, etc.

Building a game, at least remotely well, requires quite a lot of skills that are far beyond a new programmer's abilities and it is nearly impossible to master them all in a lifetime. You need to learn the basics first and to understand your limitations and resources - you won't be building a AAA or even a nice looking indie game for a long time unless you are truly exceptional, lucky, or have a team of people doing it mostly for you. At best, you'll produce something that on the surface works, but your programming ability will suffer and if you eventually do work with competent people, they will think you are terrible or hate you. That said, building a game will require you to learn so many areas and thus teach you more than almost anything the best way - hands on. It's a balance of getting things done and doing them right, and knowing where, when, and how to cross that line is vital. When you first start, you won't even likely have any ability to filter out all the information out there that is wrong, will waste your time, is bad design/BS/awful. Some programmers never learn this, but this too is hugely important.

I strongly advise you to see if programming is something you even want to do first, figure out what you like to do, where are your deficiencies, and work from there to figure out what your role would be in game dev, where you need help, how to judge others, etc. A game can be a motivator to learn more and teach you things along the way, but it can also drive you away, overwhelm you, teach you bad habits that you will never shake, and generally lead you astray. As such, just writing simpler things that solve real problems might get you there faster and sharpen your skills better along the way, while ensuring you don't throw up your hands. You might be different, but that's the pattern I've seen in most people. Pick a reasonable, small problem you care about, match the tools, go from there, repeat, potentially with new languages after you get comfortable programming for awhile.

We don't really have many true standards, just pockets of consensus on best practices and collections of so-called standards that are quite often ignored. Thanks to better communication, I think it's safe to agree that these practices are more widespread. As a result, yes, quality for certain groups has definitely increased.

I think you underestimate the fact that a large number of people actually do not follow these practices, even those that know better. Further, it's hard to make statements about software quality, especially with so many moving variables like the increase in the total amount of people in the industry and lower barriers to entry. Regarding best practices, I am sure many people have stories about asking questions in interviews about a company's software development, only to be told, "Well we'd love to do X, but we just don't have the resources or time, so we do Y." Even people who know better do otherwise in addition to those that are ignorant.

I think at a conceptual level, many things have not changed. There have always been sets of new ideas and practices that people adopted, many times blindly. These are of course a mixed bag, but many so-called "best practices" are often abandoned later - fads are the norm, and while that's sometimes OK, it does not always result in "better" as much as "different." I think some people fail to realize that in the moment, it's all happened before, and all will happen again. We both learn from our past mistakes with new trends and repeat those mistakes.

MVC and frameworks are actually interesting examples. I don't want to get too into individual tech discussions, but I've personally seen people handcuff themselves trying to religiously implement things such as MVC and actually failing because of a pattern like that since they were distracted from solving the problems properly. Adopting a pattern or framework does not automatically produce better code and can even lead you the opposite way. It's hard to say if things like this are a win for all so much as if they are simply a good fit for certain problems, and therein lies the challenge and one that hasn't become easier. The golden hammer or wrong tool will forever be problems.

Frameworks often are oversold and are not standards. In fact I've found that for many projects I have actually had to abandon a particular framework long-term because it was just getting in the way for various reasons - performance, maintainability, velocity of change, conceptual failings, zealotry, etc. Frameworks can derail "bad" developers as you call them just as much as good ones. Frameworks often explode if you don't do things the "one true way" and "bad" developers can be argued to be prone to that just as much as everyone else, and simply adhering to these rules still doesn't always produce better software. There have always been frameworks in one shape or form, but they didn't always have names, sometimes they were just the language or tool imposing its constraints, sometimes for the best, sometimes the worst. As a counterpoint, I've actually found working in various languages like Clojure, Lisp, and Racket that tend to value composition of tools and functions over frameworks more productive, however I would never apply this to all projects and situations.

I see what you're getting overall at and on some level I agree. I was around in the 80s, and I don't want to go back to that. At the same time, for all the old problems solved, I see new ones that arise along with other things that were never problems coming to haunt us. It sounds like your experience is very compartmentalized to web development and you're projecting those views on to both the past and present. People are people, and no time, technologies, or tools will fix that, just deal you different cards.

I agree more experienced people usually get stuff done and it's generally been my experience. Of course there are always exceptions. The problem I see is that often it is not the output itself that wins, rather the perception around the output.

I've seen many talentless people rise through the ranks of companies or start their own just because they were good at bs'ing, marketing themselves, had a certain personality type, and many other things that had little to do with programming directly. Of course some of these things are important and valuable, but many of them are toxic, especially in a software development context.

Indeed, we've all observed countless startups that become industry darlings that don't even ever produce real revenue let alone profits. We can argue about what their output actually is, but often it's smoke and mirrors at best, fraud at worst. This all happens often at the expense of progress or another company that actually does produce value, but fails at playing the game properly (same applies to people). But these startups "succeed" at least temporarily because they create perceptions that one day, just with many more millions and many more articles, they will be great and rule the world. Whether it catches up with them or not is something else. Perception is the way so many things in life work, and particularly important to many companies, the stock market.

I think there are just so many examples where the belief that if you work hard and do good work does not hold. I personally value these things, but many people do not. It's a complicated topic I could ramble on about forever, but I think we've all been in these situations and had things happen to use like receiving praise for arguably our worst work.

If the parent is sarcasm, please disregard my reply.

> The stuff you did in software 20 years ago has absolutely nothing to do with the stuff that's being done today.

Not even remotely true. Most of computer science is built on the past and either composed into something new upon a previous foundation, or a poor re-implementation of an already existing idea. A trendy favorite of many at the moment, Go lang is a good example of the former. For instance, CSP used in Go (and Clojure) is definitely not a new idea and has everything to do with what we do today. Another example is data structures - not sure what you're doing if you aren't using these, but the most common ones were invented long ago and most newer things I see are just refinements, additions, or behavioral changes on what existed before.

Speaking of Clojure, functional programming and Lisp are additional examples of old things "we" used to do in software 20+ years ago and are very much relevant today. You are making blanket statements about research, practices, and more here. It's true that Lisp was not widely used in many circles, but there are numerous reasons for that beyond what you mention, many of which were not good ones. Many people outside academia used a lot of old concepts successfully or otherwise knew they were good but had other limited factors, most commonly hardware or market share.

I encourage anyone "inventing" anything new to simply dig through old research whether it is 60s Lisp weeny stuff as you describe or Plan9 or anything else before you think you invented something. 99% of the time someone has at least researched it, written about it, and maybe even implemented it better than you will. Timing is often everything, as are other factors like technological resources (hardware, people, market skills, etc.). Computer science, like many fields, excels at reinventing things poorly. It usually comes down to thinking before acting as very few of us are both smart enough and talented enough to produce something properly acting on impulses and limited knowledge alone.

> This is the drag&drop and copy-paste as an abstraction VB shit era.

And this has changed how? Look at what a lot of people use Google and Stackoverflow to do. Of course these tools are great, but so was the VB GUI designer. It's how you use it and who is using it. We have far more copy-paste style tools than ever before and far more languages that are suited to producing unmaintainable spider webs of awful.

> People were writing C and the major problems of the industry were how to fit shit in to x MB of ram and x CPU cycles.

What are you doing now? People are still doing this constantly, not only for embedded programming but for games, apps, everything. Just about every month there are multiple posts on HN about people patting themselves on the back for shaving memory and CPU cycles off their code on a new platform and/or running on something like commodity hardware. I know you want to say hardware wasn't as good, but it's also been my experience less people know how to manage performance properly and we still spend a lot of time cleaning up messes, only they are on the gigabyte level instead of the byte level.

> Security was abysmal - you didn't even have process isolation on OS-es.

Not all OSs worked this way. True, the popular ones were often pretty bad. They are still not good and with more stuff accessible faster remotely, even more malicious actors, and bigger consequences, the situation is arguably worse.

> Unless you were at one of the cutting edge places that were actually innovating back then in terms of process and stuff there's likely nothing from that skill set that transfers on to the problems that we are dealing with today beyond the CS grad basics.

The same holds true today. If you only do one thing, you won't be good at programming except perhaps in that narrow field if you are lucky. If anything, it's been my observation that far less people know what they are doing as the barriers to entry into the field have gone down. Not everyone who once upon a time wrote C, COBOL, Lisp, Fortran, or whatever else learned nothing along the way. Plenty of people pivot and do amazing things.

Overall, it sounds to me you are the one who lacks the depth and breadth of experience. You need to meet more people, keep an open mind, and do research before you make judgement. Moreover, you need to avoid blanket statements (appreciate the irony).

No, you are missing nothing. But I can relate to the sentiment and point I think he is trying to make which is it's not worth it burning yourself out working on code all day, be it games or otherwise. Life seems much better when you start living it rather than just letting it pass you by while you are at work.

Regardless, I find the writing and style to be dreadful. I was hoping for something about the drawbacks of Unity the company or Unity itself as an engine. All I can find here is what amounts to a drunken urinal conversation.

Often libraries are far too specialized to share or as you point out, have dependencies/licensing that prevent open-sourcing/sharing.

For example I've written various entity/component allocators, pools, and free-list implementations that run ultra-fast and are reusable across almost any game that needs an entity system, but almost each one is optimized for the performance characteristics of the target game. When it comes to game dev, you generally can get much better performance by writing things for the purpose. Usually reusability and performance are at odds in these cases. That might sound counter-intuitive to some in the web world, but it's a fact.

Even in website, you are better off doing things for example like pooling in garbage collected languages, avoiding extra allocations, and using more primitive data structures. This of course makes the code harder to read, test, maintain, etc. so developers in these cases tend not to do it or even be ignorant of these techniques. In games, you do things all the time for your specific use-cases and this really impacts testing and reusability.

It sounds counter-intuitive, but over the years I've learned in most cases reusing things in games is a fantasy only inexperienced developers get hung-up on. That doesn't mean nothing gets reused, rather what tends to happen is you learn from your mistakes/drawbacks of previous code and rewrite it better. In effect, you are reusing the code but it's not a literal drag and drop/cut and paste into a new project. Over time, if something is really solid and doesn't have too many performance/usability drawbacks, it may finally make its way into some sort of cross-project more drop-in library. An example I've directly used EA STL. Even when you reuse something though, people tend to do the equivalent of fork it per project, again limiting reusability.

I suppose in the age of better hardware with tons more ram, some of these concerns may be going away if your target platform is PC, but with mobile, more resource starved vs pc (ex: Nintendo 3ds) and embedded-like platforms gaining popularity, inevitably things circle back to the direction of optimizing per game and per hardware which hurts reusability. Is it really that valuable for example to dig up some library you used one 1 game in the lifecycle of the ps3 when you've already moved to the ps4 for example? Probably not for most developers unless you have a large window between your game start time and the platform lifecycle. Even on PC this is a problem as everything from graphics APIs to average hardware can obsolete a lot of what you've done or make it relatively inefficient/primitive in a new project.

I've worked in game development in various capacities since the 80s. While I agree with your sentiment, a lot of your points are incorrect and I feel deserve a response. Sorry about the length.

Firstly, the reason why people didn't/don't use the STL is for a long time it was garbage for games. The data structures and allocators were huge offenders. If you've done any real game development, especially in the more resource constrained days, used std::vector was terribly inefficient and made no sense. This is why studios all wrote a lot of the same lower-level code. As to why they didn't share this code, it's just the nature of the business, however a lot of the performance of certain libraries over the years was highly tuned to the individual game.

Generally, games don't generate much reusability. Formats for assets change over the years, compression improves, resolution goes up, music chips improved, and so on. Even today things might have slowed-down, but programs used to produce assets make the level of effort of rehashing old assets not so worthwhile. Game studios that have tried to reuse things were often criticized for recycling when detected. The irony here is that this is actually justification for what you are saying - the assets aren't worth much long-term, so you might as well give them away along with the editors and level construction.

An important thing you're forgetting though is a lot of editors and tools used in game development are very one-off and shoddy. As a studio, you simply don't have time to sit there and write a perfect UI or even unity-like UI for your tools. Sure, it happens sometimes, especially when a tool is upgraded game-by-game, but generally tools are fire and forget and often given to the lower-skilled team members. I've rarely worked with game dev tools that were not full of bugs and woefully incomplete, but this is just the nature of the beast when you have limited time and budget - you don't spend it all on making perfect tools. This alone I suspect prevents many studios from releasing things to the public because the tools are very fragile, buggy, imperfect, incomplete, and so-on that it's almost embarrassing for some to see the light of day and too much maintenance for the benefit for others.

Regarding engines, I'm not sure what the gaming public's obsession with engines is. For well-tooled and documented engines, you have various degrees of offerings these days ranging from Unreal to CryEngine to Unity to other smaller, but still good engines. Those games with "custom" engines are probably no where near as useful. Sure, releasing the source would allow customizing and modding an individual game further, but again there's a lot of factors that go into this ranging from incomplete/broken pieces to game-specific hacks to lack of testing and so on. Unless a studio is in the business of releasing game engines and tools, it's hard to justify the risks. Often the copyrights and other things are not even owned anyway by the people who want to release them, so there's nothing you can do for example when your parent company or publisher views each and every line of code as some secret intellectual property.

What really bugs me though is why people think that game engines are some magical thing. What is a game engine even? In my experience, in many game codebases it is hard to draw a line between "engine" and "game." Sure you can set out to do this from the start in your architecture, but most of the time it won't happen that way when you are under the gun. The best you can do maybe is circle back and architect/extract things better post-release, which no one generally gets paid to do (unless selling the engine). Even then, the engine is not some magical thing that makes the entire game work. An engine can be anything from a way of handling assets + some graphics libraries and input handling to only graphics libraries to a stack of glued together middleware and other libraries. You don't just plug-in assets, components, and a few lines of logic and hit "run." Although I've worked on things that resemble this and those tend to be the better designed systems, the truth is in especially older games, that doesn't happen. Even when using things like Unreal, a studio may plug-in their own pieces where possible and the line between what is and is not the engine gets blurred. You can definitely release a lot of it as a package that will work for the intended purposes of things like edit levels and characters, but often there's so much cruft and code-stink, it isn't easy.

In general, some of the most elegant and some of the worst code I've ever seen is in games. The goal of most game studios is to release a fun game for profit, not to produce beautiful code and mod tools for the community. For whatever reason with games, fans forget how programs work and the fact there are real people trying to make a living behind all of these. Sure, many game programmers would love to see their work used even for free and would even donate their time to help out the community, but it's more of a fantasy than a reality. I'd work on 1000 things if I didn't have to worry about putting food on the table and I wager most other developers would. At the end of the day, even though it is games, it's still a job and people and companies have only so much time, money, and legal options.

Yes, exactly. Every time the food and delivery complaining starts, I roll my eyes, almost as much as I do when various food startups preach that they will disrupt and revolutionize the way I eat or whatever thing I do that is not so broken it needed fixing vs. almost every other problem.

Generally speaking about delivery, tipping, restaurants, food service - treat people well, as humans, and if you order something you do not like, either try again or move on. You don't always win in life and it really is not a big deal unless you were mortally wounded or something truly terrible happened.

Regarding tips, here's an interesting thing to try for when you are unsure - ask. Delivery guys and restaurant workers are people. Most will answer honestly about their working arrangements, especially if you explain yourself. They are people like you and me, and most likely they work just as hard as both of us. These people normally do deserve a tip for good service, even if they are paid in part.

A simple example - if someone needs to come up 12 flights of stairs or take the elevator to floor 14 for you, while still managing to deliver many other orders on time, you do in fact owe it to them to tip them. While you might tip less if they are already compensated on some level, you should always reward anyone for good and extra service. If it's too much with tip, don't order deliver. Get up and get it yourself. Why is this so hard for some other commenters here to understand? If the service is bad, you can say so or simply not tip and not order again.

Someone mentioned delivery vs. pickup - I've lived in countries where there's no opportunity to pull up your car, SUV, land boat to pickup your meals. You either buy it on the street and eat there/walk it home, or get it delivered by someone usually on a motorcycle or bike. Delivery is a privilege and a service, so you pay for it.

As far as tip amount, in some countries, you tip a lot less than the US. But you also tip more kinds of people and act more civil to people doing things in your life that are not generally tipped in the US - plumber, electrician, etc. For instance in Israel, it is extremely rude if someone comes to do home repairs, plumbing, movers, whatever to not offer them a cup of fresh (not instant unless they ask) coffee/tea/beverage and possibly food in addition to paying the full fee. In fact, you offer them at the beginning; they are a guest in your home, so you treat them warmly and you will receive warm and diligent service in return.

Regarding the systems food companies and restaurants use, wtf. If you can't run a solvent business without cutting all these corners, then don't. Treating people badly and not paying livable wages should not be an option. If you cannot afford to pay and treat your workers fairly, then you simply failed at you business. This capitalistic notion of cutting corners to win, because everyone is doing it, or whatever else is silly. I could have won at Monopoly that one time, but I needed to pass Go on more time. Deal with it.

Finally, if you have a bad experience, solve it in a normal way. Talk to the business, do not order the same thing again, order from somewhere else, etc. What you don't do is throw a tantrum and especially in food service, come to quick judgements about nothing. Listen, I've often ordered bad Chinese, and that's just part of life. I eat the bad Chinese if I can, and then try to remember to order something else or somewhere else the next time. None of this is complicated - don't be a dick and learn to live with consequences.

No offense, but I would venture your food does not taste so good and a lot of what you are saying sounds like someone who is grossly inexperienced. Burning garlic and onions is the sign you are not a very good cook, for instance. That's cooking 101 and should never happen. That's like burning scrambled eggs - easy, but a sign someone is a very bad cook.

There's a very good reason chefs generally do things in certain orders, and it's not just consistency and cook time. You did not "figure out" what billions of people before you could not. A lot of the reasons why people do not cook things as you describes have to do with basic chemistry. Chemistry is what you are really neglecting given your 3 categories - things like caramelization, absorbing flavors, catalysts, reactions. Not all your choices are bad (cast iron is great), but many have consequences for flavor (coconut oil is tasty, but strong, and has a high smoke point) and others are just head scratching.

I don't even know where to start with your cooking technique, but let's discuss sautés. Firstly, you do not have to cook everything together, at the same time, same temperature, all mixed by the end. I know this sounds counter-intuitive, but some of the reasons around cook time and temperature are there precisely so things blend together well. Other reasons include removing things like water, salts, bitter tastes, etc. from food. For example, you can actually often cook your meat first to some level such as a simple browning. This will season the pan nicely, allow you to do things like sear your meat correctly, and provide some tasty fat to add flavor to your veggies while they cook. Later, you can add back the meat to finish it off and make sure it's safely cooked to the proper temperature. Your way of cooking meat is not always wrong, but for many dishes it will often have consequences - soggy meat, veggies overdone, meat not safely cooked, lack of flavor from fat, no sear, textural issues, and so on.

Pretty much the same applies to stews. For one, many if not most stews taste infinitely better if you caramelize a lot of the veggies directly in your cooking pot, then pour your liquid base on. Never mind you seem to be making stews generally without any concept of stocks and using things like butter as thickening agents (shudder). Too much water is definitely not a good thing for stew and something that is not easy to fix. Thickening stews is somewhat of an art, but there are also many well-known ways that don't involve what you describe.

I've already written a novel, but I highly suggest you buy one of those textbooks from a cooking school (CIA for example). You may look down on professional texts, but cooking is one area where learning the academics are very important. While there's always room for tweaking and personal touches in cooking, completely ignoring cooking techniques will get you no where. I am sure your food makes you happy, but if you want to challenge yourself and grow, you should really do as I have suggested and buy some books. I do not mean to harshly criticize you, but rather you seem someone interested in cooking that could maybe enjoy it more but lacks some basic knowledge to be a better cook.

I agree that is what the parent is talking about, however in the context of GCE, Google Cloud Services which include App Engine and a whole slew of other services are relevant. Given that if you've used them, there are integrations and even shared admin areas/dependencies, it is very relevant to talk about how other services perform in the Google Cloud.

Maybe this is preference or something changed since I used GCE daily, but I disagree on almost all these points.

* Documentation - On the surface, GCE docs always looked better to me until I realized how many mistakes there were and things out-of-date. Not to mention there was too much of the obvious documentation and not anything regarding subjects where I'd actually want detailed docs. Although Amazon's docs are trash, they have the benefit of everyone and their mother writing about how to do x, y, or z. Whether that's a benefit or not, it depends on the author.

* Console - The console was sometimes more responsive depending on the action, but for some things was worse. Overall I'd give this one to GCE as well, but I think the GUI was a mess in places. Perhaps that's more based on my total usage of Google Services, which are a superset of GCE. Regarding command line tools though, I felt these were awful, slow, poorly documented, and buggy. Again, maybe an update fixed some of this. Google has a really bad history with consoles. Amazon's GUI is 90sish at times, but it's been pretty good to me and the API just works.

* The answer to this one is really it depends on the machines, location, etc. GCE has some advantages here that are well documented, but performance of a running machine was never really a problem I faced on Amazon provided you select a good instance type.

* Can't argue here. Amazon does like to give out its share of freebies though if you are a big enough customer or paying attention to the community.

Any players are good that encourage Amazon to do a better job. I really think AWS improved since Azure and GCE came along. Moreover, when I dealt with Amazon on calls and in meetings, any time we mentioned the Google or Azure words, they immediately wanted to proactively respond (and eventually did). We were a customer of both their competitors so this helped, but I give Amazon some credit.

Regarding lock-in, I think you are right but everyone seems to be doing this.

I think for better or worse, part of what Amazon has done has been adapting what they already were doing in-house into a product. Sometimes when people just come up with products to compete or "just because," they add in a lot of nonsense and architect things badly. Microsoft seemed to be going both routes at different times with Azure. I was an original user of Azure including the various data stores/data stores they asked for at the time. To say everything on Azure, whether the machines, data stores, services, libraries, or anything else were horrible would be an understatement (might be one of the worst major platforms I've used ever). Amazing how they turned it around when they were sure they had to compete stronger.

Also +1, App Engine is terrible. I worked for one of the largest App Engine deployments for startups. We were Python, Java, and Go and all were terrible. I've never felt like a company was giving me the middle finger as hard as App Engine. It's a terrible product and a shameful dev team.

There's a million things wrong with GAE besides performance, but if we just focus on that, where to even start? When I first took my last job using GAE, I was able to improve the performance of one of our apps in my 2nd week on the job from requests taking anywhere from 3-14 seconds to sub 1 second. That sounds good, but actually the original authors of the app didn't really do anything too bad, it was just they tried to write a standard web CRUD app in Django.

The answer to improving performance was mainly to never query their data store if you could help it. Solid advice for most apps, only the queries were completely unpredictable. Pretty much the standard Google answer for all App Engine is to do everything in memcached. OK, again, fine, but then memcached started being unpredictable. Google Answer - we'll develop private memcached to let you tweak it more. OK, fine, but it's still not as fast as when we run memcached on AWS.

Even when we ran our site with 99.9% cache hit ratio, we still had erratic performance. We next switched things to do more on the client and ran an Angular SPA app. Again we saw benefits of course, but still things sometimes were slower than we wanted. Simply Google's billing API requests and their slow servers serving requests tended to be the problem, which was often something we had no control over. And that was basically the theme of other problems we had. We figured out the requests problems at the beginning FYI and told Google, and they simply said they would work on it, but actually over time things often got slower.

App Engine is a terrible platform and most of the benefits can be replicated by various libraries out there for deployment, versioning, caching, etc. or through admin panels in other services like AWS. If you want to lock yourself into terrible APIs that do things like intercept your POST and re-issue it as a GET, go for it. If you want to start building your apps around billing patterns rather than proper architecture, go for it (how can I do y instead of x to avoid being billed?). I could go on, but yeah App Engine is pretty bad. It gets you going from dev to production somewhat quickly, but don't many frameworks + cloud providers do that now? The only real benefit I found which you could argue is that you alleviate some of the security challenges, but that's assuming you trust Google's environment and configuration (which you have essentially no control).

I've been a big user of cloud providers, and left a startup a year ago that was a huge customer of Google (GCE, BigQuery, App Engine, Google Drive, etc.) and ran one of the larger GCE and App Engine deployments for startups. We ended up having a few fringe services in Amazon and moving a lot of new ones to Amazon. Eventually we decided to leave GCE as soon as we could migrate one of our main sites off of App Engine. I mention App Engine because it shares a lot of the same core issues as GCE in terms of pain points.

Why did we want to leave? Honestly, it was a combination of things starting with the hateful and broken App Engine platform (API, admin, everything) to the usual Google nonsense of cancellations, adding useless features, bad prioritization of bugs, lack of fulfilling SLAs, etc whether it was GCE or another service. After working with 2 startups that were based heavily on Google's cloud, I can't recommend them unless something dramatic has changed. I can go into more details in private and a few publicly but it would be a huge post so I'll mention only a few things here.

Suffice to say, I found GCE to be anything but friendly compared to Amazon at all levels. While Amazon has a confusing and sometimes horrible admin panel, it's been my experience as an AWS customer for a long long time that it just works most of the time. Most of the time sounds bad, but it is better than "rarely" or "never" we experienced with Google (more later). When something is broken, Amazon generally fixes it or even a primitive retry will suffice. If something was really broken, Amazon gave us free credit, while Google either lied or hardly budged on bills (even funnier since Google was one of our investors).

A related and huge problem we had was that Google tended to make platforms, libraries, features, and services very 1/2 baked. Google is perhaps good at ideas and maybe even better than Amazon at building a solid core, but there is absolutely no follow-through. Too many times we encountered libraries and services that were terminated or overhauled because something was fundamentally broken. Worse, we pointed out big problems months or years in advance along with other customers and the community but saw no action. Google's dev team would continue to pretend nothing is wrong until either terminating or going back to the drawing board. I've never experienced a large company burying its head in the sand as much as Google. I love Google search, but I refuse to use any of their cloud products with the attitude that I've seen top to bottom, from sales to dev.

Another very important point I think a lot of inexperience people neglect - AWS has great support when it comes to libraries and integrations. Pick x language and generally you can find at least a working version of a library for whatever service you are using, including new features. Google's cloud services in my experience are filled with broken, slow, horrible libraries, including the official ones. As an example, there was a really bad (probably still open) form encoding bug in App Engine with multi-part forms that's been broken since almost the start of App Engine (basically, anything non-Ascii got corrupted). It's never really been fixed despite multiple people giving Google tons of data, patches, and workaround. We even got on the phone with them about it several times. GCE has honestly not been as bad as App Engine in terms of fixing things, but it also lacks features and library integrations.

As an example of a more specific GCE problem, anything that has issues with multi-cast had to have tons of patches. There was a special adapter for ElasticSearch when we deployed it on GCE that constantly had to be updated, and if you read about it, you'll see it's mainly a GCE thing. Pretty much every service, tech, or library we used that was more serious had similar issues - there was always a workaround or feature you had to manually implement that you didn't realize you took for granted on Amazon. The deployment story just given the tools was always far better on Amazon for example, but that may have changed.

Then there's installing and developing against GCE. Most of GCE for the past few years was command line only. That's fine if your command line is well written and well-documented, but GCE is most certainly not. The command line didn't even really work on Windows and not even really with something like cygwin. You can laugh, but at my other company we did a lot of DirectX and Xbox development, and developing on other platforms didn't make that much sense. Unfortunately some people in our company decided not using AWS would be cool. Developing against GCE once you got things working was no treat and we felt we often had to write tons of new libraries to do basic things that existed somewhere in the Amazon stack.

As far as the documentation, Google's services are usually out-of-date and full of mistakes. You could argue the docs are better than what Amazon has, however Amazon has the benefit of the community at this point that generally can answer your questions quickly. Moreover, Google in its own documentation often brags how good their docs are, while simple things like broken links or deprecated features are usually all over the place. How hard is it to run a broken link checker at least? The community is a huge topic, but I'll add that support was so bad at some points that the official line was to ask on StackOverflow instead (fine, but you're a huge company with a tiny install base at the time, wtf).

GCE did (does) have an admin console in addition to the command line, but the early versions were very limited. The last GCE console I worked with was in-step with most Google admin consoles looks like an ASP 2.0 app. Most things in the admin console are far inferior to the command line and full of bugs. Even finding the right settings in the admin console are a complete nightmare and sometimes require you to open other Google Services that you would think have no impact on GCE, App Engine, or anything else, and yet do. They often re-arrange how all of this works, but then leave parts of the old sites still running, so you end up with crazy nesting, conflicting options and navigation, and randomness. Mostly you feel like some dev somewhere kept saying, "I don't feel like doing this, so I'll put this all here because I can." It all looks like a bad assignment done last minute in a computer lab for a comp-sci class.

I know I seem a bit harsh, but I really wanted to try something new besides AWS the last few years. I joined 2 companies that did exactly that (independent of me), and that ended up terrible for both. There really was not much I couldn't do on AWS that GCE could do, while AWS could do plenty of things that GCE could not do at the time. AWS was far more reliable, stable, and well-supported for us as well, along with my own startup, and my past companies. Given I was a customer of Google's for a long, long time along with Amazon's and little changed with Google, I doubt it is much different now. Maybe someone can correct me, but usually when we get into these kinds of debates, the person with high opinions about GCE and the Google Cloud in general has not been on it long and certainly has not hosted a serious environment on it. I find Amazon as a company somewhat repulsive like Google in various ways, but AWS for all its faults is definitely more popular for a reason still. I hope Google can push Amazon to make their platform better, but from what I have seen the last few years, GCE is half-baked and only suitable if you're throwing a few small or personal servers in the cloud without significant interactions between them.

I too hate the phoning home, so good point. I feel like apps in general, whether on my phone, ps4, anything are trying to do this in some form or another. I do not want improved recommendations, a "better" future experience, or anything else. I do not want to contribute to your analytics meetings.

I agree the Windows store apps are also terrible. There are still quite a lot of non-windows store exclusive apps that you might not use that work great on windows. Likewise, there are various cross-platform apps that also work better on windows.

In a second life, I've done quite a bit of side work in graphic design, music production, and animation. Suffice to say that while Mac OS and later OSX were dominant at times in these spaces, there were always periods where this was not true. If anything, Apple seems pretty evil to these users in the last 5 years. I've had very little trouble with my apps in these areas on windows, while on OSX my friends can't stop ranting about things that have happened to Final Cut Pro, Logic, Garage Band, and other apps. I still use the aforementioned and don't necessarily agree in all cases, but it is true for some people. It may be bias or laziness on the dev, but reality is reality - just the other day I got a new sound interface and it works much better on Windows than OSX, and I use it on both for different tasks.

I guess you don't like PC gaming or using a host of Windows only powerful apps.

Come on, I run OSX and various flavors of Windows, Android, Linux, and BSD at home. Use the right tools for the right job. Windows isn't so bad and is pretty stable these days. I actually have more problems with OSX doing stupid stuff after updates or Linux murdering my hardware/desktop every few months vs. windows. My primary dev env is Linux and OSX, but I still use windows for gaming, personal use, etc.

It's not hip anymore to just rip things because they are MS, closed-source, whatever. Grow up. Every OS does many things better than the competition. Acknowledge that most of the major OS's are pretty good and use the ones that do what you need instead of ripping on them.