• Jonny (30/30) Nov 17 2015 Being able to factor a project into well understood patterns that
• Idan Arye (22/53) Nov 17 2015 Code generation from UML is bullshit. The point of design is to
• Jonny (12/74) Nov 17 2015 I think there is a misunderstanding.
• Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= (12/22) Nov 18 2015 Yes, I agree with you. I've felt the same way for a long time.
• Chris (10/32) Nov 20 2015 Defining interfaces gets you only so far. As a program grows, you
• Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= (9/17) Nov 21 2015 That is usually true, but that means that the desire to mutate

Jonny <Jonny nomail.com> writes:

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.

Idan Arye <GenericNPC gmail.com> writes:

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.

Jonny <Jonny nomail.com> writes:

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.

Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:

On Wednesday, 18 November 2015 at 02:41:33 UTC, Jonny wrote:
 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.

Yes, I agree with you. I've felt the same way for a long time. 
Unfortunately it is very hard and expensive to build such tools. 
They exist and are in use, but in very specific domains.

One of the key problem with the concept is that programmers often 
edit and mutate their programs with many unfinished pieces laying 
around before they compile. If they started by defining 
interfaces then it would be a lot easier to make a good tool.

But if you look at reactive/dataflow programming you'll find 
advanced tools that have been in production use: animation, 
audio/dsp, control systems for critical systems etc.

http://blog.interfacevision.com/design/design-visual-progarmming-languages-snapshots/

Chris <wendlec tcd.ie> writes:

On Wednesday, 18 November 2015 at 13:12:16 UTC, Ola Fosheim 
Grøstad wrote:
 On Wednesday, 18 November 2015 at 02:41:33 UTC, Jonny wrote:
 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.

 Yes, I agree with you. I've felt the same way for a long time. 
 Unfortunately it is very hard and expensive to build such 
 tools. They exist and are in use, but in very specific domains.

 One of the key problem with the concept is that programmers 
 often edit and mutate their programs with many unfinished 
 pieces laying around before they compile. If they started by 
 defining interfaces then it would be a lot easier to make a 
 good tool.

Defining interfaces gets you only so far. As a program grows, you 
have to change many things and redefine the interface later. What 
looks like a good plan/interface when you set out, invariably 
will have to be revised and changed later. This is the reality of 
programming. No matter what they tell you about planning your 
program beforehand, it changes later anyway, sometimes even 
drastically. If anyone has the perfect plan, please let me know.

[snip]

Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:

On Friday, 20 November 2015 at 15:11:58 UTC, Chris wrote:
 Defining interfaces gets you only so far. As a program grows, 
 you have to change many things and redefine the interface 
 later. What looks like a good plan/interface when you set out, 
 invariably will have to be revised and changed later. This is 
 the reality of programming. No matter what they tell you about 
 planning your program beforehand, it changes later anyway, 
 sometimes even drastically. If anyone has the perfect plan, 
 please let me know.

That is usually true, but that means that the desire to mutate 
the codebase is a challenge when moving away form textual 
representation. So creating more structured tools is quite 
demanding. That was my point.

For dataflow I think it often is just as easy to do it visually, 
but therein is the key issue you need a variety of 
representations depending on how you mutate your code, whereas 
with plain text you can do with just one representation.