Pattern Based Design

[Jonny via Digitalmars-d]

On Tuesday, 17 November 2015 at 23:41:21 UTC, Idan Arye wrote:
> On Tuesday, 17 November 2015 at 19:05:30 UTC, Jonny wrote:
>> Being able to factor a project into well understood patterns 
>> that are loosely bound yet cohesive is fundamental for a 
>> successful project.
>>
>> Does D have an ability to template patterns(or even better 
>> yet, a uml like interface that can emit D code) effectively? 
>> i.e., saves much more time than doing it by hand?
>>
>> As I become more knowledgeable about the fundamental 
>> programming concepts I realize that modern programming hasn't 
>> yet brought design to the forefront of programming, where it 
>> naturally should be.
>>
>> UML is a start, obviously and there are many reincarnations 
>> and variations on the theme. But I imagine that a fully 
>> integrated design interface is the way to go.
>>
>> Something that allows you to work in design mode when you are 
>> designing and work in implementation mode when you are 
>> implementing... keeping the two distinct is what prevents the 
>> chaos that tends to happen as a project grows.
>>
>> Proper design is the key to success, is it not? If so, then 
>> wouldn't it be wise for D to be more than just a "compiler"?
>>
>> Code folding is a cheesy attempt to reduce implementation 
>> details. Code should be more than just a text file of the 
>> implementation, but should also include details the design of 
>> the program(what it should do, the patterns involved, how the 
>> patterns are fitting together, etc).
>>
>> About the closest I have seen to the concept I am interested 
>> in is the UML applications like Visual Paradigm which attempt 
>> to make design the utmost importance. Because these apps are 
>> not integrated with the compiler, the compiler cannot take 
>> advantage of design details for optimization. Neither can it 
>> properly refactor the implementation details when the design 
>> changes.
>
> Code generation from UML is bullshit. The point of design is to 
> work at a higher levels of abstraction than your code - levels 
> behind what can be automatically compiled to executable code. 
> By working at such high levels, you can skip many 
> implementation details that can be filled later by the human 
> programmers, which allows you to easily apply design 
> changes(before you write the actual code) and which provides 
> you with better overview of the whole project or specific 
> modules, functionalities and flows.
>
> If you want to generate actual code from the design, you must 
> limit the abstraction level of the design to one that can be 
> automatically compiled to executable code - a limitation that 
> robs you of the benefits mentioned above and essentially makes 
> the format of your design a graphic programming languages. Such 
> languages have been created before, and never got traction - 
> and for a good reason! Over the years, programmers have 
> developed a large array of tools for working with textual 
> line-oriented source code files - SCMs, sophisticated text 
> editors, search tools, text manipulation tools and more. Many 
> language-agnostic tools that can work on any source files 
> provided that they are composed of textual lines of code. 
> Graphical languages don't satisfy that condition - so you can't 
> use these tools with them.

I think there is a misunderstanding.

I am mainly talking about the organizational aspects of higher 
level of abstraction rather than code generation.

Basically dealing with "files" is so old school. They reduce 
coherence of the abstraction. Modules help but still are file 
based.

I'd rather have a list of functions, a hierarchical view of class 
relationships(the uml like design).

I'd like to see the project on a higher level of abstraction 
instead of the very concrete "files" approach that hasn't changed 
since punch cards.