|
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.
|
|
|
|
|
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 agree. Chinese is a tonal language when spoken, so what's written may require context.
I guess, not knowing the language will have to change.
"A little time, a little trouble, your better day"
Badfinger
|
|
|
|
|
|
I agree. Not a Chinese language expert, but almost nothing is impossible. I have the theory that Chinese and Japanese (Korean included) written languages should have an edge in programming languages. Our phonetic languages can be compressed in their languages. Perhaps other CP folks can provide some opinions.
"A little time, a little trouble, your better day"
Badfinger
|
|
|
|
|
You seem to grossly underestimate the variation of languages. And you underestimate software complexity, thinking that "If you know what it does, hints are probably good enough to figure it out" is sufficient. You are wrong for anything beyond very trivial programs.
For a reason, I proposed that you start out with APL - that is certainly an algorithmic language although built on somewhat different basic concepts. Do you think that GT is good enough to hint you about this simple statement?:
x ← {⊃1 ⍵ ∨.∧ 3 4 = +/ +⌿ ¯1 0 1 ∘.⊖ ¯1 0 1 ⌽¨ ⊂⍵}
Or create enough hints for you to rewrite this expression in C#?:
(~R∊R∘.×R)/R←1↓⍳R
Consider these examples to be below the trivial level.
Also, expect basic concepts to differ significantly more than those of APL. There may be a lot more to making software work than replacing Chinese text with English.
But you are of course allowed to completely ignore the real issue, shrugging it off: It can be fixed.
|
|
|
|
|
You are saying that if China made APL their official language, but all the symbols were Chinese Unicode, a good APL programmer in English couldn't use the Google Translation to get a good idea of what was going on? I say bullshit. They could get close enough to figure it out.
It is highly unlikely that China would create a brand new language just for programming, just to give them full control in the manner you are saying. If they did, with the huge number of Chinese in the world, and the fact that many of them are bilingual in English, the basics of programming in that language would quickly be known by outsiders. And again, a tool like Google Translate would be enough to make a good start at translating the code to equivalent English (or another spoken language) code.
I have not claimed that a non-APL programmer could convert APL code to C++. They would have to be proficient with the underlying language constructions of both languages in order to do so. But if they are familiar with the underlying language constructions, translation from another spoken/written language is not impossible with a little work, and hints from a tool like Google Translate.
|
|
|
|
|
David O'Neil wrote: You are saying that if China made APL their official language, but all the symbols were Chinese Unicode, a good APL programmer in English couldn't use the Google Translation to get a good idea of what was going on?
No. I used APL as an example of a language based on our concepts, but still so that GT won't be of any help to make you understand what's going on.
David O'Neil wrote: It is highly unlikely that China would create a brand new language just for programming, just to give them full control in the manner you are saying.
The reason for doing it would probably be to get tools that feels at home in their culture. There are more ways to skin a cat, and Chinese cats may be different from cats in the US of A.
Nevertheless: If you are only out to steal algorithms and methods, you might, through great efforts, be able to extract something meaningful from a huge system (say, an OS) written in a Chinese programming language built on Chinese culture and understanding. You would still have a lot left to do if you were to do maintenance on that system. If some Chinese smartphone, say, becomes a great success, and you want to develop apps for it, you might have a hard time fitting a C# module in. It may be against the license for the phone, too. You can't even write a C# function to plug into an APL workspace, which is a system based on Western concepts and ideas!
|
|
|
|
|
trønderen wrote: you might, through great efforts, be able to extract something meaningful from a huge system (say, an OS) written in a Chinese programming language built on Chinese culture and understanding
Silicone works the same in China as it does in America. Registers are registers. PUSH and POP do the same thing, even if they aren't called PUSH and POP. You are not going to change the fundamentals of machine language. Even if you create something to compete with ARM and Intel, the logic at the board level won't be something radically new. (It could be radically old, though, if it was a LISP machine!)
Anyway, interesting discussion. Thanks.
|
|
|
|
|
very enlightening
diligent hands rule....
|
|
|
|
|
During the 70s and 80s Japan had been far more prevalent in electronics than China today. It's been in pair with US even in the high-end chips, something China doesn't achieved quite yet. And I don't see many people use Japanese today. China is not even at Taiwan's and South Korea's level. Heck, Intel produces i5 chips in Vietnam, but not in China, and now is shifting billions of dollars of investments to Western Europe. So maybe you can put on hold learning Chanese just for a little while. 
Advertise here – minimum three posts per day are guaranteed.
|
|
|
|
|
We must not confuse what we today think of Japan's industry and business in the 70s and 80s with how we viewed it when we were still in the 60s and 70s! (Be aware of that 10 year shift from my time reference to yours - a lot changed during those ten years!)
We might see a similar shift from how we view Chinese industry and business today to how we in fifty years look back on how China was in the 2020s.
Maybe closing your eyes is a good strategy. I am not quite sure that it is the best strategy.
|
|
|
|
|
Another cultural difference- Asian philosophers have been critical of Western dualism for quite some time, and that might give an edge to situations that aren't polar yes/no, good/bad, etc.
Many of the early applications of fuzzy logic control systems were in Japan.
Fuzzy logic - Wikipedia[^]
You even see it in entertainment media. For instance, Hayao Miyazaki flatly refuses to do simplistic "good vs evil" stories, and that's a tendency that's true for other anime and manga.
|
|
|
|
|
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
Several assumptions in that.
First of course is that the theft is of the source code in the first place. Could just be the idea. Or the process. Or hardware. Or binaries.
Second programming languages follow a set pattern. So if you had the source code, and the compiler, it is not that hard for a knowledgeable group to create a translator which would take the source code, translate the ideographs into an english version and just produce the source code in an english format. No need at all to work in the original language.
Third ideographs in general in the most complete way possible do not provide for a good way to program. The formalism is nice but the day to day activity of producing code is better managed by a far more simpler set of characters. This is equivalent to how cell phones and texting work in japan.
trønderen wrote: 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?
France and the province of Quebec in Canada. A company cannot fire an employee if they cannot use any tool because it is not in French. And selling anything to the government means it must always be in French. I have no idea how they deal with programming languages themselves though.
trønderen wrote: If China in five to ten years, say, builds the world's strongest software industry,
Heard of Alibada? Very, very successful software platform. So successful that the owner started branching out and financing other ventures. Even internationally.
Then 20 years later the Chinese government decided they didn't like it. So now the Founder has disappeared.
Attempts to force success just do not work. Attempting that just leads to toadies that make promises, hide failures and attempt to sabotage anything else that might succeed. There are plenty of other examples which demonstrate that.
|
|
|
|
|
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 30-Jan-23 13:02pm.
|
|
|
|
|
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
|
|
|
|
|
Jeremy Falcon wrote: I'm a cranky, old-ish fart.
You don't know what old is sonny. My youngest son is eight years older than you, and my eldest grand-daughter only ten years younger.
But thank you for the clarification above; it's something I need to learn more about.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
