| General > General Technical Chat |
| How many people code in C these days, and if so, why? |
| << < (95/99) > >> |
| paulca:
--- Quote from: Nominal Animal on May 19, 2020, 04:59:38 pm ---It is interesting to note, however, that JS objects best correspond to Python dicts (orderedDicts prior to version 3.8 ), and not to Python objects per se. --- End quote --- I realised that, at least to some extent and if memory serves me I only created the value objects (Datum in my example) because I googled how to use the json package and it started telling me I needed Encoders and JSON hooks. My current protocol sends a dict of named dicts. eg. {"foo": {"...":"..."}, "bar": {"...":"..."}} But when I went to the docs I ended up getting into what I have now. Even reading this, it's horrible to be honest. It looks like a hacky undergraduate project to parse JSON. https://docs.python.org/3/library/json.html |
| Wojciech Krolopp:
--- Quote from: Nominal Animal on May 19, 2020, 04:59:38 pm --- --- Quote from: paulca on May 19, 2020, 03:01:36 pm ---Have you tried to use the json package? --- End quote --- Only to and from dicts, server-side talking to ajax. And when I do that stuff, my mind is already bifurcated into two antagonists (one trying to implement the thing, another trying to misuse it), so I tend to not notice developer un/friendliness, unless the language/library actively fights me. :-// It is interesting to note, however, that JS objects best correspond to Python dicts (orderedDicts prior to version 3.8 ), and not to Python objects per se. In fact, the two even have the same syntax in the two languages... which might explain why using JSON on Python objects is not comfortable/intuitive: the way those who use a lot of JSON in Python envisioned the json module to be used, would be mainly with dict/orderedDict objects. This is exactly the paradigm difference I've mentioned in other posts, and others have called "writing X in Y" (with X and Y both programming languages). It is not necessary for "object" to correspond to "object" in another programming language. Here, it just happens that the general equivalent of JS objects is not a Python object, but a Python dict, behaviour-vise. Note that this is a pitfall anyone with any amount of experience can fall into, because we humans are instinctive extrapolators, and are particularly susceptible of missing these unless we are aware of this pitfall. Me myself, I've had to climb out of these often enough, and instead of asking "what in Y is like Z in X" (with Y a class or function name, and X and Y prohramming languages) I've had to learn to look at behaviour and features instead of assume analogous behaviour based on name or hierarchy! In theory, that should be annoying (because it means the definition of "object" is now highly dependent on the context, and not like you were taught in school/course/book). Me myself, I don't mind, because I am aware of my limitations, and finding those different approaches allow me to overcome and exceed my own built-in limitations; to grow. You know, knowing how and why others see a different thing when looking at the same thing I am, tells me a lot about what my own limitations are, and how to overcome them. I like that a lot. --- End quote --- The object oriented definitions are somewhat constrained, I mean we're not picking the same things. For instance, there's the "inside of the egg" reference, which seems to refer to the whole egg. However, it also happens to also say, "inside the sheet", which seems like an absolutely generic definition for the purpose of recognizing an object. No, I am not going to be able to tell you why it's a challenge to watch your choices and interpret them without trying to come up with a rational explanation as to why you made the decision you did. Maybe some people need that. But here's the thing: we don't have to be everyone's victim. It's really not that big of a deal to point out that the definition of "object" is silly and inconsistent. I think it's a good thing to consider, and that your own limitations are a very good thing to know about, especially in part with a deep understanding of the problem domain. |
| paulca:
So I went back to look at the json module again. It seems it works fine deserialising to a Dict. So I can probably get rid of the hooks, drop my class type or create a class type which takes the dict as it's constructor arg, so it can handle default values for fields. --- Code: ---aDict = json.loads('{"garageTemp": {"key": "garageTemp", "name": "Garage Temp", "shortName": "GR", "value": "13.12", "type": "float", "units": "\'C"},"pressure": {"key": "pressure", "name": "Air Pressure", "shortName": "AP", "value": "1012.98", "type": "float", "units": "Hpa"},"humidity": {"key": "humidity", "name": "Humidity", "shortName": "HM", "value": "65.36", "type": "float", "units": ""}, "outdoor": {"key": "outdoorTemp", "name": "Outdoor Temp", "shortName": "OD", "value": "12.94", "type": "float", "units": "\'C"}}') aDict['garageTemp'] {'key': 'garageTemp', 'name': 'Garage Temp', 'shortName': 'GR', 'value': '13.12', 'type': 'float', 'units': "'C"} --- End code --- |
| emece67:
. |
| westfw:
I feel like C++ has become * Somewhat Arduino-like in that people don't write "C++ programs" - they go out and hunt down libraries and examples that are close to what they want, and work from there. "Oh, you want Boost, and the Boost extension for lambda expressions, and the XYZZY ray-tracing library, and the ZZZ front end for importing data, and ..." * The language itself is a sort of "Computer Science Language For Computer Scientists who write libraries", which SO much stuff added to it that seems so far off in the ether: "abstracted N-dimensional graphs using lambda expressions; and improvement of Boost" (yeah, I'm picking on lambda expressions...) * There's a cult following who won't like your C++ programs unless they've become completely unintelligible to people expecting to see actual code. "That's not C++, that's Just C With Classes - you're not even using the STL! * I keep seeing presentation "advantages of C++ in an embedded environment", where they keep listing features that have also been in almost all C compilers as well ("inline"? TGtbKM!) * C++ proponents tend to be blind to needs of embedded and speed freaks - "named address spaces" were apparently explicitly rejected, for example. There's a lot of "C++ doesn't have to bad code for embedded; just avoid certain features", but not a lot of alternatives (STL almost immediately gets you dynamic allocation...) I pretty much like the level of C++ used in Arduino and other "careful" embedded projects. And I would certainly consider "real C++" for anything like implementing a GUI application on a desktop. But not everything is an object, and I don't necessarily need all of the new ways to shoot myself in the foot (I have plenty!) |
| Navigation |
| Message Index |
| Next page |
| Previous page |