I think the intension was to focus on the 80% of functionality that people use the most and consider the remaining 20$ as not-useful, which is generally ok by me. I think it's still better than the feature rich outlook.
For me, the main annoyance is cc and bcc which I use quite often. Really, how often do you edit the subject?? more than once a week?
The foul language could actually do him good in the long run... "interesting things happen when Dave gives a talk". He can stand out of the P.C. crowd.
While it's true that threads are ok if implemented correctly, one needs to be smart to correctly work with threads, and still any concurrent code will be ~10x more expensive to write and maintain.
In my perspective lack of threads is a blessing because it takes this complexity out of the equation.
On the other hand, working with async callbacks also takes training and more careful thought of the bindings and closures.
For me, after 6 months with node, I can say that I like it. It's superfast, ample modules to work with, and javascript is very convenient for working with data.
As an outsider, it looks like MSFT does not grasp kernel performance as a super important feature of Windows. They add so much bells & whistles over the UI, but the inside sucks release after release
I'm not yet 40, just 35 with 2 kids. I don't agree with any bit of what you wrote.
1. As many people noted - experience is NOT obsolete. The same few concepts re-occur in every software language. You need to learn new APIs and new syntax, but that's total non-sense for good experienced people.
2. People with children have a better understanding of what responsibility is.
3. People with children usually spend less time on dating and going to bars :)
In my opinion, apart from the execution, there is a major problem with the concept. Why should I want to bother hashing my passwords, and then having to remember the password+that it was hashed with md5/sha1??
There are apps such as LastPass that pretty much solve the password management deal altogether, by choosing, storing and retrieving strong passwords.
IMHO, first of all, more thought needs to be put into the use case.
At any event, good luck and hope you'll find the path to succeed with your app(s).
After 6 intensive months with MongoDB to build my MVP, I just love it.
For sure, it's not perfect. Lack of joins is a shame, but can be quite easily solved outside the database.
But the ease of use and speed of development are such a HUGE advantage. Not having to break my schema into normalized relations and define it in the DB saved me literally days of work.
I can imagine a case that 1 year from now, when our product will be more mature, we'll be leaving mongodb for another SQL or No-SQL database. Doesn't matter. The benefit that mongodb gives us now justifies the costs the may be incurred years from now.
I've worked for 15 years with relational databases and for the recent 6 months with mongodb on my startup. For me, the agility of not having to define my data in advance, and "work" so much to explain the DBMS how my schema should behave is no less than a game changer in my ability to build the MVP quickly.
I just can't imagine having to invest all the labor in having to model everything I did with a normalized database and ORM.