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.
