If your biggest problem with modern apps is that they're too big and slow, I envy you. As a user, I'm a lot more annoyed by the fact that so many apps are hard to use and insecure. As a developer, I'd put a *much* higher priority on making programs easier to debug, maintain, and extend than on size and speed.
(Of course, in some application areas, like scientific computing, performance is critical. But for the vast majority of apps, that's not the case.)
Another experience with "frying" in the US: It can mean deep frying, but it can also mean pan (or shallow) frying. In my experience, "frying" on its own usually means pan frying. Possibly that's because I grew up in Virginia, where, for example, real fried chicken is pan fried. YMMV.
Many of you may have read this already, but if you haven't, I highly recommend The Left Hand of Darkness by Ursula Le Guin. I found its take on gender and how it impacts all aspects of our relationships to be really interesting. And it's a good story, too.
If you're talking about programming competitions (like the ACM's International one), how a school's team performs doesn't say very much about the school as whole. The most compelling reason is simple: only a handful (3-4, typically) of students are on a team. Many schools, even ones that are not so good overally, have a small number of stellar students.
Not that the competitions aren't cool. I participated in the ACM one 3 times, one year at the international competition. It was really fun and I'm glad I did it. I just don't think it says very much about the school overall.
I think to a large degree people get the education they ask for (or at least, their parents ask for).
I grew up in a very rural area (town population ~1500). Many kids in the public schools didn't care about education, especially hard subjects like science and math, and their parent's didn't, either. My class was small (~100 students) and I was one of the top, academically. I was picked on a lot because of it. It wasn't cool to be smart.
To some extent I think kids may get this idea from the media/culture at large. But to a large extent I think they get it from their parents. Where I grew up, many of my classmates' parents were fairly uneducated and did not value education.
I've since heard from college friends, etc., that there are public schools where it is cool to be smart. But I think there are lots where it's not.
I agree that the networking demands of X are often overblown, but I don't understand what you mean by running 150 desktops off a single server. The X server is what runs on the desktop machine; it's what draws the graphics and gets the raw keyboard & mouse events. Do you mean you have 150 desktops running X servers that all use a single server box to run applications (i.e., X clients) on?
(Yeah, the X terminology can be confusing since in X-speak the server runs on the desktop, not in the back room, but we're stuck with it.)
The size isn't as big an issue for me as the weight. The lightest VAIO I could find was 3.11 lbs (the TR series), which is pretty light but not as light as the Thinkpad X40.
This isn't exactly on-topic, but I thought I'd chime in here with my biggest gripe about Apple laptops: they're too heavy.
The lightest Apple laptop I could find is the Powerbook G4 with a 12: screen, which weighs 4.6 lbs. The latest in the IBM Thinkpad X series (X40), in contrast, only weighs 2.6 lbs, 43% less!
I'm probably buying a new laptop later this year, and I was strongly considering making it my first Mac, but I don't want a laptop that heavy.
Some units may have very similar or even identical hardware, but the internal state (including connectivity) is crucial. And it will be unique for each instance.
Imagine that you're building a program to communicate with a new type
of device. You can use any existing programming language, platform,
and assume any general communications channel (e.g., serial, parallel,
ethernet, USB). But, the device has the following characteristics:
Comes "out of the box" with no documentation. (Others in your position have put together some documentation, but it's really incomplete.)
It's written in proprietary source code.
It has very low-level object code. No decompiler or even disassembler exists. Forget about reverse-engineering.
It's actually not a single computation device, but a real-time, networked system, with
~10-14 billion nodes (yes, 10-14 * 10^9)
And the nodes have dynamically changing connectivity
The system has hidden state that you cannot reset to a known state.
It's non-deterministic, thanks to its real-time nature and hidden state.
Each instance is unique.
You can only create one communications program that must work with multiple instances of the device, even though they're all unique.
In case you haven't guessed already, the "device" is a human being. This is why user interface design is hard.
The problem is the attitude that "the user is the problem."
To make a program that is easy to use, you have to have the attitude that the user is right. If the user presses a button and something happens that's different from what the user expects, that's a problem with the program, not with the user. If the user looks at the interface and doesn't know what to do to cause the desired effect, it's a problem with the program.
I understand developers who decide not to make their apps usable. It's their time, their effort, they can spend it however they want.
But: usability is hard. If you decide not to spend the requisite time and effort on it, don't be surprised if people have a hard time using your program.
Some posts already mention some reasons why this is a hard contest, but I thought I'd summarize and add a couple more:
* You have more problems than your team can possibly do in the time allotted. When I did it, the winners got 4 or 5 out of 8. There's a lot of pressure to work fast.
* All the problems are tricky, but there is definite variance in their difficulty. Since your score is based not only on how many you get right, but how fast you get them right, you have to figure out which problems are the easiest and do them first. Starting with a problem that looks easy but turns out not to be can really hose you.
* The answer evaluation is harsh. You submit a solution program and if it's not correct you get back a response like: "insufficient output", "too much output", or simply "incorrect output." Figuring out why the judges say your program doesn't work when you think it does can be really frustrating.
* There are multiple people on the team (4 my first time, 3 my second and I think since (but someone correct me if that's no the case)) and only one computer, so managing that resource is crucial.
I don't know how much the contest proves, or how much stock employers, say, should put in it, but it was fun to do.
The two years I participated in this competition, most of the problems weren't really mathematical. Out of about 8 problems given, maybe 1 or two would involve hard math.
Not that the winners shouldn't be congratulated--it's an incredibly challenging competition--just that it doesn't have that much to do with math.
I know about Self (very cool, I agree) and I know about prototype-based languages. Mainly, I was trying to be funny. I was also slightly serious, I admit. I really doubt that yet another interpreted language is going to have much impact or is really that important. Especially considering how early in the process things are.
If I implied that tests weren't useful or necessary, I take it back. That's not what I meant.
However, I still claim that it's useful to get help from the computer in writing your program correctly in the first place, and static typing helps you do that.
Static typing is also useful because it is a form of documentation that the computer can actually check is correct. You may not make typing mistakes much, and I think probably most people don't on their own code. But if you're trying to understand someone else's code, it's a lot easier to figure out what variable foo is for and what it can do if you know its type. And if you have code that you wrote a long time ago, it's effectively somebody else's code.
What's the down side of static typing? I've seen two main arguments against it here:
1. It's extra work 2. It requires you to do ugly typecasting
The way I think about #1 is as a readability vs. writability issue. Yes, static typing makes code harder/take longer to write, which is a big reason I prefer Python for really short things. However, most lines of code are read *many* more times than they are written---and certainly this applies to the programs that this article talks about. So I think readability should be heavily emphasized. And static typing makes programs more readable.
I think #2 is sometimes a valid complaint. In a statically-typed language, sometimes you have to do ugly casts. However, if you didn't have static typing, you'd be doing the same operation but with no documentation that any type changes were occurring.
That's a interesting idea. I think it would make C++ safer. It seems to me that it's better to start with a language that's safer in the first place, but I haven't really thought through what would be involved in the kind of tool you describe.
I am a big python fan. I especially love how well it integrates with Java in Jython. It's great for small programs and as a wrapper to glue together other stuff. I also like jython a lot for debugging Java programs.
However, I don't think it's suitable for large projects because it's not statically typed. (BTW, it's "lose", not "loose".)
You can usually run your unit tests in Python in less time than it takes just to compile your Java. So you actually get more checks in less time!
Tests are good, but testing is no substitute for static checking; in any large (or probably even medium-sized) project, you're lucky if you can create a code suite that causes every line of code to be executed even once, and forget about a suite that'll test a non-trivial number of paths through the code. I think the performance is a non-issue.
pychecker can spot many static errors.
Thanks for mentioning pychecker; I didn't know about it before. From reading the feature list, it sounds really helpful and I'll definitely use it for future Python projects. However, static typing gives you all that and more.
There is much less need for ugly work arounds from limitations of the type system, so less errors in the first place.
I'm not familiar with C#, but I agree that the Java typesystem does require ugliness sometimes. Generics reduce that a lot, though. And I still believe that the benefits of static type checking far outweigh the occassional hassles of doing ugly casts.
The problem with C++ is that it has too much power and flexibility, much of which it inherited from C. For example, for a lot of programs, esp. desktop applications, the ability to do pointer arithmetic is a liability, not a benefit, because people will get it wrong.
C# and Java aren't much higher level than C++, but they are definite improvements because they decrease opportunities for bugs.
A lot of people talk about performance, but for many apps the difference between Java (and probably C#, but I don't know) and C++ is small enough to be irrelevant. And the gap is shrinking.
Depending on the job, the amount of time and energy people in the company put in deciding to hire you can be a factor, too. Not only don't they want to spend the money to find somebody else, they don't want to take the time, do the politicing, etc.
This new law is similar to copyright, but different. It is a new protection in addition to anything copyright (or other existing law) may provide. Previous rulings about copyright are irrelevant, unless they relate to Constitutional issues that are also relevant to the new law.
If's kind of like Congress deciding that Purple Things need to be protected from being copied, regardless of whether any existing protections applied or not. Even if Purple Things were copyable under previous law, Congress could pass new law saying they no longer are. (Subject to the Constitution, of course.)
Even if this were about amending copyright law instead of creating a new class of protected works, prior case law has no binding effect on Congress, which has complete authority to ignore case law if it wants. (The courts are the ones bound by case law.)
Slashdot Mirror
If your biggest problem with modern apps is that they're too big and slow, I envy you. As a user, I'm a lot more annoyed by the fact that so many apps are hard to use and insecure. As a developer, I'd put a *much* higher priority on making programs easier to debug, maintain, and extend than on size and speed.
(Of course, in some application areas, like scientific computing, performance is critical. But for the vast majority of apps, that's not the case.)
Another experience with "frying" in the US: It can mean deep frying, but it can also mean pan (or shallow) frying. In my experience, "frying" on its own usually means pan frying. Possibly that's because I grew up in Virginia, where, for example, real fried chicken is pan fried. YMMV.
Many of you may have read this already, but if you haven't, I highly recommend The Left Hand of Darkness by Ursula Le Guin. I found its take on gender and how it impacts all aspects of our relationships to be really interesting. And it's a good story, too.
If you're talking about programming competitions (like the ACM's International one), how a school's team performs doesn't say very much about the school as whole. The most compelling reason is simple: only a handful (3-4, typically) of students are on a team. Many schools, even ones that are not so good overally, have a small number of stellar students.
Not that the competitions aren't cool. I participated in the ACM one 3 times, one year at the international competition. It was really fun and I'm glad I did it. I just don't think it says very much about the school overall.
I think to a large degree people get the education they ask for (or at least, their parents ask for).
I grew up in a very rural area (town population ~1500). Many kids in the public schools didn't care about education, especially hard subjects like science and math, and their parent's didn't, either. My class was small (~100 students) and I was one of the top, academically. I was picked on a lot because of it. It wasn't cool to be smart.
To some extent I think kids may get this idea from the media/culture at large. But to a large extent I think they get it from their parents. Where I grew up, many of my classmates' parents were fairly uneducated and did not value education.
I've since heard from college friends, etc., that there are public schools where it is cool to be smart. But I think there are lots where it's not.
This just in: a prominent potato farmer in Idaho is retiring upon learning that, get this... soldiers eat potatoes!
I agree that the networking demands of X are often overblown, but I don't understand what you mean by running 150 desktops off a single server. The X server is what runs on the desktop machine; it's what draws the graphics and gets the raw keyboard & mouse events. Do you mean you have 150 desktops running X servers that all use a single server box to run applications (i.e., X clients) on?
(Yeah, the X terminology can be confusing since in X-speak the server runs on the desktop, not in the back room, but we're stuck with it.)
The size isn't as big an issue for me as the weight. The lightest VAIO I could find was 3.11 lbs (the TR series), which is pretty light but not as light as the Thinkpad X40.
This isn't exactly on-topic, but I thought I'd chime in here with my biggest gripe about Apple laptops: they're too heavy.
The lightest Apple laptop I could find is the Powerbook G4 with a 12: screen, which weighs 4.6 lbs. The latest in the IBM Thinkpad X series (X40), in contrast, only weighs 2.6 lbs, 43% less!
I'm probably buying a new laptop later this year, and I was strongly considering making it my first Mac, but I don't want a laptop that heavy.
Some units may have very similar or even identical hardware, but the internal state (including connectivity) is crucial. And it will be unique for each instance.
In case you haven't guessed already, the "device" is a human being. This is why user interface design is hard.
Have you ever actually designed a nontrivial program for use by people not like yourself? Did such people try it? Did they use it?
You don't need a PhD or MFA, but you do need training to design good interfaces. It's hard and you never get it right the first time.
The problem is the attitude that "the user is the problem."
To make a program that is easy to use, you have to have the attitude that the user is right. If the user presses a button and something happens that's different from what the user expects, that's a problem with the program, not with the user. If the user looks at the interface and doesn't know what to do to cause the desired effect, it's a problem with the program.
I understand developers who decide not to make their apps usable. It's their time, their effort, they can spend it however they want.
But: usability is hard. If you decide not to spend the requisite time and effort on it, don't be surprised if people have a hard time using your program.
Some posts already mention some reasons why this is a hard contest, but I thought I'd summarize and add a couple more:
* You have more problems than your team can possibly do in the time allotted. When I did it, the winners got 4 or 5 out of 8. There's a lot of pressure to work fast.
* All the problems are tricky, but there is definite variance in their difficulty. Since your score is based not only on how many you get right, but how fast you get them right, you have to figure out which problems are the easiest and do them first. Starting with a problem that looks easy but turns out not to be can really hose you.
* The answer evaluation is harsh. You submit a solution program and if it's not correct you get back a response like: "insufficient output", "too much output", or simply "incorrect output." Figuring out why the judges say your program doesn't work when you think it does can be really frustrating.
* There are multiple people on the team (4 my first time, 3 my second and I think since (but someone correct me if that's no the case)) and only one computer, so managing that resource is crucial.
I don't know how much the contest proves, or how much stock employers, say, should put in it, but it was fun to do.
The two years I participated in this competition, most of the problems weren't really mathematical. Out of about 8 problems given, maybe 1 or two would involve hard math.
Not that the winners shouldn't be congratulated--it's an incredibly challenging competition--just that it doesn't have that much to do with math.
I know about Self (very cool, I agree) and I know about prototype-based languages. Mainly, I was trying to be funny. I was also slightly serious, I admit. I really doubt that yet another interpreted language is going to have much impact or is really that important. Especially considering how early in the process things are.
"It's a joke, son. Laugh." - Foghorn Leghorn
Yet Another New and Improved Scripting Language! Just what we needed!
Oops, did I say that out loud?
If I implied that tests weren't useful or necessary, I take it back. That's not what I meant.
However, I still claim that it's useful to get help from the computer in writing your program correctly in the first place, and static typing helps you do that.
Static typing is also useful because it is a form of documentation that the computer can actually check is correct. You may not make typing mistakes much, and I think probably most people don't on their own code. But if you're trying to understand someone else's code, it's a lot easier to figure out what variable foo is for and what it can do if you know its type. And if you have code that you wrote a long time ago, it's effectively somebody else's code.
What's the down side of static typing? I've seen two main arguments against it here:
1. It's extra work
2. It requires you to do ugly typecasting
The way I think about #1 is as a readability vs. writability issue. Yes, static typing makes code harder/take longer to write, which is a big reason I prefer Python for really short things. However, most lines of code are read *many* more times than they are written---and certainly this applies to the programs that this article talks about. So I think readability should be heavily emphasized. And static typing makes programs more readable.
I think #2 is sometimes a valid complaint. In a statically-typed language, sometimes you have to do ugly casts. However, if you didn't have static typing, you'd be doing the same operation but with no documentation that any type changes were occurring.
That's a interesting idea. I think it would make C++ safer. It seems to me that it's better to start with a language that's safer in the first place, but I haven't really thought through what would be involved in the kind of tool you describe.
However, I don't think it's suitable for large projects because it's not statically typed. (BTW, it's "lose", not "loose".)
You can usually run your unit tests in Python in less time than it takes just to compile your Java. So you actually get more checks in less time!
Tests are good, but testing is no substitute for static checking; in any large (or probably even medium-sized) project, you're lucky if you can create a code suite that causes every line of code to be executed even once, and forget about a suite that'll test a non-trivial number of paths through the code. I think the performance is a non-issue.
pychecker can spot many static errors.
Thanks for mentioning pychecker; I didn't know about it before. From reading the feature list, it sounds really helpful and I'll definitely use it for future Python projects. However, static typing gives you all that and more.
There is much less need for ugly work arounds from limitations of the type system, so less errors in the first place.
I'm not familiar with C#, but I agree that the Java typesystem does require ugliness sometimes. Generics reduce that a lot, though. And I still believe that the benefits of static type checking far outweigh the occassional hassles of doing ugly casts.
The problem with C++ is that it has too much power and flexibility, much of which it inherited from C. For example, for a lot of programs, esp. desktop applications, the ability to do pointer arithmetic is a liability, not a benefit, because people will get it wrong.
C# and Java aren't much higher level than C++, but they are definite improvements because they decrease opportunities for bugs.
A lot of people talk about performance, but for many apps the difference between Java (and probably C#, but I don't know) and C++ is small enough to be irrelevant. And the gap is shrinking.
Not all CRTs wear out that quickly. I've been using the same 17" CRT at home since 1994 and it still looks great. (FYI, it's an NEC 5FGp.)
Depending on the job, the amount of time and energy people in the company put in deciding to hire you can be a factor, too. Not only don't they want to spend the money to find somebody else, they don't want to take the time, do the politicing, etc.
Did anybody else see the title and think, "What does a Game Master have to do with chess?"
Too much RPGing, I guess...
If's kind of like Congress deciding that Purple Things need to be protected from being copied, regardless of whether any existing protections applied or not. Even if Purple Things were copyable under previous law, Congress could pass new law saying they no longer are. (Subject to the Constitution, of course.)
Even if this were about amending copyright law instead of creating a new class of protected works, prior case law has no binding effect on Congress, which has complete authority to ignore case law if it wants. (The courts are the ones bound by case law.)