My "problem" as you put it, is that I made a point which seems to have been handwaved away as if it doesn't matter. Even though it mattered to the Wii and it mattered to the Wii U. If it costs more to develop a game for the Switch and it doesn't have parity with other platforms then it a) costs more to develop titles, b) has less users to make a profit, c) ends up in shovelware hell.
I'm sure there are engines and suchlike that target mobile platforms but guess what? That means the Switch occupies the same tier as the phone in your pocket. That'll be great if you want garbage free-to-play games and so on, or crappy 3D games. It's not so good if you see someone playing Battlefield 1 or Far Cry 4 on their XB1 / PS4 and you're reduced to some shoddy shooter-on-rails port.
You're aware that Nintendo has never been in the game of cutting edge graphics, right?
That wasn't the point I was making so let me state it more plainly.
Making a game that targets the XB1, PS4 and PC is a no brainer. That's because these platforms are close enough (i.e. parity) that the tools, assets, middleware, developers, designers, testers, budgets and marketing can be shared across platforms. The cost of writing a game exclusively for the PS4 might be 10 million but the cost of adding XB1 and PC might only add another 5 million because the work is shared.
If the Switch is NOT at parity then the obvious outcome is that it will cost more money to develop for that platform than it would otherwise. And if there is a smaller userbase that will hurt sales. And as we saw for the Wii and Wii U it means devs won't bother to support the platform at all, or will set their sights lower and churn out shovelware.
You don't need the power of PS or XB to make good games.
No you don't. But let's reduce this absurd argument. You don't need the power of the PS3. You don't need the power of the PS2. You don't need the power of the Playstation. You don't need the power of the Sega Genesis. You don't need the power of the NES. You don't need the power of the Atari VCS. Ad nauseum. We could make a fun game from a dot on the screen. Hell, let's have fun with a stick and a hoop.
It's not a strong argument to defend a console with poor specs. A console is not rendered more "fun" by having gimped specs. Especially if you get to enjoy lots and lots of shovelware as a result.
Yes and you can also fire up a PC game and discover all the servers have been shut down or there is nobody on them to play against. In some cases the multiplayer service facilitator such as Gamespy has been shut down so you're totally screwed.
I do find the thought of having to pay to play multiplayer to be very objectionable however. The only reason I would think it worthwhile is if the platform holder (i.e. Microsoft / Sony) laid down the law to the likes of EA / Activision etc. on how / when / if ever they are permitted to shutdown the hosting servers. In these days of virtual machines, I don't necessarily see that a hosting server ever needs to be shutdown - they should be able to scale up or down with demand.
Even docked I don't see any way to get close to XB1 or PS4 performance. Even if it runs at a higher clock or unlocks some higher mode it's still constrained by its form factor, the mobile chipset, it's low power draw and its (in)ability to dissipate heat. I wonder what 3rd parties think of a device that yet again probably has little chance of platform parity with its competitors.
Yes. An entire cottage industry of linters, post mortem analysis tools etc. to try and figure out what your code is broken. Too bad if that happened in production on a customer machine and now they're pissed and you're going to spend hours trying to isolate why the code is leaking / racing / crashing because of it.
Code that wouldn't have been broken in the first place or neded to have been fixed if the compiler could catch it. Which is what Rust aims to do insofar as it can.
These are problems with the programmer, not with the language. A programmer who makes code with such defects will find ways to make code in Rust or any other language fail.
No, they're problems with the language. Even the most seasoned, experienced C and C++ programmers fall afoul of these issues. Don't pretend you don't. I write C and C++ all day long and I still waste days debugging stupid shit that shouldn't have happened. And of course seasoned, experienced C and C++ programmers don't become that way without writing a LOT of bugs.
That is irrelevant when it is no longer supported. With C, you have almost complete certainty that you can use the code for many decades to come. With Rust, it is very doubtful that any supported tools will still exist in ten years.
Why is it doubtful? That's you projecting when there is no indication that Rust is losing popularity.
Arrange all the privacy settings in a single, coherent arrangement, not scattered through different panels and advanced dialogs. Summarize what the data is being collected and what it may be used for. Perhaps even have a single button that says "I want to remain private" and clicking it sets everything to secure. Don't try and bury the settings. Don't throw the switches wide open by default. Inform the user, ask the user and do what the user says. And for new installations, explicitly ask the user what settings they want.
C works anywhere (* subject to a massive list of restrictions and caveats). And the keyword here is "competently written C code". Rust kicks your ass if you do stupid stuff well before the code gets in production. It's frustrating when you're learning the language but the result is code that simply doesn't fail in the ways that C or C++ does all too frequently - memory leaks, dangling pointers, data races etc.
And perhaps people will stick with C longer that Rust. That doesn't make much of an argument for a library being written right now. Nobody would backport a Rust library to C. The rust compiler will exist as long as C does. There is no reason whatsoever to go with a retrograde language for what may or may not happen some unspecified time in the future. If that argument made any sense we'd be coding in BCPL, or assembly. You know, just to be safe.
That's the case for Rust. It has a foreign function interface that is basically just methods exported in a way that C expectant applications can link to. Providing the client has C headers corresponding to the.lib it is linking to it becomes completely ignorant of what the libs was written with - Rust, Haskell, anything.
Library developers know that their libraries will be usable from every language if they write it in pure C.
Library developers know that their libraries will be usable from every language if they write it in Rust too. With the added advantage that the code is liable to be far more stable and reliable.
"Usually what you want" should be something that the programmer explicitly says through code. The problem is that if a member of the class is a handle to a file (for example), or a raw pointer, or just something which is private to that class, then copying instance A to instance B can cause trouble.
Thus a veritable cottage industry has sprouted to fix what shouldn't have been a problem in the first place, e.g. boost's noncopyable base class. And if you do follow the rule of three (which is now the rule of five thanks to move rules), the complexity and mess in the code increases the chances of other bugs happening.
So that's what I meant by that. C++ is unsafe by default and does really unhelpful dangerous things that people only learn through experience (and many hours of bug fixing) to not do. Making the language safe by default as Rust has done eliminates entire classes of problems even before they are allowed to happen. And in doing so you get more reliable code, less bugs and happier customers.
I think Rust does have some similarities to Ada in terms of its design goals and even some of its syntax (match vs case for example). But it is designed to replace C / C++ code and so the syntax is fairly C-like - curly braces, semi-colons etc. The main thing it tries to do is enforce safety upfront at compile time so that only "correct" code gets through and is therefore not vulnerable to the ubiquitous errors of C / C++ - memory leaks, dangling pointers, buffer overruns, data races etc.
I've played around with it a lot and I like the language. The compiler will kick your ass (with helpful suggestions) if you write something wrong or violate some lifetime / ownership / mutability constraint. Once your code compiles, it should be as performant as C / C++ and more reliable. It's also extremely portable and has a package manager. The downsides right now is the compiler is quite slow compared to a C / C++ compiler and code that puts boxes inside arcs inside results and unwraps it can look pretty messy.
Go offers nothing that an established language can't already do. It'll die just because Google supports it...because Google has no issues with throwing away stuff as soon as they lose interest, no matter how many people are invested in it.
Pretty much every established language can do the stuff the new languages do. It doesn't mean they do them well, or that they can't be improved upon or that we should simply live with the flaws in those languages even if they cause untold numbers of errors in production code. A simple example would be C and C++'s never ending supply of bugs related to dangling pointers, memory leaks etc., many of which are caused by inherent default choices in the language.
While I don't program Go myself it clearly demonstrates a number of advantages for writing multi-threaded, high availability, high performance applications than some other languages. It compiles to a native standalone executable, it's portable, it has garbage collection, it doesn't carry the baggage of a runtime around with it. Performance wise it sits somewhere between C and Java. I've found tools written in Go such as Prometheus to be remarkably stable and reliable.
The Rule of Three was not a design intent of the C++ language, it was an after-the-fact bodge to fix the terrible default byte copy that C++ helpfully adds whether its safe or not. Entire books are written about writing effective C++ and most of them are working around really poor, unsafe behaviour that you get by default or bad language choices. Even if someone fastidiously follows Rule of Three, it's still easy to screw up in subtle ways, such as not checking if an instance is being assigned to itself.
The correct design would not support any default copy / assignment operators on any class. Make it an explicit programming intent before adding support, e.g. require the class to have a pure copy constructor / assignment operator as a hint for the compiler to fill in or actual implementations supplied by the programmer .
C++ has tried to retroactively add stuff like move semantics (causing overload resolution to become ridiculously more complex than it already is) and now has some scoped / shared pointers that can catch copy problems but the reality is its still unsafe-by-default.
It may explain why languages like Rust that take the opposite approach are gaining such popularity.
Wrong. Pharmaceutical companies spend billions on drug research, much of which never comes to anything. We could argue they're wasting their time, that there is some other drug on the market. But if they didn't research then they wouldn't be able to profit from the one time they hit pay dirt.
No complex device pops into existence. It comes about as the result of a long development phase, prototypes, testing, rejigging, more prototypes, trials, rejigging etc. There is a large upfront cost to all this but the pay off is in when they get things right.
I really don't see this as any different. Perhaps the purpose of this is to test the solar panels durability in a questionable climate and determine what the actual limits are for such a system. If it can work in overcast Normandy then it can work in sunnier climes. If the panels can have trucks rolling over them then they'll be fine in car parks. If they can make 1km of panels they can shake issues out of the production process.
Of course they could stick panels on roofs or mount them on poles above ground, but perhaps the purpose of the experiment (since it is an experiment) is to see what happens when they do it like this. What are the costs, problems and benefits of such a solution compared to other ways? The only way to tell is to try.
It's basically a rethemed and polished version of Rasbian with LXDE or some other light weight desktop. But I can't see much reason I would want it on a PC or Mac, other than perhaps for development purposes, i.e. for writing code that targets PIXEL or the Pi without suffering the intolerably slow speeds of the Pi while I do so.
Otherwise there are already lots of Linux dists and few of them need to cut as many corners as Rasbian to get it to run on a slow embedded device.
No. Javascript is a terrible teaching language. It doesn't enforce programming discipline in any way, doesn't care program structure or types, is grossly inefficient, doesn't actually DO anything by itself because it is a scripting language (the program it runs against has that functionality), and is all around just a bad language. Yes we're stuck with it because it's used by browsers and is convenient in other places like NodeJS but it's not a teaching language unless you want to turn out another generation of Visual Basic programmers.
At the very least it would be better to teach in Typescript that addresses some of the shortcomings in JS, but then someone would moan that it's Microsoft again. But better yet, programming would be taught on a structured, forgiving, well designed standalone language. There are plenty to choose from. Scripting and other concepts would be introduced once the basics were learned.
The people I worked with came and went in months. Apparently a lot of multinationals were opening big support centres in Bangalore so they basically hopped around from place to place trying to get work visas and suchlike.
Aside from that I really couldn't stand the total passivity of the people I worked with. Every email / call was "How do I fix this problem?" rather than "I found a problem but I have this solution I want to run by you", or "FYI I found a problem but I fixed it". It was like they couldn't think for themselves or were afraid to. They wouldn't even push back on my suggestions. I hated every minute of dealing with them. The company clearly did too because they ended up selling the entire operation to Infosys.
That would explain why they shut the group down. It'd be interesting to know the reasons why but my own experience of supervising a team in India is that culture, language and staff retention are serious problems. Whatever you think you're saving by paying less you could more than lose in terms of productivity and code quality.
Slashdot Mirror
I don't know what performance the Switch will offer but I doubt it will defy what we already see on other tablet / mobile platforms.
I'm sure there are engines and suchlike that target mobile platforms but guess what? That means the Switch occupies the same tier as the phone in your pocket. That'll be great if you want garbage free-to-play games and so on, or crappy 3D games. It's not so good if you see someone playing Battlefield 1 or Far Cry 4 on their XB1 / PS4 and you're reduced to some shoddy shooter-on-rails port.
You're aware that Nintendo has never been in the game of cutting edge graphics, right?
That wasn't the point I was making so let me state it more plainly. Making a game that targets the XB1, PS4 and PC is a no brainer. That's because these platforms are close enough (i.e. parity) that the tools, assets, middleware, developers, designers, testers, budgets and marketing can be shared across platforms. The cost of writing a game exclusively for the PS4 might be 10 million but the cost of adding XB1 and PC might only add another 5 million because the work is shared. If the Switch is NOT at parity then the obvious outcome is that it will cost more money to develop for that platform than it would otherwise. And if there is a smaller userbase that will hurt sales. And as we saw for the Wii and Wii U it means devs won't bother to support the platform at all, or will set their sights lower and churn out shovelware.
You don't need the power of PS or XB to make good games.
No you don't. But let's reduce this absurd argument. You don't need the power of the PS3. You don't need the power of the PS2. You don't need the power of the Playstation. You don't need the power of the Sega Genesis. You don't need the power of the NES. You don't need the power of the Atari VCS. Ad nauseum. We could make a fun game from a dot on the screen. Hell, let's have fun with a stick and a hoop. It's not a strong argument to defend a console with poor specs. A console is not rendered more "fun" by having gimped specs. Especially if you get to enjoy lots and lots of shovelware as a result.
I do find the thought of having to pay to play multiplayer to be very objectionable however. The only reason I would think it worthwhile is if the platform holder (i.e. Microsoft / Sony) laid down the law to the likes of EA / Activision etc. on how / when / if ever they are permitted to shutdown the hosting servers. In these days of virtual machines, I don't necessarily see that a hosting server ever needs to be shutdown - they should be able to scale up or down with demand.
Even docked I don't see any way to get close to XB1 or PS4 performance. Even if it runs at a higher clock or unlocks some higher mode it's still constrained by its form factor, the mobile chipset, it's low power draw and its (in)ability to dissipate heat. I wonder what 3rd parties think of a device that yet again probably has little chance of platform parity with its competitors.
There are plenty of ways to check C code.
Yes. An entire cottage industry of linters, post mortem analysis tools etc. to try and figure out what your code is broken. Too bad if that happened in production on a customer machine and now they're pissed and you're going to spend hours trying to isolate why the code is leaking / racing / crashing because of it.
Code that wouldn't have been broken in the first place or neded to have been fixed if the compiler could catch it. Which is what Rust aims to do insofar as it can.
These are problems with the programmer, not with the language. A programmer who makes code with such defects will find ways to make code in Rust or any other language fail.
No, they're problems with the language. Even the most seasoned, experienced C and C++ programmers fall afoul of these issues. Don't pretend you don't. I write C and C++ all day long and I still waste days debugging stupid shit that shouldn't have happened. And of course seasoned, experienced C and C++ programmers don't become that way without writing a LOT of bugs.
That is irrelevant when it is no longer supported. With C, you have almost complete certainty that you can use the code for many decades to come. With Rust, it is very doubtful that any supported tools will still exist in ten years.
Why is it doubtful? That's you projecting when there is no indication that Rust is losing popularity.
Arrange all the privacy settings in a single, coherent arrangement, not scattered through different panels and advanced dialogs. Summarize what the data is being collected and what it may be used for. Perhaps even have a single button that says "I want to remain private" and clicking it sets everything to secure. Don't try and bury the settings. Don't throw the switches wide open by default. Inform the user, ask the user and do what the user says. And for new installations, explicitly ask the user what settings they want.
And perhaps people will stick with C longer that Rust. That doesn't make much of an argument for a library being written right now. Nobody would backport a Rust library to C. The rust compiler will exist as long as C does. There is no reason whatsoever to go with a retrograde language for what may or may not happen some unspecified time in the future. If that argument made any sense we'd be coding in BCPL, or assembly. You know, just to be safe.
That's the case for Rust. It has a foreign function interface that is basically just methods exported in a way that C expectant applications can link to. Providing the client has C headers corresponding to the .lib it is linking to it becomes completely ignorant of what the libs was written with - Rust, Haskell, anything.
Rust is open source, just like GCC, clang, llvm etc. Feel free to review it, or compile your own version if you're so paranoid.
Library developers know that their libraries will be usable from every language if they write it in pure C.
Library developers know that their libraries will be usable from every language if they write it in Rust too. With the added advantage that the code is liable to be far more stable and reliable.
Thus a veritable cottage industry has sprouted to fix what shouldn't have been a problem in the first place, e.g. boost's noncopyable base class. And if you do follow the rule of three (which is now the rule of five thanks to move rules), the complexity and mess in the code increases the chances of other bugs happening.
So that's what I meant by that. C++ is unsafe by default and does really unhelpful dangerous things that people only learn through experience (and many hours of bug fixing) to not do. Making the language safe by default as Rust has done eliminates entire classes of problems even before they are allowed to happen. And in doing so you get more reliable code, less bugs and happier customers.
I've played around with it a lot and I like the language. The compiler will kick your ass (with helpful suggestions) if you write something wrong or violate some lifetime / ownership / mutability constraint. Once your code compiles, it should be as performant as C / C++ and more reliable. It's also extremely portable and has a package manager. The downsides right now is the compiler is quite slow compared to a C / C++ compiler and code that puts boxes inside arcs inside results and unwraps it can look pretty messy.
Go offers nothing that an established language can't already do. It'll die just because Google supports it...because Google has no issues with throwing away stuff as soon as they lose interest, no matter how many people are invested in it.
Pretty much every established language can do the stuff the new languages do. It doesn't mean they do them well, or that they can't be improved upon or that we should simply live with the flaws in those languages even if they cause untold numbers of errors in production code. A simple example would be C and C++'s never ending supply of bugs related to dangling pointers, memory leaks etc., many of which are caused by inherent default choices in the language.
While I don't program Go myself it clearly demonstrates a number of advantages for writing multi-threaded, high availability, high performance applications than some other languages. It compiles to a native standalone executable, it's portable, it has garbage collection, it doesn't carry the baggage of a runtime around with it. Performance wise it sits somewhere between C and Java. I've found tools written in Go such as Prometheus to be remarkably stable and reliable.
The correct design would not support any default copy / assignment operators on any class. Make it an explicit programming intent before adding support, e.g. require the class to have a pure copy constructor / assignment operator as a hint for the compiler to fill in or actual implementations supplied by the programmer .
C++ has tried to retroactively add stuff like move semantics (causing overload resolution to become ridiculously more complex than it already is) and now has some scoped / shared pointers that can catch copy problems but the reality is its still unsafe-by-default.
It may explain why languages like Rust that take the opposite approach are gaining such popularity.
... no.
No complex device pops into existence. It comes about as the result of a long development phase, prototypes, testing, rejigging, more prototypes, trials, rejigging etc. There is a large upfront cost to all this but the pay off is in when they get things right.
I really don't see this as any different. Perhaps the purpose of this is to test the solar panels durability in a questionable climate and determine what the actual limits are for such a system. If it can work in overcast Normandy then it can work in sunnier climes. If the panels can have trucks rolling over them then they'll be fine in car parks. If they can make 1km of panels they can shake issues out of the production process.
Of course they could stick panels on roofs or mount them on poles above ground, but perhaps the purpose of the experiment (since it is an experiment) is to see what happens when they do it like this. What are the costs, problems and benefits of such a solution compared to other ways? The only way to tell is to try.
Otherwise there are already lots of Linux dists and few of them need to cut as many corners as Rasbian to get it to run on a slow embedded device.
At the very least it would be better to teach in Typescript that addresses some of the shortcomings in JS, but then someone would moan that it's Microsoft again. But better yet, programming would be taught on a structured, forgiving, well designed standalone language. There are plenty to choose from. Scripting and other concepts would be introduced once the basics were learned.
"The Church of Scientology - brains washed 24/7. Don't forget to ask for your rundown purification coupon book - of $50 value!"
Aside from that I really couldn't stand the total passivity of the people I worked with. Every email / call was "How do I fix this problem?" rather than "I found a problem but I have this solution I want to run by you", or "FYI I found a problem but I fixed it". It was like they couldn't think for themselves or were afraid to. They wouldn't even push back on my suggestions. I hated every minute of dealing with them. The company clearly did too because they ended up selling the entire operation to Infosys.
That would explain why they shut the group down. It'd be interesting to know the reasons why but my own experience of supervising a team in India is that culture, language and staff retention are serious problems. Whatever you think you're saving by paying less you could more than lose in terms of productivity and code quality.
Interesting. The NIMBY-ism in the UK is predominantly right wing in nature.
If Magic Leap could selectively remove clothing it might sell better.