It's hard to completely get away from objects in Python, but I don't think that needs to be an objective to get away from OOP patterns. My suggestions would be:
- Don't use classes for information. Use regular data structures (dict, list, tuple, set) and use functions to manipulate them. If you really want/need something like a struct, use a dataclass.
- The itertools module has a bunch of useful constructs for creating and combining iterators. Take advantage of Python's iterators and construct your own when necessary.
- List comprehensions and generator expressions are great for clear and concise data transformations
- You're going to have to deal with state somewhere in your program. That's fine, some state is necessary to do real work. Don't feel bad about creating classes for things like context managers (e.g. for a database connection) so you can use it in a with statement and it will handle the setup and teardown logic for you. That way your business logic stays concise and Pythonic since those classes can be in separate modules and imported as necessary. I've found this 'functions in the front, classes in the back' approach to writing Python useful as it lets me think about what my program does in a functional manner without denying myself the ergonomics of Python's class-based ecosystem.
> Don't use classes for information. Use regular data structures (dict, list, tuple, set) and use functions to manipulate them.
I've written a lot of functionalish Python, and I've found that this is a consistent way to breed code that's hard to understand. Instead, I would default to (usually frozen) dataclasses to represent data—they're functional records that also let your code reflect the concepts that make sense for whatever you're doing. A list of dictionaries of strings looks like any other list of dictionaries of strings; a sequence of User objects has clear semantics and, as a benefit, is harder to mutate in unexpected ways.
Wouldn't TypedDict come in handy here? This way we can kinda mimick a structural typing system. The only disadvantage I ran across here is that TypedDict can't handle recursive fields, unlike dataclasses. Otherwise, it seems to me like a more Pythonic choice, reminding of Clojure
> Don't use classes for information. Use regular data structures (dict, list, tuple, set) and use functions to manipulate them.
One problem is many of these datastructures are easy to mutate. When I need to ensure immutability to a dictionary, for instance - quite often - I can't avoid wrapping it in a class and setting up an interface to lock down mutation.
If Python had a way to declare immutable datastructure, similarly to Clojure, it would make life a lot easier...
> Read-only proxy of a mapping. It provides a dynamic view on the mapping’s entries, which means that when the mapping changes, the view reflects these changes.
This can be helpful in some cases, but it's precisely what I sometimes need to avoid, which is protecting a dictionary and having changes affecting only its own scope.
If function A passes a dict to function B, I would like:
1) Function A to keep the dict intact while function B can manipulate its content;
2) Function A can change the dict after passing to B, and B still keep the original copy, unaware of A's later changes.
One way of doing this is by deep copying dictionaries around, but it can easily become a big performance issue.
> Ideology is inescapable. To some extent, everyone is under its influence. But that does not mean that all are equally ideological
The author makes this point very plainly. The 'well it's all ideology anyway' take is reductive and uses relativism to (poorly) justify people supporting ideas that are harmful to both themselves and to society.
In the same way that acknowledging that human conflict is inevitable doesn't justify violence, the existence of ideology doesn't justify structuring one's entire life around it.
> justify people supporting ideas that are harmful to both themselves and to society.
Harmful according to whom? It's safe to assume people don't support ideas they think are harmful to themselves and society.
What irks me is that the "ideology is intrinsically bad" idea is historically firmly part of conservative ideology. One early formulation is Burke's criticism of the french revolution.
Harmful according to other ideologies conlficting in the mind of the same person.
You think murder is morally wrong. You think some govt policy is so important that when govt kills people while it is carrying out the policy, the ends justify the means. Ideology is what killed those people.
Is that a bad trolley problem where you only tell us the consequence of one side of the decision, and then use that to tell us that even thinking about taking that decision is is bad?
I'd call that a "no", actually. Or just a bad faith argument.
I left it vague so people of both sides could relate to how it fits the other side's hypocrisy. But I suppose this also allows people who are looking for a fight to imagine that it fits their own hypocrisy and get defensive.
I don't think it's an attempt to justify things as much as an attempt to question whether the author is making a real point. He suggests that we should "adopt flexible stances, mixing traditions", rather than "adopting rigid and extreme positions", but almost everyone honestly believes this is what they're doing. (I would argue that "rigid and extreme positions" is just what it looks like from the outside when someone's mixing in a tradition you don't understand.)
I could imagine someone saying that we should strive to live off of vibes, never having or acting on ideas about how the world should be, but he doesn't seem to be arguing that.
But liberal humanism /is/ an ideology and denying that gets you further from the truth. You can accept that as your ideology or you can say "actually this is just factual reality" but then you're being a closed-eyes ideologue just like the author. It's OK to be ideological because ideology is just the axioms you choose. If you think that equality is good or bad (in some specific situation like access to resources) that's an ideological stance. There's no "non ideological" position.
Of course there are better or worse ideologues (and blind ideologues tend to be the most insufferable because they believe they're non ideological but turn out to just be neoliberals), but nobody is non ideological.
> In the same way that acknowledging that human conflict is inevitable doesn't justify violence, the existence of ideology doesn't justify structuring one's entire life around it.
That analogy is pretty loaded, I think. I doubt people making it would take issue with someone deeply involved in a charitable cause and spending their life to relieve people from their issues. Likewise, I doubt people making that analogy would consider themselves deeply invested in ideology, while, in fact, almost everyone is almost inescapably embedded in a set of dominant ideologies.
> Would dedicated engineering time for a short time improve the situation and benefit the whole organization?
This applies to literally every software company ever. There's also too much vague corporate jargon to make it clear what specifically the role involves that makes it meaningfully different from DevOps.
> A different but equally important part of the team’s job is to architect, build, and refactor major software components
> handle multiple, sometimes conflicting priorities ... willingness to pitch in whenever necessary to get things done
Treating systems architecture with the same "ship it" mentality of product features is asking for a world of hurt.
Well even though you are talking about "corporate jargon" - From my experience this role becomes relevant much sooner. Many startups (especially in hyper growth) will suffer from decreasing velocity due to tech debt and lack of investment in dev experience and engineering enablement.
Enablement can be done in many ways - internal APIs, Skeletons, Communication protocols, Education and more. The fact that these are backend developers with different mentality and goals already makes a huge difference. For both the business and their fellow engineering that see the investment in their experience.
> This applies to literally every software company ever
Well not really. It might be right to the more mature ones. Also, There are many ways to implement Engineering Enablement, but once you cross the 30 engineers in your R&D, it feels like the right time to consider a dedicated team that are measured on these things instead of new features.
> Treating systems architecture with the same "ship it" mentality of product features is asking for a world of hurt.
Totally, That's why I'm sharing the importance of having such a role and saying this should be a dedicated role and not something you do "on the way". You must dedicate time for engineering enablement initiatives. If you can achieve it as "engineering bucket list" within your current organization - Good for you. You should give this baby a name - Engineering Enablement
For that matter even terms like DevOps seem very fuzzy and differently interpreted by everyone. It seems to some these are teams that fight fires. To others they are teams that perform any and all engineering relating to residence. To others it’s some mix. I’m not familiar with the space and approaches but I wonder if all these labels and constraints are useful or if it is better to just stick to a generic “software engineer” role.
One big difference with DevOps, according to the article, is that the enablement team can refactor the software and promote specific architectures and processes.
Let's say you are working in a micro-services architecture. Multiple services owned by multiple teams, some services are newer than others (years).
Now try to apply a new centralized logging system or migration to K8s or even introduce a new feature toggle system. How much time will this effort take? How many stakeholders will be involved, what are the tradeoffs of this effort?
With an engineering enablement team or even a "task force" - this effort becomes much more feasible
Does it matter that dbt is written in Python? dbt models are still SQL at heart. Sure there's the addition of Jinja to enable references for data lineage and configuration, but it's all compiled to SQL with fine-grained control over what's produced.
Forgive me if I come across as combative, but I don't understand generic appeals to things like a language being rigorous. Rigorous to what end? What problem is it solving where that is required? If you know something specific in this domain where that level of rigor is needed, why not share what it is?
There are a lot of problems in the analytics space (and a lot of opportunity for new practices, tools, and businesses), but I would argue that at the end of the day the primary issue is whether or not data producers choose to model data such that it is legible outside of the system that produced it much more than it is about any particular language or methodology.
For typical datasets (~95% of companies have medium data on the order of gigabyte), you are 100% correct that the data modeling / formatting is the biggest challenge.
Having well modeled data that matches the business domain is a massive (2-10x) productivity boost for most business analysis.
The most important word here is "sense" -- I don't think anyone can argue that the sense of individuality isn't real. But how much of our personal narratives are true, and how much of them do we make up to try and make sense of an otherwise chaotic existence? That isn't a fluffy philosophical musing; it's a core question of human psychology.
Some Buddhist teachings speak of "word sickness", where we spend so much of our lives living in abstractions that we are unable to experience the present moment as it actually is. We've drawn boxes around phenomena to try and classify everything, without realizing that we do this in ways that reinforce our own identities and sense of meaning in the world. We tend to treat the things we are good at as more important than the things we aren't, for instance. So how much of one's concept of self is really real, and how much has been invented to coalesce a sense of identity?
I feel like you could make an interesting game out of this. Given these rules, find the best "false negative," a realistic and inoffensive, but banned username. My best so far are "brownie_gurl" and "Megasthenes."
Is there any link between "open the kimono" and "comfort women" or is that conjecture?
It's a fascinating phrase, perhaps not least because nobody knows where it comes from but somehow people also seem to know that it's innocuous or know that it's sexist.
That was conjecture on my part. Now that I read more of that investopedia link, I see it likely came from Jobs, which would explain the use of the phrase at Apple,
> Steve Jobs, the founder of Apple, notably used the expression in 1979 during a visit to Xerox Parc. He reportedly said: “Look, I will let you invest a million dollars in Apple if you will sort of open the kimono on Xerox Parc.” This memorable expression and meeting apparently led to him discovering the mouse, and Apple subsequently launching the first commercial mouse. [1]
In that context it seems fine to me. He's talking about a product. Now, clearly, "open the kimono" means to bare something naked. If you ask a person to be more "open kimono" as a way of asking them to be more open, I think that crosses a line. And, maybe if you suggest someone go "open kimono" on their work, that could be received offensively while not being intended that way. So, context matters. I'd probably steer clear of it entirely though.
> Yes some empires went away, but we still read writings from Ancient Greece, so is it correct to say even that civilization ended?
I get your point, but I think it misses the mark. By this measure, no civilization has ever ended. If you go that far, you have to argue that the end of a civilization is the same as the end of the human species.
I think it's helpful to think of it more like the end of the French revolution. No one can agree on a point in time when the revolution ended, but we all agree that it happened.
> Reversing the decline is a monster task — and one that some journalists and news organizations have taken upon themselves. They're going to need help — perhaps from America's CEOs.
Is this a bad joke? Distrust of media is largely brought about because it is (mostly) in the private sector and therefore always puts the sustainability of its business model above objective reporting. We've known for a while now that negative news sells, clickbait sells, and media organizations are all too happy to push it out there if it helps their struggling bottom line.
France has a public agency, AFP, being the news arbiter (it’s the Reuters competitor). Yet, information is bullshit. They choose to report on some topics and not others, and they choose to publish extremely biased news without quoting the opposing side to interview their defense. Happens with the wage gap, happens with the Traoré, happens with Sarkozysm, happens with Fillion... It sways elections.
State ownership is just one small step above private ownership. A far more interesting organization would be a news co-op, preferably one not backed by ads. Unfortunately there are massive hurdles in front of such an organization existing. Not least of which, they might actually report things that it does not do to worry the public over.
> happens with Sarkozysm, happens with Fillion... It sways elections.
In which sense did it happen? They didn't report on it or they did without "quoting the opposing side"? Specifically in the case of Fillon, the guy was caught stealing from the state in a pretty obvious manner ( his wife was receiving a salary for being his parliamentary assistant for like 15 years, while never having received a pass to actually get in the parliament). There was little of substance he could say, and when he did say it, it was obviously complete bullshit. Yes, it swayed the elections ( he was the favourite to win) and thankfully, that's not the type of person anyone should want running the country.
The judge admitted she received pressure to investigate this affair.
All deputees use the assistant salary evasive mission loophole, only candidates who are potent competitors are found out by journalists. Meanwhile Macron’s assistant had 6 diplomatic passports and a gun after being fired for mugging political opponents (!), yet journalists uniformly said that it probably was a honest mistake by the passport department.
State-owned AFP and most journals being >1/3rd sponsored by the government is clearly helping the mugging of political opponents in France, whether through the use of media, judges or by simple private thugs armed with guns and diplomatic passports.
> Is this a bad joke? Distrust of media is largely brought about because it is (mostly) in the private sector
You think the 82% of Republicans who distrust the media is due to being in the private sector? And that they would trust it more if it was government run?
> sustainability of its business model above objective reporting
Wouldn't publicly-funded media be the same? if a conservative govt wanted to cut the media budget would we not see one-sided negative reporting targeting conservatives?
It's a very valid question. My personal opinion is that public media isn't by default better due to its ability to operate at a loss - in fact it could be argued that the only reason an administration would allow it to run at a loss is if it saw the operation as advantageous to its political objectives.
I think the real answer that nobody wants to hear is that media at this scale cannot exist without bad actors trying to manipulate it. There is no "web of trust" at the scale of millions.
Isn't UNIX a clear example of people not engaging in architecture "astronaut" behavior? It was designed to be as simple as possible - in stark contrast to Multics.
I would say Unix is a system designed to be simple and powerful. It takes a lot of thinking to achieve a system which is both simple AND powerful. Whereas things like XML and Multics are powerful they can do everything but they are not simple. In the end that limits their power because they are hard to learn and things built with them are difficult to understand, because they are not simple. And when something is hard to understand it is also error-prone, and such a system is fragile.
It takes "astronauts" who think hard about the architecture to come up with systems that are simple and powerful at the same time.
“It was designed” - that’s the key. We all know how hard it is to make things simple. That doesn’t come naturally. Hardest stuff I’ve ever done is to go through complexity to reach what is simple. (Definitely paraphrasing someone else there.)
Right now I have a project of potentially infinite complexity and we need to build really fast. A lot of my focus has been finding the very few pieces of bedrock and fixing on those, allowing the rest to vary as our appetite for complexity grows. Start today with an achievable goal, test hypotheses, don’t paint ourselves into a corner. All team comments are how simple it is. That’s by...design.
Simplicity does not contradict architecture. For some (me included), it is even the essence of it. Leave out the bells and whistles. This is why JSON is so successful, even though we had XML long ago. Technology should be more of that, and I would consider it superior architecture.
It's the thing with abstractions: changing angle changes the abstraction by seemingly replacement candidates, but only the good ones maps properly onto physical hardware and human cognition.
eg: "everything is a file" maps properly to both physical storage with addressable, streamable content and to the human mind as data reachable by classification (file name). Maybe a revolutionary OS design could better that with "everything is a message", but I think you can understand why one can have doubt on this translation from files.
The difference between a file and a message is that a file does not prescribe format of the file - it's usually application dependent, but is understood to be plain text.
A "message" tends to have formats associated with it (which is what differentiate it from being just a "file" that's transferred via a protocol). These formats, like JSON, or xml, or whatever new fangled formats kids these days use, now requires architectural astronauting; namely, common field names, or standards, so that different programs would parse them similarly. And now you'd want schemas for those formats, and automatic parser generated for those formats, and more and more...
- Don't use classes for information. Use regular data structures (dict, list, tuple, set) and use functions to manipulate them. If you really want/need something like a struct, use a dataclass.
- The itertools module has a bunch of useful constructs for creating and combining iterators. Take advantage of Python's iterators and construct your own when necessary.
- List comprehensions and generator expressions are great for clear and concise data transformations
- You're going to have to deal with state somewhere in your program. That's fine, some state is necessary to do real work. Don't feel bad about creating classes for things like context managers (e.g. for a database connection) so you can use it in a with statement and it will handle the setup and teardown logic for you. That way your business logic stays concise and Pythonic since those classes can be in separate modules and imported as necessary. I've found this 'functions in the front, classes in the back' approach to writing Python useful as it lets me think about what my program does in a functional manner without denying myself the ergonomics of Python's class-based ecosystem.