TeamPuzel
TeamPuzel
PostsComments
MModular
Created by david on 10/2/2023 in #questions
Will Mojo solve the Expression Problem?
"zero cost" is sadly not even true for the most basic of things. You only move the cost elsewhere.
43 replies
MModular
Created by david on 10/2/2023 in #questions
Will Mojo solve the Expression Problem?
Not doing these things is a death sentence for a language if you want abstractions to have no (runtime) cost. Here's an example of a very naive rectangle drawing method from a software renderer I made: 
public func rectangle(x: Int, y: Int, w: Int, h: Int, color: Color = .white, fill: Bool = false) {
    for sx in 0..<w {
        for sy in 0..<h {
            if fill || sx + x == x || sx + x == x + w - 1 || sy + y == y || sy + y == y + h - 1 {
                self.pixel(x: sx + x, y: sy + y, color: color)
            }
        }
    }
}
public func rectangle(x: Int, y: Int, w: Int, h: Int, color: Color = .white, fill: Bool = false) {
    for sx in 0..<w {
        for sy in 0..<h {
            if fill || sx + x == x || sx + x == x + w - 1 || sy + y == y || sy + y == y + h - 1 {
                self.pixel(x: sx + x, y: sy + y, color: color)
            }
        }
    }
}
The "zero cost" abstraction here is the Range syntax, which constructs a range and then calls next() on the iterator in a loop. In release mode it's optimized away and no slower than a C style loop, but in debug mode this is too complex to inline. The cost of actually using the iterator in the most critical part of the program here takes this from lightning fast to literally a slideshow just clearing a 320x200 screen to black, not even drawing anything (on a very fast cpu). This is a great example of one the less obvious costs of "zero cost" abstractions. Suddenly I can't use debug mode for this program, the gap between optimization levels is significantly worse the more you rely on the compiler to optimize away abstractions. Release mode prevents incremental compilation on top of further increasing compile times, so you don't want to be using it all the time.
43 replies
MModular
Created by david on 10/2/2023 in #questions
Will Mojo solve the Expression Problem?
Most of that is actually done by the backend, like llvm, not programming languages
43 replies
MModular
Created by david on 10/2/2023 in #questions
Will Mojo solve the Expression Problem?
https://youtu.be/w0sz5WbS5AM?si=ommtb1DKbakC08yB This is an interesting talk about such compiler optimisations
43 replies
MModular
Created by david on 10/2/2023 in #questions
Will Mojo solve the Expression Problem?
There's no such thing as a more evaluation efficient expression in compiled languages, modern compilers optimize things to basically unrecognizeable state and will almost always make better decisions. If by some chance a certain way of writing an expression generates more efficient code it's luck and should not be relied upon.
43 replies
MModular
Created by david on 10/2/2023 in #questions
Will Mojo solve the Expression Problem?
Although lately it seems like rejecting abstraction is becoming a programming ideology in itself 🤣
43 replies
MModular
Created by david on 10/2/2023 in #questions
Will Mojo solve the Expression Problem?
While Casey's opinion on abstraction usually seems to go a bit too far, I do agree that conforming to arbitrary programming ideologies instead of just writing code is not very productive.
43 replies
MModular
Created by david on 10/2/2023 in #questions
Will Mojo solve the Expression Problem?
Personally I dislike the concept of "zero cost abstractions", as much as the Rust and C++ communities love to say it. You always pay for them in compile times, and even at runtime if you're unlucky and something isn't optimized away by the compiler.
43 replies
MModular
Created by david on 10/2/2023 in #questions
Will Mojo solve the Expression Problem?
The "internals" part seems to be about encapsulation. In object oriented programming, as it was originally intended in languages like Smalltalk, you're supposed to use messages exclusively and avoid anything that exposes internal state, that includes getters. The design was supposed to be completely detached from implementation.
43 replies
MModular
Created by david on 10/2/2023 in #questions
Will Mojo solve the Expression Problem?
Once you use protocols enough I think you will see that they are by definition in agreement with SOLID. Those principles exist because OO is hard to get right, even ignoring performance. 🙂 People make massive classes because most OO languages don’t support multiple inheritance. You are forced to choose one base class or use interfaces which are a lot less powerful than traits, often lacking default implementations, associated types, constraints etc.
43 replies
MModular
Created by david on 10/2/2023 in #questions
Will Mojo solve the Expression Problem?
Yeah, protocols are by definition very composable. You don't really need principles that try to fix OOP because it's not OOP in the first place. They are also not harmful to performance; everywhere in code where you use a non final class, it needs a lot of additional work to handle potential subclasses, always taking the indirection cost of vtables. Meanwhile some Shape (or Rust impl Shape) is just sugar for generics, it auto generates implementations for every type used, and allows llvm to inline and optimize each implementation individually 🙂 It's not perfect of course, but inherently a simpler and more hardware friendly idea.
43 replies
MModular
Created by david on 10/2/2023 in #questions
Will Mojo solve the Expression Problem?
And within the function you can only use Drawable functionality because you don't know the concrete type.
43 replies
MModular
Created by david on 10/2/2023 in #questions
Will Mojo solve the Expression Problem?
Yes if you had a protocol and added it to String like this: 
protocol Drawable {
    func draw()
}

extension String: Drawable {
    func draw() { ... }
}
protocol Drawable {
    func draw()
}

extension String: Drawable {
    func draw() { ... }
}
Then take this function: 
func doesSomething(drawable: some Drawable) { ... }
func doesSomething(drawable: some Drawable) { ... }
you would not be allowed to pass an Int to this function because Int does not implement Drawable.
43 replies
MModular
Created by david on 10/2/2023 in #questions
Will Mojo solve the Expression Problem?
There is no possible way to compile Swift code with a potentially invalid method call, unless you explicitly force downcast or use Any.
43 replies
MModular
Created by david on 10/2/2023 in #questions
Will Mojo solve the Expression Problem?
That is not true. When you erase type information and only have some Shape you can only call methods of the shape protocol, you can't call something Triangle has. Even if all shapes implemented a method as long as it's not in the protocol you can't use it.
43 replies
MModular
Created by david on 10/2/2023 in #questions
Will Mojo solve the Expression Problem?
enum Shape {
    case triangle(Triangle)
    case circle(Circle)
}
enum Shape {
    case triangle(Triangle)
    case circle(Circle)
}
In both Rust and Swift this would force you to handle all cases and lead to a compile error if you add more cases in all the places you have to fix it. This is how these languages implement the equivalent of haskell data Shape = Triangle | Circle, and likely how Mojo will implement it too.
43 replies
MModular
Created by david on 10/2/2023 in #questions
Will Mojo solve the Expression Problem?
Yes, that’s what enums will let you do
43 replies
MModular
Created by ct on 9/28/2023 in #questions
How can I create a Python list to add and remove structs?
This is an immutable list literal for constructing collections, not a list. You can see that the module does not contain an implementation, just the literal.
9 replies
MModular
Created by ct on 9/28/2023 in #questions
How can I create a Python list to add and remove structs?
From what I’ve heard traits will be supported around the end of this year, at least partially
9 replies
MModular
Created by ct on 9/28/2023 in #questions
How can I create a Python list to add and remove structs?
There won’t be a list in Mojo until it supports traits. Without them you can’t implement a type-safe heterogeneous collection, or even a homogeneous one with iteration, equality comparison etc
9 replies