The documentation says that Lua can be used for functional programming but also that it is an imperative programming language. So for all the posts I have read about imperative and functional programming they all said the same:
Functional programming relies on a declarative programming language. This post shows a table that compares characteristics of imperative and functional programming and these are two completely different approaches to solve problems.
So how can I realise a functional solution for a problem when I use an imperative programming language?
Your best source will be “A Taste of Functional Programming” on p.74 of the newest, 4th edition of Programming in Lua. There, the creator of Lua adopts an example from the research report Haskell vs. Ada vs. C++ vs. Awk vs. ... An Experiment in Software Prototyping Productivity, by Paul Hudak and Mark P. Jones.
The point is, Lua provides the mechanisms by which to write programs using functional programming patterns and constructs. As said here, functional programming is a programming paradigm. A style. So, some programming languages are built for that paradigm exclusively. Others, like Lua, offer a variety of programming mechanisms.
I would like to provide a very simple scripting interface for a program I'm working on. My program would expose some functions that could be called from the script. I don't need much, maybe just variables, if/else, and loops. The two most popular languages seem to be lua, and python. I really do not like lua from my days of writing World of Warcraft plugins and both seem a lot more complicated than I need. What other languages are available?
Try the Ring programming language (http://ring-lang.net)
The compiler + The Virtual Machine are 15,000 lines of C code
The Ring can be embedded in C/C++ projects, extended using C/C++ code and/or used as standalone language.
The language is simple, trying to be natural, encourage organization and comes with transparent implementation. It comes with compact syntax and a group of features that enable the programmer to create natural interfaces and declarative domain-specific languages in a fraction of time. It is very small, fast and comes with smart garbage collector that puts the memory under the programmer control. It supports many programming paradigms, comes with useful and practical libraries. The language is designed for productivity and developing high quality solutions that can scale.
Learn about embedding the language from
https://en.wikibooks.org/wiki/Ring/Lessons/Embedding_Ring_Interpreter_in_C/C%2B%2B_Programs
I've done some research about Lua programming but I'm still confused about under which paradigm it can work.
In some walkthroughs, I've found that Lua is not made for Object-Oriented Programming. But they are other people that says it can work too for OOP. So, I'm looking in which programming paradigms it can work the best.
Lua is a "do what you want to" programming language. It doesn't pick paradigms; it is a bag of useful features that give you the freedom to use whatever paradigm that you need. It doesn't have functional language features, but it does feature functions as first-class objects and proper lexical scoping. So you can use it functionally if you so desire. It doesn't have "classes" or other such prototypes, but it does feature ways to encapsulate data and special syntax for calling a function with a "this" object. So you can use it to build objects.
Lua does not dictate what you do with it; that's up to you. It provides low-level tools that allow you to easily build whatever paradigm you wish.
Lua is an imperative language; so it is not ideal for functional programming.
Left by itself, Lua is a procedural language. However, given the simplicity of its data structures (it just has one: the table) it's very easy to add a "layer" on top of it and make it an object oriented language. The most basic inheritance rule can be achieved in as little as 10 lines of code. There are several libraries out there that provide a more refined experience though. My library, middleclass, is 140 LOC in total.
Another great way of using Lua is as an scripting language. It's small, fast, uses only standard C stuff, and it's standard lib is tiny. On the other hand, it doesn't come with "batteries included" like java does.
Finally, I find it very useful as a data notation language; you can express raw data in a format very similar to JSON.
In general, I think that Lua feels very close to javascript.
Is this language an OO language?
Is it often used as OO language?
Lua is fully capable of prototype-based object-oriented programming similar to JavaScript.
Prototype-based programming is a style
of object-oriented programming in
which classes are not present, and
behavior reuse (known as inheritance
in class-based languages) is performed
via a process of cloning existing
objects that serve as prototypes. This
model can also be known as class-less,
prototype-oriented or instance-based
programming. Delegation is the
language feature that supports
prototype-based programming.
For more information, see Chapter 16 - Object-Oriented Programming of the Programming in Lua book.
It does support object oriented programming with some difficulty. This chapter in the official guide explains http://www.lua.org/pil/16.html
Lua it's not an OO language "per-se" but offers mechanisms to implement different styles of Object Orientation.
There are a lot of libraries that implement OO for lua. A look at lua.org (the main Lua site) or lua-users (the Lua Community Wiki) will be helpful.
Even more helpful would be to ask in the Lua Mailing list.
Lua is a powerful, fast, lightweight,
embeddable scripting language.
Lua combines simple procedural syntax
with powerful data description
constructs based on associative arrays
and extensible semantics. Lua is
dynamically typed, runs by
interpreting bytecode for a
register-based virtual machine, and
has automatic memory management with
incremental garbage collection, making
it ideal for configuration, scripting,
and rapid prototyping.
~ Lua: about
It's mostly used as a scripting tool in Apps, to extend or implement functionalities.
What is the added value for learning F# when you are already familiar with LISP?
Static typing (with type inference)
Algebraic data types
Pattern matching
Extensible pattern matching with active patterns.
Currying (with a nice syntax)
Monadic programming, called 'workflows', provides a nice way to do asynchronous programming.
A lot of these are relatively recent developments in the programming language world. This is something you'll see in F# that you won't in Lisp, especially Common Lisp, because the F# standard is still under development. As a result, you'll find there is a quite a bit to learn. Of course things like ADTs, pattern matching, monads and currying can be built as a library in Lisp, but it's nicer to learn how to use them in a language where they are conveniently built-in.
The biggest advantage of learning F# for real-world use is its integration with .NET.
Comparing Lisp directly to F# isn't really fair, because at the end of the day with enough time you could write the same app in either language.
However, you should learn F# for the same reasons that a C# or Java developer should learn it - because it allows functional programming on the .NET platform. I'm not 100% familiar with Lisp, but I assume it has some of the same problems as OCaml in that there isn't stellar library support. How do you do Database access in Lisp? What about high-performance graphics?
If you want to learn more about 'Why .NET', check out this SO question.
If you knew F# and Lisp, you'd find this a rather strange question to ask.
As others have pointed out, Lisp is dynamically typed. More importantly, the unique feature of Lisp is that it's homoiconic: Lisp code is a fundamental Lisp data type (a list). The macro system takes advantage of that by letting you write code which executes at compile-time and modifies other code.
F# has nothing like this - it's a statically typed language which borrows a lot of ideas from ML and Haskell, and runs it on .NET
What you are asking is akin to "Why do I need to learn to use a spoon if I know how to use a fork?"
Given that LISP is dynamically typed and F# is statically typed, I find such comparisons strange.
If I were switching from Lisp to F#, it would be solely because I had a task on my hands that hugely benefitted from some .NET-only library.
But I don't, so I'm not.
Money. F# code is already more valuable than Lisp code and this gap will widen very rapidly as F# sees widespread adoption.
In other words, you have a much better chance of earning a stable income using F# than using Lisp.
Cheers,
Jon Harrop.
F# is a very different language compared to most Lisp dialects. So F# gives you a very different angle of programming - an angle that you won't learn from Lisp. Most Lisp dialects are best used for incremental, interactive development of symbolic software. At the same time most Lisp dialects are not Functional Programming Languages, but more like multi-paradigm languages - with different dialects placing different weight on supporting FPL features (free of side effects, immutable data structures, algebraic data types, ...). Thus most Lisp dialects either lack static typing or don't put much emphasis on it.
So, if you know some Lisp dialect, then learning F# can make a lot of sense. Just don't think that much of your Lisp knowledge applies to F#, since F# is a very different language. As much as an imperative programming used to C or Java needs to unlearn some ideas when learning Lisp, one also needs to unlearn Lisp habits (no types, side effects, macros, ...) when using F#. F# is also driven by Microsoft and taking advantage of the .net framework.
F# has the benefit that .NET development (in general) is very widely adopted, easily available, and more mass market.
If you want to code F#, you can get Visual Studio, which many developers will already have...as opposed to getting the LISP environment up and running.
Additionally, existing .NET developers are much more likely to look at F# than LISP, if that means anything to you.
(This is coming from a .NET developer who coded, and loved, LISP, while in college).
I'm not sure if you would? If you find F# interesting that would be a reason. If you work requires it, it would be a reason. If you think it would make you more productive or bring you added value over your current knowledge, that would be a reason.
But if you don't find F# interesting, your work doesn't require it and you don't think it would make you more productive or bring you added value, then why would you?
If the question on the other hand is what F# gives that lisp don't, then type inference, pattern matching and integration with the rest of the .NET framework should be considered.
I know this thread is old but since I stumbled on this one I just wanted to comment on my reasons. I am learning F# simply for professional opportunities since .NET carries a lot of weight in a category of companies that dominate my field. The functional paradigm has been growing in use among more quantitatively and data oriented companies and I'd like to be one of the early comers to this trend. Currently there doesn't an exist a strong functional language that fully and safely integrates with the .NET library. I actually attempted to port some .NET from Lisp code and it's really a pain b/c the FFI only supports C primitives and .NET interoperability requires an 'interface' construct and even though I know how to do this in C it's really a huge pain. It would be really, really, good if Lisp went the extra mile in it's next standard and required a c++ class (including virtual functions w/ vtables), and a C# style interface type in it's FFI. Maybe even throw in a Java interface style type too. This would allow complete interoperability with the .NET library and make Lisp a strong contender as a large-scale language. However with that said, coming from a Lisp background made learning F# rather easy. And I like how F# has gone the extra mile to provide types that you would commonly see it quantitative type work. I believe F# was created with mathematical work in mind and that in itself has value over Lisp.
One way to look at this (the original question) is to match up the language (and associated tools and platforms) to the immediate task. If the task requires an overwhelming percentage of .NET code, and it would require less shoe-horning in one language than another to meet the task head-on, then take the path of least resistance (F#). If you don't need .NET capabilities, and you're comfortable working with LISP and there's no arm-bending to move away from it, keep using it.
Not really much different from comparing a hammer with a wrench. Pick the tool that fits the job most effectively. Trying to pick a tool that's objectively "best" is nonsense. And in any case, in 20 years, all of the currently "hot" languages might be outdated anyway.