Is there a programming language that is purely written left to right?
Example (close to Python syntax):
Normal Python: a: int = 2 + 3
Left to Right Python: 2 + 3 = a: int
The assignment should be after the calculation, because the assignment happens after the calculation (proper representation of the thought prozess and of that happens in time)
There is one related post I found (Is there a programming language that reads right to left?) but it is several years old and was not very well formulated.
While SQL seems to be quite close to this, it is not turing complete.
Haskell would meet my criterias as far as I can see, except variable assignment, given some syntactic sugar is or is not used.
FOL, ASP, ECLiPSe and other more descriptive languages are mostly nondirected and are usually either by convention (FOL) or by definition (ASP, ECLiPSe) still right to left in some way.
I do see the UI advantages of variables being assigned being at the beginning of the line. It would still be interesting to see, if it is actually an advantage or if we are just used to it.
I am aware that I could simply create a new dialect or writing convention for some existing system to get this result, but I would also be interested into the readability of existing code in the wild etc. :)
Thank you in advance!
Are there modern languages which are require each line to be a statement? Apparently FORTRAN did this, but do any languages since C?
I've heard of Expression-oriented languages, including all functional programming languages, but I can't even find a term for the opposite, a "statement-oriented" language, or one that would not allow an expression, e.g. x + 3; or a call to a value-returning function without an assignment?
This is typical of low-level compiler intermediate languages, such as Three-adress codes.
I come from a background of C, Fortran, Python, R, Matlab, and some Lisp - and I've read a few things on Haskell. What are some neat ideas/examples in J or other languages from the APL family that are unique and not implemented in more common languages? I'm always interested in finding out what I'm missing...
J has a very large set of operators that make it easy to gin up complex programs without having to hunt for a library. It has extremely powerful array processing capabilities, as well as iterative constructs that make explicit control structures irrelevant for most purposes -- so much so that I prefer using tensor algebra to declaring an explicit loop because it's more convenient. J runs in an interpreter, but a good J script can be just as fast as a program written in a compiler language. (When you take out explicit loops, the interpreter doesn't have to compile the contents of the loop every time it executes.)
Another fun feature of J is tacit programming. You can build scripts without explicit reference to input variables, which lets you express an idea purely in terms of what you intend to do. For example, I could define the average function as 'summing the terms in a list and dividing them by the number of entries in the list' like so:
(+/ % #)
or I could make a script that slices into a 2D array and only returns the averages of rows that have averages greater than 10:
(10&<#])(+/%#)"1
There's lots of other neat stuff you can do with J; it's an executable form of mathematical notation. Ideas generalize easily, so you get a lot of benefit out of learning any one aspect of how the language works.
I think one of the most interesting aspects of J is that it is one of the very few non-von-Neumann languages that is even remotely mainstream.
Uhm. J mainstream? Well, yeah, compared to other non-von-Neumann languages it is! There are only very few non-von-Neumann languages to begin with, most of those only live inside some PhD thesis and were never actually implemented and those that were implemented usually have a userbase of 1 if even that. Generally, they are considered successful if at least one of the users doesn't sit on the same floor as the guy who invented it.
Compared to that, J is mainstream. In particular, J is based on John Backus's FP from his seminal Turing Award Lecture "Can Programming be Liberated from the von Neumann Style?" and it is AFAIK the only working implementation of it. (I don't think Backus ever actually implemented FP, for example.)
This is perhaps not as unique as I make it out to be, but the top feature I can think of for J is implicit typing. It creates that nice abstraction level above execution and memory management to focus on the data being processed.
Suppose you need to store a number:
var1 =: 10
And it's done. Array?
var2 =: 4 8 15 16 23 42
Done. Oh, but wait, you need to divide that by 3.7? Don't bother with casting, just go for it:
var2 % 3.7
Being rid of that necessity to cast and manipulate and allocate is a tiny blessing.
The Edison API and Core modules are the Haskell implementation of Purely Functional Data Structures
Do the F# and native .Net data structures cover use cases in the Edison API and Core sufficiently?
Would there be any benefit to trying to port the API and CORE Haskell modules to F#?
I haven't read the paper on edison, but if it's nothing more than the Haskell implementation of Purely Functional Data Structures, doesn't it make more sense to port the SML code that's in the book / thesis? It should be easier than porting Haskell code, which must be annotated for strictness, while F# will have to annotated for laziness.
The language used by the book is SML with syntax extensions for lazy evaluation. F# provides half of those extensions natively:
> let x = lazy 12;;
val x : Lazy<int> = <unevaluated>
> match x with
| Lazy(n) -> n;;
val it : int = 12
> x;;
val it : Lazy<int> = 12
To convert the book's fun lazy notation, change this:
fun lazy plus ($m, $n) = $m + n
To this:
let plus (m',n') = lazy (
match (m',n') with
| (Lazy(m), Lazy(n)) -> (lazy (m + n)).Force())
(See page 33 in the book). The differences from between SML and F# are minor syntax, so the translation should be easy.
As for whether it's worthwhile, most of the data structures in Okasaki's book are very specialised, so they are unlikely to exist already in .NET, even as F#'s immutable Set and Map. It would be worthwhile for the people that need those data structures.
Revisiting this question months later, I note that
http://lepensemoi.free.fr/index.php/tag/purely-functional-data-structures
someone has implemented lots of them on that blog.
I didn't follow the link, though I have at least a tiny familiarty with the work or Okasaki. So this whole answer is wildly speculative (I may be off base in my assumptions about what's in the Edison API).
I expect there is 'some benefit' in the sense that people like 'reference implementations of common FP data structures' in 'new languages' to help learn new languages.
As for the use in practice (rather than pedagogy), I expect that some of them are useful, though there are some F# and .Net APIs that may be as useful or more useful for many scenarios. The main couple 'batches' of overlapping functionality I would guess are the F# immutable collections (Set and Map), as well as the .Net 4.0 concurrent collections (like ConcurrentQueue).
Of course you'll also find some snippets on the web, like Jomo's immutable queue.
Wikipedia says Ruby is a functional language, but I'm not convinced. Why or why not?
Whether a language is or is not a functional language is unimportant. Functional Programming is a thesis, best explained by Philip Wadler (The Essence of Functional Programming) and John Hughes (Why Functional Programming Matters).
A meaningful question is, 'How amenable is Ruby to achieving the thesis of functional programming?' The answer is 'very poorly'.
I gave a talk on this just recently. Here are the slides.
Ruby does support higher-level functions (see Array#map, inject, & select), but it is still an imperative, Object-Oriented language.
One of the key characteristics of a functional language it that it avoids mutable state. Functional languages do not have the concept of a variable as you would have in Ruby, C, Java, or any other imperative language.
Another key characteristic of a functional language is that it focuses on defining a program in terms of "what", rather than "how". When programming in an OO language, we write classes & methods to hide the implementation (the "how") from the "what" (the class/method name), but in the end these methods are still written using a sequence of statements. In a functional language, you do not specify a sequence of execution, even at the lowest level.
I most definitely think you can use functional style in Ruby.
One of the most critical aspects to be able to program in a functional style is if the language supports higher order functions... which Ruby does.
That said, it's easy to program in Ruby in a non-functional style as well. Another key aspect of functional style is to not have state, and have real mathematical functions that always return the same value for a given set of inputs. This can be done in Ruby, but it is not enforced in the language like something more strictly functional like Haskell.
So, yeah, it supports functional style, but it also will let you program in a non-functional style as well.
I submit that supporting, or having the ability to program in a language in a functional style does not a functional language make.
I can even write Java code in a functional style if I want to hurt my collegues, and myself a few months weeks on.
Having a functional language is not only about what you can do, such as higher-order functions, first-class functions and currying. It is also about what you cannot do, like side-effects in pure functions.
This is important because it is a big part of the reason why functional programs are, or functional code in generel is, easier to reason about. And when code is easier to reason about, bugs become shallower and float to the conceptual surface where they can be fixed, which in turn gives less buggy code.
Ruby is object-oriented at its core, so even though it has reasonably good support for a functional style, it is not itself a functional language.
That's my non-scientific opinion anyway.
Edit:
In retrospect and with consideration for the fine comments I have recieved to this answer thus far, I think the object-oriented versus functional comparison is one of apples and oranges.
The real differentiator is that of being imparative in execution, or not. Functional languages have the expression as their primary linguistic construct and the order of execution is often undefined or defined as being lazy. Strict execution is possible but only used when needed. In an imparative language, strict execution is the default and while lazy execution is possible, it is often kludgy to do and can have unpredictable results in many edge cases.
Now, that's my non-scientific opinion.
Ruby will have to meet the following requirements in order to be "TRUELY" functional.
Immutable values: once a “variable” is set, it cannot be changed. In Ruby, this means you effectively have to treat variables like constants. The is not fully supported in the language, you will have to freeze each variable manually.
No side-effects: when passed a given value, a function must always return the same result. This goes hand in hand with having immutable values; a function can never take a value and change it, as this would be causing a side-effect that is tangential to returning a result.
Higher-order functions: these are functions that allow functions as arguments, or use functions as the return value. This is, arguably, one of the most critical features of any functional language.
Currying: enabled by higher-order functions, currying is transforming a function that takes multiple arguments into a function that takes one argument. This goes hand in hand with partial function application, which is transforming a multi-argument function into a function that takes less arguments then it did originally.
Recursion: looping by calling a function from within itself. When you don’t have access to mutable data, recursion is used to build up and chain data construction. This is because looping is not a functional concept, as it requires variables to be passed around to store the state of the loop at a given time.
Lazy-evaluation, or delayed-evaluation: delaying processing of values until the moment when it is actually needed. If, as an example, you have some code that generated list of Fibonacci numbers with lazy-evaluation enabled, this would not actually be processed and calculated until one of the values in the result was required by another function, such as puts.
Proposal (Just a thought)
I would be of great to have some kind of definition to have a mode directive to declare files with functional paradigm, example
mode 'functional'
Ruby is a multi-paradigm language that supports a functional style of programming.
Ruby is an object-oriented language, that can support other paradigms (functional, imperative, etc). However, since everything in Ruby is an object, it's primarily an OO language.
example:
"hello".reverse() = "olleh", every string is a string object instance and so on and so forth.
Read up here or here
It depends on your definition of a “functional language”. Personally, I think the term is itself quite problematic when used as an absolute. The are more aspects to being a “functional language” than mere language features and most depend on where you're looking from. For instance, the culture surrounding the language is quite important in this regard. Does it encourage a functional style? What about the available libraries? Do they encourage you to use them in a functional way?
Most people would call Scheme a functional language, for example. But what about Common Lisp? Apart from the multiple-/single-namespace issue and guaranteed tail-call elimination (which some CL implementations support as well, depending on the compiler settings), there isn't much that makes Scheme as a language more suited to functional programming than Common Lisp, and still, most Lispers wouldn't call CL a functional language. Why? Because the culture surrounding it heavily depends on CL's imperative features (like the LOOP macro, for example, which most Schemers would probably frown upon).
On the other hand, a C programmer may well consider CL a functional language. Most code written in any Lisp dialect is certainly much more functional in style than your usual block of C code, after all. Likewise, Scheme is very much an imperative language as compared to Haskell. Therefore, I don't think there can ever be a definite yes/no answer. Whether to call a language functional or not heavily depends on your viewpoint.
Ruby isn't really much of a multi-paradigm language either, I think. Multi-paradigm tends to be used by people wanting to label their favorite language as something which is useful in many different areas.
I'd describe Ruby is an object-oriented scripting language. Yes, functions are first-class objects (sort of), but that doesn't really make it a functional language. IMO, I might add.
Recursion is common in functional programming. Almost any language does support recursion, but recursive algorithms are often ineffective if there is no tail call optimization (TCO).
Functional programming languages are capable of optimizing tail recursion and can execute such code in constant space. Some Ruby implementations do optimize tail recursion, the other don't, but in general Ruby implementations are not required to do TCO. See Does Ruby perform Tail Call Optimization?
So, if you write some Ruby functional style and rely on TCO of some particular implementation, your code may be very ineffective in another Ruby interpreter. I think this is why Ruby is not a functional language (neither is Python).
Strictly speaking, it doesn't make sense to describe a language as "functional"; most languages are capable of functional programming. Even C++ is.
Functional style is more or less a subset of imperative language features, supported with syntactic sugar and some compiler optimizations like immutability and tail-recursion flattening,
The latter arguably is a minor implementation-specific technicality and has nothing to do with the actual language. The x64 C# 4.0 compiler does tail-recursion optimization, whereas the x86 one doesn't for whatever stupid reason.
Syntactic sugar can usually be worked around to some extent or another, especially if the language has a programmable precompiler (i.e. C's #define).
It might be slightly more meaningful to ask, "does language __ support imperative programming?", and the answer, for instance with Lisp, is "no".
Please, have a look at the beginning of the book: "A-Great-Ruby-eBook". It discusses the very specific topic you are asking. You can do different types of programming in Ruby. If you want to program like functionally, you can do it. If you want to program like imperatively, you can do it. It is a definition question how functional Ruby in the end is. Please, see the reply by the user camflan.