Pascal vs C

If you were to give a language like Python static typing and make it a compiled language instead of interpreted, you basically end up with something like Pascal. So how would you rate Pascal's abilities compared to C? I know dynamic typing requires runtime checking, but would it be possible to have dynamic typing in a compiled language like Pascal?

x86 also does not know what type system is.
That's what she said.
LOL

>>38
I don't get why you have this irrational hate of runtime.
I don't hate runtime at all. I have only been saying that LISP (for example) needs a runtime. Assembler does not. That's it really. Why do you and others continue to interpret this observation as an attack on runtime dependency?

Are you agreeing or disagreeing with him?
He was trying, I think, to take a bite out of my example by applying it to assembler features. The problem I have with that is that assembler doesn't produce programs that perform type checking (unless the programmer implements it)--the compiler just does it the once and doesn't bother the machine with it.

>>42
I think it may be your tone (as we hear it). Textual communication has always had the problem that people can read a given passage in various ways and interpret the tone differently.

unless the programmer implements it
I think this may be another issue that people have with your statements. What you are saying is that Assembly doesn't have much in the way of pre-implemented features, which is technically correct. But many features are desirable and would in all likelihood be implemented in the assembly program anyway, and all you've done is interspersed them throughout the program instead of having them in a separate unit. I'd imagine that any serious Assembly programmer would have their own macros for adding them in, but at that point I don't think there is much difference between that and just instructing the compiler to remove the features you don't use like the Lisper was suggesting.

>>42
What are you arguing about, then? It's rather clear, that virtually every language which is more high level than assembly requires at least some runtime support. One may argue that in some languages the need for runtime is greater than in the others. If that's not your point, what really is, and why do we waste time on discussing it?

>>43
Forget my tone, just try reading all the words. IIRC >>42 is the third time I made it explicit in one way or another.

But many features are desirable and would in all likelihood be implemented in the assembly program anyway,
Yes, so? At least twice I illuminated that my point was just a technical observation that had the magical power of twisting panties everywhere. Panties are most certainly twisted. It's like the Pythagoreans vs. irrational numbers--it's only a problem if you can't get over it.

I don't think there is much difference between that and just instructing the compiler to remove the features you don't use
There is a difference. Gutting a language makes it something else, even if it still happens usable or even useful--and why would you do that just to say "look ma, no runtime!"--is it that important to you? It's not that important to me.

Using a library, however, doesn't change the language itself in any sense.

>>36
Lisp has eval built into the language. That pretty much necessitates the inclusion of a full interpreter in the runtime.
EVAL and COMPILE are part of the language, like a lot of features, but nothing stops you from not using them or removing them from the language. If you don't need them at run time, you can safely remove them.
>>37
My only point was that while it's common for a Lisp, or other high-level languages to have a runtime, it's also possible to not have a runtime in a high-level language, just like ASM doesn't require one, however you can of course use LIBC or kernel apis or whatever from ASM, if you wish.
>>38
I don't hate the runtime. I merely wanted to prove that it's possible for mid/high-level languages to not use the runtime, if you wish to do so. I've done it in C quite a few times. Never tried to do it in CL, but I'm aware of what the runtime consists of, so I can see that for certain applications(for example a crypto lib that doesn't depend on anything), you could technically eliminate it, if you wished.
>>42
I have only been saying that LISP (for example) needs a runtime.
While it may be common to have a runtime for it to be useful, there's no absolute need to have one, and if needed, one could make a runtime-less Lisp program.

>>45
Gutting a language makes it something else, even if it still happens usable or even useful--and why would you do that just to say "look ma, no runtime!"--is it that important to you? It's not that important to me.
True, i was just trying to prove a practical point that if you wanted, a program written in a mid/high-level language could have its runtime removed if it doesn't make use of it.
There are some uses from removing the runtime in certain cases (think embedded/bootloader/small demos/shellcode/etc), but those cases are rather rare.

In conclusion: It doesn't matter.

>>46
I still have a problem with arbitrarily taking a language subset and calling it the language proper. For example, I've never bothered to look into manual memory allocation in LISP (who would?) but:
it may be common to have a runtime for it to be useful, there's no absolute need to have one
I take it such a thing can be done without changing the language. Here's the rub: perhaps I don't write much LISP, but I really don't think you're writing LISP if you're forced to manage memory. If I have my history straight, LISP invented GC, and LISP machines were invented to perform GC. Sadly, we haven't invented automatic compile-time GC yet, so unless you're targeting a LISP machine you are going to need some runtime support for it.

But yes, I do agree that there are proper programs that use only a subset of their language and so do not require full language support. The split hair here is that it's not LISP itself that needs no runtime support, it's a collection of LISP programs (i.e. those restricted to a runtime-free subset of LISP) which can. (Actually I disagree with that but I mention  it for the sake of argument, the comment regarding GC notwithstanding.)

>>48
Fun fact: On old Lisp Machines the GC was kind of slow, so sometimes people used to turn it off to speed up the machine. (Of course, nowadays GCs are fairly fast.)

>>34
My other cpr is a crt!

Sorry, I'll go back to the imageboards now.

>>49
Fun fact#2 The GC was so slow on old Lisp Machines that if they turned GC off, they would have to let GC run all night to clean up the program they had run

>>51
Fun fact #3: This thread is titled Pascal vs C.

>>52
Fun fact #4: The fourth fun fact is a tautology.

>>53
XKCD QUALITY

sage
sage
sage