ivy⇒blog

• Ivy
• Projects
• Notes
• Blog

Trackbacks

Aucun trackback.

Pour faire un trackback sur ce billet : http://www.ivy.fr/blog/tb.php?id=95

Commentaires

1. Le lundi 9 mars 2009 à 09:20, par éric

So would you say that the main driver behind writing this new language is because:
1- you don't *quite* like any of the other languages, in terms of syntax, so you want to be able to write programs with the syntax you like - a syntax you can keep tweaking as you see fit, and
2- you were finding that having written something in one language, you had to rewrite it in other languages sometimes
?

Also, you say in slide 12 that you can reuse language-specific types and libs, but then doesn't a given program become tied to being parsed TO a specific language? Like how you might use Sugar to use jQuery - you can't then translate that to python. My hunch is that in any given program, you'll be doing some of that. So, unless you were to create a standard lib in Sugar (so that a given api is always available), that totally defeats the purpose of 2- above, leaving only 1-, right? Which isn't to say it's bad, of course.

Finally, you obviously use it so that you can make it parse precisely the syntax you like, and you "sell" it that way as well... but it only makes sense that others would use it simply so they can also tailor it to the syntax they want (e.g., i hate how you use spaces instead of dots!)... and if that's the case, then sure more people use "Sugar the syntax translator", but not "Sugar the language" - it becomes impossible to send each other code... isn't that much worse than just putting up with some idiosyncracies of one of the current languages???

2. Le lundi 9 mars 2009 à 11:03, par Sébastien Pierre

Hi Eric,

Thanks for the comment. The main driver behind Sugar was actually experimenting with programming language design (for me) and creating an environment that would allow to abstract the syntax of a given set of programming languages (for the client who founded the initial Sugar -- called SweetC at that time).

That said, I tried to reach two ideal goals in writing Sugar:

• Be able to program in my syntax of choice
• Be able to re-use code throught projects running on various platform/languages

You're right when you point out that a program becomes tied to a specific platform as soon as you use the platform-specific libs (like jQuery on JavaScript). It turns out that in practice (from my experience) much of the code I write is manipulating generic data structures, and that only a thin layer requires usage of platform-specific libs (jQuery, POSIX, etc).

One practical example of this is using Sugar to create data visualizations that work on Flash, HTML Canvas and on the desktop. With Flash you have a native drawing API, with HTML Canvas you have another drawing API and then with Cairo you have yet another one -- but they are very similar, so all it takes is writing a thin abstraction layer and you're ready to go.

Now, regarding Sugar as a programming language (putting the meta-programming aside), I believe it is a good replacement to JavaScript and that it saves developers time and efforts -- which was verified in practice. You may not like the syntax (or some aspects of it), but so far I had no complaints (it's actually quite the opposite) from people using it on a regular basis.

Eventually, in the case of people modifying Sugar syntax, you can exchange code without too much trouble as far as the people provide you the front-end plugins for their custom syntax -- or you can simply serialize and import the resulting program object model, and re-translate it to your specific syntax. There is an alpha Sugar back-end so that any code parsed by a front-end plugin can be re-expressed as Sugar source code.

One of the points I wanted to make, which is a departure from the common idea, is that the program is not the source code, the program is a structure described by the source code -- it's a paradigm shift that opens new perspectives, and the first one is that you separate syntax from semantics in a language

I don't think everybody should use "Sugar the syntax translator": as you underline it having too many syntaxes would make things difficult for long term collaborative work. However, Sugar offers a lot of opportunities for customizing the syntax and writing DSLs (Domain-Specific Languages). At this point it is an organizational problem: people using Sugar (actually LambdaFactory) as a meta-programming framework to design their own DSL would have to make sure they settle on a policy for adding new syntaxes.

Overall, you've expressed interesting concerns, but in the end they are all related to organizational issues instead of technical or conceptual issues on Sugar/LambdaFactory -- Sugar/LambdaFactory offers an unprecedented level of freedom to software engineers, offering meta-programming, a framework for powerful source code analaysis, and the assurance that their investment in code is durable because they can access what the code actually describes (and re-express it as necessary).

As a language, Sugar offers you a clear, readable syntax (that you may not like) that was actually designed from the ground up (everthing was thought carefully and has a reason) -- this is quite an exception in the world of programming languages.

In the end, I can just encourage you to try it out for Web development as a replacement to JavaScript... you'll likely be happily surprised

3. Le lundi 9 mars 2009 à 15:21, par Damien

What I remember from my lost/forgot-to-click-publish comment…

Sly remarks from what I got out of the slides:
- You find Python consistent, but apparently not Lisp nor Smalltalk? Hmmmm :P
- Sugar is very much a Python-like language, except its closures are less broken (syntactically at least)
- Smalltalk doesn't have brackets around message sends, Objective-C does. And for a utilitary methods, that would be "self f: 1"

What I feel about the whole thing:
- One syntax to rule them all (slide 7)… meh, misguided dream IMHO. Syntaxes are not hard to learn, especially when they map well to the underlying semantics. If you hide several different semantics under one syntax, you're probably just creating confusion (unless your syntax is Lisp, in which case it doesn't exist anyway). Moreover, I don't see how you can abstract over different language-specific traits. Different languages have different semantics, that's the whole point. How would you abstract Smalltalk's resumable exceptions knowing that you want a Java backend too? Message sends do not even have the same semantics depending on the language.
- You have a point about the need to tweak syntax though, but I think the solution is more along the lines of Lisp macros or mood-oriented syntaxes (like if the regexp literals were user-defined)
- Another point is that it's tedious to work in several languages at the same time, e.g., JS callbacks in a web application. There it makes sense to restrict your main language so that you can write the callbacks in it and translate them during the build process into the equivalent JS expressions. But for full language interoperability I'd feel more at ease with bridges, aliens, or bytecode-level things.
- Slide 16, in Smalltalk:
|list|
list := 1 to: 9.
list first. "notice how that reads like your explanation comments?"
list last.
list copy.
list allButFirst. "or copyFrom:to: for the generic version…"
list allButLast. "… you can define your own anyway"
- Slide 19: structural resolution… sounds like breach of encapsulation, or of demeter's law
- why no keyword message syntax? it rocks, really!

4. Le lundi 9 mars 2009 à 17:26, par Sébastien Pierre

Hi Damien ! Thanks for posting the comment back

First, sorry for the Smalltalk/Objective-C confusion... and of course, keyword message syntax rocks (and is alpha in Sugar

Regarding your comment, I would not say that Sugar is "one syntax to rule them all" but rather "write once, use in many" -- I agree to some extent with the fact that different languages have different semantics, and also different syntaxes that are more suited to the semantics, but for a large extent of today's imperative scripting languages (PHP, JavaScript, Python, Ruby, Lua, etc) the differences (syntax put aside) are minor. Of course, some languages have more "features" than others (for instance, you have prototypes in JavaScript), but it essence they share a lot of semantics.

In practice, Sugar becomes really useful when you're in a situation when you code similar programs in JavaScript, ActionScript and Python (this is why Sugar translates to all these) -- these three languages have a lot in common, but also have differences which make porting a program from one to another quite painful. Using Sugar, I can write my program once, sometimes with target-specific code (in the same style as inline assembly for C), and use it to create programs that runs on these three platforms.

It's also important to notice that besides offering a single syntax for multiple platform, Sugar is a "white box", meaning that you can access the whole program and manipulate it as you like, making it trivial to do things like creating graphs of your program architecture or detecting dead code... it's not something that is particularly easy to do in most languages.

I think the real value of Sugar is LambdaFactory, the "programming transformation framework" for which Sugar is a front-end language. Sugar (the language) has proven to save me a lot of time and headache, and was quite a fun thing to design, but in the end it's just another syntax -- something that deeply depends on personal habits and preferences. I personally think that people doing JavaScript should use Sugar instead as it is less error-prone and helps focus on architecture, but it's still a personal opinion.

LambdaFactory, on the other hand, is something quite new (LLVM or the DLR are similar in many respects) that offers a whole new perspective on the way you program and manage your code base : program analysis, manipulation and translation becomes much easier. LambdaFactory gives you more freedom as your program becomes an object that you can manipulate and interact with... it lets you plug the syntax you prefer and translate your programs to your platform of choice. On the one hand you can experiment with new syntaxes (tailored to your domain), and on the other hand you can extend the semantics of your target platform by adding new language constructs (provided you can still translate them).

So far I've tried to advertise Sugar in my network or through reddit, but it hasn't really taken off. I don't think many people have actually tried it (even during last week's YulHackers' presentation) -- but I can't really tell the reason, or at least I did not hear about what's cool and what's not cool (which is, I must confess, a frustration).

I'm starting to think that I should try to separate LambdaFactory from Sugar when I present it, and "market" Sugar as a web front-end development language (to write ActionScript/JavaScript, just like haXe) and LambdaFactory as a programming language construction kit. This way it will probably be clearer for people, and they'll just say "oh, I like Sugar's syntax" or "no, I hate Sugar's syntax", and LambdaFactory will maybe interest people willing to experiment in programming language design.

Anyway, this was a long reply, but thanks for you're comment, it's a motivation to blog a little bit more often

5. Le lundi 9 mars 2009 à 18:16, par Damien

Hmm, thinking about it from a pure compilation POV, it doesn't sound so strange anymore. You just consider JS or Python as your runtime architecture, that's what Objective-J does after all, and it's OK as long as the generated code is not for human consumption.

But why invent a new syntax when there are perfectly fine existing ones? If you compiled your existing language of choice (with its semantics) using LambdaFactory, then you could reuse the existing tools. Currently, in Sugar, I suppose you're back to printf-debugging, ad-hoc tests, no refactorings (though they probably are rather easy to implement based on LambdaFactory…

<i> thanks for you're comment, it's a motivation to blog a little bit more often</i>
Yeeeees, I've been meaning to revive that dead link in your side bar too :D

PS. I managed to link that in my original comment, so please imagine some kind of vehement paragraph around it: modcplusplus.sourceforge....

6. Le lundi 9 mars 2009 à 18:35, par Sébastien Pierre

Objective-J or haXe are similar projects indeed, but one of the goals was to generate code that would like like hand-written code (it's really the case with the Python back-end, a little bit less for the JS and AS backend) -- it's actually a good thing because it makes Sugar transparent in a collaboration process, which is especially useful when your deliverables are JavaScript files which will be integrated by third parties.

Now about the syntax, it's simply that I find it much better than JavaScript, and slightly better than Python. Using Sugar as a replacement to Python would require you to really prefer Sugar's syntax, but switching from JavaScript to Sugar is something that makes sense if you also find it error-prone and not suitable for long-term application development.

The other reason for Sugar-the-language is just that's is really fun to experiment with syntax ! It was a delight to have a blank text editor and just type code in a language that wasn't existing yet but that I knew I could easily build. I was also an actual applied design exercise where I started by writing down design principles/goals and implemented them as a concrete syntax. Sugar syntax is personal in the sense that it's quite representative of the way I code (in Java, JavaScript, C or Python), and I've always taken a lot of attention to code presentation of readability -- so I tried to capture my "expertise and good practices" (I hope this does not sound presumptuous) in a syntax that would "incite" developers to code the same way. For the anecdote, I was using specific file headers in my code back at the university, which inspired my colleagues... and they still use the same headers now, and converted other people to use them -- I hope that maybe Sugar's syntax could have the same effect.

I don't event want to think about the comment you were going to make with such a link

Ajouter un commentaire

Nom ou pseudo :

Email (facultatif) :

Site Web (facultatif) :

Commentaire :

Captcha anti-spam :
dans le nombre "6917", quel chiffre vient avant neuf&nbsp;? (chiffres)

Le code HTML dans le commentaire sera affiché comme du texte, les adresses internet seront converties automatiquement.

Se souvenir de mes informations

© Ivy, 2004-2008, tous droits réservés - mentions légales.
XHTML + CSS, propulsé par DotClear