You need to divide C++ into two sections: Stuff that's useful for applications, and stuff that's mostly relevant to library writers. A lot of the really hairy stuff is mostly for the library writers. Moreover, a lot of the complexity of C++ (and corresponding slowness of its compilers) comes from compatibility with C and with older versions of itself. If you strip away all that, the core language that most people deal with isn't quite as daunting.
That being said, nobody is claiming that C++ isn't a difficult language to master. Scott Myers has made a career of pointing people away from it's darkest corners, after all.
But really, C++ programming took a quantum leap forward with C++11, and C++14 just filed away some of the rough edges. It's hard to explain to non-C++ programmers what a transformation it was. I'm not expecting nearly as much with C++ 17, but I look forward to seeing if any of the proposed features will be useful in my day-to-day work.
No, it's a 2D tile-based engine. Normal commercial engines can handle typical 3D scenarios, but I had some very specific ideas about how I wanted my tile-based games to work, and none of the commercial engines worked the way I had envisioned.
Unless you've got some very specific requirements that make it impractical, or unless you're a *very* large company that can afford to write your own engine, it's generally a better idea to use a commercial game engine.
I can't speak for the Tomb Raider devs, but I can at least give you my general impressions from the industry.
It's a small market, certainly, and inroads remain slow. Most high profile game developers, or at least the ones I've previously worked for, never even gave it a second thought. I think that's slowing changing, although certainly not as fast as in the indie scene. My impression is that a lot of indie game devs (my own included) focus on Linux precisely because the AAA studios don't seem to care about it, so it's a more untapped market. It takes fewer sales to make an indie game profitable, so we can afford to take the time to support that platform. When your budget is tens of millions (or hundreds in the largest case these days), you have to focus on the largest market for the biggest return.
Another factor is that many large studios have in-house engines or heavily modified commercial engines, or else rely on a large number of 3rd party technologies. Developing your own Linux port is expensive, and if you're using 3rd party software, unless Linux is fully supported, a port is much less likely. Indie devs, on the other hand, are very likely to be using vanilla Unity or Unreal, which have native Linux support.
I'm probably a bit unique for indies in that I'm using a custom engine, but am still planning complete Win/UWP/Mac/Linux support, doing all the ports the hard way (only Linux remaining now). Once your engine is done, though, it's just a matter of QA and update costs, so I'm counting on that long tail to make the initial investment worthwhile.
They can do with with their own produced videos. Somehow I have the feeling that Netflix is smart enough to understand that anyone can already download their shows FREE right now if they desire. Why not make it easy for paying customers to do the same thing?
Naturally, Hollywood will go right on fighting every innovation tooth and nail (videotapes, DVDs, streaming music and movies, the list goes on...), and making things as miserable as possible for the consumers. I'm already the least satisfied with the big-media-owned Hulu among the streaming services I subscribe to, and may be dropping it soon.
Sure we do - at least here in the US. Not sure about the EU. Unlike your personal property, nearly all business property (essentially anything used to conduct business) is taxed based on its appraised value. Why do you think businesses care so much about depreciation schedules, etc?
Note: I'm not defending this plan - just pointing out that bulldozers and drills *are* actually taxed.
I completely agree, and do the same thing. Assignments inside a conditional statement are horrendous, because it's not immediately clear whether the developer intended to make an assignment or a comparison. Moreover, the result of an assignment isn't as immediately obvious to anyone reading the code. It's one of the shittier "features" of C.
I've never understood people that try to shove as much shit as possible in a single line of code. It generally doesn't compile to more efficient machine code at all, and just makes it more difficult to parse by a human reader, which many developers underestimate the importance of. Just the other day I realized I'd been bit by a precedence bug when I was "sure" that I knew the correct precedence, only I didn't. It's just not worth being "clever". Boring, obvious code is the best code, for a variety of reasons.
At my former employer (I'd consider them the best place I'd worked at), we had "embedded QA". They'd sit right next to the developers, would be at our status meetings, would often develop specialties related to what that dev was working on, and would immediately provide either unofficial or official feedback on new features. As annoying as it is to have someone point out mistakes you've made, as a dev, you need to get over it and realize it's better for one QA member to point out your stupid mistakes than for the entire world to see them after you shipped.
For QA to be effective, I'm convinced they need to be working as part of the dev team, not as some standalone team the devs don't think about except when they get a bug report. This helps to prevent a lot of the problems with QA filing bug reports on things that aren't actually bugs since perhaps they're simply unfinished, or because they're something they don't understand about how things are supposed to work, etc. More importantly, this specialized QA person can vet other bugs from people on the team to make sure they're not dupes, etc. It can actually save the devs a lot of work.
I'm not sure how you could apply this lesson with open source development. The best is probably to release detail patch notes detailing what you worked on, so people can keep on eye on those features for any breakage, and to have an active and helpful team willing to help test out alpha or beta builds. And of course, the devs need to be willing to actually *listen* to feedback, which can unfortunately be a stumbling block when the feedback clashes with their "vision".
I'd certainly not suggest a *single* desktop would make things better. But there's a pretty big difference between *one* desktop and the many that are in development now. I mean, we've got Gnome, KDE (Plasma) as the big two for a while, but now also Unity, Cinnamon, MATE, LXQt, Xfce, Budgie, Pantheon... and probably more besides that. It feels to me that part of what's driving this is not an effort to improve, but to differentiate. There's nothing wrong with that, but on the other hand, it's not exactly helping drive things forward either.
Like you suggest, though, one great thing about having multiple projects is that you do have a choice. After Unity and Gnome 3, many users would seek alternatives like Plasma or Cinnamon.
I mentioned one already, so let's use that as an example: desktops. The situation is a hell of a lot better than it was just five years ago, but my feeling is that if efforts weren't divided over a dozen different projects, it seems like a lot of these issues would have been fixed much quicker.
Like I said, it seems like it's a bit of a double edged sword. It's really great to have a choice in desktops, but along with that comes the reality that each of those desktops is far less polished than what you see on commercial OSes like Mac or Windows.
Diversity is something of a double-edged sword. It's great for people that have a very specific itch to scratch and of course the open source nature makes Linux great for customization, but I think the amount of fragmentation on Linux tends to dilute efforts at fixing some problems. So, apparently, Linux needs a new app delivery mechanism? How many does that make now? How many desktop environments are there? Everyone seems to keep heading off and make their own rather than fixing the existing ones.
That's a lot of duplicated and wasted effort. Granted, it ultimately provides more choice, but I think it also tends to make each of those choices much less polished than what it might otherwise be.
a) A company curates and customizes a specific version of it for a specific purpose (Android, TiVo, Synology, etc) b) The OS doesn't matter so much, since it provides standardized services (e.g. web servers) c) The free price gives it a huge advantage in mass deployments on commodity hardware (data centers)
The fractured nature of Linux also isn't as much of a problem if the source you plan to use is free and open, so can simply be compiled to work with the target environment. It's more of a problem with closed commercial software. I'd imagine whether you see this as a positive or negative largely depends on how you view free/open vs proprietary/closed software.
One place those conditions don't really apply is as a desktop OS. The sad fact is, most of the useful software out there is Windows software, and so for most people who want to actually *use* that software, Windows makes the most sense for their OS. Any *nix on the desktop other than OS X is almost an error margin.
For people who don't actually need some specific piece of software and theoretically *could* switch to Linux... well, very often they're the sort of people who I'd suggest would be better off with a tablet or Chromebook anyhow.
This is why I buy any new desktop of mine through a small boutique computer shop that specializes in custom computer builds. They're rather pricey, but essentially you get a computer that looks exactly like as though you'd put together a custom machine yourself. Actually, probably even better, to be honest, since these guys really know what they're doing, and they'll recommend the components that they've deemed to be the most reliable. And yes, you get the original OEM install disk, as well as a disc with all the drivers they used in the box filled with all the "extra" parts, manuals, etc. Additionally, they'll install Linux on it, leaving off Windows, if you prefer that, so you don't have to pay the Windows tax if you don't want to.
Unfortunately, they can't really provide cutting edge laptops (that is, if you want small and/or light) beyond sort of a largish "desktop replacement" sized laptop. At the moment, I don't really need a laptop, but I'd dread having to dig through it and remove all the shit on it that clogs it up, or figure out how to reinstall from scratch if possible. Moreover, we keep finding more and more security holes in their custom updaters, not to mention any installed crapware, or even spyware in the worst cases, etc.
My last laptop was quite a few years ago, from Dell. The damned thing was so slow and unstable I literally had to wipe the OS and start from scratch, after which it ran perfectly. I have a hard time feeling sorry for the major OEMs with the downturn of the PC industry when they've been shoveling this shit down our throats for years.
Uh huh? And you don't think they had some inside information about upcoming iPhone designs, which are also manufactured in China? Gosh, they'd never resort to wholesale industrial espionage, would they?
Sorry China, but you don't get to play this both ways. Well, you DO, since it's your country, but we'll at least call bullshit on it. And in fact, we can't look too smug, since our own system is fucked up enough as it is, just not quite as fucked up as theirs.
This will probably result in Apple having to brib... er, pay some hefty fine, and then continue business as usual.
Visual C++ depreciated a number of fundamentally unsafe C library functions, replacing them with _s versions, does some rudimentary analysis of stack and array safety, and a few other things, if you compile with the Security Lifecycle Development checks.
Giving websites a secret they have to protect, especially second-tier player like this, just seems like a losing strategy in the long haul. I'm hoping something like SQRL eventually gets some traction, which uses public key crypto + site name to create an authentication method that doesn't rely on the website to keep a secret and is only viable for that single site. How many times must we demonstrate that sites can't be trusted with usernames and passwords? Nor can users be trusted to create decent passwords in the first place - which is understandable, because the advice of "don't reuse the same password", and "make your password long and complex" is absolutely untenable without a way to manage those passwords automatically.
You talk about throwing work away as though it's a bad thing. My experience tells me that the first version of any complex piece of software or software component you try to create is going to be garbage anyhow. Maybe it would be better to count on calling your first try a prototype, learn the hard lessons about what doesn't work and why, and then scrap as much of it as you need and write version two with the lessons you gleaned from the prototype.
The problem with detailed planning is that there's simply too much you don't know until you get into the meat of a problem and run into unexpected design or technology issues. You just can't plan in your initial design for those because those are unknowns. Only your second iteration can possibly account for those previously unknown factors. It's hard as hell to throw work away, but it's far more painful in the long run to work around fundamental problems that you wish could have been solved earlier in the design phase.
Beyond that, though, it sound like you've got experience with a work environment that has a lot of issues beyond any methodology problems. Long work hours, poor quality control, lack of reasonable management... no magic formula is going to fix such an environment besides a fairly radical shakeup of the company culture.
You used past tense, so I hope you're no longer at such a place. Even so...
Holy crap... hours? Did they realize the entire point of making the meeting "stand up" is to encourage people to keep the meetings extremely brief? Did they actually *stand* through those entire meetings? I hate the kindergarten mentality behind it, but I'm all for keeping meetings as short as possible. If a team can't even get that right, then no methodology is going to help. It's critical to keep the number of participants down to reasonable levels and keep the information *very* succinct, which some people admittedly have a hard time with.
If anyone listening is involved with such hellish meetings, you need to start holding your meetings standing on one leg, or perhaps in some awkward posture that can only be held for about 10 or 15 minutes. And bring a two minute timer. No individual report should take longer than that.
I'm pretty sure I'd just walk out of a meeting like that after 20 minute or so, or else bring along a laptop so I could get some actual work done. I suspect I might not last long in such an environment. Fortunately, I haven't had to.
I was pretty young at the time, so I didn't realize there was anything other than BASIC to use or how I would go about doing it, or I may have tried. We sort of take for granted the information age we live in now, but there was far less opportunity for a kid to learn how to do that stuff, unlike the instant access any kid nowadays to all sorts of free, high-quality development tools and online tutorials. I was just fortunate a kid-friendly Applesoft BASIC tutorial book came with the computer. It really was a pretty good introduction to programming.
It wasn't until quite a few years later that I got a Windows PC and taught myself Pascal, then C++ (both using Borland Turbo products in DOS), which I fell in love with for its power and expressibility.
My favorite Apple II games: Wizardry, Choplifter, Aztec, Karateka, Flight Simulator... ah, good times. I also learned how to program on an Apple II as well. It wasn't all time wasted. Good ole Applesoft BASIC. But ugh, line numbers... It was a while before I realized why I could never create programs that ran as fast as my commercial games.
These days, I write commercial games in C++. I may not have become a videogame programmer were it not for my Apple II. I guess I'm just as old.
Given the fact that we were in the midst of the cold war, it was pretty remarkable to have a Russian on the crew at all. You have to view those shows through the lens of their time.
It's actually pretty easy to get computers to write *almost* coherent prose simply by feeding it the text of a few novels and getting to regurgitate it back out based simply on some simple algorithms, like word order and basic structural analysis, combined with a few rules about character interaction. It sounds like that's exactly what they did here. What this represented was not AI, but a form of data analysis. An interesting experiment, to be sure, but that's really all.
I listened to a few minutes of this, and it sounds exactly like the sort of output you'd expect from such an algorithm. It almost sounds right, but there's no real meaning there at all. The computer had no idea what it was regurgitating. It was only the human directors and actors that even gave that gibberish a hint of meaning, and it was still a stretch.
My brother is in a commercial fleet, and he was required to learn how to do navigation by manual methods (charts, compass, sightings, etc) to pass whatever certification exams he was taking at the time (and there's a *lot* of them). I'd have to imagine Navy navigators have to pass the same sort of standards as civilians sailors. It definitely seems like a good thing not to rely too heavily on technology, not just in case it fails, but as a way to sanity-check the computer systems that nearly all modern vessels rely on.
Slashdot Mirror
You need to divide C++ into two sections: Stuff that's useful for applications, and stuff that's mostly relevant to library writers. A lot of the really hairy stuff is mostly for the library writers. Moreover, a lot of the complexity of C++ (and corresponding slowness of its compilers) comes from compatibility with C and with older versions of itself. If you strip away all that, the core language that most people deal with isn't quite as daunting.
That being said, nobody is claiming that C++ isn't a difficult language to master. Scott Myers has made a career of pointing people away from it's darkest corners, after all.
But really, C++ programming took a quantum leap forward with C++11, and C++14 just filed away some of the rough edges. It's hard to explain to non-C++ programmers what a transformation it was. I'm not expecting nearly as much with C++ 17, but I look forward to seeing if any of the proposed features will be useful in my day-to-day work.
No, it's a 2D tile-based engine. Normal commercial engines can handle typical 3D scenarios, but I had some very specific ideas about how I wanted my tile-based games to work, and none of the commercial engines worked the way I had envisioned.
Unless you've got some very specific requirements that make it impractical, or unless you're a *very* large company that can afford to write your own engine, it's generally a better idea to use a commercial game engine.
I can't speak for the Tomb Raider devs, but I can at least give you my general impressions from the industry.
It's a small market, certainly, and inroads remain slow. Most high profile game developers, or at least the ones I've previously worked for, never even gave it a second thought. I think that's slowing changing, although certainly not as fast as in the indie scene. My impression is that a lot of indie game devs (my own included) focus on Linux precisely because the AAA studios don't seem to care about it, so it's a more untapped market. It takes fewer sales to make an indie game profitable, so we can afford to take the time to support that platform. When your budget is tens of millions (or hundreds in the largest case these days), you have to focus on the largest market for the biggest return.
Another factor is that many large studios have in-house engines or heavily modified commercial engines, or else rely on a large number of 3rd party technologies. Developing your own Linux port is expensive, and if you're using 3rd party software, unless Linux is fully supported, a port is much less likely. Indie devs, on the other hand, are very likely to be using vanilla Unity or Unreal, which have native Linux support.
I'm probably a bit unique for indies in that I'm using a custom engine, but am still planning complete Win/UWP/Mac/Linux support, doing all the ports the hard way (only Linux remaining now). Once your engine is done, though, it's just a matter of QA and update costs, so I'm counting on that long tail to make the initial investment worthwhile.
They can do with with their own produced videos. Somehow I have the feeling that Netflix is smart enough to understand that anyone can already download their shows FREE right now if they desire. Why not make it easy for paying customers to do the same thing?
Naturally, Hollywood will go right on fighting every innovation tooth and nail (videotapes, DVDs, streaming music and movies, the list goes on...), and making things as miserable as possible for the consumers. I'm already the least satisfied with the big-media-owned Hulu among the streaming services I subscribe to, and may be dropping it soon.
Sure we do - at least here in the US. Not sure about the EU. Unlike your personal property, nearly all business property (essentially anything used to conduct business) is taxed based on its appraised value. Why do you think businesses care so much about depreciation schedules, etc?
Note: I'm not defending this plan - just pointing out that bulldozers and drills *are* actually taxed.
I completely agree, and do the same thing. Assignments inside a conditional statement are horrendous, because it's not immediately clear whether the developer intended to make an assignment or a comparison. Moreover, the result of an assignment isn't as immediately obvious to anyone reading the code. It's one of the shittier "features" of C.
I've never understood people that try to shove as much shit as possible in a single line of code. It generally doesn't compile to more efficient machine code at all, and just makes it more difficult to parse by a human reader, which many developers underestimate the importance of. Just the other day I realized I'd been bit by a precedence bug when I was "sure" that I knew the correct precedence, only I didn't. It's just not worth being "clever". Boring, obvious code is the best code, for a variety of reasons.
At my former employer (I'd consider them the best place I'd worked at), we had "embedded QA". They'd sit right next to the developers, would be at our status meetings, would often develop specialties related to what that dev was working on, and would immediately provide either unofficial or official feedback on new features. As annoying as it is to have someone point out mistakes you've made, as a dev, you need to get over it and realize it's better for one QA member to point out your stupid mistakes than for the entire world to see them after you shipped.
For QA to be effective, I'm convinced they need to be working as part of the dev team, not as some standalone team the devs don't think about except when they get a bug report. This helps to prevent a lot of the problems with QA filing bug reports on things that aren't actually bugs since perhaps they're simply unfinished, or because they're something they don't understand about how things are supposed to work, etc. More importantly, this specialized QA person can vet other bugs from people on the team to make sure they're not dupes, etc. It can actually save the devs a lot of work.
I'm not sure how you could apply this lesson with open source development. The best is probably to release detail patch notes detailing what you worked on, so people can keep on eye on those features for any breakage, and to have an active and helpful team willing to help test out alpha or beta builds. And of course, the devs need to be willing to actually *listen* to feedback, which can unfortunately be a stumbling block when the feedback clashes with their "vision".
I'd certainly not suggest a *single* desktop would make things better. But there's a pretty big difference between *one* desktop and the many that are in development now. I mean, we've got Gnome, KDE (Plasma) as the big two for a while, but now also Unity, Cinnamon, MATE, LXQt, Xfce, Budgie, Pantheon... and probably more besides that. It feels to me that part of what's driving this is not an effort to improve, but to differentiate. There's nothing wrong with that, but on the other hand, it's not exactly helping drive things forward either.
Like you suggest, though, one great thing about having multiple projects is that you do have a choice. After Unity and Gnome 3, many users would seek alternatives like Plasma or Cinnamon.
It's a lot less baffling if you understand that the prideful people in power who are refusing the gifts are not the same folks that are going hungry.
I mentioned one already, so let's use that as an example: desktops. The situation is a hell of a lot better than it was just five years ago, but my feeling is that if efforts weren't divided over a dozen different projects, it seems like a lot of these issues would have been fixed much quicker.
Like I said, it seems like it's a bit of a double edged sword. It's really great to have a choice in desktops, but along with that comes the reality that each of those desktops is far less polished than what you see on commercial OSes like Mac or Windows.
Diversity is something of a double-edged sword. It's great for people that have a very specific itch to scratch and of course the open source nature makes Linux great for customization, but I think the amount of fragmentation on Linux tends to dilute efforts at fixing some problems. So, apparently, Linux needs a new app delivery mechanism? How many does that make now? How many desktop environments are there? Everyone seems to keep heading off and make their own rather than fixing the existing ones.
That's a lot of duplicated and wasted effort. Granted, it ultimately provides more choice, but I think it also tends to make each of those choices much less polished than what it might otherwise be.
Yep, exactly. Linux works great in places where:
a) A company curates and customizes a specific version of it for a specific purpose (Android, TiVo, Synology, etc)
b) The OS doesn't matter so much, since it provides standardized services (e.g. web servers)
c) The free price gives it a huge advantage in mass deployments on commodity hardware (data centers)
The fractured nature of Linux also isn't as much of a problem if the source you plan to use is free and open, so can simply be compiled to work with the target environment. It's more of a problem with closed commercial software. I'd imagine whether you see this as a positive or negative largely depends on how you view free/open vs proprietary/closed software.
One place those conditions don't really apply is as a desktop OS. The sad fact is, most of the useful software out there is Windows software, and so for most people who want to actually *use* that software, Windows makes the most sense for their OS. Any *nix on the desktop other than OS X is almost an error margin.
For people who don't actually need some specific piece of software and theoretically *could* switch to Linux... well, very often they're the sort of people who I'd suggest would be better off with a tablet or Chromebook anyhow.
This is why I buy any new desktop of mine through a small boutique computer shop that specializes in custom computer builds. They're rather pricey, but essentially you get a computer that looks exactly like as though you'd put together a custom machine yourself. Actually, probably even better, to be honest, since these guys really know what they're doing, and they'll recommend the components that they've deemed to be the most reliable. And yes, you get the original OEM install disk, as well as a disc with all the drivers they used in the box filled with all the "extra" parts, manuals, etc. Additionally, they'll install Linux on it, leaving off Windows, if you prefer that, so you don't have to pay the Windows tax if you don't want to.
Unfortunately, they can't really provide cutting edge laptops (that is, if you want small and/or light) beyond sort of a largish "desktop replacement" sized laptop. At the moment, I don't really need a laptop, but I'd dread having to dig through it and remove all the shit on it that clogs it up, or figure out how to reinstall from scratch if possible. Moreover, we keep finding more and more security holes in their custom updaters, not to mention any installed crapware, or even spyware in the worst cases, etc.
My last laptop was quite a few years ago, from Dell. The damned thing was so slow and unstable I literally had to wipe the OS and start from scratch, after which it ran perfectly. I have a hard time feeling sorry for the major OEMs with the downturn of the PC industry when they've been shoveling this shit down our throats for years.
Uh huh? And you don't think they had some inside information about upcoming iPhone designs, which are also manufactured in China? Gosh, they'd never resort to wholesale industrial espionage, would they?
Sorry China, but you don't get to play this both ways. Well, you DO, since it's your country, but we'll at least call bullshit on it. And in fact, we can't look too smug, since our own system is fucked up enough as it is, just not quite as fucked up as theirs.
This will probably result in Apple having to brib... er, pay some hefty fine, and then continue business as usual.
> Visual C++ depreciated a number of fundamentally unsafe C library functions
It made them worth less money?
Laugh it up. Someday you'll get old and C-nile like me.
Visual C++ depreciated a number of fundamentally unsafe C library functions, replacing them with _s versions, does some rudimentary analysis of stack and array safety, and a few other things, if you compile with the Security Lifecycle Development checks.
Giving websites a secret they have to protect, especially second-tier player like this, just seems like a losing strategy in the long haul. I'm hoping something like SQRL eventually gets some traction, which uses public key crypto + site name to create an authentication method that doesn't rely on the website to keep a secret and is only viable for that single site. How many times must we demonstrate that sites can't be trusted with usernames and passwords? Nor can users be trusted to create decent passwords in the first place - which is understandable, because the advice of "don't reuse the same password", and "make your password long and complex" is absolutely untenable without a way to manage those passwords automatically.
You talk about throwing work away as though it's a bad thing. My experience tells me that the first version of any complex piece of software or software component you try to create is going to be garbage anyhow. Maybe it would be better to count on calling your first try a prototype, learn the hard lessons about what doesn't work and why, and then scrap as much of it as you need and write version two with the lessons you gleaned from the prototype.
The problem with detailed planning is that there's simply too much you don't know until you get into the meat of a problem and run into unexpected design or technology issues. You just can't plan in your initial design for those because those are unknowns. Only your second iteration can possibly account for those previously unknown factors. It's hard as hell to throw work away, but it's far more painful in the long run to work around fundamental problems that you wish could have been solved earlier in the design phase.
Beyond that, though, it sound like you've got experience with a work environment that has a lot of issues beyond any methodology problems. Long work hours, poor quality control, lack of reasonable management... no magic formula is going to fix such an environment besides a fairly radical shakeup of the company culture.
You used past tense, so I hope you're no longer at such a place. Even so...
Holy crap... hours? Did they realize the entire point of making the meeting "stand up" is to encourage people to keep the meetings extremely brief? Did they actually *stand* through those entire meetings? I hate the kindergarten mentality behind it, but I'm all for keeping meetings as short as possible. If a team can't even get that right, then no methodology is going to help. It's critical to keep the number of participants down to reasonable levels and keep the information *very* succinct, which some people admittedly have a hard time with.
If anyone listening is involved with such hellish meetings, you need to start holding your meetings standing on one leg, or perhaps in some awkward posture that can only be held for about 10 or 15 minutes. And bring a two minute timer. No individual report should take longer than that.
I'm pretty sure I'd just walk out of a meeting like that after 20 minute or so, or else bring along a laptop so I could get some actual work done. I suspect I might not last long in such an environment. Fortunately, I haven't had to.
I was pretty young at the time, so I didn't realize there was anything other than BASIC to use or how I would go about doing it, or I may have tried. We sort of take for granted the information age we live in now, but there was far less opportunity for a kid to learn how to do that stuff, unlike the instant access any kid nowadays to all sorts of free, high-quality development tools and online tutorials. I was just fortunate a kid-friendly Applesoft BASIC tutorial book came with the computer. It really was a pretty good introduction to programming.
It wasn't until quite a few years later that I got a Windows PC and taught myself Pascal, then C++ (both using Borland Turbo products in DOS), which I fell in love with for its power and expressibility.
My favorite Apple II games: Wizardry, Choplifter, Aztec, Karateka, Flight Simulator... ah, good times. I also learned how to program on an Apple II as well. It wasn't all time wasted. Good ole Applesoft BASIC. But ugh, line numbers... It was a while before I realized why I could never create programs that ran as fast as my commercial games.
These days, I write commercial games in C++. I may not have become a videogame programmer were it not for my Apple II. I guess I'm just as old.
Given the fact that we were in the midst of the cold war, it was pretty remarkable to have a Russian on the crew at all. You have to view those shows through the lens of their time.
Try "Hillary Clinton e"
Or better yet, "What, like with"
It's actually pretty easy to get computers to write *almost* coherent prose simply by feeding it the text of a few novels and getting to regurgitate it back out based simply on some simple algorithms, like word order and basic structural analysis, combined with a few rules about character interaction. It sounds like that's exactly what they did here. What this represented was not AI, but a form of data analysis. An interesting experiment, to be sure, but that's really all.
I listened to a few minutes of this, and it sounds exactly like the sort of output you'd expect from such an algorithm. It almost sounds right, but there's no real meaning there at all. The computer had no idea what it was regurgitating. It was only the human directors and actors that even gave that gibberish a hint of meaning, and it was still a stretch.
My brother is in a commercial fleet, and he was required to learn how to do navigation by manual methods (charts, compass, sightings, etc) to pass whatever certification exams he was taking at the time (and there's a *lot* of them). I'd have to imagine Navy navigators have to pass the same sort of standards as civilians sailors. It definitely seems like a good thing not to rely too heavily on technology, not just in case it fails, but as a way to sanity-check the computer systems that nearly all modern vessels rely on.