3 ms·

So, printf() is your friend. Log everything your program does, and if something seems to go wrong, scour the logs to figure it out. Disk is cheap, so better to

by edw519 16y ago

So, printf() is your friend. Log everything your program does, and if something seems to go wrong, scour the logs to figure it out. Disk is cheap, so better to just log everything and sort it out later if something seems to be broken. There's little hope of doing real interactive debugging in this kind of environment, and most developers don't get shell access to the machines they are running on anyway. 1985: Interactive debuggers suck. PRINT() is your friend. 1990: Interactive debuggers have matured. No one uses PRINT() any more. Debugger questions are now even part of technical interviews. 2008: Concurrent processing and cloud computing have made interactive debugging difficult. 2010: printf() is your friend again. Developing software is getting to be like fashion. Keep those old skinny jeans and workarounds in your closet. Sooner or later, they'll be in style again.

jakevoytko 16y ago
All projects are different. Use the most useful tool for your job, and pay little attention to other developers. They may be using something better, or they may just have different needs.
tibbon 16y ago
This seems to be even more interesting to compare the Ruby community (from what I've seen is massively test-driven and shuns use puts()), to the use of Python at Google. Of course, most Ruby stuff that I mentioned is Rails based, and there isn't that much concurrency happening and its set up well for testing- but just an observation.
- adambyrtek 16y ago
  Google is extremely test-oriented, every project is covered by a test suite and there is a powerful distributed continuous integration infrastructure in place that executes tests "in the cloud" and doesn't allow to commit code that doesn't pass. Not to forget about the public Google Testing Blog[1] and the famous Testing on the Toilet[2]. People in the Ruby community also use temporary puts/logging statements for exploratory debugging, but of course nobody in right mind commits such code to the repository. [1] http://googletesting.blogspot.com/ http://googletesting.blogspot.com/ [2] http://googletesting.blogspot.com/2007/01/introducing-testing-on-toilet.html http://googletesting.blogspot.com/2007/01/introducing-testin...
hvs 16y ago
This just tells me that we need to figure out a new way to debug concurrent/cloud processes more easily. The traditional debuggers just don't cut it anymore.
- aristidb 16y ago
  How about trying to find errors as early as possible, by for example using the type system? That will not catch everything, but it will catch quite a lot.
  - hvs 16y ago
    That's one of the trade-offs when deciding between a statically or dynamically typed language. Static typing isn't really going to help you with debugging/avoiding concurrency issues, though.
    - jedbrown 16y ago
      Well, the type system can be used to isolate side effects, thus ruling out large classes of concurrency bugs (especially with threads instead of separate processes or strict message passing (e.g. Erlang)). It can also prove that typing errors cannot occur, whereas with a dynamic language, it is possible for the program to be ill-typed in only certain circumstances (a function could return a different type depending on input). But yes, there are plenty of concurrency issues that are not greatly mitigated by static typing.
  - pjscott 16y ago
    You can definitely get a lot out of using better abstractions, as the success of MapReduce has shown. I'll list a few ideas, with the warning that they may be half-baked: * Strong, stern type checking has always been kind of a pain in the ass, but it's very effective at catching miscellaneous stupid errors. If debugging in the cloud is hard enough, then maybe overbearing type systems are the lesser of two hassles. * Interactive programming is a big win. One of the best things about Lisp is the REPL, and how well-integrated it is with the editor. (At least, if you use something like SLIME.) If I'm programming on a distributed system, I definitely want to be able to quickly test out my code, preferably in a concurrent environment. You could solve this by having a bunch of servers for this, or with some fancy simulation environment, or a bunch of virtual machines, or something. The point is, I want errors to show up fast. * Really good log analysis. Ideally, any framework you're using would automatically log everything it does, and then you would use some nice tools to figure out what happened, and where it went wrong. Maybe the Loggly guys will come up with some good stuff. * Data-flow oriented abstractions like what Apache Pig offers. Pig lets you define a directed acyclic dataflow graph, in which each edge is some operation like "group by field x", or "filter by function f(fields)". It compiles all this into MapReduce jobs and runs them on Hadoop. It's probably a lot harder to mess up a query in Pig than with raw MapReduce, for sufficiently complicated queries. I'm not sure how much of a performance hit you take, though.
polynomial 16y ago
> Developing software is getting to be like fashion. Keep those old skinny jeans and workarounds in your closet. Sooner or later, they'll be in style again. Or is developing software like business? Sell those skinny jeans and workarounds when they are in demand, then buy some back when they go out of style. You're now ready for their comeback and you have some mad money in your skinny jeans' pocket.
wglb 16y ago
Actually around 1985, Mark Williams invented the C Source-Level Debugger, which certainly did not suck, and was quickly imitated by other larger outfits. However, my use of debuggers has always been quite minimal, perhaps because despite the CSD experience, I am often behind the times. Or perhaps it was due to my early (not quite childhood) experience building real-time interrupt-rich programs in Sigma 5 assembly language. I also read recently that most of the grownups don't use debuggers but have always stuck by printf or equivalent. It kind of reminds me of an early attempt on my part, not wanting to do laundry in my early bachelor years, to start a wrinkled shirt fashion trend. I was not successful, at least for a large number of years. It finally did become fashion. So stick with printf and build useful but lean logging habits would be my advice.

by edw519 16y ago

jakevoytko 16y ago

All projects are different. Use the most useful tool for your job, and pay little attention to other developers. They may be using something better, or they may just have different needs.

tibbon 16y ago

This seems to be even more interesting to compare the Ruby community (from what I've seen is massively test-driven and shuns use puts()), to the use of Python at Google. Of course, most Ruby stuff that I mentioned is Rails based, and there isn't that much concurrency happening and its set up well for testing- but just an observation.

adambyrtek 16y ago
Google is extremely test-oriented, every project is covered by a test suite and there is a powerful distributed continuous integration infrastructure in place that executes tests "in the cloud" and doesn't allow to commit code that doesn't pass. Not to forget about the public Google Testing Blog[1] and the famous Testing on the Toilet[2]. People in the Ruby community also use temporary puts/logging statements for exploratory debugging, but of course nobody in right mind commits such code to the repository. [1] http://googletesting.blogspot.com/ http://googletesting.blogspot.com/ [2] http://googletesting.blogspot.com/2007/01/introducing-testing-on-toilet.html http://googletesting.blogspot.com/2007/01/introducing-testin...

hvs 16y ago

This just tells me that we need to figure out a new way to debug concurrent/cloud processes more easily. The traditional debuggers just don't cut it anymore.

aristidb 16y ago
How about trying to find errors as early as possible, by for example using the type system? That will not catch everything, but it will catch quite a lot.
- hvs 16y ago
  That's one of the trade-offs when deciding between a statically or dynamically typed language. Static typing isn't really going to help you with debugging/avoiding concurrency issues, though.
  - jedbrown 16y ago
    Well, the type system can be used to isolate side effects, thus ruling out large classes of concurrency bugs (especially with threads instead of separate processes or strict message passing (e.g. Erlang)). It can also prove that typing errors cannot occur, whereas with a dynamic language, it is possible for the program to be ill-typed in only certain circumstances (a function could return a different type depending on input). But yes, there are plenty of concurrency issues that are not greatly mitigated by static typing.
- pjscott 16y ago
  You can definitely get a lot out of using better abstractions, as the success of MapReduce has shown. I'll list a few ideas, with the warning that they may be half-baked: * Strong, stern type checking has always been kind of a pain in the ass, but it's very effective at catching miscellaneous stupid errors. If debugging in the cloud is hard enough, then maybe overbearing type systems are the lesser of two hassles. * Interactive programming is a big win. One of the best things about Lisp is the REPL, and how well-integrated it is with the editor. (At least, if you use something like SLIME.) If I'm programming on a distributed system, I definitely want to be able to quickly test out my code, preferably in a concurrent environment. You could solve this by having a bunch of servers for this, or with some fancy simulation environment, or a bunch of virtual machines, or something. The point is, I want errors to show up fast. * Really good log analysis. Ideally, any framework you're using would automatically log everything it does, and then you would use some nice tools to figure out what happened, and where it went wrong. Maybe the Loggly guys will come up with some good stuff. * Data-flow oriented abstractions like what Apache Pig offers. Pig lets you define a directed acyclic dataflow graph, in which each edge is some operation like "group by field x", or "filter by function f(fields)". It compiles all this into MapReduce jobs and runs them on Hadoop. It's probably a lot harder to mess up a query in Pig than with raw MapReduce, for sufficiently complicated queries. I'm not sure how much of a performance hit you take, though.

polynomial 16y ago

> Developing software is getting to be like fashion. Keep those old skinny jeans and workarounds in your closet. Sooner or later, they'll be in style again. Or is developing software like business? Sell those skinny jeans and workarounds when they are in demand, then buy some back when they go out of style. You're now ready for their comeback and you have some mad money in your skinny jeans' pocket.

wglb 16y ago

Actually around 1985, Mark Williams invented the C Source-Level Debugger, which certainly did not suck, and was quickly imitated by other larger outfits. However, my use of debuggers has always been quite minimal, perhaps because despite the CSD experience, I am often behind the times. Or perhaps it was due to my early (not quite childhood) experience building real-time interrupt-rich programs in Sigma 5 assembly language. I also read recently that most of the grownups don't use debuggers but have always stuck by printf or equivalent. It kind of reminds me of an early attempt on my part, not wanting to do laundry in my early bachelor years, to start a wrinkled shirt fashion trend. I was not successful, at least for a large number of years. It finally did become fashion. So stick with printf and build useful but lean logging habits would be my advice.