SoylentNews is people
SoylentNews
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: 3, Insightful) by bzipitidoo on Monday October 19 2015, @05:16AM
I am interested to see that details of the syntax are prominent in the list of highlights. Seems syntax is more important that it should be, because that's one of the basic issues that is still unsettled even after 60 years of programming language design. A difference such as the use of "begin" and "end" in Pascal, vs curly braces in C, is ultimately trivial, yet I much prefer the C syntax for its brevity and better internationality. A more important difference is that C has increment and decrement operators, and Pascal does not. An even more important difference is pointer arithmetic. Pointer arithmetic is one of the most distinctive features of C. Whether it's a good idea is debatable. Under the hood, there was the difference in how the two languages ordered items on the call stack. C has a little used keyword "Pascal", to tell the C compiler to use the Pascal order. Another difference that didn't stay under the hood is string handling. The C string library used the NULL character to terminate strings, while Pascal maintained a string length. (One trouble in Borland Pascal was that the string length was only 1 byte. Strings longer than 255 characters caused problems.) But these days, the old string library is pretty much deprecated in favor of C++ and the string handling methods used in the STL, which maintains a string length. Can't very well say that the details of string handling make for a distinctive feature of a language when it was never part of the core but instead was in an entirely separate library.
For an example of, well, the malleability of syntax and definitions, consider BASIC. A distinctive feature of BASIC is the line numbering, and of course the GOTO statement. Early versions of Microsoft BASIC had these features, but when they produced Visual Basic, they scrapped the line numbers and GOTOs. It really wasn't BASIC any more, it looked more like Pascal (or Modula) than BASIC. Is it that line numbers and GOTOs are not a distinguishing characteristic of BASIC after all? More like this was a marketing decision. Make up a structured programming language, take a few syntactic elements from BASIC, and declare that's close enough to BASIC to call it BASIC, to sell it to programming novices. They didn't stop there, they even threw in some OOP.
In case one wants to say that's just MS arrogance, maybe a better example is FORTRAN. Fortran has been greatly extended over the years. Fortran 77 is now the classic structured programming version. Since then, there's been 4 major updates, with the biggest perhaps being Fortran 2003 in which OOP was added to the language. Does that make it not Fortran anymore? C with OOP was not called C, it was given a new name, C++.
(Score: 0) by Anonymous Coward on Monday October 19 2015, @08:06AM
I've debated language design on other forums, and basically a lot comes down to personal preference. What bothers me doesn't bother others, and vice versa. Plus, different niches emphasize different things.
One thing that almost everyone agrees on if they think about it enough is that C has a stupid, archaic case/switch statement. Overloading "+" for math and string concatenation is a runner up. The deciders in both of those should be slapped. (Although, some of C's syntax was chosen for hardware-speed reasons of the time. The switch/case may fall into that.)
(Score: 0) by Anonymous Coward on Monday October 19 2015, @08:19AM
what's different with the C switch/case compared to say C#?
I took a look but didn't see much of a difference.
I use switch/case all the time in C#...
(Score: 0) by Anonymous Coward on Monday October 19 2015, @08:28AM
One is bloated and performs badly and other outputs a lean and clean jump table (or cascade of ifs - for small data sets) with zero overhead. I'll leave it as an excercise to the reader to guess which language does what.
(Score: 2) by pe1rxq on Monday October 19 2015, @09:09AM
C does not use + for string concatenation. I think you are confusing it with one of its younger (and saddly severely brain damaged) sibblings.
(Score: 0) by Anonymous Coward on Monday October 19 2015, @04:38PM
Sorry, I didn't mean to talk about C exclusively. I wasn't clear on the context, which was intended to be commonly found features of well-known languages. Note that many C-influenced variants have kept the old case/switch statement.
(Score: 2) by maxwell demon on Monday October 19 2015, @08:05PM
Whether you consider it a good idea or not, many programming languages use "+" for string concatenation. From this page [rosettacode.org] I guess that list includes at least the following languages:
>
The Tao of math: The numbers you can count are not the real numbers.
(Score: 2) by bzipitidoo on Tuesday October 20 2015, @12:54AM
I agree that C's switch statement is poor syntax. It's one of the gotchas that the execution path continues into the next case statement if there is no break statement. Ranks up near the newbie gotcha of using = when == was meant, and not getting any compiler error about the mistake because it is valid C to say "if (a=b)".
How about C's for statement? It doesn't look so bad at first, but there are some tricky details there too. A statement like "for (int i=0; i100; i++)" is an exception to the simple scoping rule that a variable is valid from the line where it is declared to the end of the block. "i" should only be valid within the body of the for statement. It was a bug in gcc up through version 2.7.2 that "i" was considered still in scope after the for block ended.
(Score: 4, Insightful) by TheRaven on Monday October 19 2015, @09:22AM
A difference such as the use of "begin" and "end" in Pascal, vs curly braces in C, is ultimately trivial, yet I much prefer the C syntax for its brevity and better internationality.
It also has a lower cognitive load. The human brain evolved to recognise symmetry as a defence against predators. If you see something symmetrical, it's probably the face of something that's trying to eat you. Spotting matched pairs of symmetrical symbols is one of the easiest things for the human visual system to do, without any conscious involvement. Matching pairs of 'begin' and 'end' requires a lot more mental effort. Not enough that you notice consciously, but enough that it's measurable in comprehension speed. Of course, by putting the open brace at the end of a line, rather than on its own line, aligned with the close brace, you can try to defeat the human visual system and make less readable C too.
C has a little used keyword "Pascal", to tell the C compiler to use the Pascal order
No it doesn't. In C, the order of parameter passing is undefined. As is the order of parameter evaluation, which often bites people. Some C implementations have a pascal keyword. Typical Pascal implementations push parameters onto the stack left to right (so the first argument is deepest on the stack) because Pascal does have defined evaluation order (left to right) and this is most efficient in a naive compiler (or one targeting p-code). Some, which are intended to be ABI-compatible with C, pass them in the other order. Most C compilers pass them the other way, because it's the easiest way of supporting variadics (the address of the first argument is the top of the stack, and all other arguments follow it). This is an ABI convention though, and not part of the language.
But these days, the old string library is pretty much deprecated in favor of C++ and the string handling methods used in the STL, which maintains a string length
Huh? The STL is deprecated too, though I presume that you mean the C++ standard library. Most C++ toolkits come with their own string class, because C++ strings are not very good, but even if they didn't, nothing in C is deprecated in favour of something in C++. They are different languages. This makes as much sense as saying that the socket APIs are deprecated in favour of XMLHttpRequest.
Make up a structured programming language, take a few syntactic elements from BASIC, and declare that's close enough to BASIC to call it BASIC, to sell it to programming novices
The original BASIC specification included gosub - BASIC has always supported structured programming. Visual BASIC also supports goto and line numbers (though they're not required, like many other BASIC dialects).
C with OOP was not called C, it was given a new name, C++.
C with OOP was called Objective-C. An entirely new language that shares a common subset with C and is designed for generic metaprogramming but also has some support for OOP was called C++.
sudo mod me up
(Score: 1, Insightful) by Anonymous Coward on Monday October 19 2015, @02:02PM
Some C implementations have a pascal keyword.
Well, that speaks to other reason why Pascal lost out. The creator of the language pretty much lost interest, or had only an academician's interest (similar to Tanenbaum and Minix), and moved onto to create another language based on the new O-O fad of the '80s. Successful languages generally have the creator who spends more than a decade shepherding the evolution and standardization of the language, addressing the inevitable shortcomings while putting up with industry politics and personality conflicts and all sorts of other nastiness.
Pascal didn't have that. They had a lead product, Turbo Pascal, which fell out of popularity after Windows 3.0 took over the PC market.
(Score: 1) by angelosphere on Monday October 19 2015, @09:35PM
At the time of Pascal, languages where not 'marketed'.
There was no reason for it.
The inventor btw. is Nicolaus Wirth. He invented more languages like, Modula, Modula II, Modula 3 and Oberon.
Researchers usually don't feel the need to 'market' languages.
(Score: 1) by nitehawk214 on Monday October 19 2015, @02:29PM
"syntax is more important that it should be" is like saying "grammar is more important than it should be".
Grammar is important because it is how we make sense of language. Poor grammar obfuscates meaning. Programming Languages with messy or vague syntax are difficult to read. Syntax was ultimately the downfall of Perl, languages with easier to understand syntax came along and replaced it. Instead of creating a flexible language for everyone, Perl became self-obfuscating.
I suppose it is no coincidence that I am particular about both grammar and code formatting.
"Don't you ever miss the days when you used to be nostalgic?" -Loiosh
(Score: 0) by Anonymous Coward on Monday October 19 2015, @03:56PM
Poor grammar obfuscates meaning.
Yes, but what is "poor grammar" to one person may be perfectly clear to someone else.
(Score: 3, Interesting) by darkfeline on Monday October 19 2015, @07:05PM
There is a universal syntax, though: Lisp
In all seriousness, I find that Lisp's simple syntax lets me fully focus on the semantics rather than the petty details of syntax. Also, not only does it make it easier to do metaprogramming (due to homoiconicity), but s-expressions can be easily converted to a different form and back, for example using a graphical tree or programming blocks interface that loads and saves from Lisp s-expressions.
Join the SDF Public Access UNIX System today!
(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!
(Score: 1) by angelosphere on Monday October 19 2015, @09:39PM
Erm ...
And that is the reason why I can mot cope with Lisp.
Everything in ( and ) makes it incomprehensible to me.
Everything a kind of list or graph makes it in-programmable for me.
Even the simplest problems cause me to do some brain acrobatics to formulate it in Lisp, if I'm at all able to do it.
I bottom line don't consider lisps syntax simple ... simple from the perspective of a computer program which is crafted to parse it ... perhaps.