I think this article has convinced me that I should learn Perl. Looks bloody useful for shell scripts, indeed ("a better awk" is the phrasing I've heard).
687 karma · joined February 25, 2010
I'm pretty sure that's exactly what the author is suggesting. For example, notice things like,
"When I was a younger entrepreneur my answer would have been, “Ok. See if you can get us better terms. Call me when you’re done.” This time I said, “Make a list of the issues in bullet form, send them to me and I’ll get back to you.”"
My interpretation was that he is saying, "don't let your lawyer run your company strategy, that's your job", and this is fundamentally what you are saying as well (though with different focus).
No, but it guarantees that, at least in theory, such a parser could be made available. In practice many languages do make it available. Your argument was a general one, that is that all "traditional languages" have this property.
> Actually it does because there are very few "traditional languages" that even approach Python's in-language support for their own AST
It only takes one counterexample to break a general claim. "Very few" is enough. Nothing about traditional languages has any intrinsic property of being parser and AST-free-- it is merely laziness, minimalism, or coincidence that causes many to not. As examples like Python show, it is quite easy to find a mainstream "traditional language" with a full-blown (actually several full-blown) interfaces to the parser available. Other languages have this too, although examples are not incredibly widespread. Lua has implementations which provide an AST, and even the hyper-traditional language C# has the Expressions framework, which lets you parse/modify/etc. the AST of an expression (including, of course, the new lambdas).
It's just not true that Lisp is the only game in town for AST support, nor that "traditional languages" don't have it in general (although it may be true that most do not, this is not the same as claiming that as a group they do not).
I'm not sure how that's a contradiction. "unambiguously representing" is still representing.
> Why do I say that? Because very few people know the full precedence of expressions. So, they break expressions in unnecessary places and/or add redundant parentheses.
Interesting, but not really relevant. They prefer the syntax, knowing that there are things they don't know about it.
> And then there's the problem of manipulating said AST. To do so for a traditional language requires a parser and a bunch of datastructures, which every project reimplements. Everything that you need for lisp is built-in.
Er, I don't understand how you can make that claim. A parser is necessarily built in to any interpreter/compiler for language with syntax, whether that language be a lisp or an assembly language or Java. Some of them don't have the parsers available at all (e.g. C), but some do (e.g. Python), and for some the parser is irrelevant (Lisps, machine code) because the AST (or "AST" perhaps, in the case of machine code) is always directly available regardless of explicitly calling out to the parser. In any case, your claim does not hold for "traditional languages" in any generality, there is too much variety.
After all, if you believe that, then Python is a Lisp too[1]. And when people say "Lisp", they don't mean "Scheme and CL and [...] and Python".
Sure, like any class of languages, there is not a single syntax. But every lisp has a syntax. And the languages people associate with the class "Lisp" use parens. And in many peoples' opinions, there are better ways of representing an AST. Like indentation, for example. Or curly brackets.
If in programming what we're really doing is telling the compiler stuff, and the compiler only sees an abstract syntax tree, traditional syntaxes are a way of representing an AST in text, and commonly considered to be "better" by the particular language's adherents (Ruby programmers like Ruby syntax, Java programmers like Java syntax, etc.). Sure, you don't get to apply proper macros, but Java/Ruby/etc. programmers don't care about that. What representation is "better" really boils down to taste and opinion.
The way you word it makes it sound as if the government is regulating where it shouldn't be, but that's not what the article says at all.
My bank (RBC) is run by old men in suits, plus I pay no mandatory fees. Optional fees are another thing. If I want the convenience of using an ATM not run by the bank, I pay a surcharge. But, it's a big bank, with ATMs everywhere I go. The surcharge is never paid. :)
No, it's always a reference to an object. It's just that some objects are immutable and so the distinction is not so clear. Otherwise, all-around agreement. +1
I mean, everybody wants to be a game developer. Any prospective developer is screwed by supply and demand and a broken development model that allows for insane crunch time.
Or have things changed?
My university doesn't hand those out. :(
Oh, and finally, they aren't unique to C. You can use the macro preprocessor on any source code you like.
Your argument is less direct, and it doesn't interest me so much. Yes, by fighting for their self-preservation (if it is at stake) they help consumers by maintaining competition and/or variety.