Same here. I use Windows maybe once or twice a year, and it's always a pain. "Winux" won't change that for me and to be honest, I don't really want to support Microsoft. Sure, I think VS is a pretty nice piece of software, but that's about it - too few reasons to switch.
It did alright on PC. The problem I see there is that they had to reimplement it in C++/C# for other platforms, causing the updates to be way behind. Maybe I got that one wrong, but wasn't there some announcement that they'd switch to C++ in the PC version as well?
I'd like to add, though, that I don't generally see a problem with programming games in Java. I just prefer C++ for that, with portability being only one of the reasons.
Usually, game consoles and handhelds don't have a JVM installed. I don't see the point in porting (parts of) a JVM to these platforms for your games, especially considering the little benefit (if any at all) that would offer.
Ironically to what you mention, Java was designed with embedded devices in mind and particularly popular as game deployment platform for old phones.
Virtually any cheap phone (non-smartphone) comes with Java ME available. Nowadays you find Android and the millions of Java-based games on the play store.
It does, but I'm not sure if material design is ready now. There is qml-material[0] though, and it's pretty good. But: The last time I checked (maybe 5 or 6 months ago), QML/Qt Quick apps on Android took way too long to launch. I couldn't do anything about it, so haven't used it since then.
Nice, I didn't know they'd add the compiler. I tried it back then, during the commercial license trial. But it didn't make much of a difference, if any. I remember being in a hurry, though, so maybe I did something wrong and I'd love to give it another try.
It's always been slower, but I don't think that can be completely fixed since Qt needs to load all of its libraries. Anyway, it's still possible to optimize the startup to be very usable.
You'll want to use a splash screen implemented with minimal UI code (no widgets of any kind yet, just an image with a background). While showing the splash screen, load dynamically a minimal main UI and some critical services -- only the parts that will affect the initial view.
Then hide the splash screen. You'll have a small bit of time after the UI becomes visible and before the user will actually use it. You'll want to use this time to load the rest of your services and preload more UI components to avoid the creation lag on UI thread later on.
I've done this kind of three-stage loading on Android without technical users even realizing it's not a native app. Would I do it again? Not really if platform native code is an option. There are too many details one has to handle when imitating platform visuals and interaction.
Because beginners could get confused when seeing the operators in other people's code, for example.
I remember the day I first saw a '++'. It was a rainy night, and I was inspecting a colleague's for loop, when suddenly a '++' operator appeared. I asked myself, "What in the holy bacon of Zeus is that?" So I looked it up in my book. My head almost exploded, and I asked myself if I should quit programming immediately. It was simply too complicated. After four months of agony and pain I finally recovered and started programming again. And yet... Sometimes, when it's raining outside, the memories come back. Programming... No, my life will never be the same again.
Same here, I'm 26. The industry has changed a lot when people realized you could make a shitload of money with the web/scripting stuff. Coding schools, open source communities and huge companies love HTML and JavaScript and Python and Ruby for their simplicity. Just take a bunch of people, tell them they could make a lot of money by learning some dead simple languages and there you go. Doesn't matter if they write the most disastrous code in the whole universe.
Look at Code Academy, for example. They add new programming languages and technologies every now and then, but basically it's always the same. Just like their audience. They won't add C to that list, because that wouldn't work for this average not-nerdy-enough-for-real-programming audience.
Yes! JS, Python and Ruby are just "dead simple" "scripting" languages that only serve to "make a shitload of money" and aren't "real programming".
Real programmers (like me) use C.
Seriously, no. Just no.
And if I wanted to prevent people from writing "the most disastrous code in the whole universe", teaching C instead of JS would be much, much lower in the list than teaching how to split code into modules/libraries, write testable code, etc.
> And if I wanted to prevent people from writing "the most disastrous code in the whole universe", teaching C instead of JS would be much, much lower in the list than teaching how to split code into modules/libraries, write testable code, etc.
And for me that would be much much lower than teaching how to keeps things simple. The whole modern web has a bad case of over engineering, everything is modules of modules of modules, with so many tools associated you get a headache trying to install a simple JavaScript library (what is wrong with a download link and I drop the lib on my page, nothing that is what).
I'm all for modern approaches but I can't help but feel many developers have lost touch with what writing clean code is, it's not making module, libraries or even tests, it's making sure what you are doing is as simple as it can be and efficient at it. Sadly most modern web stack fail at that. All hidden in mumbo jumbo of modules and dependencies no-one really needed or asked for, often created by people who never questioned the purpose of what they were doing, or if the whole internet needed it (because you are at Google and have found a neat way to deal with your huge JS stack doesn't mean the whole web needed it too, and that you needed to spent a whole lot of effort making people adopt it).
As much as you make fun of C, learning and writing C will teach you to keep you programs simple and efficient, because the language requires it. And that's coming from someone who started programming with Perl, then PHP, and only learned C later on.
Makes thing simple not simpler should be the cardinal rule of programming, not modularize and test everything, those are situational, the former applies all the time.
I didn't make fun of C. I made fun of a comment posted by a C programmer, which is very different. I have absolutely nothing against C.
> C will teach you to keep you programs simple and efficient, because the language requires it
From what I've read, the OpenSSL codebase is definitely not simple, and I'm not sure it's efficient either—it would depend on how you define efficiency. So your affirmation seems factually incorrect.
Other than that, I agree with your post. Simplicity is awesome. No point in using Angular to build a landing page if static HTML can do the job just as well. (Edit: let me take that back. There can be a point: the pleasure of experimenting and learning something new.)
You write code that can be broken up finely enough into discrete, stand alone modules that can each be run through a series of tests.
For instance, you might create a model class, and then you know that model should have a name, shouldn't be able to be saved without a name, the name should be x-number of characters.
Then you can write a series of tests that makes sure that, regardless of how the model implements that name, all your assumptions about what that name should look and act like don't change without throwing a red-flag up to whoever is changing that model.
Say you want to test how a program fares when strings are malformed, or the disk is full, etc. It can be hard to simulate this if the code refers to variables and results from functions from all over the place.
Making code into reusable modules code is generally a good thing, but it's even better if you make them in a way that will help you test those chunks independently as well - that is testable code.
Usually it's about keeping it granular enough that various sub-activities can be tested in isolation. If you have one function with 10000 LOCs, that's not really testable beyond "something doesn't work".
Then of course you need some way to automatically run these tests, but that's usually provided by IDEs or standard libraries these days.
And don't forget to post it on HN in case you should publish something like that. It sounds awesome.