Comment by pdkl95 | Hacker News Reader

Comment by pdkl95 | Hacker News Reader

Parent Full thread

> shows how poor most non-web debugging and logging

Nonsense - web programming is inherently tied to the browser, which severely limits debugging and output options.

> The ability to mix and match data types and presentation format is extremely useful.

That's a common feature of dynamic type languages.

> Almost everywhere else we just have printf.

Most languages have logging libraries, and many have them built into the stdlib or runtime. Popular languages usually have many logging libraries to choose from.

> that’s printf going to stdout

Of course - printf(3) by definition "shall place output on the standard output stream stdout"[1]. If you want stderr or any other output stream, use fprintf(3).

    #include <stdio.h>
    int main() {
        fprintf(stderr, "Error: %s\n", "LP0 on fire");
        return 0;
    }

Other languages usually handle that for you as part of the logging library.

> there isn’t a universally deployed format

Sure there is: "text"[2].

> to even allow it to travel easily over the network

Copying files to a remote host is easy with scp. There are numerous ways to send data over a network. Web software is often more work as you have to move your debugging data/logs out of the browser first or use a specialized tool that does that for you. Sending program output realtime to a remote host only requires appending "| ssh ${host} \"${remote_cmd}\"" to your command.

> advanced viewers

That's great if you have specific needs and a viewer for your complex data structures, but the only universal solution is text. Fortunately, there are many tools available to handle structured data as text.

> I think part of the problem is that programmers rarely want to get into these supportive details; they just printf and get on with it.

I think you might want to explore the work programmers have done in other languages.

[1] http://pubs.opengroup.org/onlinepubs/9699919799/functions/pr...

[2] http://www.catb.org/esr/writings/taoup/html/ch05s01.html

> Of course - printf(3) by definition "shall place output on the standard output stream stdout"[1]. If you want stderr or any other output stream, use fprintf(3).

I reject your C-centric world for one of my own making. ;)

  # perldoc -f printf | head -n3
       printf FILEHANDLE FORMAT, LIST
       printf FILEHANDLE
       printf FORMAT, LIST
  # perl -e 'printf STDERR "%0.2f\n", 2;' >/dev/null
  2.00

he was quite specific in saying printf(3), which is defined by POSIX

Yes, the reply was quite specific in rewriting printf to include the man page section, but the original comment did not.

You're totally missing my point(s). Of course web programming is tied to the browser, but why does that mean debugging via logs has to be tied to whatever particular console is attached to where a program is running? Why can't I have a console.table() equivalent in Python, and Ruby, and C, and Go, and Java that all can render via a common protocol to any viewer that can handle it?

By printf I didn't _literally_ mean printf -- I meant any logging type equivalent whether that IS printf or a built-in logging system. The point is there's no inter-op between them with any rich detail, which prohibits universal log viewers.

When I say travel over the network, I don't mean scp. I mean allow my iOS/Raspberry Pi/local Erlang server device to stream in real-time it's logs to any viewer that I want, whether that's on the same device or somewhere else in the world. That's the kind of portability required when you can't guarantee that complex display can be part of the same system that generated it -- that's a unique quality of web browsers. IT'S ABOUT THE PROTOCOL, NOT THE MECHANISM.

Text is great, and most logs will be in text. But I also sometimes want to inspect data, or expand JSON, or view an image, etc etc. But let's even stick with text -- a good viewer would let me set up filters on a host of structured qualities -- filenames, lines, log levels, keywords, etc. It would output in a way that allows me to easily view such info in a UI that supports infinite scroll back, easy copy/paste, elegantly formats so different log instances are clearly separate from each other, adds color to enhance readability, allows me to hide/collapse sections or duplicate entries, provides columns for the structured logging fields like timestamps, allow interactive sorting on these columns like Excel, etc etc all without losing my data.

Apple's Console.app is an elementary example of what I'm suggesting I'd like to see. Except I don't want it tied to the syslogs of an Apple device. I want every language/platform to be able to output to it in real-time. And for it's capabilities to be as rich or richer than what we have in the browser. We already have universal text editors like VIM/Emacs -- why can't we have universal log viewers?

"printf" will always have it's place, because when things are hosed, there's a good chance you can't push stuff to network, but things have to be really hosed to stop you pushing some chars to a UART.

> I mean allow my iOS/Raspberry Pi/local Erlang server device to stream in real-time it's logs to any viewer that I want, whether that's on the same device or somewhere else in the world.

e.g. syslog (RFC5424)? -e- You can even add some extra fields of your choosing if you so desire: https://tools.ietf.org/html/rfc5424#section-6.3

> But let's even stick with text -- a good viewer would let me set up filters on a host of structured qualities -- filenames, lines, log levels, keywords, etc. It would output in a way that allows me to easily view such info in a UI that supports infinite scroll back, easy copy/paste, elegantly formats so different log instances are clearly separate from each other, adds color to enhance readability, allows me to hide/collapse sections or duplicate entries, provides columns for the structured logging fields like timestamps, allow interactive sorting on these columns like Excel, etc etc all without losing my data.

e.g. ELK, Graylog etc?

lnav + mitmdump!

lnav looks really neat. Thanks!

> Text is great, and most logs will be in text. But I also sometimes want to inspect data, or expand JSON, or view an image, etc etc. But let's even stick with text -- a good viewer would let me set up filters on a host of structured qualities -- filenames, lines, log levels, keywords, etc.

So, it sounds like you want a debugging library you can include in the language you are using to output structured debug lines and a client side that goes along with it to represent the usefully (or just use text+JSON and a JSON aware client), and to just stick it on top of syslog. I think that pretty much covers what you're asking for.

>So, it sounds like you want a debugging library you can include in the language you are using to output structured debug lines and a client side that goes along with it to represent the usefully (or just use text+JSON and a JSON aware client), and to just stick it on top of syslog. I think that pretty much covers what you're asking for

Except the most important thing: that ability to be included as standard, readily available, and well supported in languages.

Well, that's why I specified it as a library. A C compatible Lin is likely easiest for most languages to trivially support through an FFI, and it all it's doing is outputting structured text based on the input, that's trivial to hook up. It's not like it can be too language specific because if it's supposed to work in a bunch of languages, it has to be generic enough to handle them.

Although in the end you probably aren't getting much out of it, as a dynamic language is fairly easy to just pump stuff through a JSON converter, and static/strongly typed ones probably require enough boilerplate that the added benefit is slight.

"Why can't I have a console.table() equivalent in Python"

I get a console.table() equivalent in Python by using Jupyter Notebook, which is a web-based REPL shell, and pandas, which is a library for working with tabular data. Pandas displays HTML tables when used with Jupyter.

This response managed to say very little and just give excuses for the current state of things.

>Nonsense - web programming is inherently tied to the browser, which severely limits debugging and output options.

Web programming includes cli and server side tools (Node for one, JS testing tools, etc), has several first class logging SaaS and locally installed options, and even has stuff like the developer tools protocol, which allows one to debug Chrome running code in VS Code for example...

>That's a common feature of dynamic type languages.

That's merely an "ability", it's by no means a "common feature" in dynamic languages to have different output options in the example of e.g. console.table() (which itself is limited anyway).

>Copying files to a remote host is easy with scp.

That manual busywork is not what the parent asks for.

>That's great if you have specific needs and a viewer for your complex data structures, but the only universal solution is text.

You've just restated the problem -- only with a positive spin.

Reply on news.ycombinator.com