291–300 of 306 posts
Earlier quoted context omitted.
You are, of course, correct. I appologize, and will go to greater lengths to remain civil in threads in the future.
We very much appreciate it. Thank you.
Earlier quoted context omitted.
I got the terminology right. The term “value” means what I mean by it, not what qwerty means by it. Check TAPL, pages 34 and 57.
I'm talking about "expectation".
(0) Reactions can be quantified - assigned numerical values, roughly corresponding to our intuition of a “positive”, “neutral” or “negative” reaction.
(1) The possible reactions can be meaningfully averaged, and the result can be interpreted as a reaction value as well.
So by “expectation”, I meant “expected value”, in the usual sense. If your objection is that “expectation” can't be used as this, I have evidence that suggests otherwise:
(0) http://ocw.mit.edu/courses/mathematics/18-05-introduction-to...
Earlier quoted context omitted.
But there's a difference between changing it once when you serialize/deserialize it, and changing it every time you try to access the key.
Writing the code with the assumption that a key will change is on the same level with premature optimization, in my opinion. It might be reasonable to make the assumption for some keys. In these cases a function taking the data and key as arguments and returning the value is sufficient and appropriate. Frankly, if the code base is so littered with references to that specific data and key combination it might actually…
Considering how easy it is, and how often I've had keys change on me, I have to strongly disagree.
"Frankly, if the code base is so littered with references to that specific data and key combination it might actually indicate a poor design."
That's kinda the point of the article.
Earlier quoted context omitted.
I'm talking about "expectation".
Oh, sorry. I was implicitly making the following assumptions: (0) Reactions can be quantified - assigned numerical values, roughly corresponding to our intuition of a “positive”, “neutral” or “negative” reaction. (1) The possible reactions can be meaningfully averaged, and the result can be interpreted as a reaction value as well. So by “expectation”, I meant “expected value”, in the usual sense. If your objection is…
Earlier quoted context omitted.
When using parsers like e.g. Jackson or Gson for Java, this process is completely transparent and does not require any active thought from the developer - well, maybe if there's very specific formats that don't map 1:1 with the class that should be instantiated or generated from the json object. It's a bit more tricky in JS, both client-side and node. You can't work with the json string there, but after that you work…
Automated serialization is the devil. Gson and Jackson require you to write EJB-style objects to get automatic serialization - default constructors, with getters and setters for each field - to achieve automatic serialization. The problem with this approach is that you've completely abdicated the power of the type system to ensure that your objects are valid. What happens if a field is missing from the JSON? Well, th…
Not the case. I successfully used Jackson combined with Lombok to achieve some really nice DRY class definitions that Just Worked with Jackson. It took a little figuring out and a couple bugfixes to Jackson but it worked. That said, part of the hassle was that I insisted on being able to do this with @Wither so we could have the objects be immutable too.
Then you can write stuff roughly like
@Value public final class Thing { String name; int age; boolean boiling; }
Although IIRC I had to use some other random set of lombok annotations instead of @Value to get it to work right with Jackson (this was a while ago, don't recall details)
> The problem with this approach is that you've completely abdicated the power of the type system to ensure that your objects are valid.
Yeah, this was a big problem with my approach. The other choice would have been to use @Builders instead of @Withers. Then you get a little more boilerplate (having to type .build()), but you can guarantee the built objects meet consistency requirements. (In retrospect, I doubt I chose the right tradeoff there)
Earlier quoted context omitted.
> I just expected (in the statistical sense of the term “expectation”) If you're going to argue here about programming languages terminology it behooves you get terminology from other fields correct.
I got the terminology right. The term “value” means what I mean by it, not what qwerty means by it. Check TAPL, pages 34 and 57.
Officially, yes, cat is right, but in common usage, value leans more towards my definition.
Earlier quoted context omitted.
Oh, sorry. I was implicitly making the following assumptions: (0) Reactions can be quantified - assigned numerical values, roughly corresponding to our intuition of a “positive”, “neutral” or “negative” reaction. (1) The possible reactions can be meaningfully averaged, and the result can be interpreted as a reaction value as well. So by “expectation”, I meant “expected value”, in the usual sense. If your objection is…
It's rather non-standard to say "I expected" in this sense but since you've gone to the trouble to define your terminology and back up your claim, fair enough!
At this point everyone should be using an evolvable (thrift, protocol buffers, avro, etc) schema format when they are storing or transmitting their data if they want to run an always on service - there is no downtime for migrations in the real world. Trying to do this ad-hoc with JSON is a lost cause and will eventually lead you to failure at runtime or worse, data loss situations.
JSON isn't un-evolvable. In fact, thrift can serialize to JSON. What makes thrift evolvable in practice is that we don't remove fields and don't add mandatory fields. The same discipline can be applied to JSON definitions. Well thrift also tags all fields with integers, so a consumer with an older schema can parse a record with a newer schema, skipping the new fields. Of course JSON trivially has this property. Maybe…
Earlier quoted context omitted.
I got the terminology right. The term “value” means what I mean by it, not what qwerty means by it. Check TAPL, pages 34 and 57.
Both definitions of "value" are accurate. That's what makes this whole thing so confusing. Officially, yes, cat is right, but in common usage, value leans more towards my definition.
OTOH, I can agree with the imperative programmer's intuition of a variable as a location where you can store a value (rather than a symbol that can be consistently substituted with a value). It's not a mathematical variable, but it's a sufficiently established meaning to be taken into consideration in serious discussion. (Furthermore, the connection between imperative variables and mathematical variables can be restored using Hoare logic.)
Earlier quoted context omitted.
I got the terminology right. The term “value” means what I mean by it, not what qwerty means by it. Check TAPL, pages 34 and 57.
Both definitions of "value" are accurate. That's what makes this whole thing so confusing. Officially, yes, cat is right, but in common usage, value leans more towards my definition.