Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #138589 > unrolled thread

Methodologies for C programming

Back to article view | Back to comp.lang.c

Contents

  Methodologies for C programming Thiago Adams <thiago.adams@gmail.com> - 2018-12-07 05:15 -0800
    Re: Methodologies for C programming Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2018-12-07 05:38 -0800
      Re: Methodologies for C programming Thiago Adams <thiago.adams@gmail.com> - 2018-12-07 07:57 -0800
        Re: Methodologies for C programming David Brown <david.brown@hesbynett.no> - 2018-12-07 18:05 +0100
    Re: Methodologies for C programming Thiago Adams <thiago.adams@gmail.com> - 2018-12-07 08:08 -0800
    Re: Methodologies for C programming William Ahern <william@25thandClement.com> - 2018-12-07 10:08 -0800
      Re: Methodologies for C programming Thiago Adams <thiago.adams@gmail.com> - 2018-12-07 10:23 -0800
    Re: Methodologies for C programming Wouter Verhelst <w@uter.be> - 2018-12-07 22:04 +0100
    Re: Methodologies for C programming Ian Collins <ian-news@hotmail.com> - 2018-12-08 10:46 +1300
      Re: Methodologies for C programming Thiago Adams <thiago.adams@gmail.com> - 2018-12-08 02:27 -0800
        Re: Methodologies for C programming Thiago Adams <thiago.adams@gmail.com> - 2018-12-08 10:35 -0800
          Re: Methodologies for C programming Jorgen Grahn <grahn+nntp@snipabacken.se> - 2018-12-09 08:22 +0000
    Re: Methodologies for C programming fir <profesor.fir@gmail.com> - 2018-12-09 14:40 -0800
    Re: Methodologies for C programming "Pascal J. Bourguignon" <pjb@informatimago.com> - 2018-12-27 13:17 +0100
      Re: Methodologies for C programming "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-12-27 08:12 -0500
      Re: Methodologies for C programming Thiago Adams <thiago.adams@gmail.com> - 2018-12-27 07:54 -0800
        Re: Methodologies for C programming Richard Damon <Richard@Damon-Family.org> - 2018-12-27 11:32 -0500
        Re: Methodologies for C programming fir <profesor.fir@gmail.com> - 2018-12-27 09:22 -0800
    Re: Methodologies for C programming jacobnavia <jacob@jacob.remcomp.fr> - 2018-12-27 19:54 +0100
      Re: Methodologies for C programming Richard Damon <Richard@Damon-Family.org> - 2018-12-27 17:54 -0500
        Re: Methodologies for C programming fir <profesor.fir@gmail.com> - 2018-12-27 16:24 -0800
          Re: Methodologies for C programming Chad <cdalten@gmail.com> - 2018-12-27 17:57 -0800
          Re: Methodologies for C programming Chad <cdalten@gmail.com> - 2018-12-27 17:58 -0800
            Re: Methodologies for C programming rbowman <bowman@montana.com> - 2018-12-27 21:34 -0700
              Re: Methodologies for C programming Keith Thompson <kst-u@mib.org> - 2018-12-27 21:27 -0800
                Re: Methodologies for C programming rbowman <bowman@montana.com> - 2018-12-28 08:30 -0700
                  Re: Methodologies for C programming Keith Thompson <kst-u@mib.org> - 2018-12-28 12:15 -0800
                    Re: Methodologies for C programming rbowman <bowman@montana.com> - 2018-12-28 20:42 -0700
                      Re: Methodologies for C programming Tim Rentsch <txr@alumni.caltech.edu> - 2018-12-29 09:26 -0800
                        Re: Methodologies for C programming rbowman <bowman@montana.com> - 2018-12-29 13:50 -0700
    Re: Methodologies for C programming luser droog <luser.droog@gmail.com> - 2018-12-30 12:39 -0800
      Re: Methodologies for C programming fir <profesor.fir@gmail.com> - 2018-12-30 14:00 -0800
        Re: Methodologies for C programming fir <profesor.fir@gmail.com> - 2018-12-30 14:18 -0800
      Re: Methodologies for C programming rbowman <bowman@montana.com> - 2018-12-30 16:48 -0700
        Re: Methodologies for C programming luser droog <luser.droog@gmail.com> - 2018-12-31 00:06 -0800
          Re: Methodologies for C programming fir <profesor.fir@gmail.com> - 2018-12-31 02:34 -0800
          Re: Methodologies for C programming Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2018-12-31 05:13 -0800
          Re: Methodologies for C programming rbowman <bowman@montana.com> - 2018-12-31 12:44 -0700
        Re: Methodologies for C programming Tim Rentsch <txr@alumni.caltech.edu> - 2019-01-01 16:01 -0800
        Re: Methodologies for C programming Tim Rentsch <txr@alumni.caltech.edu> - 2019-01-01 16:23 -0800
      Re: Methodologies for C programming Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2018-12-31 05:08 -0800
        Re: Methodologies for C programming Ike Naar <ike@iceland.freeshell.org> - 2018-12-31 17:32 +0000
          Re: Methodologies for C programming Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2018-12-31 14:13 -0800
    Re: Methodologies for C programming Thiago Adams <thiago.adams@gmail.com> - 2019-01-02 02:48 -0800

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

#139147

W dniu czwartek, 27 grudnia 2018 23:54:43 UTC+1 użytkownik Richard Damon napisał:
> On 12/27/18 1:54 PM, jacobnavia wrote:
> > Le 07/12/2018 à 14:15, Thiago Adams a écrit :
> >> In C we need to build your own data types. Comparing with C++
> >> for instance, we have parametrized data types like vector and map
> >> and other read-to-use types like string.
> >>
> >> Therefore, to avoid doing everything again and again we need to
> >> think in modularization and reuse. Using C++ someone else is in
> >> charge for testing the STL containers. Doing you own data types
> >> we need to make sure everything is working and unit tests also
> >> become very important.
> > 
> > To avoid that, I designed and developed a prototype STL for C, offering
> > very similar capabilities and faster performance.
> > 
> > The C standards committee rejected the proposal saying that C++ has done
> > that already, and any development of an STL in C is out of the question.
> > 
> > I have tried to promote the library in this group (used mainly by C++
> > people)  to no avail.
> > 
> > What is the CCL?
> > 
> > It provides
> > o Hash tables
> > o Flxible vectors
> > o Trees
> > o String vectors
> > o lists (single/double linked)
> > 
> > Parametized types are provides through macros.
> > Allocation can be replace by your own allocator.
> > 
> > It provides also iterators, you can be notified of changes in anyy
> > container, provides read only containers, and a LONG "etc"
> > 
> > But it has an enormous drawback:
> > 
> > It is written in standard C (1999), and as everyone in this group has
> > told me, C is a dead language, goto C++
> > 
> 
> Jacob, I have looked at and tried to use your library, but it comes off
> feeling like C++ code that has been ported to C, not as C code, which I
> think is part of the issue that the Standards Committee saw. If
> anything, I think you set your sites on implementing too much of the
> STL, and ended up with something that just doesn't feel like C.
> 
> In an application that I would be tempted to use it, I would with just a
> bit of push go all the way to implementing in C++.

library is a library, so what is someone wrote some library? its ok.. but expectation that c std comitee will treat is as a part of c is 'misguided' (weak english maybe i could put better word)
asam is on expectation that people will just use it right on the fly

as to c comitee btw i wonder if it wouldnt be better if comitee would not exist at all and ritchie and thompson
would handle it alone (like some present
projects in programing world are handled
by its authors not comitee) but maybe that was then the case a bit like javascript maybe where maybe few big companies was involved and comitee was needed to stop the wars if each of company would like to enforce its shape of language and you need to 'bribe' (or pacify) them by granting them place in
a comitee ... if no i think that if thompson and ritche could handle/guide c
it would be better (i know this view
on things feels sad, but my faith in comitee is weak ;c thay may have some 
important 'political' power (and its 
good (it could be good) if used good to promote good changes and stop bad) but their intellectual influence dont seem to big ;c and more bad than good, well.. )

[toc] | [prev] | [next] | [standalone]

#139148

I purposely submit obfuscated code to QA in order to haze the new hire(s).

[toc] | [prev] | [next] | [standalone]

#139149

And I mean things that go above stuff like

#define true false

[toc] | [prev] | [next] | [standalone]

#139158

On 12/27/2018 06:58 PM, Chad wrote:
> And I mean things that go above stuff like
>
> #define true false
>

One of our stars had

int bool;

I'm not sure how he got it to compile.

[toc] | [prev] | [next] | [standalone]

#139160

rbowman <bowman@montana.com> writes:
[...]
> One of our stars had
>
> int bool;
>
> I'm not sure how he got it to compile.

`bool` is not a keyword in C.  It's defined as a macro (expanding to
`_Bool`) only if you have `#include <stdbool.h>`.

-- 
Keith Thompson (The_Other_Keith) kst@mib.org  <http://www.ghoti.net/~kst>
Will write code for food.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#139168

On 12/27/2018 10:27 PM, Keith Thompson wrote:
> rbowman <bowman@montana.com> writes:
> [...]
>> One of our stars had
>>
>> int bool;
>>
>> I'm not sure how he got it to compile.
>
> `bool` is not a keyword in C.  It's defined as a macro (expanding to
> `_Bool`) only if you have `#include <stdbool.h>`.
>

It's not a keyword in C but when you're doing cross platform development 
and using a variety of compilers including various vintages of Visual 
Studio offerings it's not a great choice for a variable name.

[toc] | [prev] | [next] | [standalone]

#139187

rbowman <bowman@montana.com> writes:
> On 12/27/2018 10:27 PM, Keith Thompson wrote:
>> rbowman <bowman@montana.com> writes:
>> [...]
>>> One of our stars had
>>>
>>> int bool;
>>>
>>> I'm not sure how he got it to compile.
>>
>> `bool` is not a keyword in C.  It's defined as a macro (expanding to
>> `_Bool`) only if you have `#include <stdbool.h>`.
>
> It's not a keyword in C but when you're doing cross platform development 
> and using a variety of compilers including various vintages of Visual 
> Studio offerings it's not a great choice for a variable name.

`bool` is a keyword in C++, and if you want to be able to compile
your C code with a C++ compiler, you obviously can't use `bool`
(or `class`, or `public`, or ...) as an identifier.  But there's
rarely a real need to write C++-compatible C code.  No C compiler
should complain about `int bool;`.  And I'm fairly sure all versions
of Visual Studio include a C compiler.

On the other hand, `bool` is almost certainly a lousy name for
a variable.

Unless the purpose of the declaration was to ensure that the code
wasn't being compiled with a C++ compiler (though I'd use `int
class;` for that).

-- 
Keith Thompson (The_Other_Keith) kst@mib.org  <http://www.ghoti.net/~kst>
Will write code for food.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#139197

On 12/28/2018 01:15 PM, Keith Thompson wrote:
> `bool` is a keyword in C++, and if you want to be able to compile
> your C code with a C++ compiler, you obviously can't use `bool`
> (or `class`, or `public`, or ...) as an identifier.  But there's
> rarely a real need to write C++-compatible C code.  No C compiler
> should complain about `int bool;`.  And I'm fairly sure all versions
> of Visual Studio include a C compiler.

I'll have to experiment. It's all 'cl', with the compiler deciding on 
the filename extension unless you use /Tc to treat everything as a C 
file. To quote from the horse's mouth:

"The Visual C++ C compiler is compatible with the ISO C99 standard, but 
not strictly compliant. In most cases, portable C code will compile and 
run as expected. Visual C++ doesn't support most of the changes in ISO 
C11. Certain library functions and POSIX function names are deprecated 
by the Visual C++ compiler. The functions are supported, but the 
preferred names have changed."

It's left to the user to find the non-compliant parts. For various 
painful reasons most of our programmers build with the cl from VS 6.0 
which mostly supports C89. I use the 2005 cl which has some C99 
features. For example it whines about the implicit int. I think that's 
the one that also gets confused about bool. afaik, no version has gotten 
around to _Bool yet.

We still have some K&R style function definitions lurking in the dark 
corners that will probably bite us some day. At least C never went off 
the rails like Python 3 and it still works with a wide variety of tools 
if you are conservative and don't adopt the latest greatest feature.

[toc] | [prev] | [next] | [standalone]

#139213

rbowman <bowman@montana.com> writes:

[...]

> We still have some K&R style function definitions lurking in the
> dark corners that will probably bite us some day.  At least C
> never went off the rails like Python 3 and it still works with a
> wide variety of tools [...]

It's amazing how many people don't really appreciate the value of
this property.

[toc] | [prev] | [next] | [standalone]

#139215

On 12/29/2018 10:26 AM, Tim Rentsch wrote:
> rbowman <bowman@montana.com> writes:
>
> [...]
>
>> We still have some K&R style function definitions lurking in the
>> dark corners that will probably bite us some day.  At least C
>> never went off the rails like Python 3 and it still works with a
>> wide variety of tools [...]
>
> It's amazing how many people don't really appreciate the value of
> this property.
>

I certainly appreciate it every day. My first exposure was Zolman's BDS 
C subset compiler on CP/M c. 1980. It still works as I expect it to.

On the flip side I do quite a bit of GIS work and ESRI is the big dog in 
that area. After a few false starts they adopted Python for their 
scripting language -- Python 2.6 and then Python 2.7.  That's still the 
case for the traditional ArcDesktop users.

However they are now pushing ArcGIS Pro, which uses Python 3.6. There 
are other changes but there are many disgruntled users with well 
established workflows that aren't ready to move forward.

otoh, when they started to prefer C# over C++ for their ArcObjects 
programming I just shrugged and moved on. If anything C# is more peasant 
than the C++/COM hoops. It still mostly works like C.

I wonder how many slick new languages will have that staying power?

[toc] | [prev] | [next] | [standalone]

#139253

On Friday, December 7, 2018 at 7:16:17 AM UTC-6, Thiago Adams wrote:
> Recently I became more interested in unity tests 
> and modularization.  I can say that the C language is partially 
> responsible for that.
> 
> When we think in unit test, we also think in TDD, although 
> I think TDD does not exactly reflects the methodology I want 
> to use.
> 
> The reason why C is the root of the interest is that when we 
> start using C we need to build a lot infrastructure to program.
> 
> In C we need to build your own data types. Comparing with C++ 
> for instance, we have parametrized data types like vector and map 
> and other read-to-use types like string.
> 
> Therefore, to avoid doing everything again and again we need to 
> think in modularization and reuse. Using C++ someone else is in 
> charge for testing the STL containers. Doing you own data types 
> we need to make sure everything is working and unit tests also 
> become very important.
> 
> With methodologies do you use? 
> What do you think about TDD? 
> How to you reuse code?

I have recently been turned on to an alternate methodology. I began
from roughly the same position you appear to be in: constructing
separate modules around the data structures in a bottom up fashion.

The alternative is "top down design". This way you write the main()
function first and make function calls for each separate thing that
needs to be done. Then you write each of those functions in turn,
calling subfunctions for each separate thing that it needs to do.
And iterate out from there, filling in the details of each subfunction.

The process is similar to what you might achieve by writing a big
pseudo-code comment for the function and then writing code line-by-
line that implements the description from the comment. But, a 
strong advantage is that the result is already nicely factored.
You don't end up with long "story" functions that read like spaghetti
assembly from the 60s. 

The mantra is "function calls are cheap". If they're not cheap, then
turn up the compiler optimization level.

I'm still getting the hang of this methodology and struggling somewhat
to put it in to practice (for various personal reasons which are
unrelated to the technique itself). But it's sound. It's supported
by many of the CS gurus, especially Dijkstra. For more detaills, I
recommend his chapter in Dahl, Dijkstra, Hoare, "Structured Programming".

[toc] | [prev] | [next] | [standalone]

#139261

W dniu niedziela, 30 grudnia 2018 21:40:06 UTC+1 użytkownik luser droog napisał:
> On Friday, December 7, 2018 at 7:16:17 AM UTC-6, Thiago Adams wrote:
> > Recently I became more interested in unity tests 
> > and modularization.  I can say that the C language is partially 
> > responsible for that.
> > 
> > When we think in unit test, we also think in TDD, although 
> > I think TDD does not exactly reflects the methodology I want 
> > to use.
> > 
> > The reason why C is the root of the interest is that when we 
> > start using C we need to build a lot infrastructure to program.
> > 
> > In C we need to build your own data types. Comparing with C++ 
> > for instance, we have parametrized data types like vector and map 
> > and other read-to-use types like string.
> > 
> > Therefore, to avoid doing everything again and again we need to 
> > think in modularization and reuse. Using C++ someone else is in 
> > charge for testing the STL containers. Doing you own data types 
> > we need to make sure everything is working and unit tests also 
> > become very important.
> > 
> > With methodologies do you use? 
> > What do you think about TDD? 
> > How to you reuse code?
> 
> I have recently been turned on to an alternate methodology. I began
> from roughly the same position you appear to be in: constructing
> separate modules around the data structures in a bottom up fashion.
> 
> The alternative is "top down design". This way you write the main()
> function first and make function calls for each separate thing that
> needs to be done. Then you write each of those functions in turn,
> calling subfunctions for each separate thing that it needs to do.
> And iterate out from there, filling in the details of each subfunction.
> 
> The process is similar to what you might achieve by writing a big
> pseudo-code comment for the function and then writing code line-by-
> line that implements the description from the comment. But, a 
> strong advantage is that the result is already nicely factored.
> You don't end up with long "story" functions that read like spaghetti
> assembly from the 60s. 
> 
> The mantra is "function calls are cheap". If they're not cheap, then
> turn up the compiler optimization level.
> 
> I'm still getting the hang of this methodology and struggling somewhat
> to put it in to practice (for various personal reasons which are
> unrelated to the technique itself). But it's sound. It's supported
> by many of the CS gurus, especially Dijkstra. For more detaills, I
> recommend his chapter in Dahl, Dijkstra, Hoare, "Structured Programming".

lul, i doubt if there really exist something as top own methodology

it is becouse writing this way you coulnt test the program when writing it, and thats kinda nonsense

[toc] | [prev] | [next] | [standalone]

#139265

W dniu niedziela, 30 grudnia 2018 23:00:29 UTC+1 użytkownik fir napisał:
> W dniu niedziela, 30 grudnia 2018 21:40:06 UTC+1 użytkownik luser droog napisał:
> > On Friday, December 7, 2018 at 7:16:17 AM UTC-6, Thiago Adams wrote:
> > > Recently I became more interested in unity tests 
> > > and modularization.  I can say that the C language is partially 
> > > responsible for that.
> > > 
> > > When we think in unit test, we also think in TDD, although 
> > > I think TDD does not exactly reflects the methodology I want 
> > > to use.
> > > 
> > > The reason why C is the root of the interest is that when we 
> > > start using C we need to build a lot infrastructure to program.
> > > 
> > > In C we need to build your own data types. Comparing with C++ 
> > > for instance, we have parametrized data types like vector and map 
> > > and other read-to-use types like string.
> > > 
> > > Therefore, to avoid doing everything again and again we need to 
> > > think in modularization and reuse. Using C++ someone else is in 
> > > charge for testing the STL containers. Doing you own data types 
> > > we need to make sure everything is working and unit tests also 
> > > become very important.
> > > 
> > > With methodologies do you use? 
> > > What do you think about TDD? 
> > > How to you reuse code?
> > 
> > I have recently been turned on to an alternate methodology. I began
> > from roughly the same position you appear to be in: constructing
> > separate modules around the data structures in a bottom up fashion.
> > 
> > The alternative is "top down design". This way you write the main()
> > function first and make function calls for each separate thing that
> > needs to be done. Then you write each of those functions in turn,
> > calling subfunctions for each separate thing that it needs to do.
> > And iterate out from there, filling in the details of each subfunction.
> > 
> > The process is similar to what you might achieve by writing a big
> > pseudo-code comment for the function and then writing code line-by-
> > line that implements the description from the comment. But, a 
> > strong advantage is that the result is already nicely factored.
> > You don't end up with long "story" functions that read like spaghetti
> > assembly from the 60s. 
> > 
> > The mantra is "function calls are cheap". If they're not cheap, then
> > turn up the compiler optimization level.
> > 
> > I'm still getting the hang of this methodology and struggling somewhat
> > to put it in to practice (for various personal reasons which are
> > unrelated to the technique itself). But it's sound. It's supported
> > by many of the CS gurus, especially Dijkstra. For more detaills, I
> > recommend his chapter in Dahl, Dijkstra, Hoare, "Structured Programming".
> 
> lul, i doubt if there really exist something as top own methodology
> 
> it is becouse writing this way you coulnt test the program when writing it, and thats kinda nonsense

yet more precise to say would be probably to say that usually programs as far as i know (in that case all of my programs) are created like not top-own, bottom-up in fact but 'evolutionary' 

it is you start like with very small simple 'tree' and add branches to it, anoher one another one another one

in that case both thse botom-up or top-down views are rather false as it is growing more like on sides ;c

[toc] | [prev] | [next] | [standalone]

#139270

On 12/30/2018 01:39 PM, luser droog wrote:
> I'm still getting the hang of this methodology and struggling somewhat
> to put it in to practice (for various personal reasons which are
> unrelated to the technique itself). But it's sound. It's supported
> by many of the CS gurus, especially Dijkstra. For more detaills, I
> recommend his chapter in Dahl, Dijkstra, Hoare, "Structured Programming".
>

It's more often used to refer to finding your way through a thicket of 
intertwined classes in OOP but I remember someone referring to 'yo-yo 
programming'. You do a little top down until you get bored, then a 
little bottom up, and hopefully they meet in the middle.

There is a danger to the methodology in large projects. The overall 
structure is determined after months of endless meetings, equipped with 
flow charts, UML diagrams, and so forth before a line of code is written.

Finally coding starts and everyone soon realizes it's a hot mess. 
However there is so much ego involvement in the design process that it 
can't be abandoned so you slap on bandaids and tourniquets and hope for 
the best.

https://en.wikipedia.org/wiki/Tony_Hoare

There is a nice quote from Tony Hoare on that page. Methodologies have
come and gone over the years but seldom have achieved the desired results.

https://en.wikipedia.org/wiki/Software_development_process

[toc] | [prev] | [next] | [standalone]

#139277

On Sunday, December 30, 2018 at 5:47:29 PM UTC-6, rbowman wrote:
> On 12/30/2018 01:39 PM, luser droog wrote:
> > I'm still getting the hang of this methodology and struggling somewhat
> > to put it in to practice (for various personal reasons which are
> > unrelated to the technique itself). But it's sound. It's supported
> > by many of the CS gurus, especially Dijkstra. For more detaills, I
> > recommend his chapter in Dahl, Dijkstra, Hoare, "Structured Programming".
> >
> 
> It's more often used to refer to finding your way through a thicket of 
> intertwined classes in OOP but I remember someone referring to 'yo-yo 
> programming'. You do a little top down until you get bored, then a 
> little bottom up, and hopefully they meet in the middle.
> 
> There is a danger to the methodology in large projects. The overall 
> structure is determined after months of endless meetings, equipped with 
> flow charts, UML diagrams, and so forth before a line of code is written.
> 
> Finally coding starts and everyone soon realizes it's a hot mess. 
> However there is so much ego involvement in the design process that it 
> can't be abandoned so you slap on bandaids and tourniquets and hope for 
> the best.
> 
> https://en.wikipedia.org/wiki/Tony_Hoare
> 
> There is a nice quote from Tony Hoare on that page. Methodologies have
> come and gone over the years but seldom have achieved the desired results.
> 
> https://en.wikipedia.org/wiki/Software_development_process

'Design' was a poor word choice on my part. I think a more appropriate
word would be 'decomposition'. If you read my description more carefully
or the source material that I cited, it's describing something different.
Perhaps it's less applicable to large projects with large teams. But 
particularly when you write "... before a line of code is written", that
is not at all what I described nor is it what I'm talking about.

A relevant quote from Freud might be: The worst form of superstition is
to have no superstitions. I suspect the same may be true of methodologies.
The may be various benefits or drawbacks to any particular one you may
choose. But to have none at all sounds like a perfect recipe for disaster.

Fir objected that you cannot test your code until it's complete and there
is some truth to this. However with short functions that do what their
names say they should do, testing and debugging may be less necessary.
Appropriate abstractions and readable code make verification simpler.
If the function is short (and you know what the language constructs mean),
you can just read it to see what it does.

Obvious caveats apply. YMMV. FWIW. HTH. Something to think about. Worth
a try perhaps if one is shopping for a new approach. I don't claim it to
be a panacea. 

[toc] | [prev] | [next] | [standalone]

#139278

W dniu poniedziałek, 31 grudnia 2018 09:06:40 UTC+1 użytkownik luser droog napisał:
> On Sunday, December 30, 2018 at 5:47:29 PM UTC-6, rbowman wrote:
> > On 12/30/2018 01:39 PM, luser droog wrote:
> > > I'm still getting the hang of this methodology and struggling somewhat
> > > to put it in to practice (for various personal reasons which are
> > > unrelated to the technique itself). But it's sound. It's supported
> > > by many of the CS gurus, especially Dijkstra. For more detaills, I
> > > recommend his chapter in Dahl, Dijkstra, Hoare, "Structured Programming".
> > >
> > 
> > It's more often used to refer to finding your way through a thicket of 
> > intertwined classes in OOP but I remember someone referring to 'yo-yo 
> > programming'. You do a little top down until you get bored, then a 
> > little bottom up, and hopefully they meet in the middle.
> > 
> > There is a danger to the methodology in large projects. The overall 
> > structure is determined after months of endless meetings, equipped with 
> > flow charts, UML diagrams, and so forth before a line of code is written.
> > 
> > Finally coding starts and everyone soon realizes it's a hot mess. 
> > However there is so much ego involvement in the design process that it 
> > can't be abandoned so you slap on bandaids and tourniquets and hope for 
> > the best.
> > 
> > https://en.wikipedia.org/wiki/Tony_Hoare
> > 
> > There is a nice quote from Tony Hoare on that page. Methodologies have
> > come and gone over the years but seldom have achieved the desired results.
> > 
> > https://en.wikipedia.org/wiki/Software_development_process
> 
> 'Design' was a poor word choice on my part. I think a more appropriate
> word would be 'decomposition'. If you read my description more carefully
> or the source material that I cited, it's describing something different.
> Perhaps it's less applicable to large projects with large teams. But 
> particularly when you write "... before a line of code is written", that
> is not at all what I described nor is it what I'm talking about.
> 
> A relevant quote from Freud might be: The worst form of superstition is
> to have no superstitions. I suspect the same may be true of methodologies.
> The may be various benefits or drawbacks to any particular one you may
> choose. But to have none at all sounds like a perfect recipe for disaster.
> 
> Fir objected that you cannot test your code until it's complete and there
> is some truth to this. However with short functions that do what their


i previously wrote that i know only one c
methodology (winw) it is good methodology and there are not any problems with that

the problems i personally got hovever exist and are heavy and serious; i think
those problems are sorta psychical: i cannot force myself to code, at least not 
for a longer period of time (i can do it
in lesser amount but th eneed is to make it stronger and much longer)

also in my case there is also a philosophical problem with coding too 
(i know coding consumes great time, my lifetime is limited and i got really serious 'pangs of remorse' when involing me in coding (those strings of remorse 
are even not so closely sharp when i just play games of watch tv becouse its a programing which switches you brain deeply off... and when you code youre much more off than when watching tv)

(life diary digession 

in my personal case this second kind of problems (namely philosophical) are probably deciding (like i mostly quitted coding in 2012 afair, doing only some
smaller sessions from time to time.. this year 2018 i did it like even less than before

hovever i must say i partially rested and probably could be able to go basck for some time, suspending the philosophical doubts for a month or two... in that case
the struggling with thiose psyhical problems would be probably my main case again ;c)
)


> names say they should do, testing and debugging may be less necessary.
> Appropriate abstractions and readable code make verification simpler.
> If the function is short (and you know what the language constructs mean),
> you can just read it to see what it does.
> 
> Obvious caveats apply. YMMV. FWIW. HTH. Something to think about. Worth
> a try perhaps if one is shopping for a new approach. I don't claim it to
> be a panacea.

[toc] | [prev] | [next] | [standalone]

#139280

On Monday, December 31, 2018 at 8:06:40 AM UTC, luser droog wrote:
> 
> Fir objected that you cannot test your code until it's complete and there
> is some truth to this. However with short functions that do what their
> names say they should do, testing and debugging may be less necessary.
> Appropriate abstractions and readable code make verification simpler.
> If the function is short (and you know what the language constructs mean),
> you can just read it to see what it does.
> 
It depends what the code is doing.
If code has dependencies, sometimes these can be stubbed or mocked.
However the code might fail if the real code returns different values
to the stubs. Then sometimes setting up the inputs is so burdensome
that it is essentially too difficult to write tests. There is also
an issue when a function has to return something "good enough for the
human eye", that makes it very difficult to automate tests.

[toc] | [prev] | [next] | [standalone]

#139296

On 12/31/2018 01:06 AM, luser droog wrote:
> A relevant quote from Freud might be: The worst form of superstition is
> to have no superstitions. I suspect the same may be true of methodologies.
> The may be various benefits or drawbacks to any particular one you may
> choose. But to have none at all sounds like a perfect recipe for disaster.

This will elicit howls I'm sure but I look at methodologies as training 
wheels. The Holy Grail has been to develop a technique which will yield 
clean, efficient, and error free code. The unstated part is that the 
technique will allow mediocre programmers to be effective.

This isn't to say methodologies are bad; use them, learn from them, and 
determine what works for you and/or your team. Don't become a True 
Believer blind to alternatives. Be familiar with them all. That way when 
the Next Greatest Thing appears you can say 'Yeah, I remember that one.'

After all, Freud's star pupil, Jung, eventually said 'What a pile of 
crap this is.' and went off on his own tangent.

[toc] | [prev] | [next] | [standalone]

#139341

ram@zedat.fu-berlin.de (Stefan Ram) writes:

> rbowman <bowman@montana.com> writes:
>
>> intertwined classes in OOP but I remember someone referring to 'yo-yo
>> programming'.  You do a little top down until you get bored, then a
>> little bottom up, and hopefully they meet in the middle.
>
> Designing top-down is pretty cool, but when implementing,
> bottom-up yields units that can be tested immediately and
> sometimes even already be used before the whole project is
> finished.  So, design top-down and then implement bottom-up.
> (Yes, this still is a simplification and not intended to
> always be followed literally.)

The word "design" in "top-down design" means something different from
how you are using it.  For some people "design" means an unspecified
something that isn't code.  A "design" in the "top-down design" sense
is already implementation.  It isn't a complete implementation, as
some things are left out, most prominently subfunctions that are
called but not yet written, but it is still implementation.  The idea
that a top-down design can be implemented bottom-up doesn't make
sense, because the top levels have already been implemented.  So I
infer from this that you mean something different when you say
"design".

[toc] | [prev] | [next] | [standalone]

#139344

rbowman <bowman@montana.com> writes:

> On 12/30/2018 01:39 PM, luser droog wrote:
>
>> I'm still getting the hang of this methodology and struggling somewhat
>> to put it in to practice (for various personal reasons which are
>> unrelated to the technique itself).  But it's sound.  It's supported
>> by many of the CS gurus, especially Dijkstra.  For more detaills, I
>> recommend his chapter in Dahl, Dijkstra, Hoare, "Structured Programming".
>
> It's more often used to refer to finding your way through a
> thicket of intertwined classes in OOP but I remember someone
> referring to 'yo-yo programming'.  You do a little top down until
> you get bored, then a little bottom up, and hopefully they meet in
> the middle.
>
> There is a danger to the methodology in large projects.  The
> overall structure is determined after months of endless meetings,
> equipped with flow charts, UML diagrams, and so forth before a
> line of code is written.

What you're talking about here has no resemblance to what
Dijkstra was describing:  there are no meetings, flow charts, UML
diagrams, or anything of that sort.  Dijkstra's monograph is much
more down-to-earth.

> Finally coding starts and everyone soon realizes it's a hot mess.
> However there is so much ego involvement in the design process
> that it can't be abandoned so you slap on bandaids and tourniquets
> and hope for the best.
>
> https://en.wikipedia.org/wiki/Tony_Hoare
>
> There is a nice quote from Tony Hoare on that page.  Methodologies
> have come and gone over the years but seldom have achieved the
> desired results.
>
> https://en.wikipedia.org/wiki/Software_development_process

Note that methodologies and development processes are not the
same thing.  A lot of people conflate the two terms but they
are not interchangeable.

[toc] | [prev] | [next] | [standalone]

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

Back to top | Article view | comp.lang.c

csiph-web