Why Isn't Debugging Treated as a First-Class Activity? - <AUTHOR> https://robert.ocallahan.org/2018/07/why-isnt-debugging-treated-as-first.html <comment><USER2> One practice I don't think I've ever really seen properly discussed is exploratory debugging. Given a large codebase I'm not familiar with, I've found that this workflow is an incredibly fast way to get familiar with the overall flow and structure of the code:

        - run the thing
        - grab an output string of some sort (either output proper or logs or whatever else)
        - grep for it
        - set a breakpoint where the string is generated
        - run again

From there, you can explore the stack, and you start to get your bearings. How is this particular thing generated? Find the place in the stack where it first shows up, set a break point, start over and debug from there. Repeat until you have a sufficiently solid grasp of the codebase that you can just navigate the source tree searching for where things are.

<comment><USER3> To each their own, I use to enjoy such. I absolutely hate it now. Given a codebase, I want to know the story. Why was the code written, what problem was being solved, why did they decide to solve it in a specific ways, WHY, WHY, WHY? I need to know the whys. I want the story, I want to know the domains. How is the software layered, can I explore one layer without going into other layers? I don't want to do so with a debugger. I want to do so with a document reader.

<comment><USER4> The downside is that this assumes a "why" exists. Codebases are often evolved rather than designed, and just are the way they are without persistent reasons for things. A common reason would be "because it was this other way before."

Imagine all the stuff that's probably in MS office, for which the reason is totally lost. There were reasons, but they're not really retrievable.

<comment><USER5> > Codebases are often evolved rather than designed, and just are the way they > are without persistent reasons for things. A common reason would be "because > it was this other way before."

Yes and no, I think. Codebases represent a collection of point-in-time decisions, and each one of those decisions had a reason. There's always a 'why' even if it's not captured.

> Imagine all the stuff that's probably in MS office, for which the reason is > totally lost. There were reasons, but they're not really retrievable.

True - and that's Really Bad. That means you're stuck not able to improve or change certain things, because you don't know why they were done that way - and when you have a userbase the size of Office, you can't just say 'f it' and break things - at least not lightly, as a code-level decision.

<comment><USER6> The worst "why?" answers often go like this:

1\. Green field+0 years: This particular portion of the system was designed in this way as a cargo cult.

2\. Green field+2 years: Because that portion of the system was designed in that way, we had to modify this other portion of the system to achieve X.

3\. Green field+3 years: Because of the change in 2, and this new constraint Y, we had to make this other change in a third portion of the system.

5\. Green field+(3 to N) years: repeat steps 2 and 3.

6\. Green field+N+M years: Wow 5 (or previous 6) has created a mess and exposed a serious architectural flaw from step 1 or previous 6. All of the logic in the various iterations of 2+3 are refactored as best as possible.

So, the "why" basically grounds out in "the refactoring we could afford to do in order to correct a mess that resulted from a cargo cult or previous refactoring of even older cargo cult".

Is that "why" functionally helpful? Usually not for me -- in either case, I can't really assume a lot and I have to proceed with laborious "just watch what the code does" debugging/logging that I would've done without the "why?".

But this is probably a ymmv situation.

<comment><USER7> The worst why that I regularly hear is, "the client changed their mind and it's the best we could do."

Which, of course, has two negative implications. Not just one.

<comment><USER6> Yes, that's the root cause of 2+3.

</comment></comment></comment></comment></comment></comment></comment><comment><USER8> The omission is interesting only in that it highlights that programming and debugging are one in the same.

Us old folks that have been programming for 20 years don't even separate the two, there is no meaningful distinction. Programming is not a write-only operation (Perl excepted).

If it's an existing project/product, I get it running and find the entry point. If it's new, I write and entry point and get it running. Then I change something, or write something, and debug it. Is it working as expected? Maybe the execution flow isn't what I expected. Why do I always forget to initialize things right. Probably because every language thinks their version of native v. abstract references are fancier.

Blah, I need to get to work cod... debug.... what am I doing today? Ah yea, writing documentation. Fack

<comment><USER9> >Programming is not a write-only operation

A lot of people would take issue with that statement.

Most devs probably wouldn't notice that their backspace key went missing until they were fine tuning the phrasing of an email about why the best way to solve their spaghetti is to make the same spaghetti slingers port the codebase to $FAD_OF_THE_WEEK.

Edit: It should be obvious that this is a joke but if it's not you should probably check if your backspace key still works.

<comment><USER10> > check if your backspace key still works.

Back in the late 90's, when Java was still sort of new, my employer insisted that I install an IDE to do my Java development that I had been doing mostly in vi. The one they picked (for some reason) was Symantec's Visual Cafe. I found that I could reliably, reproducibly, crash the IDE by pressing the backspace key. Maybe that was their way of pushing a "no mistakes" philosophy?

<comment><USER11> In that era no IDE ran stable across its whole feature set. Crashing debuggers were very common. VisualAge had the most stable debugger but would crash just typing in code.

Jetbrains was the first one that was reliable. Slow, but not as slow as VA.

</comment></comment></comment></comment><comment><USER12> Debugging is an extraordinarily first-class, up-front, frequent activity in Common Lisp, as the facilities are built into the language itself. While Lisp gets a lot of flak for basically (up to a few daring power-user exceptions) requiring Emacs, SLIME/SLY [1,2] are environments that will make you feel closer to your program than you get in other environments, including graphical IDEs.

Given that the normal way to develop a Lisp program is to do it incrementally, your program (or someone else's!) _will_ break, and it will break often, and you'll get launched into an interactive debugger. But it's friendly, not requiring a completely separate, foreign toolchain, and much of the functionality works regardless of which editors/IDEs you're using (though Emacs makes the experience much more ergonomic).

I think this is perhaps a bigger selling point of Common Lisp than all the great, oft-quoted things like metaprogramming.

[1] [https://common-lisp.net/project/slime/](https://common- lisp.net/project/slime/)

[2] [https://github.com/joaotavora/sly](https://github.com/joaotavora/sly)

<comment><USER13> _Debugging is an extraordinarily first-class, up-front, frequent activity in Common Lisp, as the facilities are built into the language itself._

Smalltalk is something like the ultimate debugger. The advanced Smalltalk coders would often do most of their coding in the debugger. (It's very easy to unwind the stack a few places, then resume execution.) The VisualWorks debugger was so nimble, people would put expressions to be executed and debugged into code comments! (The debugger would execute the code in the context in which it was evaluated, so this could be absolutely awesome.)

 _Given that the normal way to develop a Lisp program is to do it incrementally, your program (or someone else's!) will break, and it will break often, and you'll get launched into an interactive debugger._

One of the most frequent demos we did in Smalltalk, was to write some empty scaffold methods, launch into an exception, then fill in everything in the debugger until the system was complete.

<comment><USER14> I think direct language support for "missing code here!" is a brilliant idea. Even when you have types and documentation, you often need to dummy check that values you'll get called with are what you expect.

<comment><USER15> I've heard Smalltalkers tell tales of starting an empty project by just hitting "Run", letting the debugger take exception to that fact that there is no startup function, then start typing code as it becomes necessary to proceed.

<comment><USER13> That's what I just wrote!

<comment><USER16> I read the GP as saying "you don't even need to create the scaffold methods" described in your post.

</comment></comment></comment></comment></comment></comment><comment><USER17> I'm using IDE debuggers as integral part of my normal programming workflow, not for actual "debugging", but for stepping through new code to check if it "feels right". I hardly find bugs that way (that usually happens when the code is out in the wild and several unexpected things happen at the same time), but I add a lot of little changes based on the step-debugging... rename a variable here, add a forgotten comment there, and also think about what to do next. I'm quite sure I spend more time in the debugger then writing code.

I wish edit-and-continue, rewinding time, etc... would be better supported across IDEs. Programming should be a "conversation with the machine", and ultimately with other programmers. When I'm stepping through my own code, I try to assume the role of an "outsider" and judge my code from the "outside".

The debugger is also the most important tool for me to understand code written by others.

<comment><USER18> Edit-and-continue works in several languages. Java can hotswap, for instance. And you can to some extent rewind by dropping the current frame (unless your code had side effects, but that's just another reason to avoid them ;) )

But I think my workflow is similar to yours. I often set a breakpoint in my new code and just watch the state to see if it looks as expected, so small tidbits of usage here and there.

</comment></comment><comment><USER19> From the article: > One thing developers spend a lot of time on is completely absent from both of these lists: debugging!

I notice that times changed a bit. This was true in software engineering like 10 years ago, but in recent years there is much more emphasis on good practices, constant refactoring, implementing lots of tests alongside the production code, etc. I debug maybe 1-2 hours per month, as a full-time programmer.

<comment><USER20> I agree on good practices, but often TDD is wasted time. Not on larger systems, but on small systems with limited functionality where you build using principles like SOLID so you always know where the flaw is, even without the test.

We used to write an awful lot of tests on everything. When we stopped we increased productivity by almost 60% at almost no cost.

As I said, we still work with TDD, but we only do it when it makes sense.

<comment><USER21> You don't have to do TDD for this to be useful or happen.

In my current project we follow a "bug -> reproduce bug in testcase -> fix bug" method for some parts of the code. This has cause quite an extensive test suite to develop for those parts of the system.

<comment><USER22> I'm curious... I can see the obvious value of having a testcase for a class of bugs, but a testcase for a particular bug instance which was already fixed earlier does not seem right, so I probably misunderstood something.

How often do the tests find a problem?

When it does find a problem, doesn't this mean that one hits a bug which existed before?

Can you give an example of a case when the test was useful?

<comment><USER23> This is known as regression testing, and it's extremely useful. For example, you find some bug where, say, a calculation produces a nonsense result. You fix it, then add a test for what you just fixed. 2 years from now, someone refactors the code and reintroduces the bug because their refactor didn't take into account all of the possible input cases. Your test now catches it.

Our regression tests have literally found hundreds of bugs over the years and saved us a lot of time and embarrassment.

<comment><USER22> Thanks. Of course. I see what you meant now.

</comment></comment></comment></comment></comment></comment><comment><USER24> More broadly, reverse engineering a codebase is a critical software activity. If you can't reverse engineer a codebase you can't debug it or add to it. Working with an existing code base is pretty much a given, unless you're developer #1 on a startup. Your success as a software developer hinges on how well you can work with an existing codebase.

One less celebrated but very valuable approach to grasp a codebase is the way you document what you've learnt. While you can learn about a codebase through exploratory debugging (mentioned by someone on a separate comment) you have to persist that knowledge on "paper" in some way. My favorite ways to do that:

      - class diagrams (for static stuff like data structures, class relationships, etc.)

      - sequence diagrams (for dynamic stuff like which functions call which and data passed between them)

With good documentation for your own learning purposes, it'll become easier to start working on a codebase and especially when you context switch, it'll help you return to a codebase more easily.

<comment><USER25> Ideally, documentation would be written so that there is no need to reverse engineer every project you wade into. Otherwise why share the source code in the first place?

<comment><USER24> There's various kinds of documentation of differing granularity. Typically the high level documentation (coarse grained if you will) about architecture, requirements, etc. stays good over time but finer grain documentation (the kind I mentioned in my earlier comment -- data structures, order of function invocation, etc.) gets stale quickly because source code is constantly changing -- it gets refactored, plenty of bug fixes are put in, etc.

Reverse engineering is probably a loaded word, but in general digging in to understand the codebase helps you work more efficiently and avoid introducing bugs to the extent possible.

</comment></comment></comment><comment><USER26> Reading the comments here I get the impression folks are thinking about "debugging MY code". In my experience when you are debugging you are almost always looking at an issue in someone else's code.

</comment><comment><USER27> I see a disturbing trend in industry especially in Bay area from my experience.

Young engineers are bad at debugging, bad means real bad but good at programming puzzles.

This points to the fact that people value puzzles over experience and in turn miss the big picture.

Sure you can code up a balanced RB tree in 5 mins, but what will you do when packets start showing up in bursts on your service? Can you find out that on a live system?

I despise this new Bro culture of mugging programming puzzles from leetcode and hackerank. Faltering at first real world challenge is not only disappointing, but an insult to craft of engineering.

/Rant over

<comment><USER28> Echoing this and an earlier thread...interviewers could have debugging exercises with an existing codebase. I have seen this ambitious approach at a few startups. Instead of asking yet another sorting algorithm or HackerRank brainteaser.

Until the application process changes, the applicants won't change.

<comment><USER29> interviewing is only a small part of the picture. mvp has so eroded the notion of correctness that whole organizations don't even look for bugs anymore.

try upgrading the dependencies. wrap the service in a harness to make sure it gets restarted when it fails. forget about proactively looking for bugs, wait until they come in, and if you have time that week before they slip into the 'stale - never to be addressed' pile, spend a few minutes trying to reproduce and mark 'works for me'

</comment></comment></comment><comment><USER30> I use debuggers in anger since Turbo Vision based IDE for Turbo Pascal 6.0 on MS-DOS.

If everything that one can do with a graphical debugger is single-step, step- into and continue, then they are using like 1% of its capabilities.

Taking advantage of a graphical debugger, specially when the environment supports code reload, is quite productive for interactive programming.

<comment><USER31> One of the besting things about Java and having a strong IDE ecosystem.

When I was working in Java 7 + Eclipse the ability to hotswap in changes to functions made debugging (even in production) a dream! Dropping a few new lines of conditional logging into a service was crucial for those 3am war room sessions.

Now, working in Java 8 + Intellij hot swapping fails constantly because lambdas don't seem to compile is a stable fashion. Eclipse uses a more development friendly compiler ECJ so I wonder if it has this solved.

<comment><USER30> I am yet to try out that scenario on Eclipse as I tend to refrain my FP enthusiasm due to team members.

</comment></comment></comment><comment><USER32> He writes « Perhaps people equate "debugging" with "using an interactive debugger" »

I think it's useful to think of two independent 'axes' of debugging:

\- single-stepping vs reading traces

\- using specialist debugging software vs modifying the code

Most of the time I much prefer reading traces, and IDEs often have decent primitives for setting sophisticated tracepoints, but the UI support for them is often very weak (while adding a breakpoint might be a single key press).

So I've often found myself using 'printf'-style debugging because (until compile times get very long) it's more ergonomic then using the debugger's tracepoints.

I haven't tried rr yet. Does anyone know how good it is at this? I'd like to be able to do things like define a keypress for a given tracepoint and toggle its output on and off while I'm scrolling through a trace.

<comment><USER33> > using 'printf'-style debugging

And the horror that descends upon you once you commit+push those statements.

<comment><USER34> Either "don't do that then" or have a logging framework that lets you leave enough printf in to diagnose crashes in the field.

<comment><USER33> I used to debug using print statements earlier and that was because we were not allowed to use any IDE. Now that I know hoe to use IDEs properly, things have been better. And there is always logging and `git diff` to help you out. Those colouring schemes really come handy.

</comment></comment></comment></comment><comment><USER13> There were Smalltalk server processes that would catch an exception, snapshot their memory image. A developer could then come along, and open a full interactive debugger on a live, running version of the system, which they could then modify then run as a quick dev test.

</comment><comment><USER35> The academic Software Engineering community certainly does put a lot of attention on debugging.

See my list of publications for a number of empirical studies on debugging and tools to support more efficient debugging: [http://austinhenley.com/publications.html](http://austinhenley.com/publications.html)

</comment><comment><USER36> I worked on petabyte-scale data at Mozilla. Here is a talk I gave on the history of debugging and the ways in which doing distributed large data analysis requires moving beyond printf() and STEP:

[https://www.youtube.com/watch?v=QHJBPzfrokU](https://www.youtube.com/watch?v=QHJBPzfrokU)

</comment><comment><USER37> I agree with the author that a debugger is a poor fit for many systems. However, debugging is essential, and I think debugging by checking logs works very well in many cases (provided that the logging is good). Some of the advantages (over debuggers):

\- Anybody can look at the logs, not just developers.

\- The logs show the sequence of events, not just a snapshot.

\- Feasible to do in a live system.

[https://henrikwarne.com/2014/01/01/finding-bugs-debugger- ver...](https://henrikwarne.com/2014/01/01/finding-bugs-debugger-versus- logging/)

<comment><USER38> A debugger that doesn't support those three things is just a lousy debugger.

<comment><USER39> There are many different kinds of debugging, and a debugger optimized with an interface for pinhole inspecting and stepping isn't the best tool for logging and log processing, it is ok for them to be separate things.

<comment><USER38> I never said not to log or look at logs, but a good debugger should be possible to attach to a running process, and reverse debugging can give you access to past events.

<comment><USER39> Sure, but you are still dealing with a pinhole even if you can move that pinhole around. It isn't a complete debugging experience, nor was it meant to be.

</comment></comment></comment></comment></comment><comment><USER40> I feel like it has a lot to do with the ambiguity involved in debugging, and the fact that it is hard to teach.

I have found debugging to be fuzzy and largely based on experience, mental models, and internal (scientific method based?) approaches.

There seem to be a relatively few debugging methodologies or frameworks. (ie in performance/systems realm there are USE, RED, ...?). I have only started to recently create a formal framework (a google doc I update after each incident) after 9 years of engineering experience! Not because I wasn't interesting in debugging, but it literally took 9 years worth of debugging incidents for patterns to start to become apparent to me (i work devops/system so when there is a general feeling of a problem I'm usually tasked with finding root causes).

On a side note: so far the framework has been successful within my org and I hope to formalize it enough to write about it in the near future :)

</comment><comment><USER41> "90% of coding is debugging. The other 10% is writing bugs" - Bram Cohen

</comment><comment><USER42> Somebody once posted in a Slack channel I was part of asking for things they should include in a course they were teaching for new programmers. My #1 recommendation was how to read a stack trace. The second was how to put a logging statement into your code to capture state.

</comment><comment><USER43> Just get them working on some mess of a WordPress project and you'll get them all reaching for xdebug right quick :D

</comment><comment><USER44> The result of debugging will be summed up in a commit or a ticket in Gitlab. Why should Gitlab care about the process?

<comment><USER45> Maybe he wants something like a log analyzer similar to splunk?

Or something mobile clients send their exceptions?

Sadly the post is not very clear, so we can only guess.

</comment></comment><comment><USER46> I'm afraid of building a habit of making haphazard tweaks until it seems to DTRT in one case. I don't like the idea of needing the machine to explain to me how my own code actually works. The feeling of complete understanding is an important motivator to me.

<comment><USER47> If you had a bug, then you didn't know what machine is doing. You think you have an idea it's doing X, while it does Z. If you have ever written a bug because you should have written ++x instead x++, then you need the machine to tell you what it's doing, because it's not doing what you think.

If have never ever written a bug, contact me for a job offer, I'll pay you 300% of my salary.

<comment><USER48> > If have never ever written a bug, contact me for a job offer, I'll pay you > 300% of my salary

I know just the guy. He was interested in learning how to code.

</comment></comment></comment><comment><USER49> I used to spend my days in the Java debugger, stepping through framework code to troubleshoot application-level errors, as the stacktrace we had obfuscated the error, or everything was simply broken.

Depending on the situation, I might spend most of my day debugging, as a way to better understand the program and as a code analysis tool.

This was especially useful if dealing with a code base that I was not familiar with, while in code that I wrote myself most of the time logging is sufficient.

I'm not sure why the author thinks that debugging is not a priority for tool makers, the debuggers that we currently have are awesome and have been so for years.

</comment><comment><USER50> Debugging is hidden here:

Bug handling is easy, fast, and friendly Information on "code flow" is clear and discoverable

I use interactive debugger inside IDE or inside profiling tools. Debugging is something I do alone, so it does not need special process support.

</comment><comment><USER51> I think the approach we should take is to pour more effort into minimizing the risk of debugging being necessary. Good practices, better type checkers and logic models (e.g. there was an article posted in the front page here about using linear logic to push the boundaries of file systems). Debugging can be a time sink and can become a painful task for fast distributed systems.

We should learn and hone that skill of course, as it does not only offer a solution when lightning strikes, but a way for the developer to gain comprehension of the "internals".

</comment><comment><USER23> In my opinion the reason that debugging isn't treated as a first-class activity is that it isn't taught at all in schools. Or at least it wasn't when I was in school. We were given about 2 sentences that said, "the debugger is at /usr/bin/gdb. It can help you step through your code to find a bug." And then we were thrown to the wolves with what is arguably one of the worst debuggers in the world with no documentation and no help.

</comment><comment><USER52> While we probably will always have to debug, and if not the "code" it will be a specification formal enough so that it can be considered code anyway, there are different ways to approach its role within the lifecycle of software development: on the two extremes, one can "quickly" but somehow randomly throw lines without thinking much about it, then try the result and correct the few defects that their few tries reveal (and leave dozen to hundreds of other defects to be discovered at more inconvenient times); or one can think a lot about the problem, study a lot about the software where the change must be done, and carefully write some code that perfectly implement what is needed, with very few defects both on the what and on the how side. Note that the "quick" aspect of the first approach is a complete myth (if taken to the extreme, and except for trivially short runs or if the result does not matter that much), because a system can not be developed like that in the long term without collapsing on itself, so there will either be spectacular failures or unplanned dev slowdown, and if the slowdown route is taken, the result will be poorer as if a careful approach would have been taken in the first place, while the velocity might not even be higher.

Of course, all degrees exists between the two extremes, and when going too far on one side for a given application is going to cause more problems than it solves (e.g. missing time to market opportunities).

Anyway, some projects, maybe those related to computer infrastructure or actually any kind of infrastructure, are more naturally positioned on the careful track (and even then it depends on which aspect, for ex cyber security is still largely an afterthought in large parts of the industry), and the careful track only need debugging as a non-trivial activity when everything else has failed, so hopefully in very small quantities. But it is not that when it is really needed as a last resort, good tooling are not needed. It is just that it is confined to unreleased side projects / tooling, or when it happens in prod it marks a so serious failure that compared to other projects, those hopefully do not happen that often. In those contexts, a project which need too much debugging can be at the risk of dying.

So the mean "value" of debugging might be somehow smaller than the mean "value" of designing and writing code and otherwise organizing things so that we do not have to debug (that often).

</comment><comment><USER53> I often wonder why it's not treated as a first class citizen when teaching programming. I think there should be a full CS course dedicated to it.

I put together [http://www.debug.coach/](http://www.debug.coach/) because a guy I used to work with had better debugging skills than anybody and I noticed it was because he always knew the right questions to ask.

</comment><comment><USER54> I think that is because there are no good free open source debuggers? In Visual Studio you just set a breakpoint and examine the variables; it works great. On Linux you are left alone against a command-line monster with outdated weird command syntax.

gdb has an awful interface; it requires you to read a long manual and learn outdated command syntax before even using it; it is often faster to add logging and rerun the program. It is not a debugger for humans.

For comparison, JS debugger in Chrome devtools works pretty good and is easy to use. It is really helpful and allows you to identify a problem very quickly (faster than reading an introduction page for gdb). But it has problems sometimes, when you try to set a breakpoint and it is set in another place or is not set at all without any error messages.

I saw some comments here against visual debugging; maybe their authors had experience with some buggy or poorly written debugger?

I also tried to use Firefox developer tools in several versions up to FF45 and almost every time something didn't work. And when they work, they choke on scrolling large minified files or heavy sites with lots of ads.

<comment><USER55> > In Visual Studio you just set a breakpoint and examine the variables; it > works great. On Linux you are left alone against a command-line monster with > outdated weird command syntax.

You're comparing an IDE to a command line environment, Linux has various IDE's that are more comparable and I believe some standalone front ends to gdb, windows also has windbg and dotnet mdbg that are the command line equivalents of gdb that VS is interacting with for you.

Gdb (and windbg for that matter) is much more powerful than visual studio debugging though, much like vim and similar tools it's not easy to learn but it's easy to use once you have learned. Stop expecting instant gratification.

</comment></comment><comment><USER56> Because most languages treat edit, compile, test, debug phases. No organic evolution of your idea to code to running app all the while tweaking it without restarts, which are pit stops that completely break your momentum.

That needs languages designed upfront with debugging etc as a first class live feature.

</comment><comment><USER57> One thing that may be relevant is that I was never introduced to debugging in university at all. You were expected to just invent useful techniques on your own. Without any exposure, it is hard to justify learning that over any other topic you feel like you aught to be learning.

</comment><comment><USER58> Because debugging is not a first-class activity.

If you are careful when you program (assertions, tests, logging) you rarely need to use a debugger. Time spend on a debugger is invisible and lost. It is much better to spend time adding assertions, levels of logging, and writing tests.

<comment><USER59> Depending on the capabilities of a debugger, developers might have test failures drop them into an interactive debugger that allows reloads/re- execution of code units.

Debuggers can be I instrumented to do a lot of dev-only logging for you.

I _do_ write tests and assertions, but if those fail, I am dropped into a debugger (if prog is executed interactively), I can immediately inspect the state of my program and more often than not fix the problem on the fly.

<comment><USER60> I think that, while this might work, the approach to managing state and writing the tests is not ideal. For one, your tests should be fast (ie you should be able to rerun them with almost 0 time penalty and see the results instantly). Second, if it's easier to stop the flow and look at the state / modify the state than looking at what the state should be via the test setup it's possible that the abstractions you're using are not quite right and/or the code is tightly coupled.

<comment><USER59> > I think that, while this might work, the approach to managing state and > writing the tests is not ideal.

I strive to not manage state but to write purely functional code, it makes life so much easier - see your second point as an example :)

</comment></comment></comment></comment><comment><USER61> If you needed to debug, it is a sign that you have made a mistake. Who wants to admit to making the mistake? :-)

Seriously though, I imagine that the junior devs would have such a view of debugging. But the matured devs would plan for it as they know their limitations.

</comment><comment><USER62> For the same reason that the water treatment plant gets more respect than the sewage treatment plant.

Everyone would prefer to provide something fresh and clean than to wade through other people's poop.

</comment><comment><USER63> Ask Bryan Cantrill. He is a first grade debugger.

</comment><comment><USER64> has anyone written intelliJ plugins that deal with the debugger? I have an interesting idea wrt to this, but writing an IntelliJ plugin has so far been extremely painful. If anyone out there is interested send me a message and let's chat

</comment><comment><USER65> I would go so far as to suggest that if you need a debugger, you're probably doing it wrong.

I have found that code that needs a debugger is code that is written in an extremely stateful fashion.

The very reason why debuggers exist is to deal with code that has a dozen variables book-keeping complex state that you need to track closely to figure out how something works (or why something doesn't). Debuggers even have "watches" to track something closely so that it doesn't change underneath you, when you aren't looking.

To me this is a code smell. I would suggest that instead of using a debugger, we ought to be composing small functions together.

Small and pure functions only need an REPL to test.

Once you make sure the function is behaving right, you can almost just copy paste over the test cases you ran in your REPL into unit tests.

The simplest way to enforce this discipline is to do away with assignments, and instead constrain oneself to using expressions. This forces one to break code into smaller functions. Code written this way turns out to be much more readable, as well as reusable.

I suggest that we eschew the debugger in favour of the REPL.

<comment><USER66> This is perhaps one of the most harmful statements I've ever read on Hacker News. You're not doing it wrong if you use a tool to help you understand what your program is doing. Should you follow good design patterns, like using small functions when writing your software? Yes. Should you minimize complex state? Sure. Should you use tools to help you understand what your program is doing? Absolutely. The two are not mutually exclusive.

There are a LOT of different ways to write software. Some more stateful than others. Some lower level than others. Some more asyncrounous than others. Some more functional. Some more object oriented.

Your experience with the software you write in your day to day, is not the same stack and may not even be in the same universe as what others are attempting. Writing a React app is very different from writing a game in Unity, which is very different than writing a game engine in C++ which is very different that writing large scale services that talk to clusters of computers and hardware devices, which is different than writing some low level library in Rust or Haskell or doing data science in R or Octave.

Please fucking stop with this "one right way", "you're dodging it wrong" dogmatic bullshit. Your limited worldview does not apply to ALL of software development.

Use a fucking REPL if you want. Use a debugger if you want. Use logs and traces if you want.

Just try to write good software, try to understand your code, and ignore dogmatic and valiantly bad advice and opinions like the parent comment on Hacker News.

<comment><USER65> > This is perhaps one of the most harmful statements I've ever read on Hacker > News.

And here I thought I was writing an innocuous comment on debugging code. Hyperbole much?

> There are a LOT of different ways to write software... Writing a React app > is very different from writing a game in Unity, which is very different than > writing a game engine in C++.

It's interesting that you brought up these 3 use cases. I started my career working for a shop that wrote a game engine in C++, then moved to Unity. I now write React apps for a living. Do I know you? :)

With the exception of a few corner cases, like portions of code that does rendering, and HFT software, where performance concerns trump everything else, what I have seen in that time is the following:

1) decomposing your code into smaller functions is objectively better than NOT doing so. 2) writing functions that don't mutate its local variables is objectively better than writing functions that DO.

By "objectively better", I mean that the code written conforming to the above have the following characteristics: \- more readable than code that does not. \- more testable than code that does not. \- more re-usable than code that does not.

It's on these two assumptions that I build my case for eschewing the debugger altogether in favour of the REPL. If you write code conforming to the above, you have absolutely no need for a debugger.

Having said that, it is possible that you need a debugger to wrap your mind around code bases that you inherit, which were written poorly (or equivalently, in a very "object oriented" fashion).

<comment><USER66> I don't disagree with your principals of good code quality. I disagree that by following those principals you no longer need to use a debugger or to develop debugging skills. Your post is harmful because it suggest to junior developers that if they must use a debugger they must be developing their software in a poor fashion. This is not true. There are many good reasons to use a debugger, including to develop software or to explore a codebase and to debug your code.

<comment><USER65> > I disagree that by following those principals you no longer need to use a > debugger or to develop debugging skills.

Using a debugger (as in, software where you step through code) and developing "debugging skills" are entirely different things. I was only commenting on the former.

> Your post is harmful because it suggest to junior developers that if they > must use a debugger they must be developing their software in a poor > fashion.

Would it be better if I said: "if you need a debugger, you have are either mucking around in poorly written code that you inherited or you're probably doing it wrong"?

> There are many good reasons to use a debugger, including to develop software > or to explore a codebase and to debug your code.

I concede that exploration of a codebase is a valid use of a debugger.

</comment></comment></comment></comment></comment><comment><USER67> Prejudice. The same reason NASA janitors aren't glorified as the astronauts are.

<comment><USER68> Well, the astronauts could always wipe the floors themselves, or just work in a dirty building.

The janitors probably lack the skills to go to space and command a spaceship.</comment></comment>


The Diminishing Returns of Everything - <AUTHOR> https://stevenshang.com/things-i-learned-today-april-25-2020 <comment><USER2> I can see why it _feels_ this way, but often times it seems to me the opposite is true, like a phase transition: it remains a bunch of commits until at some point it 'suddenly' becomes a product, usable by the designated users, solving a problem, possibly generating revenue. Like water that cools and cools and eventually turns to ice, even though that last quarter degree didn't change the temperature a lot.

<comment><USER3> I think you're getting at something very important about the article.

> The first couple hundred lines of code of your project will have a much > larger impact than the last few thousand lines of code ever will.

This is true of impact on functionality, not necessarily impact on the world.

If I write my own todo app it might be useful to one person, but as I continue to work on it, eventually 2 people will find it useful. Then 3. I could be up to 3x less productive per hour and still have the same impact per hour due the increased number of users.

Impact on the world is (functionality) * (# of users). If you're working on a useful project the number of users will more than make up for the diminishing functionality returns per hour.

<comment><USER4> To rephrase this then: your additional work may improve your product only a little, but it may be enough that it can now compete in the market. If it's a winner-takes-all market, a slight improvement in quality may be especially consequential.

 _edit_ I think this might model the success of Slack. _Which chat program should we use? There are lots of free ones and they 're all about the same, but Slack has slightly better polish than the rest and is easy to set up. Let's use that._ If that conversation happens in tens of thousands of organisations, you take over the world.

</comment></comment></comment><comment><USER5> _> The only exception to this rule I can think of is McDonald's fries. The more you eat, the better they become. It is true._

Potato chips are, to me, an even more perfect example of this effect. They are engineering marvels. If a food is too salty, you eventually crave something sweet. Too sweet and you get tired and want salt. Potato chips take the sweetness of potato starch and add _just_ the right amount of salt to keep you balanced.

The satisfying crunchiness gives way to carby creaminess, which then promptly dissolves entirely, leaving you feeling like you haven't consumed anything at all [1], so surely one more chip is OK, right?

Potato chips are my crack. If I could eat them unburdened by shame or the desire to take care of my health, I would eat them until I burst.

[1]: [https://www.nytimes.com/2013/02/24/magazine/the- extraordinar...](https://www.nytimes.com/2013/02/24/magazine/the- extraordinary-science-of-junk-food.html)

<comment><USER6> It feels like some foods have fervent followings despite contributing to things like heart disease. It's a good example of how humans get thrown off when dealing with decades long timespans of bad choices that add up, except with food we all have to eat.

I recall that when processed meats including bacon were classified as carcinogens, people basically said "screw that, it's _bacon_ for crying out loud." I'm not sure to what extent they were joking. I personally avoid all processed meats, but to me the public sentiment over some unhealthy foods is in stark contrast to public sentiment over smoking or alcoholism.

One time I searched something to the effect of "why are potato chips unhealthy" and got back a general sentiment of "well, they're not _that_ bad for you, as long as it's only once in a while." I feel like with this attitude it adds up over time though. It's probably not possible to pin down exactly what foods caused a heart attack, as opposed to being able to more clearly associate lung cancer with a smoking addiction.

With smoking it provides no real benefit except lessening the craving for another smoke. With unhealthy foods everyone has to eat, so maybe you'd be more forgiven for eating them than throwing away your health on something not essential to survival. Fancy ice cream parlors are the norm, and nobody is going to lobby politicians to close them down in the name of public health. It's just ice cream, served by people working out of food trucks trying to make a living. The most they do is insitute soda taxes. God forbid soda itself is banned.

Is there an illustration on how foods like potato chips affect health long- term? Something like the study that estimates every cigarette takes eleven minutes off your lifespan. There are a lot of different foods to cover though. I feel like if there was data stating every potato chip took X seconds off my lifespan it would be easier to deny myself from buying them by looking through the items at the supermarket and being able to think "17 minutes, 22 minutes."

When I think of someone beginning to smoke I imagine them being told "you're going down a path that will almost certainly kill you down the line." When I imagine someone being a regular at an artisan donut shop I imagine people asking them how the taste was.

<comment><USER5> _> I recall that when processed meats including bacon were classified as carcinogens, people basically said "screw that, it's bacon for crying out loud." I'm not sure to what extent they were joking._

I love bacon. I know it's unhealthy. I still eat it.

You seem to be coming from a perspective where the only goal is to maximize life. But that's not how people operate. People are trying to maximize _living_.

I could probably live to 110 if I ate nothing but tofu and mineral water and lived in a sanitized bubble. But would I even _want_ to?

I don't want to make choices so unhealthy that they significantly impact the quality and length of my life. But I sure as hell want to pack as many experiences as I can before I reach that point. Some of those experiences are going to take their toll on my body. That's the price you pay for living and for many experiences, the price is worth it.

Personally, I don't think it is for cigarettes. (And, in particular, it is certainly not fair to make people in the _vicinity_ of smokers pay that price.) But many people love the sensation of smoking. I do think it's worth the price to have some bacon with breakfast and a whiskey nightcap before bed.

 _> I feel like if there was data stating every potato chip took X seconds off my lifespan it would be easier to deny myself from buying them by looking through the items at the supermarket and being able to think "17 minutes, 22 minutes."_

You are describing a dystopian nightmare. Can you imagine this applied to every choice you make? You see a cute person on the other end of the bar and a little chat bubble appears in your personal heads-up-display "They will break up with you two years after you begin dating." You look at a cute puppy at a shelter. "She will die young of congenital heart disease."

<comment><USER7> "I could probably live to 110"

The problem is, if you get an extra 20 years, they aren't added on between say 40 and 50. The years from 90 to 110 aren't going to be much fun.

</comment></comment></comment></comment><comment><USER8> > For instance, I spend the past two days working on a single CSS file, in an > attempt to center-align some stupid buttons (a futile attempt, since they > are still not aligned). In comparison, at the beginning of the project, I > built out the entire REST backend of the web app in a single afternoon.

It could be argued that the value of the REST backend is lower than the value of the stupid buttons: since the backend is so simple, everybody can do it, while the stupid button takes a wizard to get right. On the market, your commoditized REST backend will have to compete with other solutions on the quality of your stupid buttons.

Hence, spend even less time on the backend, by using auto-generators, and focus all your time on the button. Buttons are a big dollar business.

Damn, I wish a had a CRUD-auto-generator-business, this would be the perfect plug. Check out auto-crud-button-focus.com right now!

/edit: adding the [irony] tag before I get more insulted "WHAT???!?!?!?"s (I know nothing about backend stuff, I work in embedded and electronics)

<comment><USER9> > since the backend is so simple, everybody can do it, while the stupid button > takes a wizard to get right

What?!?!?!

<comment><USER10> That was, as the saying goeth, the joke.

</comment></comment></comment><comment><USER11> This is disingenuous. Sure, the first X hours of working on a new project are a lot of fun and you can set up the framework for what you're doing and feel like you're making great progress.

But what you're missing is detail and quality. For example, I can set up the structure of my thesis by working out chapter titles, headings, subheadings and drafting bullet points per section. Straightforward. But doing the research and writing up takes years, it's often boring, laborious and the net addition to the document can be as low as a couple of hundred words a week. It doesn't mean the actual work is less valuable as time progresses.

Likewise let's consider a software development project. We can make grand strides in the first X weeks, gathering requirements, creating user stories, creating tasks, sprints, assigning work, setting deliverables, setting up the various ceremonies. But at some point it boils down to writing some code, often boring, time-consuming, detailed and slow. It doesn't mean the contributions made later in the project are any less valuable than the frantic hive of activity in the beginning.

<comment><USER12> You're misusing the word "disingenuous". The author has no ill intention of being insincere.

<comment><USER13> Simplifying, "The author has no intention of being insincere."

Or perhaps even, "The author is not insincere."

Or alternatively, "The author is sincere."

</comment></comment></comment><comment><USER14> I don't really like the emphasis on "wasting" time, the way he wrote it in the bathroom light automation section. If you do not enjoy tinkering with voice activation (or X thing in the general sense), then I can see why you wouldn't like losing time, but I would probably feel like it was 5 hours spent learning about home automation and voice control, which could maybe be applicable in other cases, both within home automation and outside of it. I don't see the 3 hours mentioned as "lost", but as time spent learning.

<comment><USER15> Not all time can be considered equal. Let us say that one of my team spent two weeks building tooling that might save us a single day on two occasions. That might still be worth it if that day saved is part of some time pressured work.

You can think of this as the classic engineering 'latency vs throughput' tradeoff. We're spending a bit of throughput to get an improvement in latency.

</comment></comment><comment><USER16> That's why you pay contractors / specialized people.

A 2-day electrical job would probably have taken me a month to complete working evenings / week-ends, assuming no other house maintenance on the side, and the job would certainly have been sub-optimal and I'd have selected overkill components. Same goes about a plumbing job, it's not rocket science, but working in tight spaces can be tricky/messy, professionals know how to do it.

As for the backend, it's easy to spin up if you know the tech, have done it a couple of times and know what to do. Given enough time, I could probably design an IoT gadget from the ground up. FPGA conception, ASIC design, then PCB integration, spin up, mechanical design, network interfacing, back & front end services. But not only the end product will certainly be over-engineered, but it will have taken me 2 years to build and I would have no idea how to sell it.

I had a family member who cashed out in the SV and then tanked his next start- up. Long story short, he's a business guy, not a tech guy. He lost 3 years on fairly simple MVP, then finally decided to pay someone, but it was too late.

I guess the morale of the story is to know ones own limits...

</comment><comment><USER17> > The first couple hundred lines of code of your project will have a much > larger impact than the last few thousand lines of code ever will.

I think it's easy to underestimate the importance of polish and fit and finish. In my experience a product's success or failure is made in the last 20% of development, when all the fine tuning and bug fixing goes in to overdrive, and user experience is honed.

</comment><comment><USER18> > The first couple hundred lines of code of your project will have a much > larger impact than the last few thousand lines of code ever will.

With this explanation, the author explains the diminishing returns by the fact that their value decreases ("impact"). I disagree: returns diminish because their cost increases. Assuming a thing can generate 100% of some value, the range 0-20% generates as much value as the range 80%-100%, but the latter range is more costly than the first range.

The return of centering the buttons is significant, because if they're not centered then the product will look unprofessionnal, which is not good for business. It just happens than the cost of centering them is high, in this case as high as setting up the REST service in a first place.

The return of having your company survive is extremetely high. It just happens that this cannot be done with the first few dozens employees but with hundreds more, which is of course way more expensive.

</comment><comment><USER19> > The same goes for abs. The first ten thousand set-ups you do just may give > you that 6-pack abs you want, but another thirty thousand sure won't get you > the 7-pack.

He picked the one type of exercise which doesn't really change. If you're lifting or running, you see _increasing_ returns for a long time. You get stronger by lifting heavy weights, and you need to lift light weights to be able to lift heavy weights.

<comment><USER20> It's also a bad example because pack number is determined largely by genetics and visibility is largely determined by diet. Look at Arnold in his Mr Olympia days, he only had a 5-pack.

</comment></comment><comment><USER21> But let me put it in perspective, if I wasn't wasting my time moving that button, I'd probably be watching youtube.

Is that wasted? Was it truly 3 hours lost for the OP trying to automate the light switch?

Nihilism. Do what you believe is worth it. Otherwise, don't because it's simply not worth it.

</comment><comment><USER22> I think there is additional value to automating or improving a process even if the time spent automating exceeds the time saved by the automation.

What if it just makes me happy that I can turn the bathroom light on with my voice even though the time spent figuring it out exceeds any time saved by the automation?

What if I make a sucky task at work more approachable and easier by improving it? Rather than procrastinating doing the thing because I hate it, I pick it up and do it right away because I invested some time in making it suck less.

What if I gain skills automating one thing that make me more efficient on the next thing even if I'll never recover the time spent on the first thing?

</comment><comment><USER23> Re: the voice activated light class of idea. I have a weird NIH/hoarding bug. I always try to do thing on my own (am now making electrical circuits). Somehow it's a huge waste of time. Yet I know a ton of stuff and can fix some things, or avoid fear and scams.

One alternative is a hub of DIYers. Remember the story of how Xerox PARC operated ? unattended, unmanaged.. you had an idea or a problem you ping people around that know that domain, chat around and make a thing. In groups it might turn diminishing returns into a massive life enhancement (in theory, I never worked in such an environment).

ps: I actually think that picking this kind of projects is a tiny art. Don't scratch all itches but know that knowing is always a good thing.

</comment><comment><USER24> That's the Pareto principle [0]: 80% of the effects come from roughly 20% of the causes (or effort, in this case).

Very hand-wavy but I think that's also the reason things like expertise exhibit a power law distribution - if as you progress each "unit" of improvement requires 4x the effort of the previous "unit", it makes sense that only about 1/4th of people will make it through. Of course that's very oversimplified but I think you get the gist.

[0] [https://en.wikipedia.org/wiki/Pareto_principle](https://en.wikipedia.org/wiki/Pareto_principle)

</comment><comment><USER25> As it is with many things this is both right and wrong depending on how you look at it.

Consider something like Brazilian Jiu Jitsu. The first 1000 hours will surely advance your game percentage-wise way more than the 1000 hours you accomplish after you've put 10k hours in.

However, there aren't many people with 10k of bjj practice and you're no longer in the rookie world. That 1k may make you just 1% better but that 1% means a lot among the elite.

</comment><comment><USER26> Centering a button with css should not take two days. If you haven't solved the problem already, feel free to contact me and I'll be happy to help.

</comment><comment><USER27> There are diminishing returns in everything because we focus on high impact things first. It's not a bug, it's a feature.

</comment><comment><USER28> I don't feel like this applies to UX. The third or fourth pass in this area can often make a huge difference.

<comment><USER19> More generally: editing. (e.g., How Star Wars was saved in the edit)

</comment></comment><comment><USER29> It might not net you a 7-pack, but it could possibly net you an 8-pack.

</comment><comment><USER30> Oh, how many hours of my life have I wasted trying to center align. Sad and all too true.</comment>


UK phone number transfers between networks are handled through a Yahoo Group - ga-vu https://twitter.com/eilidhmax/status/1184610499478077440 <comment><AUTHOR> This isn't so crazy. Oil traders use Yahoo Messenger [1] [2].

[1] [https://news.ycombinator.com/item?id=11826186](https://news.ycombinator.com/item?id=11826186)

[2] [https://www.bloomberg.com/news/articles/2016-06-01/oil- trade...](https://www.bloomberg.com/news/articles/2016-06-01/oil-traders-may- be-the-only-people-who-want-yahoo-to-thrive)

<comment><USER2> I feel it's helpful in these cases to distinguish between "crazy" and "unusual". It might not be unusual; it's definitely crazy.

</comment></comment><comment><USER3> Not transfers, but rather notifying the other carriers of new number range assignments so they can condition their switches to route them. Not as bad as it sounds.

</comment><comment><USER4> This is a tweet about a tweet...the link should be changed to the original tweet instead of the current link.

</comment><comment><USER5> I like the tone of this paper:

"A review might consider whether it is befitting for the world's sixth largest economy to manage critical national infrastructure via a Yahoo group but we would hope that is obvious."

</comment><comment><USER6> I hope they change before Yahoo Groups deletes all content in December!

[https://news.ycombinator.com/item?id=21269614](https://news.ycombinator.com/item?id=21269614)</comment>


Thanks a lot, Healthcare.gov - <AUTHOR> http://www.theverge.com/us-world/2013/12/3/5163228/healthcare-gov-obamacare-website-shows-how-government-can-do-tech-better <comment><USER2> I work in fed technology, and I agree wholeheartedly that the acquisition process for technology is horrible.</comment>


Nancy Pelosi and Fakebook Dirty Tricks - <AUTHOR> https://www.nytimes.com/2019/05/26/opinion/nancy-pelosi-facebook-video.html <comment><USER2> I'm very uncomfortable with the current trend of trying to get big tech to self police. They'll never get it right because of moving goal posts and moreover I don't want a private company to have that power in shaping social discourse.

If we as a society deem that type of content to be improper and that it should not be allowed on such platforms, then let's make that explicit from a legal perspective and regulate them.

<comment><USER3> >that type of content

Therein lies the problem. The video was slowed down and the audio slightly distorted. I don't see a set of metrics that can capture that "type" of alteration that doesn't also capture tons of content. Unless, of course, you go down the route of saying "it's illegal to post any altered video or image of any politician."

<comment><USER4> What would be the problem of making it illegal to alter video or images of politicians?

<comment><USER5> It plainly violates the 1st amendment.

<comment><USER6> This and also sometimes a video has to be edited to make it watchable: remove the pauses, cut long sentences a bit...

</comment></comment></comment></comment></comment><comment><USER7> I don't fully understand why people think Facebook should be policing content, yet no-one thinks the phone company should delete SMS messages that are spreading misinformation, or the postal service should destroy false mail etc.

It it because Facebook makes it much easier to share something with a wide audience? Is it because "the algorithm" means Facebook has more responsibility than if it were a simple chronological feed?

<comment><USER8> tl;dr: yes, it's "the algorithm"

Facebook (and Youtube et al) have chosen not to be content-agnostic distribution platforms (unlike the postal service and SMS). They perform a variety of editorial functions to curate content and provide recommendations with the objective of maximizing engagement and hence advertising impressions that they can sell. This is popularly known as "the algorithm".

Given that these platforms have chosen to selectively display content for profit, many people believe that they should have some sort of responsibility for the editorial decisions they make.

<comment><USER9> Facebook isn't an editor, though, it's a curator. You use them interchangably but I think there's a crucial difference. An editor modifies to inject their own standards into the work. A curator just includes or disincludes as-is.

<comment><USER4> Facebook does modify content at the level of the feed; first it includes sponsored posts, second it promotes posts to people leading them to promote them to others.

</comment></comment></comment></comment><comment> ar-jan Interesting how they're sidestepping the actually rather disfluent speech from Pelosi that prompted questions. Compare [https://twitter.com/robbystarbuck/status/1131242531503534080](https://twitter.com/robbystarbuck/status/1131242531503534080) with the C-SPAN video: [https://www.c-span.org/video/?460990-1/speaker-pelosi- presid...](https://www.c-span.org/video/?460990-1/speaker-pelosi-president- trump-took-pass-infrastructure-bill) (e.g. from around 3:00): not edited.

<comment> ar-jan My my Hacker News! How dare I link to an actual C-SPAN video, huh? Downvote away! Ignorance is bliss!

<comment><USER10> Please don't break the site guidelines by posting like this.

[https://news.ycombinator.com/newsguidelines.html](https://news.ycombinator.com/newsguidelines.html)

</comment></comment></comment><comment><USER11> A bit ironic coming from Kara, who jumped on social media to condemn the Covington Catholic students before the whole story was out, but at least she admitted her mistake [https://twitter.com/karaswisher/status/1087443815269584897](https://twitter.com/karaswisher/status/1087443815269584897)

<comment><USER12> The tech media is just as much about gotcha stories as the rest of the media. Worse so, because the tech media is absolutely dependent upon its access to the tech industry, which it must always be careful to curb their reporting so as to not lose access.

</comment></comment><comment><USER13> I don't think the idea that companies should host all content except for illegal content is a better approach. Porn is legal, as per the first amendment. Does that mean every social media platform is obligated to allow it? Furthermore it would eliminate the possibility of themed platforms. Things like pixiv and DeviantArt would have to allow content totally unrelated to art.

The whole discussion is moot, at least not without a significant reinterpretation of the fist amendment. Remember, the first amendment also protects against compelled speech. The government cannot mandate people or companies to make speech it does not want to. There's some talk about whether making these social media platforms utilities could allow the government to compel speech, but that seems far fetched at the moment.

<comment><USER14> Actually, it's entirely possible to have different legislation for different sized organizations. The tax bracket for individuals is an example.

I'm more of the opinion that Facebook should be punished as an example. Don't grow so big that your unilateral action could have devastating effects on society. Don't do things with peoples data that remotely rises to the 1984 totalitarian level. See how fast we have publicly owned holdings companies of regional wellsfargo/BoA type banks, facebooks, credit reporting agencies, etc. It's inline with concepts of having different forms of government at the local, regional, and federal levels.

<comment><USER13> > Actually, it's entirely possible to have different legislation for different > sized organizations. The tax bracket for individuals is an example.

Still illegal as per the First Amendment. The government cannot compel speech, regardless of company size.

> I'm more of the opinion that Facebook should be punished as an example. > Don't grow so big that your unilateral action could have devastating effects > on society. Don't do things with peoples data that remotely rises to the > 1984 totalitarian level. See how fast we have publicly owned holdings > companies of regional wellsfargo/BoA type banks, facebooks, credit reporting > agencies, etc. It's inline with concepts of having different forms of > government at the local, regional, and federal levels.

I'm not sure how any of this has to do with content moderation.

<comment><USER14> Facebook has a huge audience. They make it easy to for one entity to target a huge number of people with customized content per person. And yet people have some weird affinity to believe anything they see on it. If you instead had to work with several hundred facebooks across the world to target everybody it becomes more federated. The local facebooks would have more knowledge and incentive and resources to police their content for abuse.

<comment><USER14> I can imagine a few ways this may be legally executed. One is to use the 1800s anti-trust laws to forcibly break up Facebook. Create the smaller entities I described in the process and say "this is the standard for a social media company." Another would be to endow or reinforce citizens private data as some form of personal property. Give them the legal means to sue and demand payment for any storage of their PI. Make the costs of offenses steep. I am definitely not a lawyer though and not as up to date as I should be for this sort of spit balling.

Edit-I think they could also tie a temporal component and per instance cost of storing someone's "PI". That value could then be a basis to tax the corporation- create an incentive to "forget".

Edit2-make a persons likeness and social media posts part of this "PI." This would give Pelosi the legal right to the doctored content.

<comment><USER15> I agree that breaking up these companies is the best option. I can understand the calls for regulation but that is only treating the symptom and will have negative side-effects. The size and position of companies like Facebook leads to a concentration of power which is almost never desirable.

</comment></comment></comment></comment></comment></comment><comment><USER16> What should be the rule about what videos are banned? We don't want to ban parodies I suppose? What if the author of the Pelosi video claims it's a parody?

It would be great if we could allow parodies and jokes as long as a reasonable person can tell that this is indeed a joke. But that won't work since people disagree about what's "reasonable".

I guess we can require that parodies and jokes are tagged as such, so people don't confuse them with real stuff. Is that too overbearing?

Are there any better solutions that have been proposed?

<comment><USER17> It's not as though you can use the magic p word and then what you did is parody. What's parody and what's not is indeed a difficult line to define, but it's not a new problem or a problem that we lack prior art for.

<comment><USER16> > it's not a new problem or a problem that we lack prior art for.

The prior art I'm aware of comes from the copyright, trademark, and defamation laws, but the definitions developed there are so vague that it can take a few months in court (and thousands of dollars) to decide whether something is a parody / satire. Here we need a rule that can applied within hours, at a very low cost. So I'm not sure how we can adapt existing legal definitions to banning videos on the internet.

Could you describe in a bit more detail what exactly you propose?

</comment></comment></comment><comment><USER18> Facebook didn't doctor the video, out of all the content they could be blasted on this is pretty trivial.

This is part of a larger trend in MSM to pry eyeballs away from social media and back to traditional one way media.

<comment><USER19> Facebook knew the video was doctored- it was a mainstream news story for days. They chose not to content ID it, but instead to continue spreading it. That seems deliberate.

<comment><USER20> It was also a mainstream news story for days that the White House spread a doctored video which was sped up to make it look like a CNN reporter attacked a White House intern. Thing is, it was trivial to verify that wasn't at all true: if you actually compare the speed with the original frame by frame it's not sped up anywhere. The artifacts some reporters claimed were from it being sped up are actually frame rate upconversion from the exact, specific 15 FPS GIF its original poster claimed as his source.[1]

On the other hand, there was a super-viral video about this on Twitter that was really obviously doctored. It "proved" that parts had been sped up by overlaying the video on a 7-frame-behind version of the original. Unless you paused the video this desync was only noticable in faster-moving sections, creating the illusion those sections were sped up. Not one news reporter spotted this. People like Captain Disillusionment happily spread it as fact.

If we based our decisions about what's doctored and should be blocked from spreading and what isn't on the media reporting, it'd mean treating truth as lies and lies as truth.

[1] Seriously. You can replicate the incredibly simple frame rate conversion (just blending the frames on either side) in a few lines of Python and get every single one of those artifacts out: [https://www.makomk.com/2018/11/16/recreating-that-white- hous...](https://www.makomk.com/2018/11/16/recreating-that-white-house-video- in-14-lines-of-python/) From what I can tell this is the default setting in Sony Vegas, which is what the guy used.

<comment><USER21> How he made it appear does not matter though. The reporter still did not attack anyone.

</comment></comment></comment></comment><comment><USER22> A partial distributed solution would be for trusted sites to vouch for a hash of the video file, and the browser to be configured to flag or filter untrusted content.

E.g. NYT, the DNC, Pelosi's own site, etc., would flag a hash of a file as valid. Those sites would be aggregated into a web of trust. Users subscribe to nodes of that web, e.g. I trust reporter A, celebrity B, newspaper C, advocacy group D ... and their trust webs out to a depth of X.

Is there anything like this in the works? Kind of a DNS service for propagating networks of trust ratings?

<comment><USER23> Corporate censorship built in to my browser? I'll pass.

<comment><USER24> You'd decide who you trust.

</comment></comment></comment><comment><USER25> So, what's the normative suggestion here? All content on user-generated websites should be moderated for truth and anything edited, editorialized, fictional, or not strictly representing reality should be removed?

Or is the idea that only when there is enough public pressure to take down a particularly popular and deceptive video ... then it should be removed?

It seems sort of ridiculous that we should engage in across-the-board censorship of anything mis-representing reality in any way. OTOH removing things only as they become popular enough to go viral and meet some agreed upon definition of "fake" enough seems like it would establish a permanent, weird shouting match with no clear rules.

Or is the idea that we should ban and penalize Facebook specifically? Because they're Facebook. I don't really get that, but okay. We could do that. I don't think it would solve the user-generated content problem or the fake news problem.

We could not allow any website with posts, images and comments that isn't filtered through a some sort of sacred guardian of truth/editorial board. That sounds like a pretty locked-down version internet.

As some other commenters mentioned, the fact that the President/right-wing seem into this sort of approach and that this video became popular in the first place is a separate, sad issue.

I'd love for the NYTimes to spell out what they're advocating FOR as the solution. If it's just "delete facebook" and read our comments section instead, well-played I guess.

<comment><USER26> Farhad Manjoo asked that on Twitter. The response was "Hate speech comes down." which was remarkably unhelpful.

</comment></comment><comment><USER27> Firstly, if you watch both videos side by side, the effect isn't that great [1]. I thought she was drunk in the original.

Secondly, do you really want to make Facebook the great filter of political truth? Is this a role you want to give to a private company with its own agenda? Of course, for somebody working at The New York Times this kind of power is a dream scenario, where truth is simply whatever they write.

Criticism of the opinion article itself:

> Facebook decided to keep up a video deliberately and

> maliciously doctored to make it appear as if Speaker Nancy

> Pelosi was drunk or perhaps crazy.

Interesting wording, did Facebook decide to keep the video up or did it not decide to take it down? An assumption of malice is a dangerous place to start.

> The social media giant deemed the video a hoax and demoted

> its distribution, but the half-measure clearly didn't

> work.

This is the truth of their opinion, only wiping all traces of problematic material from the internet is an acceptable solution, anything else is a half- measure. What if this video was a piece of art, a political statement, a meme? Is there anyone who we can trust to make the decision without asserting their own bias?

> "We think it's important for people to make their own

> informed choice for what to believe," [..] This is

> ridiculous.

When did a company passing the responsibility of interpretation to the viewers become controversial? Why is it ridiculous to think of content consumers as having the ability to decide what is real and what is not?

> Would a broadcast network air this? Never. Would a

> newspaper publish it? Not without serious repercussions.

> Would a marketing campaign like this ever pass muster?

> False advertising.

Newspapers and serious repercussions? You mean a (comparatively) small monetary fine at most? The biggest consequence of bad journalism I've ever seen was the phone hacking scandal for News of the World, where Rupert Murdoch was basically told to reorganize his assets and make the name "News of the World" disappear [2].

[1] [https://www.youtube.com/watch?v=sDOo5nDJwgA](https://www.youtube.com/watch?v=sDOo5nDJwgA)

[2] [https://en.wikipedia.org/wiki/News_International_phone_hacki...](https://en.wikipedia.org/wiki/News_International_phone_hacking_scandal)

</comment><comment><USER9> >so are New York Times articles, because classy journalism looks good on the platform

Interesting that a journalist thinks that Facebook is optimized for what "looks good" rather than what drives eyeballs. Facebook is just giving the people what they want. (To say nothing of how self-congratulatory that sentence is)

<comment><USER28> There's nothing self-congratulatory about that sentence at all. Facebook's algorithm used to promote a certain kind of clickbait until they changed it in favor of real news (which killed a bunch of media startups that were optimizing for Newsfeed traffic). Facebook has specifically courted media organizations with Instant Articles or video for Facebook Watch.

</comment></comment><comment><USER29> that article is pushing the idea that Social networks should be better at policing speech on their platform.

As said in other comments pushing for more self policing is the worst thing that could happen for democracy and free-speech. The last thing I want is for a small clique of silicon valley tech execs to decide what I should or should not see on my feed.

I see two solutions on this:

\- Censorship is coming from an elected government body

\- No censorship and we let people decide what is news and what is fake news.

But having Zuck and his team manipulate newsfeed to push a political or social agenda is a terrible idea. This article is a shame.

<comment><USER30> How are people supposed to make that decision if they are not armed with the information needed? If they only see the fake version, how will they know to even question it?

Truth matters. News distributers are expected to fact check and should be held accountable when spreading falsehoods.

Removing provably false manipulated media is not itself a manipulation. It is a correction.

<comment><USER23> Agreed, except Facebook is not a news distributor.

<comment><USER31> They are a de-facto distributor, even if it wasn't their intention to be one.

</comment></comment></comment></comment><comment><USER32> Thousands and thousands of videos and pictures are edited and altered to mock famous people and politicians every day, why is this suddenly an issue? Its astounding to me that anyone would support having overseers like Facebook (and their government partners at the Atlantic Council and elsewhere) deciding what is okay for people to post and view.

</comment><comment><USER33> I think part of the problem here is that Facebook doesn't want to be an impartial common carrier, so they have to take responsibility for "content".

Then you have one of the most influential venues (which has taken over much of the use cases of the original open Web and Internet) having to answer to politicians about what speech it should censor.

<comment><USER34> You forget that the most influential venues all have business ties to Facebook for visibility reasons. That is a huge problem, since Facebook might indeed be interested in these venues staying influential and to suppress peoples ability to meet on other platforms. Hard regulation would fortify their dominant position.

I remember some years ago that when papers wrote articles about how they will keep being critical on Facebook, despite their cooperation. That was sad to read.

</comment></comment><comment><USER35> I don't see any problem of posting some humor related content.

</comment><comment><USER36> "No other media could get away with spreading anything like this..."

Meanwhile several major media sites are claiming the video Trump shared was this same doctored video, when it was merely a montage of regular video clips.

We can't even begin to have a conversation about censoring private companies without it immediately being used as a political weapon.

</comment><comment><USER37> I wonder if it would have taken FB that long to demote the video if it had depicted Sandberg or Zuckerberg slinging racial slurs.

<comment><USER38> That is an interesting question and could be empirically determined with an experiment.

<comment><USER39> That's my suggestion.

</comment></comment></comment><comment><USER40> Propaganda is not new, especially to fascist run governments. I for one am very concerned about our republic.

<comment><USER41> Please don't use Hacker News for political or ideological battle. It destroys intellectual curiosity, which the site exists for.

</comment></comment><comment><USER42> Established, "old media" news sources routinely spread misinformation as well either deliberately made up, or by omitting facts that don't fit the narrative of their owners. News outlets haven't been about "news" for several decades now, it's all about, to quote Chomsky, "manufacturing consent". It's just that now anyone with a webcam and a video editor can do the same thing on social media. Some, in fact, get more viewers than "traditional" media, too.

</comment><comment><USER43> America right now is the best show on television. Emmy's for Nancy and Donald.

</comment><comment><USER44> We have to kill facebook. They simply know to much! [irony/joke]

</comment><comment><USER45> The most baffling quote from the article, citing Zuckerberg

>"I'm Jewish, and there's a set of people who deny that the Holocaust happened. I find that deeply offensive," Mr. Zuckerberg said. "But at the end of the day, I don't believe that our platform should take that down because I think there are things that different people get wrong. I don't think that they're intentionally getting it wrong."

Ah yes, the very common good faith nazi. You seriously have to wonder if Mark Zuckerberg would have such nonchalant views about speech and misinformation if he didn't have a tail of private security and a fenced in mansion.

What's the Muslim store owner in Myanmar going to do when the mob comes knocking on the door after some lie about him got the local village riled up? The degree to which these people live in an alternate reality isn't even funny any more. Nothing has consequences for Zuckerberg et al and it has distorted their worldview.

<comment><USER46> I'm assuming people railing on Zuck here don't like Zuck, so it's odd to me they would prefer he become the world's arbiter of permitted speech.

<comment><USER45> I don't prefer he become the arbiter of speech. I'd prefer the government would regulate his business and hold him accountable for the damage that lies and misinformation cause on his platform. Given that he recently called for more regulation, surely he'll agree.

<comment><USER47> > I don't prefer he become the arbiter of speech. I'd prefer the government > would [...] hold him accountable for the damage that lies and misinformation > cause on his platform

I'm understanding you correctly, you believe that Zuckerberg should be held liable for untruthful content hosted on its platform, but you also believe that Zuckerberg should not be allowed to choose what content is hosted on its platform.

How do you harmonize those two fundamentally contradictory viewpoints? Or do you feel that the only "correct" way forward is to excise Facebook in its entirety?

<comment><USER45> I think the platform should be held liable if it causes damage to individuals by spreading false information about them. For example we could start by handing out fines to platforms if they do not remove damaging or false information in timely manner.

I don't think the platform needs to go entirely, I just think it needs to get an incentive, financially for starters, if it fails to adhere to standards set by legislators.

<comment><USER47> In your ideal case, lets say that Facebook identifies some content that it believes is spreading false information about somebody. Should Facebook be _allowed_ to remove it?

If no: Facebook is being fined for not taking an action that it is not allowed to take, which I can't imagine you are advocating for.

If yes: Facebook is now the arbiter of what information gets to be seen (on Facebook), which you didn't want.

A third option, of course, would be to let the government (all governments?) decide when something should be removed from Facebook, but frankly I think this is the worst option of the three.

I suspect that you meant liability in cases when something is "clearly" untrue, so my comments likely come off as pedantry. In cases like this video it's very easy to make that determination. But when it isn't so clear cut, there will _have_ to be judgement calls, and if we're talking actual liability then someone has to be empowered make them. Who gets to make these judgement calls? Either Facebook, the US Government, any government including the ones that you don't like, or maybe some supposedly non-biased third party. None of these options sound at all good to me. I don't know what the answer is, I just want to point out that whatever it is, if it even exists, it isn't as simple as that.

<comment><USER46> We all know that when people talk about coercion of removal of online content, they're talking about content _they_ deem worthy of removal.

You can avoid cognitive dissonance if you assume you have the "right" perspective on how to bucket content into two groups, acceptable and unacceptable, and that the bucketing made by regulators will be identical to yours, since it's clearly the only objectively correct one. Of course, this is so far from reality if such a thing were to be implemented that it's not worth taking seriously.

</comment></comment></comment></comment></comment></comment></comment><comment><USER48> Facebook invades privacy at minimum. It threatens our democracy.

</comment><comment><USER49> Why can't Nancy Pelosi sue facebook for $100 billion for allowing a doctored video about her to spread? They can't use the Napster defense of "we're only a platform."

<comment><USER50> I am confused. Facebook is a person-to-person(s) interaction. If someone wants to show their followers a doctored video, why should Facebook prevent it?

(The other day, someone on Reddit reminded that in Russia it's illegal to repost the Putin gay clown meme [1]. And of course there is the famous Chinese ban of Winnie-the-Pooh images. Is this in any way worse than removing the doctored video of Nancy Pelosi would have been?)

[1] [https://www.washingtonpost.com/news/worldviews/wp/2017/04/05...](https://www.washingtonpost.com/news/worldviews/wp/2017/04/05/its- now-illegal-in-russia-to-share-an-image-of-putin-as-a-gay- clown/?utm_term=.e0c202192e35)

<comment><USER49> There's a difference between satire and downright slander if the viewers can't tell the difference if something is doctored.

<comment><USER9> An average facebook user being able to ascertain the authenticity of something is a very poor barometer for its authenticity or legality.

Average FB user probably couldn't tell you if Panama papers were authentic or not, so should those be banned from dissemination as "fake news"? Plenty of people would like to make those go away as slander, I'm sure.

<comment><USER51> Please. Don't fall into the trap of underestimating others intelligence. Even that typical Facebook user from another state has valid reasons and thier opinion or values are no better than my( or Yours) I'm not trying to argue one bit okay? But how exactly do you know the Panama papers are legitimate? Do you have an inside source or did you hear about this issue the same way I did? I agree with you that it fits perfectly into my own world view and I caution you and myself to not take stuff like that as a golden source of true info. No matter how much I'd like to think it's all true, in this day and age one must be more careful about accepting sources of info as gods honest truth because there are folks out there who spend thier lives,fortunes and passions just to mislead or misinform allegedly informed ppl like me( and you)

</comment></comment></comment></comment></comment><comment><USER52> The correct way to counter disinformation is with information. This does assume a sufficiently aware populace able to process its own confirmation bias (which is actually a learnable skill). Sometimes it takes incrementally more information and that's okay.

Widespread availability of high quality media capture and technologies such as facial manipulation will inevitably lead to a future with many, many unverifiable snippets that go viral. This video is unique in that verification is possible, but the future will likely hold far more unverifiable content than otherwise. It is more positive to expect that humans will gain the ability to balance disinformation in the face of further information than to expect that benign dictators will censor perfect knowledge into cognisance.</comment>


Cloudy with High Wins: Ruby on Rails with Nitrous.io - <AUTHOR> http://railsapps.github.io/rubyonrails-nitrous-io.html

<comment><USER2> Has anyone used this in a paired environment? Would love to hear feedback on that. I'd also like to know if anyone has tried "importing" an existing rails app into nitrous, and how that has worked.

</comment><comment><USER3> This is pretty good. But does the free account last forever? Last time i was lured into signing up upcloud.com and was forced to pay a month later or my entire account gets wiped out.

</comment><comment><USER4> Thanks @DanielKehoe, this is very comprehensive. It's great to see how to do it, but how do you find using it? What's the speed like?

<comment><AUTHOR> That's the thing, I thought it would be unusable because of network latency. But I'm actually using it and it seems faster than my native environment on a Macbook Air. Fast Comcast broadband in San Francisco's Outer Sunset District but still, how can it be faster than my local shell?

</comment></comment><comment><USER5> As usual, a very complete writeup by @DanielKehoe. It's interesting to see alternatives to Heroku starting to popup.

<comment><AUTHOR> Uh, not exactly Heroku. You can launch an app and see it in your browser but just while you are doing development. You'll still need to deploy your application to Heroku or elsewhere for hosting. Nitrous.io is more like Cloud9, someplace to write code. Or maybe you are thinking of the old Heroku Garden which had a browser-based coding environment.

</comment></comment><comment><USER6> I'm definitely going to try this out for pair programming. looks very interesting.

<comment><AUTHOR> Yea, let me know how it works for you. It's easy to pair in the text editor. To share the console you'd need tmux or screensharing.</comment></comment>


'Money doesn't kill people, but it changes the fabric of daily life' - <AUTHOR> http://www.theguardian.com/books/2016/jan/02/luc-sante-books-interview <comment><USER2> > How can you be promoting the life of the poor in the 19th century when so > many of them didn't eat every day? Well yeah, it's bad, but is it really any > worse than the situation today when everybody's fed but you have an > incredible percentage of New Yorkers who live in the shelter system – > including people who have regular jobs?

For somebody who's an expert on this, I'm shocked at such a reduction. Infant mortality rates, for example, are more important to me than awesome jazz clubs.

<comment><USER3> > _For somebody who 's an expert on this, I'm shocked at such a reduction. > Infant mortality rates, for example, are more important to me than awesome > jazz clubs._

"Shocked" at what? It's not like he said today's people should live in 19th century conditions to create better jazz.

If "infant mortality" rates shock you, then there are much better targets than a historian talking about jazz clubs in old times. Like the fact that the US, for all its wealth, resources and technology, lags behinds far too many modern countries in infant mortality reduction, and what should be done to change that.

If anything when he says "is it really any worse than the situation today when everybody's fed but you have an incredible percentage of New Yorkers who live in the shelter system" he's really addressing this issue, that there's far too many things to fix even now.

<comment><USER4> I can see where the author is coming from and it is all well expressed, but I can't see how this is anything but "a romanticised vision"; contrary to what he claims.

If I had to choose between going hungry and living in a shelter but with food to eat, I'd most certainly choose the latter. If you aren't in that exact situation though, it would seem bad enough.

Sante also laments how security leads to a decline of liberal lifestyle. Well that's true and it might seem like a (terrible) loss, but only for men. Women are able to experience the world better today, thanks to somewhat better security. Crimes against women have gone down significantly in the last 40 years. Comparing rape incidents per 1000 people in the US, it went down from 2.5 to 0.5 between 1970 and 2000.

So, the author is only seeing one side. It could well be that the situation has improved overall.

</comment></comment></comment><comment><USER5> money can't kill people, but lack of do kills

<comment><USER6> > money can't kill people, but lack of do kills

do?</comment></comment>


Writing an Interpreter in Go - <AUTHOR> https://interpreterbook.com/ <comment><USER2> Is the book really beginner friendly?

Do I need to have any pre knowledge about Lexers and Parsers and the Go AST package [https://golang.org/pkg/go/ast/](https://golang.org/pkg/go/ast/) to understand the book?

<comment><AUTHOR> No, not at all. That's precisely what the book is about: what is a lexer? how do I build one? what is a parser? what is a recursive descent parser?

I tried to make the code as easy to understand as possible, always thinking: "would someone who's never written an interpreter understand this?"

<comment><USER2> Great thats exaclty what I always wanted to know about. I'm sure I'll buy the book! I always wanted to know howto implement an own little scripting language which could be used inside Go projects.

<comment><AUTHOR> Well, I couldn't describe a better use case, even if I tried. Check out the free sample, which shows how to build a lexer/scanner/tokenizer.

</comment></comment></comment></comment><comment><AUTHOR> Author of the book here. If you have any questions: feel free to ask!</comment>