Dtrace is useful for regular IT folks, i.e. people who don't read and write C every day?
I don't care about choosing an OS and toolkit for people that suck, I care about choosing a toolkit for me. Seriously. I'm responsible for maintaining the template that our servers (which run a *lot* of interdependent services -- Oracle, Tomcat, etc) are built off of. Finding and fixing performance problems in the template means that the low-level support folks have less angry customers on the phone -- and having the tools to find hard-to-locate issues on the deployed servers means customers' issues, once elevated, can get resolved quickly. Will the low-level support staff understand or use DTrace? Maybe not. Do I care? No. Right now I'm stuck using OProfile -- and while it's a good tool as far as it goes, I've seen what DTrace can do and I want some of that, damnit!
Error vomit is what some Level 3 support guys @ SUN in Bulington call it that I've spoken with, they dislike it for the reasons I've mentioned above.
They're not using it correctly, then. The whole point of folks writing scripts for DTrace is to provide the information one needs (as opposed to "vomit"). If you're using pre-canned scripts that spit out everything under the sun -- that's your problem, not the tool's.
In the case of the GPL, the restrictions are on rights which copyright law already prohibited (copying and production of derivative works). You have more rights than you would have if I simply gave you a copy without any license.
In the case of Visual Studio disallowing creation of a spreadsheet, the restrictions are on rights which copyright law (which, while it does regulate copying and production of derivative works, does not regulate use) wouldn't otherwise interfere with. You have less rights than you would have if I gave you a copy without any license.
One is more permissive than the default; one adds more restrictions than the default. Simple?
I'm not missing your point; your point is making bad assumptions.
The default action is nothing. Nothing means you grant no license, and keep your copyright rather than relinquishing it to the public domain. If you take an affirmative action to put something under the GPL, you're granting permission subject to restrictions. If you take an affirmative action to place it in the public domain, you're denying any future interest in that thing except as a member of the public. In any event, these are both affirmative actions: your work started off, the moment you created it, under copyright with no license provided. So, either action is granting a third party abilities they didn't have before. Is one more permissive than the other? Yes. Does that mean that the other one is reducing permissions? No; that's as silly as saying that I'm stealing from the poor because I haven't donated my car to charity.
And so does the GPL. That's what a license is for. Otherwise it would be public domain.
Not so. Otherwise, it would be a copyrighted work without any license granting you the right to copy, publicly perform, prepare derivative works, or take the other specific actions permitted by copyright law.
Unlicensed, copyrighted works are not public domain; rather, they're merely works the author gives you no permission to use. A license gives permission to engage in some of the actions that copyright law would otherwise prohibit; and though many make this conditional, all licenses by their nature give you permission to do something which you otherwise could not.
Maybe they're talking about hardware that, say... logs keystrokes, and can be summoned to retrieve them by a later software infection (or by a low-power radio request -- if these machines make it into an embassy or somesuch, it's entirely reasonable to have a feet-on-the-ground representative carry a piece of hardware that transfers the logs off the box).
Look at some of the ways the US bugged equipment exported to Russia during the cold war -- there's a lot of ingenuity going on there.
Do licenses try to screw those who accept it over? Licenses mostly screw people who violate it over.
Commercial software licenses typically disallow a substantial range of actions which would otherwise be permitted by law (copyright and otherwise). Some people would describe this as screwing over the acceptee -- and in several cases (such as licenses in which the licensor is given permission to arbitrarily modify the licensee's computer, to pick an extreme but increasingly common case), it's hard to argue that they're incorrect.
As far as I am aware no one has yet to build an Object Orient Processor (The Cell may be closest thing out there). I don't know that we need to go to the level of teaching logic gates and registers (thought this is probably how I would teach it), but certainly something a little closer to the root than a OO language that runs in a Virtual Machine would be a much better place to start.
I absolutely agree that before one graduates with a computer science degree, one should have a reasonable understanding of how a CPU works -- from designing state machines with Karneaugh graphs to CPU design (hardware implementation of simple opcodes; MMUs; interrupt handling; etc) to assembly language. I'm not sure that that's the right place to start learning, though.
I disagree that the use of VMs in teaching computer science is a Bad Thing. Look at The Art Of Computer Programming. Certainly, there's no OO there -- but all of Knuth's code is written (in assembly language) for a virtual machine (or, at least, nonexistent hardware)! There's nothing wrong with using VMs to teach computer science; rather, there's quite a bit wrong with substituting knowledge of the abstraction layer the VM provides for knowledge of how the VM works and what goes on underneath it.
OO isn't such a bad thing either. To be sure, it's necessary that folks be able to think in terms other than objects -- but I'm not suggesting that OO be used exclusively, but rather that it can reasonably be used in introductory classes. Data structures are core to algorithmic thinking, and objects are a reasonable way of thinking about a data structure and the code intended to operate on it; further, such thinking can be used when writing code in languages without explicit OO support. To make sure that folks don't get to thinking that that's the only way to structure their algorithms, they get some assembly (in their OS classes, maybe) and some LISP, Scheme, and/or Prolog (in their AI classes)... but OO is useful for beginners, and languages like Python help get folks quickly into working on algorithms without so much time spent on learning syntax and other such junk as is otherwise needed.
The problem isn't that OO and VM-based or interpreted languages are taught, but that the underpinnings are sometimes given less credence than they used to be. Can the underpinnings wait for one's 2nd or 3rd year, so long as they're taught? I'd argue so.
They should have some great debuggers - they're in the business of writing tens of thousands of lines of source per day
...which doesn't necessarily say anything about the quality of their externally sold dev tools. Visual Source Safe, for instance, they sell but don't use internally.
Now, I'm not saying they don't use the same debugging tools internally; rather, I'm just pointing out that what they sell to The Outside World and what they use between their walls are not one and the same thing.
since Ruby is a very dynamic language without any sort of variable declarations I don't see how else the interpreter could determine scope
Something longer, more explicit and less line-noisey than sigils... like "foo" versus "self.foo" versus "Klass.foo" (actually, the last one sucks, and I wish Python had a better way to do it).
That said... if newcomers can get over Python using whitespace (which, while a frequent up-front objection, comes to be appreciated by folks who've used it a while), I can probably make another attempt to get over Ruby using sigils.
Who cares if people who don't know the language can't read and understand it immediately? Do you expect them to maintain large, important projects written in the langauge without learning it?
I care. I care because I like being able to read 3rd-party code, and consequently I want 3rd parties to be able to read my code. I care because using Python and writing for readability has helped when I'm teaching programming to beginners. I care because those same practices have allowed me to hand off important, mission-critical production code to programming staff with extensive experience in different languages but none at all in Python prior to starting work on the code I handed off -- which is important, because I work at a Java shop where not many staff members have scripting experience. (My most recent handoff of this sort was of a particularly involved piece of code which made use of dynamically generated classes, metaclasses, and dynamic retyping of existing objects; the handoff and training took not more than two hours).
I like Ruby's semantics -- but so long as I'm not losing the massive productivity improvements that modern scripting languages provide, I care more about having a syntax that makes it easy to write code accessible to folks who don't know the language.
Could you say what in Ruby's syntax is borrowed from Perl?
Heavy use of decorators to indicate how variable names should be treated. Regular expressions as part of the core syntax rather than part of the standard library. There are other things as well, but I don't remember them off the top of my head. The first is more important to me, as it relates to readability of code by people who don't know the language.
And it's a shame, because I really, really like the semantics.
There are obvious borrowings from Smalltalk, LISP, Python, and Perl. There's a lot to like about Ruby's semantics; I just can't get past the syntax (which, in my opinion, borrowed quite a bit too much from Perl).
(Django has been in use on high-volume production websites longer than Rails has existed, incidentally -- something which might be worthwhile when bringing it up in this kind of context).
After evaluating Rails and Django, my company ended up going with TurboGears for some of our toolage (our main product is a Java Servlet-based application, and that's not changing). The reasons:
Rails and Django are very tightly integrated -- whereas with TurboGears the toolkit is loose enough that one can easily pull just one piece out for a project which doesn't need the framework as a whole. Our department does a lot of small and varied projects (many of which aren't webapps but which still could use an XML-based template engine or a simple OR mapper or a simple servlet-like API for handling requests independent of any content generation), so this was important to us.
We have more people in-house who know Python than Ruby.
TurboGears appears to be under more active development than Django.
The opposing reasons:
Django and Rails have more high-volume production sites using them.
The OR mapper used by TurboGears, SQLObject, lacks some functionality and useful design attributes provided by others. This doesn't impact us for our little in-house projects, and is less relevant now that TurboGears 0.9 is adding support for using SQLAlchemy as an alternative to SQLObject.
Anyhow -- Rails is nifty. Django is nifty. TurboGears is nifty. Quite likely all three of them have a place; I'd just like to urge people not to get so caught up in the hype over Rails that they forego evaluating other options.
My mother was a teacher. My wife's mother was a teacher. Through junior high and high school, I helped out in the local school system. While going to college, I volunteered at the local junior high (in a different part of the state).
While I can't claim knowledge as comprehensive as that which a proper study would provide, I can certainly claim to have reasonably authoritative knowledge as to the opinions of the teaching community at large in Taft, CA between the years of 1992 and 1998; and a few small (not necessarily representative) samples from Chico, CA in the four years after.
Can I speak with absolute authority? No. Am I completely talking out my ass? No.
I don't think anyone is claiming that the "union members are lazy" thing applies to all professions without exceptions, so the position you're attacking is a strawman.
On the other hand, the "unions are good" meme (which you implicitly support) is vulnerable to the argument that those who are above average in their respective professions tend to find them distaseful.
Not always -- but it's not very pleasant to work somewhere where it's not, as this means working with a bunch of incompetent coworkers who management is unwilling to fire on account of their concept of loyalty.
My current project just lost a QA lackey after 8 months that turned out to have skills we are finding very tough to replace.
Well, yes. We've lost two valuable QA lackeys and probably 5 or 10 worthless ones in the time I've been with my employer. I'm not saying all QA lackeys are useless -- but some of them certainly are.
But a union is a way to keep the good people around- if you write the contracts right.
Mmm-hmm. I've seen too many people miserable with their unions, in part because their contracts aren't written right from the perspective of the good people. Such contracts tend to protect the bad people (who good people by and large don't like working with) -- but ones that don't offer such protection aren't going to offer very much incentive for those who aren't "the good people" to join.
The average CEO isn't competent to assign value to tech people- from their point of view they're all equally worthless wastes of money.
Then the average CEO either either had damn well better delegate those decisions to people who are competant them. A CEO who can't either make the decisions directly or delegate that power to someone who can isn't a CEO worth working for.
There's a lot to be said for keeping people around for seniority and keeping them happy- they're the ones who have to go back to Big Bertha to repair code that they wrote in 1965 before you were born.
The folks who are really essential are those who have both seniority and skill. Someone who's been a QA lackey for five years isn't going to be more valuable than an individual who's been doing design and implementation for two years -- particularly if the latter is adept at maintaining others' code, which is a skill many have.
In other words- that's a pretty immature and petty complaint you're calling major there- and it's one that can cause the failure of a company.
Having the good people leave such that one has only the newbies and the idiots who've been around from the beginning because they were the CEO's college buddies is a pretty damn good way to kill a company, too.
You're using seniority as a sole measure of an individual's value to the company. Is it important? Sure! Is it the only thing that's important? Hell, no! A company should be free to assign values to its employees as it sees fit: If folks are important because they are one of the few who understand the design of some tool they wrote way-back-when that's still in production, or if folks are important because they're the ones who are coming up with the brilliant design leaps -- in any event, the company should have the flexibility to value them appropriately.
Slashdot Mirror
I don't care about choosing an OS and toolkit for people that suck, I care about choosing a toolkit for me. Seriously. I'm responsible for maintaining the template that our servers (which run a *lot* of interdependent services -- Oracle, Tomcat, etc) are built off of. Finding and fixing performance problems in the template means that the low-level support folks have less angry customers on the phone -- and having the tools to find hard-to-locate issues on the deployed servers means customers' issues, once elevated, can get resolved quickly. Will the low-level support staff understand or use DTrace? Maybe not. Do I care? No. Right now I'm stuck using OProfile -- and while it's a good tool as far as it goes, I've seen what DTrace can do and I want some of that, damnit!
They're not using it correctly, then. The whole point of folks writing scripts for DTrace is to provide the information one needs (as opposed to "vomit"). If you're using pre-canned scripts that spit out everything under the sun -- that's your problem, not the tool's.
Okay, here's the distinction.
In the case of the GPL, the restrictions are on rights which copyright law already prohibited (copying and production of derivative works). You have more rights than you would have if I simply gave you a copy without any license.
In the case of Visual Studio disallowing creation of a spreadsheet, the restrictions are on rights which copyright law (which, while it does regulate copying and production of derivative works, does not regulate use) wouldn't otherwise interfere with. You have less rights than you would have if I gave you a copy without any license.
One is more permissive than the default; one adds more restrictions than the default. Simple?
I'm not missing your point; your point is making bad assumptions.
The default action is nothing. Nothing means you grant no license, and keep your copyright rather than relinquishing it to the public domain. If you take an affirmative action to put something under the GPL, you're granting permission subject to restrictions. If you take an affirmative action to place it in the public domain, you're denying any future interest in that thing except as a member of the public. In any event, these are both affirmative actions: your work started off, the moment you created it, under copyright with no license provided. So, either action is granting a third party abilities they didn't have before. Is one more permissive than the other? Yes. Does that mean that the other one is reducing permissions? No; that's as silly as saying that I'm stealing from the poor because I haven't donated my car to charity.
And so does the GPL. That's what a license is for. Otherwise it would be public domain.
Not so. Otherwise, it would be a copyrighted work without any license granting you the right to copy, publicly perform, prepare derivative works, or take the other specific actions permitted by copyright law.
Unlicensed, copyrighted works are not public domain; rather, they're merely works the author gives you no permission to use. A license gives permission to engage in some of the actions that copyright law would otherwise prohibit; and though many make this conditional, all licenses by their nature give you permission to do something which you otherwise could not.
Maybe they're talking about hardware that, say... logs keystrokes, and can be summoned to retrieve them by a later software infection (or by a low-power radio request -- if these machines make it into an embassy or somesuch, it's entirely reasonable to have a feet-on-the-ground representative carry a piece of hardware that transfers the logs off the box).
Look at some of the ways the US bugged equipment exported to Russia during the cold war -- there's a lot of ingenuity going on there.
Do licenses try to screw those who accept it over? Licenses mostly screw people who violate it over.
Commercial software licenses typically disallow a substantial range of actions which would otherwise be permitted by law (copyright and otherwise). Some people would describe this as screwing over the acceptee -- and in several cases (such as licenses in which the licensor is given permission to arbitrarily modify the licensee's computer, to pick an extreme but increasingly common case), it's hard to argue that they're incorrect.
As far as I am aware no one has yet to build an Object Orient Processor (The Cell may be closest thing out there). I don't know that we need to go to the level of teaching logic gates and registers (thought this is probably how I would teach it), but certainly something a little closer to the root than a OO language that runs in a Virtual Machine would be a much better place to start.
I absolutely agree that before one graduates with a computer science degree, one should have a reasonable understanding of how a CPU works -- from designing state machines with Karneaugh graphs to CPU design (hardware implementation of simple opcodes; MMUs; interrupt handling; etc) to assembly language. I'm not sure that that's the right place to start learning, though.
I disagree that the use of VMs in teaching computer science is a Bad Thing. Look at The Art Of Computer Programming. Certainly, there's no OO there -- but all of Knuth's code is written (in assembly language) for a virtual machine (or, at least, nonexistent hardware)! There's nothing wrong with using VMs to teach computer science; rather, there's quite a bit wrong with substituting knowledge of the abstraction layer the VM provides for knowledge of how the VM works and what goes on underneath it.
OO isn't such a bad thing either. To be sure, it's necessary that folks be able to think in terms other than objects -- but I'm not suggesting that OO be used exclusively, but rather that it can reasonably be used in introductory classes. Data structures are core to algorithmic thinking, and objects are a reasonable way of thinking about a data structure and the code intended to operate on it; further, such thinking can be used when writing code in languages without explicit OO support. To make sure that folks don't get to thinking that that's the only way to structure their algorithms, they get some assembly (in their OS classes, maybe) and some LISP, Scheme, and/or Prolog (in their AI classes)... but OO is useful for beginners, and languages like Python help get folks quickly into working on algorithms without so much time spent on learning syntax and other such junk as is otherwise needed.
The problem isn't that OO and VM-based or interpreted languages are taught, but that the underpinnings are sometimes given less credence than they used to be. Can the underpinnings wait for one's 2nd or 3rd year, so long as they're taught? I'd argue so.
...which doesn't necessarily say anything about the quality of their externally sold dev tools. Visual Source Safe, for instance, they sell but don't use internally.
Now, I'm not saying they don't use the same debugging tools internally; rather, I'm just pointing out that what they sell to The Outside World and what they use between their walls are not one and the same thing.
Even so -- using a high-bandwidth codec for information that's going to be distributed in such a way that cost scales with size is silly.
Maybe because MPEG2 is intended for high-bandwidth applications, which streaming over the Internet isn't?
since Ruby is a very dynamic language without any sort of variable declarations I don't see how else the interpreter could determine scope
Something longer, more explicit and less line-noisey than sigils... like "foo" versus "self.foo" versus "Klass.foo" (actually, the last one sucks, and I wish Python had a better way to do it).
That said... if newcomers can get over Python using whitespace (which, while a frequent up-front objection, comes to be appreciated by folks who've used it a while), I can probably make another attempt to get over Ruby using sigils.
I've written a lot of Ruby code and have rarely used sigils.
I'm surprised you don't use instance variables much.
I care. I care because I like being able to read 3rd-party code, and consequently I want 3rd parties to be able to read my code. I care because using Python and writing for readability has helped when I'm teaching programming to beginners. I care because those same practices have allowed me to hand off important, mission-critical production code to programming staff with extensive experience in different languages but none at all in Python prior to starting work on the code I handed off -- which is important, because I work at a Java shop where not many staff members have scripting experience. (My most recent handoff of this sort was of a particularly involved piece of code which made use of dynamically generated classes, metaclasses, and dynamic retyping of existing objects; the handoff and training took not more than two hours).
I like Ruby's semantics -- but so long as I'm not losing the massive productivity improvements that modern scripting languages provide, I care more about having a syntax that makes it easy to write code accessible to folks who don't know the language.
Out of curiosity, what did you use to come up with this statement?
Mailing list activity. Not that either list is anything approaching dead -- but the TG list was substantially busier.
Could you say what in Ruby's syntax is borrowed from Perl?
Heavy use of decorators to indicate how variable names should be treated. Regular expressions as part of the core syntax rather than part of the standard library. There are other things as well, but I don't remember them off the top of my head. The first is more important to me, as it relates to readability of code by people who don't know the language.
And it's a shame, because I really, really like the semantics.
There are obvious borrowings from Smalltalk, LISP, Python, and Perl. There's a lot to like about Ruby's semantics; I just can't get past the syntax (which, in my opinion, borrowed quite a bit too much from Perl).
(Django has been in use on high-volume production websites longer than Rails has existed, incidentally -- something which might be worthwhile when bringing it up in this kind of context).
After evaluating Rails and Django, my company ended up going with TurboGears for some of our toolage (our main product is a Java Servlet-based application, and that's not changing). The reasons:
The opposing reasons:
Anyhow -- Rails is nifty. Django is nifty. TurboGears is nifty. Quite likely all three of them have a place; I'd just like to urge people not to get so caught up in the hype over Rails that they forego evaluating other options.
Not third hand, in several cases... but yes, the relevance is limited.
My mother was a teacher. My wife's mother was a teacher. Through junior high and high school, I helped out in the local school system. While going to college, I volunteered at the local junior high (in a different part of the state).
While I can't claim knowledge as comprehensive as that which a proper study would provide, I can certainly claim to have reasonably authoritative knowledge as to the opinions of the teaching community at large in Taft, CA between the years of 1992 and 1998; and a few small (not necessarily representative) samples from Chico, CA in the four years after.
Can I speak with absolute authority? No. Am I completely talking out my ass? No.
I don't think anyone is claiming that the "union members are lazy" thing applies to all professions without exceptions, so the position you're attacking is a strawman.
On the other hand, the "unions are good" meme (which you implicitly support) is vulnerable to the argument that those who are above average in their respective professions tend to find them distaseful.
The good ones mostly hate them.
Why not start by not using credit cards that charge more than 10%, or perhaps by never carrying a balance?
The credit card fairy didn't charge those purchases to your card; you or someone you authorized did.
Loyalty at jobs is a one sided deal.
Not always -- but it's not very pleasant to work somewhere where it's not, as this means working with a bunch of incompetent coworkers who management is unwilling to fire on account of their concept of loyalty.
My current project just lost a QA lackey after 8 months that turned out to have skills we are finding very tough to replace.
Well, yes. We've lost two valuable QA lackeys and probably 5 or 10 worthless ones in the time I've been with my employer. I'm not saying all QA lackeys are useless -- but some of them certainly are.
But a union is a way to keep the good people around- if you write the contracts right.
Mmm-hmm. I've seen too many people miserable with their unions, in part because their contracts aren't written right from the perspective of the good people. Such contracts tend to protect the bad people (who good people by and large don't like working with) -- but ones that don't offer such protection aren't going to offer very much incentive for those who aren't "the good people" to join.
The average CEO isn't competent to assign value to tech people- from their point of view they're all equally worthless wastes of money.
Then the average CEO either either had damn well better delegate those decisions to people who are competant them. A CEO who can't either make the decisions directly or delegate that power to someone who can isn't a CEO worth working for.
There's a lot to be said for keeping people around for seniority and keeping them happy- they're the ones who have to go back to Big Bertha to repair code that they wrote in 1965 before you were born.
The folks who are really essential are those who have both seniority and skill. Someone who's been a QA lackey for five years isn't going to be more valuable than an individual who's been doing design and implementation for two years -- particularly if the latter is adept at maintaining others' code, which is a skill many have.
In other words- that's a pretty immature and petty complaint you're calling major there- and it's one that can cause the failure of a company.
Having the good people leave such that one has only the newbies and the idiots who've been around from the beginning because they were the CEO's college buddies is a pretty damn good way to kill a company, too.
You're using seniority as a sole measure of an individual's value to the company. Is it important? Sure! Is it the only thing that's important? Hell, no! A company should be free to assign values to its employees as it sees fit: If folks are important because they are one of the few who understand the design of some tool they wrote way-back-when that's still in production, or if folks are important because they're the ones who are coming up with the brilliant design leaps -- in any event, the company should have the flexibility to value them appropriately.