Reply to Me,

> Chris R. Miller wrote:
> 
>> Whatever you call it, you can always polish the turd later,
> I'm not normally of a weak disposition, but please don't post video of
> your polishing attempts.
> 
> Unless, by "later", you mean far enough in the future that we're
> talking coprolites :)
> 
> b.
> 

it's (I hope) a figure of speech.

BCS wrote:
> Reply to Me,
> 
>> Chris R. Miller wrote:
>>
>>> Whatever you call it, you can always polish the turd later,
>> I'm not normally of a weak disposition, but please don't post video of your polishing attempts.
>>
>> Unless, by "later", you mean far enough in the future that we're talking coprolites :)
>>
>> b.
>>
> 
> it's (I hope) a figure of speech.

It's a rather rude figure of speech I picked up from my dad.  It's basically a euphemism for continuing to work on a project that already suits your purposes, though especially if it's for the wants of someone else.  For instance, I worked on a poster project for a class once to the point that it was more than good enough for me, but I "polished the turd" some more to meet the teacher's expectations.  It's also used to point some wry doubtfulness to the overall value of the project (hence the turd allusion).

Sorry for the confusion, I forget that this is an international group and not everyone is familiar with all the little idioms in English.

Neal Alexander wrote:
> Chris R. Miller wrote:
>> In the event that you are accusing me of being "personality" of Ty, I rebuke you and must say you have no idea what you are talking about.
>>
>> We are two different people who live on different continents and have different lives.  I resent your implications to the contrary.
>>
> If i were accusing you of being him, why would i ask how *you* could take *him* seriously.

Whoops, sorry.  I misinterpreted you.  No hard feelings I hope.

"Jarrett Billingsley" <kb3ctd2@yahoo.com> wrote in message news:g0uoob$2htb$1@digitalmars.com...
> "Simen Haugen" <simen.haugen@pandavre.com> wrote in message news:g0tttj$8mt$1@digitalmars.com...
>>
>> "Robert Fraser" <fraserofthenight@gmail.com> wrote in message news:g0t0gj$11sh$2@digitalmars.com...
>>> bearophile wrote:
>>>> Python/Ruby and D are in two quite different classes of languages. Usually where you use one of them you don't want to use the other.
>>>
>>> Not necessarily. D is still useful for quick scripting. More to the point, webapps are often written with Ruby/Python/Perl backends which could be swapped out for one written in a native language to help performance.
>>
>> I agree with the scripting. I'm still using quite a lot of python, but
>> when I'm doing small programs I'm often using D to avoid the bloat of
>> py2exe.
>> Too sad I haven't gotten PyD to work with larger classes, and it seems it
>> won't be updated until D2.
>
> If you're referring to the errors you get from the linker about symbol length, there's nothing Kirk can do about it.  It's a major shortcoming of the DMD Windows object format and linker, namely an extremely limited symbol length.  It works fine with all the other compiler combinations (GDCWin, DMDLin, GDCLin).

Yes, that was the think I was thinking of. But with more reflection instead of templates this can be fixed.

Clay Smith wrote:
> Chris R. Miller wrote:
>> A very good friend of mine and an absolutely fantastic programmer once told me some great advice: stop making stupid UML diagrams and write code!
>>
> 
> Sorry, but I have to say that you are not getting great advice. The design stage is the most important stage in the life of a program. Get that wrong and you can write all the code you want, and it will all be wrong.

UML class diagrams and UML sequence diagrams are not design; they are programming. Programming in a language with no compiler, programming without including your core algorithms, programming without any tests. There's no way in hell you can verify your design will be even remotely close to something that can work.

You can safely and usefully design at a higher level before writing any code, but not on the class level.

Reply to Simen,

> Yes, that was the think I was thinking of. But with more reflection
> instead of templates this can be fixed.
> 

If I'm reading you correctly, "this" can't be fixed. The symbol length limit is fixed by the file format and can't be changed. OTOH several ways to sidestep it by reducing symbol lengths have bean proposed but not implemented for various reasons.

Reply to Chris,

> UML class diagrams and UML sequence diagrams are not design; they are
> programming. Programming in a language with no compiler, programming
> without including your core algorithms, programming without any tests.
> There's no way in hell you can verify your design will be even
> remotely close to something that can work.
> 
> You can safely and usefully design at a higher level before writing
> any code, but not on the class level.
> 

I beg to differ. The one and only time I used UML it was very useful. It helped me track a number of aspects of the design and brought to light a number of deficiencies. I'd say UML is a design "tool" but in the way that Word or a pad of paper can be, as an aid to documentation.

"Daniel Giddings" <daniel.giddings@gmail.com> wrote in message news:g0vmk1$1qfk$1@digitalmars.com...
> Clay Smith wrote:
>> Chris R. Miller wrote:
>>> A very good friend of mine and an absolutely fantastic programmer once told me some great advice: stop making stupid UML diagrams and write code!
>>>
>>
>> Sorry, but I have to say that you are not getting great advice. The design stage is the most important stage in the life of a program. Get that wrong and you can write all the code you want, and it will all be wrong.
>

That would certainly be true if you're using the waterfall method.

> Your first design will either be wrong or take forever! (at least a lot longer than it need as you make decisions based on lack of experience with the problem)
>
> Better to start with a minimal design and then prototype and iterate. Set up your development process to deal with design changes and code refactoring.

That's been exactly my experience.

No matter what strategy you use, your first approach (or two, or three) is going to be wrong, period, regardless of how much thought you put into it. It's just a fact of programmer life. So you can either waste your time pretending you have a shot in hell of getting it right the first time, or you can play around with a compiler *while* you're brainstorming to get hard instant feedback instead of operating on speculation. A compiler should be one of your design-time tools.

Forcing a long code-less "design" stage is like agonizing over your code before compiling to make sure there's no syntax errors. Just compile the damn thing. It'll tell you if it's wrong (provided the language doesn't suck, but that's a different discussion ;) ).

That said, there are times when it can be good to sit back, think, and not touch the editor. But the real test to see how much "think/paper-n-pencil/UML" you should be doing, versus "implement/prototype/iterate" is "How much work will this take to try out?" The more work it takes to actually try out an idea, the more upfront thought you should put into it. But more often than not, anything you can play around with in UML structure diagrams is also going to be very easy and productive to play around with in actual code, even if you have to use a lot of stubs for "to-be-implemented" functionality.

Reply to Nick,

> 
> No matter what strategy you use, your first approach (or two, or
> three) is going to be wrong, period, regardless of how much thought
> you put into it. It's just a fact of programmer life. So you can
> either waste your time pretending you have a shot in hell of getting
> it right the first time, or you can play around with a compiler
> *while* you're brainstorming to get hard instant feedback instead of
> operating on speculation. A compiler should be one of your design-time
> tools.
> 

I'd love to see a compiler that can pick out the kind of issues I worry about. (Logic errors etc.)

> Forcing a long code-less "design" stage is like agonizing over your
> code before compiling to make sure there's no syntax errors.
> 
> But the real test [...] is "How much work will this take to try
> out?" The more work it takes to actually try out an idea, the more
> upfront thought you should put into it.

The prime issue of that is that people don't like throwing stuff out. If the developer is very willing to hit delete and go for a total re wright the above becomes much more viable. But if they are very willing to munge what they have into what they need you can start running into issues: "this is the design we have, so lest work with it"

That all said, a lot of the coolest stuff I've done couldn't be designed on a blackboard because it's been related to exploring the corners of the compiler.

BCS wrote:
> Reply to Chris,
> 
>> UML class diagrams and UML sequence diagrams are not design; they are
>> programming. Programming in a language with no compiler, programming
>> without including your core algorithms, programming without any tests.
>> There's no way in hell you can verify your design will be even
>> remotely close to something that can work.
>>
>> You can safely and usefully design at a higher level before writing
>> any code, but not on the class level.
>>
> 
> I beg to differ. The one and only time I used UML it was very useful. It helped me track a number of aspects of the design and brought to light a number of deficiencies. I'd say UML is a design "tool" but in the way that Word or a pad of paper can be, as an aid to documentation.

You were using UML class diagrams. Were you generating code from UML, or UML from code?

If you want to use UML to document existing code, that has always sounded like a good idea to me. You don't have to wade through code and comments to get an idea of what's going on. But in this case, you MUST use UML that's autogenerated from your code. Otherwise, your UML documentation will branch away from your code.