jkaptur

43 ms·

481.
by jkaptur 11y ago
I used to be in a very similar situation, but I was convinced otherwise by this article [1]. The fact of the matter is that, yes, it's easy to become familiar with a variety of programming languages, but I think you actually learn a lo
482.
by jkaptur 11y ago
Maybe it was the article's reprinting of that rant, in its entirety, with a link to the actual file in github.
483.
by jkaptur 11y ago
I've developed a tool ( http://diff.so ) that might be a good fit for your LaTeX diffing problem. It's pretty buggy and slow right now, but I'd be interested in your thoughts.
484.
by jkaptur 11y ago
Very much like Crystal Ball - an Excel add-on that's popular in the finance and energy fields.
485.
by jkaptur 11y ago
Using the author's standards, adding features to a language is always a good idea. > All well-written code is easy to read, and most poorly-written code is hard to read. Obviously Go can't change that. I completely disagree. La
486.
by jkaptur 11y ago
Yes, it is quite normal in companies with good code-review policies. I review code, not its author. As far as writing functioning code without understanding scope and closure, a lot of JavaScript is written in a way that just doesn't r
487.
by jkaptur 11y ago
Honestly, I think "a daily drumbeat about how bloated, how needlessly complex, how ridiculous most of the world's web applications really are" pretty much describes every HN conversation on any article with even a remote conn
488.
by jkaptur 11y ago
Oh cool! I'm glad to hear it. Let me know if there's any way I can make it better for you (although, like I said, it's a thing on the side).
489.
by jkaptur 11y ago
I don't think I followed any of these for my side project (www.diff.so) because, well, it's a side project! It's a prototype, something I did for fun. This is a great list of things to do before I expect someone to use it ser
490.
by jkaptur 11y ago
Under "Threats to Validity" the authors note that "some" of the code studied is generated, and that they tried to deobfuscate this code so they could understand it. I think this understates the danger to their results. I
491.
by jkaptur 11y ago
I appreciate that you're tired of writing the same comment over and over, but I'd really appreciate your going into some depth about what "this" is that you're referring to and how it contrasts with your approach. I
492.
by jkaptur 11y ago
This is almost exactly the template that I apply to my own interviewing. However, I switched away from asking about a project on the candidate's resume because I found that that question - specifically meant to put people at ease - did
493.
by jkaptur 11y ago
I really like both Firefox and Pocket, but I can't imagine a good reason for them to be integrated at this level. I searched for what justification has been offered and found [1]. I'd love to read something more informative and co
494.
by jkaptur 11y ago
The incredibly interesting thing about this example is that it sounds like the design actually had to change in two ways: 1) the value had to be configurable and 2) it had to be configurable on the fly. Anticipating and designing for (1) is
495.
by jkaptur 12y ago
"Users can then link their work and personal accounts together so that they are logged into both at the same time." Wow, that's really different from what I expected.
496.
by jkaptur 12y ago
I like this pattern a lot. On a recent project, I used it almost exactly, but with a richer model of 'error'. Even though it was just basic form validation, I thought it led to very clean code.
497.
by jkaptur 12y ago
Thanks for the feedback! You're exactly right, tokenizing at the letter level is pretty rough.
498.
by jkaptur 12y ago
Very cool! I love tools that provide better UX around diff - that show not just the shortest possible edit script, but a more human-readable output of what has actually changed. I've been prototyping some ideas in a web app: http:&#x2