And that's why it is best to avoid GPU-acceleration unless you truly need it.
GPU drivers have always been full of bugs and will always be, since modern GPUs are ridiculously complex and designed for speed rather than reliability.
JSON is just one tiny part of most programs, sitting on the edge where the program interacts with other programs; it doesn’t permeate the entire codebase.
Structure privacy, OTOH, does. Count me in as someone who really enjoys the case-based approach. It’s not the only one which could work, but it does work.
The single most productive habit I picked up int the last few years is to always use exactly the same name for the same entity across source files, configs files, database entries, protocol fields, etc.
That’s funny, I did it your way for years and ended up considering it a big mistake.
Today I use idiomatic names - MyName in Go, myName in JS/JSON, my_name in SQL. There are many reasons but generally speaking, for me, it’s less effort and code is more readable.
I just ran into this earlier today - it makes navigating code with grep more difficult.
I had a YAML file using `some_property_name`, which was turned into `SomePropertyName`, and it's a small annoyance. It's not a huge deal, but it adds friction where some languages have none. (Or alternately, getting reordered in a separate system like `property_name_some`.)
The issue that I ran into is dealing with lot of code across different languages, like plpgsql, go and JavaScript.
Especially with database code, something that's fine in Go, like EmployeeID, ends up being employeeid in SQL. You can use underscores in Go but that can trigger other behaviours. If you mix your own JSON with JSON from other sources, you get inconsistent capitalisation. And so on.
And when you have hundreds or thousands of identifiers like this, it gets really hard to read.
You can of course capitalise in SQL - even though it's not semantic - but that becomes inconsistent, too. And then of course the lifecycles of each of these things can be different, which adds another layer of complexity - maybe you refactor your Go code before you upgrade the database, so you end up with two identifiers anyway.
Ultimately I switched to using idiomatic names everywhere, and I really haven't looked back. The boundaries between these systems tend to be pretty clear, as mentioned by someone else, so finding things shouldn't be hard regardless of what they're named.
It's certainly takes slightly longer to deal with idiomatic names - but you read code way more than you write it, and it's easier to read idiomatic code.
I do the same way like you. My logic was that I can tell where the value is coming from. I would use the same type but different name.
Is it coming from a client via http? Then it needs to be checked and saved
The database? then it has an id field which could be null in other cases.
Or I just create a new instance?
Naming things is hard tho, sometimes I do think I should just name them the same and stop caring. I'm not sure if I gain productivity but it gives me some comfort that I can instantly tell the source of the data.
I have the benefit of writing mostly C++ where there is really no globally agreed idiomatic naming. At $JOB we use snake_case naming for C++ functions and objects (as opposed to types), which also matches the python naming convention we use.
Snake case is not idiomatic for xml, but we still happen to use it for leaf config options.
The main benefit is reducing ambiguity to what maps to what across files. Ease of grepability is also an advantage.
The moment you integrate with a third party your US centre zip_code field is suddenly coming over the wire as postCode. The conversions are going to go on, at least in go I can define all of that conversion with ease in one place.
I don't disagree, the problem I have with it is, I have to pay for that up front and have to factor it into my design immediately. This also combines with the fact that the namespace is very flat with no heirarchy, so, choosing good public names is something I feel like I spend way too much time on.
Go is the only language that causes me to pull out a thesaurus when trying to name methods and struct members. It's kinda maddening. Although, after going through this exercise, I end up with code that reads like English. I just wish I could refactor my way into that state, rather than having to try to nail it up front.
Go's semantic use of case is objectively bad because most of the worlds scripts do not have the concept of it. For example ideographs, as used in eastern countries, do not have capitalization. This means programmers in many parts of the world cannot express identifiers in their native tongue.
It looks like something was lost in the middle of your comment. You open with something about it be objectively bad, but then it jumps to something about how it is subjectively bad. What was omitted?
I don't really think the sarcastic tone was called for, but the previous poster is right. "I can't name variables in my native language" is objective, but whether or not that's bad is subjective.
Very true but “bad” is always subjective so at least they came up with an evaluation that is binary — either you have capitalization in your language or you don’t, either the analogy fits or it doesn’t.
(Some linguist will point out that Bongo-Bongo has half-capitalization, or half has capitalization).
So if you have a concept that doesn't have an equivalent in English you just kinda translate it and add a comment for other people of your language to understand what it is?
Sure. And for a concept that's so foreign there is no English equivalent, I hope there's plenty of documentation. I mean, to each their own, but for me, a software team using native language for variables is a red flag.
Dislike it very much specially with codebases which have lots of acronyms, aka aviation. Having to change an acronym from upper to lowercase just suck.
The casing rules are quite explicit and enforced by the compiler. A build would have immediately failed on whatever mismatch you had. A few hours and you didn't even think to try compiling it?
I'm guessing you are talking about something else entirely, like, perhaps, decoding JSON into a struct using reflection and encountering a situation where the field names didn't match? Indeed, implicitness can bite you there. That's true in every language. But, then again, as you prefer explicitness why would you be using that approach in the first place?
The rules are explicit but the actual changes in code are very small and unique to this language (or unique from the languages I had ever used). It’s one of those things that you can forget about — because it’s a small difference in code and arguably isn’t explicit.
I forget what it was, but basically my code wasn’t working the way I thought it should and it was solely due to a lowercased struct field. It happened twice where I spent at least a little while trying to figure it out.
And yeah I would guess that I tried to compile. Would be very dumb if I hadn’t although wouldn’t be the dumbest thing I’ve ever done
I'm surprised it doesn't support POWER - old Macs have to be more available than SGI kit.
(Though I'll also agree with sibling comment - if the goal was "test BE support on readily available hardware" I'd 100% use Raspberry Pis, since ARM has a BE mode. NetBSD supports it, for instance.)
I’m surprised none of the 9front guys have explored big endian mode on raspberry pi. They don’t seem like they’d be turned off by the perversity of it.
There is a SPARC compiler and linker but no kernel. So far no one has had the interest to get some old SPARC hardware and do the hacking. There is a SPARC instruction emulator on the system that I used to test some libc modifications recently.
I love this article! It is not the first time I hear the bad reputation of aspartame is unfounded.
AFAIK, there was only one study which said aspartame was dangerous: they fed a rat with a HUGE amount of it (like way more than a human could consume, in proportion) and the rat got ill or died I don't remember. That "study" was obviously flawed yet the media kept talking about it everywhere.
At that point, it wouldn't surprise me if the sugar industry is behind this.
So when you see
then $a is an array reference where each item is a hashmap. But with then $a is an array reference where each item is a reference to a hashmap.