> > C(++) and LUA are not playing the same GAME. C(++) are fully compiled so
> > mostly used when performances is the most important point.
> I wish somebody gave me a dollar every time I saw a C or C++
> application code go O(n^2) or worse on string manipulation (or other
> sequences). Especially easy in C++ since you can treat CString just
> like a Visual Basic string...so you get more VB programmers hired to
> write app code. Oh, you think MFC4.2 is ancient history? Go read some
> embedded code.
The problem is not the language,
it's the guy/girl behind the keyboard as you said : C(++) is as flexible so you can write the better thing ... but the worst one as well.
> There are other inefficiencies people are willing to eat because they
> *don't* have a garbage collector (so they make more copies to make
> sure theirs doesn't go away), and they do have to strcmp everything
> instead of just comparing pointers.[1]
So, you had a look on m$-windows code ? :) :)
> > Secondly, C(++) are very close to the hardware so it's really very "easy" to
> > write OSes or drivers or embedded with them.
> If you need to use C to do it, it is probably not easy.
??? Sorry, I didn't got the point.
What should be an easiest way to talk directly to the hardware than C ?
To speak to memory mapped device, you have only to describe it in "struct", create a pointer and plays with bit field afterward. Easy, fast and
understandable.
Idem with IRQ driven.
> > - LUA is very easy to understand and start with ... but with strings
> > manipulation. Something that is very easy in C or PHP like token parsing is
> > a tedious task in LUA.
> An honest question: what did you miss most? I've been inside the Lua
> room long enough I just don't know what new users see as missing.
All C like string manipulation API and pointers (but I may have missed something, I started Lua few weeks back and haven't all the time I would like to have). And as well PHP's explode() function.
I didn't played to much with Lua OOP, but I really like C++ heritages : a must to do reusable code. (I still miss multiple heritages in PHP).
Hum, for my lazyness as well, LUA 5.3 *must* have '++' and '+=' operators :)
The other point is starting with PHP, you're in a known area : the API is almost the same as C. After a while, you can
play as well with language specificities, but you have started.
With lua, it seems you goes very early to regulars expressions : powerful when you master them, but difficult to introduce.
> The feedback we're getting is that if clever solution X exists, it is not obvious to somebody approaching the
language.
I confirm : my own application client was initially in PHP. Moving to Lua, I need to find some equivalences ... and even if "google is my friend", it's very time consuming to find out corresponding code.
In my example, it was equivalence to dirname(), filename() and gethostname() ...
And
dir = string.match(p, '(.*[/\\]).*')
is all but looking like dirname() :)
(for my own usage, I build a module name "phplike" containing the equivalence ...).
The second example is I was introduced to Lua by creating plugin for Conky. And when you visit forums, you can
meet 2 or 3 lua experts and others are only taking piece of codes most of the time without understanding the inner things. And if you ask why, the response is always "I don't understand cryptic regex" (it has killed Perl too).
What is missing is a good and comprehensive knowledge base for all of that.
> > - It's really difficult to find good tutorials or examples for LUA.
> If you have not read it already, ISBN 8590379825. In my opinion, the
> best-written "here's my language" book since K&R.[2]
Arg, I'm a full autodidact and I never started any language by "a book" but perhaps for my first one, BASIC
(Yeah, even for C in 1987 : I got some good tutorials from Amiga's public domains or directly from Commodore's white papers ...).
For PHP, it was easy, as I said, really close to C. And for the rest, zillion of tutos on the web.
Lua ... oulala :(
> Team Fortress Meet-The-Heavy jokes aside, people really overestimate
> how efficient C++ code in the wild is.
I started to play with complex computer programming on a venerable Amiga 1000, 68000, 7.14 Mhz.
Even if AmigaOS is far lighter and efficient(*) than almost everything
we have now (but probably embedded ones), every CPU cycle count. And C
was THE language on this machine, and did very wonderful things.
Even C++ compiled by Gcc (but really memory intensive). But at this time, programmer
focussed on performances and optimisation, it's unfortunately not any
more the case now days on our current powerful hardware.
(*) 256 Ko RAM + 256 Ko ROM (yes, Ko) was far enough to run an full
multitasking OS, with GUI and all. I'm really doubtful to see an OS
needing 3 Go of RAM and a CPU able to drive a nuclear power unite 10
years before, only to display some windows and talk to it's hardware.
Bye
Laurent
