node webkit

https://github.com/rogerwang/node-webkit/

Discuss.

>>24
Fifteen seconds on the internet found me http://moreindirection.blogspot.com/2011/01/thoughts-on-nodejs.html , and I don't even like Mexican food.

>>19
Like I said, the ideal would be to have both non-blocking and threading. Node's non-blocking engine is the best there is, ever, and there is no way to do non-blocking without callbacks (maybe you could sugar it to hide the lambdas, though). A for loop is actually sugar for a callback, if you consider callback a instruction that is stored instead of executed immediately. So there you have it, there wouldn't be programming as we know it without callbacks, we'd all be programming in assembly. It can't be that it is only event callbacks that you don't like, because even haskell has events, and any language with events will have a event callback for each of them. Some of these languages use threads to schedule the events, node doesn't need to, but that doesn't change much in the syntax.
TLDR: if you're doing events without "callbacks" it is just some sugar, and if you complain that node doesn't have threads, you can always spawn many node processes and have them communicate.

>>22
Then you have trouble expressing yourself.

>>27
Loops aren't ``sugar'' for a callback.

I wish you people used language properly. As programmers you should know better.

>>26
yeah, that's not how you work with node, friend
to scale with node, you need to create new processes for every order of magnitude you increase. It can't do threads like it's been said, so it's obvious it'll have to lose eventually, if you have enough cores for a lot of threads and you test a single core program against a multi core one, even if it is non-blocking, with a sufficient size of requests the single core one will lose every single time.
Sorry for the basic cs lesson, I thought you weren't trolling.

>>28
you might not create a function object for the instructions, but you parse the instruction and store it somewhere, it could be done with a function object all the same (see scheme's hacked up for-loops), it is just such a common pattern that they decided to parse away the need for the lambda.

>>27
Way to miss the point. The blog posted by >>26-san contains a very striking line:

"I object to doing things computers can do" - and explicitly handling I/O responses certainly falls into the category of Things a Computer Should Do.

Arguing that everything is just callbacks under the hood actually suggests that this line, every single one of its implications and my entire point is correct. Doing callbacks manually when a clearer form of code can be translated to equally fast or even faster callbacks by the machine is comparable to writing everything with gotos in order to optimize loops and ifs because you think compilers produce slow code. Sure, they are gotos under the hood, but that doesn't mean we should use goto to emulate while.

This isn't progress, it's an incredible regression disguised as progress.

>>28

I wish you people used language properly.

Get with the times, man! ``Using language properly'' is for old fogeys and things like standards and specs. You should be more Agile.

>>27
Events aren't a language feature (except maybe in something like Esterel or GOLOG (see below)). They're a system or run-time (or even library or framework) feature.

You don't need callbacks to do ``events'', e.g. you can make an ``event'' framework using continuations, coroutines, streams etc. etc.

GOLOG did ``events'' (the situation calculus) declaratively.

>>29
You are very incoherent. I'm not sure if you understand that operating systems such as Linux will schedule multiple processes over multiple hardware threads of execution. The performance difference is that usually when people say multiple processes they mean multiple processes that don't share memory, whereas when they say threads they refer to threads in the one process which share methods (again, usually).

BTW what's with the influx of novices here?

>>33

...which share methods...

by ``methods'' I mean ``memory''.

>>33
Going off completely unresearched speculation, I'd say the pedorider thread on the old /prog/ was bumped and got some more exposure. It'd explain the amount of crossposting, too.

>>33
I suspect something a bit more sinister than >>35-san.

>>31
You can't create sugar for every single kind of callback.

>>33

continuations
storing the environment and execution point, to continue there later

yeah, a lot different from callbacks

multiple processes they mean multiple processes that don't share memory

a node server is lightweight (unless you're doing some pretty big simulation), the overhead would be minimal

>>38
also, you don't need that many node processes compared to threads because of the async performance

I'd wager that node with multiple processes is the single best way to explore multiple cores, or even a network of clusters

single best way known*

>>38-41
Could you please quote properly and stop making quadro posts in two minute intervals?

>>38
Yes, continuations are very different from callbacks. For example when I call a callback, a new frame is pushed onto the current execution stack. By contrast, when I call a continuation, the execution stack is swapped out for a different one.

You're using callback very generally, i.e. to mean calling procedures and passing procedures as arguments. Do you understand what this definition of callback entails? Do you understand why such a definition might be redunant and thus useless?

　.＿＿ I LOVE
ヽ|･∀･|ノ NOODLES
　|＿＿| DOT
　　|　| JIZZ

This thread looked like it may have had interesting content in it, but I have discovered it's just a train wreck of someone forcing node.jizz into a practical situation like one delivering a pet duck by savagely shoving it though some nasty pipes that it don't quite fit together and it comes out on the other side in many pieces and there's blood everywhere and the duck handler is panting furiously and reflecting upon the struggle and pondering if there is or is not a better way to accomplish the task of duck transportation and coming to the conclusion that further research into shoving ducks through jagged pipes is required and is the only way in which duck transportation will progress.

I LOVE JIZZ

http://taskjs.org/

Tasks are interleaved like threads, but they are cooperative rather than pre-emptive: they block on promises with yield.

node.JEWS

Is https://github.com/affiszervmention the node.jizz lover posting on this thread?

>>49
All signs point to yes.

>>49
Yes, see https://github.com/affiszervmention/permadeath/blob/master/about_me.md

>>43
I know the common definition, I was just pointing out that the basic principle is the same and there's no reason to prefer one over the other.
So continuations are more memory-efficient? Still that's no reason to completely disregard callbacks.

>>52
Continuations are different from callbacks, and rarely supported by languages due to the overhead they incur. Imagine you can you save a point of execution in your program, and then return to this point later. You may reinvoke the execution point many times. Each time you reinvoke it, you may pass back a different value each time.

It's like you are making a sandwich. You put the ingredients on. You put it together. You take it back to the couch and watch TV. Then you see a television commercial that shows a certain topping that you missed. But you've already started eating the sandwich. So you go back in time to when you were putting the sandwich together but this time you have that topping in mind. You continue making the sandwich again and sit and watch TV. But then another commercial has reminded you of a different topping that you forgot. So you return again to the prior point of execution with a new topping to make.

You can support execution that behaves like continuations, but it's cumbersome and uses tail calls and an emulated function call stack with a stack of linked functions. Oh and the post you are replying to, you can still have that effect if you do a tail call on the callback.

I don't like how these functions are being called 'callbacks', and also that something as fundamental as a 'callback' is being associated exclusively with something as retarded as node.jiss. This pattern is used all the time in almost all languages.

>>53
Is node.js retarded because of callbacks or are callbacks looking bad because of node.js? Please decide yourselves.
But I agree that callbacks are a pretty basic concept and not an exclusivity of node.
And I didn't know much about continuations, thanks for explaining it.

So, I think we all agree that Node.js is a good PLATFORM but yet using ECMAScript makes it useless?
What about those languages that compiles to javashit? like coffeescript, livescript, or lispyscript..

>>51

Javascript programmer (mainly, both browser and node) and crazy-about-it gamedev. (I'm the main guy defending javascript on /prog/)

OH SHIT IT'S THE ACTUAL JAVASHIT KIKE

>>55

So, I think we all agree

No, fuck off.

>>56
Yeah, it's me. Ask me anything.

>>58
Will you kindly leave and never come back?

>>58
How often do you go to the synagogue?

>>59
No, I need you guys' level of expertise for feedback on my ideas and projects. And I also find some of you guys' projects interesting (like DistBB for instance).

>>60
I'm an agnostic atheist. (And a libertarian bleeding heart.)