4 ms·
> 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
by ethbr1 1y ago
> 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.
- volemo 1y agoCould you throw on a couple of examples of calcified early mistakes of Python? GIL is/was one, I presume?
- Doxin 1y agoPossibly packaging too? though lately that has improved to the point where I'd not really consider it ossified at all.
- fullstackchris 1y ago> early mistakes of Python? Python.
- achierius 1y agoCPython 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.
- Timwi 1y agoStatic functions (len, map/filter,...) that should have been methods on objects.
- azeirah 1y agoThis one frustrates me so, so much.
- aerhardt 1y agoWhat’s the root cause? It certainly makes functional semantics in Python suck. Comprehensions don’t make up for it.
- int_19h 1y agoHow so, given that those are also free-standing functions in most languages that are considered purely or mostly functional? (e.g. ML, Haskell)
- volemo 1y agoI 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.
- int_19h 1y agomap() 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.
- worldsayshi 1y agoI 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.
- FridgeSeal 1y agoHey 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. /s
- brabel 1y agoYou 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.
- ethbr1 1y ago> with the right prompt 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.