rubber_duck

My point is that in a good code base types should be obvious from context. If you don't know the context then you will be slow (and make a lot of mistakes) no matter what the type say because you'll likely misunderstand the domain logic (context) unless it's something trivial. I would hate to work somewhere where I'm expected to randomly drop into micro services I didn't have anything to do with and debug/support them - sounds stressful.

Pointless typing and verbose code has nothing to do with writing code - it's all about code being readable.

Java type declarations can be 20+ characers - just scanning through the code and having to skip all that junk makes my eyes more tired reading through. Types are implicitly deducible when you know the codebase 90% of the time (and should be added when they are not), and if you don't know the context you will be slow no matter what.

I'm not saying Java should have introduced ground breaking features - I'm saying they made design mistakes that they should have corrected far sooner (var/type inference) and refused to add some basic features (lambdas) that would have made the code a lot better for it.

They did add those features eventually (Java 8) - about 8 years behind C# (since C# 3.0)

Not really - Java designers were just plain wrong and it took forever to admit it - things like local type inference (var) made the language pointlessly verbose for ages, and simple features like lambdas made the standard libraries terrible.

There was a 8 year gap where C# users could use stuff like enumerable operators while Java users were stuck in the stone age of writing loops for collection manipulation in a high level language ...

When you add those to the mix you're dealing with destructors, ownership, etc. so I don't see anything wrong with using stuff like unique_ptr/shared_ptr.

And C tends to reinvent object oriented programming with each library so you might as well use language defined classes.

So I don't really see the point.

You don't need to use stuff like concepts, or "showing off how smart I can be with template libraries" (looking at boost), but C++ has a lot of features that make it much more productive than C.

>The Java strategy of being very conservative about what you add to the frontend would have done C++ a lot of good after C++11 (or even before that).

Java lost a lot of mindshare to C# and Kotlin due to that "strategy".

I'd guess there is there is too much money in it due to the fact that central banks killed interest rates and started buying government bonds as needed - where pension funds would hold those they now need to search positivie returns and there's just not enough good bets there - would explain why the valuations are sky high

> and someone brings up the fact that ISIS used one of them...

They used Facebook, Twitter and YT for propaganda and Gmail for coordination (that thing about saving a mail draft on gmail instead of sending it), it's obvious the other side isn't using logic to make the argument (but beliefs, feelings or simply pushing an agenda) so using logic to argue back is pointless.

>Yes, it gains you some of the economics of factory construction and that you can start small and scale a location, but on the other side you lose that again because you lose the economics of scale that traditional PWR gets.

You mean they lose operational efficiency ? Economies of scale come from the ability to mass produce.

You forgot to mention the largest differentiator - eliminates the possibility of a global catastrophe.

Thing is this kind of design benefits massively from economies of scale, same kind of thing that has drawn the price of PV down and other green energy.

>As I said in another thread, the problem is not writing the SQL. The problem is everything else after you have written it (applying on deploy, automating for other's dev envs, rollback, etc)

What's wrong with migration managers ? They handle all you mentioned just fine. The only problem I've seen with this approach were when working on a team that didn't have proper CI flow, then it was possible for people to check in bad migrations and screw up branches, etc.

I've worked with both approaches in multiple languages, and frankly I prefer the no-magic migration manager approach.

Migrations automatically generated from model also mean your DB is tied to your app, which I'm not a fan of, if anything the reverse should be true, and the fat model approaches of rails are terrible IMO (I haven't used Django for anything serious in over 10 years so I don't remember how fat their model layer is - I know it has enough metadata to generate the admin CRUD but don't remember if it also encourages having logic on models).

The best solution I've seen is F# which uses dynamic type providers (basically compiler plugin) to auto-generate models from DB/schema at compile time, and yesql in clojure (clojure being dynamic and built arround working with data using SQL results inside of it is natural and amazing).

IMO watching a few sci-fi movies in 4k+ looks ridiculous - I start noticing the difference between CGI environment and actors and it kills the immersion completely, it goes from "that character is really there" to "this guy is larping in front of a green screen"

> I am really stoked for the future of programming languages, when localization is just a matter of translating some words.

My experience with localised codebases (in my native language) have been horrifying - like it or not terminology is developed in EN, you either get unnatural sounding "borrow" words and the translation is pointless or worse you get people coining new terminology nobody but them understands. Not to mention fragmented communities, knowledge bases, etc.

IMO localised codebases would be a regression not progress and I dread every time I see Chinese in a codebase (simply because they are a large enough market to split the dev community)

>Simply, if a restaurant offers 20 different dishes, it means each dish gets 20x less attention than if you had only one choice. Less fresh ingredients, less time perfecting the recipe and preparation. Serving only one dish makes things simpler and the restaurant is going to spend more energy making sure it is worth it.

One of my favourite places has a decently sized menu (would say 40 items on there including starters/sides/deserts) while they aren't "the best" at anything, it's really good and I love the atmosphere.

I like the flexibility and that I can invite anyone there since the selection is varied and quality is reliable. I can't call my vegan sister to a smokehouse even if their ribs are the best I tried, can't take my wife to a fish restaurant but my friends could be in the mood for fish, I have no clue what my in-laws will want to eat when I have to take them somewhere, etc.