Go Replace - simple and fast search and replace tool for command line • Hacker News Board

Re: Go Replace - simple and fast search and replace tool for command line

#61

Post by piranha » Thu, May 23, 2013, 5:09 AM UTC

artagnon wrote: post #59

agentultra wrote: post #55

Earlier quoted context omitted.

C isn't any more difficult to understand, IMO. Obviously Go has the advantage of hindsight and an opportunity to go back on the trade-offs that were made for compiler efficiency before C was standardized. However, at it's core I think C is much more simple than Go and theoretically should be easier to understand. I find GC to be a useful tool but have you ever looked into the implementation of one? Or have you run in…

I would argue that C is probably the easiest language to understand, if you know the basics of hardware. C is essentially portable assembly. The C standard is tiny, and the behaviors are very clearly defined. The challenge is not in understanding the language, but rather in honing the engineering discipline required to use it to write real-world programs. It lacks a garbage collector because there was no concept of g…

> Writing something like Jekyll in C would be an absolute pain in the arse, and totally not worth it.

Well, here you go: https://github.com/piranha/gostatic

Wasn't pain in the ass, wasn't hard, works so much faster than Jekyll (or my previous engine, cyrax, which was in Python), that it's even funny.

Re: Go Replace - simple and fast search and replace tool for command line

#62

Post by piranha » Thu, May 23, 2013, 5:12 AM UTC

piranha wrote: post #17

lazyjones wrote: post #16

Nice! svn support would be useful (ignore .svn directories) and the -r option is easy to remember, but perhaps not so much in line with the already messy standard Unix options (-r or -R for recursive operation). Note that specifically for Go source code, there is "go fix -r" for syntax/context-aware code replacement (see "godoc fix").

In case of go fix `-r` does something absolutely unrelated. To be honest, I was just lazy inventing a command line key and it's recursive by design, so it happened this way. Plus, as you say, it's easy to remember because of mnemonics. I haven't touched svn repos in years, but yeah, that could be added. I know they exist, it just that I haven't felt the need to support them.

Btw, it ignores .svn and a bit more common stuff if it doesn't find itself in a git or hg repo.

Re: Go Replace - simple and fast search and replace tool for command line

#63

Post by piranha » Thu, May 23, 2013, 5:13 AM UTC

zokier wrote: post #20

what's the rationale behind 'gr foo -r bar' instead of simply 'gr foo bar'?

Just happened so, plus if you forgot to put quotes around argument you could easily end up with a lot of problems. :)

Re: Go Replace - simple and fast search and replace tool for command line

#64

Post by gngeal » Fri, May 24, 2013, 3:07 PM UTC

artagnon wrote: post #41

Intermernet wrote: post #34

Earlier quoted context omitted.

Your last paragraph contains some spurious statements: "proudly declares that it will not use any modern advances to compiler technology" Where? I've read most of the available documentation, blog-posts etc. and have yet to come across a statement even vaguely resembling this. "what the final program looks like is secondary concern" Have you read about "go fmt"? The entire idea of it is to format the code to a standa…

> proudly declares that it will not use any modern advances to compiler technology My apologies: this is an opinion, rather than an explicit declaration from the project. Their compiler "gc" starts with a traditional recursive descent parser using bison, and chose not to use llvm. Although one can argue that llvm doesn't provide enough information to implement a great jit, all aot compilers are moving towards using i…

Although one can argue that llvm doesn't provide enough information to implement a great jit, all aot compilers are moving towards using it.

Actually, all serious Common Lisp implementations, for example, do incremental AOT compilation these days, and none of them is ever going to "move towards using LLVM". In the broader landscape of programming language implementations, as far as IR generality is concerned, LLVM is actually not significantly better than Java bytecode, and for many languages, trying to use it would probably generate more problems than actually using it would solve.