|
Microsoft added the mixed reality platform to a list of deprecated Windows features. Do they think they're Google now?
Yet another reason I tend to avoid buying Microsoft hardware. They never seem to last very long. (although I have owned their mice and keyboards, but I'm still suspicious)
|
|
|
|
|
The difference between 1983 and 1993 is vast. Since then, not so much "Don’t you see if you want something better, and better, and better, you lose the good"
|
|
|
|
|
The real question is can Doom run Doom? We know it ran on Windows NT.
|
|
|
|
|
Problem that hit university students and businesses is thankfully resolved It must have affected some exec at the company
|
|
|
|
|
As the more code you add to an application, the slower development becomes, I view all code as technical debt. So avoid debt - don't write any code
|
|
|
|
|
The feedback we’ve received since our announcement and launch of .NET Aspire last month has been amazing! For those that aspire to reach for The Cloud
|
|
|
|
|
A number of auto dealers have deployed ChatGPT-powered conversational artificial intelligence (AI) tools, or chatbots, as a way to provide quick, customized on-demand information to online car shoppers. Never trust an AI car dealer?
Or is it just AI used car dealers? Used AI car dealers?
|
|
|
|
|
Aahh, the sweet smell of payback. After dealerships played the markup game to the point where a small number of dealerships ended up with double the MSRP, it's nice to see a consumer beat them at their own game.
|
|
|
|
|
An international law enforcement operation codenamed 'Operation HAECHI IV' has led to the arrest of 3,500 suspects of various lower-tier cybercrimes and seized $300 million in illicit proceeds. Did they finally catch up with those people copying DVDs?
|
|
|
|
|
Kent Sharkey wrote: Did they finally catch up with those people copying DVDs?
They're still working on the VHS copying masterminds.
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows.
-- 6079 Smith W.
|
|
|
|
|
We’re updating the Uno Platform VS Code extension to support the C# Dev Kit, replacing the older C# extension OmniSharp. For those that prefer C#
|
|
|
|
|
CyberRunner completed the labyrinth maze game in 14.48 seconds So much for trapping the AIs in mazes
I refused to type, "It's aMAZEing"
|
|
|
|
|
Bill Gates through the Gates Foundation and its partners, is looking into AI innovations to improve living conditions in low-income areas across the world. And he's never been wrong in the past
(no one mention Windows Millennium Edition)
|
|
|
|
|
I'm not sure how AI can solve war, strife, child/women abuses, food and water shortages, lack of education opportunities, cast systems, drug problems, and religious dictates/dictators.
Sorry, that probably should have gone in the old "Soapbox" forum, but the point is, what is Bill smoking that he thinks AI can solve problems that have to do with people, not technology?
|
|
|
|
|
But...but...it can draw funny pictures! Perhaps a nice illustration of "a corgi in a smoking jacket blowing bubbles out of a pipe while skateboarding" will solve the Israel-Palestine conflict finally?
Yeah, there's some heavy-duty Kool-Aid drinking going on there.
TTFN - Kent
|
|
|
|
|
Kent Sharkey wrote: Perhaps a nice illustration of "a corgi in a smoking jacket blowing bubbles out of a pipe while skateboarding" will solve the Israel-Palestine conflict finally?
Well, they've tried (almost) everything else...
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows.
-- 6079 Smith W.
|
|
|
|
|
IMHO most of those things you mentioned cannot actually be solved. At best they can be managed.
While AI might be able to help in that management a bit the bigger problem is AI/robotics/automation putting too many people out of work in the coming decade or two. The world needs to figure out what to do with several billion chronically unemployed souls.
|
|
|
|
|
What about Bob? Which was worse?
I’ve given up trying to be calm. However, I am open to feeling slightly less agitated.
I’m begging you for the benefit of everyone, don’t be STUPID.
|
|
|
|
|
Over the past few years, the C++ community has coped with challenging social media situations, calls for a so-called successor, and signs of upcoming anti-C++ safety regulations. And the best little C++ it could ever be
|
|
|
|
|
Except in the case of real time systems, C and C++ need to be retired.
|
|
|
|
|
Why? They are perfectly fine languages for those who want to understand programming. I'd argue that C++ is better in many ways, because it has easier-to-use constructs for memory management without leaks, but maybe that's just me.
|
|
|
|
|
David O'Neil wrote: Why? They are perfectly fine languages for those who want to understand programming. Assuming that "programming" means "generating the proper machine instructions". If you want to learn basic computer hardware, C/C++ is almost as good a tool as assembler.
On the other hand, if "programming" means "systematically develop methods to solve an application problem", then you work in terms of the application domain. The user rarely if ever care about (or even know about) "memory leaks", constructors and destructors, even the difference between a float and a double. The user knows if a numeric value represents a count (or integer, as we call it) or a measurement (we call it floating point).
And so on. C/C++ is perfectly fine for managing a lot of tiny little details that have no direct relevance to the application problem. Managing the tools. Less so for solving the problem at the conceptual level.
I prefer to develop problem solutions at the application level without being concerned about memory leaks, cache, locality, stack alignment, overflow exception handlers, destructors, type casting, pointer arithmetic ... When the way to arrange the data and how to manage them to solve the problem is in place, and I go looking for a way to implement it on a computer, picking a language, I may of course say that "stack alignment and memory leaks are super essential for this to run!" that I go for C/C++. Or I could say: "I trust the compiler and runtime system to handle low level technical details is the best, or certainly good enough, way", and choose a language where you don't control those details, and don't have to worry about them. You worry about the application problem being solved in a correct way.
I have done my share of assembly, C and C++ programming. C# is one step up (unless you insist on digging down into the details, then it is just half a step), but only one step. The stairway is long.
Programmers tend to ridicule application-near languages and methodologies, and do not realize that the reason why these languages survive is that they don't bother the user with leaks, cache and multiple inheritance. Maybe a language allows some low level manipulation, but you don't have to. Can you do bit field manipulation in VB6? Maybe, but who cares. Even if you could do pointer arithmetic (if it was meaningful), I am quite sure that those who still program in VB never make use of it, or even know what it is. That is the reason why VB still lives: The programmer (who is often an application domain expert rather than a PhD in bit fiddling) doesn't know and doesn't care about those hardware details that are so essential to C/C++ people.
Besides: K&R C was little more than a set of assembler macros. You really could tell from the source code what the CPU was going to do. With OO, multiple inheritance, virtual and abstract functions, optimizing compilers and whatnot you still have an illusion of being close to the hardware, but fact is that a good share of C++ programmers do not have a clue about how, say, multiple inheritance works at the machine code level. So in small, selected areas you can use libraries (still hiding the machine code level that you really want to control) to give you an even stronger illusion of being in control. You don't have to, but still you have to cope with memory leaks and integer overflow. You pay the price, but without reaping the benefits of not having to worry about the details.
If your application domain is the inner workings of an OS, or a compiler, C/C++ may be a reasonable choice. For application problem solving, the things that C/C++ is really good at are not relevant at all.
|
|
|
|
|
trønderen wrote: For application problem solving, the things that C/C++ is really good at are not relevant at all. In the case of C, I can agree to an extent. C++, on the other hand, is very good for application problem solving. You will probably disagree, with the attitude you've expressed, but I've given one example in my C++ tutorial in my sig. C++ is very good at modeling the problem domain with simple constructs. I will agree that it is a pain to have to write headers, and keep memory safety in mind, but learning about memory does teach you a lot more about how the computer fundamentally works than you would learn with memory managed systems.
|
|
|
|
|
As long as the problem to be solved is yours, you are most likely right. We have got a lot of great program development tools, because the domain experts are available. You do not have to leave the coding lab.
Very few code developers are domain experts in other domains. If the real user is a pipe organ player who wants to control the pipes from an electronic keyboard, with proper tactile feedback on the keyboard, or a tailor making national costumes and wants his sawing machine programmed for specific patterns, or a wine maker wanting an automatic system for monitoring the entire process, or whatever that is far from heap management and stack alignment: You need to discuss the solution with someone who doesn't know an if from a while. You can of course sit down at a conference table to discuss requirements - but that is not the solution, or how to make it. Unless you yourself are an honored pipe organ player, tailor of national costumes or wine maker, you have to discuss the solution, beyond the requirements spec, with someone who knows.
Unfortunately, this 'you have to' has too often been overlooked. Not the least in open source communities. Too many IT developers grab the requirement specs, dig down to their coding lab and pop up a few months later with some sort of half-useless code but proudly displaying a checklist with 87.4% checked off, promising that more will come in the 0.94 release. Or at least in the 0.95 or 0.96 release ... Yet, it just isn't done right! That is not the way we work!
Bring in a professional expert who know how you work. Have him tell what lies behind the requirements spec. That spec is made in a framework of domain specific conventions, traditions, established work patterns. You have to know those to know how to build the solution. When you bring in that domain expert, he must understand what you are doing when building the solution, so that he can stop you, correct you, adjust your compass when you are heading in the wrong direction. He must understand what you are doing.
I believe that C/C++ presents major obstacles for a non-programmer domain expert to understand the solution created.
The quality of the tool is not measured by how well you, the programmer, think that you understand of the application domain. That will be mediocre in any case (at the best). The important measure is how well the domain expert understands your proposed solution implementation, and to which degree it is possible for him to make specific corrections and adjustments to that solution.
For the organ player, the national costumes tailor and the wine maker, I believe that other problem solution formats than C++ are more suitable for discussing the implementation.
|
|
|
|
|
trønderen wrote: I believe that C/C++ presents major obstacles for a non-programmer domain expert to understand the solution created. And I believe that if you are making it so complicated in C++ that you cannot explain it to the domain expert in their own field, then you are not a domain expert on C++, and are a hack who misuses his tools. C++ is very able to model real-world domains in simple terms. And if the real-world domain is complicated, C++ is capable of modeling that, as well. Good C++ is simple, although you probably don't believe so.
|
|
|
|
|