I get this point and am mostly in agreement with the intent. However, the US is also more of a service economy, which would lead me to believe we should tend to have lower emissions/productivity compared to other countries that mostly produce goods instead.
So I am curious if there's a way to associate emissions to different categories of productivity and see if we're more wasteful, on average, when it comes to specific parts of our GDP (e.g. using personal automobiles).
I'm not saying this in the self-hating way that I think is trendy for people in the US, but I am curious in the way that, if we want to improve, we could focus on specific parts of the economy that are more wasteful than others. (Driving would be an obvious one, hence the example.)
In 2018, 69% of the US GDP was Personal Consumption. The contribution from Net Exports was -5%. Yes, minus 5.
All you're really saying here is, "it's alright that our CO2 emissions are so high because we're also such greedy materialistic bastards". That's not a great argument.
GDP is a bad metric. It mostly measures how "good" you are at tracking wealth. Much of value in society is not captured by GDP.
I was raised by parents who loved me a lot and did a pretty good job raising me. Had they been delinquent and raised me poorly, value would have been lost, but the GDP would have been none the wiser.
But hey, this seems to be a fun project more than anything else. And working in such low-dimensional spaces with an obvious disentangled representation (only shot strength and angle matter) might provide intuition to beginners.
Never just an idea. Remove the "just". It is a realised idea and it was important that you execute the idea and, to whatever useful extent, finish it. Don't allow that negative wordplay. Don't make light of this and think there are no consequences in keeping that diminishing, passivity inducing "just".
Nope, but there was a stock increase that made my initial grant worth way more. There was no magic here. I was hired at a fairly established company, got a decent package and then sat around.
Oh sure that’s definitely true. I have a strong resume. At some point I just stopped having to do any work, and instead of trying to “fix” it I just went along with it. Another key element is there’s no way I’ll ever get promoted. I decided I don’t care. The difference between making 500 and 800 or whatever is sort of meaningless after taxes.
I'd love to be in that position. I have a strong resume too, and I'm more than ready to be rewarded for it with a high paying job which I can more or less cruise in. So count your blessings!
This needs to be higher up -- Nativescript is Flutter's biggest competition and IMO it's better than Flutter, because it doesn't require investing in Dart and switching to the Flutter "ecosystem" completely.
Yup, I used it on a client application the first time I used it and it worked very well. The project was finished a while ago, and Nativescript has made leaps and bounds in that time, it's even better today.
I used Nativescript-Vue[0] which has since been brought under the nativescript umbrella fully, and it was a great experience. Vue is drastically less complex than React and that translated to very easy app building.
I don't build mobile apps (I think the market is somewhat saturated), but if I had to, I wouldn't even consider Flutter these days (I've built a small app in that as well), or building natively (who wants to be an "android developer" these days if you don't want to specialize in it?) -- Nativescript all the way.
There's also stuff like svelte-native[1] -- Nativescript is a better platform to build on than React Native. Props to the React Native team for being the first to have the idea (same goes with the component-driven design of react itself, though arguably backbone/marionette views were first), but Nativescript is a much more flexible and easy to use solution.
You can[0] -- that's one of the upsides to the web as a platform, you get to use some familiar tools to debug the JS side of things.
Also, I'd honestly argue at you that development is so fast for Nativescript (especially when you start using Hot Module Replacement[1]) that you could get away with print debugging.
And again, another really awesome thing is that nativescript integrates really well with native code -- you can write your game/native-feature-heavy screen in native java/kotlin/swift/objc and just write every other screen with nativescript. Flutter makes that just a smidge harder to do because of how it integrates (drawing every pixel) -- it's possible[2], but my money is on Nativescript being better at it.
No but it introduces a complete shim of the native platform underneath -- as in your can write and execute JS that moves native code underneath. React Native doesn't support this currently (and has no plans to).
There's also the possibility of using vastly lighter weight frameworks, for example svelte-native[0] which should be quite a bit more responsive.
So it will have the same issues as react native and xamarin will have. What is interesting about flutter is how it doesn't wrap native ui elements, so you don't have to become an expert in all target platforms plus your wrapper platform to fix tricky bugs.
Also I think it's not responsive compared to native because it's javascript and a wrapper, not the specific javascript libraries you are using in between.
> So it will have the same issues as react native and xamarin will have. What is interesting about flutter is how it doesn't wrap native ui elements, so you don't have to become an expert in all target platforms plus your wrapper platform to fix tricky bugs.
This is definitely one of the best parts of Flutter -- the fact that they've done the tremendous work of making a framework that draws every pixel to the screen is amazing, but that's also a liability. Android/iOS has an ecosystem of things that you can
One thing I ran into during flutter development was that the SQLite library[0] did not support off-device use -- I couldn't even run tests locally without putting them on the device. Maybe that's changed in recent memory, but that really turned me off to it.
There's also the difficulty of acclimating to the BloC paradigm[1][2]. If you hear it explained it seems simple, and then you try to write some code with it and confusion ensues -- it's like flux mixed with FRP-style stream programming and that's the official answer from the Flutter team. Everyone is confused by it and it isn't the easiest thing you could do but the other answers aren't that great either.
> Also I think it's not responsive compared to native because it's javascript and a wrapper, not the specific javascript libraries you are using in between.
So that's the thing -- if you really need native performance (you don't, most of the time, especially most apps are almost web pages). You can write and integrate completely native views with Nativescript, and in fact you can build them with JS because Nativescript has shimmed the entirety of the native APIs -- you can write code like `const intent = new Intent(...);` in JS and get an android-native Intent object. Of course, you can also call native APIs easily when you need the power.
Exactly. Seems here that there’s tons of Dart fanboys in this thread forgetting that most people code to solve a business problem in the most efficient way.
What Flutter has achieved is impressive, but I don't think it's reasonable to classify Dart as a good language in 2020 off the back of it -- the competition is just too good.
Dart feels like an older java in a time when java doesn't even feel like java (with the recent versions, along with other JVM options). For example, try and check out Dart's JSON serialization story[0], it's bad compared to Haskell, Rust and even Go. Dart was rewritten (Dart1 was a train wreck) and Dart2 still doesn't have the features that are expected. Who rewrites a language but doesn't add non-nullable types[1]??
The Dart team is full of smart people, and what they've created is certainly a feat of engineering, but the competition is just tough out there. I consider Typescript to be a better language to write (in this same space, since it's an option for Nativescript), and would consider Swift just barely better, and of course on android you have Kotlin (or Go) as a choice.
At this point I'm generally curious, what do Dart fanboys mark as the strengths of the language over others?
Don’t get me wrong but I know a lot of people that don’t use the right tool for the job. And people here are very biased towards Dart.
I was a software engineer coding objc and swift at a pretty well known publicly traded German company. If it wasn’t because of typescript/js I wouldn’t have been able to build my startup completely on my own supporting backend, web, iOS and Android.
I mean I'm definitely one of those people, I have my unreasonable biases, but I just don't see (yet) the reasons behind the Dart bias. I'd love to learn more about it.
And yeah, what's crazy is that in recent time you could know tyepscript/js and actually build every bit of a startup (assuming you know the domains well enough)... Dart as an investment just doesn't make sense when you've got a language like JS (IMO best paired with Typescript) that can go everywhere.
[1] https://www.statista.com/statistics/270267/united-states-sha...