Mailing List Archive
tlug.jp Mailing List tlug archive tlug Mailing List Archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]Re: [tlug] Alternatives to sed + awk
- Date: Thu, 10 Mar 2011 02:04:10 +0900
- From: "Stephen J. Turnbull" <stephen@example.com>
- Subject: Re: [tlug] Alternatives to sed + awk
- References: <AANLkTim_-D9CFYC8TNp33ni85zB+QBA7jV=BpLN=4SbZ@example.com> <4D6F8D94.9040109@example.com> <87ei6nl906.fsf@example.com> <AANLkTimk1z41fSvQQmU+7fE-1Krd_kuo3_z-1SYD5rW6@example.com> <87ipvskik1.fsf@example.com> <AANLkTi=_6DoBt+xfQVOwM6KyKrxxgA_Ec9bhp751f15y@example.com>
Josh Glover writes: > > [I]t's not clear what "powerful" means. > > To me, "powerful" means "expressive, I guess that's reasonably close to what I'd expect a usable definition to be, but then, I'd just say "expressive" in the first place. :-) > and gets out of my way when I want to be a little naughty", e.g. > > class String > def bar; reverse end > end > > my_string = 'foo' > my_string.instance_eval { def baz; reverse } > > puts 'Ruby is insane' if foo.bar.baz == foo I think that's actually more ugly than naughty. It's potentially useful to monkey-patch a base class like that if you need to change the behavior of objects you don't "own", but it makes for really unreadable code -- you have no idea what promises might be kept any more. So *that* kind of "power" *subtracts* from expressiveness. I'm not sure it's worth it (but then I don't write code working with objects where I can't change their classes directly if need be). Adding methods to instances seems philosophically pointless. Possession of a method says "this object is an instance of a class that provides a set of methods". If you want to provide an operation on an instance, it seems to me that you either want to systematically create more similar instances, in which case you should subclass (or monkey-patch the class), or you don't, in which case use an ordinary function. > http://www.pragprog.com/magazines/2011-03/punk-rock-languages Interesting. Except Emacs isn't written in C, it's written in Lisp -- and the amount of Lisp that is written in Lisp, not C, increases in every version. I would suspect that neither is FireFox written in C++, not at the level that most of the add-ons target. In fact, Emacs is a really interesting example, since (with the exception of CSS and browser-quality redisplay in general) it provides all of the apps you would expect on the desktop, except games. And in many cases it arguably provides better UI (unless your definition of "intuitive UI" is "like Microsoft"), usually without perceptible performance cost. (This isn't a claim that Emacs is suitable for the mass market; it's not, because Emacs programmers are not willing to put in the effort required to sand off all the rough edges, cf the comment about CSS. It's a claim that for most desktop apps, a very slow interpreted language is performant enough.) A couple of random comments. The section "Institutionalized" was completely unpersuasive. Those descriptions fit Python, Common Lisp, TeX, and Scheme (and I would assume Ruby and Perl, especially Perl) as well as C or Ecmascript. The comment that Graham doesn't mention C is on target, but that's not surprising. He doesn't mention assembler, either. These aren't languages in the sense that Graham means. It's not really obvious to me that any of the programs that Adamson mentions are actually written in C, anyway. They're written in "Xt" or "GTK+" or "wxWidgets" or whatever. The syntax is mostly C (but not entirely, nonsyntactic macros are not unusual), but that's like saying the kanji of Japanese are based on the same radicals and components and written with the same stroke order as Chinese hanzi. These programs show a higher-level syntax that expresses what they're really doing. This is especially true of Lisp, where pretty much every large program is written in a language which shares the very basic "an expression is a list starting with a function and followed by expressions" syntax, but most expressions are functions with very specific requirements on the arguments, thus looking a lot like syntax. > As does Paul Graham: > > http://www.paulgraham.com/hundred.html avg.html is probably more to the point. :-)
- Follow-Ups:
- Re: [tlug] Alternatives to sed + awk
- From: Josh Glover
- References:
- [tlug] Alternatives to sed + awk
- From: Nguyen Vu Hung
- Re: [tlug] Alternatives to sed + awk
- From: Alexander Danilov
- Re: [tlug] Alternatives to sed + awk
- From: Stephen J. Turnbull
- Re: [tlug] Alternatives to sed + awk
- From: Alexander Danilov
- Re: [tlug] Alternatives to sed + awk
- From: Stephen J. Turnbull
- Re: [tlug] Alternatives to sed + awk
- From: Josh Glover
Home | Main Index | Thread Index
- Prev by Date: Re: [tlug] Alternatives to sed + awk
- Next by Date: Re: [tlug] Alternatives to sed + awk
- Previous by thread: Re: [tlug] Alternatives to sed + awk
- Next by thread: Re: [tlug] Alternatives to sed + awk
- Index(es):
Home Page Mailing List Linux and Japan TLUG Members Links