cbsmith

Yeah, there was a ton of wrong here. You captured much of the highlights.

I now understand why some developers tell me they think using environment variables for secrets is a bad idea.

One can recognize a term but be confused by a statement in which the term is used and how it is relevant to the discussion.

> Plenty of examples of open-bid ascending-price auctions beating better systems due to familiarity, for instance.

Yeah, I think we're talking past each other. I wasn't making a statement about "better" systems, and there are certainly other factors that can influence outcomes. I was only speaking of the principle that it is advantageous for an auction to be fair, and open-bid ascending-price auctions can be fair. I am quite certain that if you were to murder anyone who participates in a fair auction, then unfair auctions will be more successful, but that's outside the scope of the principle I'm speaking to.

> No, there isn’t. If anything, the market failure of non-competitive markets almost implies the reverse: power prefers unfair auctions.

I do not follow your reasoning here. What do you mean by "the market failure of non-competitive markets"?

Seriously, this stuff is econ 101. Ultimately auctions are about bringing together as many buyers and sellers as possible to produce as much liquidity as possible. Fair auctions naturally attract more buyers and sellers than unfair auctions. If the auction is unfair to say, buyers, then you'll have fewer buyers using them than auctions that are fair or favour buyers, which in turn means that sellers will get access to fewer buyers, so they'll go somewhere else.

> Milgrom is saying Google ran fair auctions. I don't believe anyone has put forward evidence to suggest it didn't.

...and the idea that running fair auctions are subtly geared to concentrate wealth at the top is silly. Yes, there is a well understood principle that fair auctions will out-compete unfair auctions in the long run, but whether that concentrates wealth at the top is a consequence of a lot of other factors that are entirely external to the auction dynamics.

> I bet you haven't. It's like asking a programmer if designing weapons is their primary imperative - nearly everyone will say no. But when you examine the number of people that make contributions that could be weaponized or is abused as a weapon by their superiors, the statistics tell a different story.

Just because one's work can be used as a weapon doesn't mean that designing weapons is one's primary imperative. "primary imperative" isn't about outcomes, it's about objectives. I'm pretty sure the primary imperative of the Wright Brothers was to get something into the air, not to design a weapon.

I'd argue non-typed Python supports duck typing pretty well too, so you don't necessarily need Typed Python to support it.

That seems a lot like duck typing to me.

    class X(TypedDict):
        x: str

    class Y(TypedDict):
        y: str

    class XYZ(X, Y):
        z: str

That should get you the class/superclass relationship that you want, no?

Python classes are basically dictionaries that have a distinct type bound to them. Alternatively you can subclass from dictionary to give yourself a distinct type but still be a dictionary. Slotted classes are basically named tuples (and of course, Python has actual named tuples and dataclasses), so there's a lot of ways to "tag" a collection with a specific type in mind.

Their problem stems from the scenario where you don't type them. You just leave them as generic lists & dicts.

Frankly, your contract was that you have no idea what fields those objects might have. I'm just fulfilling it. You won't have checks for validity of each field, as Optional is valid, but you will have to have code that handles Optional<> types (so things like foo.getModel().orElse()...), which is the requirement you described. That doesn't mean you'll be constantly checking the validity of each field.

> In languages built for it, you can type your dicts/hashes/maps/whatever and its easier to see what they are/know where the functions that operate on them live.

I think I must be misunderstanding what you mean by that, because I can very much do that in Python.

I always think of Python as having "fairly strong" typing, because you can override the type of objects by just assigning to __class__.

That one is pretty simple. You have a Car object with four fields. The types of the fields are, respectively Optional<Make>, Optional<Model>, Optional<Year>, and Optional<Colour>.

Hickey makes it sound worse than it is.

Living this dream in Python right now (inherited a code base that used nasty nesting of lists & dicts). You don't strictly need to do OOP to solve the problem, but it really does help to have a data model. Using dataclasses to map out the data structures makes the code so much more readible, and the support for type hints in Python is good enough that you can even debug problems with the type system.

I don't find the visualizations shown on websites terribly convincing, so I kind of get it. Yes, you need to kick the tires to understand if it is useful.

Exactly what I'm trying to say, though written better.

> So as the parent suggests it's really better to adjust the business process if you can.

That's another way of saying that there are serious trade-offs going that way that need to be justified... which may also be true for the path of adjusting the business process.

s/ERP/any other business software product/

...and yet there are all kinds of segments where customized tooling is more the norm than otherwise. It just depends on whether the deviation from the norm is a competitive disadvantage or a competitive advantage. There are a lot businesses where in at least one case, it is an advantage.

There's a bit of selection bias going on there though. The reality is that SAP and similar products are designed for a business that works a certain way, and so obviously businesses that fit that profile are most likely to get value from using the tool. However, there's a reason other businesses don't work that way, and often retooling to work the SAP would be a net negative. Sometimes retooling SAP to fit the business is also a net negative, in which case the right choice is just to not use SAP, but I've certainly observed cases where there was a benefit from refactoring the tool to fit the business.

In other news... https://www.reuters.com/technology/intel-aws-expand-strategi...

I love realizing that I'm old enough that people think that practices that were the norm at the start of my career don't seem credible even a decade ago.

That's an arbitrary division of "one thing" though. You've decided the "one thing" includes the HTTP request and response, but it doesn't involve the socket call for that request and response. I'm not saying the test has to involve a network, or a network card, or anything like that, but perhaps a more accurate reflection of the "unit" to be tested is something that reads and writes to a channel or even a socket (and again, not necessarily a TCP/IP socket).

In reality, you're actually testing a bunch of method invocations that won't happen when the code is being used, and to do it, you're also breaking a lot of the contracts that one would otherwise expect to be maintained... maybe that's not the optimal way to do things.

It's the first time they've publicly acknowledged what specifically was used in the training set for their LLMs. It's NOT the first time they've said that that data could be used for research. The presumption was that they had used the data for their LLMs.

Maybe it is surprising to some that they this particular research used that data, but it really shouldn't be to anyone aware of how LLM development is done.

"I want to be able to mock the REST callout without performing any actual i/o."

Why? Because it's hard for you to mock out actual I/O, which could be solved by a tool that makes it easy to mock out actual I/O.

> The security manager was removed as no one used it well or found it useful.

That's as much an indictment of the Security Manager than anything else. ;-)

> Every one of these features were added because they were useful to java developers.

Which creates a requirement in my mind that removing those features needs to be justified by adding more benefit than they take out, but it is entirely possible that those features were the best way to address the needs of Java developers.

The reality is that Java is no longer seen has being a high integrity runtime anymore, so nobody uses it that way. The use cases for a high integrity runtime haven't gone away though.

There's an argument to be made that to the extent they break the rules in some manner, they're doing more harm than good. Should you be testing scenarios that are impossible to encounter with the code? Should frameworks be breaking encapsulation and contracts of code?

Most of the time breaking the rules is a reflection of either a bad practice or lack of functionality in the language. I'm all for experimenting in either of those dimensions, but there's a lot of value to have a default behaviour of not doing that.

This is why successful organizations shadow interviews.

African or European. Everyone knows that.