> Give it more than a couple months though and I think we'll see it mature some more.
Or like the early Python ecosystem, mistakes will become ossified at the bottom layers of the stack, as people rapidly build higher level tools that depend on them.
Except unlike early Python, the AI ecosystem community has no excuse, BECAUSE THERE ARE ALREADY HISTORICAL EXAMPLES OF THE EXACT MISTAKES THEY'RE MAKING.
CPython in particular exposes so much detail about its internal implementation that other implementations essentially have to choose between compatibility and performance. Contrast this with, say, JavaScript, which is implemented according to a language standard and which, despite the many issues with the language, is still implemented by three distinct groups, all reasonably performant, yet all by and large compatible.
I don’t mind those, tbh (maybe because I came to Python from C and Lisp).
Contrary, I dislike NumPy’s decision to make reduce/accumulate methods of operations (e.g. np.add.reduce and np.mul.accumulate), not higher order functions or methods of NumPy arrays.
map() and filter() work on any iterable, so it's not clear which type you'd expect them to be methods on (keeping in mind that the notion of "iterable" in Python is expressed through duck typing, so there's no interface like say .NET IEnumerable where they would naturally belong).
len() guarantees that what you get back is an integer. If some broken type implements __len__() poorly by returning something else, len() will throw TypeError. You can argue that this is out of place for Python given it overall loose duck typing behavior, but it can still be convenient to rely on certain fundamental functions always behaving well. Similar reasoning goes for str(), repr(), type() and some others.
One can reasonably argue that Python should have something similar to C# extension methods - i.e. a way to define a function that can be called like a method, but which doesn't actually belong to any particular type - and then all those things would be such functions. But, given the facilities that Python does have, the design of those functions makes sense.
I guess there's an incentive to quickly get a first version out the door so people will start building around your products rather than your competitors.
And now you will outsource part of the thinking process. Everyone will show you examples when it doesn't work.
Hey there, expecting basically literacy or comprehension out of a sub-industry seemingly dedicated to minimising human understanding and involvement is bridge too far.
Clearly if these things are problems, AI will simply solve them, duhhh.
You joke, but with the right prompt, I am almost certain that an LLM would've written a better spec than MCP. Like others said, there are many protocols that can be used as inspiration for what MCP tries to achieve, so LLMs should "know" how it should be done... which is definitely NOT by using SSE and a freaking separate "write" endpoint.
That's LLM in a nutshell though. A naive prompt + taking the first output = high probability of garbage. A thoughtful prompt informed by subject matter expertise + evaluating, considering, and iterating on output = better than human-alone.
But the pre-knowledge and creative curation are key components of reliable utility.
Or like the early Python ecosystem, mistakes will become ossified at the bottom layers of the stack, as people rapidly build higher level tools that depend on them.
Except unlike early Python, the AI ecosystem community has no excuse, BECAUSE THERE ARE ALREADY HISTORICAL EXAMPLES OF THE EXACT MISTAKES THEY'RE MAKING.