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.
