Live data from Hacker News

What It's Like To Be Ridiculed For Open Sourcing A Project

harthur.wordpress.com

481–490 of 826 posts

Re: What It's Like To Be Ridiculed For Open Sourcing A Project

#481
post #277

Earlier quoted context omitted.

Honestly, I think you ended up really making the case for replace. The nix CLI examples are convoluted at best. I've used CLI tools for years, and it would probably take me 5-10 minutes of scanning the man pages to reproduce all but the simplest of those snippets. Granted, this boils down to the sporadic use-case, but that's the entire point. The replace examples are all clean. It would mean I would not be juggling l…

Then take the 5-10 minutes to scan the man pages. Write a simple shell script wrapper exposing a syntax as simple as "replace". And be done with it in 15 minutes top. It seems to me that writing all this js code would take a lot longer than 15 min.

Add another 30 minutes or so for learning how to write a shell script. I mean how to pass variables into a shell script and stuff like that. Actually no idea if 30 minutes are sufficient for learning how to write shell scripts (it can get pretty confusing with environment variables that are suddenly not available and what not).

Re: What It's Like To Be Ridiculed For Open Sourcing A Project

#483
post #298
post #277

Earlier quoted context omitted.

Then take the 5-10 minutes to scan the man pages. Write a simple shell script wrapper exposing a syntax as simple as "replace". And be done with it in 15 minutes top. It seems to me that writing all this js code would take a lot longer than 15 min.

I think the point everyone is trying to make here is. Should every person spend 5-10 minutes doing this? If the problem occurs too frequently, it makes more sense to make the solution re usable. Which is exactly what 'replace' is doing here.

The point everyone seems to be making is that there is no reason to do this in javascript if it's for command line use. Implementing it in js like this is just silly.

Re: What It's Like To Be Ridiculed For Open Sourcing A Project

#484
post #323

Earlier quoted context omitted.

both Perl and Python use PCRE No, Perl doesn't. PCRE was written because a lot of people liked some of the ideas that were first introduced in Perl's regular expression engine. But PCRE was a reimplementation, and never was all that compatible with what Perl was doing.

The funny thing is, that Python doesn't use PCRE either and never had.

True enough. It's not the first time I hear about PCRE and Python, so maybe it's a common misconception.

Other than "re", there's "re2" and "regex". None are PCRE but "regex" is close enough most of the time.

Re: What It's Like To Be Ridiculed For Open Sourcing A Project

#486
post #456

Earlier quoted context omitted.

This to me is very unfortunate. I'm an experienced Ruby and RubyOnRails developer, and I think that this is totally unacceptable. This is why the Python community flourishes (and I learned to code with Python!), and the Ruby community, which has unfortunately become equated to the Rails community, relatively languishes. I also think it's pretty funny/awful/ridiculous to see Rails devs hating on JS code. (JS is diffic…

#python is dominated by a toxic cabal as well, so that is unfortunate.

Seriously? I'm always on #python, and I find nothing but polite people there. :)

Re: What It's Like To Be Ridiculed For Open Sourcing A Project

#487
post #247
post #223

Earlier quoted context omitted.

She was able to simplify her command line interface in order to support only the features she needed, so of course her syntax is nicer. Whereas sed/find/xargs can do a lot more things, so of course they come with a more evolved syntax. It is the usual tradeoff between simplicity and features.

Yeah, who needs TextMate when you have vim, right? Or Ruby when you've got Perl?

I beg to differ on your first argument. Learning Vim was one of the best decisions I've ever made in terms of how I write code. Other editors feel like toys in comparison.

I'm siding with mrb on this one. Learning flexible tools gives you immense power in comparison to low-learning-curve ones. The time invested is considerably smaller than the time spent figuring out how to solve edge cases with simple tools. This is something which appears to be impossible to communicate to people with words. Learn some of these tools and you will see for yourself.

By 'learn' I do not mean, for example, becoming familiar with hjkl for navigation in Vim. I mean mastering the tools to the point that using them requires no effort - where just as you experience the impulse "I want a glass of water" and without any effort go to fetch one, you experience the impulse "I want to create a new class in file X, navigate to file Y then modify method Z", your fingers start moving and suddenly you're done. I get frustrated watching my IDE using co-workers write code - it takes them a very long time to do very simple things. Their tools are narrow and do not facilitate expression - they constrain it.

Pre-emptive strike on the argument that code completion is better - Eclim (Eclipse with a Vim frontend) solves this problem very well. Nonetheless, I have it installed and configured but can barely find a use for it.

Re: What It's Like To Be Ridiculed For Open Sourcing A Project

#488

Earlier quoted context omitted.

Fair point. Once I read the names of those involved, I was a little taken aback for this very reason. Friends I respect think quite highly of Corey, for instance. Also worth noting, both [Steve and Corey] have published apologies on their own blogs. Both are worth reading.

How nice of them. Makes you wonder how many apologies are outstanding.

To clarify - apologies to other people.

There's no such thing as accidental one-off snobbery.

Re: What It's Like To Be Ridiculed For Open Sourcing A Project

#489
Even if the tool wasn't as useful as the traditional tool users have liked, I think that the following was an interesting comment:

  I think that, at least hypothetically, this app won’t be 
  significantly faster written in C than in JavaScript. 
  It’s I/O bound, and in JS regular expressions get JITted
  to native code (which sed won’t even do!).

  The real slowdown here with our current JS 
  implementations will be overhead for creating and
  replacing-in strings. This app actually just gave me a 
  crazy idea for how we could optimize this kind of usage, 
  so I wanted to say thanks!
http://harthur.wordpress.com/2011/06/06/replace/#comment-776

Re: What It's Like To Be Ridiculed For Open Sourcing A Project

#490
post #284

Earlier quoted context omitted.

You have a valid point but its incomplete, allow me to explain you why we need projects like replace. You are right in telling that sewing a few utilities using pipes can emulate 'replace'. But remember you are talking about learning those 'few' utilities first. Trust me unless you have practiced your way out of these thing with hundreds of hours with experience over years its humanly impossible to remember and use a…

I have just publish a report on monday where I explain that the command line should be used instead of some small scripts that encapsulate for loops. The argument is that basic shell knowledge should be trained in order to not lose skill (or to improve). At my work, these skills are useful when facing unexpected urgent needs. Having a short script is a very poor benefit (simpler syntax and reduced key typing) for a b…

This is like saying you should learn C before using [some-lang] when all you want to do is cobble together a web page. Yes, it might be beneficial to some, but it's not absolutely required.

Some people just don't live in the shell. We're taught to build upon useful building blocks to make useful things - why would you not abstract away the monotonous tasks?

Post reply on HN