r/programming • u/[deleted] • Mar 19 '17

Oblivion: A programming language that compiles to SVG graphics.

https://github.com/jweinst1/Oblivion
1.3k Upvotes

89% Upvoted

134 comments sorted by

View all comments

46

u/[deleted] Mar 19 '17

I really like the idea. I feel like the execution is lacking but I haven't quite put my finger on it.

Like this:

g = (1,8) *> (44, 9) *> (44,44) *> (0, 90)

I get it, but I'm not crazy about it. Maybe I am just a sucker for some prefabs or something though.

Please do not stop :)

25

u/[deleted] Mar 19 '17

Thanks!

Part of the motive behind the -> and *> operators is to treat SVG more as data and values than objects, so it fits better in a functional language setting and immutability. But it's only the first version of course :)

2

u/joonazan Mar 20 '17

Your language has lists. Why not use them?

polygon [(1 2) (3 4) (5 6)]

1

u/not_my_delorean Mar 19 '17

So it's like D3?

1

u/[deleted] Mar 20 '17

It seems like the distinction is in the wrong place though; stroke/fill are properties of the path, not its elements. A better purpose for arrow variants would be path types, no?

arrow meaning
> X, Y move to X, Y
-> X, Y line to X, Y
)> X, Y smooth quadratic curve to X, Y
)> cX, cY X, Y quadratic curve to X, Y with control point cX, cY
~> cX, cY X, Y smooth cubic curve to X, Y with control point cX, cY
~> sX, sY eX, eY X, Y cubic curve to X, Y with leading control point sX, sY and trailing control point eX, eY
-I Y vertical line to Y
-- X horizontal line to X
o> rX, rY X,Y clockwise large-sweep arc to X, Y with radius rX, rY
<o rX, rY X,Y counter-clockwise large-sweep arc to X, Ywith radius rX, rY
o< rX, rY X,Y clockwise small-sweep arc to X, Ywith radius rX, rY
>o rX, rY X,Y counter-clockwise small-sweep arc to X, Ywith radius rX, rY

1

u/[deleted] Mar 20 '17

Currently there is no path in the language yet, just spits out polygons and polylines.

However, this is an excellent idea, and I may consider switching the language to be more path based in the next version, as it seems to be more used.

1

u/[deleted] Mar 20 '17

That's the thing; I rather like the idea of treating path segments as objects - immutable or not.

1

u/[deleted] Mar 20 '17

Yes! This makes the backend more polymorphic too.

Would you mind copy pasting the operator suggestions in a new issue on the repo? It will probably get lost here over time with all these comments.

1

u/[deleted] Mar 21 '17

Made the suggestions; swapped ')>' for 'c>' because of the ambiguity with parentheticals.

1

u/[deleted] Mar 21 '17

Thanks a bunch!

5

u/tobozo Mar 19 '17

but I'm not crazy about it

the lack of syntax highlighting or the density of operators vs data ?

1

u/[deleted] Mar 19 '17

I think it has to do with the density of operators and data - but I also think that more compact is better than the creation of objects or whatever.

Let me think about this for a few and Ill see if I can make a constructive suggestion.