I started programming in a time when the idea that the computer could keep track of your variable types for you automatically was a fever dream, so it's wild for me to see some programmers now throwing shade at particular langages for "not implementing proper variable typing functionality".
It feels like someone saying that low-fat milk producers are too cheap or lazy to put enough fat in their milk.
Fashion really does go in cycles.
Seriously, the best option is whatever matches the brightness of your screen to its surroundings. I read about this decades ago and it eliminated screen fatigue for me.
If switching to dark mode works for you, great. When I worked on a PC in a well-lit office all day, I would open a program with a white background, hold up a blank white piece of paper next to the screen, and adjust the screen brightness until it looked about the same as the paper. I did this once or twice a week because I was near a set of picture windows and I was affected by weather and the seasons, but in a room with more artificial light it would be "set and forget".
It seemed very dim at first, and several of my coworkers commented on it. It took a few days of resisting the urge to turn the brightness back up, but I got used to it and never went back.
My PC at home is currently set up in a partially shaded corner of a well-lit room, so I put a dim little light bar behind the screen to make the wall match the brightness of the screen and the rest of my desk/room.
Only Winsocks.
I hadn't heard of Kate before, so I can't offer much hands-on advice. I dug around and found a "handbook" here: https://docs.kde.org/stable5/en/kate/kate/index.html
Unfortunately it does look like you need to define a project to compile/run anything, which appears to require manually creating a .kateproject file in the directory as outlined here:
https://docs.kde.org/stable5/en/kate/kate/kate-application-plugin-projects.html#project-create
I had exactly the same problem when I moved from languages that were interpreted or combined the IDE and runtime environment into one, and starting to use languages which had their own external compiler. Unfortunately, open source project user documentation is often terrible for beginners (what I found above for Kate seems to be no exception), and IDEs often seem to be written by people who don't really expect anyone to actually use the included build options (to be fair, most folks seem to like using their own separate build utilities, so probably this is often the case)
If you can tell us which compiler or interpreter you're using (e.g. gcc, clang, Python), someone can probably tell you how to compile and/or run a single-file program from the terminal with a fairly simple command.
You're quite right! I didn't notice that.
I first learned about Java in the late 90s and it sounded fantastic. "Write once, run anywhere!" Great!
After I got past "Hello world!" and other simple text output tutorials, things took a turn for the worse. It seemed like if you wanted to do just about anything beyond producing text output with compile-time data (e.g. graphics, sound, file access), you needed to figure out what platform and which edition/version of Java your program was being run on, so you could import the right libraries and call the right functions with the right parameters. I guess that technically this was still "write once, run anywhere".
After that, I learned just enough Java to squeak past a university project that required it, then promptly forgot all of it.
I feel like Sun was trying to hit multiple moving targets at the same time, and failing to land a solid hit on any of them. They were laser-focused on portable binaries, but without standardized storage or multimedia APIs at a time when even low-powered devices were starting to come with those capabilities. I presume that things are better now, but I've never been tempted to have another look. Even just trying to get my machines set up to run other people's Java programs has been enough to keep me away.
I wonder when he last sat down and really played a game for an afternoon. Now that everything is plugged in and ready to go at the push of a few (spreadsheet-tracked) buttons, he has finally overcome all the difficulty of switching consoles and can now play through all the games he's been wanting to play. Right? Right?
I think that the demographics of gamers have been skewing older and older, and it's finally reached the point where a critical mass are past the age where they place significant value on the "newness" of a game.
You can still find 13-year-olds decrying PS3 and 360 games as being "unplayable" due to their perceived technological shortcomings, but every year they represent a smaller and smaller slice of the total market. The surveys I've seen lump 18-35 into one group, but I'd be interested to see the results of splitting that into two groups at around 26-27.
Similar concepts (i.e. connect to random strangers' devices when in close physical proximity, and trade mini profiles/trading tokens/whatever) have been done at least half a dozen times, both before and after Nintendo, but somehow they never seem to stick. Street Pass may have been the most successful iteration that I'm aware of. I think that it's hard to get critical mass. Users are excited at first when they set things up, but after a few days or weeks of not getting any hits, they tend to lose interest and turn the service off to save battery life.
I played this on the PS2 and it's s fantastic experience.
Interestingly, the PAL version (and probably the Japanese version, too) has content that wasn't in the NA version. There's an extra puzzle, a semi-hidden alternative "funny/happy" coda after the main ending if you play through a second time, and some extra in-game options that are unlocked after you finish the game for the first time, including understandable subtitles for ALL characters, even ones that are normally speaking an unknown language. I'm not sure if the hidden weapon you can get in the middle of the game becomes a light saber on the second playthrough in the NA version as it does in the PAL version, but it may.
This was before video streaming sites, so there were many arguments on forums about how these things are in the game, no they aren't you trolls, yes they are here's a picture, that's obviously fake... and so on. It was interesting that once people figured out that the NA and PAL versions were different, there was a vocal core of NA players still insisting that it was all fake for quite a long time afterward.
One thing that wasn't mentioned in the article is default settings. In so many CLI programs (and FOSS in general), there seems to be some kind of allergy to default settings. I don't know whether it's a fear of doing the wrong thing, or a failure to sympathize with users who haven't spent the last three months up to their elbows in whatever the program does. But so often I've come to a new program, and if I've managed to stick with it, come to the realization later that at least half of the settings I needed to research for hours and enter manually every time could have been set to static defaults or easily-derived assumptions based on other settings in 99% of cases. Absolutely let your users override any and all defaults, but please use defaults.
I'd also be interested in the overlap between people saying, "LOL just get gud" about using the command line, and people who are terrified of using C++.
I'm all for humourous roasts of things, but does anyone really find this funny? Was the author possibly being serious? I don't know. What I do know is that I stopped watching after the first four examples because they were all deliberately incorrect or misleading, but also didn't seem funny to me.
That sure is a lot of ways to initialize a variable! Even though some of these variables are quite different and would be initialized differently from each other in many other languages, even only counting the initializations that are functionally equivalent, there are a bunch of abuses of syntax that I've never seen used in the wild.
At this point I had hope that this was meant to be amusing.
C++ has had a version of C's printf function from the very beginning. That weird stream syntax has some hardcore fans but many people ignore it. I did my CS degree close to 30 years ago, and the only time I used stream syntax was for one lab class exercise in which we had to show that we understood how to use stream syntax.
They still could be going for a comedy roast, I guess.
Much like the printf statement for number 2 above, C++ had its own version of C's rand function from the start. I've never even heard of the stuff that's being shown in this part of the video.
OK that was virtually the same fake point as the previous one, and still no punchlines in sight.
Nope, you don't. You're free to ask the compiler to automagically recast your variables to another type without giving any further detail just like you can in C. In fact, they're often called "C-style casts". There are even implicit casts, where you literally don't add anything, and just cross your fingers that the compiler does what you think it should do. It's like a little bit of the thrill of dynamic typing brought into C++! By using the static_cast keyword, you can tell the compiler that you understand that there's a potential issue with this recast, but that you expect that the standard way of handling it will be fine. There are other keywords for more unusual situations; it's not just a random bit of busywork added for no reason.