Forgot your password?

typodupeerror

Comment: Two steps (Score 1) 246

by michaelmalak (#44024127) Attached to: Ask Slashdot: How To Start Reading Other's Code?

Two steps:

1. Make an act of thanksgiving that you're not dealing with code written by someone trained in FORTRAN, where all variable names are two characters long and all function names are six characters long. "You can write FORTRAN in any language." If you do happen to be dealing with FORTRANesque code, give up now.

2. Become familiar with the idioms of every programming language, of every programming paradigm (structured, object-oriented, functional, event-driven, dataflow, etc.), and of every programmer educational background (high school/self-taught, CS degree, startup pressure cooker, etc.). If you don't have time to do that prior to starting on the current project, then let your attempt to reverse engineer the current project serve as a building block for the next time.

Comment: Re:LaserDisc "brief"? (Score 1) 134

by michaelmalak (#43993931) Attached to: The Trajectory of Television: A Big History of the Small Screen.

The MPEG standards track (that eventually became the digital HDTV standards) was "in-the-works" in the mid 90's (not the 80's).

DIgital or no, the sense in the 80's was that HDTV was "just around the corner". On CompuServe's Consumer Electronics Forum (CEFORUM), we were all agonizing over whether to buy new televisions, or wait for the HDTV's to come out. The forum moderator, Marc Weilage, chided us that HDTV would not be able available in the next 10 years, although I doubt even he thought it would take 20 years. Although CEFORUM archives are not available, a 1989 UseNet post shows one of the hot topics of the day in HDTV standards definition: square pixels (to satisfy computer users) vs. rectangular pixels (to satisfy broadcasters, presumably for backward compatibility, interlace, and bandwidth issues).

The 1998 alt.video.dvd FAQ thought it necessary to include the question, "Will DVD support Digital TV (HDTV)?" Some people thought that by buying a DVD player, they were preparing for the HDTV future.

Comment: LaserDisc "brief"? (Score 2) 134

by michaelmalak (#43992425) Attached to: The Trajectory of Television: A Big History of the Small Screen.

FTFA:

LaserDisc had its brief moment in the sun

Brief? LaserDisc was available for almost as long as VHS, having come out in 1978 compared to VHS's 1976. DVD killed them both circa 2000. Coupled with a $10,000 Kloss projection TV, LaserDisc ushered in "home theater" 20 years before DVD made the term popular. (In fact, LaserDisc had been out for so long, the release of DVD caused a collective groan due to the market confusion it created over whether its 480p was "hi-def" and the delay in HDTV standard that had been in the works since the 80's.)

Comment: Here's the one recommendation you need (Score 2) 206

Target house brand box red wine. That's right, you buy it at Target (at locations where they're allowed to sell wine).

The three varieties, Merlot, Shiraz, and blend are all good. It's like the best $12 bottle you've ever had -- not a typical $12 bottle, the best. The box is $16 and contains the equivalent of four bottles, of course with the self-sealing spigot and collapsing plastic bladder to prevent oxidation. Stays fresh for weeks or even months after opening -- provides a glass a day for three weeks.

Comment: Re:Code should accompany data (Score 1) 358

by michaelmalak (#43911923) Attached to: Vint Cerf: Data That's Here Today May Be Gone Tomorrow

I consider PDF to be powerful because it can contain JavaScript, and even embedded mouse-driven interactive animated 3D. I consider PDF to be a lateral alternative to embedding JavaScript in XML as I presented.

I agree, self-describing formats, such as the Voyager pixel image and the Contact engineering diagrams, are interesting. They solve the extreme of the problem, in a survivalist way. It's the bomb shelter level of planning, whereas it would be reasonable for most people to instead just stock 7-30 days of provisions on a shelf. A shelf is convenient, as is a data file that executes itself against a widely-available interpreter.

Yes, I see the chain of operating systems as the solution just for the closed source world, and I'm hoping those days are behind us or soon will be.

Comment: Re:Code should NEVER accompany data! (Score 1) 358

by michaelmalak (#43911811) Attached to: Vint Cerf: Data That's Here Today May Be Gone Tomorrow
In my presentation, you'll see that the strategy of embedding XSL in an XML file has the code in the top half and the data in the bottom half, clearly delineated. They are easily separable. But by having them in a single file, they will not get separated by someone copying them.

Comment: Re:Code should accompany data (Score 1) 358

by michaelmalak (#43911749) Attached to: Vint Cerf: Data That's Here Today May Be Gone Tomorrow

The likely long-term viability of PDF does not discredit the long-term viability of JavaScript.

You agree with Vint Cerf about PowerPoint 97 being an archival format. I disagree with him. As I wrote, I believe software archives will maintain VMs, copies of OS's, and copies of Microsoft Office due to the historical installed base of tens of millions.

The question is whether you would be able to find a JavaScript interpreter on a search engine in 2100. I believe the answer is "yes," because it was an important (by installed base) piece of software. Admittedly, it won't help you in an apocalyptic scenario.

Comment: Re:Code should accompany data (Score 1) 358

by michaelmalak (#43911417) Attached to: Vint Cerf: Data That's Here Today May Be Gone Tomorrow

It's an issue of installed base.

The installed base of any given NDT system is typically less than Qty. 100, often much less. The installed base of HTML5 interpreters is on the order of a billion. The installed base of PowerPoint 97 at its peak was in the tens of millions. To be honest, I think Vint Cerf is complaining a bit much. Anyone (including him) could download the appropriate VMs, archival operating systems, and archival Microsoft Office systems to read PowerPoint 97 and even convert it to a modern format where the file could even be further edited and modified. In his search to provide an example, I don't think Vint Cerf came up with a good one.

A life-critical system with an installed base of less than 100 where the data must be preserved for 50 years is a better example, and answers your question: why code can be more useful than data. Code from an installed base of 100 is useful if it relies upon software that had an installed base of a billion.

Comment: Code should accompany data (Score 4, Interesting) 358

by michaelmalak (#43911113) Attached to: Vint Cerf: Data That's Here Today May Be Gone Tomorrow

I presented a solution to this long-standing problem last year to the Denver HTML5 Meetup.

Code should never be separated from data. This is possible with HTML5, JavaScript, and open source.

In the presentation, I steal and repurpose Hofstadter's analogy of DNA to an LP vinyl record, which is an information bearer, but useless without its information retriever (the record player). Like the cell of an animal, which contains both DNA and the means to "play" it, I ask why not the same with software?

My maxim is: data should always carry the code with it to play itself. It was inspired from the field I've spent 50% of my career in: non-destructive testing where, for example, X-Rays and ultrasounds are performed on safety-critical industrial parts with 50-year service lives. If one of those parts fails and kills someone, you're going to want to go back into the old data and find the earliest indication of the flaw or fault and reinspect every other part in the world like it that is still in service. And maybe you need to go back 50 years. Under such a context, not providing the code with the data could be considered an act of gross neglect.

In my presentation, I use the 1990's era trick of embedding XSL into an XML file, with the addition of the XSL now being able to use HTML5/JavaScript. Sadly, I've only gotten it work with Firefox -- the other browsers consider it a security violation.

Comment: Re:Not a troll - no pun intended (Score 1) 146

by michaelmalak (#43892011) Attached to: Salvaging E.T. In Software, Instead of New Mexico

I really don't understand why people are even discussing this anymore. I have this game, it sucked, it was 20 something years ago - no one should care. Moon Patrol was the shit.

Indeed, that is why the previously linked arstechnica.com story includes:

reports suggest the dump may also contain unsold consoles, PCs, and even prototypes of the Atari Mindlink controller

The "oh we'll find 3.5 million copies of E.T." is just the satire -- that they'll have to dig through waist-deep crap to get to the gems.

You need tender loving care once a week - so that I can slap you into shape. - Ellyn Mustard

Working...