Slashdot Mirror

Remember the 4GL initiative from Japan in the nineties? Still waiting for that killer language...

Yet Another AC here. Their 5GL languages KL0 and KL1 have been released as open source for several years. Those are basically versions of Prolog to do low level programming, such as writing operating systems for parallel computers.

The main problem of the Japanese 5th Generation project was that their dedicated parallel hardware could not compete with clusters of cheap off-the-shelf hardware.

Different AC here. A language can be considered Turing-complete even if the machines you can run it aren't universal machines.

I was going to say the same thing.

Your move, AC ;-)

We are legion.

Dell traces its origins to 1984, when Michael Dell created PC's Limited while a student of the University of Texas at Austin. The dorm-room headquartered company sold IBM PC-compatible computers built from stock components.

8 years after Apple started making computers, just like the OP said.

The Micro-Professor MPF-I, introduced in 1981 by Multitech (which, in 1987, changed its name to Acer)

5 years after Apple started making computers.

Really?

7 years after Apple.

Cray never made PCs

In 1954, Fujitsu manufactured Japan's first computer, the FACOM 100, and in 1961 launched the transistorized FACOM 222.

Here's a picture of your FACOM 100, c'mon, check your facts before you do the Wikipedia copy/paste. It's pretty obvious Schiller meant PCs, even the Slashdot title says "PC Maker."
http://museum.ipsj.or.jp/compu...

Pretty sloppy counterargument. Your biggest problem? Apple built their first PC in 1976.
http://en.wikipedia.org/wiki/A...

You're using the date of 1984, which is the Mac. OP clearly was not talking about the Mac intro date, he calls the Mac's release date out as a separate date in several sections.

By the time I hit middleschool, his curriculum had been curtailed down to essentially teaching word processing.

By highschool, it was a total joke, focused around... yet more word processing.

Ha ha, somewhat ironically, one of my first significant computing device I had when I was growing up in Thailand was a word processor, albeit a somewhat nice Japanese one similar to:
http://museum.ipsj.or.jp/en/computer/word/0001.html

The keyboard, menus, and manual were all in Japanese, but it used lots of pictures and diagrams so I was able to muddle my way through many of the advanced editing, printing, and file management functions without knowing a single word. It was a pretty interesting introduction to thinking symbolically. Certainly was more of a challenge figuring out how to use that word processor than playing games on my old C-64 or even copying BASIC programs onto it from 3-2-1 Contact magazines :P

I found one...
http://museum.ipsj.or.jp/en/computer/office/0007.html

it used a box of relays as the processor.
State of the art ....

This is the list of defects that odf still has, according to the SC4
Considering ooxml has much more and much serious problems, I'm starting to think this will end just like the dis29500(ooxml) standardization process.
*sigh*

Agreed; we will fully define the information necessary to implement each compatibility setting which was not previously completely described. ...

Note the future tense.

Maybe, Slashdotters are just slow readers and haven't finished reading the 2293 pages of the Disposition of Comments in the past 3 months :-)

Besides, I'm not sure if it is actually a publically readable document: the version on the SC34 website (document #980) is locked and I'm not authorized to download it: DIS29500-2008-002.pdf

There's some meta-info about the document by Rick Jelliffe here: Interestingly, Jelliffe wrote:

There is a small chunk of comments that are out of scope (typically concerning IPR or procedural comments.) There is a small chunk which the Editor has decided are issues for the maintenance phase, not the fast-track process: these are typically how comments like âoeODF has feature X, why doesnâ(TM)t OOXML support it?â There is another chunk of issues where the Editor disagrees with the substance of the comment, but wants to address the issue by adding clarifying or helpful text to the specification: for example, the issue of bitmasks is handled by giving examplars of how to handle them in XSD, RELAX NG, Schematron, DTLL and XSLT.. And finally, another chunk where the Editor disagrees, and gives the rationale for the disagreement. These are typically where the comments cross ECMAâ(TM)s line in the sand: that no currently valid OOXML document should become invalid.

So I say: go UKUUG! Sue their pants off! (and I'm not even a Brit).

If you want to see how bad was this process handled, see one of its awfuls deliverables.

Open the document "Response_DE-0028_dates_v9.doc" in this zip

http://www.itscj.ipsj.or.jp/sc34/open/0989_reference_docs.zip

This is one of the changes frenetically accepted in BRM, regarding treatments of dates in OOXML. See the salad of colors trying to explain the modifications. And this is a fix ( BRM ) of a fix ( one of ECMA 1027 proposed fixes ) of a NB comment of a draft text ( original ECMA submission ).

And this document contradicts this another BRM document: http://www.itscj.ipsj.or.jp/sc34/open/0989.pdf because the first says that the .DOC file replaces ECMA responses 18 and 43 but the "Response_DE-0028_dates_v9.doc" document says that it replaces ECMA responses 18, 43, 76 and 690 !

ECMA and Microsoft have not provided a final text with all this changes applied. In the BRM they frenetically changed Scope, Conformance , Schemas , and lot of normative text. Microsoft is now rushing to get a final text in less than one month, to comply with ISO normative.

This is how ISO delivers IT international standards, mandating fundamental changes to drafts, leaving national bodies with the only alternative to cast a political vote leaving aside the technical content of the specification.

Congratulations to the countries that had *balls* and didn't agree with this way of deliver standards to people:

• New Zealand ( dissaproved )
• Brasil ( dissaproved )
• India ( dissaproved )
• China ( dissaproved )
• South Africa ( dissaproved )
• Canada ( dissaproved )
• Venezuela ( dissaproved )
• Ecuador ( dissaproved )
• Iran ( dissaproved )
• Italy ( abstained )
• Spain ( abstained )
• Belgium ( abstained )
• Netherlands ( abstained but only Microsoft opposed the disapproval )
• France ( abstained due to heavy Microsoft pressure )
• Malaysia ( abstained due to heavy Microsoft pressure )
• Australia ( abstained due to heavy Microsoft pressure, government opposed OOXML )
• Kenya ( abstained )

And congratulations Microsoft, your friendly little countries supposedly experts in XML document description languages ;-) ( now ISO P-members ), who joined ISO JTC1 just to cast an unconditional-yes-votes payed off:

• Jamaica
• Cyprus
• Malta
• Kazakhstan
• Lebanon
• Azerbaijan
• Cote-d'Ivore
• Pakistan

If you want to see how bad was this process handled, see one of its awfuls deliverables.

Open the document "Response_DE-0028_dates_v9.doc" in this zip

http://www.itscj.ipsj.or.jp/sc34/open/0989_reference_docs.zip

This is one of the changes frenetically accepted in BRM, regarding treatments of dates in OOXML. See the salad of colors trying to explain the modifications. And this is a fix ( BRM ) of a fix ( one of ECMA 1027 proposed fixes ) of a NB comment of a draft text ( original ECMA submission ).

And this document contradicts this another BRM document: http://www.itscj.ipsj.or.jp/sc34/open/0989.pdf because the first says that the .DOC file replaces ECMA responses 18 and 43 but the "Response_DE-0028_dates_v9.doc" document says that it replaces ECMA responses 18, 43, 76 and 690 !

ECMA and Microsoft have not provided a final text with all this changes applied. In the BRM they frenetically changed Scope, Conformance , Schemas , and lot of normative text. Microsoft is now rushing to get a final text in less than one month, to comply with ISO normative.

This is how ISO delivers IT international standards, mandating fundamental changes to drafts, leaving national bodies with the only alternative to cast a political vote leaving aside the technical content of the specification.

Congratulations to the countries that had *balls* and didn't agree with this way of deliver standards to people:

• New Zealand ( dissaproved )
• Brasil ( dissaproved )
• India ( dissaproved )
• China ( dissaproved )
• South Africa ( dissaproved )
• Canada ( dissaproved )
• Venezuela ( dissaproved )
• Ecuador ( dissaproved )
• Iran ( dissaproved )
• Italy ( abstained )
• Spain ( abstained )
• Belgium ( abstained )
• Netherlands ( abstained but only Microsoft opposed the disapproval )
• France ( abstained due to heavy Microsoft pressure )
• Malaysia ( abstained due to heavy Microsoft pressure )
• Australia ( abstained due to heavy Microsoft pressure, government opposed OOXML )
• Kenya ( abstained )

And congratulations Microsoft, your friendly little countries supposedly experts in XML document description languages ;-) ( now ISO P-members ), who joined ISO JTC1 just to cast an unconditional-yes-votes payed off:

• Jamaica
• Cyprus
• Malta
• Kazakhstan
• Lebanon
• Azerbaijan
• Cote-d'Ivore
• Pakistan

http://www.itscj.ipsj.or.jp/sc34/open/0989_reference_docs.zip

If you want to see how bad was this process handled, see one of its awfuls deliverables.

Open the document "Response_DE-0028_dates_v9.doc" in this zip

http://www.itscj.ipsj.or.jp/sc34/open/09891.pdf

This is one of the changes frenetically accepted in BRM, regarding treatments of dates in OOXML. See the salad of colors trying to explain the modifications. And this is a fix ( BRM ) of a fix ( one of ECMA 1027 proposed fixes ) of a NB comment of a draft text ( original ECMA submission ).

ECMA and Microsoft have not provided a decent final text with all this changes applied. In the BRM they frenetically changed Scope, Conformance , Schemas , and lot of normative text. Microsoft is now rushing to get a final text in less than one month, to comply with ISO normative.

This is how ISO delivers IT international standards, mandating fundamental changes to drafts, leaving national bodies with the only alternative to cast a political vote leaving aside the technical content of the specification.

Congratulations to the countries that have balls and didn't agree with this way of deliver standards to people:

• New Zealand ( dissaproved )
• Brasil ( dissaproved )
• India ( dissaproved )
• China ( dissaproved )
• South Africa ( dissaproved )
• Canada ( dissaproved )
• Venezuela ( dissaproved )
• Ecuador ( dissaproved )
• Iran ( dissaproved )
• Italy ( abstained )
• Spain ( abstained )
• Belgium ( abstained )
• Netherlands ( abstained but only Microsoft opposed the disapproval )
• France ( abstained due to heavy Microsoft pressure )
• Malaysia ( abstained due to heavy Microsoft pressure )
• Australia ( abstained due to heavy Microsoft pressure )
• Kenya ( abstained )

• Jamaica
• Cyprus
• Malta
• Kazakhstan
• Lebanon
• Azerbaijan
• Cote-d'Ivore
• Pakistan

First laptop by Sun? I thought they re-sold something like the SPARC LC in the early 90's: http://www.ipsj.or.jp/katsudou/museum/computer/513 0_e.html

...this abstract for you.

It seems to address what you want, but is fairly recent! This means that solutions might not exist in the wild yet!!!

However, its very recentness also indicates that the issues it addresses (and you are trying to address) are still of very real significance in existing technologies.

So either all's well thanks to this solution, or you'll have to roll your own.