I confess that I didn't give a lot of attention to the definition of "scripting language" when I put together my short list. That's because > I started with the suggestions from the earlier slashdot comments. (You'll note that I quoted the Groovy person from that discussion.)
At least a couple of people said Scala really ought to have been included so I figured, "okay, sure."
But I must respectfully disagree; there are plenty of movers and shakers here. In intelligently run companies (and one of the joys of me working at CIO.com is that I've discovered that they do exist!) the Powers That Be to want to know what the techies think. Sometimes they even listen to the advice. As with so many other things, the people who believe they have the power may not have as much as they think they do... and vice versa.
The original title was "State of the Scripting Universe Revisited." It was too long for the./ subject line. And the CIO.com one had to be written for search engines as well as humans (for reasons that are probably obvious but annoying nonetheless).
Still, the article's deck does say that it's a follow-up. As you'll see elsewhere in this thread, I'm happy to write about Groovy et al.
Perhaps you should take a closer look at your copy of Down to Earth REXX. Why yes, that is "Schindler" on the front cover.
As was explained earlier, Lynn and I chose these languages because that's what we had chosen three years ago. And we chose those at the time because they had the highest usage in the Evans Data surveys.
Groovy. Check. Lua. Check. Scala. Good suggestion.
Political rhetoric? Sure, it's definitely scripted, the syntax has lots of boundary conditions, and it is well understood in its own domain. But it never actually executes any functionality so I don't think I should include it.
Seriously, those are good suggestions. one more, and I'd have a nice short-and-sweet article with which I could bonk the PTBs on their heads—Esther (who also blogs occasionally)
It was a conscious omission... or perhaps semi-conscious. Lynn and I thought that if we were going to revisit the topic we should look at the same languages we did before.
I do want to cover Groovy at CIO.com, honest. Just haven't had a good hook for it yet. I feel like there's an opportunity for "&number; programming languages your developers wish you'd let them use" aimed at CIOs and IT managers, with Groovy probably top on the list. But I don't know what else ought to be on the list, so I haven't done anything with this idea. Suggestions always welcome.—Esther
That was a pretty reasonable guess, except it isn't correct.:-)
Lynn understandably went back to the same people, initially, since it would be easiest to say, "Hey, three years ago you said this... change you mind on anything?" Some of the guys didn't have the time (for example, Guido's a little busy with the next version of Python), so she asked who they'd recommend she speak with instead. To my understanding, Dave Thomas suggested Lam. Though he might have suggested someone else who suggested Lam.
IOW it had nothing to do with Microsoft. Though, come to think of it, it could be a good idea to ask all the Scripting Dudes and Dudettes from Microsoft for their opinions on stuff. Hmmmmmm.
As I remarked in the comments to that article, there isn't one right answer to "how to manage and motivate developers" any more than there's only one right way to write an application. People, skills and situations differ; in fact, I worry more about people who'd think that all these things apply every time and in every scenario.
In other words, the article represents only what it says it does: developers' own answers to "what should the boss know about motivating me." Unlike the other articles in that "getting clueful" series (like what the CIO should know about Agile or telecommuting) , which does not require introspection... well, this one requires that someone be aware of what motivates them and the feeling of Being Managed Well. One of my first bosses was smart enough to recognize that if he let me talk long enough about how I couldn't possibly solve this coding problem, I'd eventually explain to him how I could; but I'd never have said at the time, "A good manager will shut up and let me talk." I think people notice such things by their absence than by their presence.
So I don't expect that developers always know the right way to manage them. I think that managers should be aware of how the developers see it (for compassion reasons if nothing else--we all want to believe our opinions matter)... but the boss still does have to make the right decision.
The thing with the cat is just funny. ("Dogs come when they're called; cats take a message and get back to you later."--Mary Bly)
No, but I think we could have a good time coming up with "words that should make you run away from a job interview." Synergy should be on the list, surely. I'd add "leverage." And "thought leader."
You don't think that his Star Trek comment is funny?!
There's a sort-of accompanying article about managing developers, based on what developers say motivates them. Not all the opinions agree, obviously. (I wrote that one.)
Not everyone does understand basic maintenance. You'd be amazed. Plenty of people wait until the car breaks down before they think to get it serviced.
And they don't like to gain even basic knowledge. In the gas crisis of the late 1970s, my (then-)mother-in-law waited 40 minutes at a gas station before she got to the pump. When she discovered it was self-serve, she drove away, because she didn't know how to use the pump herself. (Yes, obviously all she had to do was ask the person behind her—who'd be motivated to help—but she didn't.)
Also, even when people take the car in for maintenance, it's something they do out of distrust for the practitioners. That's better than not taking it in, of course, but it's inherently a combative relationship: what's the mechanic gonna tell me I need this time?
The thing is, few of us want to be experts in every technology we use. We just want it to work.
None of which excuses ignorance, mind you, but it does explain it.
I do know what those users think, and it's very much like you posited: "My computer has become unusably slow, and I don't know why or how to fix it!" Unfortunately that was followed by, "Aunt Esther, can you tell me what's wrong?"—and thus I spent half a day killing enough of the junk that I could install a firewall, antivirus, etc.
People like my nephew aren't unwilling to learn. They're just lost when it comes to their computers. And they don't particularly mind being ignorant as long as the equipment works right (or appears to). Just as most of us don't feel the need to understand how a car works in order to drive one.
Some of us remember the days when we wistfully wanted computers to become easy enough for ordinary people to use them. Alas, we got our wish.
I covered OS/2 actively for several years past that point. I knew several of the developers, and was one of the lead perpetrators of the OS/2 WarpTech conference in 2000. So yeah, I have some idea of how much work continued to go into development. And how little went into marketing.::sigh::
Despite significant shortcomings, PHP is perhaps the most popular Web scripting language in the world. But despite a large collection of nails, not every tool is a hammer. So when should it be used, and when would another dynamic programming language be a better choice? We identify its strengths and weaknesses.
The key to understanding when (and when not) to deploy JavaScript has as much to do with the intent of the target application as it does JavaScript itself. Written by Michael Morrison, author of Head First JavaScript.
In some ways, AJAX is easy. But if you get into a non-trivial programming exercise, such as building an entire site relying on all sorts of data inputs, the typical developer tools don't necessarily help you along. Yes, the options (FOSS and proprietary) are getting better, but there's still a long way to go before it's precisely easy to write a useful quick-and-dirty app the way that, say, you can throw together a desktop database tool today.
While Ajax is clever and useful, it isn't easy and it has limitations. Scott Guthrie, Microsoft general manager,.Net development platform, says, "Ajax itself is built on top of an innocuous HTML feature; the programming model wasn't built to scale for that." JavaScript performance is an issue as applications get bigger and need to be maintained. Plus, he points out, these applications are "weirdly stitched together."
As a result, says Bob Brewin, Sun's software CTO, doing Ajax is really painful, "like building an aircraft carrier by hand." Hand-coded Ajax development today requires a large skill set, so several interesting technologies have materialized to simplify it.
Well for one thing, the article isn't meant to be an exhaustive list of resources. It's meant to explain, from a CIO or IT manager's viewpoint, what the concerns are for enterprises that want to adopt Macs (in large or small numbers).
Shouldn't the survey have been sent out to 400 randomly chosen developers? Aren't you biasing the results already by choosing developers more likely to have some involvement with linux?
If you want to know about the opinions and behavior of Linux users, then it's important to interview Linux users. Just as it makes sense to learn about wireless development tools, attitudes, and so on by asking wireless developers. The database developer's report interviews developers who are working with databases for a similar reason. Why set up a situation in which a significant percentage of respondents have to answer "not applicable"?
From the information provided, it may not be apparent to you at what level of depth the developers are queried. I believe that Nicholas' report is something like 300 pages long... it's far more than the highlights that he's able to pull out here.
That isn't to say that there isn't useful information to be gained by interviewing 400 randomly chosen developers. In fact, Evans Data does a general North American Developer's Report twice a year, as well as additional reports about development in other countries. Those studies are a cross-section of about 500 "random" developers, so Evans can track trends in the development community at large.
It's not just Linux growth, but what percentage of developers expect to write a wireless app, how many have experienced a network security breach, and so forth. Then we can cross-tabulate by operating system (as well as a bunch of other things, from company size to the kind of apps the respondents write) to determine any correlation between, say, wireless development and primary OS usage. The questions are somewhat more general, since they cover a wider range of subjects.
You'll find a document on the EDC Web site explaining the company's methodology. You'll also find a link that will let you join the developer panel, if you're interested in doing so.
Esther Schindler
Senior Analyst, Evans Data Corp.
(but speaking as herself, here)
Slashdot Mirror
I confess that I didn't give a lot of attention to the definition of "scripting language" when I put together my short list. That's because > I started with the suggestions from the earlier slashdot comments. (You'll note that I quoted the Groovy person from that discussion.) At least a couple of people said Scala really ought to have been included so I figured, "okay, sure."
I think the problem is "you can only use..." and not what the tool is.
Thanks for the kind words!
But I must respectfully disagree; there are plenty of movers and shakers here. In intelligently run companies (and one of the joys of me working at CIO.com is that I've discovered that they do exist!) the Powers That Be to want to know what the techies think. Sometimes they even listen to the advice. As with so many other things, the people who believe they have the power may not have as much as they think they do... and vice versa.
The original title was "State of the Scripting Universe Revisited." It was too long for the ./ subject line. And the CIO.com one had to be written for search engines as well as humans (for reasons that are probably obvious but annoying nonetheless).
Still, the article's deck does say that it's a follow-up. As you'll see elsewhere in this thread, I'm happy to write about Groovy et al.
My dear Anonymous:
<snort>
Perhaps you should take a closer look at your copy of Down to Earth REXX. Why yes, that is "Schindler" on the front cover.
As was explained earlier, Lynn and I chose these languages because that's what we had chosen three years ago. And we chose those at the time because they had the highest usage in the Evans Data surveys.
Groovy. Check. Lua. Check. Scala. Good suggestion.
Political rhetoric? Sure, it's definitely scripted, the syntax has lots of boundary conditions, and it is well understood in its own domain. But it never actually executes any functionality so I don't think I should include it.
Seriously, those are good suggestions. one more, and I'd have a nice short-and-sweet article with which I could bonk the PTBs on their heads—Esther (who also blogs occasionally)
Lynn asked the Big Cheese(s) who to talk with. Ya think she ought to have said, "No, that guy isn't cool enough"?
Oh my. Don't tell anyone I did that.
It was a conscious omission... or perhaps semi-conscious. Lynn and I thought that if we were going to revisit the topic we should look at the same languages we did before.
I do want to cover Groovy at CIO.com, honest. Just haven't had a good hook for it yet. I feel like there's an opportunity for "&number; programming languages your developers wish you'd let them use" aimed at CIOs and IT managers, with Groovy probably top on the list. But I don't know what else ought to be on the list, so I haven't done anything with this idea. Suggestions always welcome.—Esther
That was a pretty reasonable guess, except it isn't correct. :-)
Lynn understandably went back to the same people, initially, since it would be easiest to say, "Hey, three years ago you said this... change you mind on anything?" Some of the guys didn't have the time (for example, Guido's a little busy with the next version of Python), so she asked who they'd recommend she speak with instead. To my understanding, Dave Thomas suggested Lam. Though he might have suggested someone else who suggested Lam.
IOW it had nothing to do with Microsoft. Though, come to think of it, it could be a good idea to ask all the Scripting Dudes and Dudettes from Microsoft for their opinions on stuff. Hmmmmmm.
As I remarked in the comments to that article, there isn't one right answer to "how to manage and motivate developers" any more than there's only one right way to write an application. People, skills and situations differ; in fact, I worry more about people who'd think that all these things apply every time and in every scenario.
In other words, the article represents only what it says it does: developers' own answers to "what should the boss know about motivating me." Unlike the other articles in that "getting clueful" series (like what the CIO should know about Agile or telecommuting) , which does not require introspection... well, this one requires that someone be aware of what motivates them and the feeling of Being Managed Well. One of my first bosses was smart enough to recognize that if he let me talk long enough about how I couldn't possibly solve this coding problem, I'd eventually explain to him how I could; but I'd never have said at the time, "A good manager will shut up and let me talk." I think people notice such things by their absence than by their presence.
So I don't expect that developers always know the right way to manage them. I think that managers should be aware of how the developers see it (for compassion reasons if nothing else--we all want to believe our opinions matter)... but the boss still does have to make the right decision.
The thing with the cat is just funny. ("Dogs come when they're called; cats take a message and get back to you later."--Mary Bly)
No, but I think we could have a good time coming up with "words that should make you run away from a job interview." Synergy should be on the list, surely. I'd add "leverage." And "thought leader."
You don't think that his Star Trek comment is funny?! There's a sort-of accompanying article about managing developers, based on what developers say motivates them. Not all the opinions agree, obviously. (I wrote that one.)
Not everyone does understand basic maintenance. You'd be amazed. Plenty of people wait until the car breaks down before they think to get it serviced.
And they don't like to gain even basic knowledge. In the gas crisis of the late 1970s, my (then-)mother-in-law waited 40 minutes at a gas station before she got to the pump. When she discovered it was self-serve, she drove away, because she didn't know how to use the pump herself. (Yes, obviously all she had to do was ask the person behind her—who'd be motivated to help—but she didn't.)
Also, even when people take the car in for maintenance, it's something they do out of distrust for the practitioners. That's better than not taking it in, of course, but it's inherently a combative relationship: what's the mechanic gonna tell me I need this time?
The thing is, few of us want to be experts in every technology we use. We just want it to work.
None of which excuses ignorance, mind you, but it does explain it.
I do know what those users think, and it's very much like you posited: "My computer has become unusably slow, and I don't know why or how to fix it!" Unfortunately that was followed by, "Aunt Esther, can you tell me what's wrong?"—and thus I spent half a day killing enough of the junk that I could install a firewall, antivirus, etc.
People like my nephew aren't unwilling to learn. They're just lost when it comes to their computers. And they don't particularly mind being ignorant as long as the equipment works right (or appears to). Just as most of us don't feel the need to understand how a car works in order to drive one.
Some of us remember the days when we wistfully wanted computers to become easy enough for ordinary people to use them. Alas, we got our wish.
My coworker wrote a blog entry at CIO.com, Should Microsoft Throw Away Vista? reporting on this issue.
Sure... but the higher in the food chain they are, the more damage they can do.
(The corollary, of course, is that a competent executive can have a wide effect in a good way.)
I covered OS/2 actively for several years past that point. I knew several of the developers, and was one of the lead perpetrators of the OS/2 WarpTech conference in 2000. So yeah, I have some idea of how much work continued to go into development. And how little went into marketing. ::sigh::
That was definitely true of SOM in the 2.1 days. SOM 2 took it from a cool, technically interesting hack to real code.
You Used PHP to Write WHAT?!
Despite significant shortcomings, PHP is perhaps the most popular Web scripting language in the world. But despite a large collection of nails, not every tool is a hammer. So when should it be used, and when would another dynamic programming language be a better choice? We identify its strengths and weaknesses.
http://www.cio.com/article/176250
You used JavaScript to write WHAT?
The key to understanding when (and when not) to deploy JavaScript has as much to do with the intent of the target application as it does JavaScript itself. Written by Michael Morrison, author of Head First JavaScript.
http://www.cio.com/article/print/175950
In some ways, AJAX is easy. But if you get into a non-trivial programming exercise, such as building an entire site relying on all sorts of data inputs, the typical developer tools don't necessarily help you along. Yes, the options (FOSS and proprietary) are getting better, but there's still a long way to go before it's precisely easy to write a useful quick-and-dirty app the way that, say, you can throw together a desktop database tool today.
That's not just my opinion. It was the opinions of some of the tool builders themselves, when I interviewed them for Beyond Ajax: Software Development, Two Years from Now a few weeks ago. In Making Development Less Difficult: Interceding with the Browser GodsWell for one thing, the article isn't meant to be an exhaustive list of resources. It's meant to explain, from a CIO or IT manager's viewpoint, what the concerns are for enterprises that want to adopt Macs (in large or small numbers).
If you want to know about the opinions and behavior of Linux users, then it's important to interview Linux users. Just as it makes sense to learn about wireless development tools, attitudes, and so on by asking wireless developers. The database developer's report interviews developers who are working with databases for a similar reason. Why set up a situation in which a significant percentage of respondents have to answer "not applicable"?
From the information provided, it may not be apparent to you at what level of depth the developers are queried. I believe that Nicholas' report is something like 300 pages long... it's far more than the highlights that he's able to pull out here.
That isn't to say that there isn't useful information to be gained by interviewing 400 randomly chosen developers. In fact, Evans Data does a general North American Developer's Report twice a year, as well as additional reports about development in other countries. Those studies are a cross-section of about 500 "random" developers, so Evans can track trends in the development community at large.
It's not just Linux growth, but what percentage of developers expect to write a wireless app, how many have experienced a network security breach, and so forth. Then we can cross-tabulate by operating system (as well as a bunch of other things, from company size to the kind of apps the respondents write) to determine any correlation between, say, wireless development and primary OS usage. The questions are somewhat more general, since they cover a wider range of subjects.
You'll find a document on the EDC Web site explaining the company's methodology. You'll also find a link that will let you join the developer panel, if you're interested in doing so.
Esther Schindler
Senior Analyst, Evans Data Corp.
(but speaking as herself, here)