|
1. The lounge is for the CodeProject community to discuss things of interest to the community, and as a place for the whole community to participate. It is, first and foremost, a respectful meeting and discussion area for those wishing to discuss the life of a Software developer.
The #1 rule is: Be respectful of others, of the site, and of the community as a whole.
2. Technical discussions are welcome, but if you need specific programming question answered please use Quick Answers[^], or to discussion your programming problem in depth use the programming forums[^]. We encourage technical discussion, but this is a general discussion forum, not a programming Q&A forum. Posts will be moved or deleted if they fit better elsewhere.
3. No sys-admin, networking, "how do I setup XYZ" questions. For those use the SysAdmin[^] or Hardware and Devices[^] forums.
4. No politics (including enviro-politics[^]), no sex, no religion. This is a community for software development. There are plenty of other sites that are far more appropriate for these discussions.
5. Nothing Not Safe For Work, nothing you would not want your wife/husband, your girlfriend/boyfriend, your mother or your kid sister seeing on your screen.
6. Any personal attacks, any spam, any advertising, any trolling, or any abuse of the rules will result in your account being removed.
7. Not everyone's first language is English. Be understanding.
Please respect the community and respect each other. We are of many cultures so remember that. Don't assume others understand you are joking, don't belittle anyone for taking offense or being thin skinned.
We are a community for software developers. Leave the egos at the door.
cheers,
Chris Maunder
The Code Project | Co-founder
Microsoft C++ MVP
modified 16-Sep-19 9:31am.
|
|
|
|
|
#Worldle #374 1/6 (100%)
🟩🟩🟩🟩🟩🎉
https://worldle.teuteuf.fr
"A little time, a little trouble, your better day"
Badfinger
|
|
|
|
|
I often feel like code review are mostly filled with unneeded comment for the sake of commenting or to take some sort of "ownership" that doesn't do anything special beside burdening the reviewee with a special cosmetic change udpate.
Anyway, someone was updating my code and I was feeling revengeful so I also asserted my opinion on purely cosmetic and totally irrelevant code! 
Although, come to think of it, the guy was doing unnecessary work in Dispose() because "that's what is done everywhere", even though it's not needed and closing documents take godamn too long (due to all those unncessary piece of code run in all those Dispose() method), mmmrrppphhh... I stick to my gun!
|
|
|
|
|
Super Lloyd wrote: Anyway, someone was updating my code
One of my earlier co-workers discovered that my code contained a '#define ever ;;' so that I could write an infinite loop as 'for (ever) { ...'. A few years earlier, I was working in a CHILL environment; in CHILL 'DO FOR EVER' is a part of the base language.
This construction made my coworker so upset that he not only changed it where he had discovered it; he searched through the entire code base of the company for other uses, and found a good handful; I had been programming with 'for (ever) {' for a couple of years by then (in embedded software, infinite loops are commonplace), changing every one of them to 'while (0) {', adding an angry commit comment that requested everybody to refrain from making such 'jokes' in our program code - we are a serious company!
Then he brought it up at the scrum, to make sure that everybody would know that in our company, we do not code that way.
I asked if we could make it slightly less cryptic by using 'while (true) {', but this fellow would not under any circumstances accept that. According to him, there is one, single way of coding an infinite loop, that is immediately recognized by every programmer in the world, and that is 'while (0)'. So he would not tolerate anything else.
He certainly had no formal authority, completing his degree about three years earlier, having worked in the company for half a year, I was 25 years his senior. I didn't have to accept his dictate. But he had an unbearable arrogance and self confidence that I didn't care to fight against, so I just nodded "OK!".
At least that episode gave me a story to tell - this is certainly not the first time 
|
|
|
|
|
Wordle 591 3/6
🟨⬛⬛⬛⬛
🟩🟩⬛🟩⬛
🟩🟩🟩🟩🟩
|
|
|
|
|
Wordle 591 6/6
⬜⬜⬜⬜⬜
⬜🟨🟨⬜⬜
🟨⬜🟩🟨⬜
🟨⬜🟩🟩⬜
⬜🟩🟩🟩⬜
🟩🟩🟩🟩🟩
|
|
|
|
|
If computer is a bicycle for the mind, is ChatGPT then a pedelec? 
|
|
|
|
|
Or just playing cards on the rear wheel.
|
|
|
|
|
Like in Øystein Sunde Sykkeleiker[^]?
I never learned to play this piece - I tried but gave up. Later, I learned that it is played with a different tuning, which makes it a lot easier. But by that time I had given up the guitar entirely.
|
|
|
|
|
Just a random thought:
No doubt we are at a trading war with China ("which we call Red China ..."). We try to curb their technological development by refusing to sell various high-tech components, limiting Chinese students / researchers / ... access to 'sensitive' software etc. It is too late. Years ago, they reached a level where they no way are 'dependent' on Western technology. When we close the door, they certainly can respond with a shrug and go back to their offices and workshops and develop something equally good, or better.
If they do, they could protect their software (and similar intellectual property) from theft by Western spies in a simple way: If they develop new programming languages expressed in Chinese script, the source code will make no sense to 99,9% of all Western software developers. We could try to translate the ideograms one by one, like we can translate spoken languages word by word: The result may be close to gibberish. Like trying to translate Lisp or APL to C++ - I wouldn't like to take the responsibility for maintaining that code base.
We cannot take for granted that a Chinese language is based on concepts similar to Western ones. E.g.: What we consider 'truth', in a very positive sense, is better the less it is subject to discussion, the more absolute and unambiguous it is. I was told that in Chinese culture, this is a 'simple truth', a primitive thing. A deep truth is one that can be understood in different ways. The more meanings you can give to a truth, the deeper and more valuable it is. A programming language with elements of such concepts may be very difficult to transform to C++.
Some of us remember Prolog, the predicate language: You develop your solution starting out without any restrictions at all, adding restrictions (predicates) one by one: The sum of X and Y must be 10. X and Y are yet unrestricted. You restrict them by requiring that the product of X and Y must be 24. Still, it holds true for several values. Your add another predicate: X > Y. The Prolog interpreter says: True - in the sense: I have identified a simple truth, that holds, assuming that X is 6 and Y is 4. Up until that point, you worked with a truth containing many possiblities.
I think this solution method bears some resemblance to the simple and deep truth way of thinking. Certainly: Prolog was pushed by Japanese researchers, but their culture has stronger ties to Chinese culture than we might be aware of. 40 years ago, when Prolog was heavily pushed, China was at a stage of development where it could not follow up, or take the initiative, the way it may be capable of today.
Most Chinese software developers have at least some mastery of English; the keywords of a programming language are not completely Greek to them. They can draw on our software solutions. While there are people in the Western world learning Chinese ("und I'm learning Chinese, says Werner von Braun"), not many of them are software developers.
If China in five to ten years, say, builds the world's strongest software industry, demanding (as an element in the trade war) that all electronics manufactured in China shall be programmed in languages expressed in Chinese script, with documentation in Chinese ... Maybe you can create fully 'Western style' end user apps, but the APIs are in Chinese. The only way to follow up, to maintain the products, to steal even open-source software, would be to learn Chinese language, concepts, cultural idioms and similar elements.
Would you do that - learn what you need to know to handle software driven electronics manufactured in China? Or will you say 'Being a plain end user of Chinese products is good enough for me'? Is is OK to close off a market of 1500 million consumers, because Chinese consumer authorities demand that anything sold in China shall have both user and maintenance documentation in Chinese, and be maintainable in China, i.e. software produced in a language and with tools compatible with Chinese standards?
I can imagine that China could do something like that. Even if we try to hang onto it, the IT industry of the West would nevertheless be turned into a software banana republic. Like the West has been telling the rest of the world: Just change your ways and your society into something like us, and you will succeed!, we will be told: Just change your software development ways into something like our way, and you will succeed!
I am certainly not saying that this will happen, just that it might happen. We should not underestimate the risk.
|
|
|
|
|
You have a rather narrow view of software if you think one nation can monopolize it. That's like saying the rest will just shut off their brains. The fact the west is where it is is partly related to culture and a particular mental attitude ... there are some nationalities that just don't work well "as a team".
"Before entering on an understanding, I have meditated for a long time, and have foreseen what might happen. It is not genius which reveals to me suddenly, secretly, what I have to say or to do in a circumstance unexpected by other people; it is reflection, it is meditation." - Napoleon I
|
|
|
|
|
I did not intend to suggest that "the rest will just shut off their brains". But in my childhood, everyone ridiculed Japanese industry: Suggesting that European and US camera makers will loose the market to Japanese makers? Hah! You're crazy! Leitz, Hasselblad, ... Noone can knock them out!
Sure enough - they did survive. Just barely. Lots of smaller makers closed down. Nikon F came in 1959, but ten years later, lots of people still viewed Japanese cameras as primitive clones of Western ones. They refused to relate to the fact that the Japanese were taking over major parts of the market.
Same with electronics: We considered Japanese radios and receivers to be cheap transistor boxes, ignoring that brands like Kenwood, Yamaha, Pioneer, Sony, ... were taking over a major part of the world marked. Similar to Leica and Hasselblad, Western products gradually became 'speciality' brands for those who could pay a premium price.
Japanese cars were laughed at, too. It took many years of industry statistics proving their very high reliability and durability before they were taken seriously. How many percent of the world market do they have today?
I think that we today mis-judge China the way we mis-judged Japan throughout the 1960s and 1970s. At that time, their industry was very capable, but we closed our eyes, refusing to accept it, until we were forced to realize not that they will or may take over essential parts of the the world market, including the Western one, but that it had happened years ago.
The shipping crisis last fall made lots of people realize how critically dependent we already are on China: What are we going to tell the kids if the Christmas gifts don't get here in time? Lots of people never went beyond such rather primitive understanding of the problem. This isn't about Christmas gifts, it isn't solved by shipping the gifts by rail through Eurasia to European harbors. If, in a trade war, China closed down all 'export zones' overnight and put an embargo on all Chinese exports to the Western world, we would almost instantly have a severe shortage of a long list of products, from shoes and t-shirts to toys to electronics (including electronic components).
They could, rather than an embargo, still make money on selling their products to the Western world, but put restrictions on them. We have the last year or two had a 'right to repair' outcry in the smartphone markets, strongly backed by EU. If China makes a similar requirement, that products should be 'maintainable', in specified terms that includes requirements to software maintainability, demanding a Chinese based programming language and environment, we could still buy those smartphones and all other sorts of digital electronics. The Chinese could maintain them, but we couldn't.
Programmed electronics is everywhere nowadays. The handbook for my new kitchen oven spends a full page listing all the software licenses that applies (including a JPG package - I have no idea why they would need that!). A huge number of Chinese products are similar, and the share is increasing. Introducing maintenance requirements as I suggest could more or less paralyze essential parts of Western business.
So you would not "shut off your brain". But how would you handle that situation, that anything bought from China must be maintained using Chinese-based tools? If everything you want to sell to those 1500 million people must be maintainable by Chinese based tools, will you provide it?
Maybe you would claim that "The Chinese cannot do that!" There are some funny collections of "Last words" that come to mind
|
|
|
|
|
trønderen wrote: If they develop new programming languages expressed in Chinese script, the source code will make no sense to 99,9% of all Western software developers.
I suspect Google Translate will be good enough to get the general idea, for a first step to translating it to usable, compilable English. If you know what it does, hints are probably good enough to figure it out.
|
|
|
|
|
I had a Chinese native in my "study group".
His approach to problem was - "we cannot go home until we ALL agree ".
Needles to say - we did not get very far resolving the issue due to "lack of team approach"
as he put it.
For a few months I worked for a small computer retail outfit and I was the on "white" person there.
The company "objective" was to have certain number of full 10 gallons drinking plastic bottles stacked next to the drinking machine - on the "show " floor. I believe it was seven bottles...and each week a different person was assigned to the task.
Now I live in Texas the "I do not care (it is not my job man ) " state...
Life is peachy...
|
|
|
|
|
David O'Neil wrote: I suspect Google Translate will be good enough to get the general idea, for a first step to translating it to usable, compilable English.
Why don't you start out your translation project showing the feasability of such translation by using Google Translate to provide a "usable, compilable English" from a program in APL? Then, for a second language, go on to Lisp. And then go to Prolog.
Maybe you are expecting a possible Chinese language to be structured identically to C#, but using Chinese ideographs for the keywords. Just replace the ideographs with the English translation, and Voila! There you have compilable C# code! ... Sorry, that is extremely naive. If the Chinese language is based on a completely different way of thinking, a different approach to problem solving, you might be at loss.
One Norwegian poet stated that "Your choice of words is important, but your choice of language is far more important. You can replace the words and say almost the same, but if you replace the language, it won't help you that the words are the same". I guess that your Google Translate approach would end up with something like that. The words may be English, but they make little or no sense as a program solution.
|
|
|
|
|
I'm not asking how to codez teh homework, and I'm looking for more theory. But, if this seems like a programming question, then just downvote this sucker and give me angry emojis. 
But, C++ modules... what's the big deal with them? In JavaScript/ECMAScript it's a huge deal because prior to modules the best we had was clumsy hacks to workaround lack of support for separating code. But, in C++... I don't get it. What's the benefit over using a static library with a pre-compiled header?
This one of them things where history just repeats under a new name so younger devs feel like there's change when there's really not? Or is this a marketing thing where C++ is trying to play like the new, cool kid on the block too?
Edit:
Also, when did using the pre-processor become discouraged in C++? I never understood the disdain for that (assuming you don't go too crazy with macros like the Win32 API does). Years and years of C coding and I never once ran into an issue because of the pre-processor, so generally I just chalk that up to people wanting to sound fancy by insulting things they have little concept of.
Jeremy Falcon
modified 9hrs 15mins ago.
|
|
|
|
|
Well, I probably should've Googled a bit more. Came across a better explaination that, once you remove all the useless hoopla, said this:
Quote: Before C++ modules, only one option was available: precompiled headers. They are not standard therefore results will vary depending on platform and compiler.
IMO that's the only valid argument for them. Everything else is a crap argument. Guess this is one area where MS was way ahead of the curve on.
Note: I have nothing against modules. I'm just no longer fooled by hoopla. Decades of coding will do that to you.
Jeremy Falcon
|
|
|
|
|
The idea is not bad. But as far as I know there is not yet a standard defined and google and MS do it in a different way 
|
|
|
|
|
0x01AA wrote: The idea is not bad
Yeah, at its core I think it's nice to standarize this. Not trying to sound poopy, just trying to get to the truth without hoopla is all.
0x01AA wrote: But as far as I know there is not yet a standard defined and google and MS do it in a different way
This is makes me laugh. That twisted sense of humor kicking in. 
Jeremy Falcon
|
|
|
|
|
Note that VS has one problem with modules that is worth being aware of: forward declarations. I reported this a year ago, and it would be nice to see it fixed: Visual Studio Feedback
|
|
|
|
|
Jeremy Falcon wrote: Before C++ modules, only one option was available: precompiled headers.
That was never true and is even less so now. Precompiled headers just allow compilations to run a bit faster, but they were never mandatory, and are probably less valid with modern high powered systems.
|
|
|
|
|
Richard MacCutchan wrote: That was never true and is even less so now.
How so? AFAIK there was no other pre-compiled mechanism for removing header compilation prior to PCH.
Richard MacCutchan wrote: Precompiled headers just allow compilations to run a bit faster, but they were never mandatory, and are probably less valid with modern high powered systems.
This is missing the point. Nobody said PCH was mandatory. We're talking abstract concepts here, a bit higher level than this.
Jeremy Falcon
|
|
|
|
|
Maybe I missed the point you are trying to make.
|
|
|
|
|
More like trying to understand what the big deal is, not that I have anything against them in theory. But to me, it seems they may add a slightly better way of doing things, but it's not Earth shattering like it was for JavaScript/ESM as C/C++ had more than one way to split and re-use code before this.
I'm a cranky, old-ish fart.  So, ya know, want to get past the fluff I've seen on Google so far and get straight to the real talk as I inquire about them.
Jeremy Falcon
|
|
|
|
|
I don't know about modules; in my current job/career path, I will probably never use them.
But about the pre-processor thing ... I think it was just abused too much at some point and became a mess; there are just better way to do the same thing with modern language features.
It's the same thing with goto, in itself it's not bad, but when it's badly used, can be a big problem (resource leak, safety issues, ... )
CI/CD = Continuous Impediment/Continuous Despair
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
