SciFi history?

[DMcCunney]

Originally Posted by nomesque

*gibber*

Help! I'm remembering my university days! That's not supposed to happen, is it?

ARGH - flashbacks... computer lab... unix boxes... VI!!! Telnet!!! Linx! Eiffel!!!

*weeps and stuffs memories back where they came from*

"You are trapped in a maze of twisty little university memories, all different."
______
Dennis

[nomesque]

Originally Posted by DMcCunney

"You are trapped in a maze of twisty little university memories, all different."

MUDs!! ARGHHH!!!!

[pholy]

When are we going to get back to SciFi history?

I have very little interest in reliving the career from which I just retired.

[Worldwalker]

Originally Posted by pholy

When are we going to get back to SciFi history?

I have very little interest in reliving the career from which I just retired.

Given the way this thread has drifted, perhaps if you started a thread called "Computer Nostalgia" that would mutate into a discussion of science fiction history.

[HamsterRage]

I'm a vi and vim fan. A couple years back I switched over to a Dvorak keyboard layout and, man, did that cause problems for me with vi. It seems that in my head, I had linked the commands to specific keys, not the letters. So when the letters all moved around the keyboard, taking the commands with them, my brain didn't make the swap.

Some changes were tragic. For instance, the Dvorak "D" is on the Qwerty "H". So I'm looking to go back, or left, a couple of characters and my fingers automatically go to the Qwerty "H" key. Which, of course, is now "D". If you know vi, then you know what happens instead of going backwards a few characters.

[theducks]

Originally Posted by pholy

When are we going to get back to SciFi history?

I have very little interest in reliving the career from which I just retired.

I was just re-reading some (not so) older SF books where the author "Modern" computer jargon or terms.

"Asked IT for another 1024K of online-storage"
Inserted her disk.
CRT (as a computer terminal)
Sort of reminds me of, Scotty and the Mouse" in one S.T. movie

Other books have the same basic, future functions, but use vague terms and avoid tottally Dating the date written.

Storage cube
VDU, Terminal
Flimsy (Avoids a specific type of hard copy)

Then there are "Waldow's", where SF named a future product

[nyrath]

Originally Posted by pholy

When are we going to get back to SciFi history?

I have very little interest in reliving the career from which I just retired.

I've written a little bit about SciFi history
http://www.projectrho.com/rocket/rocket3ab.html

[pholy]

Thank you for those links - I think... I know i will spend many hours browsing all that. Ah, well, that's what retirement is for, I guess. You get all the Karma I can give.

[mike_bike_kite]

Originally Posted by nyrath

I've written a little bit about SciFi history
http://www.projectrho.com/rocket/rocket3ab.html

What an excellent read!

[nyrath]

Why, thank you!

[GeoffC]

True History or True Story the first sf story ?

[frquixote]

Originally Posted by Worldwalker

My first programming language was FORTRAN IV, and I've been accused of writing FORTRAN programs in every language I touch, including assembler.

Ah, the nostalgia! Did you, by chance, learn FORTRAN using WATFOR or WATFIV?

[nyrath]

Well, for my part, I was taught WATFIV FORTRAN.
Oh those fussy Hollerith cards.

[jbjb]

Originally Posted by Ralph Sir Edward

O O - How do you change an object? Well... the object has the code that made it embedded as part of the object. You end up re-executing the code to get at the data, change the data, and re-encapsulate the data with the code. You think that isn't overhead? In a non O O language, you read the data raw, in your own data layout (or existing file layout you reuse), mod the data, and write. An order of magnitude less machine use. (But you have to know your data! (i.e. you have to know what you are doing.))

It's not always as bad as all that. C++, for example, can be written very efficiently, with minimal or no overhead over an equivalent C program.

I know purists will say that C++ isn't a pure OOP language, but it certainly includes OOP in the paradigms it supports, and it's certainly possible to write in an OOP style in C++.

/JB

[jbjb]

Originally Posted by DMcCunney

One of the biggest problems in programming has been the need to allocate memory used by your application, and free it again once done. In C, for example, you use malloc to do it, and it's on you to handle the case where there isn't enough memory available and fail gracefully.

Or if you're on an OS like Linux with VM and deferred physical page allocation, you may find that malloc returns a valid, non-NULL pointer but the app faults with an out-of-memory condition later when you try and use it.

It's also on you to make sure the memory you allocated is properly freed when you're done with it, and "memory leaks" because this didn't happen are probably the single biggest headache for programmers. You did put in a "free" call to free the memory, but something happened and it never got executed....

In a language like Java, those details are handled for you. You can concentrate on the logic of the application, not the housekeeping required to make it work.

In my experience this can often lead to problems. Programmers lean too heavily on the garbage collection, and end up without a clear idea of the ownership and lifespan of their data structures. Given that memory is only one of the limited resources that a programmer needs to keep track of (sockets, file handles, various other system resources, etc. etc.), this lack of clear understanding causes issues elswhere.

Garbage collection also introduces differences in behaviour between the same Java program on different platforms.

2) It's "write once, run anywhere." Java compiles to tokenized binary form called bytecode, targeted at the underlying virtual machine implemented by the JVM. The bytecode is the same, regardless of what you wrote it on. So you can take a well written Java program created on a Windows PC, compile to bytecode, and run that bytecode on a Mac, expecting it to look and behave the same.

"Write once, test everywhere" is perhaps a better characterisation. There is lattitude allowed to JVM implementors in areas such as threading model, garbage collection etc. which means that the behaviour of a (perhaps poorly written) Java program can vary significantly between
platforms. For example, implementations may vary widely in terms of when garbage objects are reaped and hence when, or even if, finalizers are run. Any program which has any significant work done in a finalizer is prone to portability issues.

/JB