I am beginning to feel like an idiot by actually making my own interpriter from scratch .. Dou!

Well, don''t feel like an idiot for making it. Feel like an idiot if you think the world is going to embrace your language and use it :-)

But it''s good to learn a few languages and try implementing the techniques in your own toys.

quote:

---

Original post by Indeterminatus
I absolutely dislike the idea of skipping a definition keyword. if you have x = y; create a new variable, that might seem quite handy, but there is one very huge drawback (just thinking of actionscript in flash). if you spell a variable only slightly wrong, that would lead to a very hard to debug code, since a new variable would be created without any warning / error.

myfancyvariable = 3;

myfnacyvariable = 5; // spelled wrong --> new variable

print(myfancyvariable);

---

Simply have a warning for ''singleton'' variables which are the variables whose identifiers are only used once. You''ll have to spell it incorrectly twice for the system not to catch it. Languages like Prolog and ML use this and just infer the types from usage and they are very concise.

This is just a general comment, but people really shouldn''t design languages so that they are easy to parse, which a few people have suggested in various ways. You should make it as easy as possible for the code writer to use and not require them to do things that the computer could work out itself. For example, use a two pass parser to eliminate the header files, prototypes and forward declarations from C/C++ to make the user more productive.

Well, it might seem like it''s easier for non-programmers to not declare variables, but in reality it''s not. I remember before I started to actually program, I did some stuff using the scripting language of a game called Graal, and you didn''t have to declare variables. Guess what - most of my time was spent looking at the variables list, looking for spelling errors. Duh. I could just as easily have written the same list in the script, and know when I made a mistake typing a variable. Same thing when I started with VB, I ended up always using "option explicit" (requiring you to explicitly declare variables). It made debugging so much easier, and for a non-programmer/newbie anything that helps debbugging totally rocks

Also, variants should be allowed cuz some people just can''t get used to types, but you shouldn''t totally discard them. They not only make everything run a lot faster, but are also another great help when debugging. So you''re adding up 2 variables or whatever... but wait, one of them is actually a string. It''s even worse if the string looks like a number and it''s totally wrong. Those errors are a pain to trace. It would be much easier to just have an error saying "you can''t assign a string to an int here"; that''s easy to fix. And I''m sure anyone can say if a variable should hold the player name or some number. That''s why they have names

I''m sorry if this ended up looking like a rant; it isn''t. It''s just my opinion, I think that some stuff don''t need to be any more complicated than they are.

quote:

---

Original post by Jotaf
Well, it might seem like it''s easier for non-programmers to not declare variables, but in reality it''s not.

---

Read the post before yours.

quote:

---

Also, variants should be allowed cuz some people just can''t get used to types...

---

The benefits you assign to variants aren''t really a function of variants at all. The fact that type is dynamic does not prevent it from being strong. Python, for example, has a TypeError exception. If you want to write an API that requires, for example, a string parameter, use isinstance() to verify the type of the supplied argument and throw a TypeError if it fails. This places the burden of complexity on the API author as opposed to the API user - and the users are usually the less skilled ones, so this is as it should be.

quote:

---

Original post by Oluseyi

quote:

---

Also, variants should be allowed cuz some people just can''t get used to types...

---

The benefits you assign to variants aren''t really a function of variants at all. The fact that type is dynamic does not prevent it from being strong. Python, for example, has a <tt>TypeError</tt> exception. If you want to write an API that requires, for example, a string parameter, use <tt>isinstance()</tt> to verify the type of the supplied argument and throw a <tt>TypeError</tt> if it fails.

---

I''ve not used Python before, but it looks like a shift of compile time errors to runtime errors (ie the compiler tells you the parameter type is wrong as oppose to the executing code throwing an exception at the point of the error). It really depends on the task, but for robust programs, I''d much prefer the compile time errors as you have to exercise all the control paths to find the runtime errors, which is a pain and not very feasible for big programs. That is, unless you can do some kind of static checking based on the possible types a variable could change to during runtime. For a scripting language though, the scripts should be short, concise and readable as a priority.

quote:

---

Original quote by Anonymous Poster
I''ve not used Python before, but it looks like a shift of compile time errors to runtime errors (ie the compiler tells you the parameter type is wrong as oppose to the executing code throwing an exception at the point of the error). It really depends on the task, but for robust programs, I''d much prefer the compile time errors as you have to exercise all the control paths to find the runtime errors, which is a pain and not very feasible for big programs. That is, unless you can do some kind of static checking based on the possible types a variable could change to during runtime. For a scripting language though, the scripts should be short, concise and readable as a priority.

---

Yes, this is the tradeoff between static and dynamic typing. Static typing will pick up certain classes of error at compile time, whereas dynamic typing will usually wait until runtime. Of course that is a very simplistic viewpoint, it is perfectly possible for a compiler to analyse a program written in a dynamically typed language and detect some inconsistencies (depending on the semantics of the language).

IMO (strong) dynamic typing is what a scripting language should provide, but it should be pushed way into the background so you virtually never have to notice that a type system is being employed.

Then again, OCaml (my pet example, you can find others) is extremely concise and readable and yet is strongly statically typed.

quote:

---

Original post by Anonymous Poster
I''ve not used Python before, but it looks like a shift of compile time errors to runtime errors (ie the compiler tells you the parameter type is wrong as oppose to the executing code throwing an exception at the point of the error).

---

Depends on if you interpret or JIT, and on if the type can be fully determined at compile time. It is possible for a compile-time error to be the first line of defense, with a runtime error as a backup.

quote:

---

It really depends on the task, but for robust programs, I''d much prefer the compile time errors as you have to exercise all the control paths to find the runtime errors, which is a pain and not very feasible for big programs.

---

I think the folks at TwistedMatrix (of Twisted Python fame) would beg to differ. I also think the various projects profiled at Pythonology would take exception with your assertion.

Besides, that''s what testing frameworks exist for, and they''re far more powerful with a dynamically-typed, self-documenting and reflection-capable language.

quote:

---

Original post by Oluseyi
I think the folks at TwistedMatrix (of Twisted Python fame) would beg to differ. I also think the various projects profiled at Pythonology would take exception with your assertion.

Besides, that''s what testing frameworks exist for, and they''re far more powerful with a dynamically-typed, self-documenting and reflection-capable language.

---

I''m not disagreeing with you, but I don''t understand how a dynamically typed language can be more robust than a statically typed one, in the sense of detecting typing errors. Testing frameworks are there to catch bugs and are crucial for any serious projects, but I''d rather the computer did the labourious and obvious tests for me (ie checking the types are ok).

With the dynamic typing, I''ll have to write a test to try every conceivable control path the program would take and all the possible permutations of input/output parameter types for each function. Even if you fill up your testbed with numerous typing tests (which would be time consuming), there''s still nothing to guarentee that you didn''t missed something and have a runtime error bring down your program during execution.

For example, C++ templated containers give me a greater feeling of safety than Java''s generic containers that can contain multiple types when you virtually always only want one class (or subclass) to be in there. Then there''s languages like Prolog where predicates silently fail with no solutions when you get the types wrong (or give you unexpected solutions), making debugging a nightmare. I find complex and clever languages features quite fun and elegant for short programs, but as they get larger, I prefer more constrainted and easy to understand behaviour in terms of possible inputs and outputs to limit unexpected errors from creeping in. I haven''t used dynamically typed languages for large projects before, so if anyone disagrees, I''d be open to change my views given enough good reasons.

quote:

---

Original post by seanw
I''m not disagreeing with you, but I don''t understand how a dynamically typed language can be more robust than a statically typed one, in the sense of detecting typing errors.

---

I never said it was, at least as far as detecting typing errors. But what proportion of errors are due strictly to typing? Did static typing and compile-time error checking detect that NASA''s engineers were using feet/sec rather than meters/sec (or whatever) and thus save us a satellite/space probe? Obviously not.

It''s a matter of tradeoffs, and where greater emphasis is placed on readability, learnability, correctness, extensibility, flexibility... runtime evaluation (or as close to runtime as possible) wins.

quote:

---

Testing frameworks are there to catch bugs and are crucial for any serious projects, but I''d rather the computer did the labourious and obvious tests for me (ie checking the types are ok).

---

Rather than arguing the point further, I''d recommend you try it before knocking it. Only through personal experience have I come to appreciate/respect the abilities of a well-designed, dynamically-typed, strong-typing language.

With the dynamic typing, I''ll have to write a test to try every conceivable control path the program would take and all the possible permutations of input/output parameter types for each function. Even if you fill up your testbed with numerous typing tests (which would be time consuming), there''s still nothing to guarentee that you didn''t missed something and have a runtime error bring down your program during execution.

quote:

---

For example, C++ templated containers give me a greater feeling of safety than Java''s generic containers that can contain multiple types when you virtually always only want one class (or subclass) to be in there.

---

That''s really a function of C++''s approach toward type. Coercion is pretty easy (particularly with pointers), so static type checking is necessary to avoid catastrophic results. It is also a function of the level that C++ targets: an absurdly low one for people interested in end-user domain applications. Do I really need bit-twiddling as a pervasive language feature if I''m writing a word processor? A spreadsheet? A web browser? All I need is a standard library module/function that permits me to do so on the rare occasions I need it - loading and writing binary data and a few other instances.

quote:

---

I find complex and clever languages features quite fun and elegant for short programs, but as they get larger, I prefer more constrainted and easy to understand behaviour in terms of possible inputs and outputs to limit unexpected errors from creeping in.

---

I concur. There is nothing intrinsic about dynamically-typed languages that makes them "complex" or "clever", however; such attributes are functions - or failures - of overall language design. Python takes the philosophy that a feature should be both simple to understand/use and to program by the developers.

quote:

---

I haven''t used dynamically typed languages for large projects before, so if anyone disagrees, I''d be open to change my views given enough good reasons.

---

It''s not a big deal, but if you ever get the chance to, give it a shot.