[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: Are parenthesis-free calls a Good? (was Re: patch: C-style string lexing)
- From: "Brandon Van Every" <bvanevery@...>
- Date: Thu, 31 Jan 2008 11:56:55 -0500
On Jan 31, 2008 11:36 AM, Eike Decker <firstname.lastname@example.org> wrote:
> Or like the sample from Alexander
> foo "name"
> bar "bar";
> baz "baz";
Hrm, to me the bar and baz look like type declarations.
I've been lurking around here trying to decide if there's value in
using Lua as an embedded language for the CMake cross-platform build
tool. http://www.cmake.org Although the conversations I'm reading on
the list are stimulating from an experimental language design
standpoint, it's making me wonder how mature Lua actually is, or how
complicated it's actually going to become. I'm starting to see the
advantages of simpler languages with fewer ways of doing things.
Namely, they're easier to parse and metaprogram because there are
fewer cases to consider. Parentheses do help a parser, and they
indicate "this is a function call" to mainstream programmers, so they
help human parsing as well.
> But of course it's arguable - however: I have stopped counting the times I have
> explained the colon syntax even to experienced programmers who were puzzled. I
> don't think that there exists a syntax that helps the beginners.
That's another tradeoff: more learning curve for potential tool users,
and more needed documentation. This creates a barrier to acceptance
if there aren't other compelling reasons to learn the language.
Perhaps for core Lua you don't have this problem, you have sufficient
popularity and critical mass. But if, for instance, CMake were to
adopt Lua as the scripting language, how much of "hey WTF is this?"
would people have to go through, and how much would that put them off?
In an embedded application, people may not be that interested in Lua,
they may be a lot more interested in getting up and running with the
tool quickly. Arcana in the language usage doesn't help that.
Brandon Van Every