You're right, chapter 16 of the JLS says that a compiler "must carry out a specific conservative flow analysis" to make sure local variables are assigned before being accessed.
> That will through a compiler error
Yup. Good fodder for a more thorough data flow analysis tool to chew on...
Yup, true, as long as the programmer doesn't go nuts waiting for the compiler:-)
> it's provably impossible for the compiler > to tell if there's memory leaks
Yup. Sometime I feel that some folks who don't do much programming have the feeling that "oh those lazy programmers, they're just not working hard enough". What they don't realize is that good programming is hard to do, and it's not as much as an exact science as they might think...
[tom@hal tmp]$ cat Test.java public class Test {
int foo() {
return null.length();
} } [tom@hal tmp]$ javac Test.java Test.java:3: <nulltype> cannot be dereferenced
return null.length();
^ 1 error [tom@hal tmp]$
but not this:
[tom@hal tmp]$ cat Test.java public class Test {
int foo() {
String bar = null;
return bar.length();
} } [tom@hal tmp]$ javac Test.java [tom@hal tmp]$
Still, that's a step in the right direction. It'd be great if javac had a "-dfa" flag or something to enable some data flow analysis checks like that one...
> If you see a warning, get rid of it right > away! Once you slack off a bit, it becomes > like dirty dishes piling up in the kitchen > sink. Nobody wants to touch them, and > everybody feels like most of them are the > other roommate's anyway.
So true! This kind of goes back to the article the other day about having a public daily build. Checking code quality regularly can help keep things under control.
> If I write a C program that makes 5 malloc() > and 4 free(), the compiler should notice > that and say, "Gee, you have a > memory leak here"
That's a tricky tradeoff, though... the more stuff the compiler checks, the longer a compile takes.
Some things couldn't be caught at compile-time, too. I mean, the compiler would have to actually run the program to ensure it correctly allocated and deallocated memory. That's what stuff like Valgrind is for...
Ah, yes, there's the key. You're right - if a daily build means that the checkin window is only a few hours, that's a problem. Something else needs to be fixed - maybe the build can be distributed or some such.
We do hourly builds on my current project - but it's in Java, and the whole build only takes about 20 minutes, so that works fine.
> perhaps they have developed better methodologies
Yup, maybe distcc. One would hope so, anyhow.
> the right interval for builds
I'd say - as often as possible without being a pain:-)
> by definition continues to be resold > in a new package, with new features, > new designs, new, new, new.
Heh, yup. Perhaps, though, such is the nature of commercial software. It must be continually reinvented, whether it needs to or not, if only to sell more boxes.
That's one of the nice things about open source software - there's no drive to add new bells and whistles just to justify a new release...
Hm. Ok. Sure, all those things you mention are bad - blinding, enthralling, charming, customers being children, and so forth.
I guess I didn't quite get that from the original article, though... I felt that he was just trying to say "write the software so that the users really like it".
> 13. Enrapture the customers. > This is one of Microsoft's mantras, and > it's where Microsoft and the Open Source > community disagree, fundamentally. > I think we have to examine this and > discuss it.
Hm. "Enrapture" just means "to fill with delight". Why would that be a bad thing?
11. If you build it, it will ship. Conversely, if you don't, it won't. The product should be built every day, along with all setup scripts and on-line help, in a public place, where QA can conduct appropriate assessment of daily status, and the entire team can observe progress or its lack. This is the single biggest indicator that a team is functional and a product being developed.
So true. And "in a public place" is definitely an important part of that - when a build fails, everyone should be able to see the compilation error.
> To have ones fingers in many > pies is to be involved in many diverse endeavours.
Ah, OK, right. I had thought perhaps there was a specific quote from Russell to which he was referring... 'twas a kind comment on the parent AC's part, indeed.
... that I wrote - PQA - runs only from the console. I could write a Ruby/Tk or a WxWidgits GUI for it... but why bother? As it is, I can feed in all the necessary parameters at the command line and not have to click around a GUI.
At the same time, it's best to write the code in such a way that a GUI could be put on top of it... but for me, a console interface is good enough for now.
Slashdot Mirror
> a manual override of the null checking
:-)
Thanks for making me look this up
You're right, chapter 16 of the JLS says that a compiler "must carry out a specific conservative flow analysis" to make sure local variables are assigned before being accessed.
> That will through a compiler error
Yup. Good fodder for a more thorough data flow analysis tool to chew on...
... it's Apple's WorldWide Developer Conference.
> will be flagged
Hm, cool, yup, it's flagged with a "variable x might not have been initialized". Odd that an assignment to null couldn't have been caught as well.
Ah well, as you say, it's something, at least.
> I think "Java" and "Browser lockup"
> became nearly synonymous.
So true. That's why I went with JNLP for my tetris clone. Of course, JNLP has got its own problems... argh.
> it leads to a better and more stable program
:-)
Yup, true, as long as the programmer doesn't go nuts waiting for the compiler
> it's provably impossible for the compiler
> to tell if there's memory leaks
Yup. Sometime I feel that some folks who don't do much programming have the feeling that "oh those lazy programmers, they're just not working hard enough". What they don't realize is that good programming is hard to do, and it's not as much as an exact science as they might think...
> the lead deveolper just isn't a Sopranos fan?
Heh, no, but the guy who did the logo is.
Hm, that's interesting! It catches this:but not this:Still, that's a step in the right direction. It'd be great if javac had a "-dfa" flag or something to enable some data flow analysis checks like that one...
> If you see a warning, get rid of it right
> away! Once you slack off a bit, it becomes
> like dirty dishes piling up in the kitchen
> sink. Nobody wants to touch them, and
> everybody feels like most of them are the
> other roommate's anyway.
So true! This kind of goes back to the article the other day about having a public daily build. Checking code quality regularly can help keep things under control.
> If I write a C program that makes 5 malloc()
> and 4 free(), the compiler should notice
> that and say, "Gee, you have a
> memory leak here"
That's a tricky tradeoff, though... the more stuff the compiler checks, the longer a compile takes.
Some things couldn't be caught at compile-time, too. I mean, the compiler would have to actually run the program to ensure it correctly allocated and deallocated memory. That's what stuff like Valgrind is for...
> ActiveX was more a response
> to JavaScript/Flash/et al.
Right on... I thought the "ActiveX was a response to Java" was a bit of a stretch too. Also, the author says
> "everyone complained about wanting to
> bypass the "sandbox" to get file-level
> access to the local host.".
I'm not sure that was why applets were not a big hit... I'd blame the slow JVM startup time for that one.
> ...if you can just shoot the message?"
So true. Thus the logo for PMD, a Java static analysis tool - "don't shoot the messenger".
> The only branch of AI that I have any
> faith in is neural networks
People have done some nifty stuff with fuzzy logic, too. Washing machines, dishwashers, etc, have some sort of fuzzy controllers in there.
It's not AI in the sense of self-aware robotic overlords, but still...
TMR is a DARPA Advanced Technology Office program... other projects in the same office are here.
> can take hours to build.
:-)
Ah, yes, there's the key. You're right - if a daily build means that the checkin window is only a few hours, that's a problem. Something else needs to be fixed - maybe the build can be distributed or some such.
We do hourly builds on my current project - but it's in Java, and the whole build only takes about 20 minutes, so that works fine.
> perhaps they have developed better methodologies
Yup, maybe distcc. One would hope so, anyhow.
> the right interval for builds
I'd say - as often as possible without being a pain
> by definition continues to be resold
> in a new package, with new features,
> new designs, new, new, new.
Heh, yup. Perhaps, though, such is the nature of commercial software. It must be continually reinvented, whether it needs to or not, if only to sell more boxes.
That's one of the nice things about open source software - there's no drive to add new bells and whistles just to justify a new release...
Hm. Ok. Sure, all those things you mention are bad - blinding, enthralling, charming, customers being children, and so forth.
I guess I didn't quite get that from the original article, though... I felt that he was just trying to say "write the software so that the users really like it".
> 13. Enrapture the customers.
> This is one of Microsoft's mantras, and
> it's where Microsoft and the Open Source
> community disagree, fundamentally.
> I think we have to examine this and
> discuss it.
Hm. "Enrapture" just means "to fill with delight". Why would that be a bad thing?
So true. And "in a public place" is definitely an important part of that - when a build fails, everyone should be able to see the compilation error.
> if you want a good, open-source
> relational database, PostgreSQL is a champ.
Right on. Good utilities are available for it, too!
> Apache 2.x has a large number of
> new features designed to better handle
> high volume sites (with or without PHP)
Yup. We run Apache 2.0 with mod_jk and mod_php on SemWebCentral;, no problems.
> To have ones fingers in many
> pies is to be involved in many diverse endeavours.
Ah, OK, right. I had thought perhaps there was a specific quote from Russell to which he was referring... 'twas a kind comment on the parent AC's part, indeed.
... that I wrote - PQA - runs only from the console. I could write a Ruby/Tk or a WxWidgits GUI for it... but why bother? As it is, I can feed in all the necessary parameters at the command line and not have to click around a GUI.
At the same time, it's best to write the code in such a way that a GUI could be put on top of it... but for me, a console interface is good enough for now.
> fingers and pies [...] Bertrand Russell
Even Google could not help me understand this... surely it must be a pithy quote... don't keep me in suspense!
...my WAD file parser. Argh!
...is in the spinoff projects. For example, this open source Java memory profiler is a spinoff of the DARPA-supported COUGAAR agent framework.
And since both projects are hosted on a server running GForge, I can help improve GForge during working hours. Good times!