tef posted:

you can roll your own in 0mq, sure, but really, there are other options out there. HTTP makes a decent request-response protocol, and there is a poo poo ton of library support for it. if you use a good one, you can take advantage of http caches and load balancers.

also I have no idea how 0mq makes things 'scalable'. scaling an application is m often an operations problem, more than an implementation problem.

tef posted:

in small potatoes land, http is fine.

in big things, http has caches and load balancers.

in real time stuff, 0mq is probably doing stuff behind your back that you don't want.

Shaggar posted:

yes people don't understand how to do safe concurrency and they make a mess of it. really the solution is to avoid it whenever possible.

PleasingFungus posted:

this legit hurts my head

I think I understand it after three reads, but it's still really a thing

wait, no, maybe I don't understand it after all

gently caress

JewKiller 3000 posted:

jesus christ i read farther in that thread, and there's someone about to graduate with a 4.0 in cs who doesn't know what a hashmap is, with the excuse "i only know java"

shrughes posted:

I'm convinced that people who poo poo on C++ are all dumb. This isn't because C++ is great, it's just that every time you see somebody complain about C++, it turns out that they only give specious arguments and vapid blather. What's the probability that we'll ever come across an existential C++ rant that isn't written by a dumb person? I'd say 0.3% right now.

What really happens when people make complaints like this? It's people seeing others doing stuff they don't understand, because they're too new or too stupid, and assume somebody else is the problem. Look at the complaint about rvalue references. This person can't see rvalue references improving people's lives and the robustness of programs, because he's ignorant and doesn't know what he's talking about.

Another recent rant about C++ was done by the 0mq guy. Anybody who's looked at the 0mq source code can tell you that it's complete poo poo, and it's not C++'s fault.

Here is the real fact about C++: It's not about C++. It's about making a language suitable for efficiently writing non-garbage collected efficient programs. If and when C++ sees a suitable replacement, it'll be a language that is at least as complicated. It might lose a few superficial complications that C++ has, thanks to its C legacy, but the superficial complications are not the real problem that C++ has or that C++ programmers have. It's the problem of writing code without garbage collection itself, and C++ only helps.

Stringent posted:

MononcQc posted:

- optionally encrypt data for safe transmission over unsecured networks
- be supported by as many platforms and languages as possible (who gives a poo poo about a thing nobody can use)
- be conceptually simple enough, for the same reasons as above

MononcQc posted:

In this case, if you're a customer, you then have the choice to use many different protocols based on the log stream you have and how sensitive it is, and choose yourself the balance you want in all of the requirements listed above.

MononcQc posted:

So what you do is you create an API where you document easy simple defaults, let people do that. Hide some use cases behind a simple command line that they can learn in under 10 seconds. Then if they want more, you can sell that service, or expose different data formats that may be more appropriate for what you want to do. Or anyway, that's one way to do it.

MononcQc posted:

It's not because you have a toilet that a toddler can use that you require plumbing that a toddler can put together.

MononcQc posted:

man at this point I honestly don't know what would be simpler than doing '$ heroku addon:add <thing>' where you have <thing> be 'loggly' or 'papertrail' and you get some basic logging done for free, outside of making that decision for them in the first place. The basic logging offered stores ~2000 lines ('heroku logs') and can stream them, and anything else is documented -- the page I linked to is literally what the 'features' page links to under 'Heroku Logs'. And you have to visit that page to at least know how to write logs (write to stdout) and whatnot.

So what would be a better solution to you, outside the the google-like approach of "we're just gonna store all your poo poo for free forever" ? What's the behaviour you want to see there?

Otto Skorzeny posted:

the actual problem with the strategy pattern is that it is trivial and not worth discussing (all gof patterns are either trivial inclusive-or dumb, and most of them are papering over flaws of early c++ and java rather than actual language-agnostic designs)

suffix posted:

well guess what, those xml interfaces are going to be just as broken and ad-hoc as any json parser.

like one of them ignores any encoding you specify and just reads everything as ISO-8859-15,
and one of them runs a bunch of perl regexes on the input and fails if you have whitespace in a self-closing tag,
and one of them just uses print statements and doesn't escape any output data.

Notorious b.s.d. posted:

xml solves a lot of hard problems, and if you don't understand why xml is good, it means you haven't figured out the problems yet

http://www.ietf.org/rfc/rfc4627.txt?number=4627 posted:

A JSON text can be safely passed into JavaScript's eval() function
(which compiles and executes a string) if all the characters not
enclosed in strings are in the set of characters that form JSON
tokens. This can be quickly determined in JavaScript with two
regular expressions and calls to the test and replace methods.

var my_JSON_object = !(/[^,:{}\[\]0-9.\-+Eaeflnr-u \n\r\t]/.test(
text.replace(/"(\\.|[^"\\])*"/g, ''))) &&
eval('(' + text + ')');

tef posted:

read the bit about unicode


and of course we all know that json isn't a subset of javascript, right?

Bloody posted:

this is funny because im using gigabyte+ protobufs in a project

JewKiller 3000 posted:

1) yes but only in rare cases, and before you use it, think hard about whether you really need to
2) absolutely not

Condiv posted:

i do know the difference between the two, i just think final should make not only the reference immutable, but the members of the object it refers to.

as for why, sometimes it's nice to have some guarantees that this function, or this piece of code, or whatever, can't gently caress around with the state of this object.

Bloody posted:

wait what's wrong with mutability? why should i scrap an entire object and any children objects any time anything changes?