Several comments here point out that this kind of weak security can be circumvented in various ways, not necessarily requiring sophisticated hackery, allowing some users to defeat the content usage restrictions. True indeed, as a security measure it is weak. But for commercial purposes, this approach may be enough. To succeed, they don't have to block EVERY violation, but just make it a bit harder to violate such that violations aren't dramatically reducing sales.
By example, if Napster hadn't been so widespread and easy to use -- if we were just exchanging MP3's via email, for example -- I bet the landscape would look quite different, because MP3 exchange wouldn't be seen as such a threat to copyrights and royalties.
I hate technologies that restrict what strikes me as 'fair use,' that restrict the free exchange of ideas, or that treat something that appears commonsensical and public-domain as if if were proprietary.
That being said, I won't dismiss the commercial value of easy-to-defeat restrictions. If 90% of the end users are perpetually confused, then taking the 'save as' button away from a.pdf file provides a statistical measure of protection -- even if 10% of the community can figure out how to make a copy, and 1% knows how to hack the.pdf content.
Can you imagine having missed this story? What could be more important or hilarious than a nerdgram about sending IP via carrier pigeon? Thank you, slashdot, for providing a forum where such vital news can be shared by geeks everywhere.
Thermoelectric sounds like a good approach. But are there cheap thermoelectric generators? I've never heard of one, but that doesn't mean anything. Of course, a magneto is a cheap, easily-available component that might be the no-brain approach.
Good point. I should have said, "having the time of their lives, at this time in their lives."
Of course, guys like that manage to have a great time digging into whatever happens to be the problem of the moment. And nobody can die as a result of this particular venture (unless it crashes into something, heaven forfend!) so I can imagine it might be more enjoyable even if not as huge an undertaking.
Remember they have a little 1Hp internal combustion engine. It could generate electricity pretty cheaply and efficiently. Or a little cellphone lithium-ion battery should give plenty of juice. I doubt they're maintaining continuous contact in either direction. Some of the earlier posts suggest the plane is being operated by remote control, like those lame battling robots on TV. But I'm sure the computers are there to make this thing semi-autonomous, checking GPS fixes and sending return telemetry at relatively infrequent intervals (i.e. not constantly) to keep radio use down. The thing is steering from waypoint to waypoint, like commercial autopilots, maintaining a predefined flight profile without somebody steering the thing.
This project is so cool, I'm sure these guys are having the time of their lives.
Exactly right. Somebody should mod that comment up.
It seems quite obvious that publishing sheet music online without approval is a copyright violation, no different from publishing somebody's novel or poetry. (As you point out, if one objects to copyrights in general, and intellectual property rights, that's a totally different argument. It's also a tough fight considering the current worldwide body of law.)
Publishing tablature is the same thing as publishing [other] sheet music, except it's intended for musical illiterates. There's no shame in being unable to read music, but surely the distinction between traditional musical notation and tablature isn't so much greater than the difference between HTML and ASCII text. "It isn't a copyright violation because I published in in Arial instead of Garamond."
Sheesh.
By all means, publish tablature to your heart's content for music you have a right to distribute -- things in the public domain and things you write yourself. We can always use more new music. Just don't steal from the guy who chooses to publish music for a living through resources like Harry Fox.
that's hardly revolutionary - the idea of composition of functions...precedes computers by a long way -- greenrd
Indeed. I didn't articulate my point properly. I was admiring the use of a dataflow metaphor (a | b | c) to control a system instead of using function composition (c(b(a()))) or temporary data. The idea of redirecting inputs and outputs was surely a paradigm change from earlier command languages, and it proved a good way to simplify the interfaces among a large class of interactive tools.
[Interfaces are a] great contribution, but they are fundamentally shallow for many kinds of complex systems.
Again, I was not thinking in the narrow sense of 'interface' as a specific language mechanism, but the general sense of decomposition and implementation-hiding through formal interface contracts at the metadata level. I believe that this is the underlying goal of most design and analysis methodologies, and is a great intellectual tool. I suppose we can attribute the germ of this idea to the Aristotelian tradition, which has indeed proven a fruitful way of developing simplified models of the world.
I realize these are basically platitudes, but sometimes I find platitudes quite interesting nevertheless.
JMHO -- Trevor
Re:Borders in the Stellar Theme Park??
on
Tito In Space
·
· Score: 1
What benefit to mankind is he performing up there? -- shokk
Defraying $20M of the cost of Russian participation in the program. Is it worth it to the program? Tough call. For $200K, obviously not. For $5B dollars, Bill Gates could definitely have a ride. At $20M, he's probably contributing more than he's taking, though it's just a guess on my part.
This doesn't seem like such a big deal to me. It would be different if it were secret payola disrupting the system, or if he were Dr. Evil. But it seems fairly above-board.
I didn't mean to imply that you hadn't addressed these issues -- I agree that the LX and Mozart designs address many of my wish-list items. I was providing first-blush comments on metadesign issues that seemed important, mostly from past experience, before I made a detailed study of your design (which I thought might be helpful -- but RTFM is usually good advice, and in hindsight I was probably wrong to use 'ready, shoot, aim' as my approach).
Anyway, two further comments:
1) I'm uncomfortable with end-of-line as a statement separator, and with indentation as structure control. It seems we're mixing lexical/expressive/publication issues with language syntax. The issue of cleanly disambiguating program structure always seems to me more a problem for the development environment than for the language syntax. At least, please be sure that long expressions can be spread over multiple lines with interleaved comments, and that short blocks can be expressed on a single line without resorting to '(a ? b : c)' or the like.
2) There's always a tradeoff between flexibility and consistency. It's clear that LX lets us create new sublanguage dialects (e.g. by creating new infix operators, and other richly overloaded syntax). I'm afraid that one person's coding conventions could easily create code that is incomprehensible to another. I'm sure this flexibility is a design goal, or a byproduct of one, but a language capable of being all things to all people loses its charm of simplicity and readability.
Others have pointed out here that creating a new language is not to be undertaken lightly. I don't agree that there's no reason to do so, because all our existing tools suffer from certain expressive problems that limit our ability to create and manage large, complex systems. Correcting these limitations is a stated purpose for Mozart. However, in your designs I still see a muddling of issues: programming environment, language syntax, design methodology, metadata distribution, documentation, modularity/separate compilation, etc. It's hard to draw the lines in the right places. (I don't mean you've created muddled designs, but that the issues themselves are so deeply threaded. I'm not convinced that we've cut to the core issues yet.)
Think about what we love about the Lambda calculus and about algebraic notation. Each is a simple formalism, easily defined and used, providing limitless expressive power. I still yearn for a comparable underpinning for constructing robust computer systems -- a meta-LX, if you will. (Perhaps something like this is already part of the spec, and I'm just seeing the leaves of the tree rather than the trunk.) But before any Lispites and Schemites and Mary programmers raise their hands: my dream-language would (somehow) not lead to systems that can only be created and maintained by visionaries. It must somehow simplify the development problem in a way that pure lambda calculus or pure message-passing don't seem to do for most humans.
Anyway, I see this project as very useful and important, even though in many ways you're tilting at windmills.
Bravo. This is the right set of questions to ask anybody embarking on a language design project. I couldn't resist making an earlier comment about the things I wish had been present in the last few broad-applicability languages I was using, but you're right, even though there is plenty wrong with today's languages the solution is (probably) not Yet Another Language Standard.
Aside: Here's my favorite example of an ideal match between a language construct and a semantic behavior: typing a command line with a bunch of pipes and forks. "ls | grep | foo | more" was such a leap forward from manually naming and manipulating temporary files. It lets us control a complex suite of functions through a very simple interface model. Interface specifications are our great contribution to the advancement of knowledge. They let us take a complex system, and simplify its behavior and definition by organizing it in terms of independent components. And yet interface definition, management, publication, and revision is one of the things we've done worst through the years.
Here are a few random comments, based on a history of having designed many languages through the years (none of which you've ever heard about). I hope this isn't considered too bloated a comment; sorry if it pisses you off, but I find the topic so interesting.
Comments. Make it really easy to provide strong in-line documentation. Don't, for example, emulate whatever brain-dead folks at M$ are responsible for VB still not permitting comments after the "_" used for line continuations, making it impossible to have function parameters documented one-per-line. Consider multiple documentation-related conventions, e.g. "//" for end-of-line comments, perhaps support for standardized structured comment blocks in preambles, ways to comment-out and uncomment blocks of code, ways to group sets of procedures, ways to draw separator lines etc. within listings (printed listings are still useful even in this day and age), ways to generate indices/crossrefs etc. Think of it as an algorithm publication problem.
PL/1 disease. You've proposed lots of good features. However, as others have pointed out, it will be easy to overload the language with a bazillion keywords and features to satsify every participant's biases. At the end, there will be n separate incarnations of the language, consisting of each user's set of preferred constructs. Nobody will really grasp the whole thing. Instead, strive for the kind of expressive purity of C (better: LISP), where a small number of primitive syntactic components can yield a rich semantics. It's a hard problem, and frankly a collaborative effort rarely can yield the conceptual purity that a single author can impart. But don't give up.
Extensibility. The most useful languages (IMO) can be extended to suit new situations. In many complex environments, it's better to adapt the language of the solution to match the language of the problem. This is why meaningful names, operator overloading, shared libraries, named constants, preprocessor definitions etc. are so helpful -- you can extend a language's working suite of concepts by documenting the specific interfaces used to interact with a particular execution environment or problem domain. So, for example, resist including I/O primitives and instead make it easy to create extensions from within the language. (Why consider them extensions rather than just traditional function calls? So that we can specify compile-time properties and behavior for their interfaces, such as argument marshalling, synchronization, error handling, exception conditions, etc., without bloating the runtime environment.)
Encapsulation. We should always be able to replace a named entity that appears to be an atomic value (integer, string, etc.) with a named property having a complex programmatic implementation, with either compile-time or run-time behavior. Such a replacement should be transparent to clients of the associated interface or name. Preferably, this should be possible within a narrow lexical scope, not just between packages or interfaces.
Integrated data definition/metadata. Try to bridge the gulf between the language's internal namespace and the external database environment. It should be anathema to reference entities using names stored or specified as character strings ("MyDatabase.OpenTable('Employees').Fields('SSN')" as we must do in so many languages when referencing external data). Instead, somehow let us bind the external data definitions into the compiler's namespace, so that referring to "Employees.FirstNaame" generates a compile-time error. (Obviously, we need to control the binding semantics so that in some cases this occurs at run-time, in some cases at link/load time, in some cases at compile-time, in some cases at preprocessing time.) Ideally, the same mechanism should support run-time interfaces to external resources such as CORBA components, including run-time retrieval of interface metadata.
Incremental compilation. Design the interactive programming environment, the language, and the compiler together, a la Smalltalk, rather than using the raw source code paradigm. Assume that we'll want the ability to dereference variables, determine variable scope, jump to definitions, view cross-references, etc., all while editing the source. This isn't really a language design issue, other than putting an emphasis on components that support separate compilation. But if you build your first compiler this way, e.g. via a p-code implementation, all your successor environments will preserve the interactive development model rather than the batch compilation model.
Explicit declaration and lexical scope. Help us find those dangling/incorrect references.
Constants and other compile-time tools. Give us strong support for creating highly-readable code that nevertheless can compile efficiently into in-line code and integer arithmetic. Combining the ability to drill-down to the physical machine with high-level encapsulation and incremental compilation would give us a wonderful span of control. (This is what we love about Smalltalk, being able to hack the running device drivers from inside the source code editor.)
Asynchrony, continuation-passing, message-passing, interrupts, critical sections, real-time constraints, shared memory, etc. Give serious thought to how deep issues of OS programming would be handled. If possible, address such issues through highly-visible fundamental mechanisms rather than hacks. For example, if you want to provide a way for two execution threads to share write access to a variable, implement some kind of encapsulation that provides well-defined interfaces and behaviors, rather than permitting indeterminate and possibly system-crashing results by making it look like a normal variable.
Well, that's enough blather for the moment. I hope these comments are useful. A few inspirations I'd love for you to consider in language design: C and BLIS, for their conceptual simplicity; Cedar, for its richness and language/environment integration; Smalltalk, for its extensibility and structural encouragement of small code fragments rather than monolithic procedures; CLU (and Simula and Smalltalk and SQL-embedded languages) for integration of external and internal data.
What irony here. If you have a VB problem you need to contac the VB tech support people? Damn, that's too complicated. -- Mike Buddha
Uh, considering that VB components and VB use are integral parts of MSAccess, that VB under MSAccess is QUITE DIFFERENT from stand-alone VB, that you can't do anything serious with MSAccess without using VB, that MSAccess documentation blurs the line between MSAccess and VB, and VB support guys are equally happy to punt the problem when they hear that Access was involved, no, I don't think calling the Access support number was a stupid thing to do.
It would be different if he were trying to use the VB stand-alone product to manipulate a Jet.mdb database. But if you buy a box marked "MSAccess" and it lists a telephone support number for that product, I'd say it's a reasonable choice to call for Access support.
If the DMCA is not used to stifle academic research on cryptography then it is worthless.... What are the ethics of providing skeleton keys to the general public...? Should the researchers provide their information to some authority before providing it to the general public? -- AC
OK, I'll bite. I won't dispute your point that there are legitimate conflicts -- if there were only one reasonable side to the argument, the discussion wouldn't have continued this long.
But I must be sceptical about the idea of protecting public and private data via a war-on-crypto, analogous to our wildly successful war-on-drugs. Bad boys will continue to hack through every new security system, and keeping all this work underground prevents the rest of the world from a) knowing how many security holes exist, b) knowing how we might protect ourselves, and c)advancing the state of the art. A set of feel-good rules like our airline security system, inconvenient to everyone EXCEPT the pro bad guys who can work around them, doesn't help.
It is science, after all. Laws to restrict scientific enquiry don't have a good track record, on either ethical or practical grounds.
I will acknowledge that copyright protection issues are just one aspect of general hackery, but crypto is crypto and lessons in one area apply elsewhere.
The bottom line for me is pretty simple: I have no confidence in developing legal remedies as bandaids for technical and social problems. This is like saying "If you get wronged, seek restitution in court." Litigation and criminalization are hardly ever great choices and never happy ones. This is a case in point. We need to think more deeply about how the rights of authors and other content creators can be protected without implementing laws that shackle legitimate scientists or creating another set of Prohibition laws that don't make sense to the average consumer.
The solution, at least in the most frivolous cases, is loser pays. I would imagine that most courts would find against the RIAA at this point. If loser pays, then the RIAA would have to pay the legal expenses of these researchers. -- leviramsey
In the U.S. legal system, in nearly all cases, each side pays its own legal fees. We might feel we'd be better with the UK model, where the loser pays, but that's simply not the one we have. There are some specific U.S. law situations involving antitrust and intellectual property where the loser bears court costs, and of course a given contract may specify that the loser pays court costs; but in general, absent special conditions, each side pays its own way regardless of who wins, and the judge has no discretion about this.
I'm in precisely this situation. My (little) company has been screwed by a big company that has decided not to honor an agreement. We have about $200K in damages but it would cost $80-100K to litigate. Litigation is painful and invasive, and there's always a reasonable chance that we would lose, despite the fact that on the face of it we are the victims. So we will probably chalk it up to experience.
It's all well and good to say that these folks should stand up and fight the good fight. But it costs real dollars to do this, and it's disruptive and painful. I'd have been happy if they had chosen to fight, but I certainly can't second-guess their decisions. Litigation should always be the last desperate step after other measures have failed, and is never entered into lightly.
No, Scott Adams get his ideas from guys like this. In truckloads. Daily. He freely admits that all his comics are now based on stories sent to him by his readers. -- tb3
Well, plus his years of PacBell experience as a card-carrying nerd himself. He draws on a lot of his own battle scars -- otherwise he never could have become so funny.
naasking said: int* pi = (int*)malloc(sizeof(int));...is NOT correct even with the cast. It's valid, but not correct. That statement is requesting an int and assigning it to a pointer. That should read: int* pi = (int*)malloc(sizeof(int *));
or int pi = (int)malloc(sizeof(int));
Huh? As I read it, the original line is quite correct: malloc a chunk the size of an int, treat the return pointer as a pointer to int, and store that pointer as 'pi.' The result is a pointer to an int-size value.
Your two examples do something quite different. The first mallocs a chunk the size of a pointer, and makes 'pi' point to it (yet 'pi' is defined as a pointer to int, not a pointer to a pointer). The second mallocs a chunk the size of an int, treats the address as an int, and stores it on the stack. Neither of these seem to be the desired result.
Try rereading these. I don't think I skipped my coffee this morning.
- What's bimodal and brown? A chocolate-covered flip-flop.
On instruments like the violin or in voice, Db should be slightly higher than C#. -- Cpk71
You're opening a whole can of worms here! There are many who disagree violently with this assertion, maintaining that mean-tone tuning or any other deviation from equal temperment is a hopeless throwback to the seventeenth century. Certainly, if you play in a symphony or an ensemble in which equal temperment instruments participate, you'd better play/sing tempered fifths. Easley Blackwood was famous for berating string sections on this point.
Of course, if playing Irish fiddle tunes or singing madrigals, you're quite right -- use those pretty-sounding perfect intervals. But if you're playing Beethoven, Hindemith, or Thelonious Monk I'd stick to the tempered scale.
ROFL, didn't expect this conversation in this thread.
- What's bimodal and brown? A chocolate-covered flip-flop.
So how much do the reviewers charge for their reviewing services?.... Costs for doing page layout, typesetting, printing, and on-line distribution are low now, and getting lower.... What kind of real costs are there? -- tricorn
A typical reviewed publication has a combination of volunteer and professional staff together producing the end product. The volunteers, as you correctly conclude, are not compensated. But think for a moment about how much editorial time is needed to manage a database of reviewers, select the right subject-matter experts for each paper, send the papers for review, follow-up with the reviewers to see if they accept the assignment, bug them to get the reviews back, reassign the paper if the reviewer refuses the assignment or doesn't respond, send comments back to the author, etc. etc. It's a lengthy time-consuming process. Good-quality journals have multiple assignment editors, each with their own areas of expertise, responsible for a pool of thousands of possible reviewers (depending on how broad the scope is of the journal in question).
The professional staff might typically include an editor-in-chief, an executive editor (if the organization publishes multiple journals), one or more assistant editors, one or more assignment editors (though these may be volunteers), plus a few lower-level people who handle the workflow of sending out and receiving documents, copy editing, page layout, annual indices, coordinating conferences (where many of these papers are presented), etc.
At the end of the day, there's usually a small business infrastructure supporting the journal. Those salaries have to be paid. Publication and printing costs have to be paid. The logical source is subscription fees. If you take away subscription fees, you have to find another source, or cut out some of the costs.
Some journals have little or no professional staff, and rely on volunteers. Very few of these turn out a first-class result, for the obvious reasons.
JMHO, after spending plenty of time in the trenches with the mechanics of journal publication.
- What's bimodal and brown? A chocolate-covered flip-flop.
I've been hearing about these for a while, but to be honest I don't see how a honeynet will really help your network. -- ethereal
Presumably, these would be helpful for specialists and researchers, not for Joe Average Netgeek. If you're studying security issues in a comprehensive way, it makes sense that a honeynet could be a useful tool. It would also be a good testbed for simulated attacks. I don't think the authors were advocating that the general population set these things up all over the place.
This approach struck me as analogous to using a live stress test as part of a system deployment. There are some things you can only find out with real systems instead of emulators.
I might agree that the paper treats this as a more significant idea that the rest of us may think. But you can't blame the guys for wanting to describe it well -- would we prefer if they learned to stammer?
JMHO
Sometimes the only alternative is to get a different number. Yours probably shows up in some directories that are widely distributed. I've had this problem several times in the past, with fax numbers and cell phones that wouldn't stop ringing. There's a cost in changing the number but the odds are your problem will go away.
JMHO
PLUGH and XYZZY to you, eschasi.:) By the way, Compuserve was one of the big 10/20 holdouts where lots of machines ran System 1022 until the late 80's at least. Tatters of the Jupiter project were reportedly purchased and kept (briefly) alive through the financial support of the 1022 base.
Slashdot Mirror
Several comments here point out that this kind of weak security can be circumvented in various ways, not necessarily requiring sophisticated hackery, allowing some users to defeat the content usage restrictions. True indeed, as a security measure it is weak. But for commercial purposes, this approach may be enough. To succeed, they don't have to block EVERY violation, but just make it a bit harder to violate such that violations aren't dramatically reducing sales.
.pdf file provides a statistical measure of protection -- even if 10% of the community can figure out how to make a copy, and 1% knows how to hack the .pdf content.
By example, if Napster hadn't been so widespread and easy to use -- if we were just exchanging MP3's via email, for example -- I bet the landscape would look quite different, because MP3 exchange wouldn't be seen as such a threat to copyrights and royalties.
I hate technologies that restrict what strikes me as 'fair use,' that restrict the free exchange of ideas, or that treat something that appears commonsensical and public-domain as if if were proprietary.
That being said, I won't dismiss the commercial value of easy-to-defeat restrictions. If 90% of the end users are perpetually confused, then taking the 'save as' button away from a
JMHO -- Trevor
Can you imagine having missed this story? What could be more important or hilarious than a nerdgram about sending IP via carrier pigeon? Thank you, slashdot, for providing a forum where such vital news can be shared by geeks everywhere.
Thermoelectric sounds like a good approach. But are there cheap thermoelectric generators? I've never heard of one, but that doesn't mean anything. Of course, a magneto is a cheap, easily-available component that might be the no-brain approach.
Good point. I should have said, "having the time of their lives, at this time in their lives."
Of course, guys like that manage to have a great time digging into whatever happens to be the problem of the moment. And nobody can die as a result of this particular venture (unless it crashes into something, heaven forfend!) so I can imagine it might be more enjoyable even if not as huge an undertaking.
Plus batteries. -- krokodil
Remember they have a little 1Hp internal combustion engine. It could generate electricity pretty cheaply and efficiently. Or a little cellphone lithium-ion battery should give plenty of juice. I doubt they're maintaining continuous contact in either direction. Some of the earlier posts suggest the plane is being operated by remote control, like those lame battling robots on TV. But I'm sure the computers are there to make this thing semi-autonomous, checking GPS fixes and sending return telemetry at relatively infrequent intervals (i.e. not constantly) to keep radio use down. The thing is steering from waypoint to waypoint, like commercial autopilots, maintaining a predefined flight profile without somebody steering the thing.
This project is so cool, I'm sure these guys are having the time of their lives.
Exactly right. Somebody should mod that comment up.
It seems quite obvious that publishing sheet music online without approval is a copyright violation, no different from publishing somebody's novel or poetry. (As you point out, if one objects to copyrights in general, and intellectual property rights, that's a totally different argument. It's also a tough fight considering the current worldwide body of law.)
Publishing tablature is the same thing as publishing [other] sheet music, except it's intended for musical illiterates. There's no shame in being unable to read music, but surely the distinction between traditional musical notation and tablature isn't so much greater than the difference between HTML and ASCII text. "It isn't a copyright violation because I published in in Arial instead of Garamond."
Sheesh.
By all means, publish tablature to your heart's content for music you have a right to distribute -- things in the public domain and things you write yourself. We can always use more new music. Just don't steal from the guy who chooses to publish music for a living through resources like Harry Fox.
JMHO -- Trevor
Just to clarify --
that's hardly revolutionary - the idea of composition of functions...precedes computers by a long way -- greenrd
Indeed. I didn't articulate my point properly. I was admiring the use of a dataflow metaphor (a | b | c) to control a system instead of using function composition (c(b(a()))) or temporary data. The idea of redirecting inputs and outputs was surely a paradigm change from earlier command languages, and it proved a good way to simplify the interfaces among a large class of interactive tools.
[Interfaces are a] great contribution, but they are fundamentally shallow for many kinds of complex systems.
Again, I was not thinking in the narrow sense of 'interface' as a specific language mechanism, but the general sense of decomposition and implementation-hiding through formal interface contracts at the metadata level. I believe that this is the underlying goal of most design and analysis methodologies, and is a great intellectual tool. I suppose we can attribute the germ of this idea to the Aristotelian tradition, which has indeed proven a fruitful way of developing simplified models of the world.
I realize these are basically platitudes, but sometimes I find platitudes quite interesting nevertheless.
JMHO -- Trevor
What benefit to mankind is he performing up there? -- shokk
Defraying $20M of the cost of Russian participation in the program. Is it worth it to the program? Tough call. For $200K, obviously not. For $5B dollars, Bill Gates could definitely have a ride. At $20M, he's probably contributing more than he's taking, though it's just a guess on my part.
This doesn't seem like such a big deal to me. It would be different if it were secret payola disrupting the system, or if he were Dr. Evil. But it seems fairly above-board.
I didn't mean to imply that you hadn't addressed these issues -- I agree that the LX and Mozart designs address many of my wish-list items. I was providing first-blush comments on metadesign issues that seemed important, mostly from past experience, before I made a detailed study of your design (which I thought might be helpful -- but RTFM is usually good advice, and in hindsight I was probably wrong to use 'ready, shoot, aim' as my approach).
Anyway, two further comments:
1) I'm uncomfortable with end-of-line as a statement separator, and with indentation as structure control. It seems we're mixing lexical/expressive/publication issues with language syntax. The issue of cleanly disambiguating program structure always seems to me more a problem for the development environment than for the language syntax. At least, please be sure that long expressions can be spread over multiple lines with interleaved comments, and that short blocks can be expressed on a single line without resorting to '(a ? b : c)' or the like.
2) There's always a tradeoff between flexibility and consistency. It's clear that LX lets us create new sublanguage dialects (e.g. by creating new infix operators, and other richly overloaded syntax). I'm afraid that one person's coding conventions could easily create code that is incomprehensible to another. I'm sure this flexibility is a design goal, or a byproduct of one, but a language capable of being all things to all people loses its charm of simplicity and readability.
Others have pointed out here that creating a new language is not to be undertaken lightly. I don't agree that there's no reason to do so, because all our existing tools suffer from certain expressive problems that limit our ability to create and manage large, complex systems. Correcting these limitations is a stated purpose for Mozart. However, in your designs I still see a muddling of issues: programming environment, language syntax, design methodology, metadata distribution, documentation, modularity/separate compilation, etc. It's hard to draw the lines in the right places. (I don't mean you've created muddled designs, but that the issues themselves are so deeply threaded. I'm not convinced that we've cut to the core issues yet.)
Think about what we love about the Lambda calculus and about algebraic notation. Each is a simple formalism, easily defined and used, providing limitless expressive power. I still yearn for a comparable underpinning for constructing robust computer systems -- a meta-LX, if you will. (Perhaps something like this is already part of the spec, and I'm just seeing the leaves of the tree rather than the trunk.) But before any Lispites and Schemites and Mary programmers raise their hands: my dream-language would (somehow) not lead to systems that can only be created and maintained by visionaries. It must somehow simplify the development problem in a way that pure lambda calculus or pure message-passing don't seem to do for most humans.
Anyway, I see this project as very useful and important, even though in many ways you're tilting at windmills.
Bravo. This is the right set of questions to ask anybody embarking on a language design project. I couldn't resist making an earlier comment about the things I wish had been present in the last few broad-applicability languages I was using, but you're right, even though there is plenty wrong with today's languages the solution is (probably) not Yet Another Language Standard.
Aside: Here's my favorite example of an ideal match between a language construct and a semantic behavior: typing a command line with a bunch of pipes and forks. "ls | grep | foo | more" was such a leap forward from manually naming and manipulating temporary files. It lets us control a complex suite of functions through a very simple interface model. Interface specifications are our great contribution to the advancement of knowledge. They let us take a complex system, and simplify its behavior and definition by organizing it in terms of independent components. And yet interface definition, management, publication, and revision is one of the things we've done worst through the years.
JMHO - Trevor
Comments. Make it really easy to provide strong in-line documentation. Don't, for example, emulate whatever brain-dead folks at M$ are responsible for VB still not permitting comments after the "_" used for line continuations, making it impossible to have function parameters documented one-per-line. Consider multiple documentation-related conventions, e.g. "//" for end-of-line comments, perhaps support for standardized structured comment blocks in preambles, ways to comment-out and uncomment blocks of code, ways to group sets of procedures, ways to draw separator lines etc. within listings (printed listings are still useful even in this day and age), ways to generate indices/crossrefs etc. Think of it as an algorithm publication problem.
PL/1 disease. You've proposed lots of good features. However, as others have pointed out, it will be easy to overload the language with a bazillion keywords and features to satsify every participant's biases. At the end, there will be n separate incarnations of the language, consisting of each user's set of preferred constructs. Nobody will really grasp the whole thing. Instead, strive for the kind of expressive purity of C (better: LISP), where a small number of primitive syntactic components can yield a rich semantics. It's a hard problem, and frankly a collaborative effort rarely can yield the conceptual purity that a single author can impart. But don't give up.
Extensibility. The most useful languages (IMO) can be extended to suit new situations. In many complex environments, it's better to adapt the language of the solution to match the language of the problem. This is why meaningful names, operator overloading, shared libraries, named constants, preprocessor definitions etc. are so helpful -- you can extend a language's working suite of concepts by documenting the specific interfaces used to interact with a particular execution environment or problem domain. So, for example, resist including I/O primitives and instead make it easy to create extensions from within the language. (Why consider them extensions rather than just traditional function calls? So that we can specify compile-time properties and behavior for their interfaces, such as argument marshalling, synchronization, error handling, exception conditions, etc., without bloating the runtime environment.)
Encapsulation. We should always be able to replace a named entity that appears to be an atomic value (integer, string, etc.) with a named property having a complex programmatic implementation, with either compile-time or run-time behavior. Such a replacement should be transparent to clients of the associated interface or name. Preferably, this should be possible within a narrow lexical scope, not just between packages or interfaces.
Integrated data definition/metadata. Try to bridge the gulf between the language's internal namespace and the external database environment. It should be anathema to reference entities using names stored or specified as character strings ("MyDatabase.OpenTable('Employees').Fields('SSN')" as we must do in so many languages when referencing external data). Instead, somehow let us bind the external data definitions into the compiler's namespace, so that referring to "Employees.FirstNaame" generates a compile-time error. (Obviously, we need to control the binding semantics so that in some cases this occurs at run-time, in some cases at link/load time, in some cases at compile-time, in some cases at preprocessing time.) Ideally, the same mechanism should support run-time interfaces to external resources such as CORBA components, including run-time retrieval of interface metadata.
Incremental compilation. Design the interactive programming environment, the language, and the compiler together, a la Smalltalk, rather than using the raw source code paradigm. Assume that we'll want the ability to dereference variables, determine variable scope, jump to definitions, view cross-references, etc., all while editing the source. This isn't really a language design issue, other than putting an emphasis on components that support separate compilation. But if you build your first compiler this way, e.g. via a p-code implementation, all your successor environments will preserve the interactive development model rather than the batch compilation model.
Explicit declaration and lexical scope. Help us find those dangling/incorrect references.
Constants and other compile-time tools. Give us strong support for creating highly-readable code that nevertheless can compile efficiently into in-line code and integer arithmetic. Combining the ability to drill-down to the physical machine with high-level encapsulation and incremental compilation would give us a wonderful span of control. (This is what we love about Smalltalk, being able to hack the running device drivers from inside the source code editor.)
Asynchrony, continuation-passing, message-passing, interrupts, critical sections, real-time constraints, shared memory, etc. Give serious thought to how deep issues of OS programming would be handled. If possible, address such issues through highly-visible fundamental mechanisms rather than hacks. For example, if you want to provide a way for two execution threads to share write access to a variable, implement some kind of encapsulation that provides well-defined interfaces and behaviors, rather than permitting indeterminate and possibly system-crashing results by making it look like a normal variable.
Well, that's enough blather for the moment. I hope these comments are useful. A few inspirations I'd love for you to consider in language design: C and BLIS, for their conceptual simplicity; Cedar, for its richness and language/environment integration; Smalltalk, for its extensibility and structural encouragement of small code fragments rather than monolithic procedures; CLU (and Simula and Smalltalk and SQL-embedded languages) for integration of external and internal data.
Good luck. -- Trevor
The above link just rec's this post, don't click it unless you want to mod that one up. :)
We need a moderator option of "abuse" (or "goatsex") for flagging these. P)
How can you be in two places at once when you're not anywhere at all?
What irony here. If you have a VB problem you need to contac the VB tech support people? Damn, that's too complicated. -- Mike Buddha
.mdb database. But if you buy a box marked "MSAccess" and it lists a telephone support number for that product, I'd say it's a reasonable choice to call for Access support.
/rant
Uh, considering that VB components and VB use are integral parts of MSAccess, that VB under MSAccess is QUITE DIFFERENT from stand-alone VB, that you can't do anything serious with MSAccess without using VB, that MSAccess documentation blurs the line between MSAccess and VB, and VB support guys are equally happy to punt the problem when they hear that Access was involved, no, I don't think calling the Access support number was a stupid thing to do.
It would be different if he were trying to use the VB stand-alone product to manipulate a Jet
If the DMCA is not used to stifle academic research on cryptography then it is worthless.... What are the ethics of providing skeleton keys to the general public...? Should the researchers provide their information to some authority before providing it to the general public? -- AC
OK, I'll bite. I won't dispute your point that there are legitimate conflicts -- if there were only one reasonable side to the argument, the discussion wouldn't have continued this long.
But I must be sceptical about the idea of protecting public and private data via a war-on-crypto, analogous to our wildly successful war-on-drugs. Bad boys will continue to hack through every new security system, and keeping all this work underground prevents the rest of the world from a) knowing how many security holes exist, b) knowing how we might protect ourselves, and c)advancing the state of the art. A set of feel-good rules like our airline security system, inconvenient to everyone EXCEPT the pro bad guys who can work around them, doesn't help.
It is science, after all. Laws to restrict scientific enquiry don't have a good track record, on either ethical or practical grounds.
I will acknowledge that copyright protection issues are just one aspect of general hackery, but crypto is crypto and lessons in one area apply elsewhere.
The bottom line for me is pretty simple: I have no confidence in developing legal remedies as bandaids for technical and social problems. This is like saying "If you get wronged, seek restitution in court." Litigation and criminalization are hardly ever great choices and never happy ones. This is a case in point. We need to think more deeply about how the rights of authors and other content creators can be protected without implementing laws that shackle legitimate scientists or creating another set of Prohibition laws that don't make sense to the average consumer.
JMHO -- Trevor
The solution, at least in the most frivolous cases, is loser pays. I would imagine that most courts would find against the RIAA at this point. If loser pays, then the RIAA would have to pay the legal expenses of these researchers. -- leviramsey
In the U.S. legal system, in nearly all cases, each side pays its own legal fees. We might feel we'd be better with the UK model, where the loser pays, but that's simply not the one we have. There are some specific U.S. law situations involving antitrust and intellectual property where the loser bears court costs, and of course a given contract may specify that the loser pays court costs; but in general, absent special conditions, each side pays its own way regardless of who wins, and the judge has no discretion about this.
I'm in precisely this situation. My (little) company has been screwed by a big company that has decided not to honor an agreement. We have about $200K in damages but it would cost $80-100K to litigate. Litigation is painful and invasive, and there's always a reasonable chance that we would lose, despite the fact that on the face of it we are the victims. So we will probably chalk it up to experience.
It's all well and good to say that these folks should stand up and fight the good fight. But it costs real dollars to do this, and it's disruptive and painful. I'd have been happy if they had chosen to fight, but I certainly can't second-guess their decisions. Litigation should always be the last desperate step after other measures have failed, and is never entered into lightly.
JMHO and IANAL -- Trevor
No, Scott Adams get his ideas from guys like this. In truckloads. Daily. He freely admits that all his comics are now based on stories sent to him by his readers. -- tb3
Well, plus his years of PacBell experience as a card-carrying nerd himself. He draws on a lot of his own battle scars -- otherwise he never could have become so funny.
naasking said: int* pi = (int*)malloc(sizeof(int)); ...is NOT correct even with the cast. It's valid, but not correct. That statement is requesting an int and assigning it to a pointer. That should read:
int* pi = (int*)malloc(sizeof(int *));
or
int pi = (int)malloc(sizeof(int));
Huh? As I read it, the original line is quite correct: malloc a chunk the size of an int, treat the return pointer as a pointer to int, and store that pointer as 'pi.' The result is a pointer to an int-size value. Your two examples do something quite different. The first mallocs a chunk the size of a pointer, and makes 'pi' point to it (yet 'pi' is defined as a pointer to int, not a pointer to a pointer). The second mallocs a chunk the size of an int, treats the address as an int, and stores it on the stack. Neither of these seem to be the desired result.
Try rereading these. I don't think I skipped my coffee this morning.
- What's bimodal and brown? A chocolate-covered flip-flop.
On instruments like the violin or in voice, Db should be slightly higher than C#. -- Cpk71
You're opening a whole can of worms here! There are many who disagree violently with this assertion, maintaining that mean-tone tuning or any other deviation from equal temperment is a hopeless throwback to the seventeenth century. Certainly, if you play in a symphony or an ensemble in which equal temperment instruments participate, you'd better play/sing tempered fifths. Easley Blackwood was famous for berating string sections on this point.
Of course, if playing Irish fiddle tunes or singing madrigals, you're quite right -- use those pretty-sounding perfect intervals. But if you're playing Beethoven, Hindemith, or Thelonious Monk I'd stick to the tempered scale.
ROFL, didn't expect this conversation in this thread.
- What's bimodal and brown? A chocolate-covered flip-flop.
So how much do the reviewers charge for their reviewing services?.... Costs for doing page layout, typesetting, printing, and on-line distribution are low now, and getting lower.... What kind of real costs are there? -- tricorn
A typical reviewed publication has a combination of volunteer and professional staff together producing the end product. The volunteers, as you correctly conclude, are not compensated. But think for a moment about how much editorial time is needed to manage a database of reviewers, select the right subject-matter experts for each paper, send the papers for review, follow-up with the reviewers to see if they accept the assignment, bug them to get the reviews back, reassign the paper if the reviewer refuses the assignment or doesn't respond, send comments back to the author, etc. etc. It's a lengthy time-consuming process. Good-quality journals have multiple assignment editors, each with their own areas of expertise, responsible for a pool of thousands of possible reviewers (depending on how broad the scope is of the journal in question).
The professional staff might typically include an editor-in-chief, an executive editor (if the organization publishes multiple journals), one or more assistant editors, one or more assignment editors (though these may be volunteers), plus a few lower-level people who handle the workflow of sending out and receiving documents, copy editing, page layout, annual indices, coordinating conferences (where many of these papers are presented), etc.
At the end of the day, there's usually a small business infrastructure supporting the journal. Those salaries have to be paid. Publication and printing costs have to be paid. The logical source is subscription fees. If you take away subscription fees, you have to find another source, or cut out some of the costs.
Some journals have little or no professional staff, and rely on volunteers. Very few of these turn out a first-class result, for the obvious reasons.
JMHO, after spending plenty of time in the trenches with the mechanics of journal publication.
- What's bimodal and brown? A chocolate-covered flip-flop.
I've been hearing about these for a while, but to be honest I don't see how a honeynet will really help your network. -- ethereal
Presumably, these would be helpful for specialists and researchers, not for Joe Average Netgeek. If you're studying security issues in a comprehensive way, it makes sense that a honeynet could be a useful tool. It would also be a good testbed for simulated attacks. I don't think the authors were advocating that the general population set these things up all over the place.
This approach struck me as analogous to using a live stress test as part of a system deployment. There are some things you can only find out with real systems instead of emulators.
I might agree that the paper treats this as a more significant idea that the rest of us may think. But you can't blame the guys for wanting to describe it well -- would we prefer if they learned to stammer? JMHO
Sometimes the only alternative is to get a different number. Yours probably shows up in some directories that are widely distributed. I've had this problem several times in the past, with fax numbers and cell phones that wouldn't stop ringing. There's a cost in changing the number but the odds are your problem will go away. JMHO
PLUGH and XYZZY to you, eschasi. :) By the way, Compuserve was one of the big 10/20 holdouts where lots of machines ran System 1022 until the late 80's at least. Tatters of the Jupiter project were reportedly purchased and kept (briefly) alive through the financial support of the 1022 base.