Hi, this is a side project started about a year ago that we’re finally launching. We combine automatically generated statistics with manual curation on the most popular data science and data engineering projects. We are independent consultants and the idea came from helping clients choose the best open source to build their applications. Rather than a lot of manual digging, you can find the relevant projects in one place, get a quick comparison, and have a starting point to probe deeper. We hope you find it useful. Your feedback is much appreciated!
I think comments are really a bad idea. If you want comments, either make them explicit properties in your data structures or use something else like YAML or XML. JSON is the most practical language out there for inter-machine and inter-program data representation.
JSON has two unique properties among data representation languages that make it useful for certain types of tasks: 1) it is very simple to write conformant parsers and serializers, and 2) the parsed representation contains all the original semantic information in the original document (excluding maybe whitespace). If you have a separate syntax for comments, then parsers must either drop the comments (making transformation tools less powerful) or parser must provide a more complex representation (e.g. like the DOM) and drop the simple map/list/scalar data model.
Please don't make JSON the next XML! Source: I spent about 5 years suffering with XML in the Enterprise Application Integration world.
That being said, I think there are some situations where you want to check for problems up front (possibly in addition to exception handling). In particular, if you are parsing some data from outside the program, you may want to provide some context about what was wrong. KeyError is not very helpful to your users.
I've personally run into problems when I don't do exact comparisons with True and False. For example, I've forgotten to return a value in one path of a function/method, and then tried to use the result in an if statement in the style recommended by the OP (e.g. if fcall(): do something). After being bitten several times by this, I always do explicit comparisons.
In this particular situation, there was no else. I probably added an else clause with an assert return_value == False, as the function call was a virtual dispatch that could have many implementations. Of course, I wouldn't do that for every if/then/else statement in my code. In general, I'd prefer a stricter language that only permitted a boolean as a condition in the IF statement, avoiding this problem altogether.
If you are using truthy/falsey values, I think it can be a code smell that you are not doing enough to catch invalid values up front or should normalize the values closer to their creation point.
But the discussion is about truthy values and inexact comparisons - avoiding inexact comparisons and having an else means:
if something==True:
do_this()
elif something==False:
do_that()
else:
raise UserWarning("Shouldn't be here")
Which is a code smell to me. What I would do is:
assert isinstance(something, boolean), "Shouldn't happen"
do_this() if something else do_that()
(replace assert with something else if you want it not to be optimized away with -O; assert is a debug-only construct in Python. Or just drop the assert altogether. In most places, I would - there's no end to the amount of validation you could do, and most of it is unnecessary)
Another approach that can work in big organizations: make sure that your boss knows that, if they ignore your advice, the responsibility for the decision is theirs, not yours. In a C.Y.A. organization this is often enough. Be sure to have written proof -- when it hits the fan, people tend to have selective memory.
This leaves a bad taste in my mouth. I've seen quite a few people use this approach in an attempt to get their boss's job, irrespective of the boss's performance in their position. In general, I think that fighting your boss only leads to a draw, almost never to a win.
It is interesting to see this from a (former) CEO's perspective. I've seen many big company executives who get stuck in stage 3. I knew that my last big company was destined for failure when the CEO bought everyone a management book about dealing with change. He seemed to be saying, "its not me, its you". If he had a bit more humility, he could have made the changes to get the company moving again. Of course, it can be hard to accept responsibility when egos are big and failures are politicized.
In a startup, you have this process not just for the company itself, but for each setback (e.g. in fundraising, customer acquisition, customer issues, etc.). Establishing a culture of accepting responsibility and learning from failures is absolutely critical. I think the biggest thing I've learned about my time in the startup space is how to deal effectively (or at least better) with failure.
I welcome the maker movement and I'm glad that what I did as a kid is now cool.
I got my start in engineering by reading the manuals of my father's HeathKit projects and by building a simple computer using a Z80 and a few other chips that I got through mail order and Radio Shack. Back then, having a personal computer was much less common and I could imagine building something roughly comparable to what was on the market (Altair, Apple II, C64,...). A generation before me tinkered with Ham Radio.
Today, HeathKit is out of business and Radio Shack sells overpriced consumer goods. Our electronics is now much more sophisticated and there exists a much wider gap between what one can do from on their own vs. commercial products. I think there was a dry period after the rise of PCs and before the maker movement, where there wasn't much opportunity for a hardware hobbyist. Limor and others like her are coming up with really interesting projects that are still relevant in today's world. I appreciate their re-imagination and invigoration of this hobby and hope to get my son interested when he's a bit older.
