[opensource] RESOLVE

Brian Swaney swaney.29 at osu.edu
Sun Feb 8 03:21:37 EST 2009


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Shaun Rowland wrote:
> I believe it was the original open source club people who created
> a Linux version of Resolve. I don't know what ever happened with that.
> I hope no one comes to me with a resume after taking the first set
> of core courses claiming they know whatever language it is implemented
> in when the course is not about the language, since - as we've
> established - it's not about learning the language... and I'd add
> "to a sufficient degree to be resume worthy" to that.
http://opensource.cse.ohio-state.edu/extra/rcpp is what we currently
have. We do not have a completed version because (a) I do not have all
the files necessary (many of my labs were lost to dead hard drives,
etc. and (b) if we included all the files, we'd be guilty of academic
misconduct. I was considering setting up a sort of Ubuntu RESOLVE
compiler for stallman, where club members could compile their labs
without having to log into Solaris, but was unable to do this. I
obtained the files here from Paolo Bucci, who said the files not
included are those used for students' labs, homeworks, etc. This means
some things, such as Sorting_Machine, will not work unless I can make
an arrangement of some sort with the RSRG.

One of the fundamental problems here is that even in an educational
institution, we are encouraging non-disclosure agreements which
prevent cross-platform compatibility.

Shaun Rowland wrote:
> On Feb 7, 2009, at 10:11 PM, Brian Swaney wrote:
>> Can nobody change the subject line so it doesn't ask about Printing?
> Nope. Now you've ruined an experiment in statically subject-ed thread
> evolution. I wanted to see if this could have evolved in a couple
> more directions with the same subject :-)
You're welcome.
>> For the record, I do support most of the RESOLVE principles. My
>> only 2 problems are that they are effectively wasting 3 quarters of
>> undergraduates' time by denying them access to actual usable
>> programming languages. For the same reason many programmers who
>> start with .NET languages have difficulty with other languages such
>> as C++, it is difficult to move from RESOLVE to another language if
>> that's the only one you know. A more useful means of teaching the
>> course would be to teach it in a language that would be useful to
>> know.
> Have you finished the course sequence and had difficulty moving to
> a new language? I view the point as teaching the concepts that should
> allow you to move to other languages. One should not get hung up
> on the syntax of Resolve. You could get hung up on the syntax of
> Java and then have problems moving somewhere else too - especially
> if they aren't covering how to really use the language itself and
> are instead using it as a means to an end in teaching the concepts.
> If the argument is to teach the languages, there are courses that
> do that already.
>
> Using the .NET programmer who can't move to another language easily
> example seems to enforce the idea that teaching concepts at first is
> more important than teaching a language itself.
I cannot back up my claims because I have not invested a significant
amount of resources into learning another language, but I am really
bothered by not knowing any languages, and therefore getting turned
down from anything I apply for. I would like to have learned a
language of practical use within those 3 quarters though, and it would
be much easier to apply the principles if I could use them in programs
I proceed to write in standard languages.
>> Also, the specifications are not very readable. While I appreciate
>> the need to document the input/output of your libraries, and to use
>> the same "contracts" for future implementations and thusly prevent
>> the need to rewrite the entire kernel for one extension, the
>> psuedo-mathematical syntax used is often less readable than the
>> code itself. If they want us to use their style, they should make a
>> point of how it simplifies programming by making their
>> documentation readable. I claim this can be done without losing
>> preciseness if done carefully, and is much easier. The current
>> specifications actually (for me) make RESOLVE harder, but maybe
>> that's just me. I've left feedback multiple times, both verbally,
>> and in course evaluation forms, but I get the feeling that the RSRG
>> is closed-minded on how they teach the series.
> Is their goal to get you using their mathematical syntax or to use
> it as a tool to enforce the concepts? As I said, my experience was
> years ago and I can't really answer that, but I know where my answer
> would tend to be.
They said something to the extent of using contract-based
specifications, where the math part was the client view, describing
what is expected of the client (user, being program or human) and what
is expected of the program assuming the client keeps his end. If the
client follows the *requires* clause, the *ensures* clause should
always be fulfilled, and you should be able to prove that. They use
math in order to make the clauses as specific as possible and prevent
ambiguities. The problem is, however, that there is no simple way of
putting actual math into ASCII code, and they wind up making it more
confusing to read than the code itself. It is also often much easier
to explain (or understand) what the function/procedure does without
the math, and without making the specifications any less precise.
However, as one of the course objectives, they still ask students to
write code based on their psuedo-math on exams.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFJjpYRcevrTUuxj9QRAkT5AKCKVefKXE1NX9JU8phUPqm6M1Aj6gCfVDXM
Oqy9hU8UpNR2zm4YwKXv1nw=
=euj8
-----END PGP SIGNATURE-----

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3250 bytes
Desc: S/MIME Cryptographic Signature
Url : http://mail.cse.ohio-state.edu/mailman/private/opensource/attachments/20090208/5c114356/smime-0001.bin


More information about the Opensource mailing list