Re: Hmm. Why no binaries?

[HyperHacker <hyperhacker@...>]

On Tue, Sep 13, 2011 at 22:24, Lorenzo Donati
<lorenzodonatibz@interfree.it> wrote:
> On 14/09/2011 5.11, Gerry Weaver wrote:
> [...]
>
>>
>> Okay. I don't mean to ruffle any feathers, but here's the thing. Lua is
>> very dependent on C/C++. Lua gets most of it's functionality from C/C++
>> libraries. I'm starting to get the impression that a few folks
>> think/wish they could somehow ignore C/C++ and exist in a world where
>> they don't have to know or care about C/C++ and building C/C++ code.
>> Unfortunately, in my opinion, Lua is so dependent on C/C++ for even the
>> most basic facilities, that it's really not possible.
>
> Yes, I think you're substantially right, even if this is somewhat a pity. I
> started learning Lua a couple of years ago because it was embedded in my
> favourite editor (SciTE) and I had never heard anything about it at the
> time. Although I had been an active SW developer (Java mainly), I hadn't
> touched a line of serious C for ~15 years (actually I had used turbo C under
> DOS!), so it came to me as a bit of a surprise that to cope with some
> problems in Lua you had to resort to C. Well for me that was an opportunity
> to revamp my C skills, but that's another story.
>
> Yes, if you read the manual and PiL you quickly understand the tight
> relationship between the two, but it is not immediately apparent that even
> for something basic you have to resort to C (e.g. recompling Lua to make its
> dll use the same CRT of a library or vice versa - on Windows I mean).
>
> This comes as a surprise if your are on Windows and if you are used to other
> languages with "batteries included" (e.g. Java or Python). And it comes as
> particularly inconvenient for novices since Lua has almost no battery,
> although its facilities are quite powerful (in some cases I would say
> strikingly powerful, for such a tiny language!), but they require some
> understanding, so probably they are not suited for people with little
> programming experience [1].
>
> As I said this is a pity IMHO, because when you get the hang of it, Lua is
> one of the most fun languages I ever programmed in (among which, at various
> expertise level, FORTRAN, C/C++, Forth, various BASIC dialects, assembly,
> Javascript, Python, Java, Pascal). And there are many non-programmers who
> may be "exposed" to Lua (because Lua is embedded in many places) who could
> be scared off by this "dependency" [1].
>
> But in some way this is a "having a cake and eat it too" problem, since many
> of the benefits of Lua (and its intended design) stem from this tight
> relationship with C, as the cool guys on this list demonstrate every day.
>
>>I'm not
>>
>> recommending that everyone run out and become an expert in C/C++
>> programming. However, having the ability to resolve simple compile/link
>> errors is going to enhance the Lua experience immeasurably. No one would
>> expect this to happen overnight. Give it a try and ask questions if you
>> run into problems. I hope y'all hang in there with Lua. It's an awesome
>> language. However, if you are violently opposed to the idea of learning
>> the basics of C/C++ and building C/C++ code, perhaps Lua is not the
>> right choice for you. I think Visual Basic or Java might be much better
>> options. Then again, I'm sure there are those who would vigorously
>> disagree with me.
>>
>
> The big problem is that C/C++ is *hard* (and probably harder on Windows). A
> newbie in programming (not only in Lua) would have a very hard time in
> getting right the basics of C by self education (which is one of the usual
> path of people approaching programming), unless he/she is very smart and/or
> determined. Let alone C++, which sometimes reminds me of a mouse with a
> gorilla on top!
>
> Compile/link/run is not so an easy concept for absolute beginners,
> especially when you run into issues, such as C toolchain not finding a
> symbol. Even the terminology used in the error messages is hard! Therefore
> either a newbie is so lucky that he types "make" or "make install" and
> everything goes right, or he is left puzzling about what to do, besides
> crying for help.
>
> Of course a developer (even one who haven't ever touched C in his life)
> shouldn't have such big problems, especially because this list is always
> very helpful.
>
> Probably the real question should be why C/C++ programming should be so
> hard, but that's a question for another mailing list :-)
>
>> Thanks,
>> -G
>
> Cheers.
> -- Lorenzo
>
>
> [1] There was an interesting old thread about the suitability of Lua as a
> first programming language:
>
> http://lua-users.org/lists/lua-l/2009-09/msg00539.html
>
>

In my experience, writing C/C++ isn't that difficult (though I still
don't like it) - but compiling it can be a bloody nightmare. Figuring
out makefiles, setting up compilers, tracking down libraries...
Compiling *other peoples'* programs especially can be a gigantic pain,
and I have problems pretty much every single time. (Usually just
having to figure out what packages to install to resolve this obscure
dependency - then often discovering I have to compile *that* library
too, and so on... and then some just plain refuse to compile for
whatever reason, often appearing to be just blatantly broken and
leaving me to wonder how the heck the original author ever got them to
work.)
Setting up a dev environment can also be somewhat difficult even on
Linux - and on Windows? Forget it, you're better off just installing
Linux in a VM. (Or just switching to it completely... ;-) ) Cygwin
might also help, but you're still dealing with a lot of Windows things
like filename restrictions and paths, so I don't know how much better
it'd be.

Lua is a fair bit easier to write than C/C++ because it's higher level
(no pointer bugs, no templates, macros, #includes, #defines, platform
dependency issues; libraries are generally just "luarocks install foo"
or Google for the file), but its real advantage is it's far, FAR
easier to set up and use.

I don't think I'd recommend it for a first language though. I'd
recommend it for a second, following some very simple language
designed specifically to be a first language, that lacks a lot of the
"complexity" that languages designed for writing non-trivial programs
have.

-- 
Sent from my toaster.