|
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.
|
|
|
|
|
There are many different types of applications, and the best way to solve their domain-specific problems is with an application framework implemented in a powerful language in widespread use. C++ definitely qualifies on that front.
|
|
|
|
|
Implementing a framework is close to implementing a compiler and its runtime system. Is there any big, principal difference between a rich runtime system and a framework? I see a framework as a high level (and often domain specific) runtime system.
Creating a framework is a "one time job", just like a compiler is a "one time job". (In ""s, because you obviously update and extend the compiler.) It is not the kind of programming project you start off when some customer presents you with a specific application domain problem. If a framework is used for a hundred different application domain problems (if less, it probably wasn't worth the resources to develop it!), I am not worried about that one development project for the framework, but the hundred projects using it.
The hundred projects where you discuss your problem solution with a domain expert, which is not a coding expert, is what concerns me. We must realize, in a very deep sense, that as software developers, we are not domain experts! We need to discuss our proposed solution with those who really know the domain. I do not want to discuss a solution where pointer arithmetic and abstract functions are essential for understanding the solution. It is perfectly fine with me, when I am working alone, but when presenting the solution to a domain expert, I most certainly would want much better tools.
The traditional work pattern is that you meet you domain expert who tells you, verbally, what he wants. Then you go back to the coding lab and do it the way you - as a non-expert - interpreted the signals from the expert. That work pattern has caused a lot of mediocre solutions, because we as programmers really didn't understand what the expert was saying. We have to bring the expert into the real solution building activity. He must see the real code, understand it, relate to it. Then pointer arithmetic and abstract functions are not the right concepts to introduce him to.
So: If you want to build an application domain specific framework, feel free to do it in C++. But make sure that when that framework is used in discussion with a customer, that customer can relate to application concepts only, and can completely ignore issues of heap management, stack alignment, pointers, virtual and abstract functions and so on. Create the problem solution in an environment, i.e. with tools, where such concepts are irrelevant.
I do not see C++ as the ideal for emailing to you customer for him to see if you have understood his explanations correctly, and have the domain expert make corrections and supply the details that you were missing.
To present a counter example: Many years ago, in the age where manually handled paper archives were being replaced with digital solution, I was involved in a couple different projects; you could call it "data modelling" projects: We were helping the customer (one was the city administration of our town) to straighten up which different information collection existed, how they related to each other, which were non-authoritative copies of others, which depended on which others, and so on.
This we did not present as C++ classes with multiple inheritance and virtual functions, but in Entity-Relationship diagrams. They were immediately understood by "everyone", including those who had never used a PC. We could hand out printed ER diagrams and had them returned with extra arrows and attributes of the entities, big question marks, crossed out relations and new relations, for another meeting with users and their experts to discuss back and forth which are the "correct" relations and placement of information fields (attributes).
For those unfamiliar with ER: Transformation of an ER diagram to a relational database is a trivial affair, comparable to the code generator of a compiler. There is an almost perfect 1:1 mapping between entities/relations and database tables. So although there was an "implementation step" where the users where not directly involved, this was an all mechanical process. There were several tools taking the agreed-upon-with-the-customer as input to a table generator. If a meeting resulted in a model change, recompiling to a new set of tables was a trivial affair. So the domain experts and their users was indeed directly involved in the creation of the solution.
Unfortunately, ER didn't survive as a commonly used modelling tool. I see two major causes: First, there is a continuous battle about who is in control, dominating. When one tool becomes too popular, beyond the pure percentage figures, but in the sense of accepted, understood, and acknowledged by the general public, then we the programmers start fearing that we will loose control, loose our hegemony. So we push alternatives that is not yet understood by the general public, in the sense that they can control it. ER became too popular.
So what happened to ER? It was "developed", augmented, by an endless stream stream of extension, most of them could be called "super-academic" of nature, that made it next to impossible to discuss an ER model with non-IT user; they would minimum need a three day course in our ER language to understand what we were talking about. ER grew cancer, which killed it.
Why is VB still around? For the same reason that simple, un-cancerous ER succeeded a generation ago. If we are to discuss the real problem solution with the customer/user, we must have the appropriate tools.
Methinks C++23 is not.
|
|
|
|
|
All good points. The reason I think a framework should choose a language in widespread use (assuming that the language is appropriate) is division of labor: specialization. It's hard to get a framework right, and it's hard to get a language right. It's unlikely that the skills required to implement a domain-specific language will exist within the same team or even the same company. And if the framework uses a language in widespread use, it and its applications will be able to use the tools, and possibly some third-party software, available in that language. It's very unlikely that a company will want to recreate all of that. But if they somehow go down the path of implementing their own language, it's almost a certainty that the first thing to get cut in an economic downturn will be the budget for the language and its tools.
|
|
|
|
|
Seen from an application domain point of view, the best would often be a domains specific language, as you strongly suggest. And, as you also suggest, that could turn out to be costly.
Yet, if that is out of reach, so you have to make due with existing languages, they are not all the same, from the user point of view.
[putting on my asbestos suit:]
Maybe, for some problem solutions outside the IT domain, even VB6 is a better alternative than C++ 23 for discussing the solution implementation with a domain expert.
|
|
|
|
|
To implement an application framework, one must become reasonably expert in the domain. This might come from having worked on software for that domain for many years or through discussions with a domain expert, bolstered by use cases.
I don't know anything about VB6 other than there are many who are quick to deride it. But it might well be an excellent choice for certain domains, just as C++ is often the best choice for real-time systems and servers.
|
|
|
|
|
trønderen wrote: I do not want to discuss a solution where pointer arithmetic and abstract functions are essential for understanding the solution.
If you have a domain where pointer arithmetic or abstract functions are the best solution for the problem, then use them. I'd argue that very, very, very few problems require pointer arithmetic. But if you aren't able to convey to your client that in your framework, abstract classes are the way programs enforce having a common calling convention for similar types, then you aren't a very good communicator. The heart of what you are talking about is communication, not programming languages. You are saying that it is necessary for the wine makers to understand the code. In fact, if they want to understand the code, it is your job to help them because that is your domain expertise, not theirs. If you are overmodeling it in C++, you will likely overmodel it in another paradigm as well. Hell, C# has interfaces, which pretty much do the same thing. I've made objects in VBA for Office. If someone wanted to understand my work, I've done my best to make it simple. But at some point it can't be made any simpler, and it will have to adhere to the limitations of VBA (which I don't believe allows abstract classes for one thing).
Extending your earlier argument for ER diagrams, as far as I'm aware, there is nothing stopping a C++ programmer from interacting with a client using ER diagrams, and tailoring their feedback back into C++ code. (Granted, such tailoring may be much easier in another language.) As I've said, your point is one of communication, not programming. And I agree, communication is VERY important.
|
|
|
|
|
Jeff Bezos’ space tourism company safely brought its crew capsule and New Shepard booster back to Earth after a one-year hiatus. Now there are two
...billionaires engaged in a **** measuring contest, that is.
|
|
|
|
|
Kent Sharkey wrote: back to Earth after a one-year hiatus
Does that mean it was orbiting for a year? Poor sentence structure.
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.
|
|
|
|
|
Watching those boosters land always reminds me of the goofy effects in Buck Rogers or Flash Gordon B&W shows. It's really amazing how sci-fi becomes reality decades later. And I still can't wrap my head around the computations and sensors needed to do all this.
|
|
|
|
|
There are actually several active orbital launch systems, but Blue Origin isn't one of them. New Glenn never reaches orbit. New Glenn is nothing more than a rocket powered amusement ride.
|
|
|
|
|
In Visual Studio 2022 version 17.8, we introduced a feature that allows C++ developers to easily view the size and alignment of classes, structs, unions, base types, or Enums. For more perfect unions (and classes, structs, and enums)
|
|
|
|
|
Most Windows users pay attention to updates only when they wreck something, like the latest story about universities suggesting uninstalling December 2023 updates to fix broken Wi-Fi connections in Windows 11. Better late than never?
|
|
|
|
|
I've been using Windows 11 since close to when it came out (purchased a new machine with it) and haven't seen this bug. I can see how it would be really annoying to those whose systems have it but I suspect it isn't that widespread.
|
|
|
|
|
Yeah, not here either. There's all kinds of fun that can happen I suspect when you combine all the variations of BIOS/chipsets/hardware. Sometimes I marvel that Windows works at all as well as it does.
TTFN - Kent
|
|
|
|
|
I see it quite regularly on work PC. It is really annoying. At first I thought I was alt-tabbing without noticing 
|
|
|
|
|
The video, featuring a cat named Taters, was sent back from nearly 19 million miles away by NASA’s laser communications demonstration, marking a historic milestone. Cat videos...in SPACE!
Their conquest continues
Hemi-semi-demi dupe, but I think the last one was just "a message". This one is showing they can stream content.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
