Peter Bex wrote:
On Thu, Dec 14, 2006 at 03:41:44PM -0800, Brandon J. Van Every wrote:
I know and understand why to use tests. I'm not opposed to tests,
but I am opposed to lumping the tests in with the main code.
I'd much rather just keep the code clean and put the tests in
another file.
Well, I question why we have files. We have historical reasons for
it; all of our text editors are built in terms of them. But a program
is really just one big database of stuff, and it might make more sense
to have it all uniformly accessed and searched, rather than being
cobbled across a filesystem.
Thus I am saying, "why should it appear together" vs. "why should it
appear apart," is pretty arbitrary and historical. If one regarded
the program as a database, then either is just a view of the database.
When the time comes that all tools support this kind of "I choose what
I want to see" stuff,
Well, even SciTE appears to support "folding," which seems to be the
gratuitous expansion and collapse of code you don't want to look at. So
if your editor could "fold" the contract, then the clutter wouldn't be
an issue. So it seems that the time is now, for some tools that are
somewhat evolved.
you won't need files and there's no problem with
lumping everything together because you select your own preferred view
for the particular task you're working on. Unfortunately (?), that time
isn't here yet and we have to make do with imperfect plaintext-editors
(though paredit.el really helps).
One mustn't apologize for Emacs. Those cardboard stands at the grocery
stores with all the dimes and quarters in them? They're for the Emacs
users.
Only if those specifications are terse, legible, and universal enough
to describe nearly any class of problem that needs specification. I
have my doubts, but I haven't tried this paradigm. I suspect my eyes
will glaze over, and that deciphering contracts isn't much better than
deciphering simple tests.
What I read between the lines is that you're opposed to this idea because
you don't have any experience with it.
You needn't read between the lines, just re-read what I've written
elsewhere in this ever lengthening thread. I don't oppose contract
programming. I'm generally in favor of any testing method, good
comments, and things that resemble literate programming. However, I
think there are probably limits to what contract programming can do for
people, so I'm not inclined to oversell it. It would be one heckuva
specification language that could handle any arbitrary problem domain,
with clarity and aplomb. I think there will be head scratching, same as
always. It isn't that different from writing small, clear, concise test
cases.
I bet once you've seen a few
programs that work like this, you will gradually learn how to read them
and that will mean a productivity increase.
When you first came into contact with a recursive Scheme program, didn't
you think it was very difficult to read?
I *still* think it's difficult to read. I think *C* code is difficult
to read. Code is difficult to read.
I'm sure specifications in the form of contracts, if done properly, are
a lot more terse than tests. Which is exactly why I'm so fiercly opposed
to inline tests. As an example: A big project I'm working on at work has
a core library that has to be tested well. The library is only 400 lines
of Ruby code (it builds on existing classes), but it has ~1400 tests.
That is an awfully big test:code ratio. You really don't want to have
these tests inlined!
I don't value terseness. I am opposed to gratuitous required verbosity,
like VariableNamesThatMustBeReallyLong, but that's not the same thing as
valuing terseness. If you read CMakeLists.txt, you will see it is far
from terse. It certainly isn't bloated, everything in there actually
does something, but it became a lot more verbose when I tutorialized the
whole thing. Whether something is 400 or 800 lines of code really isn't
the issue. The issue is how long does it take to write it, and how long
does it take to read it. If it's longer but clearer, that's better. If
it's longer and straightforward, rather than being terse and fancy,
that's better. The worst code I wrote in CMakeLists.txt is the stuff
where I gratuitously macrotized the lists of files. It's much easier to
maintain a manual list of files, because people can actually find things
and add/delete them, without needing to understand any oh-so-clever macros.
I think Perl sucks. That's pretty much the epitome of terseness at the
expense of intelligibility.
Tests
don't say shit. They're a very low-level and nonsemantic way of
groping around to ensure your corner cases are covered.
Depends on the test. I think the comments are what help. I don't
care what kind of code someone writes, it's gonna make my eyes glaze
over.
Again, this is personal. In my opinion, code is the only thing that
really counts. Comments are often neglected with the heat of a deadline
on your heels, or don't touch upon every aspect.
Well, I don't like the computer industry, or how most programmers behave
in it.
Tests may miss significant situations
people just didn't think of at the time. Same goes for contracts, by
the way.
Right, which is why I'm not inclined to oversell contracts.
If you do not want to read code, you shouldn't be in the
programming business.
Hey that's like saying if you don't want to read Microsoft APIs, you
shouldn't be in the programming business. Bull-oney! There's all kinds
of things in programming I don't *want* to do. The question is *will* I
do them? Yeah, I'll read / funge other people's code *if* it does
something for me, or *if* I'm getting paid. Otherwise, it's a complete
waste of my time. Sitting around reading other people's code ain't one
of the joys.
Declarative styles are not panacea. Some problems are better
specified imperatively. Sometimes you really want to know that "A
happens, then B happens, then C happens" and it's easier to debug.
That's a matter of personal preference. I am sure a lot of Schemers
will disagree with you here.
No, it's not preference. What I stated above is fact. You are going to
run into situations where "A happens, then B happens, then C happens" is
easier to debug. Now, how often you write that sort of code, or have to
deal with that sort of code, depends on what you're up to.
The latter. Because I'm probably implementing a bit twiddling
optimization algorithm, and I need to know exactly what's happening as
the code converts to machine instructions. When you state a
preference for declarative interfaces, you are implicitly stating you
don't want to be bothered with the implementation details. That you
prefer abstract problems. Now that may have its place in various
problem domains, but not typically in mine.
If your domain is the odd one out, should Chicken really give second-class
treatment to all those other ones?
Should Scheme be a pure declarative language? Nope. Should OCaml?
Nope. I don't believe in pure programming languages. When you
straitjacket people with The One True Paradigm, all you do is complicate
things for someone else's real world problem.
Of course, from your perspective it
should right now, but what if you need to write some entirely different
type of program? Wouldn't you like to do it the best way possible, and
in Chicken?
Bigger is fine.
I really dislike Java and C# where you often end up with huge amounts
of boilerplate code. Bigger is *not* better, that's one of the reasons
we have macros.
Macros are a two-edged sword, requiring judicious use. The common
wisdom is, don't use 'em unless that's the only way to get the job done.
I suppose we just have to agree to disagree on this issue. Maybe a user
poll about what approach to take is in order?
No, not really. Having declarative contract programming available is
fine. Forcing people to use it is wrong. Expecting everyone to think
it's the greatest thing ever, is unrealistic. Some people will do
contracts and others will do tests.
Cheers,
Brandon Van Every
_______________________________________________
Chicken-users mailing list
Chicken-users@nongnu.org
http://lists.nongnu.org/mailman/listinfo/chicken-users