Sorry, but this is my least-favorite Kurosawa
film. The pace is almost glacial. I'd take Seven Samurai or Kagamusha over it any day.
Thos are also great movies and 7 Samurai is also one of my favorites. Some movies are intended to be fast some intended to be slow. One needs ballads as well as bebop.
I'm a sucker for gorgeous scenery shots and survey parties...:^)
by Kurosawa. One of the most gorgeous and touching movies I've seen.
Use it as a tool, not a crutch
on
Java IDEs?
·
· Score: 1
It's true that using a debugger can substitute for *thinking* about the code you are looking at; I've been guilty of that at times. But there are a lot of things you can do with a debugger that you can't easily do with printf()s. For one thing, stepping through code is a good way to prove your code is doing what you think it is. For another, you can browse through datastructures (especially with a good debugging environment like DDD) and learn a lot about how the code works. And I have solved some extremely obscure and difficult bugs with patient and creative use of the debugger; setting a variety of conditional breakpoints until the problem was found. Asking each equivalent question about the code would have involved a tedious recompile.
The story was crap, and it had enough holes to drive a fleet of trucks through. The dialog was painfully bad. It required a focus on technique over substance: like watching one of those candy ads at the start of the movie where you try to figure out if they used Phong shading on Mr. SoftDrink's hands. Actually, I think the candy ad had a better plot.
Really! Open source projects always need cash. Lots of cash. Preferably unmarked tens and twenties. You can send them to me and I'll be sure they get into the right hands.
In a related development, the MPAA filed suit against God seeking a ban on memory, arguing that consumers that remembered movies were depriving large corporations of profits. "Say a viewer sees a movie and doesn't like it. Under current rules, they can remember not to watch that movie ever again. That's unfair, and we're going to seek chemical solutions to prevent such behavior", a MPAA representative whined. God could not be reached for comment.
1) Comparison to Java: I'd have to say that Java's class libraries are generally more mature at this point. Also for server-side programming, the startup time of the JMV isn't much of an issue. It also has greater typesafety, and has a mature threading model (which is critical for many types of applications).
2) Comparison to perl: well written perl can be just as maintainable as any other language, and it's better at munging text than any of the other listed languages. Perl has a bad rap because for a long time it was deemed to be a language for quick-n-dirty scripts, so people tended to use it with a quick-n-dirty mindset. Read Damien Conway's book to see what perl can be.
3) Comparison with C++: 'really fast' OO programs are really important. C++ has gotten very complex and it's hard to write C++ compilers, so most good C++ programmers I know use about %70 percent of the features but understand them well. My experience is that well designed C++ programs ave surprisingly few memory problems. Also remember that garbage collected languages like perl and python can have memory problems if you don't think enough about how large your data structures may get; I've found this kind of memory problem to be very common.
4) Comparison with C: C doesn't have 'tragically painful' memory management. C has incredibly sinple memory mangement. Experienced C programmers know that well-thought-out designs can radically reduce the number of memory problems. I've worked on huge bodies of C code that had very few memory problems: the result of a tight, thourough design process.
C is also the most portable of the listed languages, and generally the fastest. C is the foundation that makes most computer technology possible (gross generalization alert).
I like python, and I think it has a bright future. But don't fall into the trap of seeking 'the one true language' for every occasion. Each language has strengths and weaknesses and requires a certain set of programming strategies and mindset.
Well, tastes differ. I really enjoyed Cryptonomicon, but I found Deepness to be the most turgid uninteresting book he's written to date. Two thirds of the way through I was fighting to keep reading it. Part of the problem was the arachnids; they were about as alien as a my brother (who can be fairly bizarre at times). Compared to Peace War this was a big letdown.
I'm always trying to get better at conducting interviews. The strategies that work for me:
* Ask them questions about work they've been doing recently. If it's a sizable project it should offer a wealth of technical and design problems that they had *better* be able to discuss in depth.
* I look for someone who can explain things clearly and completely, since this shows the kind of ordered thinking I want in a programmer. I've only met a *tiny* number of good engineers who couldn't fit this criteria.
* As them to write some code on the whiteboard. Even if it's not compilable-quality, I want to see a minimum level of fluency and confidence. A lot of people can't write well thought out code to save their skin!
* Puzzle questions (like the manhole cover qustion) tend to be kind of a waste of time. Instead, give them programming problems typical of your job. I'd rather see a good ability to break down problems into solveable chunks than mere knowledge of a language. Languages are easy to learn, problem decomposition isn't.
* If you get a lot of buzzwords, start probing hard. Most of the people I want to hire are good explainers and can explain things in english. People tend to throw a lot of buzzwords up as a cover for lack of knowledge.
* Look for confidence. It's very hard to maintain confidence over the course of a full interview unless you really believe you can cut the mustard.
* Interviewing junior engineers is different than interviewing experienced engineers.
You're clearly someone who's never done any serious UNIX programming, otherwise you'd appreciate the value of his books. Then again you're probably too self-absorbed and immature to have much heart-felt compassion, so why should I waste my time giving you the attention you seek by making such comments?
Slashdot Mirror
Then I can walk down the hall in the middle of the night without fear of stepping on my little boy's building blocks.
Thos are also great movies and 7 Samurai is also one of my favorites. Some movies are intended to be fast some intended to be slow. One needs ballads as well as bebop.
I'm a sucker for gorgeous scenery shots and survey parties...
by Kurosawa. One of the most gorgeous and touching movies I've seen.
It's true that using a debugger can substitute for *thinking* about the code you are looking at; I've been guilty of that at times. But there are a lot of things you can do with a debugger that you can't easily do with printf()s. For one thing, stepping through code is a good way to prove your code is doing what you think it is. For another, you can browse through datastructures (especially with a good debugging environment like DDD) and learn a lot about how the code works. And I have solved some extremely obscure and difficult bugs with patient and creative use of the debugger; setting a variety of conditional breakpoints until the problem was found. Asking each equivalent question about the code would have involved a tedious recompile.
The story was crap, and it had enough holes to drive a fleet of trucks through. The dialog was painfully bad. It required a focus on technique over substance: like watching one of those candy ads at the start of the movie where you try to figure out if they used Phong shading on Mr. SoftDrink's hands. Actually, I think the candy ad had a better plot.
Really! Open source projects always need cash. Lots of cash. Preferably unmarked tens and twenties. You can send them to me and I'll be sure they get into the right hands.
:^)
As a born-n-raised native of Berkeley, I get touchy when people leave out the second E...
In a related development, the MPAA filed suit against God seeking a ban on memory, arguing that consumers that remembered movies were depriving large corporations of profits. "Say a viewer sees a movie and doesn't like it. Under current rules, they can remember not to watch that movie ever again. That's unfair, and we're going to seek chemical solutions to prevent such behavior", a MPAA representative whined. God could not be reached for comment.
1) Comparison to Java: I'd have to say that Java's class libraries are generally more mature at this point. Also for server-side programming, the startup time of the JMV isn't much of an issue. It also has greater typesafety, and has a mature threading model (which is critical for many types of applications).
2) Comparison to perl: well written perl can be just as maintainable as any other language, and it's better at munging text than any of the other listed languages. Perl has a bad rap because for a long time it was deemed to be a language for quick-n-dirty scripts, so people tended to use it with a quick-n-dirty mindset. Read Damien Conway's book to see what perl can be.
3) Comparison with C++: 'really fast' OO programs are really important. C++ has gotten very complex and it's hard to write C++ compilers, so most good C++ programmers I know use about %70 percent of the features but understand them well. My experience is that well designed C++ programs ave surprisingly few memory problems. Also remember that garbage collected languages like perl and python can have memory problems if you don't think enough about how large your data structures may get; I've found this kind of memory problem to be very common.
4) Comparison with C: C doesn't have 'tragically painful' memory management. C has incredibly sinple memory mangement. Experienced C programmers know that well-thought-out designs can radically reduce the number of memory problems. I've worked on huge bodies of C code that had very few memory problems: the result of a tight, thourough design process.
C is also the most portable of the listed languages, and generally the fastest. C is the foundation that makes most computer technology possible (gross generalization alert).
I like python, and I think it has a bright future. But don't fall into the trap of seeking 'the one true language' for every occasion. Each language has strengths and weaknesses and requires a certain set of programming strategies and mindset.
Well, tastes differ. I really enjoyed Cryptonomicon, but I found Deepness to be the most turgid uninteresting book he's written to date. Two thirds of the way through I was fighting to keep reading it. Part of the problem was the arachnids; they were about as alien as a my brother (who can be fairly bizarre at times). Compared to Peace War this was a big letdown.
I'm always trying to get better at conducting interviews. The strategies that work for me:
* Ask them questions about work they've been doing recently. If it's a sizable project it should offer a wealth of technical and design problems that they had *better* be able to discuss in depth.
* I look for someone who can explain things clearly and completely, since this shows the kind of ordered thinking I want in a programmer. I've only met a *tiny* number of good engineers who couldn't fit this criteria.
* As them to write some code on the whiteboard. Even if it's not compilable-quality, I want to see a minimum level of fluency and confidence. A lot of people can't write well thought out code to save their skin!
* Puzzle questions (like the manhole cover qustion) tend to be kind of a waste of time. Instead, give them programming problems typical of your job. I'd rather see a good ability to break down problems into solveable chunks than mere knowledge of a language. Languages are easy to learn, problem decomposition isn't.
* If you get a lot of buzzwords, start probing hard. Most of the people I want to hire are good explainers and can explain things in english. People tend to throw a lot of buzzwords up as a cover for lack of knowledge.
* Look for confidence. It's very hard to maintain confidence over the course of a full interview unless you really believe you can cut the mustard.
* Interviewing junior engineers is different than interviewing experienced engineers.
Hmm..let's see:
1) It has good character development.
2) It has a good storyline.
3) It has a strong message, well told.
4) It's unusual.
Most of the writers you mentioned would probably
consider themselves fortunate to write a book this good.
Actually, emacs is an adventure game. Think of it as rogue that does spell checking...
You're clearly someone who's never done any serious UNIX programming, otherwise you'd appreciate the value of his books.
Then again you're probably too self-absorbed and immature to have much heart-felt compassion, so why should I waste my time giving you the attention you seek by making such comments?