Y
HN Search
Hacker News Search
new
|
comments
|
top
|
jobs
showell30
searching Neon…
1.
▲
2.
▲
3.
▲
4.
▲
5.
▲
6.
▲
9 ms
·
1.
▲
by
showell30
9y ago
I'm one of the original developers of Zulip. The long comment I'm replying to is a somewhat rant-y critique of Zulip, but it's basically valid. We honestly have a hard time communicating the stream/topic paradigm, even
2.
▲
by
showell30
14y ago
It's an interesting idea. My assumption is that stronger JS engines already do a good job of optimizing simply-written JS, whether the JS is hand written or produced by a transcompiler. Transcompilers that were target-specific could probab
3.
▲
by
showell30
14y ago
I'm personally in favor of leaving JS mostly alone, especially at the syntax layer, and then let transcompiler solutions like CoffeeScript evolve to relieve the syntax burden and add semantic improvements. CoffeeScript is far from perfect--
4.
▲
by
showell30
15y ago
The tool obviously works best with a fairly wide browser window, but patches are more than welcome to improve the CSS, which is obviously kind of primitive. For simple stuff, filing an issue would be great--no need for a full-blown pull re
5.
▲
by
showell30
15y ago
Yup, there is some support for editor integration, although it's still up to you to actually glue it into your editor of choice. See the issue below for more discussion. https://github.com/showell/CoffeeScriptLineMatcher/issues/13
6.
▲
by
showell30
15y ago
I agree with you that are some skeptics who will continue to move the goalposts. I also think that the tool itself won't change any minds. My hope is that it can help early adopters get over the initial debugging barrier, which, despite th
7.
▲
by
showell30
15y ago
I also think that lack of line-number mappings is a fair criticism of coffeescript. If the article is rejecting FUD, then it should target statements like "debugging is a nightmare." I agree with the author's overall point that you can usu
8.
▲
by
showell30
15y ago
This is Rob Pike's take on FUD toward new programming languages: http://commandcenter.blogspot.com/2011/12/esmereldas-imagina...
9.
▲
by
showell30
15y ago
CoffeeScriptLineMatcher lets you see CoffeeScript/JavaScript code side by side. It's mostly geared toward debugging, but it also helps you examine the transformations made by the CS transcompiler.
10.
▲
CoffeeScriptLineMatcher
(github.com)
15 points
by
showell30
15y ago
|
9 comments
11.
▲
by
showell30
15y ago
I hope you change your mind about visiting the US, and the Silicon Valley in particular. If you're concerned about your safety or enjoyment while you're here, that's fine, but I wouldn't boycott the US to make a political statement. The s
12.
▲
by
showell30
15y ago
I agree that matching up line numbers is usually pretty trivial, although I also see how this complicates the workflow for people. To make matching lines even easier, I've written this tool: https://github.com/showell/CoffeeScriptLineMatc
13.
▲
Source mapping tool for coffeescript
(youtube.com)
2 points
by
showell30
15y ago
|
0 comments
14.
▲
by
showell30
15y ago
Ok, I'll dial back the snark and just be blunt. I think all your concerns about CoffeeScript are hypothetical exaggerations. I don't think you've written much CoffeeScript at all, and I suspect that if you did, you'd quickly see that your
15.
▲
by
showell30
15y ago
barrkel, I think you should create a new programming language with more sensible scoping than CoffeeScript, so that developers can create bug-free code while working in parallel on thousand-line codebases without close reviews. I would sta
16.
▲
How Scoping Works in CoffeeScript
(gist.github.com)
1 points
by
showell30
15y ago
|
0 comments
17.
▲
by
showell30
15y ago
Your example does demonstrate how CS works. When you assign bar a new value inside its original scope, the value of bar does indeed change. bar = -> "I called bar!" foo = -> console.log bar() bar = "I manually as
18.
▲
by
showell30
15y ago
When I said the two programs have the same behavior, I was simply referring to the end result--what they output. I understand how both languages work here. Ruby solves a problem that simply doesn't exist in CS. In JS/CS "bar" never impli
19.
▲
by
showell30
15y ago
Well, this is a case where the equivalent CS behaves exactly like Ruby. class Foo bar: -> 'bar' baz: -> bar = "foo" console.log bar bang: -> console.log @bar() foo = new Foo() foo.baz() #
20.
▲
by
showell30
15y ago
There is some discussion here on why a "bar" variable at top level only affects the scoping of other "bar" variables that are lexically below "bar" in the file, not above it. https://github.com/jashkenas/coffee-script/issues/1121
21.
▲
by
showell30
15y ago
The problem with mandatory conventions is that they represent a different kind of user hostility--you're not trusting the developer to make his own decisions about variable names. To give an example, many CoffeeScript programmers do follow
22.
▲
by
showell30
15y ago
You are correct about "last", "start's, etc., but there are also good examples in the CS sourcecode of easily avoiding naming conflicts with a sensible naming convention: browser.coffee:CoffeeScript = require './coffee-script' coffee-
23.
▲
by
showell30
15y ago
These links explain the thought process behind CS's current behavior: https://github.com/jashkenas/coffee-script/issues/712#issuec... https://github.com/jashkenas/coffee-script/issues/712#issuec...
24.
▲
by
showell30
15y ago
It's a serious suggestion. Instead of introducing four top-level variables (log, sin, cos, and tan), just introduce one (Math) that wouldn't possibly conflict with a local.
25.
▲
by
showell30
15y ago
I wish that you would allow comments on your blog, so that folks following your twitter link would be able to see both sides of the issue, but I obviously understand your spam issues, which is why I said "wish" and not "should". I wish that
26.
▲
by
showell30
15y ago
Just to be completely clear, variables are only at top level scope if you declare them at top-level scope. The variables "x" below are completely encapsulated within f1 and f2. The variables at top-level scope are intentional in the code
27.
▲
by
showell30
15y ago
You are correct that variable scoping goes all the way to the top, but nobody is forcing you to create top-level variables with overloaded names like "log". Seriously, if you have a file that uses log files and logarithms, just take some c
28.
▲
by
showell30
15y ago
In fairness, Armin (the author the blog post) did engage Jeremy (the author of coffeescript) on this issue over twitter. I wish that he would allow comments on his blog. I also wish that he could engage the broader CS community in a prope
29.
▲
by
showell30
15y ago
FWIW this is how CS works: top_level_variable = null f = -> top_level_variable = "hello" f() console.log top_level_variable # prints hello
30.
▲
by
showell30
15y ago
Well, fine, but Python2 had the inverse problem--you couldn't mutate top-level variables without awkward "global" statements.
More ›