Re: Can't read CString after serialization

See below...
On Thu, 13 Mar 2008 06:38:22 +0000, "Ian Semmel" <anyone@xxxxxxxxxxxxxxxxx> wrote:

Don't get me wrong, I agree with what Joe says further on about writing
programs for modern computers in modern languages etc, but some of the
techniques we used then are still current, I believe.

For example, many modern-day programmers have a fear of designing binary
message formats, their justification being that it is a lot easier to
debug if you can just load the messages into a text editor to view them.
However, some of the systems I work on are still using serial comms.
Messages which are half the length are transmitted twice as fast.
****
I/O bandwidth is one of those issues that has not scaled with the computing capability; a
serial port in 2008 is for all practical purposes the same speed as a serial port in 1978.
I worked in one app where we used a real-time zip library to compress the data as it was
sent across the port, and got a lot better than a factor of 2 (more like 20)
****

And although modern computers are 1000 times faster than they were, in
many instances they are executing 1000+ times the number of instructions
so the end result is not that much of an improvement.
****
Actually, not true. For inner loops and other intense computations, the number of
instructions is essentially the same. We might execute a million instructions to update
the screen instead of using printf, but that's not where the time goes, anyway.
****

I read a statistic the other day, that 80% of the world's financial
transactions are still processed using legacy COBOL code. Why would this
be so ? There have been a few spectacular failures trying to replace
older systems, but I do not know much detail about them. One aspect of
the many fewer tests etc we had back then was that we had to think out
the problem rigourously before leaping in. Today, we find an error, fix
it, and recompile and test without looking a bit further on to see if
there is another error looming.
****
Here's your assignment. Take 10,000,000 lines of undocumented source code, for which the
original programmers are no longer available (perhaps dead of old age), which interfaces
in obscure ways to undocumented file formats, convert it all to C#, make it better in
every way, and don't change anything. Note that the existing code is convoluted because
it must also conform to existing laws, regulatory agencies rulings (multiple agencies),
best-financial-practice, obscure policies of the financial institution, impositions of
case law in legal matters, Federal tax law, deal with the fact that if the customer is in
PA it must conform to the PA situations, but for the CT customers it must conform to the
CT situations, and the 1997 Smith vs. Amalgated Financial civil suit implications (which
apply only in PA, TX, OK, and MN). Get it right the first time.
****

In a past job, the boss did some statistics on programmer productivity.
He found that although those who had been trained in the batch days took
longer to initially write programs, they usually got them working in a
shorter time over those who had learned in an online environment.
****
This is more due to training in thinking than the limitations of the batch systems. I
believe the training in design was more rigorous than today, when voodoo like UML will
Solve All Our Design Problems; we foster in modern students the notion that "good tooling"
substitutes for thought.
joe
****

"Giovanni Dicanio" <giovanni.dicanio@xxxxxxxxxxx> wrote in message
news:OCycO2HhIHA.5752@xxxxxxxxxxxxxxxxxxxx:

"Ian Semmel" <anyone@xxxxxxxxxxxxxxxxx> ha scritto nel messaggio
news:eDA0hTHhIHA.4436@xxxxxxxxxxxxxxxxxxxxxxx


When I started programming in 1964, we had one compile and test per
day.


*One* compile and test per day??

...How long time was required to build software?



One drawback to this is that it has allowed what we would have called
"sloppy" programming practices to come into vogue.


May you give an example of "sloppy" programming practices widely used
today?
I'd like to learn... (maybe I use some of them and I'm not aware of...).

Do you think garbage collectors are sloppy programming practices? I
think
not, because they help the programmer focus on the problem to solve
instead
of focusing on details like memory management, IMHO.

Thanks,
Giovanni
Joseph M. Newcomer [MVP]
email: newcomer@xxxxxxxxxxxx
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm
.

Relevant Pages

  • Re: A modern C128 8-bit
    ... My personal views on a modern C128 like machine - - ... The DOS could be built as a relational database from the ground up. ... Right now there is no operating system that's based on relational ... can be for all types of programming. ...
    (comp.sys.cbm)
  • Re: aeBIOS pc speaker in 32 bit protected mode asm
    ... Programming the Programmable Interrupt Timer should work with either Terrence's code or Mike's 32-bit version, ... Guessing at the age of the original code, I'd bet that 300 is a little short for "duration" on a modern machine. ... The first two hook int 9, ...
    (alt.lang.asm)
  • Re: Cant read CString after serialization
    ... Don't get me wrong, I agree with what Joe says further on about writing programs for modern computers in modern languages etc, but some of the techniques we used then are still current, I believe. ... > "sloppy" programming practices to come into vogue. ... Do you think garbage collectors are sloppy programming practices? ...
    (microsoft.public.vc.mfc)
  • Re: To RISC or not to RISC
    ... And you don't get that "car" feeling when driving a modern car. ... do programming just for fun, there is nothing wrong to use assembler ...
    (alt.lang.asm)
  • Re: New Desktop
    ... Falcon more than any other system, I do agree that there are a lot more ... desktop features that I'd like to see added, ... modern one like you want, your option is the only one left, as ... I can't help much from a programming aspect (as I'm ...
    (comp.sys.atari.st)