I've heard people say (and have experienced myself) that too many in-code comments tend to clutter a function and make it difficult to read.
As a solution to the problem that exists because I just said it does, I think people far underuse syntax hilighting. I use a darkish blue-green background with white code and black comments. The comments are easily legible, but it is very easy to tune them out to see which lines of code actually "do stuff." With the default black code and green or red comments on a white background in many editors, this benefit is often missed.
As the person who usually comes along later and spends hours cataloging variables in a 500-line function with oodles of legacy code, just to find out what the function does, I wholeheartedly agree!
Self-preservation. If he were to make 7, 8, and 9, some depressed geek with a ruined childhood is sure to snap and go on an uzi-toting rampage at Skywalker Ranch.
Also, think of the ways people could mess with the system. Have a few friends selectively stop their cars on the route you all want to take home, and voila! you have a significantly less congested road!
"You lack vision, but I see a place where people get on and off the freeway. On and off, off and on all day, all night. Soon, where Toon Town once stood will be a string of gas stations, inexpensive motels, restaurants that serve rapidly prepared food. Tire salons, automobile dealerships and wonderful, wonderful billboards reaching as far as the eye can see. My God, it'll be beautiful."
-Judge Doom, "Who Framed Roger Rabbit"
Really, why, in North America, are we so fixated on the automobile for personal transport?
Because so many suburbanites scream NIMBY at the top of their lungs when a mass transit plan comes along. Example: the CenterLine project in Orange County, CA.
So are posts of "frist psot.":) Thankfully, we have enough ensembles to accomodate 30+ clarinetists at the moment, so there's no problem getting in. I think we might have capped our saxophones though.
This is true. You must audition to the department on an instrument, at least at my university. This includes composition and music history majors, as well as the more obvious performance and education majors. You are expected to be a musician, not just a scholar. Auditions are somewhat more lenient for non-performance majors.
For undergrad, as a composition major you complete your first two years as a general music major, then are accepted into the composition department based on what you've been writing (which can be as little as an invention and fugue from counterpoint class).
We have music majors who aren't all that good on their instrument, but all are proficient on at least one. At the end of the semester, there is a "jury" where you play for a panel of professors who decide if you can continue to be a music major the following semester. As a composition major, the jury switches to an evaluation of your writing after two years.
If you want to be a music major and can't play an instrument (I don't know any such cases) they may let you in under certain circumstances, but more likely they'd let you start taking classes and make you take lessons, not letting you declare until you satisfactorily audition into the department.
For a graduate program, I'm not sure if an audition is required; for comp majors they may just look at your portfolio. At this point, though, I think it's assumed that you've already completed an undergrad program that required an instrument.
Oh, and in all these cases, of course, voice counts as an instrument if you are so inclined.
Perhaps at some times the emphasis is a bit much. However, I hardly think the criteria for a composition major is to be a "star performer." As a composition major, I've seen plenty of people who are "ok" performers accepted into my department, especially if they are education or composition majors rather than performance.
As for the emphasis on performance: There are always a few exceptions of people who are excellent writers but can hardly put out a note on their instrument. In general, though, instrumental proficiency is practically a must for composers. I have a hard enough time writing for strings, but I can fall back on my knowledge of wind instruments. Ideally, a composer would know how to play all instruments, but in-depth knowledge of a single instrument provides a significant understanding on how to write for performers. A clarinetist myself, I understand how a slight rewrite of a part can save hours of rehearsal, different registers are completely different in performability, certain areas project better and can be more melodic, etc.
After that, it takes more time and effort to become familiar with things other instruments take for granted. Playing an instrument very well gives you a base line, a point of reference by which to understand the type of things that are easy and hard, what works and what doesn't, what notes are generally flat and sharp, etc. Also, you become more attuned to much more subtle issues, such as octave compression, instruments that blend well, the harmonic series and its relation to intonation, and how to emphasize downbeats ever so slightly to ensure proper time and phrasing when appropriate.
When I am given a clarinet part, I can often guess the composer's native instrument by their attention to or ignorance of certain issues. Someone who has not put in significant time on an instrument is much less likely to understand and sympathize with the quirks of each instrument.
In orchestration class, there are times when the two clarinetists or the three pianists or the tuba player will cringe in horror at what is written on the page. Without playing an instrument well and being exposed to other instruments (pianists have this especially difficult, as they are in large ensembles far less often), you simply don't know that such issues exist. So much of music is intuition and experience. You can read all the books you like that tell you that a half dozen flutes playing low D will still not be heard over a trombone, but you'll simply understand it if you play a wind instrument of any sort.
What of the noise? He's attaching a fan to the hard drive with metal parts, and it looks like his hard drive is attached to the case without any noise-reducing apparatus. It's sure to add yet another irritating drone to the system.
After making a low-noise PC, (3 quiet fans, runs very cool) I can't imagine putting an extra fan in for something that a bit of improved airflow design could alleviate.
IMHO, if one doesn't know in advance whether one likes to write code or not (from hacking on computers during one's teen years), one shouldn't choose CS as a major.
Interesting point. They don't let people declare music majors unless said students already know how to play an instrument...
Let me get this straight...you are showing the customer one diagram, and then coding to another? If this is a contract, you're probably commiting fraud. At the very least, you are going to end up in breach of contract sooner or later.
True. This was for a class, and there was no contract. Had it been for a real job, I would have quit without signing said contract and gone for a job at McDonald's. It was one of those "If this is software engineering, I'm changing my major" courses. I learned proper software engineering by using a "this idea could work very well if it was applied in a different way than they're showing us here" philosophy.
We did a funky version of UML in the course, and were given specifications on how to apply it. These specifications were completely inapplicable to our project. It was as if we showed up one day with a can of beans and the professor said "I want you to make a popsicle out of them."
A good design document, like any technical document, should be well written. All too often, something that could take a sentence to write is expanded into multiple paragraphs or even pages, because the writer likes to feel important. Keep it relevant, and keep it simple.
Also, despite what they tell you in academic paper-writing classes, it's *all right* to write in everyday language. A statement such as "The user moves pointing device A over the activity area of the button in question, intending to activate Process Retroincabulator, and presses the button of activation." can easily be replaced by "Click button A."
Less is more. Each unhelpful word the engineer has to read in a hopelessly long design document brings them one step closer to "Screw it, I'll do it my way and get yelled at later." Reread and revise, removing as much unnecessary verbage as necessary.
Figure out which class from your local university deals with software engineering, find the book(s) for the class, and buy it.
Then burn it. The methods are all nice in theory, but in practice it's often a crapshoot. Then again, I have a bit of history on this one, as my software engineering class was more of a class on how to deal with the PHB (clueless professor).
We learned how to make all the pretty diagrams, while we discovered that such pretty diagrams could never have relevance to our particular project. It ended up a game of "make the diagrams the customer wants, then make much simpler and more sensible ones for yourself that don't follow proper software engineering protocol but actually tell us how the darn thing works."
As a composer, I've recently written a piece based on video game music (no tune in particular, but the general Mario/Zelda/Kirby/etc.-esque feel) for clarinet choir that will be performed next month. It isn't the subject matter that's upsetting; I believe all, and I do mean all, musical styles have something to offer and should not be discounted.
I totally agree that most of the backlash isn't due to the fact that he's playing video game tunes, but that he's playing them sloppily, with regard only for speed and show rather that nuance.
Despite the fact that they're "cheezy video game tunes," the stuff he plays has great potential for creative interpretation, and seeing that lack of interpretation disregarded by many is indeed what I personally get up in arms about.
The performer is having fun with it, which is great, but until he adds some character to his performance, I'll cringe whenever I read a "this guy is unbelievable," the same way I cringe when the PBS announcers say "Yanni is amazing! He writes music right out of his head!"
We should, however, teach them how to Write TFM in a concise, helpful manner. There are a lot of badly-written FMs out there, and after a while it's quite irritating being told to R them. Better yet, they could be taught to design things in such a way that makes TFM less necessary to R.
Throwing the pencils away doesn't get you any paper.
True. But pencils don't require power, maintenance personnel, upgrades, software, or significant floorspace. And a lone pencil's distractive gaming capability is limited to Tic-Tac-Toe, MASH, and Dots.
Slashdot Mirror
Just because you've seen lots of lousy comments, doesn't mean good comments don't exist. They do, and are immensely helpful.
I've heard people say (and have experienced myself) that too many in-code comments tend to clutter a function and make it difficult to read.
As a solution to the problem that exists because I just said it does, I think people far underuse syntax hilighting. I use a darkish blue-green background with white code and black comments. The comments are easily legible, but it is very easy to tune them out to see which lines of code actually "do stuff." With the default black code and green or red comments on a white background in many editors, this benefit is often missed.
As the person who usually comes along later and spends hours cataloging variables in a 500-line function with oodles of legacy code, just to find out what the function does, I wholeheartedly agree!
eBay yields 22 results at the moment.
Self-preservation. If he were to make 7, 8, and 9, some depressed geek with a ruined childhood is sure to snap and go on an uzi-toting rampage at Skywalker Ranch.
Also, think of the ways people could mess with the system. Have a few friends selectively stop their cars on the route you all want to take home, and voila! you have a significantly less congested road!
"You lack vision, but I see a place where people get on and off the freeway. On and off, off and on all day, all night. Soon, where Toon Town once stood will be a string of gas stations, inexpensive motels, restaurants that serve rapidly prepared food. Tire salons, automobile dealerships and wonderful, wonderful billboards reaching as far as the eye can see. My God, it'll be beautiful."
-Judge Doom, "Who Framed Roger Rabbit"
Actually, if it went to infinity, you'd have zero cars
And any cars you actually do see must be the figments of a deranged imagination.
[ ] Mounted Antennas
[ ] Ground Sensors
[ ] CowboyNeal ate my transmitter.
Really, why, in North America, are we so fixated on the automobile for personal transport?
Because so many suburbanites scream NIMBY at the top of their lungs when a mass transit plan comes along. Example: the CenterLine project in Orange County, CA.
But this is wildly off topic for Slashdot...
:)
So are posts of "frist psot."
Thankfully, we have enough ensembles to accomodate 30+ clarinetists at the moment, so there's no problem getting in. I think we might have capped our saxophones though.
This is true. You must audition to the department on an instrument, at least at my university. This includes composition and music history majors, as well as the more obvious performance and education majors. You are expected to be a musician, not just a scholar. Auditions are somewhat more lenient for non-performance majors.
For undergrad, as a composition major you complete your first two years as a general music major, then are accepted into the composition department based on what you've been writing (which can be as little as an invention and fugue from counterpoint class).
We have music majors who aren't all that good on their instrument, but all are proficient on at least one. At the end of the semester, there is a "jury" where you play for a panel of professors who decide if you can continue to be a music major the following semester. As a composition major, the jury switches to an evaluation of your writing after two years.
If you want to be a music major and can't play an instrument (I don't know any such cases) they may let you in under certain circumstances, but more likely they'd let you start taking classes and make you take lessons, not letting you declare until you satisfactorily audition into the department.
For a graduate program, I'm not sure if an audition is required; for comp majors they may just look at your portfolio. At this point, though, I think it's assumed that you've already completed an undergrad program that required an instrument.
Oh, and in all these cases, of course, voice counts as an instrument if you are so inclined.
Perhaps at some times the emphasis is a bit much. However, I hardly think the criteria for a composition major is to be a "star performer." As a composition major, I've seen plenty of people who are "ok" performers accepted into my department, especially if they are education or composition majors rather than performance.
As for the emphasis on performance: There are always a few exceptions of people who are excellent writers but can hardly put out a note on their instrument. In general, though, instrumental proficiency is practically a must for composers. I have a hard enough time writing for strings, but I can fall back on my knowledge of wind instruments. Ideally, a composer would know how to play all instruments, but in-depth knowledge of a single instrument provides a significant understanding on how to write for performers. A clarinetist myself, I understand how a slight rewrite of a part can save hours of rehearsal, different registers are completely different in performability, certain areas project better and can be more melodic, etc.
After that, it takes more time and effort to become familiar with things other instruments take for granted. Playing an instrument very well gives you a base line, a point of reference by which to understand the type of things that are easy and hard, what works and what doesn't, what notes are generally flat and sharp, etc. Also, you become more attuned to much more subtle issues, such as octave compression, instruments that blend well, the harmonic series and its relation to intonation, and how to emphasize downbeats ever so slightly to ensure proper time and phrasing when appropriate.
When I am given a clarinet part, I can often guess the composer's native instrument by their attention to or ignorance of certain issues. Someone who has not put in significant time on an instrument is much less likely to understand and sympathize with the quirks of each instrument.
In orchestration class, there are times when the two clarinetists or the three pianists or the tuba player will cringe in horror at what is written on the page. Without playing an instrument well and being exposed to other instruments (pianists have this especially difficult, as they are in large ensembles far less often), you simply don't know that such issues exist. So much of music is intuition and experience. You can read all the books you like that tell you that a half dozen flutes playing low D will still not be heard over a trombone, but you'll simply understand it if you play a wind instrument of any sort.
What of the noise? He's attaching a fan to the hard drive with metal parts, and it looks like his hard drive is attached to the case without any noise-reducing apparatus. It's sure to add yet another irritating drone to the system.
After making a low-noise PC, (3 quiet fans, runs very cool) I can't imagine putting an extra fan in for something that a bit of improved airflow design could alleviate.
IMHO, if one doesn't know in advance whether one likes to write code or not (from hacking on computers during one's teen years), one shouldn't choose CS as a major.
Interesting point. They don't let people declare music majors unless said students already know how to play an instrument...
Let me get this straight...you are showing the customer one diagram, and then coding to another? If this is a contract, you're probably commiting fraud. At the very least, you are going to end up in breach of contract sooner or later.
True. This was for a class, and there was no contract. Had it been for a real job, I would have quit without signing said contract and gone for a job at McDonald's. It was one of those "If this is software engineering, I'm changing my major" courses. I learned proper software engineering by using a "this idea could work very well if it was applied in a different way than they're showing us here" philosophy.
We did a funky version of UML in the course, and were given specifications on how to apply it. These specifications were completely inapplicable to our project. It was as if we showed up one day with a can of beans and the professor said "I want you to make a popsicle out of them."
A good design document, like any technical document, should be well written. All too often, something that could take a sentence to write is expanded into multiple paragraphs or even pages, because the writer likes to feel important. Keep it relevant, and keep it simple.
Also, despite what they tell you in academic paper-writing classes, it's *all right* to write in everyday language. A statement such as "The user moves pointing device A over the activity area of the button in question, intending to activate Process Retroincabulator, and presses the button of activation." can easily be replaced by "Click button A."
Less is more. Each unhelpful word the engineer has to read in a hopelessly long design document brings them one step closer to "Screw it, I'll do it my way and get yelled at later." Reread and revise, removing as much unnecessary verbage as necessary.
Figure out which class from your local university deals with software engineering, find the book(s) for the class, and buy it.
Then burn it. The methods are all nice in theory, but in practice it's often a crapshoot. Then again, I have a bit of history on this one, as my software engineering class was more of a class on how to deal with the PHB (clueless professor).
We learned how to make all the pretty diagrams, while we discovered that such pretty diagrams could never have relevance to our particular project. It ended up a game of "make the diagrams the customer wants, then make much simpler and more sensible ones for yourself that don't follow proper software engineering protocol but actually tell us how the darn thing works."
Screw the danger, what about the noise? I live in the L.A. area, and you can't go outside without hearing an airplane as it is now.
Was that in the 82 as well? (that's what we had)
As a musician, mod parent up!
As a composer, I've recently written a piece based on video game music (no tune in particular, but the general Mario/Zelda/Kirby/etc.-esque feel) for clarinet choir that will be performed next month. It isn't the subject matter that's upsetting; I believe all, and I do mean all, musical styles have something to offer and should not be discounted.
I totally agree that most of the backlash isn't due to the fact that he's playing video game tunes, but that he's playing them sloppily, with regard only for speed and show rather that nuance.
Despite the fact that they're "cheezy video game tunes," the stuff he plays has great potential for creative interpretation, and seeing that lack of interpretation disregarded by many is indeed what I personally get up in arms about.
The performer is having fun with it, which is great, but until he adds some character to his performance, I'll cringe whenever I read a "this guy is unbelievable," the same way I cringe when the PBS announcers say "Yanni is amazing! He writes music right out of his head!"
This was in California. We not only played the "real" Oregon Trail game, but a few cheap knockoffs as well.
We should, however, teach them how to Write TFM in a concise, helpful manner. There are a lot of badly-written FMs out there, and after a while it's quite irritating being told to R them. Better yet, they could be taught to design things in such a way that makes TFM less necessary to R.
Indeed. Slashdot ran a review last September of a book that suggests just that.
Throwing the pencils away doesn't get you any paper.
True. But pencils don't require power, maintenance personnel, upgrades, software, or significant floorspace. And a lone pencil's distractive gaming capability is limited to Tic-Tac-Toe, MASH, and Dots.