Simple continuation explanation for web developers.
1. Write some JS code in chrome and verify expected behaviour.
2. Add a debugger statement.
3. When the debugger pops up, go down a few frames and add debug point.
4. Right click the frame and select restart.
5. In the new break point, write some code in the console to modify the state.
6. When you step through the code, it now does something else.
Now imagine if the language allow you to do this programmatically in the code by passing the frame around as an argument similar to functions.
You're misrepresenting your point 3. The article talks about the kind of cuts that paper tends to make, and how it exposes nerves to the world differently than deeper cuts.
Sometimes programmers need to look at unusual files: binary files, very big files, odd data files. Epsilon was designed without the limits of other editors, so it can handle these kinds of jobs, as well as ordinary files. For example, with Epsilon, lines can be as long as you like.
This text editor gets it. Such a contrast to some of the editors we have today where anything over a few megabytes is an edge case not worth fixing.
Really? I loaded a 1.2GB ISO in the demo and it used… 1.2GB of RAM. (At least it worked though, coughAtomcough.) And more importantly it has no unicode support whatsoever as far as I can tell (any non-ASCII characters I typed showed up as ?).
Wouldn't a hex editor be a better choice for binary files and odd data files? Are there benefits besides the ability to handle large files and long lines?
There was some people talking about this issue in the support forums and their response was to stick with v2 until they sort out the issues.
They recently made a change with the node sdk recently so you don't need the apiKey for public access.
Not sure about the web version, You would probably have to use the Browserify or something.
That said, If I were you, I would stick with V2 sdk since I don't think hacker news has actually updated yet.
An easier way is to just use the rest apis, That is still clearly working.
I'm not sure when promises came to the javascript, but it seems weird that people would settle with callback hell for so long without even attempting to refactoring it.
I mean if I didn't have the option of using promises, I would have probably written something like this.
That looks like a very similar pattern that I've seen commonly used in Go. It makes for very clear code and explicit error handling. I kind of like it for the clarity, even if it isn't "elegant" or concise.
