Page 3 of 3
Posted: Sun Oct 07, 2007 4:14 pm
by Combuster
I can't really call VB, Perl, Ruby, Lisp, and most other high level languages programming languages. They're scripting languages more than anything else. (With a few exceptions.) I'm not saying that they're not as intricate as C, for instance, or are inferior, but am suggesting that they do not compile directly to machine code
VB compiles to machine code. Theoretically you could even program an OS in it but it would be one big hell hacking at how microsoft implemented the runtime. The clones (powerbasic) would probably be easier to port.
There are oses written in lisp already.
and are therefore unpredictable
that implies that you can not rely on interpreted languages. I.e. PHP would have been dead by now.
IMNSHO scripting languages are just as much a programming language as any other. Their usability for OS development is not relevant.
Posted: Sun Oct 07, 2007 5:57 pm
by JackScott
I agree with Combuster.
Wikipedia wrote:
Programming languages are used to facilitate communication about the task of organizing and manipulating information, and to express algorithms precisely.
A programming language is (to me) anything that makes the programmer's life easier.
Posted: Sun Oct 07, 2007 9:39 pm
by Alboin
Combuster wrote:I can't really call VB, Perl, Ruby, Lisp, and most other high level languages programming languages. They're scripting languages more than anything else. (With a few exceptions.) I'm not saying that they're not as intricate as C, for instance, or are inferior, but am suggesting that they do not compile directly to machine code
VB compiles to machine code. Theoretically you could even program an OS in it but it would be one big hell hacking at how microsoft implemented the runtime. The clones (powerbasic) would probably be easier to port.
There are oses written in lisp already.
Yes, but, as you said, they rely on an often large standard library to function. There's a small line between being able to do something, and the practicality of doing something.
Combuster wrote:
and are therefore unpredictable
that implies that you can not rely on interpreted languages. I.e. PHP would have been dead by now.
IMNSHO scripting languages are just as much a programming language as any other. Their usability for OS development is not relevant.
In PHP, what does
compile to? In C, I know that
will roughly translate to a mov instruction. If I were to compile a PHP application, I really have no control over what my code generates, and even if I did have some knowledge, it would most probably be dozens of calls to and from the runtime. Because the language, more often than not, requires the runtime, and usually cannot run on bare hardware, I do not consider it a full blown programming language, but instead, a scripting language.
Posted: Mon Oct 08, 2007 3:17 am
by Combuster
Because the language, more often than not, requires the runtime, and usually cannot run on bare hardware, I do not consider it a full blown programming language, but instead, a scripting language.
C++ depends on a runtime. Therefore C++ isn't a programming language. I suggest you choose your arguments a bit more careful.
I'll leave now since this pointless discussion will only lead to a holy war. If you refuse to call something the way the majority does then it is entirely your problem.
Posted: Mon Oct 08, 2007 5:23 am
by Solar
Combuster wrote:C++ depends on a runtime.
So does C.
I tend to distinguish between "system" languages (ASM, C, C++, ...), "application" languages (Java, VB, ...), and "scripting" languages (Perl, PHP, ...). I admit it gets fuzzy around the edges, but I'd never get so far as to deny e.g. VB the status of "programming" language. Whether I'd use it voluntarily is another matter.
Posted: Mon Oct 08, 2007 9:22 am
by Alboin
Combuster wrote:Because the language, more often than not, requires the runtime, and usually cannot run on bare hardware, I do not consider it a full blown programming language, but instead, a scripting language.
C++ depends on a runtime. Therefore C++ isn't a programming language. I suggest you choose your arguments a bit more careful.
I'll leave now since this pointless discussion will only lead to a holy war. If you refuse to call something the way the majority does then it is entirely your problem.
I do realize that both C\C++ have a runtime, but they are small (For the most part.), and in C and most of C++, the core language does not depend on them.
If VB is truly a programming language, then so is Perl, PHP, Ruby, and Python, as they all can be compiled. What then, is a scripting language?
Posted: Mon Oct 08, 2007 5:35 pm
by JackScott
Perhaps they are a subset of programming languages? Why do they have to be mutually exclusive?
Posted: Mon Oct 15, 2007 1:23 pm
by Crazed123
C# is really a Delphi successor with C-like syntax. M$ actually hired away the chief architect of Delphi to design C#.
Bastards.
Posted: Tue Oct 16, 2007 8:00 am
by AndrewAPrice
Alboin wrote:
In PHP, what does
compile to?
It'll equivalent of C's strcpy or C++'s std::string::operator =. C and PHP also handle variables differently. In C, variables are references to a point in memory, and you cannot change their type once you define it (well, there is type casting). In PHP, the interpreter keeps a list of variables, along with their name, value, and the sort of data they hold (array, text, or numeric), and you can freely convert data between different types, or append an unlimited number of characters on to the end of a string after it has been defined, because in PHP it is up to the interpreter to handle memory management, not the programmer (this is somewhat easier in C++ with the use of streams and strings).
Posted: Tue Oct 16, 2007 9:06 am
by Solar
All true, but it does mean that, to use e.g. Perl in systems programming, you'd either have to cripple the language (effectively using a "custom" language, IMHO A Bad Thing (tm)), or live with the fact that you simply cannot trust even the effective address of a value to stay the same...
Posted: Wed Oct 17, 2007 1:26 am
by AndrewAPrice
Maybe a pointer goes by some internal ID rather than memory address?