Marriage is a statement of commitment. This is why we invite lots of people to attend and generally make a big deal about it. And the reason why the commitment is important is because it is intended to provide stability. If you find that there isn't stability; that one or both of the partners is cheating or abusing or an addict or whatever, then it makes sense to withdraw the commitment. But stability is important, and highly valued, because it provides a basis for raising a family, getting and providing an education, saving, making a home; all those things that society is based on. Obviously, that is the ideal, and not the reality for lots of people. And the difference between the ideal and the reality has always been with us, and was not an invention of the sixties or birth control, as some would have it. Otherwise, Moses could have come down from the mountaintop with at least one less commandment. And yes, you can build a great life and have a great future without the commitment. But generally speaking, it makes it easier to survive the inevitable rough stretches. As for jokes, I've found that my marriage has been much much better since I learned to laugh at our minor and normal issues. And maybe that's another reason for marriage jokes; the problems are something of an experience we all go through and it is a good way to share?

If its been a long time since you've worked as a 1099, and if you're not covered by someone else's insurance, you may be startled by the price of your health insurance.

The OP asked about Steve Jobs vs Bill Gates, not Apple vs MS. From a software perspective, Steve Jobs took the ideas from Xerox PARC and brought the desktop UI to the masses. Bill Gates ran down the street and bought the rights to DOS. Later on, Steve Jobs brought us the iPhone while Bill Gates was retired or something. I really don't think its even close.

I agree with you that there is a lot more to know now than in the 60s. More importantly, I think, things change a lot faster now. But to be fair, there's a lot they had to know back then that most of us don't have to think about at all anymore. In particular, we don't usually need to think nearly as carefully about hardware issues (memory constraints, timing issues) or lower-level software issues (how to write a quicksort algorithm or a garbage collector). We don't need to cram 8 different boolean values into a single byte that we xor to read the value from. We don't need to write code that modifies itself or overlays itself to save memory. And we don't have to wait fifteen minutes or more for an edit/compile/run cycle.

I think we're talking past each other. You keep talking about the price of BC; i.e. the conversion of BC and dollars. So I think you're thinking of BC as something you bought with your extra dollars and stuck in an account. If the value goes up over time, no matter how volatile it is, you're happy. To me, that means you're thinking of it as an investment. And of course you're right. If BC goes mainstream and demand goes up tenfold, your investment in BC should do quite well. But I'm saying that for this to happen, it will have to function better as a currency. I'm envisioning trying to use BC for everyday life, which is quite different than an investment, right? Here, volatility is a huge concern. No one wants the price of a loaf of bread to "be 10 BC today, 11 the day after, then 13, back to 11 and up to 20". And of course, you need to have a way to buy the loaf of bread without exchanging your BC for dollars every day. And the reason I'm thinking of BC in this way is because, ultimately, that is what BC needs in order to go mainstream, right? It's not stock in a company that makes revenue, or a bond with some revenue stream behind it. Right now, BC seems to have a niche in unordinary goods, as well as the occasional pizza. But as an investor (I'm assuming you are), I'm sure you want it to expand its market, right? In order for BC to expand its market and grow in value, ultimately, it has to function well as a way to buy and sell ordinary goods every day. Do you think BC can do that today? If not, what do you think will make that happen? What do you personally use BC for? Have you ever bought anything with it? Cheers

When I talk about stability of prices, what I mean is, if it costs X BC to buy a widget today, how many BC does the widget cost a year from now? If a widget costs me 10 BC today, 35 next week and 5 the week after that, it isn't doing a very good job as a currency, in my opinion. And I'm not saying that BC is no good because it helps me buy illegal items. I'm saying it seems useless if I can't use it to go and buy groceries, or gas, or pay my mortgage, or whatever. And I know there is some gradual adoption of BC for ordinary goods, and so some day maybe it will be more useful. But the endless splintering into me-too "currencies" doesn't help. It just seems to me that a lot of the excitement around this stuff is due to the investment angle or the philosophical angle. But in order to sustain itself, its eventually got to become more useful as a currency.

What is this "up and down" of which you speak? Oh, right, you are interested in how much BitCoin is worth in terms of dollars... A lot of people are also interested in crypto-currency's technical characteristics; blockchain, security, how they get 'mined'. To me I think the most interesting aspect in evaluating BitCoin is what can I buy with it, and how stable are those prices. I'm only a casual observer, but so far it seems like mostly I can buy illegal goods and pay off ransomware. If so, in this regard, I'd say BitCoin and all the rest are still useless (worthless?) to me.

I'm kind of surprised at the lacks of specifics on this thread. So far no one, including the OP, has indicated specifically what they like or don't like about Javascript or the tools and ecosystem that surrounds it. One of the things I find most amazing about Javascript is how chameleon-like it is. Folks have created TypeScript, to provide strong typing and a more traditional OO flavor. React and other frameworks rely more on its Functional Programming flavor. Other people have compiled Javascript source into such compact code that the recently released WebAssembly standard is only a minor improvement. People have even made Javascript look like the granddaddy of OO languages, Smalltalk (Amber Smalltalk[^]). Tools around Javascript also make the language extremely powerful. Flow allows you to find flaws in your code without requiring the explicit type declarations that TypeScript utilizes. WebPack and its many plugins allows you to not only minimize your production code, but you can even create hot-loaded modules so that your enormous web app doesn't have to all be loaded when the user accesses the first page. And if you're generating minimized code, make sure you also generate source maps, so you can debug it so much more easily. Chrome's built-in developer tools are powerful, and I rely on them every day, but occasional glances at FireFox and Edge make me think they have pretty strong debugging tools as well. There's no way to tell from your post what it is about Javascript you don't like, or how much experience you have with the language, and so its impossible to suggest approaches that might help you deal with your issues. And there's no doubt that Javascript continues to have its limitations. But it still seems to me that Javascript survives not only because it is the only game in town for front-end web programming, but because it is a remarkably adaptable tool that enjoys strong support from a large, vibrant developer community.

I'm inferring that you're one of the developers on the project, and not actually responsible for delivery of the product. So, my suggestion is to talk to the people who do have that responsibility, state your concerns clearly, briefly, and without confrontation or rancor. Suggest a couple of things that would be the easiest to do and have some positive effect (reduce or eliminate testing of trivial code, increase focus of the sprints on features). Even if the people with responsibility for delivery are the biggest proponents of the team's current methodology, they should feel some concern as they see the project slipping away from them. And so they may eventually inform the team that they came up with a great idea, which is to reduce testing and shift focus to implementing features (snark). So, seek out allies, state your concerns, and try to build your credibility. Culture is hard to change, though, and so ultimately it may come down to finding a new one. Good luck!

As someone else mentioned, there is a language called scratch, developed at MIT, intended to teach kids programming. Also, there's a fantastic thing for kids called First Lego League. Kids program a robot, using a visual language called Mindstorms. Along the way, the kids are encouraged to learn about teamwork and to develop a set of core values, one of which is "Have Fun".

Thanks for an interesting post. I looked at the list, though, and you've got rigidity listed twice... what's the correct list?

I've been teaching programming to my grandkids; 10 and 12 years old. I decided the first thing a programmer needs is a computer, so I bought them a kano (www.kano.me), which is a Raspberry Pi based kit designed for kids who want to learn about computers. The kano comes with a variety of things that can be used as a base for programming learning. The two that got the most traction with my grandkids was Sonic Pi and Scratch. You don't actually need the kano for either of these; you can play with them on windows or macs just as well, maybe better. For example, the version of Scratch on the kano is older than the version you can get online (scratch.mit.edu). Also, the online version requires Flash, which doesn't run on the kano, so you're stuck with the older version. Anyway, Sonic Pi is awesome; it combines programming concepts with music, math and science, and can be used to explore any of those concepts fruitfully. Scratch is also fantastic. It is a visual programming environment, with an immediate gratification that pulled my grandkids in enthusiastically. Shouts of 'Mom, come look at this', etc. Scratch does have some limitations, but it does get important concepts across, and there are a variety of pathways to more complex applications. For example, there is a similar but more advanced environment called Snap!. Or, the kano version of Scratch is written in squeak smalltalk, and it is possible to break into the smalltalk environment and make your own extensions, for whatever you want to do. I was originally planning on teaching them using JavaScript, but in retrospect I'm glad I stayed away from traditional text based languages for their first languages. The arduino sort of path others have suggested is also really cool. Its more of a hardware project path, which can be anything from hooking a camera up to the Pi, to making lights blink, to robots and other amazing things. For a software guy like me, though, its a little intimidating. Good luck!