4 ms·

Objective-C without the C is Smalltalk without the IDE. I don't see how that has any relation to Mojo which seems to be a compiled, lowish-level language on th

Objective-C without the C is Smalltalk without the IDE. I don't see how that has any relation to Mojo which seems to be a compiled, lowish-level language on the same vein as Rust/C++/Swift? Maybe because it has a Python "fallback"? I don't find Python particularly "smalltalky" beyond its dynamism.

andrekandre 3y ago
i think the idea is, that with objective-c, the substrate was always c with the objects (connection language) being the objective (smalltalkish) part if you took the c out of objective-c you basically have smalltalk but you still might need c-ish level expressions to get better performance the expectation from swift then, was that you'd start out with that high-level paradigm and then provide lower level constructs only when needed for performance or other reasons, but the reality is you start off closer to a really well-designed and clean c++ (structs, classes, enums, generics) that adds higher level features (actors, async, etc) when you need it than something that starts off high-level as smalltalk or python from the get-go the reason the author likes mojo more in that respect then is because it starts with the high-level constructs (python) as the substrate and allows for tuning where needed... the presupposition i think is that will lead to higher productivity and simpler code in the long run (this is my interpretation)
- sirwhinesalot 3y ago
  Much as I would have preferred Swift to have been "Objective-C the good parts", my reasons for wanting that are totally unrelated to the idea pushed in the blog post. Python isn't any more expressive than a language like C# once you remove the Java-inspired cruft. C# lets you go all the way down to the metal with pointers and what not if need be and supports fully dynamic types with "dynamic" and the underlying "Dynamic Language Runtime", but at no point does it feel like two separate languages glued together the same way Objective-C did, or now Mojo. People have written a Nintendo Switch emulator in C# ffs. Python's higher productivity is entirely thanks to its libraries (including the standard library). The dynamism isn't really key to it, heck, @dataclasses expect you to annotate the field types even though they aren't used because of a syntax quirk! Mojo is based around Python to piggyback on Python's ecosystem the same way Objective-C and C++ piggybacked on C. It has nothing to do with a "scripting" language vs a "component" language. Lua has a much nicer interface for scripting C than Python does, not requiring manual reference counting for one, to the point the original Torch (before it became PyTorch) used it. It didn't matter in the face of Python's ecosystem.

andrekandre 3y ago

i think the idea is, that with objective-c, the substrate was always c with the objects (connection language) being the objective (smalltalkish) part if you took the c out of objective-c you basically have smalltalk but you still might need c-ish level expressions to get better performance the expectation from swift then, was that you'd start out with that high-level paradigm and then provide lower level constructs only when needed for performance or other reasons, but the reality is you start off closer to a really well-designed and clean c++ (structs, classes, enums, generics) that adds higher level features (actors, async, etc) when you need it than something that starts off high-level as smalltalk or python from the get-go the reason the author likes mojo more in that respect then is because it starts with the high-level constructs (python) as the substrate and allows for tuning where needed... the presupposition i think is that will lead to higher productivity and simpler code in the long run (this is my interpretation)

sirwhinesalot 3y ago
Much as I would have preferred Swift to have been "Objective-C the good parts", my reasons for wanting that are totally unrelated to the idea pushed in the blog post. Python isn't any more expressive than a language like C# once you remove the Java-inspired cruft. C# lets you go all the way down to the metal with pointers and what not if need be and supports fully dynamic types with "dynamic" and the underlying "Dynamic Language Runtime", but at no point does it feel like two separate languages glued together the same way Objective-C did, or now Mojo. People have written a Nintendo Switch emulator in C# ffs. Python's higher productivity is entirely thanks to its libraries (including the standard library). The dynamism isn't really key to it, heck, @dataclasses expect you to annotate the field types even though they aren't used because of a syntax quirk! Mojo is based around Python to piggyback on Python's ecosystem the same way Objective-C and C++ piggybacked on C. It has nothing to do with a "scripting" language vs a "component" language. Lua has a much nicer interface for scripting C than Python does, not requiring manual reference counting for one, to the point the original Torch (before it became PyTorch) used it. It didn't matter in the face of Python's ecosystem.