Related
I've been using smalltalk for a while now and I love the language and the concept. What I just hate is the System browser. This tool doesn't even resemble a modern IDE. How am I supposed to code without tabs, outlines and handy shortcuts? I often find myself implementing a selector and noticing that it would be nice to isolate a piece of code in a separate (private) selector, just for readability shake, but I don't. Because it takes like 5 mouse clicks and I have to navigate away from the selector I am working at, and navigate back to it. Oh wait, I can't! Because it has syntax errors, because I haven't finished it yet! Kills me. And I don't have a 24 inch display to open 3 browsers.
Sorry for a little rant. My question is, is there a real IDE (Eclipse, Net.Beans, VS) for smalltalk? Maybe for some commercial version of smalltalk?
You might want to check out tODE. It's at a very early stage, but it is an attempt to provide a Smalltalk IDE in the web-browser and is a break from the traditional Smalltalk IDE. With that said, I don't think you'd want to start using tODE right away, but you can keep an eye on it as it evolves.
Dale
Pharo is trying to have the Nautilus Browser ready for Pharo
1.4. I suspect there will be a flood of awesome new tools as the system stabilizes over the next few releases.
There's the Glamorous Inspector.
Spoon has been mounted as a WebDAV filesystem, so you can use whatever tool you like. Spoon is not another Smalltalk, but a testbed for revolutionary Smalltalk technology, which can be incorporated into any other Smalltalk (it's currently on top of Squeak)
There is the Tiling Window Manager to help you organize
Since Squeak and Pharo are live, dynamic, open systems powered only by volunteers, anyone sufficiently motivated can create the next generation of tools ;-)
p.s. I feel your pain. The 20-browsers-open thing is a drag. Let's invent the future!
Historically, the real "IDE" is the Smalltalk one, and one could claim that the others are just an adaptation to the limits of traditional textual programming languages (not rethorical, just check out the evolution of typical development environment UIs and how they are adding features that exists in Smalltalk from the very beggining, like the senders and references in VS).
Just a side note: actually more than 2000 open-source projects in the SqueakSource repository were coded without tabs, outlines and shortcuts (I think still in Squeak you can cross reference any text selecting and pressing with Alt-6). I can't tell you how sad I feel when I must to go back to file based developement, still don't understand why most developers love to sweep text, mess with line numbers and page up-down files in directories. The good news for you, is that you have many options:
There is an alternative browser called BobsBrowser (works in Pharo 1.3) which lets you browse
Class hierarchy windows exploring each class
System Category window
Unsaved edits
Recent classes
Recent methods
Method categories for instances and classes
Unsent methods
Driller relating every structural information
etc.
The advantage over the Whisker browser is that the hierarchical lists are attached to a window while in BobsBrowser you can detach them.
It all depends of the different activities you're performing when you're developing. With some experience in Smalltalk you'll find that you prefer some browser for exploratory insights and others for refactorings, etc. BobsBrowser for example is good for knowledge organization or custom navigation of Smalltalk classes and categories, the hierarchies you can see are the organizations from the Smalltalk reflective meta-architecture at any level (classes, senders, implementors), and they are expandable/collapsable (in the classic system browsers you can only expand the system categories and subcategories).
The instance variables were shown historically in the Smalltalk/V flavors, and there is an old goodie (from Squeak 2.7 IIRC) to enable it back again but almost nobody today maintains the classic System Browser in Squeak/Pharo. Adding that feature to OmniBrowser would be more complicated though because is a browser framework (as every serious framework, it took some time to learn it for the first time), although the effort of the Squeak/Pharo community is absolutely incredible, still the Smalltalk community needs more developers.
You have also a commercial Smalltalk which isn't public (downloadable) yet but includes IDE-like features of traditional programming environments
And I don't have a 24 inch display to open 3 browsers.
You could give the Whisker Browser a try. It lays out the methods side-by-side so that you don't have to position all these windows manually.
I played with it a few years ago but I'm not sure what state it's in right now.
I don't know how mature it is, but the Etoile project has an IDE called CodeMonkey for writing Smalltalk applications. It's not specifically for Squeak, and instead uses their own smalltalk implementation, but it may be worth looking into. Unfortunately, it's only available in their SVN repository, so it's a pain to compile and install.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 12 years ago.
This may be too opinionated, but what I'm trying to understand why some companies mandate the use of an IDE. In college all I used was vim, although on occasion I used netbeans for use with Java. Netbeans was nice because it did code completion and had some nice templates for configuration of some the stranger services I tried.
Now that my friends are working at big companies, they are telling me that they are required to use eclipse or visual studio, but no one can seem to give a good reason why.
Can someone explain to me why companies force their developers into restricted development environments?
IDE vs Notepad
I've written code in lots of different IDEs and occasionally in notepad. You may totally love notepad, but at some point using notepad is industrial sabatoge, kind of like hiring a gardener who shows up with a spoon instead of a shovel and a thimble instead of a bucket. (But who knows, maybe the most beautiful garden can be made with a spoon and a thimble, but it sure isn't going to be fast)
IDE A vs IDE B
Some IDE's have team and management features. For example, in Visual Studio, there is a screen that finds all the TODO: lines in source code. This allows for a different workflow that may or may not exist in other IDEs. Ditto for source control integration, static code analysis, etc.
IDE old vs IDE new
Big organizations are slow to change. Not really a programming related problem.
Because companies standardize on tools, as well as platforms--if your choice of tools is in conflict with their standards then you can either object, silently use your tool, or use the required tool.
All three are valid; provided your alternative doesn't cause other team-members issues, and provided that you have a valid argument to make (not just whining).
For example: I develop in Visual Studio 2008 as required by work, but use VS2010 whenever possible. Solutions/Projects saved in 2010 can't be opened in 2008 without some manual finagling--so I can't use the tool of my choice because it would cause friction for other developers. We also are required to produce code according to documented standards which are enforced by Resharper and StyleCop--if I switched to a different IDE I would have more difficulty in ensuring the code I produced was up to our standards.
If you're good at using vim and know everything there is to know about it, then there is no reason to switch to an IDE. That said, many IDEs will have lots of useful features that come standard. Maintaining an install of Eclipse is a lot easier than maintaining an install of Vim with plugins X, Y, and Z in order to simulate the same capabilities.
IntelliSense is incredibly useful. I realize that vim has all sorts of auto-completion, but it doesn't give me a list of overloaded methods and argument hints.
Multiple panes to provide class hierarchies/outlines, API reference, console output, etc.. can provide you more information than is available in just multiple text buffers. Yes, I know that you have the quickfix window, but sometimes it's just not enough.
Compile as you type. This doesn't quite work for C++, but is really nice in Java and C#. As soon as I type a line, I'll get feedback on correctness. I'm not arrogant enough as a programmer to assume that I never make syntax errors, or type errors, or forget to have a try/catch, or... (the list goes on)
And the most important of all...
Integrated Debuggers. Double click to set a break point, right click on a variable to set a watch, have a separate pane for changing values on the fly, detailed exception handling all within the same program.
I love vim, and will use it for simple things, or when I want to run a macro, or am stuck with C code. But for more complicated tasks, I'll fire up Eclipse/Visual Studio/Wing.
Sufficiently bad developers are greatly assisted by the adoption of an appropriately-configured IDE. It takes a lot of extra time to help each snowflake through his own custom development environment; if somebody doesn't have the chops to maintain their own dev environment independently, it gets very expensive to support them.
Corporate IT shops are very bad at telling the difference between "sufficiently bad" and "sufficiently good" developers. So they just make everybody do the same thing.
Disclaimer: I use Eclipse and love it.
Theoretically, it would decrease the amount of training needed to get an unexperienced developer to deal with the problems of a particular IDE if all the team uses that one tool.
Anyway, most of the top companies don't force developers to use some specific IDE for now...
I agree with this last way of thinking: You don't need your team to master one particular tool, having team knowledge in many will improve your likelyhood to know better ways to solve a particular roblems.
For me, I use Visual Studio with ReSharper. I cannot be nearly as productive (in .Net) without it. At least, nobody has ever shown me a way to be more productive... Vim, that is great. You can run Vim inside of Visual Studio + R# and get all the niceties that the IDE provides, like code navigation, code completion and refactoring.
Same reason we use a hammer to nail things instead of rocks. It's a better tool.
Now if you are asking why you are forced to use a specific IDE over another, well that's a different topic.
A place that uses .NET will use Visual Studio 99% of the time, at least that's what I've seen. And I haven't found anything out there that is better than Visual Studio for writing .NET applications.
There is much more than code completion into an IDE:
debugging facilities
XML validation
management of servers
automatic imports
syntax checking
graphical modeling
support of popular technologies like Hibernate, TestNG or Spring
integration of source code management
indexing of file names for quick opening
follow "links" in code: implementation, declaration
integration of source code control
searching for classes or methods
code formatting
process monitoring
one click/button debugging/building
method/variable/field/... renaming
etc
Nothing to do with incompetence from the programmers. Anybody would be A LOT less productive using vim for developing a big Java EE application.
How big were you projects at college? A couple of classes in a couple of files? Or rather a couple of hundreds of classes in a couple of hundreds of files?
Today I had the "honor" of looking at a file in a rather large project where the programmer opted to use vi (yes vi, not vim) and a handcrafted commandline compiler call (no make). The file contained on function spanning about 900 lines with a series of if-else-if-else-constructs (because that way you have all your code in one place!!!!!!). Macho-Programmer at his finest.
OK there are very good reasons for enforcing a particular toolset within a production environment:
Companies want to standardize everything so that if an employee leaves they can replace that person with minimal effort.
Commercial IDEs provide a complex enough environment to support a single interface for a variety of development needs and supporting varying levels of code access. For instance the same file-set could be used by the developer, by non-programmers (graphics designers etc.) and document writers.
Combine this with integrated version control and code management without the need of someone learning a particular version control system, all of a sudden IDEs start to look nicer and nicer.
It also streamlines maintenance of build systems in a multi-homed environment.
IDEs are easier to give tutorials to via phone or video, and probably come with those.
etc. etc. and so forth.
The business decision making behind enforcing a standardized environment goes beyond the preference of a single programmer or for that matter perhaps the understanding of the programming team.
Using an IDE helps an employee to work with huge projects with minimal training. Learn a few key combos - and you will comfortably work with multi-thousand-file project in Eclipse, IDE handles most of the work for you under the hood. Just imagine how many years of learning it takes to feel comfortable developing such projects in Vim.
Besides, with an IDE it is easy to support common coding standards across the entire team: just set a couple of options and an IDE will force you to write code in a standardized way.
Plus, IDE gives a few added bonuses like refactoring tools (especially good in Eclipse), integrated debugging (especially good in Visual Studio), intellisense, integrated unit tests, integrated version control system etc.
The advantages and disadvantages of using an IDE also greatly depends on the development platform. Some platforms are geared towards the use of IDEs, others are not. As a rule of thumb, you should use IDE for Java and .Net development (unless you're extremely advanced); you should not use IDE for ruby, python, perl, LISP etc development (unless you're extremely new to these languages and associated frameworks).
Features like these aren't available in vim:
Refactoring
Integrated debuggers
Knowing your code base as an integrated whole (e.g., change a Java class name; have the change reflected in a Spring XML configuration)
Being able to run an app server right inside the IDE so you can deploy and debug your code.
Those are the reasons I choose IntelliJ. I could go back to sticks and bones, but I'd be a lot less productive.
As said before, the question about using an IDE is basicaly productivity. However there is some questions that should be considered by the company when choosing a specific IDE. that includes:
Company culture
Standardize use of tool, making it accessible for all developers. That easies training, reduces costs and improve the speed of learn curve.
Requirements from specific contract. As an example, there are some development packages that are fully supported (i.e. plugins) by some IDE and not by anothers. So, if you are working with the support contract you will want to work with the supported IDE. A concrete example is when you are working with not common OS like VxWorks, where you can work with the Workbench (that truely is an eclipse with lot of specific plugins for eclipse).
Company policy (and also I include the restriction on company budget)
Documentation relating to the IDE
Comunity (A strong one can contribute and develop still further the IDE and help you with your doubts)
Installed Base (no one wants to be the only human to use that IDE on the world)
Support from manufacturers (an IDE about to be discontinued probably will not be a good option)
Requirements from the IDE. (i.e. cross platform or hardware requirements that are incompatible with some machines of the company)
Of course, there is a lot more. However, I think that this short list help you to see that there is some decisions that are not so easy to take, when we are talking about money and some greater companies.
And if you start using your own IDE think what mess will be when another developer start doing maintenance into your code. How do you think will the application be signed at the version manager ? Now think about a company with 30+ developers each using its own IDE (each with its own configuration files, version and all that stuff)...
http://xkcd.com/378/
Real programmers use the best tools available to get the job done. Some companies have licenses for tools but there's nothing saying you can't license/use another IDE and then just have the other IDE open to copy/paste what you've done in your local IDE.
The question is a bit open-ended, perhaps you can make it community wiki...
As you point out, the IDE can be useful, or even a must have, for some operations, like refactoring, or even project exploring: I use Eclipse at my work, on Java projects, and I find very useful to get a list of all occurrences of the usage of a public method or a class in a project. Likely, I appreciate to be able to rename it from where it is defined, and having all these occurrences automatically updated.
The fact I have the JavaDoc displayed when hovering over a name is very nice too. Like autocompletion, jump to a class name, etc.
And, of course, debugging facilities...
Now, usage of Eclipse isn't mandatory in our shop! Some years ago, some people used the Delphi IDE (forgot its name), I tried NetBeans, etc. But I think we de facto standardized on Eclipse, but it was a natural evolution rather than a company policy. And we often just open files in a text editor when we need a quick update...
What is the best route or place to get started with arcobjects if one is not a developer and not aiming to become one?
I've been using gis professionally for a long time, almost two decades, arcinfo/arcgis for most of that; I'm pretty good. I'm learning software development, and even have a modestly successful small python application used in a public project; I'm not good! I don't want to become a full fledged software developer but I keep running into things I just can't do without programming (example). In the arcgis world this puts me pretty squarely in the python camp, which is fine by me since I like python, however python does not have straightforward access to arcobjects.
Soooo, I need to get started, but where? Arcgis help says to get started with the ESRI Developer Network but $1500/yr is definitely not in my budget, and sounds like using a sledge hammer to swat mosquito. And which language .NET, Visual Basic, or Visual C++?
Thanks for your thoughts.
Assuming you have desktop, I'd just install the SDK from the desktop installation DVD's and download the free VS2010 60 day eval (which can be extended).
VS Express is supported, but I've never used it.
For language, I'd stay away from C++. There's more sample code available for C# than VB.NET. Except for the yield keyword, VB.NET and C# are equal.
I've been developing for Windows and *nix platforms for quite some time, and am looking to move into Mac development. I am tossing up between using ObjC/Cocoa and C++/Qt4.5.
The C++/moc semantics make more sense to me, and improving knowledge in Qt seems like a sensible thing to do given that you end up with a skill set that covers more platforms.
Am I likely to handicap my applications by skipping Cocoa?
The sample Qt applications look pretty Mac-native to me, but they are quite simple so potentially don't tell the whole story. Are there other pros to the Xcode way that Qt doesn't have, such as packaging, deployment, etc.?
Here's an easy way to answer it:
If you were developing a Windows app with .NET or MFC, would you handicap your applications by using Qt? If the answer to that is yes, then the situation is likely to be the same on the Mac.
A few negatives I can think of off the top of my head:
Licensing
Qt apps, while good, are not completely a native UI experience and there's things a native UI designer can do in Cocoa which boggle the mind. While I can't be sure that all the same functionality isn't available in Qt, I doubt it.
Qt is always a little behind. If Microsoft or Apple come out with a great new technology, you have to wait for the Qt developers to update Qt.
However, with all that said, only you can determine the business value of using Qt. If you think cross-platform development is going to be a major part of your development, then Qt might be worth it, despite the issues mentioned.
Ask yourself: how many of the best Mac applications that you know of use Qt instead of native Cocoa?
For our robotic systems, we originally wrote our control software in C++ using the cross-platform wxWidgets library (we avoided Qt due to some licensing concerns), because we felt that we had to target Windows, Linux, and Mac platforms for our end users. This is what we shipped for over a year until I started tinkering with Cocoa.
Right away, the thing that most impressed me was how quickly you could develop using Cocoa. Eventually, we decided to drop support for Linux and Windows and rewrite our entire control applications in Cocoa. What had taken us years to put together in C++ required only three months to completely reimplement in Cocoa.
Aside from the "lowest common denominator" interface issues that others have pointed out, the rapid development allowed by Cocoa has become a competitive advantage for our company. Our software has advanced far more quickly since our conversion to Cocoa, and it has allowed us as a new company with one developer to pull even with 10-year-old competitors that have 20-man development teams. This appears to be a common story in the Mac development space, where you see a lot of small teams who are able to create products that compete with those of much larger companies.
As a final note, using Cocoa gives you the ability to stay on top of the new APIs Apple is continually rolling out. We're now working on a new control interface that will make heavy use of Core Animation, something that would be painful to deal with using Qt.
I'm currently developing both with QT (actually PyQT, but it makes no difference to your question) and native Cocoa app. For me it's no brainer, I'd chose Cocoa. It's really worth time to explore Cocoa in general, there are many great concepts within the Cocoa framework, and Objective-C 2.0 as well.
I'd use Qt if you want this to be a crossplatform application.
You can have a look at the QMacCocoaViewContainer class. It acts as some kind of wrapper for generic Cocoa views, so you can also have Cocoa elements which are not officially supported by Qt.
Of course this means learning a little about Cocoa and Objective C and how a Cocoa UI would need to look like. But if you already know Qt well and if it’s not like your application is all and only about the GUI this could be a good way to go.
And don’t forget about the QMacStyle::WidgetSizePolicy or you won’t understand why your tables come out so huge.
Obviously, the best option is to use a cross platform suite that supports native widgets.
With QT4 you can build your base user interface. Then just add native support for your specific target platform.
Sure, Cocoa has a lot of fancy stuff (and you can still use them trough QT4), but let me be clear. I see a lot of fancy Apps on the AppStore, pretty ones, but most of then are just crap, expensive.. what ever. I really missed my Kate text editor, my okular viewer, my krita drawing software... those are just better than the commercial and expensive alternatives and are free. so i just tweak the source code a little bit too have a REAL native and great experience.
What if i have to use a linux app on my main computer with is a mac os x? or windows? or whatever? only?
For example, why on earth i have to buy a expensive ,fancy but far less featured image editor software for my mac like pixelmator when i can use a full featured real image manipulation software like Gimp? YES Gimp is gtk2 based which is a pain on any platform, specially on Mac because is really ugly. Gimp should be ported to QT4. Inkscape should be ported to QT4 too, and it would feel so great.
Is so simple to do.. gosh!
http://doc.qt.nokia.com/4.7-snapshot/demos-macmainwindow.html
Even you can add support for the the new native lion fullscreen feature, unified title and toolbar menus, etc
I , as a user, i really care about efficient, featured, good and cross platform apps, i don't really care about developer's convenience or laziness .
I do a lot of cross-platform development (Mac, Windows, Linux), and for some projects use Qt. It is a fine framework, and provides a rich class library. If you need to deploy on multiple platforms, cannot afford to spend the time/effort on platform-specific front-ends, or the "generic" support for each platform is sufficiently good, then use Qt.
However, Qt inevitably suffers in some ways from the lowest common denominator syndrome, and sometimes does not feel quite native enough. There are also certain features that are either difficult to support, or are simply not provided in the Qt libraries. So if you can afford the time and effort, or your app really demands the attention to detail and fit & finish, then developing separate front-ends may be worth it.
In either case, you ought to be writing your back-end (aka domain) code in a platform-neutral and front-end neutral manner. This way, the front-end is easily replaced, or modified between platforms.
You could always start with a Qt front-end and go for a quick time to market, then develop a native front-end down the line.
In practice, I've noticed that a Qt app on Windows looks most "native", while on Mac there are certain subtle telltale signs that make it look/feel not quite right. And Mac users tend to have much higher expectations when it comes to UI/UX!
Since posting this, i've been learning the Cocoa / Objective-C way, and have been quite impressed. Despite what I initially thought was quite a quirky syntax, Objc appears to be a very effective language for implementing UI code, and the XCode sugar - things like Core Data and bindings - make short work of all of the boring bits.
I spent a while with the QT examples and documentation before digging into cocoa, and tend to agree with what has been said above w.r.t being slightly behind the curve and less 'aqua-ish' - albeit from a fairly trivial inspection. If I absolutely had to be build a cross-platform app i'd probably use QT rather than trying to separate out the UI code, as it seems like it would provide close-enough visuals, but for mac only purposes, Cocoa seems like a definite win.
Thanks all for your responses, they've all been very helpful!
DO NOT use Qt for a Mac app. You will get no hardware acceleration for 2D rendering, and you will not be able to deliver ADA compliance.
Depending on what kind of apps you want to write, another contender is REALbasic now called Xojo.
The move from C++ is pretty easy (I have 15 years C++ experience) and the framework and IDE extremely productive. You have the added bonus of being able to deploy to Linux and Windows with trivial effort. Their framework compiles to native code and uses native widgets so you don't have an emulated look and feel.
The big reason for learning Cocoa and coding in Objective-C is if you want to hone your iPhone skills or are chasing a really fancy user experience. If you wanted to rival the cutting edge of WPF development then I'd recommend Cocoa.
As already discussed in "Lua as a general-purpose scripting language?" Lua currently probably isn't the best scripting language for the desktop environment.
But what do you think about the future? Will Lua get so popular that there will soon be enough libraries to be able to use it like Python, Ruby or something similar?
Or will it simply stay in it's WoW niche and that's it?
I think it has a great future, a lot of projects are starting to adopt it for it's simplicity and usefulness.
Example: Awesome WM (Window Manager)
The project recently released version 3, incorporating a new configuration system completely written in Lua. Allowing you to literally write your configuration file as a program, loops, booleans, data structures.
Personally I love the syntax and the flexibility of such a system, I think it has great potential.
I wouldn't be surprised if it became more popular in the future.
Brian G
I suppose the answer starts with 'It depends how you want to use it...'.
If you're writing the common business app (fetch the data from the database, display the data in a web page or window, save the data to the database), Lua already has what you need.
The Kepler Project contains goodies for web development. Check out their modules to see some of the available libraries - there's network, MVC, DBMS access, XML, zip, WSAPI, docs...
As an example web app, check out Sputnik.
For desktop UI, there's wxLua - Lua hooks for wxWidgets.
ORM is conspicuously missing but that didn't stop people from developing in other languages before ORM was available.
If you're looking for specialized libraries - scientific, multimedia , security - don't count Lua out before you check LuaForge.
When it comes down to it, there's nothing in Lua's design that prevents general purpose use. It just happens to be small, fast, and easy to embed... so people do.
Uh? I would say instead WoW is a niche in the Lua ecosystem... The world of Lua doesn't revolve around WoW, there are lot of applications, some big like Adobe Lightroom (to take a non game), using Lua.
Lua is initially a scripting language, in the initial sense, ie. made to be embedded in an application to script it. But it is also designed as an extensible language, so we will see progressively more and more bindings of various libraries for various purposes.
But you will never get an official big distribution with batteries included, like Python or Perl, because it is just not the philosophy of the authors.
Which doesn't prevent other people to make distributions including lot of features out of the box (for Windows, particularly, where it is difficult to build the softwares).
Lot of people already use it for general system-level scripting, desktop applications, and such anyway.
There are more and more libraries for Lua.
If you are a Windows user, have look at Lua for Windows. It comes with "batteries included" (wxLua, LuaCURL, LuaUnit, getopt, LuaXML, LPeg...).
Very usefull!
It's 2017, 9 years after this question was first asked, and lua is now being heavily used in the field of machine learning due to the Torch library.
I really like it as an embedded language. It's small, very easy to use and embed and mostly does what I need right out of the box. It's also similar enough to most languages that it has never really been an issue for me. I also like how easy it is to redefine and add base functions and keywords to the language to suit whatever needs my application has.
I have used it in the WoW area but I've also found it useful as a generic scripting language for a number of different applications I've worked on, including as a type of database trigger. I like Ruby and Python and other more full-featured scripting languages but they're not nearly as convenient for embedding in small applications to give users more options for customizing their environments.
being comfortable as a shell language has nothing to do with being a great general purpose language.
i, for one, don't use it embedded in other applications; i write my applications in Lua, and anything 'extra' is a special-purpose library, either in Lua or in C.
Also, being 'popular' isn't so important. in the Lua-users list periodically someone appears that says "Lua won't be popular unless it does X!", and the usual answer is either: "great!, write it!", or "already discussed and rejected".
I think the great feature of Lua is, that it is very easily extensible. It is very easy to add the Lua interpreter to a program of your own (e.g. one written in C, C++ or Obj-C) and with just a few lines of code, you can give Lua access to any system resource you can think of. E.g. Lua offers no function to do xxx. Write one and make it available to Lua. But it's also possible the other way round. Write your own Lua extension in a language of your choice (one that is compilable), compile it into a native library, load the library within Lua and you can use the function.
That said, Lua might not be the best choice as a standalone crossplatform language. But Lua is a great language to add scripting support to your application in a crossplatform manner (if your app is crossplatform, the better!). I think Lua will have a future and I think you can expect that this language will constantly gain popularity in the long run.
Warhammer Online, and World of Warcraft use it for their addon language I believe.
I think it's hot! I'm just no good at it!
Well, greetings from 2022.
It is already a general purpose language. Today you can even serve pages using OpenResty, extend games, read databases or create scripts as shellscript replacements.
There are a plenty of libraries "modules" for Lua, many ways to achieve what you are wanting and Lua 5.4 is even faster.
The "extendable and extensive" nature of Lua, accostumed people to think it should only be used as plugin or extension. In Linux, by example, you can shebang a file with lua-any, make it executable and run like any system script. Or you can make a folder app like Python or virtualenv using Lupe. Lua 5.3 also gained impressive performance improvements.
Also there are many good tools like IUP to create native windows in Lua for Mac, BSD, Linux and Windows and side environments like Terra that lets you use Lua with its counterpart Terra and write compiled programs. Lua now, is more than a extension language, it has its own universe.