Slashdot Mirror

Back in the old days, before Rod Brooks started iRobot, I worked part-time at a small MIT AI Lab spinoff making robots for kids called Turtles. The Turtle was an outcome of Logo, and, which itself was an outgrowth of Lisp, and so somehow the company's name got on a list of AI and Robotics vendors. (Sidenote: Lego Mindstorms also came from this same group of people at MIT and industry, though not this particular startup.)

Anyway, we got a letter from a defense contractor asking for "applications of our AI and robotics products to battlefield logistics" and gave a half-dozen or so areas for us to evaluate our products.

As you can imagine, puzzlement gave way to amusement, which quickly gave way to mayhem and by 3:05AM we had started writing our response, starting off with "The Turtle enjoys very low observability, due to a minimal radar cross-section and an almost non-existent infra-red signature."

The letter made the rounds on the photocopy/bulletin-board circuit (there was no electronic copy available outside), and somehow the response got published in an ACM journal. Through the magic of modern imaging, it is available for you to read today in PDF.

There is a somewhat related topic on the c2 wiki:

http://www.c2.com/cgi/wiki?HappinessIsElusive

Snippet:

Follow-up to WeDontNeedDrugsToBeHappy. I think happiness is elusive. Assuming we take a Darwinian model of human behavior, there is no reproductive advantage in long-term happiness because a happy person just sits there and does nothing. Our brain will simply up the ante when we achieve something that makes us happy. And, I think this fits with observations about human nature in general. The rich gripe almost as much as the poor about something or other.

What I think he is really trying to fight is what the Agile Movement calls Big Design Up Front. BDUF recognizes that customers will never see how a software application will transform their business and will invariably change their minds. Dwight D. Eisenhower summed it up as "In preparing for battle I have always found that plans are useless, but planning is indispensable."

If you enjoy tech stories of things gone well or things gone wrong, try "Category Stories" at c2.com:

http://www.c2.com/cgi/wiki?CategoryStories

Click on the big title at the top for a list of subjects that often contain such stories. (Warning, c2 wiki is kind of a long and winding road and not for those seeking instant gratification.)

Dude, that was just a pic of a snake in a toilet...
I'd suggest looking on the c2 wiki for info:
This should be it

I remember distinctly reading on some Agile XP whatever site that CRC cards (the documentation is the code and unit tests!) are used long enough to get the devs on board with what to do AND THEN THEY ARE DISCARDED.

Yeah, people often freak out about that. I tell them, "Ok, then you can keep the cards." They will happily put them in a box and then never look at them again. Myself, I don't use CRC cards much, I just sketch UML on the whiteboard. I do tend to leave the last few months of story cards up on the wall, though.

Note that the most important documentation on an XP project is the acceptance tests, which you can think of as either machine-verifiable specs or automated versions of what QA people often do manually. Those say what the product is supposed to do. One framework for this is FIT, which uses specially structured tables in HTML documents.

Unit tests, on the other hand, are where developers say what individual chunks of the code are supposed to do.

You don't have to save anything you don't use, and you (the compiler) should only use extra registers if it is advantageous to do so (taking into account the cost to save/restore them). Having more registers available simply gives you more options.

That's the optimist's view. In reality it's less clear than that. When you see 20+ instructions to handle entry and exit code, then that strikes me as RISC gone wrong. And this is with a good compiler, not just some student project.

As an aside, when you pass parameters in registers you often have to turn around immediately and copy them to different registers or write them out to memory. It's not hard to come up with cases where it's faster to pass parameters on the stack.

See SufficientlySmartCompiler.

Here is my favorite debugging story, from here: http://c2.com/cgi/wiki?TarongaZooStory
P.S. as if this wasn't funny enough, the "confirm you're not a script" word I had to enter for this post was: tigers
-----

I was working as a contractor at Taronga Zoo (Sydney), on a livestock tracking system.

The deal with this is that most of the larger animals have eartags that can be detected by radio transceivers located at strategic points around the enclosures. This allows the zookeepers to do stuff like detect that the orangs are already in their night cage and lock the door without actually going out to check, or to notice from the office that a zebra has approached within 2 metres of the outer fence (i.e. they have got past the inner fence). One day there was an enormous fuss when it was discovered from the console that the male lion had gone off-line, so either we had a system failure or the lion had escaped. Luckily, since the lion was still where he was supposed to be, it had to be a system failure.

Since none of the other animals were missing, we guessed that it was a problem with the ear tag. As it turned out, the only staff members who had any expertise with the tags were (a) sick and (b) on maternity leave; so the only person in the zoo who knew how to install an ear tag was me. This meant I had to go with the lionkeeper into the lion's enclosure, and install a new ear tag. Well it wasn't so hard to get the tag on the lion, him being well-fed and not really being interested in moving, but of course once we got the new tag on, it didn't work. That was pretty strange, since I had tested it already and I knew it did work. I figured it must be the radio transceivers. So I took the ear tag myself, and started walking around the perimeter of the enclosure trying to see where/whether the tag would be detected.

I think this is where we breached the OccupationalHealthAndSafety? guidelines - because the lionkeeper stayed with the male, I went behind this bamboo thicket and was suddenly by myself with only the female lions for company. And the female lions were much more curious, particularly about the laptop I was carrying. Now don't forget here that it is the females which are the killers. So I am slowly, carefully, mostly terrified, walking around the perimeter of this enclosure, followed by two female potentially man-eating lionesses; when suddenly I pass the break in the transceiver network, and the laptop lets out this tremendous beep and scares the heck out of me.

And the lions.

I jumped, they growled, and I dropped the laptop. Luckily for me, one of them bit the screen of the laptop, and the other one tried to bite the keyboard. I had enough presence of mind to leave them to it, and strolled back to the lionkeeper, where I politely asked if we could leave in a hurry.

Lesson learned: Let sleeping lions lie.

Yes there are many incompatibilities, so the only reason you haven't encountered any incompatibilities, is because you haven't tested your application on every possible browser and operating system, which you have to do in order to be sure your AJAX application will run across any platforms you want to support.

AJAX requires you to test against all browsers, because all browsers are subtly and not-so-subtly different. If you're not doing all that testing, then you have no way of knowing whether or not your AJAX application will really work on other people's browsers, and it probably won't.

You couldn't be more mistaken about the XMLHTTPRequest implementation in Internet Explorer being non-standard. In case you didn't know, XMLHTTPRequest was invented by Microsoft, and Internet Explorer was the first browser to support it. Microsoft's implementation of XMLHTTPRequest defines the interface, and all other browsers are implementations of Microsoft's specification. Better do your homework next time, kiddo.

It's incorrect to say that AJAX is a new idea, and it's also incorrect to say that Microsoft invented the idea. It's been around for a long time, in systems like NeWS, the Network extensible Window System, developed in the 1980's.

It puzzles me why a consulting company like Adaptive Path would want everyone to think that they believe AJAX is a new technology. It sounds like they don't know their history, and haven't been paying attention to networking technology for the past couple of decades, so they were blindsided by a technology that's been around for a long time, and now they want people to think they invented it. Now they're totally overpromising and hyping it, because they lack the experience to know its limitations.

Coming up with a new buzzword for an old idea isn't rocket science, and using the term AJAX makes people sound like newbies to me.

-Don

If you have a unixy laptop, installing a local wiki might be a solution.
There are many different wiki sistems, from very simple, to very very extensive. Im sure yu can find soemthing you like. Take your pick here http://c2.com/cgi/wiki?WikiEngines

Many will have plugins to draw simple diagrams, can attach files etc.
The one I use extensively is TWiki : http://twiki.org/
Both for note taking and group collaboration in my university department.

...but that little fragment of code isn't going to be terribly useful to them, is it?

You usually don't get a great deal of business value from tiny fragments of algorithmic/programming genius - the real value is in having a larger chunk of tested, known-good, documented and working code. Yeah, you'd get a little value from stealing a code fragment here or there - but nothing really significant. You'd still have to make the effort to integrate that stolen code into your codebase.

If they steal only a few small chunks of code, it's unlikely they'd be caught - but the value they'd get out of it would be pretty small. Conversely, if they stole a significant library of working code, they'd probably get significant value out of it - but they'd be at much greater risk of being caught.

It's a risk-reward thing - and even at best, the reward isn't likely to be anything too special. And I believe that most developers prefer to be honest and/or write their own code anyway (even if it's okay to use someone else's). Ever heard of the Not-Invented-Here syndrome? :)

XML is much harder to read and more verbose than Lisp. That's discussed here: XML Is a Poor Copy Of Lisp S-Expressions.

A schema is like a stigma: when you have more than one of them, they're called stigmata (schemata).

Could you possibly think of a worse example of a hard-to-read XML application than RDF??!

XML is like electricity: it's a great way to transmit information (power), but a horrible way to store it. Often it's much more efficient to store it in a traditional database where it can be efficiently indexed and manipulated (chemical potential energy like hydrogen or batteries), and only convert it to XML when it hits the wire.

Print statements with embedded output strings are absolutely horrible. You have to deal with all the quoting and formatting issues, and that introduces all kinds of special case bugs and security holes in your code. What's even worse is half-assed regular-expression based parsers that don't fully or correctly implement proper XML, like Perl programmers love to write.

There's no reason to discourage discussion of language A versus language B versus language C. That's what the Portland Pattern Repository Wiki is all about.

Programming language design is not just a matter of style or personal opinion: some well designed languages actually are qualitatively superior to others, and some badly designed languages (like Visual Basic, Perl, PHP and TCL) are fatally flawed in ways they needn't have been, if only their designers had been wise enough to learn about other languages (like Lisp, Python, Ruby and ML).

If you made a bad decision and invested a lot of time and effort in learning an inferior language like Perl, then there's no reason to cover your ears when people discuss its problems and the advantages of better languages. Not knowing what's wrong with Perl will only cause you more problems, if you still choose to continue using it after learning how bad it is.

-Don

XML is much harder to read and more verbose than Lisp. That's discussed here: XML Is a Poor Copy Of Lisp S-Expressions.

A schema is like a stigma: when you have more than one of them, they're called stigmata (schemata).

Could you possibly think of a worse example of a hard-to-read XML application than RDF??!

XML is like electricity: it's a great way to transmit information (power), but a horrible way to store it. Often it's much more efficient to store it in a traditional database where it can be efficiently indexed and manipulated (chemical potential energy like hydrogen or batteries), and only convert it to XML when it hits the wire.

Print statements with embedded output strings are absolutely horrible. You have to deal with all the quoting and formatting issues, and that introduces all kinds of special case bugs and security holes in your code. What's even worse is half-assed regular-expression based parsers that don't fully or correctly implement proper XML, like Perl programmers love to write.

There's no reason to discourage discussion of language A versus language B versus language C. That's what the Portland Pattern Repository Wiki is all about.

Programming language design is not just a matter of style or personal opinion: some well designed languages actually are qualitatively superior to others, and some badly designed languages (like Visual Basic, Perl, PHP and TCL) are fatally flawed in ways they needn't have been, if only their designers had been wise enough to learn about other languages (like Lisp, Python, Ruby and ML).

If you made a bad decision and invested a lot of time and effort in learning an inferior language like Perl, then there's no reason to cover your ears when people discuss its problems and the advantages of better languages. Not knowing what's wrong with Perl will only cause you more problems, if you still choose to continue using it after learning how bad it is.

-Don

XML is much harder to read and more verbose than Lisp. That's discussed here: XML Is a Poor Copy Of Lisp S-Expressions.

A schema is like a stigma: when you have more than one of them, they're called stigmata (schemata).

Could you possibly think of a worse example of a hard-to-read XML application than RDF??!

XML is like electricity: it's a great way to transmit information (power), but a horrible way to store it. Often it's much more efficient to store it in a traditional database where it can be efficiently indexed and manipulated (chemical potential energy like hydrogen or batteries), and only convert it to XML when it hits the wire.

Print statements with embedded output strings are absolutely horrible. You have to deal with all the quoting and formatting issues, and that introduces all kinds of special case bugs and security holes in your code. What's even worse is half-assed regular-expression based parsers that don't fully or correctly implement proper XML, like Perl programmers love to write.

There's no reason to discourage discussion of language A versus language B versus language C. That's what the Portland Pattern Repository Wiki is all about.

Programming language design is not just a matter of style or personal opinion: some well designed languages actually are qualitatively superior to others, and some badly designed languages (like Visual Basic, Perl, PHP and TCL) are fatally flawed in ways they needn't have been, if only their designers had been wise enough to learn about other languages (like Lisp, Python, Ruby and ML).

If you made a bad decision and invested a lot of time and effort in learning an inferior language like Perl, then there's no reason to cover your ears when people discuss its problems and the advantages of better languages. Not knowing what's wrong with Perl will only cause you more problems, if you still choose to continue using it after learning how bad it is.

-Don

I like both Lisp and XML, and the way I use XML is deeply influences by Lisp. I'd rather be using Lisp, but XML (and JavaScript and Flash) are ubiquitous and well supported, so I'd be a fool to try to reinvent those wheels instead of learning to live with what we have and improving on it.

There's an interesting discussion of Lisp -vs- XML. Some people think Xml is a good copy Of Lisp S-Expressions, and other people think Xml is a poor copy Of Lisp S-Expressions.

"Think of XML as Lisp for COBOL programmers." (Tony-A on slashdot)

"S-expressions are a representation, XML is a career path." -- WardCunningham (oopsla '03)

The ExtensibleMarkupLanguage is a poor copy of EssExpressions.

XML made the worst part of sexprs worse, by introducing lousy syntax. Then it failed to really capture the strengths of sexprs. Less for more cost, what a deal.

See http://xmlsucks.org/ or http://xmlsucks.org/but_you_have_to_use_it_anyway/

-Don

I like both Lisp and XML, and the way I use XML is deeply influences by Lisp. I'd rather be using Lisp, but XML (and JavaScript and Flash) are ubiquitous and well supported, so I'd be a fool to try to reinvent those wheels instead of learning to live with what we have and improving on it.

There's an interesting discussion of Lisp -vs- XML. Some people think Xml is a good copy Of Lisp S-Expressions, and other people think Xml is a poor copy Of Lisp S-Expressions.

"Think of XML as Lisp for COBOL programmers." (Tony-A on slashdot)

"S-expressions are a representation, XML is a career path." -- WardCunningham (oopsla '03)

The ExtensibleMarkupLanguage is a poor copy of EssExpressions.

XML made the worst part of sexprs worse, by introducing lousy syntax. Then it failed to really capture the strengths of sexprs. Less for more cost, what a deal.

See http://xmlsucks.org/ or http://xmlsucks.org/but_you_have_to_use_it_anyway/

-Don

I like both Lisp and XML, and the way I use XML is deeply influences by Lisp. I'd rather be using Lisp, but XML (and JavaScript and Flash) are ubiquitous and well supported, so I'd be a fool to try to reinvent those wheels instead of learning to live with what we have and improving on it.

There's an interesting discussion of Lisp -vs- XML. Some people think Xml is a good copy Of Lisp S-Expressions, and other people think Xml is a poor copy Of Lisp S-Expressions.

"Think of XML as Lisp for COBOL programmers." (Tony-A on slashdot)

"S-expressions are a representation, XML is a career path." -- WardCunningham (oopsla '03)

The ExtensibleMarkupLanguage is a poor copy of EssExpressions.

XML made the worst part of sexprs worse, by introducing lousy syntax. Then it failed to really capture the strengths of sexprs. Less for more cost, what a deal.

See http://xmlsucks.org/ or http://xmlsucks.org/but_you_have_to_use_it_anyway/

-Don

I like both Lisp and XML, and the way I use XML is deeply influences by Lisp. I'd rather be using Lisp, but XML (and JavaScript and Flash) are ubiquitous and well supported, so I'd be a fool to try to reinvent those wheels instead of learning to live with what we have and improving on it.

There's an interesting discussion of Lisp -vs- XML. Some people think Xml is a good copy Of Lisp S-Expressions, and other people think Xml is a poor copy Of Lisp S-Expressions.

"Think of XML as Lisp for COBOL programmers." (Tony-A on slashdot)

"S-expressions are a representation, XML is a career path." -- WardCunningham (oopsla '03)

The ExtensibleMarkupLanguage is a poor copy of EssExpressions.

XML made the worst part of sexprs worse, by introducing lousy syntax. Then it failed to really capture the strengths of sexprs. Less for more cost, what a deal.

See http://xmlsucks.org/ or http://xmlsucks.org/but_you_have_to_use_it_anyway/

-Don

I like both Lisp and XML, and the way I use XML is deeply influences by Lisp. I'd rather be using Lisp, but XML (and JavaScript and Flash) are ubiquitous and well supported, so I'd be a fool to try to reinvent those wheels instead of learning to live with what we have and improving on it.

There's an interesting discussion of Lisp -vs- XML. Some people think Xml is a good copy Of Lisp S-Expressions, and other people think Xml is a poor copy Of Lisp S-Expressions.

"Think of XML as Lisp for COBOL programmers." (Tony-A on slashdot)

"S-expressions are a representation, XML is a career path." -- WardCunningham (oopsla '03)

The ExtensibleMarkupLanguage is a poor copy of EssExpressions.

XML made the worst part of sexprs worse, by introducing lousy syntax. Then it failed to really capture the strengths of sexprs. Less for more cost, what a deal.

See http://xmlsucks.org/ or http://xmlsucks.org/but_you_have_to_use_it_anyway/

-Don

I like both Lisp and XML, and the way I use XML is deeply influences by Lisp. I'd rather be using Lisp, but XML (and JavaScript and Flash) are ubiquitous and well supported, so I'd be a fool to try to reinvent those wheels instead of learning to live with what we have and improving on it.

There's an interesting discussion of Lisp -vs- XML. Some people think Xml is a good copy Of Lisp S-Expressions, and other people think Xml is a poor copy Of Lisp S-Expressions.

"Think of XML as Lisp for COBOL programmers." (Tony-A on slashdot)

"S-expressions are a representation, XML is a career path." -- WardCunningham (oopsla '03)

The ExtensibleMarkupLanguage is a poor copy of EssExpressions.

XML made the worst part of sexprs worse, by introducing lousy syntax. Then it failed to really capture the strengths of sexprs. Less for more cost, what a deal.

See http://xmlsucks.org/ or http://xmlsucks.org/but_you_have_to_use_it_anyway/

-Don

Good Design (aka Big Design Up Front) is very effective when the problem domain is well understood or there exist a reasonable number of known solutions to choose from. Text editing is a good example of this, people have been writing text editors for over 40 years so there shouldn't be too many surprises and there are lots of examples. (Telephone signal exchange is similar...) For these problems a very formal approach should work well and result in a well documented and well designed system.

Other problems, usually in newer fields of endeavor, lend themselves to more dynamic software creation strategies with less stringent design phases such as hacking, exploratory programming, prototyping and good old XP. It's very hard to write requirements, functional specifications or even UML diagrams for a system that does things nobody has even dreamed about.

In an ideal world both approaches will result in a good design. What started as a hack can turn into a prototype and evolve into a design, the trick is to document it all... but that would require infinite time and infinite resources. This might occur in large open source projects where the user and development communities are large enough to represent statistical universes but in the corporate world where the bottom line drives everything and therefore time and resources are limited shortcuts are taken. Sometimes this results in brilliantly designed but undocumented applications, but just as often the result is a giant ball of mud that will scare the willies out of the first intern or student hired to maintain code.

Good Design (aka Big Design Up Front) is very effective when the problem domain is well understood or there exist a reasonable number of known solutions to choose from. Text editing is a good example of this, people have been writing text editors for over 40 years so there shouldn't be too many surprises and there are lots of examples. (Telephone signal exchange is similar...) For these problems a very formal approach should work well and result in a well documented and well designed system.

Other problems, usually in newer fields of endeavor, lend themselves to more dynamic software creation strategies with less stringent design phases such as hacking, exploratory programming, prototyping and good old XP. It's very hard to write requirements, functional specifications or even UML diagrams for a system that does things nobody has even dreamed about.

In an ideal world both approaches will result in a good design. What started as a hack can turn into a prototype and evolve into a design, the trick is to document it all... but that would require infinite time and infinite resources. This might occur in large open source projects where the user and development communities are large enough to represent statistical universes but in the corporate world where the bottom line drives everything and therefore time and resources are limited shortcuts are taken. Sometimes this results in brilliantly designed but undocumented applications, but just as often the result is a giant ball of mud that will scare the willies out of the first intern or student hired to maintain code.

http://c2.com/cgi/wiki?DefinitionOfOrthogonal

If you don't actually know Perl and Lisp, then you're not qualified to make unsupported statements comparing them like that. So please share your source of wisdom that tells you that "the human brain takes more naturally to a straight-forward imperative languages"?

If you've only seen programs represented by XML "a couple of times", then how are you qualified to understand them? I'm sure you would find Perl and Lisp programs incomprehensible too, if you only saw those languages "a couple of times". Your own ignorance and incomprehension are not valid arguments that a language is flawed.

You declare that Lisp is unnatural for the human brain, but maybe it's your brain that's impared?

Your mistaken belief that declarative languages are hard to understand might have been caused by learning BASIC as your first language.

Edsger W. Dijkstra observed in Selected Writings on Computing: A Personal Perspective that "It is practically impossible to teach good programming style to students that have had prior exposure to BASIC: as potential programmers they are mentally mutilated beyond hope of regeneration."

-Don

It's not an experiment unless there are testable hypothesis that one can disprove or expand upon. The results of this test do/did not increase our understanding of the way fluid flows work.

On top of that, when you say, "the payoff is uncertain," the rule "YAGNI" comes to mind.

Get the C2 Morse Trainer from here. It's really quite amazing, and totally beats the G4FON one.

That said, I haven't seen a really good way to manage permissions. It's just not practical for an applet to say, "In order to run this, you need these 47 permissions" and expect you to fix that. With cleverness the modeler could create roles with aggregates of permissions, so that you can say, "This app needs access to your browser UI" (like Tabbrowser).

I find it interesting that every application has to wrestle with these problems time and time again, instead of them being solved by the operating system. The reason for all this trouble is that the Access Control List security model is inherently flawed.

Using ACLs makes us adjust permissions per user basis, while it is not the user who does (good or evil) things with the computer but the processes running on behalf of the user. Thus an application can (be tricked to) do malicious things with the user's full permissions - as if the user himself was actively and knowingly destroying his data, sending it over to an eavesdropper, etc. A correct approach would be to grant permissions to do a certain operation on a certain resource per process basis. This is what the capability based security is all about. (If I am mistaken, I hope someone more enlightened in CAP theory will correct me).

I am amazed that none of the popular operating systems implement capability based security models, since they would eliminate Confused Deputy Problems like this.

Some random links relating to Capability based security:

• A cool tech demo of what capability based security would mean in a desktop setting
• Granma's Rules of POLA
• Split Capabilities for Access Control - an interesting implementation from HP
• A discussion of ACLs and their problems, with links to CAP related pages

That said, I haven't seen a really good way to manage permissions. It's just not practical for an applet to say, "In order to run this, you need these 47 permissions" and expect you to fix that. With cleverness the modeler could create roles with aggregates of permissions, so that you can say, "This app needs access to your browser UI" (like Tabbrowser).

I find it interesting that every application has to wrestle with these problems time and time again, instead of them being solved by the operating system. The reason for all this trouble is that the Access Control List security model is inherently flawed.

Using ACLs makes us adjust permissions per user basis, while it is not the user who does (good or evil) things with the computer but the processes running on behalf of the user. Thus an application can (be tricked to) do malicious things with the user's full permissions - as if the user himself was actively and knowingly destroying his data, sending it over to an eavesdropper, etc. A correct approach would be to grant permissions to do a certain operation on a certain resource per process basis. This is what the capability based security is all about. (If I am mistaken, I hope someone more enlightened in CAP theory will correct me).

I am amazed that none of the popular operating systems implement capability based security models, since they would eliminate Confused Deputy Problems like this.

Some random links relating to Capability based security:

• A cool tech demo of what capability based security would mean in a desktop setting
• Granma's Rules of POLA
• Split Capabilities for Access Control - an interesting implementation from HP
• A discussion of ACLs and their problems, with links to CAP related pages

If you told your customers that henceforth your products would run twice as slowly, but you would deliver new features twice as fast, what would they say?

Sure, there are developers out there who really need to program in C for some good reason, but there are even more developers clinging to C (and C++, the way most people use it) whose customers would be thrilled if they ditched C for a less demanding language.

By the way, the "twice as slow" part doesn't have to happen. My company has been using C++ to build systems that span the numerics, hardware, and application areas, and alternating hard and soft layers* has been a big win for us. It's awesome to fire up a REPL and use our software components to experiment, dissect some data, replicate a bug in isolation, or give a quick tour to a new developer. Since none of the "soft" code is critical to performance, there's no downside.

*http://c2.com/cgi/wiki?AlternateHardAndSoftLayers

This Truck Number tends to imply that all people are contributing equally to a project.

I've been on projects where there may be 10 folks working on it and the project would be devestated if, say, 2 specific developers were run over by a truck, but could still carry on even if 5 different developers were killed.

It was for the ability to obtain an "emergency tolerant" skillset.
You could lose a good few staff from any area, and your knowledge base wasn't significantly impacted.

So, if your project truck number is 2, you could afford to lose one member of staff due to a random event (sickness, quitting, etc.) but not two.

-Don

you must only be familiar with shared-state concurrency. because if you weren't, you wouldn't spread this FUD framed from the perspective that threads are the only way to manage concurrency (parallelism) in software.

the means to do "thoughtless" concurrency has been available for going on 40 years now. look up (http://www.c2.com/) carl hewitt's actors paradigm (predecessor to alan kay, both as student-teacher relationship and actors-OOP) as well as read the successor to SICP, Concepts, Models, and Techniques of Computer Programming (http://www.info.ucl.ac.be/people/PVR/book.html).

now, understand instead: MESSAGE-PASSING CONCURRENCY. this is the "thoughtless" solution to programming on the Cell chip, CMT, and all these other new buzzwords for concurrent processing of information with multiple cores. (though, i don't think Oz, or MOZart, are the pragmatic languages to do this with; simply because i don't believe in multiple-paradigm languages -- perhaps i'm just really bitter against C++.)

int AccumulateLoopCount(int N)
{
return n*(n+1)/2;
}

Do some reading on Ward's Wiki:

http://www.c2.com/cgi/wiki?WelcomeVisitors ...specifically "Velocity":

http://www.c2.com/cgi/wiki?MeasuringProjectVelocit y ...and maybe take a look at X-Planner type software.

http://www.xplanner.org/screenshots.html

I'm also a fan of the gummy-bear model, and regular, working customer demonstrations. Provide value as early in the process as possible, not as late as possible. If you don't have your deliverables specified, you'll never know when you're done. Thus, Nail down your deliverables, break them into equal sized chunks, complete them and demo them to your customer, and determine your project's velocity after 2-3 iterations of doing the above.

--Robert

Do some reading on Ward's Wiki:

http://www.c2.com/cgi/wiki?WelcomeVisitors ...specifically "Velocity":

http://www.c2.com/cgi/wiki?MeasuringProjectVelocit y ...and maybe take a look at X-Planner type software.

http://www.xplanner.org/screenshots.html

I'm also a fan of the gummy-bear model, and regular, working customer demonstrations. Provide value as early in the process as possible, not as late as possible. If you don't have your deliverables specified, you'll never know when you're done. Thus, Nail down your deliverables, break them into equal sized chunks, complete them and demo them to your customer, and determine your project's velocity after 2-3 iterations of doing the above.

--Robert

That has the potential to be very good. The writers would have the freedom to kill off or transform any crew members they wish, not just the ones wearing red shirts. With everyone and everything (including the ship) potentially expendable, it could be a wild ride with lots of plot reversals.

It also has the potential to be very bad. Many viewers don't realise how much the regular Trek actors influence the show by keeping an independent reality check on their characters. Multi-season arcs in TNG were actually actor driven (like Troi quietly disliking Worf for most of the show).

So while it might be a great movie, it might be Trek only in name. We'll have to wait and see. Too bad it will be an odd number movie.

There is a reason why more or less all programming languages use braces (or keywords, or some other explicit construct) to mark blocks, rather than relying on whitespace.

That's because people who created all these Algol-derived languages hated FORTRAN column-fixed syntax, I think. And then it stuck :-) Read here or here.

A language's expressiveness determines its usefulness, and if you limit the former, you are also going to limit the latter.

Perl is "grown" as "there are more than one way to do it". Python is designed to be "there is one obvious way to do it" . It does not limit your "expressiveness", however - you can write ugly and unmaintainable code in Python.

...What do you think is more bug-prone? A one-liner in Perl or a 20-liner in C that has to go to lengths to reproduce the same behaviour that can easily be had in Perl?

I prefer 2-liner in Python. And it might be more understandable by somebody who've never seen python code before. The whole Python language is designed to be readable.

The fact that it's easy to write even relatively complex programs in Perl is *good*. A car may have more controls and take a bit longer to learn how to handle than a bicycle, but wouldn't you agree that in the end, a car is more useful/powerful/versatile than a bike?

Yeah! It's easy to write complex Perl programs. To fix and maintain them - that's the hard part. And "python car" is no less powerful than Perl truck :-)

In summary: I don't try to ditch Perl, I'm trying to convince you to overcome your "syntactic-whitespace-hate" and try Python a little more. See what Eric Raymond says ("Oddly enough, Python's use of whitespace stopped feeling unnatural after about twenty minutes. I just indented code, pretty much as I would have done in a C program anyway, and it worked.")

Speaking of myself, I used Perl for six years and recently switched to Python. It's typical - not many doing the opposite... That's why "it's the Python folks in particular who always ridicule Perl" - they usually know both sides :-)

There is a reason why more or less all programming languages use braces (or keywords, or some other explicit construct) to mark blocks, rather than relying on whitespace.

That's because people who created all these Algol-derived languages hated FORTRAN column-fixed syntax, I think. And then it stuck :-) Read here or here.

A language's expressiveness determines its usefulness, and if you limit the former, you are also going to limit the latter.

Perl is "grown" as "there are more than one way to do it". Python is designed to be "there is one obvious way to do it" . It does not limit your "expressiveness", however - you can write ugly and unmaintainable code in Python.

...What do you think is more bug-prone? A one-liner in Perl or a 20-liner in C that has to go to lengths to reproduce the same behaviour that can easily be had in Perl?

I prefer 2-liner in Python. And it might be more understandable by somebody who've never seen python code before. The whole Python language is designed to be readable.

The fact that it's easy to write even relatively complex programs in Perl is *good*. A car may have more controls and take a bit longer to learn how to handle than a bicycle, but wouldn't you agree that in the end, a car is more useful/powerful/versatile than a bike?

Yeah! It's easy to write complex Perl programs. To fix and maintain them - that's the hard part. And "python car" is no less powerful than Perl truck :-)

In summary: I don't try to ditch Perl, I'm trying to convince you to overcome your "syntactic-whitespace-hate" and try Python a little more. See what Eric Raymond says ("Oddly enough, Python's use of whitespace stopped feeling unnatural after about twenty minutes. I just indented code, pretty much as I would have done in a C program anyway, and it worked.")

Speaking of myself, I used Perl for six years and recently switched to Python. It's typical - not many doing the opposite... That's why "it's the Python folks in particular who always ridicule Perl" - they usually know both sides :-)

Well, you're right in that regard. JavaScript lacks the nice message-sending utilities of other OO languages like Smalltalk, Objective-C, Ruby and Python.

But I disagree with, "This makes it difficult if not impossible to create object oriented applications using MVC and many other OOP design patterns." It's obnoxious, but it's certainly doable. This is one of the many reasons why the Command Pattern was invented.

Laszlo used to cost about ten thousand dollars per license, but it is now fully open source and free. Flex costs more than ten thousand dollars per server license, and has restrictions on how you can modify and redistribute Flex components.

Macromedia has a spotty track record supporting their server software over the long haul, and now that Adobe's bought them, Flex is in Flux. Laszlo is here to stay because it's available now, free and open source, and you're not restricted in how you can modify and reuse Laszlo and its components.

Flex is a lot like Laszlo, because Flex is Macromedia's imitation of Laszlo, but Flex is intended to lock you into Flash instead of giving you independence from it.

The most important difference between Laszlo and Flex, is that Laszlo is not tied to Flash, it "just happens to" use it right now, because that's the most practical target platform at this point in history. Laszlo is a high level JavaScript/XML based language which currently targets the Flash player as its initial platform, with more to come.

Laszlo abstracts away Flash dependencies, so it will target other runtimes than Flash in the future, as they mature and shake out: Java (Rhino/Java2D), C# (CLR, GDI+, Avalon), C++ (SpiderMonkey, CGI+, Quartz, Cairo, AGL), SVG (Adobe, Batik, Firefox), DHTML (web browsers, JavaScript, AJAX).

But right now Flash rules, and Laszlo is the best way to develop rich web applications that run on Flash.

One really interesting possible target platform for Laslo is an open source Flash player, that can easily be integrated into applications and games, and uses OpenGL with hardware accellerated rendering.

-Don

The problem with "AJAX", compared to NeWS or OpenLaszlo, is that imaging model sucks, because it's limited to the lowest common denominator of HTML across all browsers. NeWS uses the PostScript imaging model to render interactive user interface components (buttons, sliders, pie menus, tabbed window frames, etc). OpenLaszlo uses Flash graphics to render interactive user interface components (all the widgets you expect, including a full widget set skinnable with Frash graphics, supporting animation, transparency, color tinting, etc).

As a imaging model, Flash is nicer than PostScript in some ways, not as nice in other ways, but vastly superior to HTML. It's also interesting to compare Flash with SVG, which is also great for implenting "AJAXian" user interfaces, but doesn't have nearly the installed base. The best thing about Flash is that it's exactly the same across all platforms, and it's got a great installed base.

-Don

Newsgroups: comp.windows.news
From: don@BRILLIG.UMD.EDU (Don Hopkins)
Local: Sat, Feb 6 1988 5:38 am
Subject: Comparing Display PostScript and X11/NeWS

[...]

NeWS has extensions to the PostScript language that allow for programs (light weight processes), running in the display server, to receive input events on behalf of NeWS clients (other programs running on the same computer, or at some remote site). They may process input locally (on the same machine and in the same process where the events are happening), without consuming any communications bandwidth. This is a big advantage, if you want fast, responsive graphical feedback.

NeWS processes can communicate with each other by manipulating shared data structures, and by sending messages through the event queue. They can receive low level input events ("The left mouse button was released at location (X,Y) in window W at time T"), and give graphical feedback ("erase the old slider, redraw it at its new position, and fill the border with bright red"). They can translate input from the user into high level, application specific events, which are sent to the client ("set the volume of the CD player to 100%"). NeWS processes can run autonomously in the server, without a connection to a client, providing "desk accessories" such as a calculator, event journaling, menus, and control panels.

According to the fellow from Adobe who talked at the PostScript BOF at the X conference, Adobe's Display PostScript provides output capabilities, but has no facilities for receiving input directly from of the X event queue. As I understand his explanation, the X server must send X events over the IPC link (network, shared memory, modem, or whatever) to the client, which must then translate the events into PostScript commands, and send them back over the link to be executed by Display PostScript. Because there is no way for PostScript programs to read events off of the X event queue, the client must process input events behalf of the display server. Messages must go on a round trip, from the X server, to the client, and back to the Display PostScript extension in the server, to produce any graphical output on the screen.

[...]

The NeWS "Lite" user interface toolkit is written entirely in PostScript. Menus, buttons, windows, sliders, scroll bars, and even terminal emulators, are implemented as device independent PostScript programs, in NeWS's object oriented PostScript programming environment. Since the toolkit can run in the server, clients can share the same code, and a copy of the toolkit does not have to be linked into each client. It's easy to mod

If so, George has certainly earned a look at The Book.^(1/2)

If so, George has certainly earned a look at The Book. (The one containing all possible mathematical theorems...)

Scheme already has goto statements! Magically, mystical, state preserving goto statements that can be used to implement things like exceptions, generators, coroutines, and more!
http://c2.com/cgi/wiki?CallWithCurrentContinuation

1) MS Word is a word processor, not an operating system;

The name must be a reference to the old IBM System 360 mainframe. The 360 stood for "the full circle of computing". Microsoft is trying to imply that they will be as important in the console market as IBM was in the mainframe market. This is a huge claim to make, given their second place status so far. See http://c2.com/cgi/wiki?IbmSystemThreeSixty for details.

The WikiWiki concept was created by Ward Cunningham (the very first wiki is here). Also, I doubt the Wikimedia Foundation have actually trademarked "Wikipedia" ...

</wiki geek>

The WikiWiki concept was created by Ward Cunningham (the very first wiki is here). Also, I doubt the Wikimedia Foundation have actually trademarked "Wikipedia" ...

</wiki geek>

This isn't a submarine patent as it was filed in 94 and granted 3 years later. And I'd assume borland was probably using it before the patent was granted instead of patenting vaporware and trying to delay the process long enough till invention becomes viable.