You've already proven to yourself that the tooling that you are trying to use is costing you time, not saving you time like you want.

Just don't use them for this project. Just build the project using what you know now.

You can pick up that new tooling again at a later stage when you aren't so pressured to deliver something.

99% of being a successful programmer is coming back tomorrow, and getting a tiny bit more done, and learning a tiny bit more.

You should divulge your personal aspirations because your company might actually help you achieve them.

It pays to start thinking about how your interests which you are a little bit afraid to share might help your career... because this is how you get your employer to pay for them.

It depends on the employer. I wouldn't say "I want to quit this dump and become a water colour artist and photographer". But I /would/ say "I think that studying some art subjects would really benefit my front end design work here".

I wouldn't say "I want to get away from you and write poetry" but I /would/ say "I would like to improve my written communication skills, which will really help the clarity in my correspondence with clients and in my detailed documentation and commit messages. Would work fund this course I have found"

If there is any cross-over at all between where you want to go and what benefits your employer, it's in both of your interests to put that spin on it and get them to pay for it.

The one-on-ones are only something to dread if you don't know how to ask for things in a way that is mutually beneficial. As you get older and more experienced in negotiation it becomes easier.

Remember, its "career aspirations", not "personal aspirations".

yeah.

And as a parent who has held back normal bodily functions for an entire day while they did all the "right" things for their kids, sometimes the safest and best thing for everyone involved is to sit the kids in front of TV and know they will stay put for 15 minutes, so you can go to the toilet and then cook their dinner.

Also, the other day our 4 year old told me he wanted to be a paleontologist so he can find bones and coprolite. He didn't learn those words from me.

He wants to find dino poo, that is a cool 4 year old!

Dora is kind of good for little kids. They learn some problem solving, get introduced to Spanish.

But for goodness sake, all of the programmes talked about here are ENTERTAINMENT.

While I certainly enjoyed the shows I saw as a kid, the current crop seem more suitable for kids to me (ie, more balanced in terms of gender issues, racism and violence). I would rather my kids watched what is available now, than what I watched 30 years ago.

AttributeError: 'NoneType' object has no attribute

isn't much better.

Java might not be perfect, but it does let you catch a lot of problems at compile time rather than run time, which is a step in the right direction. The alternative (run it and see) gets old fast.

While I agree - this particular alternative is worse - it's not the only alternative. I was talking about more expressive type systems, not less.

Java provides less of the benefits of static typing than many other statically-typed languages (even than others available on the JVM), at a much higher cost in required ritual invocations made to the type system.

Yes, there is a value in static typing, but that value is minimized when you have a type system that isn't particularly expressive and/or have to make add a lot of redundant code to satisfy a comparatively unsophisticated type checker.

Java may have gotten slightly better since its poor performance in cost:benefit terms when it came to static typing helped launch the surge in popularity of dynamic languages, but its still not a great poster child for the benefits of static typing.

> Java provides less of the benefits of static typing than many other statically-typed languages

Don't let Java's type declarations fool you into thinking that Java is statically typed. It's still dynamic typing, with merely some kind of type hints slapped on top to be checked at compile time.

And don't forget Java's type erasure. Still wondering how they could actually call that a FEATURE.

Was erasure necessary to maintain backwards compatibility?

Also what are you doing that you need type information at runtime?

Type Erasure is the reason you can't use builtin types as generic arguments. And in a lot of cases it forces you to cast.

And as type erasure happens very, very early in the compilation process, you lose a lot of static type information the compiler could act on or give you warnings.

No it wasn't necessary to maintain backwards compatibility. Type erasure was implemented to allow libraries to upgrade to generics without breaking compatibility with existing applications.

How is that not backwards compatibility?

The one is on a language level, the other on an application/framework level.