Slashdot Mirror

It looks like you meant to write the traditional "cleanup code" example, but your pseudocode does not make sense. "close(resource1);" should only be done if it had been opened (when "a" was true), but you have it called based on "b", not "a".

The pattern you're looking for is

if (!(a = open("a"))) return;
if (!(b = open("b"))){
close(a); return;
}
if (!(c = open("c"))){
close(b); close(a); return;
} ...


Anyhow, gotos are still bad (from the academic standpoint that professors use).

The example of cleanup statements is an insufficient argument for allowing goto into a language. That problem can be solved with try/catch exception handlers, or final{} blocks, or even a special limited-goto which can only jump forward to the top-level of the same function.

A real goto statement, however, can do many more things that just jump to the postscript of a function. It can jump forwards, backwards, to/from the bodies of loops and other functions- in short, it can make your program enormously more difficult to understand, analyze, or optimize.

Djikstra alluded to the wisdom that goto should only be used for "alarm exits" or "abortion clauses". But restricting programmers to only use a feature in a few certain ways is less reliable than restricting the language to offer only safer, alternative features.

Daily Builds are for Wimps! And they only have one architecture to build for. Compare for example Mozilla's Tinderbox.

First GOTO and now CGI. Why doesn't someone call C evil so we can call it a night

yx; double u, b, tmin, sqrt(), tan(); double vdot(A, B) vec A, B; { return A.x*B.x + A.y*B.y + A.z*B.z; } vec vcomb(a, A, B) double a; vec A, B; { B.x += a*A.x; B.y += a*A.y; B.z += a*A.z; return B; } vec vunit(A) vec A; { return vcomb(1./sqrt(vdot(A, A)), A, black); } struct sphere *intersect(P, D) vec P, D; { best = 0; tmin = 1e30; s = sph+NSPHERE; while (s-->sph) b = vdot(D, U = vcomb(-1., P, s->cen)), u = b*b-vdot(U, U)+s->rad*s->rad, u = u>0 ? sqrt(u) : 1e31, u = b-u>TOL ? b-u : b+u, tmin = u>=TOL && u<tmin ? best = s, u : tmin; return best; } vec trace(level, P, D) vec P, D; { double d, eta, e; vec N, color; struct sphere *s, *l; if (!level--) return black; if (s = intersect(P, D)); else return amb; color = amb; eta = s->ir; d = -vdot(D, N = vunit(vcomb(-1., P = vcomb(tmin, D, P), s->cen))); if (d<0) N = vcomb(-1., N, black), eta = 1/eta, d = -d; l = sph+NSPHERE; while (l-->sph) if ((e = l->kl*vdot(N, U = vunit(vcomb(-1., P, l->cen)))) > 0 && intersect(P, U)==l) color = vcomb(e, l->color, color); U = s->color; color.x *= U.x; color.y *= U.y; color.z *= U.z; e = 1-eta*eta*(1-d*d); return vcomb(s->kt, e>0 ? trace(level, P, vcomb(eta, D, vcomb(eta*d-sqrt(e), N, black))) : black, vcomb(s->ks, trace(level, P, vcomb(2*d, N, D)), vcomb(s->kd, color, vcomb(s->kl, U, black)))); } main() { printf("%d %d\n", SIZE, SIZE); while (yx<SIZE*SIZE) U.x = yx%SIZE-SIZE/2, U.z = SIZE/2-yx++/SIZE, U.y = SIZE/2/tan(AOV/114.5915590261), U = vcomb(255., trace(DEPTH, black, vunit(U)), black), printf("%.0f %.0f %.0f\n", U); }

I highly recommend that you:
1) Spend some time training end users how to use basic tasks such as GUI stuff (copying files, moving windows) then try office apps (word processors, spreadsheets) and you will be amazed. Alternatively, take a good course on user interface design, or Medical Informatics. The average user cannot recognize something as a check box, unless it the same as the ones they know. Even bits of shading and color can make them unable to recognize the screen as anything other than colors. It just "looks to complicated" and they turn off their brains.

Apple realized this long ago. MS hasn't (hence, Windows XP was born). There are a great many articles available at the ACM Digital Library regarding user interface design and experiments. There are certain user interface rules are that pretty much accepted as fact, since they have so much research behind them. Apple is very consistent at following them, which is why people think Apples aer easy to use, even though most techies look at them as really being the same. It's the subtleties that we don't see. A quick list from my memory:

- Dynamic menus are always slower than static menus
(You know the rearranging menus in Office 2000/Windows 2000?)
- Vertical scrolling is easier than horizontal scrolling
- Multimodal interfaces are faster if they are properly paired
(Ex: Keyboard=okay, Mouse+Keyboard = excellent, Joystick+Keyboard=bad)
- Consistency is more important than feature set

I highly recommend that you:
1) Spend some time training end users how to use basic tasks such as GUI stuff (copying files, moving windows) then try office apps (word processors, spreadsheets) and you will be amazed. Alternatively, take a good course on user interface design, or Medical Informatics. The average user cannot recognize something as a check box, unless it the same as the ones they know. Even bits of shading and color can make them unable to recognize the screen as anything other than colors. It just "looks to complicated" and they turn off their brains.

Apple realized this long ago. MS hasn't (hence, Windows XP was born). There are a great many articles available at the ACM Digital Library regarding user interface design and experiments. There are certain user interface rules are that pretty much accepted as fact, since they have so much research behind them. Apple is very consistent at following them, which is why people think Apples aer easy to use, even though most techies look at them as really being the same. It's the subtleties that we don't see. A quick list from my memory:

- Dynamic menus are always slower than static menus
(You know the rearranging menus in Office 2000/Windows 2000?)
- Vertical scrolling is easier than horizontal scrolling
- Multimodal interfaces are faster if they are properly paired
(Ex: Keyboard=okay, Mouse+Keyboard = excellent, Joystick+Keyboard=bad)
- Consistency is more important than feature set

This isn't about supporting Microsoft's business model. This is about being able to have the NSA tell Microsoft to stick back doors into its software, making it easier to conduct surveillance. (Also see here.)

If foreign governments switch to free software, the U.S. will have to try the ol' gcc backdoor maneuver, which may be harder now with all the md5 sums and digital signatures.

From the article: The best comparison table is apparently still the GUI Toolkit, Framework Page. Which is the best cross-platform GUI toolkit that provides native look and feel? Which is the best overall? What IDEs and other tools do you use? What are the problems?

GUI toolkits and IDEs could be exploited if widely used.

Ken Thompson who we all know and love from UNIX lore has written Reflections on Trusting Trust which describes just this problem.

Imagine that you insert a backdoor into a compiler, so that everything the compiler compiles is trojaned. If the compiler detects that it is recompiling itself, it quietly reinserts the trojan code. The actual source code to the trojan might be wiped out, but as long as you are running infected binaries, it will keep popping up again and again.

From the paper: "First we compile the modified source with the normal C compiler to produce a bugged binary. We install this binary as the official C. We can now remove the bugs from the source of the compiler and the new binary will reinsert the bugs whenever it is compiled. Of course, the login command will remain bugged with no trace in source anywhere."

A very interesting read.

From the article: Michelin (the tire manufacturer) has announced that it is planning on embedding RFID transmitters into every tire. The article states that 'the microchip stores the tire's unique ID, which can be associated with the vehicle identification number.' Let the privacy invasion begin!

Ken Thompson who we all know and love from UNIX lore has written Reflections on Trusting Trust which describes just this problem.

Imagine that you insert a backdoor into a compiler, so that everything the compiler compiles is trojaned. If the compiler detects that it is recompiling itself, it quietly reinserts the trojan code. The actual source code to the trojan might be wiped out, but as long as you are running infected binaries, it will keep popping up again and again.

From the paper: "First we compile the modified source with the normal C compiler to produce a bugged binary. We install this binary as the official C. We can now remove the bugs from the source of the compiler and the new binary will reinsert the bugs whenever it is compiled. Of course, the login command will remain bugged with no trace in source anywhere."

A very interesting read.

From the story: 'One minute you're looking out your bay window at your neighbor's back yard, and the next you're watching Tom Cruise and 'Top Gun''."

Ken Thompson who we all know and love from UNIX lore has written Reflections on Trusting Trust which describes just this problem.

Imagine that you insert a backdoor into a compiler, so that everything the compiler compiles is trojaned. If the compiler detects that it is recompiling itself, it quietly reinserts the trojan code. The actual source code to the trojan might be wiped out, but as long as you are running infected binaries, it will keep popping up again and again.

From the paper: "First we compile the modified source with the normal C compiler to produce a bugged binary. We install this binary as the official C. We can now remove the bugs from the source of the compiler and the new binary will reinsert the bugs whenever it is compiled. Of course, the login command will remain bugged with no trace in source anywhere."

A very interesting read.

From the story: This has got me thinking - why should we pay large amounts of cash for authorized certs when so little is done by the companies issuing them? Sure they get you to send them a copy of a business certificate but how does this prove the character of those running the SSL server?

Ken Thompson who we all know and love from UNIX lore has written Reflections on Trusting Trust which describes just this problem.

Imagine that you insert a backdoor into a compiler, so that everything the compiler compiles is trojaned. If the compiler detects that it is recompiling itself, it quietly reinserts the trojan code. The actual source code to the trojan might be wiped out, but as long as you are running infected binaries, it will keep popping up again and again.

From the paper: "First we compile the modified source with the normal C compiler to produce a bugged binary. We install this binary as the official C. We can now remove the bugs from the source of the compiler and the new binary will reinsert the bugs whenever it is compiled. Of course, the login command will remain bugged with no trace in source anywhere."

A very interesting read.

You're making a joke, but the problem you mention is actually a serious one. Ken Thompson who we all know and love from UNIX lore has written Reflections on Trusting Trust which describes just this problem.

Imagine that you insert a backdoor into a compiler, so that everything the compiler compiles is trojaned. If the compiler detects that it is recompiling itself, it quietly reinserts the trojan code. The actual source code to the trojan might be wiped out, but as long as you are running infected binaries, it will keep popping up again and again.

From the paper: "First we compile the modified source with the normal C compiler to produce a bugged binary. We install this binary as the official C. We can now remove the bugs from the source of the compiler and the new binary will reinsert the bugs whenever it is compiled. Of course, the login command will remain bugged with no trace in source anywhere."

A very interesting read.

I seem to remember seeing something like this in a gadget-oriented genre, like a Bond film, for maps. It's a pretty cool idea, since it's not much different than using a magnifying lens.

In fact, when you think about it, this is a real-world application of a virtual device that implements a real-world tool. Check out The Movable Filter as a User Interface Tool : essentially a magnifying lens with "logical filters". Now that's been moved back into the real world again.

Who needs new ideas when there are so many good ones that haven't been used already?

Found here. Although this might not be what you were talking about. Its a speech done by Ken Thompson and it was about theoreticaly trojaning all software by trojaning the compiler. As far as I recall this was never actually used or anything. Now that I think of it though, I think I do recall something about login being trojanned. Nope its in that paper (check google and the 2nd link was to it).

Go To Statement Considered Harmful, by Edsger W. Dijkstra. Reprinted from Communications of the ACM, Vol. 11, No. 3, March 1968, pp. 147-148.

He also came up with the concept of database normal forms. A good way to remember the different normal forms is to have

The Key (1NF)

The Whole Key (2NF)

Nothing but the Key (3NF),
so help you Codd

(thanks to my CS prof for this statement)

SIGGRAPH is the very biggest research conference of anything.

Correction: SIGGRAPH is for graphics only because SIGGRAPH stands for Special Interest Group for Graphics. SIGGRAPH is one of ACM's special interest groups. There are a lot others like SIGPLAN (Programming Language), SIGKDD (Knowledge Discovery in Data), and so forth. Click here for details.

Don't forget that we still have IEEE and other independent research communities. They too make significant breakthrough although often unheard of.

What about the ACM? Doesn't that qualify as a "serious professional association" for IT workers?

Men and algoritms both tend to be judged by their fruits. This line from the article was probably the best argument for tossing out the technique at this point:

"There are no proficiency tests, there are no independent studies to say that this works or that it's reliable," Heyer said.

The same arguement would be made about absolutely any automated system for doing the same thing. Computers don't drive cars. Not because they *can't* drive cars, but because they can't do it better, or even as well, as humans.

Any algorithm written by a human being on a platform made by human beings ought to be just as suspect as a human being. If the basic algorithm were public knowledge and seperate open source implementations were created all with the same results on different platforms, then perhaps hard analysis could be brought against it. But a single implementation especially in poorly understood binary is subject to no such analysis.

This ACM classic on trusting trust does a great job of explaining one major loophole. How hard do you think it would be for a malicious coder to insert an algorithm that biased all results away from a specific set of prints?

As to software bias...
deviation of the expected value of a statistical estimate from the quantity it estimates

What is a data mining technique if not a synthetic statistical estimate? Bias in an alogorithm doesn't have to be about purposely favoring (or disfavoring) one outcome. Choose 10 completely different methods (or algorithms) for solving a particular problem (spam filtering would be a good example). Each solution to the problem will have different results even for the same input data. I would tend to call that difference a "bias". This bias would exist even with the most "trusted" algorithms and computing platforms.

But I sure couldn't be trusted with an image and expected to come up with a totally unbiased, objective enhancement of it.

Actually, if you were given a "rough print" you'd never seen before and had no idea what it was going to be matched against and had instructions only to "enhance" it, you might come up with something a lot less biased than you might think. As the technician stated himself, if he knew what he was trying to match against, it would be a lot harder to create an unbiased enhancement.

I'm saying [an algorithm] is more trustworthy, repeatable and does not introduce external variables

The algorithm itself *is* an external variable. The bigger and more complex it is, the more external variables it introduces. I'd argue about trustworthy, but I doubt we agree on the definitions of words like "trust" and "truth".

Resolution?

In the sense that an alogirthm in the right circumstances can be better understood than a human, and that a single algorithm could process more fingerprints than a single human, you may be correct that an algorithm could be more appropriate in something approaching an ideal situation. On different fingers, it should be quite plain that a human is vastly more capable than any set of algorithms yet contrived.

As to "enhancing" fingerprints in general. I have faith that our legal system can fully bung up either method. Human directed or computer controlled.

In the field of computer science, this problem is probably less pronounced. Several resources make it very easy to read papers, so access is not much of an issue. These resources include CiteSeer and the ACM Digital Library, which contain vast databases of computer science publications in electronic form.

Some of the top C# creators came from Borland

uh, duh.

The top C# and Delphi creator came from Borland

If someone set up a dedicated box for me, first thing I'd do is ssh in and change the root pass. Then you *know* they're not logging on.

Just playing devil's advocate here. :)

The moral is obvious. You can't trust code that you did not totally create yourself. (Especially code from companies that employ people like me.)

The story is absolutely true, and the perpetrator was Ken Thompson, co-creator of Unix. You can read all about it here.

However, take a look at Parnas' classic paper on information hiding. In it, he makes the following statement (emphasis mine):

The KWIC index system accepts an ordered set of lines, each line is an ordered set of words, and each word is an ordered set of characters. Any line may be "circularly shifted" by repeatedly removing the first word and appending it at the end of the line. The KWIC index system outputs a listing of all circular shifts of all lines in alphabetical order.

This is a small system. Except under extreme circumstances (huge data base, no supporting software), such a system could be produced by a good programmer within a week or two.

This paper was written 30 years ago. It only pre-dated Brooks by 5 years. In that time, if my estimate is accurate, the development time for simple programs may have fallen by a factor of a hundred or more.

Software doesn't appear to have improved in that time simply because we keep trying to do more complex things.

The "desktop" metaphor is getting increasingly outdated, but I haven't seen a really good overhaul yet. There are some links at this site, the most interesting of which is David Gelertner's LifeStreams.

Nothing about C#, but still a good related read. Reflections on Trusting Trust

You can still keep the system open by forcing the sender to spend a little bit of CPU time to send a message (e.g. finding a collision of a short hash function). The idea is explained at:

• http://www.acm.org/crossroads/columns/onpatrol/mar ch2001.html (search for spam)
• http://www.cypherspace.org/~adam/hashcash/

ACM's position on software engineering is that software engineers should not be licensed as professional engineers. Follow the link for lots of reasons.

My own opinion is that liability can exist without licensing. Companies working on safety-critical projects should be careful about people they pick to work for them. They should have adequate quality control procedures in place and should be held liable for negligent behavior. On top of that you could have regulation addressing specific safety concerns as you do for car and medical equipment manufacturers.

Pretty entertaining reading...

"More famously, there was a version of a very popular C compiler that would put in a back-door whenever it noticed itself compiling a common bit of Unix login code,"

Nope. This was a theoretical attack presented by Ken Thompson. It was never out in the wild, to the best of anyone's knowledge.

The point still remains that you can't trust code unless you can personally verify it at any level, because the moment you give any important code trust, the code can potentially use that as a way of subverting the entire system.

(This is taken from slashdot comments from awhile ago.)

So it must be true, right? ;-)

(Relax, I'm kidding. I don't doubt what you're saying. Your citation, however, cracked me up.)

More famously, there was a version of a very popular C compiler

"Reflections on Trusting Trust," Communications of the ACM, August '84. Read it here.

Unfortunatly, the Patent was issued in Dec 2000; the first time I heard this idea was the Paul Graham implementation in the last few months.

So, if this is all old hat to anyone out there, please do everyone a favor and find that prior art and let everyone know, so that, in 5 years when MS trys to enforce this patent, there is a defense.

------

I accidently posted this as an AC (score:0) so I am reposting it, but in the mean time another AC post claims to have some prior art. According to that AC This article (fixed link) may be helpful, I couldn't read it myself as the Full Text requires ACM membership. Perhaps somebody with access could take a look, and review it's potential applicability as prior art. (ie. Does it explicitly mention using baysian techniques to filter spam?)

Its Denis Ritchie

And he only might have done it (can you tell?)

See http://www.acm.org/classics/sep95/ for more details

Parent doesn't know what he's talking about. I'm a graphics expert and what he says is nonsense.

For instance (and I'm not going to do a point-by-point rebuttal), this paper describes the method for drawing curved surfaces on NV30, and it was developped in OpenGL first. NVidia has appropriate extensions to access these capabilities. So the comment about "arbitrary geometry ala (sic) postscript" is completely off the mark.

For what it's worth, I'm one of the NV30 developers.

As pointed out in the article, an employee of the slot machine manufacturer altered machines for payout.. this wouldnt happen if a secure computer system were to design the slot machine[...]

Even that wouldn't work; sorry.

I remember reading about this five or six years ago - it was called Lifestreams at the time, then later commercialized by a company called Mirror Worlds which now goes by the name Scopeware (whose server we are currently crashing). Here's an old paper on the subject. With videos!

It was touted as the way of the future then, too.

I remember reading about this five or six years ago - it was called Lifestreams at the time, then later commercialized by a company called Mirror Worlds which now goes by the name Scopeware (whose server we are currently crashing). Here's an old paper on the subject. With videos!

It was touted as the way of the future then, too.

Are there really people out there who haven't heard of Dijkstra?

In his paper dissing goto statements, Dijkstra didn't consider BASIC syntax harmful. He considered BASIC's distinctive "feature" at the time, namely overuse of goto, harmful. He considered languages without else, for, and while harmful. Guess what? Microsoft QBasic and most other semi-modern BASIC descendants have else, for, and while and rarely use goto.

If I'm not mistaken, you're Steve McGeady of Intel, who did Set Top Boxes with Gosling at SIGGRAPH '95.[1] Why didn't Intel put up the $40k to cover your expenses as a witness in the government's case, especially in light of what Microsoft did to them?

__

[1] FWIW, mad props for keen vision etcetera; and isn't it interesting how that prospect was also killed off by Microsoft?

...he says as I pick up a copy of the SIGACT News and wish that it had a few more illustrative cartoons...

I'd check out material from Google, Amazon, The HCI Bibliography, NASA, the W3C, and Joel for starters.

While some may scoff, the ACM has an article on the Windows 95 interface, a little bit aged by now. Though many in this forum dislike Microsoft for its other faults (the constant crashes, draconian business practices, etc.), a big part of their current success comes from the fact that their user interface is simply easy to use. They do their homework when it comes to that.

My mom couldn't spell WWW when I set up my parent's computer for them a couple years ago. She complained that IE wouldn't go to the website after she typed in the address. It took me a while to realize that she wasn't pressing Enter when she finished typing the address in. That's why they have that little "Go" button next to the address box that I always get rid of right away.. Duh!

This is a noble quest, young hero. God speed.

First OpenSSH, then Sendmail...

Consistant use of best practices everywhere would prevent this, but that just doesn't happen. I don't actually use Sendmail (prefer exim), but I do use OpenSSH, and either way, these are both major applications... when is GCC going to be trojaned? And then will it be a week of compiling other apps and kernels and modules before it's discovered? I hope not.

That said, I'm not running anything but Linux/BSD and OpenSource software... wouldn't have it any other way.

-yb

The problem with most operating system GUIs (as I see it, as do Nielson and Gentner ) is that they follow the "desktop" metaphor, where the main onscreen workspace is a "desktop." You have easy access to different tasks you would do, like a calendar or letter-writing program. "Documents" reside inside the desk in different drawers. At this point, the methaphor breaks down: you get desktop shortcuts (or wharf buttons or whatever), which have no real-world counterpart and are confusing to people who are not familiar with the underlying file systems; you get programs that do specialized tasks that are in no sense connected to sitting at your desk and doing office work. In short, the desktop metaphor is fairly limited.

The desktop GIU is ubiquitous enough that people have a passing familiarity with it, however, so the major OS makers won't blow it up and start with a professionally designed UI based on a better concept. (maybe this will change in the next decade when we move to 3d GUIs, into which Microsoft has poured tons of research money). Open source wms can be much more experiemental, and may lead to some ideas that UI experts can later refine.

I mean... Most authors can't even handle their own proofreading. Who says they create their own links?

Actually, most authors do handle their own proofreading. Editors (whose time is usually spent doing far more administration than "galley slavery") love writers who submit clean copy. It saves them time, and it makes the author in question look like a real pro who actually knows what they're doing, instead of yet another no-neck yahoo who thinks they can write.

Likewise, a lot of authors can and do create their own links. I should think that Declan McCullagh, with his tech-related tearsheets as thick as the average encyclopedia, would be better-suited to defending his ability to write a simple hyperlink (and to opine on the deliberateness -- or not -- of the DeCSS link) than I, but I'm here.

Also, low level process note: For any web-based print medium for which I've written (several, by now), the author generally includes his or her own hyperlinks, if not actual markup. Editorial commentary and/or low-level drudgery only come into it if the links don't work for some reason, in which case the author usually gets an e-mail from the editor advising him or her to change the link and resubmit the revised version. YMMV, especially if the link leads to actionable content...

Posting from Mozilla on Window Maker on Debian, I have to say that his user interface comments are way off the mark. Free Software is free to combine the best interfaces with the best answer to any particular problem. Sure, that makes for some inconsitency as the right tool for the job is never a universal. Just the same I've gotten used to the particular interfaces I like and now think of them as far easier than the M$ junk I use at work and even Apple stuff. If he wants to be the tyrant of an interface, he's welcome to make one or even to simply make some constructive comments. Oh wait, I see, he and the people he works for consider such stuff "intellectual property" that can be owned so that best practices never go very far.

His website would benifit from a more modular approach. Everything is thrown out in one big long scroll down page. Stuff like his background should be a link to two kilobytes of text with links instead of a too short to be useful with no links paragraph. Recent articles and publications should also be links. The sidebar is full and distracting rather than informative and useful. Why would I take this man's opinion about software design seriously when his site so clearly misses the pull nature of html? Oh wait, now I see, he thinks of his web page as an advertisment rather than a means of sharing information.

I'm starting to see a patern and it's name is greed. The things he bemoans are the direct result of his own way of thinking. The only thing he gets right in the article is that many cheap gadgets have poor interfaces. Who is not sick of having to read a manual to learn how to use yet another black box that is a toaster or microwave oven? This has little to do with software design and his mixing the two up is the result of ignorance or malice. His ingorance of the world of free software is less than forgivable from a design expert. His disparagement of software licenses that give the user the ability to run software for any purpose, modify that software as the user pleases and share those modifications, is likewise the result of unforgivable ignorance or malice. Take the blinders off, Don, you might like what you see.

The trouble is, that functional languages, while they may be more powerful, are much harder to write well in, generally taking you far longer to get to the finished state you want.

But don't take my word for it:

• Prototyping Real-Time Vision Systems: An Experiment in DSL Design (1998) Abstract: We describe the transformation of XVision, a large library of C++ code for real-time vision processing, into FVision (pronounced "fission"), a fully-featured domain-specific language embedded in Haskell. The resulting prototype system substantiates the claims of increased modularity, effective code reuse, and rapid prototyping that characterize the DSL approach to system design....
• Four-fold Increase in Productivity and Quality: Industrial-Strength Functional Programming in Telecom-Class Products (PDF) Abstract: The AXD 301 ATM Switch is the flagship in Ericsson's line of Datacom products. A fault tolerant and highly scalable backbone ATM switch, AXD 301 has enabled Ericsson to take the lead in the migration of public telephony networks to becoming true multiservice networks, offering both quality voice and broadband data services on the same backbone.... This paper demonstrates how the development of such systems is supported by the Erlang/OTP technology. The Erlang [functional] programming language was developed by Ericsson specifically for the purpose of building fault tolerant, distributed and complex systems.... The paper demonstrates how Erlang supports the characteristics mentioned, while offering unusually high productivity.
• Haskell vs. Ada vs. C++ vs. Awk vs. ... : An Experiment in Software Prototyping Productivity: Abstract: We describe the results of an experiment in which several conventional programming languages, together with the functional language Haskell, were used to prototype a Naval Surface Warfare Center (NSWC) requirement for a Geometric Region Server. The resulting programs and development metrics were reviewed by a committee chosen by the Navy. The results indicate that the Haskell prototype took significantly less time to develop and was considerably more concise and easier to understand than the corresponding prototypes written in several different imperative languages, including Ada and C++.
• Functional languages in microcode compilers (ACM Digital Library). Abstract: This paper discusses the advantages of using high-level languages in the development of microcode. It also describes reasons functional programming languages should be considered as the source language for microcode compilers. The emergence of parallel execution in microarchitectures dictates that parallelism must be extracted from the microcode programs. This paper shows how functional languages meet the needs of microprogrammers by allowing them to express their algorithms in natural ways while allowing the microcode compiler to extract the parallelism from the program.

I hate to be a downer, but that's way too big a question, and too fundamental. It's a catch-22: the fact that you are asking this question indicates you probably won't be able to accomplish the project.

If what you want to do is try your hand at designing a 3D modeller, I'd say you should fork or join (no pun intended) an open-source project. If you don't like some of their design decisions, then redesign those parts.

OK. Having said all that, I'm actually going to try to answer this question as best I can off the top of my head. Beware: this is a brain dump, and that's how it will read...

Start with the interfaces. They are everything. Without good interfaces, you find that the development time for a project with n lines of code will grow as n^2. With good interfaces, it's more like nlogn. I don't know much about 3D modellers, but I bet it will get big enough that this will matter. If your brain is too small to design all these interfaces at once, try to design as many as you can, and then start writing prototype implementations, but be ready to chuck them when you figure out their weaknesses; after all, that is why you are writing them.

For each interface, ask not what facility that interface provides, but rather what information it hides. That is, what changes could occur behind-the-scenes without requiring corresponding changes to the caller of that interface? If you can't describe in one simple sentence (with no "ands" or "ors" in it) what an interface is hiding, then it's no good, and you need to take another stab at it. (Of course, I didn't think up this information hiding thing myself.

As you design your interfaces, identify those that are truly fundamental (ask yourself: would every conceivable 3D renderer need to be able to do this?), and separate them from the others that contain some of your own personal choices. The former are your base interfaces that should (in theory) converge toward the ideal design, such that you feel less and less need to change them as development progresses. The simplicity and stability of these interfaces will determine the flexibility of your design. Their header files should be physically segregated from those of the other less-fundamental interfaces.

Then, remember to think big and code small. By that, I mean you should brainstorm while writing your interfaces, and design them so they could accomodate every plausible implementation; then, implement them in the simplest, most straightforward way you can. Churn out those prototype implementations with a focus on the shortest path toward correctness. Worry about everything else later; thanks to the flexibility of your interfaces, you can change any of the implementations later. This approach prevents premature optimization, and keeps you from writing lots of intricate code you don't need.

Recognize when you have opposing forces on each side of one of your interfaces (ie. the caller and the implementor), and split that interface into two. That way you can give both the caller and the implementor an interface they like. (That's described in my thesis--chapter 4--and the PowerPoint slides on my web site.)

When you don't know how you want to do something, see if you can make an interface that hides that decision. That way you don't need to think about it now; punt the decision until you have enough information to make a good choice. If there's no obvious "best" implementation, then that may be something you'll want to change later anyway, and you'll be glad you made an interface to hide it from the rest of the system.

I have only just barely scratched the surface here. This is a truly vast question you have asked.

Good luck with the project.

3G is out before it is ever in...

> Such accusations are not very useful (nor friendly) without something more specific.

Sorry, but database field is too rich to give all the specifics in a Slashdot post. You can go to DB Debunk, Open Directory or Wiki Encyclopaedia for specifics: or better yet, buy An Introduction to Database Systems by Chris J Date.

And no, I was not caring to be much friendly. I believe people should educate themselves before publishing their thoughts to the world, and the database field has suffered much already from people who did not.

But just because you seem interested, a relational database is based on two-valued predicate logic, where predicates are expressed by n-tuples organized on relations, which are time-varying values of relation variables. This is what makes it so simple and powerful. If you break this model, as SQL did, you get something at the same time more complex and less powerful. Programming languages should adapt to it, not the other way round.

> building sets *into* the programming language may make inter-language info sharing harder

I fail to see that. Can you point to somewhere where this is demonstrated? On the contrary, if a programming language gets the relational elements right, they will be the same as in any other programming language that does the same. They would all get the data structures directly from the RDBMS. What that subtracts from tables? It is just higher level, because relations do not have ordering, duplicates, undifferentiated NULLs and all the inconsistencies of SQL.

> it would be interesting to see OO-like classes based on sets rather than trees.

Read The Third Manifesto, and make sure to buy the book too. A class, by definition, is a set. So it maps to data types on the programming language, and domains on the database. Not only maps in the sense of having some relation to, but they are identical. The inheritance thing is orthogonal, and should be done thru Specialisation by Constraint.

> Are you saying that the xBase approach is "flat"?

I said what I said, please read carefully. I said that more distant from relational than xBase would be OO and flat files, but that does not make xBase relational. It is what was called navigational in olden times. But you miss the point, because you have not yet grokked how distant SQL is from the relational model.