1,827 karma · joined July 5, 2018
background - I am a computer science major with 30+ years experience. I did do a mandatory class of 'implement your own lisp' many eons ago. It just never really 'clicked' for me. I do, by accident, assimilation and lazyness,employ FP style designs in my software. And I guess fp techniques gradually rub off on me from e.g. javascript, lambdas,closures, and map-filter-reduce. in particular, lambdas are useful to me. But I am one of the guys who continue to read the "let me tell you what monads really are", and every time I fall off the bicycle. So, well, I appreciated this 'Xfor 5year olds" :-)
It is an obnoxious hassle to replace the batteries on it, and equally so set the clock on it.
So, should I trust thus beautiful design to not be a hassle in daily use..? I long for an ugly parking timer that is easy to use, but those have been driven out of the market by this beauty.
Maybe for the user, but for the corporation, they offer more control..
It sounds like is is a sort of 'change-events' pub-subscribe approach, where dependent systems keep their state updated by doing deltas against what they currently store (if I misunderstood this part, the rest here probably is moot).
If that is true, is there anything in the system that guards against if a subscriber fails to ingest an event, for whatever technical reason (bug or systems/execution failure, e.g. network or overload), ie some sort of 'transaction' approach where a subscriber will keep receiving/being due an event, until he has reported back an "ACK I have processed that" ().
I am asking because otherwise it could lead to things like a user account staying open/active, even though an event said it should be deleted.
Some alternative mechanisms with other trade-offs could be things/events like "group X has changed, its current member list is now [...]". In that case, the mirrored group might eventually become consistent on a later update (as opposed to carrying an eternal memory left over by a missed update).
() I am vaguely aware true consistency guarantee is impossible in a distributed system, something about confused generals.
I agree with and recognise its premise - that SO started to feel hostile and decline, before AI "attacked" it. Maybe the article isn't flawed; maybe it just doesn't match my personal expectations/wishes: I would have expected more details on how the late self/auto-moderation reputation game damaged SO. Instead, the article fades out waxing poetically on how developers long for 'authentic community' where we help each other. Put differently, it appeared to promise it would deliver on the flawed reputation game.
Instead, I'll put in my personal anecdotal experiences of this as an SO user. I am an 'average' SO user, doing a mix of the three 'passive consumption', 'asking questions', and occasionally answering or commenting on questions I have trench-warfare experience on / 'been there too, did this'. My SO experience as the years progressed, is that more and more my attempts at relevant contributions would be flagged/killed/removed on spurious judgements and vague-unclear justifications.
The actions reeked of being motivated by "if I moderate/remove N items, I meet my quota", instead of being grounded in valid concern. And of being based on literal interpretations instead of intent ("TECHNICALLY, it is possible to flag this contribution according to rule #237, and since it earns me a cookie point, I'll do it because nothing stops me").
The original intent behind that entire system was to ensure quality contributions. But the actual effect of it being applied this way, just conditioned me to not be bothered to add contributions, with the feeling that at best I would get hassle to be able to contribute, and that instead I was producing dead-in-the-water cannon-fodder for a reputation-farming moderator.
I had hoped the featured article would shed some more light on this, but it never really dug into the subject, just referred to it as accepted fact.
I do use the AI tools to some extent, if for no other reason than that they are currently the path of least resistance, and google+friends have lately played themselves out of the game.
He is probably right we should get acquainted with using agents before dismissing it :-).
- the 'autopilot GPS' problem: Colleagues who basically have no idea how things fit together, because DI connects the dots for them. So they end up with either a vague or no mental model of that happens below the surface.
- the same, but related to scope and costs: Costs: Because they don't touch what is 'built behind the scenes', they get no sense of how costly it is ('every time you do use that thing, it instantiates and throws away a million things'). Scope: Often business logic dictates that the construction hierarchy consists of finely tuned parts: You don't just need an instance of 'Foo', you need a Foo instance that originates from a specific / certain request. And if you then use two Bar's together, where Bar 1 is tied to Foo 1 but Bar 2 is tied to Foo 2, you will get strange spurious errors (think, for example, ORMS and database transactions - the two Foos or Bars may relate to different connections, transactions or cursors.)
One antipattern I have seen (which may actually be an argument FOR DI..), is the 'query everything' service, which incorporates 117 other sub-services. And some of the junior developers just love that service, because "then I can query everything, from a single place!" (yes.. but you just connected to 4 databases with 7 connections, and you are only trying to select a single row from one of them. And again, code with the everything-service becomes quite untestable).
The best part of the article is its advice for triggering the broken dependencies at compile-time, I really hate when I have to go through complicated flow #127 to learn that a dependency is broken.
So, you don't really have orinciples or a cause, apart from 'I should be in charge'. It also means voters, if they are capable of judging that, cant really trust you, because you will switch causes whenever it suits you.
In my own country, I could name politicians who always carried the same color as the reigning political movement, and who would switch when the winds change, because their real principle was 'be on the winning side'.