/tech/ - Technology★

Why even use C if you're using JSON? Why are people such niggers?

>>876506

It's easier for humans and machines to parse than XML.

>C is bad because CURRENT_YEAR!

>>876515

No bloated C is bad because bloated code in any language is bad.

>>876534

People would be more likely to take you seriously if you actually posted your own opinion instead of copy pasting some retarded pajeets opinion in every thread.

>>876549

>LOC is an indicator of bloat

o I am laffin

C is more verbose than other languages, that doesn't mean the implementation is bloated or bad, it's just meticulous.

>but the source is bloated

Define bloat, do you simply mean more lines or do you mean the typical meaning of the word, full of useless features?

>>876504 (OP)

Is JSON insane bloat? I never used it but I just thought it was just some kind of map?

>>876588

>Define bloat

I mean loads of useless(already implemented elsewhere on targeted systems) features. From OP:

>* implements an entire lex/yacc BISON parser, compiler and bytecode interpreter (in C)

I can use the classic OpenSSL example of re-implementing malloc as another example of bloat. Of course there were(still are?) many other issues with this but thats besides the point.

>>876588

>C is more verbose than other languages, that doesn't mean the implementation is bloated or bad, it's just meticulous.

C is verbose, bloated, and bad.

>Define bloat, do you simply mean more lines or do you mean the typical meaning of the word, full of useless features?

How about more lines and no useful features?

    The solution, as any well-seasoned unix veteran will
    tell you, is to use "tar" if you want to copy a
    hierarchy.  No kidding.  Simple and elegant, right?

For me, using "tar" to copy directory hierarchies is the
archetype of what is fundamentally wrong with Unix, the
fundamental wrongness being that in Unix the user is forced
always to say *how it is* s/he wants something done, rather
than *what it is* s/he wants to do.

The notion of using the tape archiver to move a directory
hierarchy is not inconsistent with the notion of using C to
write robust, maintainable programs.  Think about it.

>>876504 (OP)

>* implements an entire lex/yacc BISON parser, compiler and bytecode interpreter (in C)

It's a language. Do you expect it to not implement a lexer and parser? If not, would it really be better to roll their own?

>>876644

check your reading comprehension

>>876655

Are you saying that it reimplements bison itself? Where?

>>876512

Use C for the hard stuff, and a proper parser written in something else for everything else.

>>876594

JSON is easy to parse.

>>876655

>>876656

Okay, given that there's a big FSF copyright header at the top of parser.c, I think it's safe to say that they used flex and bison in the standard way.

Which means that parser.c and lexer.c are generated from the .y and .l files.

So I'm asking you again: would it have been better for them to write their own parser and lexer, instead of handing the task over to an old respectable set of code generators? Did you count the generated code as part of the 21k lines?

>>876642

>C is bloated

Probably the smallest standard library of all the useable languages.

>muh tar copying

MANPAGER="sed -n '4p'" man pax

pax --- read and write file archives and copy directory hierarchies

Okay, I think I figured out where you went wrong. You're comparing jq to the 60 lines of node.js used by jq.node.

Let's say I've got a server running a pretty old system that doesn't package a useful JSON processor. I could use jq, or I could use jq.node.

If I use jq, I make sure I have some very basic dependencies installed, I put the code on my server, and I compile it. It's very easy. I know that because I've done it, on my server.

If I use jq.node, I have to install all of node.js and the node package manager before I can even get started. Now, I don't know exactly how complicated building node.js is, but I know it's a lot more complicated than building jq. Look at this shit:

https://github.com/nodejs/node/blob/master/BUILDING.md

Look at that. Building node.js actually requires Python. What the fuck?

jq.node isn't just sixty lines of javascript, it's an entire bloated javascript implementation. You're writing node.js and pretending you're using a language implemented in 60 lines. It's enormous, bloated, and a hundred times as slow as jq according to the benchmarks provided by jq.node itself.

jq.node has a parser, and it's much larger than jq's, it's just in a different repository.

>>876506

isnt java like flash? im surprised people use this shit. hell, even hooktube makes me disable noscript because of json bullshit.

it gets tiring trying to defend yourself against botnet. And that's just from a browser perspective.

>>876665

This might be bait but if it isn't bait then please stop talking about this subject until you know more about it

>contains a 70k line javascript file <https://github.com/dflemstr/rq/blob/master/src/js/lodash.js>

jq.node uses that one too, it just doesn't put it directly in the repository because it expects you to pull it in with npm.

>>876666

quads of truth tbh

if /tech/ followed this advice, it would be a better board

>>876504 (OP)

why should anyone care about this project anyway? never heard of this shit before.

do a proper post with all the info, or fuck off this board.

Oh my god who gives a fucking shit about how many lines of code it has I just want the one that works the fastest and the most reliably.

>>876686

>fuck off this board

No you, /g/ owns this board now.

>>876606

Just because an implementation of something already exists, doesn't mean it's the best implementation, especially in all contexts. I unironically trust anything made by the OpenSSL team more than I would the standard.

Ironically sometimes people reimpliment things without the extra features they need in order to be more performant or portable.

>>876686

kill yourself

>>876642

>Use "tar" if you want to copy a hierarchy

$ ls a
directory-a directory-b
$ cp -r a b
$ ls b
directory-a directory-b

>>876642

Well, maybe you were talking about backups.

Your argument is still retarded because tar was literally made for tarrin' shit up for tape backups.

It's literally the purpose behind the tool that you are griping about using it for.

>>876729

>tar was literally made for tarrin' shit up for tape backups

Exactly this. The OS was not meant for desktop use and it's really only like 1% who persist anyway. Unix was meant for servers or phones or any place where the permanence of data was not a thing.

This is one of the reasons Windows GNU thing is so fucking funny.

>>876728

This will give different results depending on whether b exists or not.

Use `cp -r a/. b/` to copy reliably.

>>876746

>This will give different results depending on whether b exists or not.

how is this shit so pervasive? literally all of UNIX userspace is full of bizarre special cases and trapdoors. Fuck it. redesigning everything from scratch is the only solution.

>>876686

It's a JSON processing tool.

Here's a dumb example:

curl https://8ch.net/tech/res/876504.json | jq -r '.posts[] | .name + " " + (.time | todate) + " No." + (.no | tostring) + "\n" + .com + "\n"'

>>876764

>bizarre special cases and trapdoors

All the behaviour is consistent. Read the man pages, retard.

>Fuck it. redesigning everything from scratch is the only solution.

Good luck with that, maybe you'll come up with OpenVMS and hate it as much as VMS users do

>>876506

>Why even use C if you're parsing a file?

Check what you said.

>>876764

They tried with Plan9.

>>876594

json has a better signal to noise ratio than xml...

>>876823

And plain text has a signal to noise ratio of 1 while being garbage for structured data, and comparing things to XML is setting the bar unreasonably low. What's your point?

>>876823

>signal to noise ratio xml

what is this? did a quick web search and nothing relevant came up.

>>876826

I always hear people shit on XML but I don't see why, and people praise JSON seemingly because it's easy to parse and "human readable". XML seems like it'd be much faster to parse for a machine, I don't see why human readability should even be a factor for structured data, the whole point is to compose human output from the input if you want human readability.

What's so bad about XML, what's so good about JSON, and what are some noteworthy (good and bad) alternatives?

>>876832

JSON is great because it is based on javascript :-DDDDD

>>876832

XML is bad because it's tedious to write and too complex for non-hardcore users to fully understand. There's some sort of attack that uses tricky standard-conforming tags to exponentially grow in memory, so even parsing it can be problematic. And after all that it's still annoying for humans to deal with.

JSON is just barely human readable enough to get used for human-authored configuration files, but it's finicky enough to make writing it annoying - no trailing commas, no comments. If it were a little less readable it would be abused a lot less. It's kind of bad.

XML is much more powerful than JSON. There are tasks for which XML is only kind of sucky but for which JSON would be a disaster.

YAML is good for a lot of the things people should stop using JSON for. It's actually useful for human beings. It's not worth using for anything that doesn't involve humans, though.

>>876776

looks like a useless crap, these things are easier to do in a normal programming language like Python.

>>876841

I use Python for complicated things, but jq is great for one-liners. If I want to explore a document's structure or do quick and dirty data extraction it's much more convenient.

I'd rather write jq .foo[].bar than python3 -c 'import json, sys; for x in json.load(sys.stdin)["foo"]: print(x["bar"])'.

>>876735

>Exactly this. The OS was not meant for desktop use and it's really only like 1% who persist anyway. Unix was meant for servers or phones or any place where the permanence of data was not a thing.

Permanence of data was definitely a thing, but the UNIX filesystem got corrupted all the time because it sucked. Backups on real OSes were made to protect against physical hardware damage. Backups on UNIX were made because the filesystem lacked robustness and because there was no way to undelete a file or restore a previous version.

>>876764

>how is this shit so pervasive? literally all of UNIX userspace is full of bizarre special cases and trapdoors.

It's pervasive because they don't care and because of their attitude of everything being the user's fault.

    Stanford had a system called "labrea".  It was (is?) a
vax 750 with 10 fuji eagles (4.5 Gbytes, which was a lot
when it was first around...)

    Tape handling has always been a real weak point of unix.
Any real operating system has much better backup/restore
capabilities, and a lot of these are 10s of years old...

    This poor user tried to use Unix's poor excuse for
DEFSYSTEM.  He is immediately sucked into the Unix "group of
uncooperative tools" philosophy, with a dash of the usual
unix braindead mailer lossage for old times' sake.

    Of course, used to the usual unix weenie response of
"no, the tool's not broken, it was user error" the poor user
sadly (and incorrectly) concluded that it was human error,
not unix braindamage, which led to his travails.

Let me supply you with an example.  Just today I had the
following dialog with one well known computer manufacturer's
version of Unix:

  > rm temp
  rm: temp directory

  > rmdir temp/
  rmdir: temp/: Is a directory

(Of course if I type the name of the directory -without- the
trailing "/", rmdir works just fine.)  Now just what the
heck braindamage do you suppose results in this idiotic
error message?  "OF COURSE IT'S A DIRECTORY", I shout at my
terminal, "WHY THE HECK DO YOU THINK I'M USING RMDIR?"

Now that's the kind of teeth-grinding experience this
mailing list is all about.

   If you want to remember the actual last time you edited
   those files, then keep your own damn database of dates
   and times, and stop bothering us Unix Wizards.

I thought this is what RCS is for.

I'm TA'ing an OS course this semester.  The last lecture was
an intro to Unix since all other operating systems were only
imperfect and premature attempts to create Unix anyway.
Some lecture highlights...

An aside during a discussion of uid's and many a unix
weenie's obsession with them: "A lot of people in the Unix
world are weird."

When asked if Ritchie et al regretted some other
inconsistency in Unix metaphysics, "These guys probably
don't care."

Have another twinkie.

>>876906

>"rmdir temp/ fails because of the trailing /"

>$ mkdir a

>$ rmdir a/

>No problems

Works on my machine™

>>876919

Watch this:

$ mkdir a
$ ln -s a b
$ rmdir b/
rmdir: failed to remove 'b/': Not a directory
$ rm b/
rm: cannot remove 'b/': Is a directory

Oh, and in case you wondered:

$ rm -r b/
rm: cannot remove 'b/': Not a directory

>>876923

>>876927

I have never in my entire life used rm -r without -f.

>>876923

That's because b isn't a directory, it's a symlink.

Shiggy diggy.

>>876721

>I unironically trust anything made by the OpenSSL team more than I would the standard.

Have you ever actually read the openssl code? Its a clusterfuck of terrible programming. Bob Beck gave a talk[1] on all the cancer they removed in the first month after forking it. I suggest you give it a watch. Not that I think that libressl is the solution to the openssl problem but if you need openssl compatibility its much better then using the actual thing.

[1]https://www.youtube.com/watch?v=oM6S7FEUfkU

>>876923

>>876927

Because `b/` isn't a directory. It's a symlink.

`rm b` works absolutely fine.

>>876923

>>876927

literally this >>876973

Also unlink.

inb4

>hurr whats the difference between a link and file

>>876815

>makes retarded "human readable" data format

>parses it in C to get "speed"

>>877036

>all files are "human readable"

>implies parsing files doesn't include byte econdings

can you read?

>>876973

I know why it happens, I set it up myself. But it's inexcusable for a single tool to both complain that "b/" is a directory and that it's not.

>>877182

My solution to you is to stop using retarded GNU coreutils. Besides emacs pretty much all gnu software is shit. Following your example

sbase$ rm b/
rm: unlink b/: Not a directory
OpenBSD$ rm b/

Sbase tells you what you are supposed to do and OpenBSD just does it. Both are more acceptable then retarded gnuisms.

>>877045

>econdings