On one of those Simtel CDs I found Jorf. (Josephine's Recipe Filer). It was a OO language, with an interpreter for DOS or Windows, and it supported stuff that was really advanced for the time, and it made my coding a lot simpler.
Out of nostalgy, I downloaded a copy (yes, it is still there), and ran it in DosBOX (yes, it still works), to check if it was as good as I remembered.
You know what? It is.
In fact, if it had come out 2 or three years later, and as free software instead of shareware... I think it would have been big.
Here are some highlights og the language:
OOP
Has integrated windowing toolkit (for DOS and Windows)
It had an interactive hypertext/windowing tutorial written in itself. In 1993.
It looks like a cousin of Python. A freaky cousin, though.
-Comments start with |
-Strings limited with single or double quotes
-Automatic type conversions
-Intentation controls flow :-)
-No declared data types
-Integrated editor and debugger
The article author's native language seems to not be English, but it's a fun little piece on a language that might have been.
(Score: 2) by bzipitidoo on Monday October 19 2015, @08:32PM
I know there's a Lisp community with near fanatical love for the language. And it is a good language. But a major criticism of Lisp is too many parentheses. Most programming languages use 2 forms of function call syntax, an explicit one, and for mathematical operations the classic infix style that was in use long before computers existed. Mathematical notation is more compact and clearer, and it works thanks to the use of several conventions. Arithmetic operators take a limited, fixed number of parameters, so there is no need to delimit the start and end of a parameter list. Because the operator is in the middle, it even serves the additional purpose of being a separator, no need to employ a comma or even a blank space. There's also operator precedence, which allows more brevity.
But Lisp doesn't use any of that, it uses only the first form, an explicit function syntax which always requires parentheses, whether they are really needed or not. That makes the language easier to implement and parse and all, but it sure adds to the visual clutter. A mathematical expression such as "d = a + b * c" can be written as almost exactly that in C and Java (need a semicolon at the end), Pascal (using := for assignment), Python, and many others. But in Lisp it has to be encoded as something like "(set d (+ a (* b c)))". Ugly. 3 sets of parentheses required where none were truly needed.
Trouble is, in all those other languages, the support for mathematical syntax is limited. Can define as many functions as desired, cannot define more operators. What's the difference between an operator and a function? Semantics, that's all. Operator overloading, which is an acknowledgement of their equivalence, barely scratches the surface of what is needed to really support the form of function call syntax based on mathematical notation.
(Score: 3, Interesting) by darkfeline on Tuesday October 20 2015, @10:14AM
I'm sure you can see this coming, but macros can solve that problem: (set x (math a + b * c))
Or hell: (c-syntax x = a + b * c ;)
(Yes, semicolon is the comment symbol. Semicolon is still a valid symbol name internally, you just need to get the reader to parse it.)
Lisp is a "pure" language. Every language, when compiled or interpreted, will get parsed into a tree form that is essentially similar to Lisp. I think that makes Lisp a"universal syntax.
Also, since Lisp is pure, it doesn't necessarily need to use parens. You could very well write Lisp like this:
set x
+ a
* b c
Or:
set(x, add(a, multiply(b, c)));
In fact, I would bet a pretty nickel that most Lisp programmers have tried something like this at least once (just google "Lisp without parens"). Most, if not all, go back to the parens, because the Lisp enlightenment is realizing that the syntax doesn't matter. You can use parens, you can use indentation, you can use emoticons, but it's still distinctively Lisp. It exists in the pure form that other languages need to be translated into during compilation or interpretation.
I actually don't use Lisp very much, but I know that there's a reason Lisp fanatics love Lisp. Once you "get it", other languages will seem, well, lesser.
Join the SDF Public Access UNIX System today!