Some fascinating facts about Dr. Laura
on
Congress@Work
·
· Score: 5
Actually, you don't need to look to something as radical as logic to see the source of Dr. Laura's allegedly moral objections to porn.
It turns out that her attacks on the American Library Association and pornography in libraries began, by a strange coincidence, shortly after some amateur porn photos she'd done during an extramarital affair in the 70s leaked onto the net (search on "Dr. Laura Naked" to find the uncensored version). She sued over the photos, but the suit was dropped. Interestingly, the porn company that bought the photos also brought a lawsuit against the amateur sites which posted them. There was a great interview with the guy who took the photos which I'm afraid I can't find. He talked about her "sleeping her way to the top" of the radio industry.
Whenever somebody takes the moral high ground in attacking others, I immediately suspect them of doing the same. "Let he who is without sin cast the first stone," as I'm sure Dr. Laura herself would quote.
Re:1 app with 1000 feat. vs. 1000 apps with 1 feat
on
The Humane Interface
·
· Score: 2
One of the reasons people love UN*X-style OSes runs along with what both you and I are talking about: at the command line, you have a set of (mostly) simple and general tools at your disposal. Through basic building blocks -- pipe, redirect, grep, sed, awk, and so forth -- there's almost always a way to do tie things together in the way that you need to. This is one of the advantage of a small set of generalized features: it's really good at doing things its designed didn't anticipate.
There is certainly a glut of command-line tools, though. The problem with the 1000 UN*X apps is that
they don't all have one feature, because they all have to have input and output handling options so they can play with each other, and
there's a lot of feature overlap, because roles overlap and it's often necessary to make a whole new command in order to change just one feature.
But I suppose this happy mess is really in the nature of a sort of the Darwinian free-for-all of UN*X.
I'd really like to see a shell built on a single powerful set of list and pure function operations that would neatly generalize pipes, redirects, backquotes and lots of command-specific features into a single, more general scheme. It's silly that I have to know about the output format of ps to kill all processes with some specific thing in the command line:
kill `ps -ef | grep nuj | cut -c9-15`
I should really be able to say something like:
kill (ps ? (#.cmd==nuj)).pid
...where ps just outputs some list of named hashes, and I don't have to play ASCII games or know anything about the format of its output.
Some random thoughts in the spirit of this discussion: We often judge user interfaces by their feature sets. More features mean more power, and are better, right? I think not. I actually want my software to have a minimal feature set which is maximally robust.
The idea behind building feature-rich software runs something like this: figure out what a program will generally be used for, and come up with a set of tasks -- use cases -- which are representative of what the majority of users will want to do with the software. Design the software around the use cases, using the ease and efficiency of each of the use cases as a yardstick for the program's success. If users demand more features, the market for the software expands, or the company simply has more resources to build up the software, then add more use cases and repeat.
This works reasonably well, but it has a serious flaw: as the amount of functionality and thus the number of use cases go to infinity, the number of features goes to infinity. Think of M$ Word -- at a certain point, the wizard that will make multi-column address labels is useless to me, because there are so many damned wizards I don't know where to find it.
What software really should try to do is maximize robustness while minimizing the feature set that achieves that functionality. If you want your software to achieve a wider base of functionality, you have to make your interface's features more generalized, and more expressive. As the amount of functionality goes to infinity, the feature set stays bounded, and just approaches some sort of Turing-complete programming language.
So when designing software, don't ask "What features should we add?" Ask "What functionality can we add, and what features can we generalize in the hope of removing others?"
I realize that this is all very idealistic, but it seems like a guiding principle that could keep software bloat in check.
This statement is a model of good writing: it's clear, accurate, to the point, elegantly phrased, and neatly addresses every issue that Mundie's speech raised. Your rambling criticism does its authors a disservice.
Explain, please: how is the statement "weak"? Would you prefer that they had responded with Mundie-style drivel? Would you rather that the response read like a flame on Slashdot? Thanks goodness our "open source luminaries" can come up with better writing than you just did, or than I am right now! Sheesh!
(1) That's "global" in the sense of "worldwide", not "universal". Certainly there is worldwide enthusiasm for the idea of free software. And yes, you are right, that enthusiasm is not universal.
(2) No, not everybody is running Linux. Linux != free software in general, however, and this discussion is about free software, particularly the GPL. A great many people are using free software, and virtually everyone on the internet interacts with it.
So, in short "global enthusiasm for free software" is not the same as "everyone and their brother is running linux". Please check your troll at the door.
A number of the free software evangelists, in informal discussion, felt that the proper response to Microsoft would be to stand together. Mundie's speech shows that Microsoft's strategy is to keep us divided and attack us one at a time, until all are gone.
Right on.
The current global enthusiasm for both free and open-source software amounts to diddly if the proponents of these ideas can't present a united front. When the software community responds to something like Mundie's speech or the DMCA with a thousand flame wars in the underbelly of the Internet...well, guess what: nobody cares. When we respond with consensus -- especially with such a thoughtful, articulate, and nail-on-the-head treatise as this one -- then we have a chance of getting somewhere!
My thanks and respect to this document's ten signers. I wish I could sign it, too, or at least give them all +5 karma.
Sounds great! I've never used Mandrake, but it sounds like I should. I've seen some update features on other Linux distros, but they haven't been as well-organized or as carefully considered as Apple's.
...these would be minor modifications to the existing system.
Mandrake folks: Do it! Don't hold back! Right now, OS X is way ahead of Linux for usability (sorry, but it's true). But a lot of the good work that Apple has done would not be such a stretch for Linux; much of it would require, as you say, only minor modifications. The Linux community should be studying OS X under a microscope and ripping off every one of Apple's insights. If Linux, which is faster, stabler, more efficient, and has a wider base of software than OS X, could also be as user friendly...well, I'll stop there before I get into rampant speculation.
Think of the massive media panic that follows on the heels of ever newly discovered Virus of the Apocalypse. Millions of people are out there wondering where to download the update for Outlook and how to install it...in fact, many of the novices are wondering whether they are even using Outlook.... A scheme like Apple's, done right, could stop a lot of these viruses in their tracks.
If I can get a painless, nearly-transparent bug or security fix the moment it's ready for prime time just by clicking "update", I'm a happy camper. I'm puzzled by this assertion that every two weeks is too much.
An update scheme such as OS X's should meet the following criteria:
No configuration or install necessary to use auto-update
User can customize the auto-update schedule, make it manual, or simply disable it completely
There is a clear explanation of when an update is available, which software it affects, and what features it adds/improves/fixes
User has a choice about whether to download/install an update when it's available
Updates are painlessly self-installing
Updates are well-tested and don't break existing software
I'm using OS X as my primary OS, and so far, Apple has done an absolutely outstanding job with 1, 2, 4, 5, and 6. Only #3 is week -- the only explanation you see when an update is available is "OS X 10.0.3". You have to install the update then try to divine what's changed. If Apple fixes this problem, they'll have a killer mechanism that Linux distros would do well to study.
...is Interwoven's Teamsite. My impression is that it's more geared to building web sites than internal documentation, but it still might interest you.
T-Ranger is right -- you'll probably have to spend some big bucks here, at least as things currently stand. This sounds like a good free software project for some enterprising programmer out there...!
I'm tempted, like many of the other posts, to say "screw the bastards; they dissed you, so you can do the same back."
However, if there is a hack, it's not just the decision-makers who will feel the pain. You said a hacker has access to employee names, SSNs, fire dates...and most of these belong to people who had nothing to do with choosing or implementing this bad system. OK, probably the hack will come from some kid with no malicious plans for the compromised data...but what if this personal information lead to identity theft? What if information about a firing were leaked to a potential employer?
Forget the contract -- you lost it. But you have information about a serious potential threat to several hundred people. Isn't there some ethical obligation to the innocent employees whose privacy is on the line here?
There are two essentially different ways of approaching the problem of learning to program.
Philosophy #1 says, "In the ever-changing world of technology, you should leave college knowing all of the most cutting-edge technologies." Programs that emphasize this tend to have courses in specific programming languages and tools, e.g. "Advanced C++".
Philosophy #2 says (I think rightly), "Technology is such a large world and is changing so fast, any languages or tools you learn now will be useful for somewhere between five years and three seconds. What's really important is that students are able to learn and adapt quickly, and solve problems creatively." These programs tend to have much more theoretical curricula, which emphasize extensive and somewhat open-ended projects.
Programs of the #2 ilk take a lot of abuse: "Why do I have to learn this dumb language (Scheme/SML/Eiffel/whatever) that I'll never use?" Such complaints miss the Big Secret of Programming: for all the vast differences in quality and popularity, most languages and software tools are essentially the same, and when you know one, it's easy to pick up another. The best programmers are the ones who can adapt quickly and be creative, not the ones who know the top 10 hottest languages. Smart companies know this, and will be much more impressed with your ability to catch on quickly than your textbook knowledge of their favorite language. It's trite but overwhelmingly true: in programming, ideas are more important than facts, and imagination is more important than knowledge.
If your program is using Eiffel, they're probably leaning toward Philosophy #2. Whether Eiffel is useful to you depends a lot on how you approach the program. If you expect school to be a practice run for your job...forget it! That's what internships are for. If you get excited about the ideas, and constantly look for ways to challenge yourself, bend the assignments around, and just have fun with everything you can get your hands on...well, now you're in business!
I actually got ordained by the ULC online, and married a couple of friends...er, rather, I officiated their ceremony. The ordination was free, though I did have to give the state of MN $5 to register myself as a reverend and make the marriage legal.
I haven't received any spam from the ULC, other than their single initial response explaining the exciting do-it-yourself spirituality kits they sell.
In short: it may be hokey, but it's quite legit, and highly recommended if you're looking for a wedding of the beaten path!
..software with a license of use that guarantees the user, without an extra fee, the following rights:...
5. Modification of the program, and free distribution of the modifications and the resulting new program, under these same conditions.
That's a sticky phrasing; perhaps it's partly the translation. Does this mean that the user has the right to free redistribution, or that the license must guarantee free redistribution?
It it's the latter, this law would seem to prohibit BSD-style licenses, which allow users to redistribute the software with proprietary modifications. I'd say that would cross the line into ideological crusading inappropriate for a government...though I doubt that's what they intended.
Is the original Spanish available, and can somebody understand it well enough to clarify?
I'm sure there are going to be a lot posts saying things like, "What's the point of this? Why are you bothering? Who needs another programming language? Everything you are doing has already been done better, and it was all useless anyway." I got a lot of that crap when Eidola was Slashdotted recently.
Keep an open mind. If you're not the sort of person who can enjoy new ideas that are cool but may turn out to be useless, just go read another thread.
There's an interesting study about the much-abused field of visual programming languages. The researchers polled programmers who worked with visual and non-visual languages to see which they liked best, and which was most effective. Their main result? Programmers' opinions of a language correlated strongly with how long they'd been using it. In other word, programmers have an overwhelmingly strong bias for the familiar; they are so strongly biased towards what they are used to that they can't really make objective judgements about unfamiliar ideas. Not surprising, but easy to forget!
This bias is a tremendous barrier to new technology. If everyone with an interesting but questionable idea gets shouted down, a lot of useful ideas are lost. Think of the brave souls who installed Linux before it was really usable while everyone was saying "OSes have been done before. Why are you bothering?"...and thank them now.
Then give Mozart and LX a fair hearing. There are some good ideas there; let's help them mature.
So he's looking at his predecessors and thinking, "Boy were they wrong. What give?" I think that's a fair question, especially since he's in the same game.
Katz once again has believed the market hype of the media whores who pushed the whole "internet will change all our lives".
That's quite unfair to Katz. In the net's early days, and even before computers, many people made all sorts of utopian predictions about technology and massive information access. Unsurprisingly, many of those predictions failed. He's drawing on sci fi authors, media pundits, prominent scienists and hackers, etc. Katz is not saying that he personally expected all this great stuff to happen.
Rather, he's asking us to think about some of the original idealism of self-styled net philosophers. Was it completely unrealistic? Or did we miss the boat on something wonderful?
If asynchronous chips became popular, it might help further debate on the difficult question of what makes "fast" fast. The common number, MHz, is of course pretty meaningless -- sort of like measuring the speed of a car by the RPMs. (If you've got the same model of car in the same gear, it's a meaningful comparison. But is a G4 at 500 MHz exactly five times as fast as a 486 at 100? What does "five times as fast" mean anyway?)
Making the familiar measurement meaningless might put more emphasis on benchmarks, and give more impetus for getting them better standardized and more meaningful....Or not -- there are obvious and equally meaningless alternatives for asynchronous chips, like FLOPS, or LOPS (Logical Ops Per Sec).
Were consumers demonstrably harmed by Microsoft? If so, how?
I'd argue that they have, by creating a technological and psychological climate which has made it very difficult for software to compete on the grounds of quality, both by maintaining a public perception that Microsoft is a stellar example of "innovation", and by squashing competitors who threatened this perception. No single company has done more to stifle the innovation of software than Microsoft. That's certainly harmful to consumers.
Of course, the consumers brought it on themselves. It's arguable whether we can blame Microsoft for taking advantage of their complacent, manipulable consumer base. Ripe bastardism is the captialist way, after all. There's a certain philosophical dissonance to anti-trust laws...they're a sort of pacifier to help us believe that capitalism is somehow fair. The market does not value fairness.
"Democracy is two wolves and a sheep deciding what's for dinner. Capitalism is the wolves just eating the sheep."
The software quality situation is improving. Microsoft's own products are better than they use to be, and they are increasingly having to scramble because of competition on the quality continuum. Java and Linux are good examples of products which are succeeding because in large part because they are really good software. That's encouraging.
It's interesting that the government went after Internet Explorer, one of the best products Microsoft makes. It's also interesting that IE is one of the best. Hmmm... Java, Linux, Netscape... Is it necessary to give your product away for free to fight Microsoft to the point where they will resort to writing good software?
You will not see this kernel representation. You can only manipulate it through the various, er, representations of it.
Well, you always have to use some kind of representation, unless you have psychic powers which can just twiddle bits in memory.
Since you have a choice of notation systems, you should have some that are very low-level and close to the bone, showing you exactly what's going on. The purpose of a notation is not to hide the messy stuff, unless you want it hidden for the moment.
The kernel representation...will not be fully specified, which means that programs written in one Eidola environment will not be compilable in a different Eidola environment.
No, actually, the whole idea of having a formally specified semantics is that you don't have this problem. If you say, "This kernel implements the semantics", that's a very strong statement. If another kernel also implements it, and if they have a common interchange format, no problem. That's the idea.
Based on my very limited knowledge of Lisp, I'd say that READ is getting at something very similar. Certainly Lisp's semantics is also a representation-independent idea.
If there's a major difference in Eidola, it's that the language's design emphasizes making this structure available at edit time. That's what the kernel is doing -- it's like READ, only instead of being a unidirectional translation from representation to structure, it's an interactive translator with a big multithreaded event-based observer model, and fancy-sounding crap like that.
Well, duh. Before a project is finished, it's unfinished. This is a project in its very, very early stages. Eidola is very far from being a complete language, and obviously there are a lot of major missing pieces! Consider the ideas that are there now; others will come in time.
I cannot emphasize enough: Eidola is a young project. It is vaporware. It is mostly theory. Bear with it -- these things take time to grow.
Slashdot rang the doorbell on Eidola while it was still in the shower, naked, unshaved, and only half-soaped. It's not quite ready to go out on the town. So take it all in that context. If you can't deal and demand to see it finished, check back on the Eidola site in ten years.
You are presuming that "representation independence" means "graphical", which is not right.
Representation independence means that a program is stored in a form that doesn't presume anything about how it's represented -- no textual syntax, no graphical positioning. Display information like that might be attached to the code in the form of optional display hints, but the code itself is just program structure, nothing else.
how do you compare (i.e. diff) two graphic programs? You must rely on its binary form, and hope its equivalent even if you move a component over 5 pixels
A diff doesn't depend on whether something has shifted by 5 pixels, or whether there's some extra white space, or whatever. An Eidola diff would theoretically be more representative of actual changes to the code than even a textal diff.
programs must be kept small due to complex relationships obscuring parts of the code
Programs don't need to be kept small, because traditional textual representation is always an option. It is actually the problems that text has representing large-scale structure which I would like to minimize with Eidola. Don't picture a screen with a hundred boxes and a thousand arrows -- that's bad notation, even worse than text. A notation system should be at least as good as pure text.
no matter how revolutionary you get, you still must be able to form logic gates, and so it all boils down to a text-version
I think what you mean is it always could be translated to a text version, which is quite true. A program always has a particular representation if it's on a computer -- maybe it's a textual syntax, a binary file format, an object model, a database schema.... The idea of representation independence is that all these are equivalent, because they all answer to the same mathematical description. So you can switch representations with no information loss.
For more information, see my answers to common Slashdot questions.
There are no visual parts to Eidola yet because it is a very young project.
I think when you talk about "complicated text", you are looking at the semantics. The semantics is not what the language would look like, and it's not something that most programmers would deal with directly.
I suggest you skim my answers to common comments about Eidola on Slashdot, which might clear up some of your confusion.
Eidola is not VB... may the Thundering Sky Demons smite me if it is. VB is just a GUI layer that sometimes mostly hides a textual language underneath. Neither the textual nor the graphical part is representation independent.
I suggest you skim my answers to common comments about Eidola on Slashdot, which covers this.
Slashdot Mirror
Actually, you don't need to look to something as radical as logic to see the source of Dr. Laura's allegedly moral objections to porn.
It turns out that her attacks on the American Library Association and pornography in libraries began, by a strange coincidence, shortly after some amateur porn photos she'd done during an extramarital affair in the 70s leaked onto the net (search on "Dr. Laura Naked" to find the uncensored version). She sued over the photos, but the suit was dropped. Interestingly, the porn company that bought the photos also brought a lawsuit against the amateur sites which posted them. There was a great interview with the guy who took the photos which I'm afraid I can't find. He talked about her "sleeping her way to the top" of the radio industry.
Whenever somebody takes the moral high ground in attacking others, I immediately suspect them of doing the same. "Let he who is without sin cast the first stone," as I'm sure Dr. Laura herself would quote.
See also the Stop Dr. Laura site for further amusements.
There is certainly a glut of command-line tools, though. The problem with the 1000 UN*X apps is that
But I suppose this happy mess is really in the nature of a sort of the Darwinian free-for-all of UN*X.
I'd really like to see a shell built on a single powerful set of list and pure function operations that would neatly generalize pipes, redirects, backquotes and lots of command-specific features into a single, more general scheme. It's silly that I have to know about the output format of ps to kill all processes with some specific thing in the command line:
kill `ps -ef | grep nuj | cut -c9-15`
I should really be able to say something like:
kill (ps ? (#.cmd==nuj)).pid
...where ps just outputs some list of named hashes, and I don't have to play ASCII games or know anything about the format of its output.
-END OF PONTIFICATION-
Some random thoughts in the spirit of this discussion: We often judge user interfaces by their feature sets. More features mean more power, and are better, right? I think not. I actually want my software to have a minimal feature set which is maximally robust.
The idea behind building feature-rich software runs something like this: figure out what a program will generally be used for, and come up with a set of tasks -- use cases -- which are representative of what the majority of users will want to do with the software. Design the software around the use cases, using the ease and efficiency of each of the use cases as a yardstick for the program's success. If users demand more features, the market for the software expands, or the company simply has more resources to build up the software, then add more use cases and repeat.
This works reasonably well, but it has a serious flaw: as the amount of functionality and thus the number of use cases go to infinity, the number of features goes to infinity. Think of M$ Word -- at a certain point, the wizard that will make multi-column address labels is useless to me, because there are so many damned wizards I don't know where to find it.
What software really should try to do is maximize robustness while minimizing the feature set that achieves that functionality. If you want your software to achieve a wider base of functionality, you have to make your interface's features more generalized, and more expressive. As the amount of functionality goes to infinity, the feature set stays bounded, and just approaches some sort of Turing-complete programming language.
So when designing software, don't ask "What features should we add?" Ask "What functionality can we add, and what features can we generalize in the hope of removing others?"
I realize that this is all very idealistic, but it seems like a guiding principle that could keep software bloat in check.
This statement is a model of good writing: it's clear, accurate, to the point, elegantly phrased, and neatly addresses every issue that Mundie's speech raised. Your rambling criticism does its authors a disservice.
Explain, please: how is the statement "weak"? Would you prefer that they had responded with Mundie-style drivel? Would you rather that the response read like a flame on Slashdot? Thanks goodness our "open source luminaries" can come up with better writing than you just did, or than I am right now! Sheesh!
(1) That's "global" in the sense of "worldwide", not "universal". Certainly there is worldwide enthusiasm for the idea of free software. And yes, you are right, that enthusiasm is not universal.
(2) No, not everybody is running Linux. Linux != free software in general, however, and this discussion is about free software, particularly the GPL. A great many people are using free software, and virtually everyone on the internet interacts with it.
So, in short "global enthusiasm for free software" is not the same as "everyone and their brother is running linux". Please check your troll at the door.
A number of the free software evangelists, in informal discussion, felt that the proper response to Microsoft would be to stand together. Mundie's speech shows that Microsoft's strategy is to keep us divided and attack us one at a time, until all are gone.
Right on.
The current global enthusiasm for both free and open-source software amounts to diddly if the proponents of these ideas can't present a united front. When the software community responds to something like Mundie's speech or the DMCA with a thousand flame wars in the underbelly of the Internet...well, guess what: nobody cares. When we respond with consensus -- especially with such a thoughtful, articulate, and nail-on-the-head treatise as this one -- then we have a chance of getting somewhere!
My thanks and respect to this document's ten signers. I wish I could sign it, too, or at least give them all +5 karma.
Sounds great! I've never used Mandrake, but it sounds like I should. I've seen some update features on other Linux distros, but they haven't been as well-organized or as carefully considered as Apple's.
...these would be minor modifications to the existing system.
Mandrake folks: Do it! Don't hold back! Right now, OS X is way ahead of Linux for usability (sorry, but it's true). But a lot of the good work that Apple has done would not be such a stretch for Linux; much of it would require, as you say, only minor modifications. The Linux community should be studying OS X under a microscope and ripping off every one of Apple's insights. If Linux, which is faster, stabler, more efficient, and has a wider base of software than OS X, could also be as user friendly...well, I'll stop there before I get into rampant speculation.
If I can get a painless, nearly-transparent bug or security fix the moment it's ready for prime time just by clicking "update", I'm a happy camper. I'm puzzled by this assertion that every two weeks is too much.
An update scheme such as OS X's should meet the following criteria:
I'm using OS X as my primary OS, and so far, Apple has done an absolutely outstanding job with 1, 2, 4, 5, and 6. Only #3 is week -- the only explanation you see when an update is available is "OS X 10.0.3". You have to install the update then try to divine what's changed. If Apple fixes this problem, they'll have a killer mechanism that Linux distros would do well to study.
...is Interwoven's Teamsite. My impression is that it's more geared to building web sites than internal documentation, but it still might interest you.
T-Ranger is right -- you'll probably have to spend some big bucks here, at least as things currently stand. This sounds like a good free software project for some enterprising programmer out there...!
I'm tempted, like many of the other posts, to say "screw the bastards; they dissed you, so you can do the same back."
However, if there is a hack, it's not just the decision-makers who will feel the pain. You said a hacker has access to employee names, SSNs, fire dates...and most of these belong to people who had nothing to do with choosing or implementing this bad system. OK, probably the hack will come from some kid with no malicious plans for the compromised data...but what if this personal information lead to identity theft? What if information about a firing were leaked to a potential employer?
Forget the contract -- you lost it. But you have information about a serious potential threat to several hundred people. Isn't there some ethical obligation to the innocent employees whose privacy is on the line here?
There are two essentially different ways of approaching the problem of learning to program.
Philosophy #1 says, "In the ever-changing world of technology, you should leave college knowing all of the most cutting-edge technologies." Programs that emphasize this tend to have courses in specific programming languages and tools, e.g. "Advanced C++".
Philosophy #2 says (I think rightly), "Technology is such a large world and is changing so fast, any languages or tools you learn now will be useful for somewhere between five years and three seconds. What's really important is that students are able to learn and adapt quickly, and solve problems creatively." These programs tend to have much more theoretical curricula, which emphasize extensive and somewhat open-ended projects.
Programs of the #2 ilk take a lot of abuse: "Why do I have to learn this dumb language (Scheme/SML/Eiffel/whatever) that I'll never use?" Such complaints miss the Big Secret of Programming: for all the vast differences in quality and popularity, most languages and software tools are essentially the same, and when you know one, it's easy to pick up another. The best programmers are the ones who can adapt quickly and be creative, not the ones who know the top 10 hottest languages. Smart companies know this, and will be much more impressed with your ability to catch on quickly than your textbook knowledge of their favorite language. It's trite but overwhelmingly true: in programming, ideas are more important than facts, and imagination is more important than knowledge.
If your program is using Eiffel, they're probably leaning toward Philosophy #2. Whether Eiffel is useful to you depends a lot on how you approach the program. If you expect school to be a practice run for your job...forget it! That's what internships are for. If you get excited about the ideas, and constantly look for ways to challenge yourself, bend the assignments around, and just have fun with everything you can get your hands on...well, now you're in business!
I actually got ordained by the ULC online, and married a couple of friends...er, rather, I officiated their ceremony. The ordination was free, though I did have to give the state of MN $5 to register myself as a reverend and make the marriage legal.
I haven't received any spam from the ULC, other than their single initial response explaining the exciting do-it-yourself spirituality kits they sell.
In short: it may be hokey, but it's quite legit, and highly recommended if you're looking for a wedding of the beaten path!
Rev. Paul
..software with a license of use that guarantees the user, without an extra fee, the following rights: ...
5. Modification of the program, and free distribution of the modifications and the resulting new program, under these same conditions.
That's a sticky phrasing; perhaps it's partly the translation. Does this mean that the user has the right to free redistribution, or that the license must guarantee free redistribution?
It it's the latter, this law would seem to prohibit BSD-style licenses, which allow users to redistribute the software with proprietary modifications. I'd say that would cross the line into ideological crusading inappropriate for a government...though I doubt that's what they intended.
Is the original Spanish available, and can somebody understand it well enough to clarify?
I'm sure there are going to be a lot posts saying things like, "What's the point of this? Why are you bothering? Who needs another programming language? Everything you are doing has already been done better, and it was all useless anyway." I got a lot of that crap when Eidola was Slashdotted recently.
Keep an open mind. If you're not the sort of person who can enjoy new ideas that are cool but may turn out to be useless, just go read another thread.
There's an interesting study about the much-abused field of visual programming languages. The researchers polled programmers who worked with visual and non-visual languages to see which they liked best, and which was most effective. Their main result? Programmers' opinions of a language correlated strongly with how long they'd been using it. In other word, programmers have an overwhelmingly strong bias for the familiar; they are so strongly biased towards what they are used to that they can't really make objective judgements about unfamiliar ideas. Not surprising, but easy to forget!
This bias is a tremendous barrier to new technology. If everyone with an interesting but questionable idea gets shouted down, a lot of useful ideas are lost. Think of the brave souls who installed Linux before it was really usable while everyone was saying "OSes have been done before. Why are you bothering?"...and thank them now.
Then give Mozart and LX a fair hearing. There are some good ideas there; let's help them mature.
Yeah, for example.
So he's looking at his predecessors and thinking, "Boy were they wrong. What give?" I think that's a fair question, especially since he's in the same game.
Katz once again has believed the market hype of the media whores who pushed the whole "internet will change all our lives".
That's quite unfair to Katz. In the net's early days, and even before computers, many people made all sorts of utopian predictions about technology and massive information access. Unsurprisingly, many of those predictions failed. He's drawing on sci fi authors, media pundits, prominent scienists and hackers, etc. Katz is not saying that he personally expected all this great stuff to happen.
Rather, he's asking us to think about some of the original idealism of self-styled net philosophers. Was it completely unrealistic? Or did we miss the boat on something wonderful?
If asynchronous chips became popular, it might help further debate on the difficult question of what makes "fast" fast. The common number, MHz, is of course pretty meaningless -- sort of like measuring the speed of a car by the RPMs. (If you've got the same model of car in the same gear, it's a meaningful comparison. But is a G4 at 500 MHz exactly five times as fast as a 486 at 100? What does "five times as fast" mean anyway?)
...Or not -- there are obvious and equally meaningless alternatives for asynchronous chips, like FLOPS, or LOPS (Logical Ops Per Sec).
Making the familiar measurement meaningless might put more emphasis on benchmarks, and give more impetus for getting them better standardized and more meaningful.
Were consumers demonstrably harmed by Microsoft? If so, how?
... Java, Linux, Netscape ... Is it necessary to give your product away for free to fight Microsoft to the point where they will resort to writing good software?
I'd argue that they have, by creating a technological and psychological climate which has made it very difficult for software to compete on the grounds of quality, both by maintaining a public perception that Microsoft is a stellar example of "innovation", and by squashing competitors who threatened this perception. No single company has done more to stifle the innovation of software than Microsoft. That's certainly harmful to consumers.
Of course, the consumers brought it on themselves. It's arguable whether we can blame Microsoft for taking advantage of their complacent, manipulable consumer base. Ripe bastardism is the captialist way, after all. There's a certain philosophical dissonance to anti-trust laws...they're a sort of pacifier to help us believe that capitalism is somehow fair. The market does not value fairness.
"Democracy is two wolves and a sheep deciding what's for dinner. Capitalism is the wolves just eating the sheep."
The software quality situation is improving. Microsoft's own products are better than they use to be, and they are increasingly having to scramble because of competition on the quality continuum. Java and Linux are good examples of products which are succeeding because in large part because they are really good software. That's encouraging.
It's interesting that the government went after Internet Explorer, one of the best products Microsoft makes. It's also interesting that IE is one of the best. Hmmm
You will not see this kernel representation. You can only manipulate it through the various, er, representations of it.
Well, you always have to use some kind of representation, unless you have psychic powers which can just twiddle bits in memory.
Since you have a choice of notation systems, you should have some that are very low-level and close to the bone, showing you exactly what's going on. The purpose of a notation is not to hide the messy stuff, unless you want it hidden for the moment.
The kernel representation...will not be fully specified, which means that programs written in one Eidola environment will not be compilable in a different Eidola environment.
No, actually, the whole idea of having a formally specified semantics is that you don't have this problem. If you say, "This kernel implements the semantics", that's a very strong statement. If another kernel also implements it, and if they have a common interchange format, no problem. That's the idea.
Based on my very limited knowledge of Lisp, I'd say that READ is getting at something very similar. Certainly Lisp's semantics is also a representation-independent idea.
If there's a major difference in Eidola, it's that the language's design emphasizes making this structure available at edit time. That's what the kernel is doing -- it's like READ, only instead of being a unidirectional translation from representation to structure, it's an interactive translator with a big multithreaded event-based observer model, and fancy-sounding crap like that.
You are right -- all programs have a meaning which is separable from their syntax/representation.
The Eidola idea is just to take this into account from the start when designing a language, and take advantage of it.
And they have ZERO examples of any good Eidola code! Maybe some white knight will step in and write some good representation engines for them?
Uh, Eidola guys, you might want to spend a few more days thinking before calling for help.
From my FAQ for this article:
Well, duh. Before a project is finished, it's unfinished. This is a project in its very, very early stages. Eidola is very far from being a complete language, and obviously there are a lot of major missing pieces! Consider the ideas that are there now; others will come in time.
I cannot emphasize enough: Eidola is a young project. It is vaporware. It is mostly theory. Bear with it -- these things take time to grow.
Slashdot rang the doorbell on Eidola while it was still in the shower, naked, unshaved, and only half-soaped. It's not quite ready to go out on the town. So take it all in that context. If you can't deal and demand to see it finished, check back on the Eidola site in ten years.
You are presuming that "representation independence" means "graphical", which is not right.
Representation independence means that a program is stored in a form that doesn't presume anything about how it's represented -- no textual syntax, no graphical positioning. Display information like that might be attached to the code in the form of optional display hints, but the code itself is just program structure, nothing else.
how do you compare (i.e. diff) two graphic programs? You must rely on its binary form, and hope its equivalent even if you move a component over 5 pixels
A diff doesn't depend on whether something has shifted by 5 pixels, or whether there's some extra white space, or whatever. An Eidola diff would theoretically be more representative of actual changes to the code than even a textal diff.
programs must be kept small due to complex relationships obscuring parts of the code
Programs don't need to be kept small, because traditional textual representation is always an option. It is actually the problems that text has representing large-scale structure which I would like to minimize with Eidola. Don't picture a screen with a hundred boxes and a thousand arrows -- that's bad notation, even worse than text. A notation system should be at least as good as pure text.
no matter how revolutionary you get, you still must be able to form logic gates, and so it all boils down to a text-version
I think what you mean is it always could be translated to a text version, which is quite true. A program always has a particular representation if it's on a computer -- maybe it's a textual syntax, a binary file format, an object model, a database schema.... The idea of representation independence is that all these are equivalent, because they all answer to the same mathematical description. So you can switch representations with no information loss.
For more information, see my answers to common Slashdot questions.
There are no visual parts to Eidola yet because it is a very young project.
I think when you talk about "complicated text", you are looking at the semantics. The semantics is not what the language would look like, and it's not something that most programmers would deal with directly.
I suggest you skim my answers to common comments about Eidola on Slashdot, which might clear up some of your confusion.
Eidola is not VB ... may the Thundering Sky Demons smite me if it is. VB is just a GUI layer that sometimes mostly hides a textual language underneath. Neither the textual nor the graphical part is representation independent.
I suggest you skim my answers to common comments about Eidola on Slashdot, which covers this.