Live data from Hacker News

Bringing a decade old vector editor back to life

github.com

81–89 of 89 posts

Re: Bringing a decade old vector editor back to life

#82

I though it was FreeHand. Maybe someday

I hoped to hear someone finally ported Xara LX [1] to Cairo... [1] https://en.wikipedia.org/wiki/Xara_Xtreme_LX

Looking forward for this as well. I've used Xara Extreme version 4 (released around 2008) couple of years after they have released Xara Extreme LX, and I've still got the CD with me. It's probably the fastest and the most intuitive graphics editor I've used. It seamlessly managed to integrate raster and vector graphics editing for the masses.

Re: Bringing a decade old vector editor back to life

#83
post #73

Earlier quoted context omitted.

Cooperative multitasking usually involves a scheduler. Coroutines are called explicitly, which you can't do through a scheduler.

Now you're really just making claims about implementation details. That doesn't make one concept more "fundamental" or "flexible" than the other, while "interesting" is just a subjective judgement.

I'm not. The scheduler decides what code to execute next, the caller does not. With coroutines, the caller explicitly decides what code to execute next. That's a fundamental difference.

Re: Bringing a decade old vector editor back to life

#84

Earlier quoted context omitted.

Cooperative multitasking usually involves a scheduler. Coroutines are called explicitly, which you can't do through a scheduler.

With coroutines, your program logic itself is the scheduler.

Thus why coroutines are more fundamental and powerful.

Re: Bringing a decade old vector editor back to life

#85
post #73

Earlier quoted context omitted.

Now you're really just making claims about implementation details. That doesn't make one concept more "fundamental" or "flexible" than the other, while "interesting" is just a subjective judgement.

I'm not. The scheduler decides what code to execute next, the caller does not. With coroutines, the caller explicitly decides what code to execute next. That's a fundamental difference.

Explicitly selecting what code to execute next can be trivially achieved in a cooperative multitasking system. Naturally, the details work out differently. That's because both concepts are equivalent, just not the same.

Re: Bringing a decade old vector editor back to life

#86
post #85

Earlier quoted context omitted.

I'm not. The scheduler decides what code to execute next, the caller does not. With coroutines, the caller explicitly decides what code to execute next. That's a fundamental difference.

Explicitly selecting what code to execute next can be trivially achieved in a cooperative multitasking system. Naturally, the details work out differently. That's because both concepts are equivalent , just not the same .

Sure, you could implement some kind of anti-scheduler, but that is just plain silly, and really doesn't affect the point at all. You can do anything in any Turing-complete language, but that doesn't mean that Brainfuck is equivalent to Prolog in any way that is actually useful or interesting.

Re: Bringing a decade old vector editor back to life

#87
post #85

Earlier quoted context omitted.

Explicitly selecting what code to execute next can be trivially achieved in a cooperative multitasking system. Naturally, the details work out differently. That's because both concepts are equivalent , just not the same .

Sure, you could implement some kind of anti-scheduler, but that is just plain silly, and really doesn't affect the point at all. You can do anything in any Turing-complete language, but that doesn't mean that Brainfuck is equivalent to Prolog in any way that is actually useful or interesting.

That's like saying that implementing a scheduler using coroutines is silly. Yet people do it all the time. * You may keep moving the goal posts all you want, your original claims were wrong and they stay wrong.

Can't you just say something like "I like coroutines more, they are so minimalist and elegant, and yet they are equivalent in power to cooperative multitasking!". I'd actually subscribe to that notion. But not your overblown claims of objective superiority.

* One has to wonder why so many people crave a scheduler, when they already have coroutines? Maybe because having a scheduler makes certain things easier than naked coroutines?

Re: Bringing a decade old vector editor back to life

#88
post #87

Earlier quoted context omitted.

Sure, you could implement some kind of anti-scheduler, but that is just plain silly, and really doesn't affect the point at all. You can do anything in any Turing-complete language, but that doesn't mean that Brainfuck is equivalent to Prolog in any way that is actually useful or interesting.

That's like saying that implementing a scheduler using coroutines is silly. Yet people do it all the time. * You may keep moving the goal posts all you want, your original claims were wrong and they stay wrong. Can't you just say something like "I like coroutines more, they are so minimalist and elegant, and yet they are equivalent in power to cooperative multitasking!". I'd actually subscribe to that notion. But not…

It's not, that is a perfectly logical thing to do: Use a more generic primitive to implement more specific functionality.

It's not about liking one thing or another more. It's that coroutines are coroutines, and cooperative multitasking is cooperative multitasking. The two are often confused, and all I am saying is that that is incorrect.

Cooperative multitasking can easily be implemented with coroutines, but doesn't have to be. You could implement coroutines with cooperative multitasking but doing so is highly silly and a massive hack.

Re: Bringing a decade old vector editor back to life

#89
post #87

Earlier quoted context omitted.

That's like saying that implementing a scheduler using coroutines is silly. Yet people do it all the time. * You may keep moving the goal posts all you want, your original claims were wrong and they stay wrong. Can't you just say something like "I like coroutines more, they are so minimalist and elegant, and yet they are equivalent in power to cooperative multitasking!". I'd actually subscribe to that notion. But not…

It's not, that is a perfectly logical thing to do: Use a more generic primitive to implement more specific functionality. It's not about liking one thing or another more. It's that coroutines are coroutines, and cooperative multitasking is cooperative multitasking. The two are often confused, and all I am saying is that that is incorrect. Cooperative multitasking can easily be implemented with coroutines, but doesn't…

>The two are often confused, and all I am saying is that that is incorrect.

And both are equally capable is all I'm saying.

Well, I suppose we've come close enough then to move on.

Post reply on HN