Slashdot Mirror

It's true that PHP include statements do not involve the merging of executable binary objects into a single native executable object. This does not change its fundamental nature that executable programs of PHP are loaded together (linked together) to form a single program. The fact that the defacto implementation of the PHP language is an interpreter rather than being a native machine language compiler does not change this. In fact language interpreters/translators/compilers are not an inherent property of any language, these are implementation specific decisions; one can write a C language interpreter and one may also write a Perl language -> machine executable code compiler if they wanted. Well the "PHP include system" loads in PHP files in the same fashion as a binary linker: the result is a full program that is loaded into memory as a single program as opposed to being dumped to disk file and a native executable object.

I really like PHP. It is however not a bloody programming language, it's a scripting language.

I really hate PHP, but what I hate even more is being confronted with this mysterious distinction between "scripting" and "programming" languages.

A language might be strongly or weakly, dynamically or statically typed. A particular implementation might employ a compiler, a virtual machine or interpreter. These are meaningful distinctions. But what (with the possible exception of a hardware specific control language) does it even mean for a language (as distinct from its implementation) to be a "scripting" language?

Would PHP cease to be a scripting language if an object code compiler were available for it? Is 'C' a "scripting language" just because it's interpreted? And what about a language which has never actually been implemented, what in the language specification determines unequivocally if that language is 'scripting' or a a 'programming' language?

For the most part the language doesn't matter that much. ADA, C, C++, PASCAL, BASIC, LISP...

let's be clear, for the most part, people who learned and write exclusively in interpreted languages are not programmers.

Spoken like a language bigot. In truth, the distinction between interpreted and scripted is pretty arbitrary. You can write in interpreted C or compiled Ruby.

I've met a lot of people who know a lot about interpreted languages, but they don't know why many of those languages are so bad with handling things like arrays and what their shortcomings are.

Funny, the languages I know that are the most painful to do array manipulation in are the compiled ones like C and Java.

While it's true that nothing is stopping someone from making a hardware Java bytecode running solution, the fact that it's possible doesn't make Java a non-interpreted language, any more than the fact that it's theoretically possible to create a hardware BASIC solution makes BASIC a non-interpreted language.

Hardware CPUs that run Java bytecode directly already exist and have done for years.

So Java is no more "interpreted" than C, which was designed for a specific architecture (the PDP), and is also available in interpreted forms and used to compile code which is run as bytecode. You can even compile C to Java bytecode.

Whether something is compiled or interpreted is not a function of the language, nor is it defined based on which CPU instruction set happens to be most popular at the moment.

#!/usr/bin/python
import urllib
import cPickle as c
import time

sn = "screename"

try:
scores = c.load(open("scores.pickle"))
except:
scores = []

s = urllib.urlopen("http://www.aimfight.com/getFight.p hp?name1=ashot&name2=%s"%sn).read()
sc = int(s.split("score2=")[1].split('&')[0])
scores.a ppend((sc,time.time()))
c.dump(scores, open("scores.pickle",'w'))
print "Content-type: text/plain\n\n"
print "\n".join([str(x[0]) for x in scores])

I'm not sure where the link in the article (http://www.softintegration.com.nyud.net:8090/) came from, but it wasn't working for me so I tried www.softintegration.com and that worked fine.

"...learning LUA takes exactly 1 hour."

I couldn't read the reference manual in one hour. I couldn't learn the quirks of co-routines in one hour.

I think there is a big, big misunderstanding about computer languages. The "quick and dirty" ones are incomplete and limited. The complete languages are necessarily complex. At one time, Perl was like Lua. Then it needed this and that until now it is beginning to be as complex as C++. The same will happen with Lua, I'm guessing, if it remains popular.

It seems that every self-motivated serious programmer writes at least one editor or one language or one compiler. Even I wrote a language and compiler -- for Hewlett-Packard data acquisition equipment.

I think Larry Wall didn't foresee the future when he started Perl. Did he begin Perl with the idea that it would eventually be object-oriented? Did he expect that he would spend his entire life developing his "report language"?

I'm tired of learning new languages. I don't see the point in it. I'll bet there are hundreds of thousands who learned Pascal in college who wish they had not wasted their time; except for Delphi, Pascal is dead.

For those who want an embedded scripting language, how about a C interpreter? Try Cint or Ch.

From a source of unknown and possibly questionable repute:

However, C was (and is) still highly useful and well worth keeping around, so a sort of extended C language was developed. This language was essentially "C and then some", or C-plus (C+). As the concepts of object-oriented programming continued to develop, C+ had to be upgraded, and became C++.

So I'm not the only one who was mistaken.

But with a little more research we find out Ch is C+. Not what I was thinking of, but interesting in its own way.

There is also a Small C+ sublanguage for developing on the Z88 portable computer. I haven't been able to find anything specifially about Small C+, but it seems to just be C with support for the proper address size on the Z88.

Of course, none of this is really what I thought I was talking about.
After spending a bit of time trying to vindicate myself, it looks like what I remember as C+ is actually a set of headers to implement object oriented-ness in C. This project is a little bit newer than I thought, but is probably what my brain was triggering on.

Try CH.

http://www.softintegration.com/