Deutsche Welle news article on Raspberry Pi - "Raspberry Pi and the new computer science kids"

perl definitely is.

formatting link

--
Today is Boomtime, the 49th day of Discord in the YOLD 3179 
           "Jesus died for somebody's sins, but not mine"
Reply to
Huge
Loading thread data ...

I don't realy expect any code I write to still be running in 7987 years time, and I rather think that if it is - it'll be someone elses problem.

-Paul

--
http://paulseward.com
Reply to
LP

All interpretive languages could/should have an 'eval' equivalent.

--
(\__/)  M. 
(='.'=) If a man stands in a forest and no woman is around 
(")_(") is he still wrong?
Reply to
Mark

It's people like you that caused Y2K.

deKay

--
  Lofi Gaming - http://lofi-gaming.org.uk 
  Gaming Diary - http://lofi-gaming.org.uk/diary 
  Blog - http://lofi-gaming.org.uk/blog 
  My computer runs at 3.5MHz and I'm proud of that
Reply to
deKay

That's a bit of an oversimplification. Assuming you can pass *any* expression to EVAL (i.e. one involving variables and not just constants) an additional requirement is that variable names are preserved in the run environment. That may not be true for all interpreted languages since, in the same way that keywords are often 'tokenised', variable names may be modified or shortened for performance reasons.

In the specific case of BBC BASIC, EVAL will work if the program is simply run in the interactive environment, since variable names are preserved. But if any kind of 'crunch' operation is performed, in which variable names are abbreviated, (and that's the default in BB4W when 'compiling' to an executable) EVAL cannot be expected to work. BB4W provides a compiler directive (REM!Keep) specifically for the purpose of specifying variable names that should not be abbreviated.

Richard.

formatting link

Reply to
Richard Russell

The ISO 8601 format (ccyy-mm-dd hh:mm:ss) is better because its a recognised standard.

I'm not so sure. If the hardware your program is running on can't handle a change of century, then its a bit hard to blame a programmer or systems designer.

So, I'd blame the makers of real time clocks that worked in decimal dates rather than offsets from a base date (e.g. amongst others, the people who designed the hardware clocks in IBM mainframes and those in almost all microcomputers (with both Intel and Motorola chipsets) because every one of those I've used only allowed two digits for the year.

Add in CODASYL, which specified that COBOL's "ACCEPT" statement could

*only* accept a date into a 6 digit date (yymmdd). That limitation was written into COBOL-84 and so was in force when much of the Y2K non- compliant code was written. If the programming environment has this sort of limitation it takes an exceptional designer to look past it and specify a set of programs that not only can deal with a 4 digit year, but can correctly roll over century ends and do correct date arithmetic as well. If you add in the thought that many systems being designed and implemented up to the early 1980s had a design life of under 10 years, you can see that there was very little incentive to think about Y2K and, if you did, you might well be shot down over the extra programming and storage costs that would involve.

FWIW, at the time I was using ICL 1900 and 2900 mainframes.

The 1900 stored dates as days since 31/12/1899 in a signed 24 bit word. This would have overflowed around August, 24866.

Its successor, the ICL 2900, held its date and time as microseconds from, midnight, 31/12/1899 in a signed 64 bit counter. This would only overflow after 584500 years.

While I was working on ICL kit I wasn't ever required to design or implement anything which used more than two year digits until 1982, when we built the Radio 3 music planning system, and that system only had a 4 digit year requirement because it needed to hold dates, such as a composer's birth and death of when a work was composed, from 55BC onward, so it could easily deal with any date up to 31/12/9999.

--
martin@   | Martin Gregorie 
gregorie. | Essex, UK 
org       |
Reply to
Martin Gregorie

I must be the only one who got the subtle joke. Count the y's in the date format above. :-)

bill

--
Bill Gunshannon          |  de-moc-ra-cy (di mok' ra see) n.  Three wolves 
billg999@cs.scranton.edu |  and a sheep voting on what's for dinner. 
University of Scranton   | 
Scranton, Pennsylvania   |         #include
Reply to
Bill Gunshannon

Fair cop, guv. I've see a few too many ccyymmdd (sortable, minimum size) date strings to bother counting the whys.

--
martin@   | Martin Gregorie 
gregorie. | Essex, UK 
org       |
Reply to
Martin Gregorie

On 2 May 2013 08:10:33 GMT, Huge declaimed the following in comp.sys.raspberry-pi:

REXX -- it's the core of the common "rexxtry" utility; though it's more blatantly explanatory:

interpret "some string representing code"

Python has exec as a statement and eval as a function (eval expects an /expression/ and returns the result; exec expects complete statements).

Python's exec would be the match to REXX interpret.

--
	Wulfraed                 Dennis Lee Bieber         AF6VN 
        wlfraed@ix.netcom.com    HTTP://wlfraed.home.netcom.com/
Reply to
Dennis Lee Bieber

This seems relevant:

(text taken from )

There was once a COBOL programmer in the mid to late 1990s. For the sake of this story, we'll call him Jack. After years of being taken for granted and treated as a technological dinosaur by all the UNIX programmers and Client/Server programmers and website developers, Jack was finally getting some respect. He'd become a private consultant specializing in Year 2000 conversions. He was working short-term assignments for prestige companies, traveling all over the world on different assignments, and making more money than he'd ever dreamed of.

He was working 70 and 80 and even 90 hour weeks, but it was worth it. Soon he could retire. Several years of this relentless, mind-numbing work had taken its toll on Jack. He had problems sleeping and began having anxiety dreams about the Year 2000. It had reached a point where even the thought of the year 2000 made him nearly violent. He must have suffered some sort of breakdown, because all he could think about was how he could avoid the year 2000 and all that came with it. Jack decided to contact a company that specialized in cryogenics. He made a deal to have himself frozen until March 15th, 2000. This was a very expensive process and totally automated. He was thrilled. The next thing he would know is he'd wake up in the year 2000; after the New Year celebrations and computer debacles; after the leap day--nothing else to worry about except getting on with his life. He was put into his cryogenic receptacle, the technicians set the revive date, he was given injections to slow his heartbeat to a bare minimum, and that was that. The next thing that Jack saw was an enormous and very modern room filled with excited people. They were all shouting, "I can't believe it!" and "It's a miracle" and "He's alive!". There were cameras (unlike any he'd ever seen) and equipment that looked like it came out of a science fiction movie.

Someone who was obviously a spokesperson for the group stepped forward. Jack couldn't contain his enthusiasm. "It is over?" he asked. "Is 2000 already here? Are all the millennial parties and promotions and crises all over and done with?"

The spokesman explained that 2000 had gone, but that there had been a problem with the programming of the timer on Jack's cryogenic receptacle - it hadn't been year 2000 compliant, and it was now March 15th of 9999, not

2000. But the spokesman told Jack that he shouldn't get excited as someone important wanted to speak to him.

Suddenly a wall-sized projection screen displayed the image of a man that looked very much like Bill Gates. This man was Prime Minister of Earth. He told Jack not to be upset, that this was a wonderful time to be alive--that there was world peace and no more starvation--that the space programmed had been reinstated and there were colonies on the moon and on Mars-that technology had advanced to such a degree that everyone had virtual reality interfaces which allowed them to contact anyone else on the planet, or to watch any entertainment, or to hear any music recorded anywhere.

"That sounds terrific," said Jack. "But I'm curious. Why is everybody so interested in me?" "Well," said the Prime Minister. "The Year 10000 is just around the corner, and it says in your files that you know COBOL".

--Anonymous

// Christian

Reply to
Christian Brunschen

No, that is the "extended format"; the "basic format" doesn't have the separators (at least in the date part), so Walter is correct.

Reply to
tony van der Hoff

Maybe. You're referring to languages that have a compilation step and also use an interpreter. When I refer to an interpretative language I meant one that does not use any compilation.

--
(\__/)  M. 
(='.'=) If a man stands in a forest and no woman is around 
(")_(") is he still wrong?
Reply to
Mark

In comp.sys.raspberry-pi message , Thu, 2 May 2013 21:22:19, Martin Gregorie posted:

The ICL 1905 processor unit had a feature which I believe the rPi lacks: a compartment in which the engineer (Wally Pellatt, IIRC) could keep his lunch.

24867-03-24 Thu - 2^23 days from 1899-12-31

If one uses the Julian Calendar, that date apparently becomes

24866/10/02.
--
 (c) John Stockton, nr London, UK.   E-mail, see Home Page.    Turnpike v6.05. 
 Website   - w. FAQish topics, links, acronyms 
 PAS EXE etc. :  - see in 00index.htm 
 Dates - miscdate.htm estrdate.htm js-dates.htm pas-time.htm critdate.htm etc.
Reply to
Dr J R Stockton

YES!!!!

--
martin@   | Martin Gregorie 
gregorie. | Essex, UK 
org       |
Reply to
Martin Gregorie

However, it was a little bigger than an RPi in a Wafer 'enclosure' and had an enclosed space.

I never used a 1905 - only 1901, 1902, 1903S and 1904T

OK, since its you saying so.

Thanks for that: I only did a rough calculation on my HP28S and got

24966.75 ( 2^23 / 365.25 = 22966.7570157) from which I guesstimated August. I evidently misread the third digit.
--
martin@   | Martin Gregorie 
gregorie. | Essex, UK 
org       |
Reply to
Martin Gregorie

I'm not sure the term 'compilation' is appropriate for such a simple process as tokenising keywords or abbreviating variable names. But, yes, I'm talking about the common situation when the 'interpreter' or 'run-time engine' doesn't see exactly the original source code as entered by the user. That was true even of QBASIC.

Richard.

formatting link

Reply to
Richard Russell

Better to be safe than sorry. The code you write today and the assumption therein could be buried so far in the innards of the future's systems as to be unreachable. OTOH, computer using societies after that length of time are improbable.

--
Gambling with Other People's Money is the meth of the fiscal industry.  
 me -- in the spirit of Karl and Groucho Marx
Reply to
Walter Bushell

IIRC qbasic's DRAW command included a subset of eval.

--
?? 100% natural
Reply to
Jasen Betts

On Sat, 4 May 2013 05:41:24 -0700 (PDT), Richard Russell declaimed the following in comp.sys.raspberry-pi:

Yeah... I'd differentiate between mere tokenization, where the interpreter is still interpreting the original language syntax (most BASICs of the late 70s early 80s era [where the use of PEEK/POKE could produce self modifying code by changing the 1-byte operation token]) vs those that compile to an intermediate or pseudo-assembly language, and it is that pseudo-assembly language that then gets interpreted (classic Python, Java, P4-derivative Pascal systems [one could even hand-link Alcor Pascal as its object file format was ASCII])

--
	Wulfraed                 Dennis Lee Bieber         AF6VN 
        wlfraed@ix.netcom.com    HTTP://wlfraed.home.netcom.com/
Reply to
Dennis Lee Bieber

Yeah, technology will likely have collapsed again and we will be once more back to using stone tools. :-)

And RaspberryPi will be something you eat for desert.

bill

--
Bill Gunshannon          |  de-moc-ra-cy (di mok' ra see) n.  Three wolves 
billg999@cs.scranton.edu |  and a sheep voting on what's for dinner. 
University of Scranton   | 
Scranton, Pennsylvania   |         #include
Reply to
Bill Gunshannon

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.