Slashdot Mirror

Maybe, but getting anywhere near Lisp means dealing with the Smug Lisp Weenies.

Too bad, as Lisp is something worth learning (even if you never use it).

The Wiki things are cool in a way, but too filled with unqualified opinion.

You're missing the magic behind Wikis.

Most web pages are static, or if they're dynamic, the reader isn't the one with the power to change things. On a Wiki, anybody can come by and help edit.

That doesn't seem like a big deal, but it's amazingly powerful. When I first used the original Wiki, I notice that one sentence in an otherwise good page was confusingly phrased. And so I fixed it. In a few seconds. Wikis allow you to aggregate small amounts of effort from thousands of people.

If the Wikipedia is currently imperfect, that's ok. As experts come by and look at it, they'll fix things that they notice are wrong. It will never be completely perfect, but that's ok; no document ever is: caveat lector was good advice long before the web.

The advantage of the Wiki is that it's a document with an extremely low cost of change, so that it will be able to stay in sync with current knowledge and viewpoints much better than, say, a paper document like Britannica.

I'm too cheap to donate, and I'm only 16 anyway...

I'm not! I just sent them $100. It's a good resource, and a fascinating experiment in collaborative content generation.

Remember the excitement about the internet circa 1997? Well Amazon turned out to be a big mall, and eBay turned out to be a big flea market. But the Wikipedia is pushing the boundaries of what the web is. Those of you who miss the exitement of the early days should check it out. And send them a check so you can see how it turns out.

As a software designer, I am amazed by Wikis. If somebody asked me to build a system that would allow tens of thousands of people to collaborate on the same big document, I would have come up with something an order of magnitude more complicated than The Wikipedia and two orders of magnitude more complicated than Ward Cunningham's original Wiki. But they work amazingly well. $100 is a small price to pay for what I learned studying and using Wikis.

Cross language inheritance is nothing unique. Jython has it. Jython and C# came about at roughly the same time.

As other posters suggest, problems start when you realize that Java has single inheritance and Python has multiple. The same problem occurs when bridging C# and Python.

I guess everything looks better when it comes from M$ PR department.

This seems like a fine time to mention Slow Sort, which makes bubble sort look downright efficient and clever. From this paper (PDF).

(The paper is fun if you know computer science, the c2.com link is in "normal English". Try the paper if you think you'd enjoy it; it has a dry wit and pursues its task of sorting as slowly as possible with great gusto.)

But it's important to distinguish between a Unit Test (which is easy to write, even for GUI programs), and an Acceptance Test, which can be hard to write.

A GUI test shouldn't test something like "when you go to Window>Server List, and leave the window open, showing an active status message by starting a connection by right clicking the server and selecting 'Refresh', then you open the properties with Edit>Properties and change the settings that efect the server, the still-running connection works properly with the old settings until the refresh is completed". That's the kind of corner case where you're likely to find a bug, but testing that sort of thing is nigh impossible -- especially when the software is changing, and the interface is changing, and this is one among thousands of corner cases.

When you use unit tests you don't test a complete thing like that. You test each part, but you test it very completely. You may not test the GUI at all -- instead you test that the underlying server code and preference code work properly. You test that they work to spec, and not just within the bounds of the interface. Maybe in version 1 you can't select both the server window and the preferences window at the same time, so this situation is impossible. But you can still make a unit test for this case.

When you do that, you avoid a huge number of bugs. At that point you don't need to test the entire program by simulating input. Instead you rely on the fact that each component works in a controlled and correct fashion. Then, fitted together, they all work together. Sure, the people writing GTK need unit tests -- but only for what GTK does, not for the particulars of how your application uses GTK. And so it goes, we each build upon well-tested code, but we don't retest that code. We trust the upstream developer.

Of course, we've all seen bad interactions between things we wouldn't expect. Part of using unit testing is to make components that work in an isolated fashion, components that can be tested in isolation. Reducing coupling between components is essential.

Which is again a reason why GUI applications are hard to test -- coupling is encouraged, because it's usually a better user interface. You want to fit everything together based on the best metaphor for the user, the most expressive interface you can get, expected workflow, etc. That often doesn't match up with the underlying objects you are using. It's often highly coupled. But you can have that in one part of your system, so long as you really trust the pieces its built on.

I think as more areas of open source embrace unit testing and test driven development -- and it's happening rapidly! -- that we'll see some significant improvements in quality. And it's great for open and free software, because unit testing is something that's hard to bolt on later. But you can do it, it just requires a lot of refactoring. Because of the availability of the source, refactoring is an option for us. Because APIs for environments like Windows or Java are largely set, and the components largely opaque, they don't have this option.

But it's important to distinguish between a Unit Test (which is easy to write, even for GUI programs), and an Acceptance Test, which can be hard to write.

A GUI test shouldn't test something like "when you go to Window>Server List, and leave the window open, showing an active status message by starting a connection by right clicking the server and selecting 'Refresh', then you open the properties with Edit>Properties and change the settings that efect the server, the still-running connection works properly with the old settings until the refresh is completed". That's the kind of corner case where you're likely to find a bug, but testing that sort of thing is nigh impossible -- especially when the software is changing, and the interface is changing, and this is one among thousands of corner cases.

When you use unit tests you don't test a complete thing like that. You test each part, but you test it very completely. You may not test the GUI at all -- instead you test that the underlying server code and preference code work properly. You test that they work to spec, and not just within the bounds of the interface. Maybe in version 1 you can't select both the server window and the preferences window at the same time, so this situation is impossible. But you can still make a unit test for this case.

When you do that, you avoid a huge number of bugs. At that point you don't need to test the entire program by simulating input. Instead you rely on the fact that each component works in a controlled and correct fashion. Then, fitted together, they all work together. Sure, the people writing GTK need unit tests -- but only for what GTK does, not for the particulars of how your application uses GTK. And so it goes, we each build upon well-tested code, but we don't retest that code. We trust the upstream developer.

Of course, we've all seen bad interactions between things we wouldn't expect. Part of using unit testing is to make components that work in an isolated fashion, components that can be tested in isolation. Reducing coupling between components is essential.

Which is again a reason why GUI applications are hard to test -- coupling is encouraged, because it's usually a better user interface. You want to fit everything together based on the best metaphor for the user, the most expressive interface you can get, expected workflow, etc. That often doesn't match up with the underlying objects you are using. It's often highly coupled. But you can have that in one part of your system, so long as you really trust the pieces its built on.

I think as more areas of open source embrace unit testing and test driven development -- and it's happening rapidly! -- that we'll see some significant improvements in quality. And it's great for open and free software, because unit testing is something that's hard to bolt on later. But you can do it, it just requires a lot of refactoring. Because of the availability of the source, refactoring is an option for us. Because APIs for environments like Windows or Java are largely set, and the components largely opaque, they don't have this option.

The developers at Microsoft are quite capable of great things.

It's just that MSFT management decisions made to obscure things for competitors has created a Big Ball of Mud.

You know, Ballmer's song, "DOS ain't done till Lotus won't run!"

"I guess my dream of visiting every star in our galaxy just got a bit tougher."

Yes, but are you going to insult everybody in it? Individually, personally, one by one, and by alphabetical order?

I miss Douglas Adams

"Javascript" was originally LiveScript and the name was changed by Netscape as a marketing ploy, not Sun.

1. You cannot apply a technological solution to a sociological problem (Edward's law) [everyone does this, consider the people who wrote MS Word]

2. OO represents "real world"
[When did the real world start using 'CommandContainerFacade.getEventProducerFactoryCre ationCommand()'?]

3. There is a magic product out there that solves all problems.
[yeah sure, maybe in million years!]

4. Methodology X is panacea. [see Usenet]

Also see Anti-patterns catalog for other examples.

How about going to the store and knowing if you got the correct change?

When you have one, and only one, stereotypical answer to a question as open-ended as "Why do students need to know arithmetic?", it's a smell (in the sense used in the link; please do read it carefully before assuming you know what I mean).

(Similar such smells include technologies where everybody gives the same use case across a span of technologies, like "Home automation is useful because you can turn on your dishwasher at work!" If that's all you got, it's not a good argument, and lo, home automation has never taken off. Also see video phones, where The Argument (singular) seems to be "Relatives on the other side of the country can see their kids/nephews/grandchildren!" (while ignoring a raft of negatives associated with real use of the technology).)

Doesn't mean you're "wrong", but it does mean that's an awfully weak argument.

I still think arithmetic is important, but mostly because it's in the class of "things so god-damned easy that if you can't even add two numbers together, you have no hope of understanding anything logical, ever." Harder to point to concrete use cases, but goddam folks, if you can't teach your kids about basic arithmetic, you're already fucked; give up and let everyone go home.

then in effect you ARE extending the class

From a pragmatic point of view, yes. I would prefer to say that the class has the same method signature. Note that, for example, an encapsulating class of this kind could not be used in the same place as an instance of a superclass of the wrapped class. So taking a simple example:

class Ape() {
...
}

class Bonobo extends Ape {
...
}

class BonoboWrapper {
private Bonobo wrappedBonobo;

public void BonoboWrapper(Bonobo myApe) {
this.wrappedBonobo = myApe;
}
}

then a method expecting an Ape would work with a Bonobo instance, but not with a BonoboWrapper instance. As to which is more appropriate, it depends on the circumstances. Better minds than mine have debated this extensively here and here, so I'm not going to commit myself and look even more stupid :-)

(Sorry about losing the indentation on the code; today's too short to work out how to get round /.'s formatting vagaries.)

then in effect you ARE extending the class

From a pragmatic point of view, yes. I would prefer to say that the class has the same method signature. Note that, for example, an encapsulating class of this kind could not be used in the same place as an instance of a superclass of the wrapped class. So taking a simple example:

class Ape() {
...
}

class Bonobo extends Ape {
...
}

class BonoboWrapper {
private Bonobo wrappedBonobo;

public void BonoboWrapper(Bonobo myApe) {
this.wrappedBonobo = myApe;
}
}

then a method expecting an Ape would work with a Bonobo instance, but not with a BonoboWrapper instance. As to which is more appropriate, it depends on the circumstances. Better minds than mine have debated this extensively here and here, so I'm not going to commit myself and look even more stupid :-)

(Sorry about losing the indentation on the code; today's too short to work out how to get round /.'s formatting vagaries.)

XML is standard. It can fit almost any type of data

Well, then why not make a comma-delimited standard or a relational text standard? Relational can also fit almost any kind of data (in theory).

http://www.c2.com/cgi/wiki?RelationalAlternative To Xml

nobody's going to hit a SCO exec

Based on past writings, disciples of Ed Yourdon might contribute. The question is how. It's already recently been proven that the waterfall methodology may not work. Maybe we can make thermite from left over Jolt cola cans (powdered aluminum) and iron oxide (rusted brillo).

Whatever... Based on SCO's current popularity, it sounds like it'd be a very popular open source project.

You're absolutely right, and I'm surprised that the Open Source community hasn't embraced something like OpenDoc for this very reason. Anybody could bite off a managable piece of code and work on it without worrying too much about learning a particular, monolithic infrastructure.

OverlyBroadIntellectualPropertyAgreements discusses exactly this sort of problem.

The "Fine Arts Waiver" described on the page is definitely something I will not work without. With some companies it's just a matter of asking for it.

Isn't it obvious? Support. Rewind until 1999. Who did Redhat buy? Cygnus. Cygnus was a support company.

Wiki Cygnus Support

Cygnus Support is a Free Software Business -- Cygnus gives away Free software using the Free Software Foundation model, and the GNU Public License, adding value by providing professional support. Interesting in that it can be done, and that it can be done well. And, well, that it can be done, and done, and done...interesting.

At my company we use WikiWiki for documenting everything from internal code management procedures to HR policies. It works great.

However, I work at a pretty small company. I don't think that a WikiWiki site would serve the needs of 5000 employees, simply because you don't get the "personal responsibility factor" check and balance for making changes to the Wiki. I can see it now....Fred in accounting says that we all get 20 weeks off a year! Horray!

IN Soviet Russia, Cygwin WINs YOU!!!! And All yOur base are belong to muthaficking US!!!


FIRST POST MUTHAFUCKA!!!!!!! MUAAHAHAHAHAHAAAAAA!!!!

IN Soviet Russia, Cygwin WINs YOU!!!! And All yOur base are belong to muthaficking US!!!


FIRST POST MUTHAFUCKA!!!!!!! MUAAHAHAHAHAHAAAAAA!!!!

This is a variation of the well-known mantra of developers everywhere:

"IT WORKS ON MY MACHINE"

See also: http://c2.com/cgi/wiki?BugsArentVoodoo

At one point I worked at a company that had one particular project team trying out a monetary penalty for uttering the words "it works on my machine". (The fine was something like $5 and went into a project team party fund.) Another clever penalty was that if you broke the build, not only was there a small fine, but your mug shot photo was taped to the window of the main project meeting room, as a sort of "build breaker's wall of shame". When I was walking by one day I saw one person's picture up there at least 4 times. :)

Not only that, but Ward Cunningham has stated that HyperCard was an inspiration for some of the concepts of Wikis.

From here

As for C being strongly or weakly typed, I suggest you check out this page. Certainly, C could be considered either in the proper context, and I don't want to debate it. Nonetheless, I think it's a bit dishonest to try to lump C in with PHP and Perl, which I would think was the implication of "weakly typed" in our context (or such was my assumption).

You don't mention any PHP or Perl experience in there, so I'll try to fill you in. Working on other people's code in either of those two languages, unless very well documented, sucks. I use both PHP and Perl for small projects I need to whip up quickly, such as a simple web-application or dynamic content on a webpage. But for a large-scale project, it would be hell. I'd choose JSP.

I went poking around on Google and could not find an answer in 30 seconds, so you are forgiven. ;-)

I think this page on aliasing should answer most of your good question.

Add to that page the fact that if a compiler can't be sure about something, the answer is typically to copy the thing it can't be sure about into a safe location, and either copy it back somewhere after the "unsafe" thing or explicitly check it for changes.

For instance, if you're calling a function and the compiler can't know what it's going to do to the caller's registers, the compiler must painstakingly copy the registers out to main memory (well, it'll probably land in L1 cache but still it could be very expensive compared to the function itself), call the function, and copy the registers back in, whereas if the compiler can know it's a little function that only uses registers X and Y, it can only save those. If you're calling lots of little functions, this can add up.

A real example of this? If you're making a static call in C to a function, the compiler can go look at the function and do this analysis. If you're calling through a pointer, a common operation (at least, I can't stand using C without it...), it can't, because that pointer could be pointing at anything, up to and including a dynamically constructed function (if you're brave). To maintain its promises to the programmer that a function call never changes the variables in the caller (which may be located in registers), it has to protect all the registers.

Aliasing is a nasty problem because it's completely opaque to the compiler; the compiler can't see through that indirect function call to the function beyond, not even in theory. As the page mentions, other techniques are being developed that don't involve that sort of opacity by working around aliasing, and the JIT compilers take a different, more dynamic tack that in theory lets them do this analysis dynamically. (The Transmeta processors can also do some of this stuff, which is one of the ways they can speed up code when they run it a lot; they can do this more expensive analysis and dynamically optimize the code.)

... compared to the code-generating power of lisp macros.

Also, it wasn't just an article, it was a series of articles. I'm at work (posting on /. rather than writing code ... bad coder, no donut), so I don't have my DDJ collection here (and their site seems not be be responding for the moment), but I think these are the same basic content. This is another page with links to his stuff, but it is a bit out of date. For instance, I believe he's moved on from MicroSoft (though I can't be botherd to check on that ... what d'ya want for nuthin?).

But the uniformity of the syntax of lisp (actually VERY traditional, going back to 1958...) is one of its major advantages.

I agree that Lisp's syntax makes many things easy -- stuff that can't be done as elegantly in other languages -- but it's not that old. Google for "M-Expressions"; example links: here and here.

You can do your part by writing the OSUG award committee through the club secretary and, in your own words, letting them know you approve of all of the nominees. Kimberly is a new surprise as well, but Martin was entirely unexpected. I'm writing to the award committee myself, as well as to Martin Pool and his now far-away life partner, Robert Crawford, now VP of Software Development at the Bridge Agency.

Here is a link on c2.com with a skeptical debate about code generation:

http://www.c2.com/cgi/wiki?CodeGenerationIsaDesi gn Smell

Basically, it is saying that code generation is converting info from a compact, well-factored, form to a less compact less well-factored form. In some cases I can see where it may improve run speed, but not code maintanance. One should generally remove duplication of patterns from code and data, not add to it.

Think of the (as beer) as a casting operation to the free word

Of course! It's not clear until it's expressed as a computer science concept, naturally.

It still doesn't feel natural to me, since I can't think of a case where the sense of "free" isn't implicitly understood. In most cases it's an object that is free(beer). Of course, you could talk about it being free(libre) to do something or other... but that would be anthropomorphizing an inanimate object, and they hate it when you do that.

Except, of course, (duh!) the concept of free(freedom/speech) software. Aha. Now I get it. Thanks to the Wikipedia article for spelling that out for me.

And finally, how can someone who has such a low slashdot ID not have picked these things up?

That why it was such a stupid question. I've been here since 1996... and the free beer has confused me for all 7 years.

The rest of it I understand a bit better, though I'm always curious about the etymologies of these things.

I have now also found a good explanation of the Soviet Russia bit, attributing it to Yakov Smirnoff.

And thanks to "glivings" for explaining that the whole "profit" thing comes from a SouthPark episode.

Now I'm just waiting for someone to write their PhD dissertation on /. culture... :)

- Peter

This is actually what the whole Wiki revolution is for. Wiki is an easy-to-use web-based collaboration system. It's been in use for years at a number of great sites.

One interesting site, Portland Pattern Repository, contains lots of pages that various programmers have put together to describe their experiences programming. For instance, you can find a lot of information about the Singleton Programming Pattern.

Another site that really shows the power of Wiki is Sensei's Library (a website for learning Go.)

So I would look through the available Wiki's and see if any match your intended audience. Then start creating your pages and go to town...

This is actually what the whole Wiki revolution is for. Wiki is an easy-to-use web-based collaboration system. It's been in use for years at a number of great sites.

One interesting site, Portland Pattern Repository, contains lots of pages that various programmers have put together to describe their experiences programming. For instance, you can find a lot of information about the Singleton Programming Pattern.

Another site that really shows the power of Wiki is Sensei's Library (a website for learning Go.)

So I would look through the available Wiki's and see if any match your intended audience. Then start creating your pages and go to town...

This is actually what the whole Wiki revolution is for. Wiki is an easy-to-use web-based collaboration system. It's been in use for years at a number of great sites.

One interesting site, Portland Pattern Repository, contains lots of pages that various programmers have put together to describe their experiences programming. For instance, you can find a lot of information about the Singleton Programming Pattern.

Another site that really shows the power of Wiki is Sensei's Library (a website for learning Go.)

So I would look through the available Wiki's and see if any match your intended audience. Then start creating your pages and go to town...

I love wikis (see also Twiki, a very flexible one, and Openwiki if you prefer M$ technologies): you can organize anything you want, with anyone you want. It's more suited to a workgroup of people, but they work for individuals too. They're totally flexible, extensible, and templatable.

I'm sure people here will come up with ideas like knowledge trees and weird topological concepts, but gimme a wiki any day.

There really should be a Beer 101 class for geeks everywhere. Here's a start: What Part of Beer Don't You Understand?.

Unfortunately, the Homebrew computer club has little to do with homebrewing beer or even brewing software although beer geeks know the true meaning of Free as in Beer.

Assign everyone large, heavy, foam-covered clue sticks so you can play Whack-a-mole with your cube neighbours.

Invite the nearest PHB to play, but take the foam off first.

Any technology not indistinguishable from magic is insufficiently advanced. -Pratchett

While Pratchett has a sizable amount of great quotes this one isn't his. It's one of Clarkes Laws

Keep a webpage with one of these tables. In each quadrant, just keep an ordered list of tasks to be done, person who requested task, and date task must be completed by. I'd put a line at the top like "I exist to serve the business of the organization. Choose the place your request fits best. If uncertain, call people and negotiate until you are certain. You can figure out where it goes better than I".

Keep an org chart on a portion of the same page, and tell them that they can put their task anywhere in front of anyone at their level in the heirarchy or lower, or in front of their own boss. If they need to get past someone's request, all they have to do is go to someone high enough in the organization and convince them to send you an email.

Then spend 6 hours a day on urgent important things, 1/2 hour on urgent unimportant things, 2 hours on non-urgent, important things, and 1/2 hour on unimportant, urgent things, or some other mix you find appropriate.

You will slowly see that you are told the important things far in advance, because people find out they get done quite early and very reliably if they give you notice (because you always make time for important things). People also see they shouldn't ask you to do things that aren't important, and by keeping things public, they won't ask the silliest of things that you get now. You'll also see your users start to use the proper terms for things as the list is public and they will otherwise appear unintelligent. Rather then seeing "My computer is broke. u fix it" you'll see "Configure Eudora on My Desktop to Send Email"

As you complete a task, move them off into a permanent record of tasks completed.

And keep an extra computer by the door in your lab/office. If someone walks in with a request, just have them file it appropriately right at that terminal.

Laziness is widely recognized as a desirable trait in programmers. We want to get the most done in the least time. And I must've read a few hundred posts similar to the parent before I let that post go.

Consider that what MS is doing is analogous to what TRW,Experian and Equifax do for consumers, or what Dun&Bradstreet do for corporations. They are trying to mine information from a publicly available source. There's nothing really wrong with that. The question becomes what do you do with that information? I think most people are concerned about what someone can do with that sort of information when it can be correlated to other tangential information.

Consider:
MS mines a news group - the FBI comes in and subpoenas the records of Joe Looser as "part of an on going investigation". (Joe isn't notified of this because the Patriot Act allows them to serve a search warrant and delay notification to the targeted party that the warrant is being served) Afterwards, they go to the library and pull the records of the books that you just checked out. Been doing a little studying on microbiology have we? Oh, and last year, you checked out a copy of the Koran. They then tap into your health records (which are now electronic, but protected by HIPPA) and see that you've filled a cipro proscription 3 times in the past 4 months. Couple this with your high school and college records that comment that you are a "troubled" loner and you get arrested on suspicion of terrorism. Given that you may or may not be allowed to talk to your attorney... who knows how long you could be detained.

In reality, you're high school records indicate your a troubled loner because you didn't get along with your guidance counselor, and you made the mistake of showing the school librarian how easy it was to crack into her macintosh. (And we all know "those Hacker types" are all social miscreants.) Plus, you wore a "Free Kevin" shirt as a frosh. The books you got from the public library on microbiology were actually for a report you were doing on computer genetic algorithms, comparing and contrasting DNA in organic organisms vs. electronic programs. The Koran was required reading for your comparative religion class (damn those humanity requirements) but you were smart enough to get the book via inter library loan, and not have to buy a copy from the school bookstore. ($36 for a paperback? Yikes.) Your cat knocked over the first bottle of cipro and it spilled into the sink; you finished out your prescription and then refilled it, just in case... you never know when you'll end up with strep throat, and waiting three weeks to get a doctors appt. at the campus clinic sucks.... oh yeah, as it turns out, the "terroristic" posting on the Al'Queda message board was made by someone who had an email address that was identified by another computer as a likely email alias of a known terrorist.

Granted that this is a contrived scenario, but I think this could become "the rule" as opposed to the "exception". As the old saying goes, when you have a hammer, everything looks like a nail. When you have all this "data" it's very tempting to assume that you can turn it into knowledge.

In Soviet Russia jokes originated from a coldwar era soviet comidian, Yakov Smirnov. This pagehas a more detailed description, as well as some of the original quotes.

I was waiting to reuse this link I found on here the other day. What you need is one of these.

I only offer this information in the hope that it will help these jokes die. Please God, let them die.

Is there anything else I should be doing?

Consider getting one of these.

#define SetPenColour SetPenColor
#define GetPenColour GetPenColor
#define GetNumberOfColours GetNumberOfColors

Or something like that. But then again, that only works in C/C++ and it's probably bad programming practice.

The original Wiki on the subject is here Looks like it could use some updating on this subject.

Real artists ship.

I think the bigger issue is like the magician's trick of a card force, or the equivalent mental trick. Say you show someone an image that looks vaguely like the McDonalds arches. It's such a huge part of western culture that it's pretty well drilled into people's heads.

I like the concept of choosing a password based on a pattern, but I don't think I'd trust someone else to come up with the pattern.