On Thursday, 1 November 2018 at 22:37:59 UTC, unprotected-entity
wrote:
On Thursday, 1 November 2018 at 03:10:22 UTC, H. S. Teoh wrote:
Actually, code within a module *should* be tightly coupled and
cohesive -- that's the whole reason to put that code inside a
single module in the first place. If two pieces of code
inside a module are only weakly coupled or completely
decoupled, that's a sign that they should not be in the same
module at all. Or at the very least, they should belong in
separate submodules that are isolated from each other.
How does one determine, whether a 10,000 line module, is
tightly coupled and cohesive?
You take a look through it and make a judgement.
Only the author can make that statement - which they naturally
will, even if it's not true.
?
An outsider, seeking to verify that statement, has a hell of a
job on their hands...(I for one, think code smell immediately).
There is a basic question in life. Do you believe in discernment
(if possible informed by data) or are you someone who makes
decisions on the basis of evidence and believes that anything
else is completely arbitrary and nothing more than a matter of
opinion.
My impression is that the values of the D community tend more in
the direction of recognising the importance of discernment. If
someone is somebody who believes more in 'evidence', policy and
rules then it probably isn't going to be satisfying expecting
one's values to be shared on a wide scale here.
People also differ in their working memory and the degree to
which they naturally think associatively. Chopping up everything
into small pieces favours those who have a smaller working memory
and who think more analytically but it's a disadvantage for those
who have a large working memory and think associatively. For a
private project that's something to be resolved between the
relevant people, but I don't think it's reasonable to say that
large files per se are wrong, just because they aren't your cup
of tea personally.
I think that lots of things seem clear in theory but the
difference between theory and practice is often quite large.
In practice Phobos is very readable.
And on the other hand, I have seen an experienced and capable C#
programmer struggle to understand an intranet site written in the
approved way by an experienced person who was well-trained at
Microsoft. I couldn't understand it either so I concatenated all
the little itty bitty files, pulled out the data structures and
then it was easy.
I don't use a particular language. I'm more interested in
design and architecture.
Can one really speak of that kind of design in the abstract ?
Language features shape your choices and lead to large shifts in
the optimum. If you don't have design by introspection as a
possibility you are going to pick something else.
In the age of 'lock-down-everything', increased modularity is
becoming more important. A monolithic module approach, is
already outdated, and risky, in terms of developing secure,
maintainable software....
If you can't understand the program does that make you more or
less secure? Security requires also to understand the behaviour
of the system as a coherent whole. I think D programs are pretty
easy from that perspective.
Is that really such a bad idea? Are there no programmers out
there in the D world that might think this could be a good,
additional tool, to give programmers, so they can better
architect their solution?
Burden of proof is on you to write a DIP and make an argument for
it. I am not sure you would find it easier to get a change into
C++. Look at how difficult it is for Walter sometimes ; and he
has just a little earned credibility. Same thing for Guido - he
had such little fun with a recent PEP he decided to retire from
BDFL of python.
The amount of push back in the D community on this idea, is
really odd to me. I'm still trying to understand why that is.
Persuading people isn't easy even if it's a good idea. Look at
the pushback from C++ over static if. They crippled it when they
finally did relent. It's a bit entitled to think that if you
can't persuade people without having written a DIP that it's them
not you!
Are D programmers just hackers, insterested in getting their
code to work, no matter what? Are their not enough Java/C#
programmers coming to D - and bringing their design skills with
them?
Would you mind explaining why you think that people from mass
communities have design skills by virtue of having come from a
mass community? Walter and Andrei are just a little bit known
for their design capabilities so the bar is quite high. I think
it's possible you might have things topsy turvy.
Making D code work is rarely a problem.
Every nation has its own strengths and weaknesses and the same is
true of language communities.
Having worked with D professionally since 2015 and with a decent
size codebase in relation to what I have heard from others, my
experience of working with D programmers is that I have never had
to say please don't make this dirty hack. Whereas you know you
could copy memory just this once, please don't bother making this
bit fast, I really think we can just make a start on a prototype
before doing a full design, do we really need to refactor this
part of the code now - those things whilst not common are more
frequent sources of disagreement with D programmers.
So like I say I think you have it upside down. The D programmers
I work with have a strong focus on design and doing things in the
right way. Take a look at Atila Neves work on excel-d or dpp.
It's a model of clean code. There are some outstanding Java and
C# programmers but they are much sparser than in the D community.
I spoke to the then CTO of the company where I am now involved.
I was telling him about my project and he said ooh you want to
spend a couple of weeks mapping out your class hierarchy. I said
I don't have any classes. Well I did have two, but I took out
one and John Colvin got rid of the other. The expression on his
face was priceless.
You can write D like Java or C# if you like. Depends what you
are doing - you certainly don't need to, and many people who have
been using D for a while often find writing code using structs
much better for their goals and given their values.
When one encounters a new idea that's unfamiliar sometimes it's
easy to think that because it's unfamiliar it must be unsound.
That can be a mistake. It might be better to suspend judgement
for a while and keep an open mind.
