Subject: RE: [hackers-il] Maintenance of 10,000,000 lines long application s?

From: Chen Shapira <[email-masked]>
Date: Sun, 6 May 2001 11:38:33 +0200

> *alert* *alert* *alert*....  a good integrator has to be a 
> good programmer
> as well. it could be very dangerous placing a non-experienced 
> programmer
> in configuration management. i've seen it done and causing problems...
> 
> the integrator _must_ be able to read the code being checked 
> in, and see
> what was changed, to avoid problems that delay the whole project's
> development.

From our experience, a smart second/third year student can read code and
verify changes very well.
The main problem with unexperienced programmers (for example me), isn't the
way they read code, because code reading is taught and tested in the
university. The problem is with specific aspects of code writing. They tend
not to test their code well enough, and don't pay enough attention to
special cases.

I saw Comverse employing a complete non-programmer as an integrator, a smart
pre-army kid, who studyed computers in highschool. This too worked, but not
as well, and required more work from programmers.

---

From: Chen Shapira <[email-masked]>
Date: Sun, 6 May 2001 16:16:41 +0200

> A very helpful tool for little-by-little productive 
> development is a visual IDE,
> but I'm not crazy to say such a thing in this list.

Actually this list isn't a homogenous as you think.

I'm a GUI developer, working under windows, with MS-Studio tools.
I mostly enjoy it.

I agree that visual IDE is the best thing since sliced bread, but why do you
think it helps little-by-little development?

I think that the most helpful thing for incremental development is working
in an interpeted language.

---

From: Omer Musaev <[email-masked]>
Date: Sun, 6 May 2001 17:04:59 +0200

> i also find that beginning programmers often compile after absurdly
> small changes, even as small as one line of code.
> 
> so, a question, o' il'y hackers: how often do you compile? approx, per
> how many lines of code?

My current preference is to code in following manner:

1. Understanding the problem, maybe writing a few unit tests to describe the
problem
and to make some estimation of problem.

2. Coding a bit, something like 100-500 lines of code

3. Stepping with debugger all the code, starting with the outer functions,
going down 
to inner ones and back to outer.

4. Writing more unit-tests

5. Re-decisioning about some points. Coding at this stage usually do not
span more than 5-10 lines of
code between builds. Sometimes I even build after inserting a CR into a code
- to make the code more
debugger-friendly.

I found that the worst bugs I have appear _after_ refactoring. For that
matter unit-tests
are very useful. 

As you can see, in that approach I mix both styles - writing big blob of
code _and_ making tiny
changes between builds. I prefer this way because:

a. When you write some piece of code, you usually have some interaction
between various parts of 
your program. You want to design the code as close to requirements as
possible, and ( in my case )
that make a lots of code just to complete the design.

b. When you have a (mis)functioning code already, you do not want to drown
below too many changes.
 
Hope that this helps.
> -- 
> mulix
> http://www.advogato.com/person/mulix
> 
> linux/reboot.h: #define LINUX_REBOOT_MAGIC1 0xfee1dead

---

From: Omer Musaev <[email-masked]>
Date: Sun, 6 May 2001 17:21:55 +0200

> but I'm not crazy to say such a thing in this list.

I am very fond of making a lots of tools do the work instead of me. For that
matter I 
would say that I prefer to use IDE when such a thing exists instead of many
various tools, 
but, unfortunately, I do my development under platform that lacks any one
IDE that would suit 
my needs.

One can argue that UNIX itself _is_ IDE, since it gives you version control
tools, build tools, 
source code analysis tools et cetera. 
Moreover, UNIX environment is very generic and can be adapted to a wide
range of development models.

However, I would like something more expressive, environment that would not
make me think on 
_how_ do I do one task, but rather do it.

I think that Xemacs has a lot of tools to help a programmer to program. 
But even that monster of features is not enough for me...

What I use now is a strange combination of Xemacs, shell scripts, commercial
IDE ( which I use as plugin 
for Xemacs ) and a lot of emacs LISP hacks to make my builds on remote
platforms.

P.S. My team doesn't use the build platform that Chen described. I hope we
will one day, but now it is 
one integrator ( who can be backed up by two other people ) for approx 30
people, and instead of configuration
management software we use SCCS/workspace by Sun.

> Dan.
> 
> To unsubscribe from this group, send an email to:
> [email-masked]
> 
>  
> 
> Your use of Yahoo! Groups is subject to 
> http://docs.yahoo.com/info/terms/ 
> 
>

---

From: Omer Musaev <[email-masked]>
Date: Sun, 6 May 2001 21:00:09 +0200

> > And after working for 1 year on CGI without a debugger, and 
> then moving to
> > ASP which has a debugger - I can safely say that debuggers 
> are very cool.
> 
> aye, a debugger is nice. but thinking hard about the problem 
> and PROVING
> your solution is correct, for all cases (which is my preferred coding
> technique, for tough problems) makes for much better code. and that's
> the whole point, isn't it?

well, this is obvious. However, by rejecting software tools you shooting
yourself in foot.

Regarding proving solutions: http://www.afu.com/proof.gif

---

From: Chen Shapira <[email-masked]>
Date: Sun, 6 May 2001 21:06:13 +0200

Let me generalize your statement, and we'll both feel happy:

Programming without thinking is dangerous.

All else is commentary. Stupid mistakes can be done with or without a
debugger.
You can make them more easily with a debugger, but you can make everything
easier with a debugger, so its not fair :-)

> -----Original Message-----
> From: Chen Shapira 
> Sent: Sunday, May 06, 2001 8:50 PM
> To: [email-masked]'
> Subject: RE: [hackers-il] Maintenance of 10,000,000 lines long
> application s?
> 
> 
> > agreed, to both accounts. on a tangent, the use of the 
> > debugger, i would
> > be happy to have your opinions on the following post by linus:
> > 
> > http://lwn.net/2000/0914/a/lt-debugger.php3
> > 
> > i find that when i try to avoid the debugger, the resulting code is
> > higher quality, because i have to reall _think_ about the code i'm
> > writing. however, in some cases (a deep call stack, an obscure bug
> > which only happens every n'th iteration), a debugger is very, 
> > very usefull.
> 
> The other day, OmerM and I discussed Linus's attitude toward 
> conventional
> development tools (CVS, Debugger, IDE, etc.). We worried that 
> since so many
> young people view Linus as a Demi-God, they will be presuaded 
> into thinking
> that inorder to be more like Linus (which isn't a bad wish) 
> they should
> avoid software tools.
> 
> Which reminds me (and forgive me for discussing female 
> problems in a male
> forum, but after you started with playboy...) for many years 
> I was a rabid
> feminist, naturally I avoided wearing bra's, which are 
> obviously yet another
> symbol of male oppression. Last year I started wearing bra's 
> and guess what?
> They are damn comfortable.
> 
> Same with software tools, they may substract from your 
> "hacker" value, and
> you can certainly work without them, but they are damn comfortable.
>

---

From: Chen Shapira <[email-masked]>
Date: Sun, 6 May 2001 21:14:53 +0200

> Regarding proving solutions: http://www.afu.com/proof.gif

BTW, there's a mistake in this proof.

Few other things:
1) One doesn't need symbolic logic to prove anything. Dr. Aner Shalev always
wanted to write a formal proof as a poem. But really, most proofs you meet
when studying math aren't that symbolic. They are pretty readable.

2) Functional programming was built around the concept of formal proofs.

3) Proving a solution doesn't need to be a formal proof, it is usually
enough to have convincing arguments on why the logic behind the code is
right. Most of us do it during code reviews.

---

From: Omer Musaev <[email-masked]>
Date: Sun, 6 May 2001 21:20:09 +0200

> Sent: Sunday, May 06, 2001 9:15 PM

No, at his book pvdl says that he lied and there is no mistake.

> right. Most of us do it during code reviews.

You are right. However, formal proof is an extreme case of proving, and,
like 
any other thing taken to extreme, it can cost more that it gives.