[OT] Re: Advice on Programming Language
From: Anthony Borla (ajborla_at_bigpond.com)
Date: 11/25/04
- Next message: Karl Heinz Buchegger: "Re: Atoi keeps on failing."
- Previous message: Karl Heinz Buchegger: "Re: Atoi keeps on failing."
- In reply to: SecretCodeBreaker: "Advice on Programming Language"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Thu, 25 Nov 2004 08:32:29 GMT
"SecretCodeBreaker" <thisisan@invalid.address> wrote in message
news:BE6pd.55373$7i4.43203@bgtnsc05-news.ops.worldnet.att.net...
> I would like some advice about the choice of a programming
> language.
>
> I am considering beginning a project to revise and 'reprint' my
> three book series "Secret Code Breaker - A Cryptanalyst's
> Handbook."
>
> I'm getting down to the bottom of the barrel with copies of
> the first printing and I must decide to do either a reprint,
> revision or just let them go out of print.
>
> The project would essentially be this -
>
<DOCUMENT PUBLISHING ISSUES SNIPPED>
>
Your editor / publisher would be the most appropriate source for such
information, or perhaps a forum that specialises in that area. A quick
Google search turned up the following link:
http://www.soltys.ca/techcomm/dtp.html
which may provide you with a suitable starting point for further research.
>
> The programs for the first two books were written in QBasic.
> The third book's program was written in C++. All of the
> programs from the view point of the user look the same (simple
> DOS programs) and all will run on a plain old DOS platform or
> in a 'Window.' None require any Windows support and no
> special features are used (like a mouse).
>
Ok, so they are console-based applications. However, are they command-line
driven, or interactive in nature [e.g. present the user with a menu of
options, and the user is expected to remain within the program environment
while they work] ?
>
> Chris Card wrote the Secret Code Breaker Monoalphabetic
> Cipher Solver program using C++ and that program requires
> a Windows platform on which to run. I like the 'appearance'
> of this program and I recall that it was necessary to write it
> in C++ because of a 'speed' requirement for some of
> the complex algorithms it required. Dave Smith wrote the
> Secret Code Breaker PolyAlphabetic Cipher program using
> Visual Basic and it has a nice appearance also. Speed was not
> an issue in this case, and would not be an issue for the programs
> that are part of the three books.
>
It is quite possible to:
* Separate user interface and 'core' code, perhaps
placing each into separate libraries [e.g. DLL's or
shared libraries]
* Construct programs using different languages, one for the
user interface, another for 'core' code that perhaps has
more exacting performance requirements
In short, your program(s) need not be designed as standalone, 'one-piece'
applications. I elaborate on this aspect in the postscript.
>
> The first book's program was written in 1993 and it still
> runs on any Windows machine today (and on a Mac with
> emulation). Their primary drawback today is that they 'look like'
> old programs ...
>
Is this observation purely from a user interface perspective, or does it
also include a source code perspective ? What I am asking is if your book
includes source code listings of the program(s), and expects / encourages
the reader to alter, enhnace or otherwise tinker with the program(s).
>
> ...and don't use a mouse. Most users today
> are lost if they can't use the mouse.
>
It depends what you mean by 'most users'. I'd argue that if your target
audience is technically-oriented, even mildly so, that they would be quite
comfortable using an non mouse-based user interface. I would tend to think
that any one reading your book(s) would be in this catergory.
>
> My primary requirement is that the programs have a long
> shelf life.
>
My gut feeling is that the QBasic programs would definitely need to be
rewritten to achieve this. This isn't a reflection on their quality or
performance, nor is it indicative of a predjudice against this language. Put
simply, this language is neither in widespread use [overtaken by VB], nor is
it any longer relevant, particularly because of its lack of support for many
modern facilities; it is highly doubtful it would appeal to a modern reader,
let alone be easily understood by them.
>
> Any way, what would you recommend as a programming language
> for re-writing these programs? Visual Basic, C++ or is there
> another language that would be best?
>
Currently popular languages such as C, C++, Java, Perl, Python, REXX, and C#
[in the Windows environment only] would all seem [on the surface] to be
suitable candidates for such a rewrite, though many more issues need to be
considered before a final choice can be made.
I hope this helps.
Anthony Borla
P.S.
It's not clear whether you considered it or not [I suspect not] but it is
quite possible to (re)design the program(s) so that the user interface code
is entirely separate from the 'core' application code [i.e. the code
implementing the various cryptographic algorithms].
This division may take one of several forms, and in all cases, offers the
advantage of making your code far more flexible in that you have a greater
choice of user interfaces that could be offered.
For example, assuming that 'core' code was placed in a shared library [e.g.
Windows DLL], you could then write seperate programs [in possibly different
languages] that would use this code but present different user interfaces. A
possible scenario:
* Write the 'core' code in a compiled language like C
or C++, and package as a shared library
* Write the user interface programs:
- Command-line driven program(s) also using a compiled
language
- GUI-based program(s) using a scripting language like
REXX or Python since it is quite easy to write non-complex
GUI programs using these languages
- A console [i.e. text-based] program, perhaps implementing
a menu, sporting mouse support and screen control. Again
REXX or Python could be used here, but both C and C++
would aslo be feasible candidates
Each of these interface programs would use the same library-based 'core'
code. It is even possible to have the GUI and console + screen control
program(s) invoke the command line program(s) to perform the requisite
tasks.
Another approach that could be used is a browser-based design. Here the user
interface is implemented via loaded web pages in the user's web browser; an
interface could quickly be implemented using something like JavaScript. The
'core' code could reside locally, or could perhaps be installed at a remote
web site for acces via URL.
As you can see the design opportunities are vast. I would suggest that you
do much more research before deciding on an approach, especially if you want
it to be long lived.
- Next message: Karl Heinz Buchegger: "Re: Atoi keeps on failing."
- Previous message: Karl Heinz Buchegger: "Re: Atoi keeps on failing."
- In reply to: SecretCodeBreaker: "Advice on Programming Language"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
|
