Page 3 of 13

Grammar-Pattern Programmers: Is Over-Abstraction Delivering Projects Faster Or Slower?

Posted: April 12th, 2016, 6:09 pm
by Cuchulainn
QuoteOriginally posted by: PolterAn interesting talk in this context (Lie #2: Code designed around model of the world):Three Big Lies: Typical Design Failures in Game Programming: http://www.gdcvault.com/play/1012200/Th ... 2010.pdfIn short data-driven design? Data inside (1980s OOP) versus outside (the 1970s Structured Analysis/COBOL). Fair enough. Back to the future. A lot of the stuff cannot be disagreed with. The talk could have been condensed into 20 minutes. It was slow moving. But he does have a point.Of course, NVidia/CUDA boards is happiest with SPMD (data-driven) designs??

Grammar-Pattern Programmers: Is Over-Abstraction Delivering Projects Faster Or Slower?

Posted: April 12th, 2016, 6:35 pm
by Cuchulainn
DOD QuoteObject-oriented programming is [...] both anti-modular and anti-parallel by its very nature, and hence unsuitable for a modern CS curriculum.This is not even wrong. It's how you use it.That's why we need modules in C++. And parallel libraries like PPL and TBB. Well worth it

Grammar-Pattern Programmers: Is Over-Abstraction Delivering Projects Faster Or Slower?

Posted: April 12th, 2016, 9:03 pm
by Traden4Alpha
QuoteOriginally posted by: PolterAn interesting talk in this context (Lie #2: Code designed around model of the world):Three Big Lies: Typical Design Failures in Game Programming: http://www.gdcvault.com/play/1012200/Th ... nteresting! Yet this conclusion rests on the assumption that "model of the world" is a noun-focused model (which may be the prevailing thought pattern in Western cultures that the world is composed of distinct and separable objects). But if "model of the world" is a context-based one (which may be the prevailing thought pattern in Eastern cultures) then perhaps the "model of the world" is correct.I'd also quibble for lie #1 in that many (but not all!) software systems actually are platforms in that they define an instruction set that other programs or the end-user can use in different ways or sequences to accomplish their goals. A "word processor" really is a processor and different "word processors" are akin to different CPUs in how they used.

Grammar-Pattern Programmers: Is Over-Abstraction Delivering Projects Faster Or Slower?

Posted: April 13th, 2016, 5:03 am
by Cuchulainn
QuoteOriginally posted by: Traden4AlphaQuoteOriginally posted by: PolterAn interesting talk in this context (Lie #2: Code designed around model of the world):Three Big Lies: Typical Design Failures in Game Programming: http://www.gdcvault.com/play/1012200/Th ... nteresting! Yet this conclusion rests on the assumption that "model of the world" is a noun-focused model (which may be the prevailing thought pattern in Western cultures that the world is composed of distinct and separable objects). But if "model of the world" is a context-based one (which may be the prevailing thought pattern in Eastern cultures) then perhaps the "model of the world" is correct.I'd also quibble for lie #1 in that many (but not all!) software systems actually are platforms in that they define an instruction set that other programs or the end-user can use in different ways or sequences to accomplish their goals. A "word processor" really is a processor and different "word processors" are akin to different CPUs in how they used.It was a bit 'tongue-in-cheek' indeed. I heard the answer in the video loud and clear, but I missed the question;) IMO another example of QuoteNo two languages are ever sufficiently similar to be considered as representing the same social reality. The worlds in which different societies live are distinct worlds, not merely the same world with different labels attached. Edward Sapir I would say CUDA forces the developer to design in a certain way. What is reality? It is relative. All models are wrong, some are useful.

Grammar-Pattern Programmers: Is Over-Abstraction Delivering Projects Faster Or Slower?

Posted: April 13th, 2016, 6:23 am
by Cuchulainn
Which programming style would you like today? There was a short period in he 80s when Logic Programming and Japanese 5th generation AI were going to take over the world.

Grammar-Pattern Programmers: Is Over-Abstraction Delivering Projects Faster Or Slower?

Posted: April 13th, 2016, 7:26 am
by Cuchulainn
QuoteWhile object-oriented design is a nice concept that helps developers on big projects, such as games, create several layers of abstraction and have everyone work on their target layer, without having to care about the implementation details of the ones underneath, it's bound to give us some headaches.Do we blame OOP or do we blame the developers who did not agree (or even know) on inter-system contracts during design? Hardware engineers do not have this problem.

Grammar-Pattern Programmers: Is Over-Abstraction Delivering Projects Faster Or Slower?

Posted: April 13th, 2016, 12:37 pm
by Cuchulainn
Weinberg?s Law of Twins:QuoteMost of the time, for most of the world, no matter how hard people work at it, nothing of any significance happens.Weinberg?s Law of Twins, Inverted:QuoteSome of the time, in some places, significant change happens ? especially when people aren?t working hard at it.

Grammar-Pattern Programmers: Is Over-Abstraction Delivering Projects Faster Or Slower?

Posted: April 13th, 2016, 1:03 pm
by Polter
QuoteOf course, NVidia/CUDA boards is happiest with SPMD (data-driven) designs?QuoteI would say CUDA forces the developer to design in a certain way. I don't think it's just GPUs -- data parallelism similarly applicable to CPUs: Not only SIMD, but also superscalar multicores -- in a sense the ever-present ILP is dependent on this, too (the design with data dependencies -- including the ones implied by pointer chasing resulting from a "hierarchical objects' tree" design -- may be equally hostile to ILP as it is to vectorization and multicore-parallelism). This usually cannot be added on top (as in the idealistic "optimize later" stage) of a parallelism-unaware design, unless we're okay with "optimize later" meaning a "complete rewrite."True, also implications for modularity and maintainability.One organization vs. another -- different trade-offs: http://gameprogrammingpatterns.com/data ... erestingly, we haven't lost much encapsulation here. Sure, the game loop is updating the components directly instead of going through the game entities, but it was doing that before to ensure they were processed in the right order. Even so, each component itself is still nicely encapsulated. It owns its own data and methods. We simply changed the way it's used.QuoteHardware engineers do not have this problem.It's interesting, because it's the exact same problem as in computer architecture -- people living in "their" separate layers ("algorithms", "ISA", "microarchitecture", "digital logic") -- in the past not communicating with one another, not enough real inter-disciplinarity ("it's okay if I design hardware and I don't understand algorithms, if anything I can always collaborate with CS theoreticians" _and_ "it's okay if I design algorithms and don't understand hardware, if anything I can always collaborate with hardware engineers" both problematic!). Assumptions becoming increasingly outdated with the end of the free lunch (Joy's Law) -- a thread-unaware but highly-optimized (for a single CPU) memory controller may work great for a single-core uniprocessor, but be terrible for a multi-core CPU.QuoteInteresting! Yet this conclusion rests on the assumption that "model of the world" is a noun-focused model (which may be the prevailing thought pattern in Western cultures that the world is composed of distinct and separable objects). But if "model of the world" is a context-based one (which may be the prevailing thought pattern in Eastern cultures) then perhaps the "model of the world" is correct.Interesting, context may be a good thinking tool.At the same time doesn't that exacerbate the "no objective test to evaluate benefits" problem?QuoteI'd also quibble for lie #1 in that many (but not all!) software systems actually are platforms in that they define an instruction set that other programs or the end-user can use in different ways or sequences to accomplish their goals. A "word processor" really is a processor and different "word processors" are akin to different CPUs in how they used.I'd call that a "virtual platform" -- as in, distinct from a "physical platform" :-)One more interesting talk:A system is not a tree - ​​Kevlin Henney:
Both beautiful and useful. But we're not talking about the green, oxygen-providing ones. As abstract structures we see trees all over the place -- file systems, class hierarchies, call trees, ordered data structures, etc. They are neat and tidy, nested and hierarchical -- a simple way of organising things; a simple way of breaking large things down into small things.The problem is, though, that there are many things -- from modest fragments of code up to enterprise-wide IT systems -- that do not fit comfortably into this way of looking at the world and organising it. Software architecture, design patterns, class decomposition, performance, unit tests... all of these cut across the strict hierarchy of trees. This talk will look at what this means for how we think and design systems, whether large or small.

Grammar-Pattern Programmers: Is Over-Abstraction Delivering Projects Faster Or Slower?

Posted: April 13th, 2016, 3:22 pm
by Traden4Alpha
QuoteOriginally posted by: PolterQuoteInteresting! Yet this conclusion rests on the assumption that "model of the world" is a noun-focused model (which may be the prevailing thought pattern in Western cultures that the world is composed of distinct and separable objects). But if "model of the world" is a context-based one (which may be the prevailing thought pattern in Eastern cultures) then perhaps the "model of the world" is correct.Interesting, context may be a good thinking tool.At the same time doesn't that exacerbate the "no objective test to evaluate benefits" problem?Context simply reflects that fact that the behavior (i.e., the code) associated with an object depends on the context. A chair for sitting, a chair used as a weapon in a bar fight, and a chair heaped in a bonfire would all be modeled differently. From the standpoint of programing, "what it does" matters more than "what it is." There is an exception: if the program modeled all objects from lowest level chemistry or physics, then it would reflect the chair's behavior in any context (assuming the physics/chemistry is accurate). But if programmer labor and CPU/RAM are limited, then we must use "what it does" approximations.QuoteQuoteI'd also quibble for lie #1 in that many (but not all!) software systems actually are platforms in that they define an instruction set that other programs or the end-user can use in different ways or sequences to accomplish their goals. A "word processor" really is a processor and different "word processors" are akin to different CPUs in how they used.I'd call that a "virtual platform" -- as in, distinct from a "physical platform" :-)LOL! But all of the common modern day CPUs are software platforms! The machine code is translated into microcode. And even the microcode is at a non-zero level of abstraction in that the bits within the microcode interact with non-trivial subsections of hardware modeled as abstract machine elements (e.g., an ALU).QuoteOne more interesting talk:A system is not a tree - ​​Kevlin Henney:
Both beautiful and useful. But we're not talking about the green, oxygen-providing ones. As abstract structures we see trees all over the place -- file systems, class hierarchies, call trees, ordered data structures, etc. They are neat and tidy, nested and hierarchical -- a simple way of organising things; a simple way of breaking large things down into small things.The problem is, though, that there are many things -- from modest fragments of code up to enterprise-wide IT systems -- that do not fit comfortably into this way of looking at the world and organising it. Software architecture, design patterns, class decomposition, performance, unit tests... all of these cut across the strict hierarchy of trees. This talk will look at what this means for how we think and design systems, whether large or small.I'd assert that it's incorrect to say "we see trees all over the place " and more correct to say "we have created trees all over the place". Those trees say more about human thought patterns than they do about the real world.

Grammar-Pattern Programmers: Is Over-Abstraction Delivering Projects Faster Or Slower?

Posted: April 13th, 2016, 6:12 pm
by Cuchulainn
QuoteOne more interesting talk:A system is not a tree - ​​Kevlin Henney:
Both beautiful and useful. But we're not talking about the green, oxygen-providing ones. As abstract structures we see trees all over the place -- file systems, class hierarchies, call trees, ordered data structures, etc. They are neat and tidy, nested and hierarchical -- a simple way of organising things; a simple way of breaking large things down into small things.The problem is, though, that there are many things -- from modest fragments of code up to enterprise-wide IT systems -- that do not fit comfortably into this way of looking at the world and organising it. Software architecture, design patterns, class decomposition, performance, unit tests... all of these cut across the strict hierarchy of trees. This talk will look at what this means for how we think and design systems, whether large or small. KH is very good in that video. Relaxed speaker. He's on the ball.Michael Jackson "Problem Frames" esp. figure page 21 is it. It resolves the T4A/Polter paradox on virtual machines. It's a non-issue.That's all I have to say. ==I'll have you Know I was certified Michael Jackson JSP COBOL programmer. And it's on its way back.

Grammar-Pattern Programmers: Is Over-Abstraction Delivering Projects Faster Or Slower?

Posted: April 13th, 2016, 6:26 pm
by Cuchulainn
A city is a semi-lattice

Grammar-Pattern Programmers: Is Over-Abstraction Delivering Projects Faster Or Slower?

Posted: April 14th, 2016, 7:11 am
by Cuchulainn
QuoteOver-encapsulation and over-layering create rat-holes filled with bugs and unexpected behavior.In fairness, this is not the fault of layering. The root cause is that developers have not defined the _contracts_ between layers (see Eiffel).Telecom, TCP/IP layered protocols have got their act together in this regard AFAIR.

Grammar-Pattern Programmers: Is Over-Abstraction Delivering Projects Faster Or Slower?

Posted: April 14th, 2016, 10:34 am
by Traden4Alpha
QuoteOriginally posted by: CuchulainnQuoteOver-encapsulation and over-layering create rat-holes filled with bugs and unexpected behavior.In fairness, this is not the fault of layering. The root cause is that developers have not defined the _contracts_ between layers (see Eiffel).Telecom, TCP/IP layered protocols have got their act together in this regard AFAIR.As any lawyer (or Godel) will tell you, the problem with contracts is that they are either inconsistent or incomplete. The lawyers would also cite the related problem of ambiguity -- the language used to write a contract is itself not defined by contract. One could argue that each and every programmer (and user) is using a slightly different version of the interpreter/compiler to reach different conclusions about what the contract means and what the software should do.What makes layered systems potentially fragile is that the user of a high-level layer might easily issue commands that resolve to out-of-bounds or corner-case inputs for the low-level layers. Moreover, the low-level layers might return values or created system states deemed nonsensical by the higher-level user. Layered systems can also have extremely poor runtime performance if the high-level programmer/user does not understand the consequences (i.e., the pattern of lower-level activities) spawned by their commands. I worked on an image processing system which in it's first version spent 30% of the CPU time converting ascii to floating point numbers because the high-level programmers called functions to get stored calibration values which the low-level programs resolved as commands to read and interpret the pre-stored calibration files. And I know of another project that attempted to write an air traffic control system using the full OSI 7-layer stack with the result that the system's response time to real-time commands was on the order of minutes due to all the traversals of the layers. In essence, the layers may have well-defined but incorrect contracts or have well-defined but incorrectly used contracts.Programming in a layered model is like the issue of programming for different architectures -- how you write a program differs for single-core, multi-core, or CUDA hardware. The programmer must understand the platform before they can write good code. Yet a layered system is a platform running on a platform running on a platform running on ......You are right that the whole internet networking stack of layers is relatively well designed (with the exception of the many low-level and high-level security vulnerabilities in these systems) but few systems can afford the millions (hundreds of millions?) of man-hours and decades of debugging that have gone into producing it.

Grammar-Pattern Programmers: Is Over-Abstraction Delivering Projects Faster Or Slower?

Posted: April 14th, 2016, 12:36 pm
by Cuchulainn
How do committees invent? QuoteA contract research organization had eight people who were to produce a COBOL and an ALGOL compiler. After some initial estimates of difficulty and time, five people were assigned to the COBOL job and three to the ALGOL job. The resulting COBOL compiler ran in five phases, the ALG0L compiler ran in three. QuoteOne could argue that each and every programmer (and user) is using a slightly different version of the interpreter/compiler to reach different conclusions about what the contract means and what the software should do.Is this your finding? Don't think medical systems would accept this..It means the final software system fails and you should reduce the team size until quality improves.

Grammar-Pattern Programmers: Is Over-Abstraction Delivering Projects Faster Or Slower?

Posted: April 14th, 2016, 12:48 pm
by Cuchulainn
What is a developer's mental model? For example, the customer has written this specWhat's triggered in Grammar-Pattern Programmer's head? How does it pan out?