Countries may be artificial categories but they do serve as convenient entities for purposes of sampling the effects of language & cultural mental habits on software development. No doubt some Chinese programmers program like Germans and vice versa, but most don't and that lets us compare the software development outcomes on a country by country basis.

I suspect that the belief in the necessity of "defining the domain and requirements" might be a Sapir-Whorf artifact of Western top-down thinking. That may be how many people in the West are taught to program but it's certainly not how Darwinian evolution or natural neural nets operates both of which create very successful large-scale programmed systems.

And the notion of requirements drift supports my belief that many failures of software development are not the fault of the methods or the programmers. Is requirements drift evidence of an endogenous flaw in the development process or an exogenous necessity in an uncertain and dynamic environment?

It may be true that Western developers are taught to make models, but do all successful programmers make them? Do all languages even have a word for "model"?

It may be true that Western developers are taught to make models, but do all successful programmers make them? Do all languages even have a word for "model"?

Everyone has a model, even lone rangers. In many cases it is implicit.

It may be true that Western developers are taught to make models, but do all successful programmers make them? Do all languages even have a word for "model"?

Everyone has a model, even lone rangers. In many cases it is implicit.

Maybe. Is there research in human neurobiology or cognitive science to prove this is universal? Or do some people just believe there must be models because the Sapir-Whorf effects makes them think that way?

Countries may be artificial categories but they do serve as convenient entities for purposes of sampling the effects of language & cultural mental habits on software development. No doubt some Chinese programmers program like Germans and vice versa, but most don't and that lets us compare the software development outcomes on a country by country basis.

Nice if you want to make a report for the OECD, or whatever. Culture and inherited customs are more important in the current case,

Chinese programmers don't need models, they just copy Western software.

Chinese programmers don't need models, they just copy Western software.

That hasn't been my experience, in general. I've had quite a few students from the Baruch online courses + elsewhere/banking, and MSc supervision in other places of learning. On the contrary, can "westeners" keep up?? Lagging behind somewhat.  Bright Westeners tend to become not-always-bright (project) managers. And they become deskilled.
And the best programmers in my experience are female Chinese students.

Generalisations are easy and usually untrue.

I meant Chinese programmers in China, not Chinese programmers working for Western companies.

gent-based class design, C++ with a robot glue gun


Abstract

Abstracting a set of functionalities into a class which provides a higher level interface often requires tough design decisions. Users who do not have the exact requirements for which the abstraction is optimized will suffer a syntactic or run time overhead as a result. Alexandrescu's famous "policy-based design" provides a mechanism to allow the user to extend and customize an existing abstraction in order to fine-tune its functionality for many different use cases. This is however limited to use cases where each policy more or less represents a compile time strategy pattern.

Alas, not everything is a strategy pattern. In this talk I will explore the viability of a more agent-pattern-like paradigm where each policy knows its requirements and publishes its capabilities. In this paradigm, glue code connecting any valid set of policies is automatically generated using template metaprogramming. This allows much more powerful customizations while maintaining static linkage.

What do words mean? In Greenland they have 50 words for snow. Programmers have even more for blob-like entities.

Mathematicians would never dream of concocting a new concept and call it a quaternion, for example.

“Few programmers write even a rough sketch of what their programs will do before they start coding.”

Corollary: how does a programmer communicate with (non-programmer) client?

“Few programmers write even a rough sketch of what their programs will do before they start coding.”

Corollary: how does a programmer communicate with (non-programmer) client?

Interesting!
If one is writing an Italian opera, why would one write out a English outline?
Perhaps the best language for "sketching" a program is the programming language itself.

Obviously the programmer must communicate with the client in the client's language.  But that does not mean that the programmer should think and sketch in the client's language.

“Few programmers write even a rough sketch of what their programs will do before they start coding.”

Corollary: how does a programmer communicate with (non-programmer) client?

Interesting!
If one is writing an Italian opera, why would one write out a English outline?
Perhaps the best language for "sketching" a program is the programming language itself.

Obviously the programmer must communicate with the client in the client's language.  But that does not mean that the programmer should think and sketch in the client's language.

The language should be understandable by both parties. The onus is on the programmer to explain the intent in a way that the client understands. It's all about communication.

Perhaps the best language for "sketching" a program is the programming language itself.
I disagree. Doesn't work in general. Because 1st party is talking about the solution (of some problem in their head, implicit yes) while the 2nd party is talking about the problem. And the programmers want to start programming the solution ASAP.

Programmers (should) get design blueprints and map them to code. Clients get the logical design sketches.,

Amid a wash of paper, a small number of documents become the critical pivots around which every project 's management revolves. These are the manager's chief personal tools. 


W. Bengough, "Scene in the old Congressional Library/' 1897 
The Bettman Archive

Chemical engineers learned long ago that a process that works in
the laboratory cannot be implemented in a factory in only one
step. An intermediate step called the pilot plant is necessary to give
experience in scaling quantities up and in operating in nonprotec-
tive environments. For example, a laboratory process for desalting
water will be tested in a pilot plant of 10,000 gallon/day capacity
before being used for a 2,000,000 gallon/day community water
system.

There's a lot of nonlinearity in chemical systems with reaction rates, thermodynamics, fluid dynamics, power consumption, heat dissipation, etc.  There's lots of rules of thumb for scaling but they aren't that accurate. Also, if the prototype sysem has acceptable performance (sufficiently low energy consumtpion, sufficiently high throughut, and sufficiently pure yield), then it's worth investing the literal billions in a full scale plant.  And in making the jump to scale, the engineers typically layer-on a bunch more efficiency & control complexity (e.g., heat-recovery systems) that is justified by that scale.

Would a programmer write a prototype program with 8-bit indices on arrays before writing one with 32-bit indices?

Would a programmer write a prototype program with 8-bit indices on arrays before writing one with 32-bit indices?

If portability and hardware-independence were a requirement, then yes. Usually on a feature list.

If it is an afterthought then funny things happen with new software releases... knowledge about the nitty gritty evaporates e.g. Arianne V.