Slashdot Mirror

... Pascal, whose sole flaw is using verbose keywords like "begin/end" instead of the concise "{ }".

ROTFL!

http://www.lysator.liu.se/c/bw...

Not really, the great firewall has bots designed to port scan the targets of outgoing connections, https://www.nsc.liu.se/~nixon/sshprobes.html

Most people don't care because they aren't even interested in computers.

If you talk about Slashdot readers then they have all read enough articles to know that open source itself doesn't provide a perfect protection against backdoors.
You also have to read the source to see that no backdoors are put in place, and you need to build the executable to make sure that the version you are running isn't built from a version of the source with backdoors in it.
Now, assume that a processor like this becomes as mainstream as Intel and AMD CPUs, do you really think it is impossible to manufacture an FPGA with backdoors?
For people to use the CPU it has to reach a stable point at some time. A stable CPU and a stable toolchain to build it will have a known layout and can be targeted with backdoors in the FPGA in the same way the CPU would have backdoors.

So knowing that it isn't sufficient to just have an open design but that you also need to verify the hardware, why just not just skip the open part and verify the hardware directly?
As a Slashdot reader you should at least have seen the reverse engineered 6502 visualizer. It is a much simpler CPU, but it has been reverse-engineered and its function is emulated in javascript with the transistors of the chip lit up. No room for backdoors there.
A similar analysis has been done for the M68000, I couldn't find the slides from the presentation on it I saw, but here is a pdf with a rough overview that doesn't go into as much detail.

Since you need to do that kind of analysis of the FPGA anyway it seems to me that the open source CPU part is more about "Not Invented Here" than about protecting against backdoors.
That means that most people who you would think would care. They like the idea of it, but not this implementation since it isn't the one they did themselves.

Pascal might be underrated but it doesn't matter. There is no place for Pascal in the modern programming world.

When I went to college, Pascal was the standard teaching language. I have studied it pretty thoroughly and I understand it pretty well.

Pascal was designed as a teaching language. There are features in Pascal that are stripped-down, and I think it was just to make the teaching easier. In particular, why must all goto labels be integers rather than strings? I'd much rather write goto cleanup_after_fatal_error than goto 1000. It was a tiny bit simpler to write a Pascal compiler because of this limitation.

If you know C and really want to understand why Pascal didn't win over C, get a copy of Software Tools in Pascal. Look at all the places they had to work around limitations in Pascal, and consider how to write similar code in C. In all the cases, I realized that they simply wouldn't have had a problem in C.

Also, after writing the above book, Brian Kernaghan wrote an essay Why Pascal Is Not My Favorite Programming Language and if you have rose-colored glasses for Pascal I suggest you read it.

C really is the king of the "third-generation languages". In its earliest form it had dangerously little type-checking, but in its modern form (where you use function prototypes so the compiler can check types) it has type checking similar to Pascal, with all the benefits that provides. And it has all the little things I appreciate, such as terminating a loop early using break. In Pascal, to terminate a loop early you needed to either clutter up the loop conditionals with an extra flag variable (early_exit or some such) or else you had to use goto to break out (with a numeric label target, of course).

"But wait," some of you are muttering. "I used to write Pascal programs and I remember using break..." No, you didn't used to write Pascal programs: you used to write Turbo Pascal programs. When Borland created Turbo Pascal they fixed all of the worst problems of Pascal, pretty much by just doing whatever C did first. I wrote a lot of Turbo Pascal and I liked it very much.

But this points out the biggest problem of Pascal: it was not well specified, and as a result it didn't work a lot of the time. Where a spec is weak, you tend to get different implementations doing different things, which is horrible for portability. The wonderful book Oh, Pascal! discusses the brokenness of the I/O in Standard Pascal, and the various ways that Pascal implementations work around the problem, and summarizes with Cooper's Law of Standards: "If it doesn't work, it doesn't stay standard."

For Pascal to have a niche, it should do something a lot better than C, for it is C that it needs to displace. But IMHO there really isn't anything it does very much better than C, and there are numerous areas where it's a non-starter unless it copies features from C.

Given the massive installed base of C, C isn't going anywhere, and that leaves no room for Pascal; Pascal does the same sort of things as C does, but not as well.

Word for word this short essay served to improve my coding more than any other document, and not just in C. Most of the essay is applicable to any language. Pike elegently and concisely explains the most important principles of good code style and software architecture. The sections "Programming with data" and "Function pointers" are particularly sailent. The section "Complexity", also known as "Rob's Rules", is outstanding and ought to be burned into the brain of every software developer. It's a free online classic and I'm surprised it hasn't been mentioned yet. http://www.lysator.liu.se/c/pi...

Look, if they really didn't care you would have opened /. one day and found yourself staring at what is presently called Beta. No warnings, no "beta" period, just a sudden change.

My guess is that they're doing it this way to make sure that all the bugs are caught and fixed before they make the complete changeover. That's probably why they're asking for feedback: if anything isn't working the way they think it should, they want to find out. What they don't want, if my suspicions are correct, is users telling them that the new format has a Lovelace value of several hundred million, meaning that it can suck exoplanets down nanotubes.

Breaking DES with side-channel attacks

This lab will demonstrate how power analysis of cryptographic hardware can reveal the key. We will be using basic electronic measurement tools such as oscilloscopes to demonstrate this side-channel attack.

You will be using a small hardware board (fig. 1) with a generic microprocessor programmed to perform DES encryption and decryption. The scenario is that you are the attacker and want to find out the secret key stored inside the board. There is no way of getting to the key directly, so you will need to perform a side-channel attack by measuring the power consumption of the board while the algorithm is running. The hardware board also allows the user to load a custom key in order to compare the power consumption.

Hey, I'm the author of that lab instruction. How on earth did you find this humble little document? :)

There have been other attacks previous discussed here as I recall, such as using power fluctuations or timing attacks, and so on, as cribs to retrieve a key. It appears this sort of attack that exploits the characteristics of the system performing the encryption will continue to be an attack vector of growing importance.

Timing Attacks on Implementations of Diffie-Hellman, RSA, DSS, and Other Systems

Abstract. By carefully measuring the amount of time required to perform private key operations, attackers may be able to find fixed Diffie-Hellman exponents, factor RSA keys, and break other cryptosystems. Against a vulnerable system, the attack is computationally inexpensive and often requires only known ciphertext. Actual systems are potentially at risk, including cryptographic tokens, network-based cryptosystems, and other applications where attackers can make reasonably accurate timing measurements. Techniques for preventing the attack for RSA and Diffie-Hellman are presented. Some cryptosystems will need to be revised to protect against the attack, and new protocols and algorithms may need to incorporate measures to prevent timing attacks.

Breaking DES with side-channel attacks

This lab will demonstrate how power analysis of cryptographic hardware can reveal the key. We will be using basic electronic measurement tools such as oscilloscopes to demonstrate this side-channel attack.

You will be using a small hardware board (fig. 1) with a generic microprocessor programmed to perform DES encryption and decryption. The scenario is that you are the attacker and want to find out the secret key stored inside the board. There is no way of getting to the key directly, so you will need to perform a side-channel attack by measuring the power consumption of the board while the algorithm is running. The hardware board also allows the user to load a custom key in order to compare the power consumption.

And to think that there were people poopooing NSA for pulling cables and servers that Snowden had access to. More attack vectors for everybody!

The technology inside Apple’s $50 Thunderbolt cable

A source within the telecom industry explained to Ars that active cables are commonly used at data rates above 5Gbps. These cables contain tiny chips at either end that are calibrated to the attenuation and dispersion properties of the wire between them. Compensating for these properties "greatly improves the signal-to-noise ratio" for high-bandwidth data transmission.

Procedural city building like this was done back on the Peter Jackson "King Kong" back in 2005 by Joe Letteri.

They called their system "CityBot - Urban Development System"
Using this system they were able to create "...over 90,000 3D digital buildings..." out of "...22 million components..."

Article by Chris White @ Weta Digital:
http://staffwww.itn.liu.se/~andyn/courses/tncg08/sketches06/sketches/0147-white.pdf

Duff's Device in C is "clever," not elegant.

When the inventor himself describes it as follows (scroll down to his original 1983 email), it's generally safe to assume it's not "elegant":

Disgusting, no? But it compiles and runs just fine. I feel a combination of pride and revulsion at this discovery. If no one's thought of it before, I think I'll name it after myself.

He found a clever way to implement something in C to speed up some time-sensitive animation tasks... that does not make it an 'elegant' solution.

It's not a FRAUD ALERT, it's a Slashdot editor ignorance alert. Slashdot editors once ran a story about some method of file compression that was far better than the ones we currently have. Slashdot editors ran a story about cell phone radiation causing chemical changes. There have been articles about "breakthroughs" by Israeli companies wanting investors. All were quickly shown to be dishonest.

Comment to the L.A. Times story by Tython at 8:59 AM April 22, 2012: "This 'hypothesis' is full of holes?"

From the abstract of the "scientific" article: "Our large brain, long life span and high fertility are key elements of human evolutionary success and are often thought to have evolved in interplay with tool use, carnivory and hunting." Translation: We already believe!

Guess: The Swedish Research Council got money from meat producers to counteract an earlier study: Meat Production and Climate Change: an Ethical Investigation.

Could you expand on the Pascal limitations things?

Allow me to just link to a demi-god:
Why Pascal is Not My Favorite Programming Language by Brian W. Kernighan,
http://www.lysator.liu.se/c/bwk-on-pascal.html

Whoooa! Not so fast there matey! I know this is not on the market, but it's a little further along than 'some research'. it won awards! It was planned to go into the Saab 9-5 until GM bought them and decided that it wasn't worth spending money on forward thinking technology. Yeah, well done.

Anyway, the Saab variable compression ratio engine, very do-able:
http://www.fs.isy.liu.se/Lab/SVC/data.html

A year or two ago everybody was happy with Gnome

Clearly, not everyone was as happy as you thought. Otherwise there wouldn't be so many people working on so many alternatives.

and now another kid on the block... what the hell went wrong?

Not a damn thing. You can use gnome 2.x until MATE is working well enough to replace it. It's really the same thing.

I for one don't understand why people get all emotionally attached to their old UI. I've used fvwm, twm, windowmaker, enlightenment, kde, gnome 1, gnome 2, xfce, unity, gnome shell (with extensions). Honestly I think these things just keep improving over time. But seriously. If you are a romantic masochist, just install the window manager that emulates the amiga workbench and be done with it.

They can't and there is nothing preventing TP from doing it himself right now. There are so many effective ways you could do it with any imagination at all in a peaceful, easy way.

That is so much bullshit.

If you had taken a minute or two to review the methods file, you would know that there is no method available to the average person that can guarantee death in all cases. All the reliable poisons are controlled; hanging, asphyxiation, and exsanguination by various means all run a serious risk of failure accompanied by permanent brain damage; very tall buildings are uncommon in many places, and firearms, if they are even available, require dexterity that may be beyond someone who is presumably seriously ill.

Mr. Pratchett has every reason to be concerned about this, especially since his disease will ultimately render him completely incapable of even recalling his original wish to die.

> hmm... did you miss the part where the guy also bitched that interpreted languages are "too slow"?

You know "the guy", happens to be Rob Pike, _the_ Rob Pike, co-author of the "Unix Programming Environment" classic? Also the "Practice of Programming" book and the co-creator of UTF-8. He also wrote one of the first C style guides: http://www.lysator.liu.se/c/pikestyle.html. I'd say he knows a thing or two about programming languages; especially C.

I thought it was pike.

"Pike is a dynamic programming language with a syntax similar to Java and C."

You seem confused. He said C++ is complex, not C, and he is entirely right.

Yes. Actually, Pike loves C. He has written a C compiler for Plan 9. The language he co-designed was C-like. And I don't remember the source, but I once read that he writes object-oriented in C, using structures and pointers!

I'm not sure about which Pascal we're talking about here, because the original Wirth's Pascal is horrible (see section 2.1) at string handling. ISO Pascal "fixed" it in a very half-assed way. Turbo/Borland Pascal finally fixed that problem (in an entirely non-standard way), only to introduce another one, known as "255 characters is enough for everybody" (length of string was encoded as a single byte).

Other than that, GP is absolutely correct in that Pascal is just as low-level as C. For example, it also has pointers, including dangling ones. About the only other feature I can think of where Pascal is one step above is variant ("case") records - they're typesafe, unlike C unions; though, ironically, Turbo Pascal allowed them to be non-typesafe.

There's nothing funny about this. There's people starving. This isn't an idea solution, but at least it is one.

On a similar note, I know someone who distributes lockpicks and lockpicking manuals to the poor so they can get out of the cold at night. Where I live, there is lots of heated, unused space, and yet people are freezing outside. WTF?

I just hope they don't end up getting caught.

Out of curiosity, does anybody use Pike, at least outside of Scandinavia and Germany? I've only written toy programs in it, but it seems quite nice and to be pretty efficient. It's C-like, but with many of the nice features of dynamic languages. (Okay, I admit it, what I really like is that it allows binary literals.)

Ever heard of Tin Whiskers?

Also, cosmic rays and such can screw up memory if they happen to pass through the chip.

Besides that there are bad components on the motherboard that can affect memory as well. Bad capacitors, power regulators, defective interconnects. Lots and lots of things can cause memory errors.

You should check out Pike. Lot nicer than PHP and still has all of those things you mentioned.

http://www.ida.liu.se/~abdmo/SNDFT/docs/ram-soft.html

This references an IBM study, which is what I think I actually remember but could not find quickly this morning.

"In a study by IBM, it was noted that errors in cache memory were twice as common above an altitude of 2600 feet as at sea level. The soft error rate of cache memory above 2600 feet was five times the rate at sea level, and the soft error rate in Denver (5280 feet) was ten times the rate at sea level."

IBM research is a wonderful resource in the area of soft errors. I do remember exactly reading your quote, I didn't bother to track the exact article, but it should be part of this special issue http://www.research.ibm.com/journal/rd40-1.html, the banner article mentions Denver but doesn't have the exact quote. The web shows it would be "Terrestrial Cosmic Rays", the second article in that issue. They have a more recent special issue on the same subject http://www.research.ibm.com/journal/rd52-3.html

Second time I've posted this, but it's an interesting paper:

http://www.ida.liu.se/~abdmo/SNDFT/docs/ram-soft.html

http://www.ida.liu.se/~abdmo/SNDFT/docs/ram-soft.html

This references an IBM study, which is what I think I actually remember but could not find quickly this morning.

"In a study by IBM, it was noted that errors in cache memory were twice as common above an altitude of 2600 feet as at sea level. The soft error rate of cache memory above 2600 feet was five times the rate at sea level, and the soft error rate in Denver (5280 feet) was ten times the rate at sea level."

There are conflicting reports on that, apparently. This page gives a good overview of the subject, and has links to several scientific studies on the matter.

It also gives, if I read it correctly, an error rate of one bit flip per 14-142 years, varying with a number of factors including height above sea level and the specifics of the memory cell construction. Probably the error rate is towards the high end of that estimate. At the very least it can be said for certain that neither alpha particles nor cosmic rays are likely to be crashing your computer every week.

When was the last time you heard about a buffer overrun in Pascal?

When was the last time you heard about Pascal being used to make useful software, other than as a teaching language? That's not the greatest example you picked, as it has a lot of serious deficiencies. At least it's not Turing.

Defining classes in Perl is not easy, and I always have to go back to the manpage to make sure I've got all the incantations. Many times, I simply use object oriented structures and forgo the object definitions.

Why o' why does Python use "pop" for arrays, but not "push"? What were the designers on when they decided "exists" is not a member function of hashes -- excuse me -- dictionaries and arrays? Why this syntactic distortion of over 50 years of computer programming overturned?

I never liked Perl or Python, but graduated from sh to awk to Pike. It's not for everyone, but for people used to C syntax, it's a script language from heaven.

It's not very sexy, but it's fascinating and readable. I remember coming across it in Dillons bookshop, not knowing the name, and flicking through. Half an hour later, when I realised the time, I knew I had to buy it! Other books go into more exhausting detail (Knuth in particular), or cover a wider range (Knuth again!), or more modern ideas or languages. But Sedgewick is a great read, and I've been through it several times.

It covers all the basics (maths, searching, sorting, strings, graphs, and touches on FFTs and hardware and optimisation), and gives enough detail that you could go off and write some programs yourself. But more importantly, it explains them: how each algorithm works, what it's trying to achieve, how it behaves, and why. And it's because it explains the ideas so well that I'd recommend it. After every section I felt I'd learned something -- not because I had to, but for the sheer pleasure of understanding something new and interesting.

Other recommendations: Effective Java (a staggering amount of insight into the language), Thinking in Java (by someone who understands that language is more than just syntax), Deep C Secrets (again a pile of insight, interspersed with anecdotes and some rather off-the-wall diversions), Programming Pearls and More Programming Pearls (problem-solving in bite-sized chunks -- a little dated but still interesting). Plus I've already mentioned Knuth. K&R is well done, though narrow in scope. I find Design Patterns useful, but more for clarifying things I've already seen than for learning new things. I've never actually read The Mythical Man-Month, but people I respect mention it, so I'm sure it's well worth reading too!

Of course, times being what they are, especially in this field, a lot of interesting stuff is on-line. Some hat should go without saying hereabouts include the latest Jargon File, some of Eric Raymond's books, and more online documentation and archives than anyone but Google can cope with.

Other interesting articles include The Programmer's Stone, a guide to writing Unmaintainable Code, The Ten Commandments for C Programmers (annotated edition), Ken Thompson's Reflections on Trusting Trust, What Colour are your Bits?, and Guy Steele's Growing a Language.

Also as the "Go Text Protocol" http://www.lysator.liu.se/~gunnar/gtp/

A bit of googling leads to this PDF which I got from this link. These are more descriptive than the ZFS slide.

I haven't programmed in neither language and I can't tell code in Pike and code in C# apart. Is this just a superficial similarity or is it something more? I've never had the same trouble with all the other C-like languages.

However, I do know of a really good author, that is a "dead tree" author, for C: Herbert Schildt.

I used to recommend his books too, but he has a bad reputation among many developers:

Why do many experts not think very highly of Herbert Schildt's books?

A good answer to this question could fill a book by itself. While no book is perfect, Schildt's books, in the opinion of many gurus, seem to positively aim to mislead learners and encourage bad habits. Schildt's beautifully clear writing style only makes things worse by causing many "satisfied" learners to recommend his books to other learners.

Do take a look at the following scathing articles before deciding to buy a Schildt text.
http://www.lysator.liu.se/c/schildt.html
http://herd.plethora.net/~seebs/c/c_tcr.html

The above reviews are admittedly based on two of Schildt's older books. However, the language they describe has not changed in the intervening period, and several books written at around the same time remain highly regarded.

The following humorous post also illustrates the general feeling towards Schildt and his books.

http://www.qnx.com/~glen/deadbeef/2764.html

There is exactly one and ONLY one C book bearing Schildt's name on its cover that is at all recommended by many C experts - see Q 25.

See http://www.mai.liu.se/~jalar/qkg/faq.html?lang=en

Everybody who cares to look already knows that ODF is about IBM's business AND the pubic good.

Yeah, but.. " Microsoft executives have accused the rest of the world of leading the campaign against their initiative to have Office Open XML approved by the International Organization for Standardization. " doesn't have the right spin.

I've downloaded and looked at the MSOOXML spec and I thought it was some kind of insult. I seriously invite everyone who has ever read a spec, and who still doubts how bad this one really is, to download the 38 Mb PDF file from .. oh wait.. it's not there anymore.. now probably from ECMA-376 and you probably want the ZIP file "ECMA-376 part 4" (warning, 32 Mb) and also get the 2000+ pages of errata from ECMA which the countries have to read in the next 2 weeks before they get to have a final vote at the ballot resolution meeting.

You want the file titled "Office Open XML Part 4 - Markup Language Reference.pdf".

A copy of the 2200 page PDF file of criticisms can be downloaded from here.

Frankly, you can get a good laugh out of all the stuff about 1900 and 1904 date systems (response 43, I quote CH-0007

"Software bugs should be fixed, not exported by ISO standards to the programs of competitors."

) and the mathematically wrong CEILING function (response 30 p. 121),

But I believe this is the one "killer question" that the BRM should consider discussing for those 5 days: Response 31 on p. 122 (211) to questions BE-0001, CH-0013, CL-0001, DE-0119, KR-0001, NZ-0003, PE-0010, ZA-0003

Basically, AFAIK, the comments are "We already have ODF, why do we need OOXML?" and the proposed solutions are of the gist "Develop OOXML starting from ODF". This is ECMA's response:

Proposed Disposition

There are currently several XML-based document formats in use, each designed to address a different set of goals or requirements. These include ISO/IEC IS 26300 (ODF), China's UOF, and ECMA-376 (DIS 29500 Open XML). All these formats have numerous implementations in multiple tools and multiple platforms (Linux, Windows, Mac OS, hand-held devices).

The Ecma Response Document from the Fast Track 30-Day contradiction phase for DIS29500 addressed the question of harmonization by explaining the differences between the ODF and Open XML formats as follows:

"... one must recognize that creating a single "merged" format to address the user requirements of both ODF and OpenXML is a much more difficult goal--one that is hindered by fundamental obstacles comparable to what one might encounter while merging HTML and ODF or HTML and PDF. This is because of sheer difference of scope, feature and architecture. Ecma believes that one format cannot simultaneously meet the requirements that would come from the merge of the two formats and the stringent requirements of backward compatibility that drive the design of OpenXML.

First, while both formats share the high-level goal, to represent documents, presentations, and spreadsheets in XML, their low-level goals differ fundamentally. OpenXML is designed to represent the existing corpus of documents faithfully, even if that means preserving idiosyncrasies that one might not choose given the luxury of starting from a clean slate. In the ODF design, compatibility with and preservation of existing Office documents were not goals. Each set of goals is valuable; sacrificing either at the expense of the other may not be in the best interest of users.

Second, the resulting differences are not merely variances in scope that could be resolved by adding capabilities to one or the other. They are structural and architectural in nature

"Actually when I first learned of it in the late 70's I thought Pascal was a pretty cool and powerful language."

Being specifically designed for teaching structured programming concepts doesn't preclude a language from being powerful.

"At that time, Fortran IV was probably the language most people learned first (BASIC was starting to take hold too...)."

Wirth's goal with Pascal was to instil an awareness of structure in students who would be likely to spend their careers writing COBOL and FORTRAN code. His first successful implementation was in 1970 for a mainframe, and it was extremely rare in those days to find a high-level language other than COBOL or FORTRAN on any computer outside research establishments, so it was natural for him to assume that most of those who learned Pascal would end up coding in one of them.

"So in the context of the time, Pascal was (and still is) a perfectly reasonable general-purpose programming language. Maybe the general-purposeness of it might have hurt it more than anything else - it never was the best at anything (except perhaps enforced readability)"

Wirth Pascal had a number of deliberate restrictions that prevented it from being a practical vehicle for commercial software development. I suggest you read Brian Kernighan's criticism of it (when compared to his and Ritchie's C) for a reasonable overview of them that might help you understand why many programmers disliked it. You can find it at (among many other places) http://www.lysator.liu.se/c/bwk-on-pascal.html

NB: this is a fairly old paper, so most of the criticisms don't apply to modern Pascals such as FreePascal, which have been influenced by more practical implementations from the likes of Borland and Apple that specifically targeted applications programmers, and therefore both removed some of the restrictions that were only desirable from a didactic viewpoint, and clearly defined certain aspects of Pascal that were either not defined or ambiguous in the original specification.

On a final note, I much preferred both Modula-2 and the later Oberon to C or Pascal, but neither of them managed to gain much of a foothold in the industry despite the fact that both had amply demonstrated their capabilities as both systems and applications programming languages whilst at the same time managing to avoid many of C's pitfalls.

Between seven and eight figures, US dollars. It was very big business at the time. The cards sold for hundreds of dollars. Up to a million were sold. It was for a short time a very large market.

By contrast, how much money can a fraudster make defeating bank security? It should minimize the petty fraud, but not ellminate all fraud.

The typical phishing ring takes in much less than the pirate satellite gangs did in their prime. The largest phishing rings might come close to the satellite rings but I doubt that.

Losses due to Internet crime are large, profits to the criminals are much smaller and divided many ways. The vast bulk of the costs is caused by the petty fraud. Each phishing spam run costs a huge amount in customer service as people call up to enquire even if there is no actual monetary loss.

Put it this way, banks are all about making money. Why do you think improved security hasn't been implemented?

Well that is the subject of the two books, isn't it. The short form is that we are pretty good at deploying tactical security measures that have a short term effect, where the costs and benefits align. We are not so good at deploying strategic measures where the costs are not neatly aligned. In the case of Chip and PIN we need government action, we cannot deploy without it because of the anti-trust laws.

However I do know Pascal and to say Pascal is a broken language, when variants have been used with great success in niche markets is something I find hard to agree with. (eg. Borland Pascal compilers and then Delphi, also Miranda though not commercially).

All of which ignored the worst examples of Wirth's idiocy. For example the idea of typechecking the size of arrays. In ANSI Pascal an array of 4 integers is totally different from an array with 5. You cannot have a subroutine with a signature foo (int bar []). It has to be foo (int bar [4]). Try doing string handling libraries with that!

Kernighan pretty much nailed it in 1980 why Pascal is not my favorite language. I have used Borland Pascal quite a bit, back in the days it was just TurboPascal. It has much more in common with C than ANSI Pascal. It took me much longer to rewrite my programming class assignments in ANSI Pascal than it did to get them written in Turbo Pacal in the first place.

Sure you can make a decent-ish language using Pascal-like syntax. But the result is not Pascal. Back in the 80s we did a lot of things to make it possible to compile code on the 12 Mhz 16 bit PCs of the day. I don't see any value in inflicting them on student's today any more than punch cards and paper tape.

After not playing for quite some time, I got hooked on Nannymud again this year.

not entirely on-topic, but i figured the slashdot community might be interested in this tool.

OpenModelica

a very nice modelling package that can help you with practical mathematics issues like mathematica might.

cheers.

Peter

The Cray 1M was the first commercial system that I'm aware of that had an SSD option.

I was a sysop in the 1990s on a Cray Y-MP C916/12 512. Its SSD was a $2M option (guessing).

Here's a great photo of a Cray C90 with an SSD. The SSD is the smaller cabinet to the back of the girl. Both cabinets were liquid cooled, hence their small size.

Our Cray C90 had twelve central processing units (custom vector silicon) with a clock speed of 230 MHz and contained 512 megawords (4096 megabytes) of shared memory. It also had a 512 megaword Solid State storage Device (SSD). Its I/O subsystem also connected to a Cray 2 to handle all access to real disk - making that Cray 2 one of the most expensive disk controllers ever.

Though the vector CPUs were outmatched by newer systems, we continued to use the C90 into 1999 for oil exploration because of its incredible I/O throughput and ability to handle very large datasets (1GB) efficiently.

Back when, games had boxes and came with kick-ass posters.

I'm not sure I would trust a survey that has an obscure scripting language clocking in at 0.13% in the September 2007 results.

It seems that you forget that this fast-track is taking place in Wonderland

http://www.lysator.liu.se/c/bwk-on-pascal.html

I sincerely hope the language has been fixed since that was written...

"The first thing I'd like are some of my favorite features from Common Lisp, like first class functions, ability to do procedural, functional, and object oriented programming with the same language, dynamic typing, macros, closures, and lexical scoping.

Having a C-like syntax would be good for people who are used to C or Perl and don't want to learn about s-expressions. Automatic memory management is a must."

You just described pike (although it has both static and dynamic typing).
http://pike.ida.liu.se/

No, the moral of the story is to ignore Theo and rest of his merry bunch of clowns.

Disclaimer - I'm a paid-up member of the FSF (number 3000-and-something) but also have half a dozen OpenBSD CDs on the shelf, partly because I use OpenSSH and other of their code all the time, and partly because it's Free and Free is Good, and partly because I want to support a security-focussed software distribution.

they felt the need to virtualize that Linux-based OS under an RTOS.

The Prime 50 series used segment 07777, offset 0 for the null pointer, at least for PL/I. Later models used segment 0, offset 0 for null pointers in C, necessitating new instructions such as TCNP (Test C Null Pointer), evidently as a sop to all the extant poorly-written C code which made incorrect assumptions. Older, word-addressed Prime machines were also notorious for requiring larger byte pointers (char *'s) than word pointers (int *'s).

The Eclipse MV series from Data General has three architecturally supported pointer formats (word, byte, and bit pointers), two of which are used by C compilers: byte pointers for char * and void *, and word pointers for everything else.

Some Honeywell-Bull mainframes use the bit pattern 06000 for (internal) null pointers.

The CDC Cyber 180 Series has 48-bit pointers consisting of a ring, segment, and offset. Most users (in ring 11) have null pointers of 0xB00000000000.

The Symbolics Lisp Machine, a tagged architecture, does not even have conventional numeric pointers; it uses the pair (basically a nonexistent handle) as a C null pointer.

Depending on the "memory model" in use, 80*86 processors (PC's) may use 16 bit data pointers and 32 bit function pointers, or vice versa.

The old HP 3000 series computers use a different addressing scheme for byte addresses than for word addresses; void and char pointers therefore have a different representation than an int (structure, etc.) pointer to the same address would have.