4 ms·

Introducing Sugarless - A Functional & Context Oriented way to write JavaScript

42 points by laktek 15y ago

rektide 15y ago
Sugarless is apparently a toolkit for creating execution contexts bearing a strong resemblance to a run through a Chain of Command pattern.
shimsham 15y ago
syntactic saccharin?
- rektide 15y ago
  nay, execution context DSL.
mjijackson 15y ago
tl;dr: If you think that var output = Sugarless(input)( sanitize , trim , truncate, "", 200 ); is more readable than var output = truncate(trim(sanitize(input)), 200) than you may be interested in Sugarless. Call me old school, but I prefer the latter.
- switz 15y ago
  Yeah, that looks confusing as heck. Also, if I can't tell the difference between a comma and a period on your _improved language syntax_ homepage, then you're doing something wrong.
- seliopou 15y ago
  What about something like this: fn = compose(truncate.flip().curry(20), trim, sanitize); output = fn(input); Better or worse?
  - DougBTX 15y ago
    Better, since it is clear how to pass a function as an argument.
sipefree 15y ago
Looks like you can't pass a function as an argument to any of the functions in a Sugarless chain. Seems like a pretty glaring oversight to me.
- kbego 15y ago
  Sugarless is something difference from other libraries, I think we can pass any functions into the Sugarless chain as array. Seems this example explain how deal with functions as arguments in the Sugarless chain. https://github.com/laktek/SugarlessJS/blob/master/examples/client/todo_list.html https://github.com/laktek/SugarlessJS/blob/master/examples/c...
systemizer 15y ago
The idea using next() with asynchronous sounds interesting. With sugarless, you could create a state machine with functions as the nodes and next() calls as the transitions. I don't know if I would ever use this, but it is still an interesting idea.
- rektide 15y ago
  you can only descend further into your command stack, not transition upwards. you could make a state machine by modelling out transitions forwards, sure, but it'd be of limited length.
seliopou 15y ago
I mentioned this when stream.js was announced on hacker news a couple months back. I think that it's a good idea for JavaScript project pages to include the actual library in the page. That way, when I visit the project page, I can just pop open a console and start playing around with it, which is always my first instinct.
woogley 15y ago
In addition to not being easier to read at all (in my opinion), its complete dependence on the `arguments` object means your code will be less likely to be traced/compiled by the JIT.
Animus7 15y ago
The project that I'm working on has functional abstractions, contexts, and node-fibers flying all over the place. It gets hairy at times but (I claim) it's nonetheless workable precisely because I don't use libraries like Sugarless -- every abstraction is designed for its specific purpose. If input processing is complicated enough to have annoying syntax, it gets its own special-purpose class (if not a separate module) written in the language of the domain. Frankly there's probably several things that look like Sugarless in the codebase already. But I consider this a Good Thing: If I want to change the way operations distribute over an Input object, I can do it in an arbitrary, appropriate way. If I'm using someone else's convenience library, I'm limited to what the library author decided I should be able to do. This happens surprisingly often in my use case and more often than not it means going back to throw away the library in question, and reimplementing what I needed in the first place. This isn't actually a comment on Sugarless itself -- I haven't gone out and used it. But I'm quite jaded by all of the times I've had to deep dive into other people's 'convenient' JS library when it was subtly broken (or wasn't working as I'd like) to the point that I try to avoid them as best as I can.
NHQ 15y ago
I don't like to play contrarian when the room is full of them ;), but I was just reading some slides from a conference about understanding various costs in javascript and how to optimize, and it was put forth that contextualizing with call() and apply() are quite costly, more costly than one or two "upward" context traversals in search of e.g. the "self" variable you created to point to the top context (var self = this). And arguments look-ups can be costly as well. I can't find the damn slides or website now tho, sry.
mike_ivanov 15y ago
A better approach to it: http://documentcloud.github.com/underscore/#chain http://documentcloud.github.com/underscore/#chain var stooges = [{name : 'curly', age : 25}, {name : 'moe', age : 21}, {name : 'larry', age : 23}]; var youngest = _(stooges).chain() .sortBy(function(stooge){ return stooge.age; }) .map(function(stooge){ return stooge.name + ' is ' + stooge.age; }) .first() .value();

42 points by laktek 15y ago

Sugarless is apparently a toolkit for creating execution contexts bearing a strong resemblance to a run through a Chain of Command pattern.

shimsham 15y ago

syntactic saccharin?

rektide 15y ago
nay, execution context DSL.

mjijackson 15y ago

tl;dr: If you think that var output = Sugarless(input)( sanitize , trim , truncate, "", 200 ); is more readable than var output = truncate(trim(sanitize(input)), 200) than you may be interested in Sugarless. Call me old school, but I prefer the latter.

switz 15y ago
Yeah, that looks confusing as heck. Also, if I can't tell the difference between a comma and a period on your _improved language syntax_ homepage, then you're doing something wrong.
seliopou 15y ago
What about something like this: fn = compose(truncate.flip().curry(20), trim, sanitize); output = fn(input); Better or worse?
- DougBTX 15y ago
  Better, since it is clear how to pass a function as an argument.

sipefree 15y ago

Looks like you can't pass a function as an argument to any of the functions in a Sugarless chain. Seems like a pretty glaring oversight to me.

kbego 15y ago
Sugarless is something difference from other libraries, I think we can pass any functions into the Sugarless chain as array. Seems this example explain how deal with functions as arguments in the Sugarless chain. https://github.com/laktek/SugarlessJS/blob/master/examples/client/todo_list.html https://github.com/laktek/SugarlessJS/blob/master/examples/c...

systemizer 15y ago

The idea using next() with asynchronous sounds interesting. With sugarless, you could create a state machine with functions as the nodes and next() calls as the transitions. I don't know if I would ever use this, but it is still an interesting idea.

rektide 15y ago
you can only descend further into your command stack, not transition upwards. you could make a state machine by modelling out transitions forwards, sure, but it'd be of limited length.

seliopou 15y ago

I mentioned this when stream.js was announced on hacker news a couple months back. I think that it's a good idea for JavaScript project pages to include the actual library in the page. That way, when I visit the project page, I can just pop open a console and start playing around with it, which is always my first instinct.

woogley 15y ago

In addition to not being easier to read at all (in my opinion), its complete dependence on the `arguments` object means your code will be less likely to be traced/compiled by the JIT.

Animus7 15y ago

The project that I'm working on has functional abstractions, contexts, and node-fibers flying all over the place. It gets hairy at times but (I claim) it's nonetheless workable precisely because I don't use libraries like Sugarless -- every abstraction is designed for its specific purpose. If input processing is complicated enough to have annoying syntax, it gets its own special-purpose class (if not a separate module) written in the language of the domain. Frankly there's probably several things that look like Sugarless in the codebase already. But I consider this a Good Thing: If I want to change the way operations distribute over an Input object, I can do it in an arbitrary, appropriate way. If I'm using someone else's convenience library, I'm limited to what the library author decided I should be able to do. This happens surprisingly often in my use case and more often than not it means going back to throw away the library in question, and reimplementing what I needed in the first place. This isn't actually a comment on Sugarless itself -- I haven't gone out and used it. But I'm quite jaded by all of the times I've had to deep dive into other people's 'convenient' JS library when it was subtly broken (or wasn't working as I'd like) to the point that I try to avoid them as best as I can.

NHQ 15y ago

I don't like to play contrarian when the room is full of them ;), but I was just reading some slides from a conference about understanding various costs in javascript and how to optimize, and it was put forth that contextualizing with call() and apply() are quite costly, more costly than one or two "upward" context traversals in search of e.g. the "self" variable you created to point to the top context (var self = this). And arguments look-ups can be costly as well. I can't find the damn slides or website now tho, sry.

mike_ivanov 15y ago

A better approach to it: http://documentcloud.github.com/underscore/#chain http://documentcloud.github.com/underscore/#chain var stooges = [{name : 'curly', age : 25}, {name : 'moe', age : 21}, {name : 'larry', age : 23}]; var youngest = _(stooges).chain() .sortBy(function(stooge){ return stooge.age; }) .map(function(stooge){ return stooge.name + ' is ' + stooge.age; }) .first() .value();