I believe that Rails does qualify as self-modifying. There is code doesn't exist at design time. Nor can I step into with a debugger at run time, because there is no associated source file.
That isn't self-modifying code, that's generation of code at runtime. Runtime code generation is ugly (better to do it at compile time with macros, as in Lisp), but it's not self-modifying code. "Self-modifying code" is usually used to refer to assembly language hacks where you (say) overwrite an adress in part of your code to change where a jump instruction jumps to.
I think it's a category error to say that a usage is wrong. One often hears people say that C has pass-by-value and pass-by-reference, and it's perfectly clear what they mean.
As for whether I understand the difference, it should have been clear that I do from the bracketed portion of my first reply to you.
Neither pass by reference nor arrays explain how the underlieing system works. Pointers do.
This is often stated but never explained. It's rubbish for a number of reasons. First, an array is a pretty good model of the underlying system. It's a linear block which can be indexed. The reference to the array is (amongst other things) a reference to the place where the block starts.
Second, C pointers are a fairly good model of a PDP11's memory architecture, but they abstract away from a lot of facts about the underlying system, such as memory segmentation/paging, and the fact that if you add 1 to a pointer to a 32-bit int, you actually get a pointer to the second byte of that integer, not the the next integer along in an array.
As I said previously, many other languages have everything C does except pointer arithmetic, and pointer arithmetic isn't really fundamental to the way in which arrays are implemented at a lower level.
Finally, it's just nonsense to state that you can't write good code without understanding the nitty-gritty of memory alllocation. You just need a basic understanding of the space behaviour of the data structures your language supports, however low-level or high-level it is. In C, this translates into a knowledge of memory allocation at a low level, because C is a low-level language, but in a high-level language it doesn't.
Wow, you're so wrong. Objects are always passed by reference, primitive types are always passed by value. (Or if you like, everything's passed by value, but there's no such thing as an object value, so you have to pass an object reference by value...)
Oh come off it. Every language (almost) has pass by reference and arrays. The only extra thing C has is pointer arithmetic, and you don't need to know anything about pointer arithmetic in order to write non-buggy and efficient code. In fact, code using pointer arithmetic tends to be slower these days, because it's hard for compilers to optimise.
And indeed the Mafia are rather effective at limiting organised crime, since they squash other criminal organisations quite effectively. The point is that in any market, there's a natural tendency for someone to have a monopoly. The only way to prevent this (in some cases) is to have a powerful organisation prevent it from happening. This organisation can either be democratic (i.e. a government) or a mafia/dictatorship of some kind. Take your pick.
While you're working out who's to blame, the rest of us -- living somewhere in the vicinity of the real world -- are trying to work out how to fix real problems without ideological blinders.
There's nothing to it, it's just a subset of the Javascript literal syntax which happens to have a lot of library/community support (i.e. you don't have to roll your own Perl parser/generator library, or whatever).
Because the scoping itself works fine. The problem lies with variable assignment and declaration in Python being ambiguous when dealing with multiple scopes.
But if the syntax for assigning variables doesn't work nicely with lexical scoping, I think it's reasonable to say that something to do with lexical scoping isn't working properly. If Python would change it's lexical scoping rules slightly, the problem would be fixed without changing the assignment syntax. (Essentially, you could have the system work such that every line of a function introduced a new nested scope).
This is why I say incomplete, and not broken. By the same standards, I say that Perl's object model is incomplete, rather than broken. If you claim that Python's closures are 'broken', then you must also accept that Perl's object model is 'broken'.
I don't see why, given that there aren't any standard OO features missing from Perl (with the exception of enforced public/private access, but that's missing from Python too). Arguing over the definitions of "broken" and "incomplete" seems pointless to me. I've made it clear what I think is wrong with Python's closures, you can call it what you like.
When last I looked, Perl didn't treat scalars, hashes and arrays as objects.
No, but you can create your own classes which use the special syntax for built-in types (e.g. you can create your own hash class, see man perltie). IIRC, the class you create doesn't technically inherit from a standard hash class, but since Perl is a dynamic dispatch language this doesn't have any practical consequences (other people can use your custom hash object just as if it were a real Perl hash). Python's treatment of builtins has some quirks anyway, since it's only recently they've become true Python classes ("len" is not a method, etc.)
. And on the subject of things Perl doesn't have, as far as I know, it has no metaclass support, either.
Well, you can create classes programmatically, so in effect it does. See the Class::Struct module, for example, which generates structure-like classes. Perl has pretty much everything in terms of OO (including for example the ability to trap calls to non-existent methods). The syntax is a little clunky, but the actual functionality is easy enough to use.
Only in the scope of a single function, and realistically speaking, if your functions are so long that you don't know whether a local variable has been assigned or not, then perhaps your function is too long, anyway. Certainly when I'm programming in Python, functions tend to be under a dozen lines long.
True, but that basically amounts to saying "lexical scope isn't particularly useful". You have a point here I admit -- it's easy enough to get along in a language with little or no lexical scoping (e.g. C, prior to C99). But it's still anoying that closures are so limited in Python, if you like functional programming, as I do.
How is it not a problem with lexical scoping? The assignment is ambiguous because of the way lexically scoped variable declarations (don't) work in Python. Whether this is a problem with lexical scoping itself or the syntax of variable assignment in Python is really a meaningless question, since it's a problem resulting from the combination of the two. Definitional questions aside, I don't want to work in a language with "incomplete" closures when there are better alternatives.
Perl has a perfectly well-defined object model. Not sure what you mean by that. If you just mean that Python has a nicer object model, then I agree up to a point, but Perl's is at least as powerful. I don't much like OO anyway, I'm more of a functional programmer.
Ruby's OK, but it's slower than Perl, and it can't get lexical scoping quite right either.
The thing is that it's really more-or-less impossible to have satisfactorary scoping rules without explicit variable declarations. Even ignoring Python's problems with closures, you still have the problem that whenever you write "a = b", you can't be sure whether you're binding a new variable, or assigning a new value to an existing variable. (Same applies to Ruby).
So overall, I prefer Perl. It might not be as buzzword-compliant as Python or Ruby, but it doesn't try to run before it can walk.
I'm afraid it is still true. Lexical scoping has never been properly fixed in Python in relation to closures. See this link for an excellent explanation. Perl does lexical scoping just fine, and I like explicit variable declarations, even in a scripting language.
An armed population is the last defence against despotism.
Except when the gun freaks tend to be supporters of the most despotic government in recent American history, that is.
Hey, why not go the whole way and let everyone own tanks and ICBMs. It would be unconstitutional to prevent them, of course.
And yes, gun control in Europe is a massive feadalist conspiracy (and we thought you wouldn't notice!) Although that you might want to consider the fact that it's actually the more wealthy people in Europe who tend to be in favour of gun ownership, not us salt-of-the-earth serf types.
Just because guns aren't the only offensive weapon in existence doesn't mean that banning them doesn't make it more difficult to kill people. Despite what you say, there are very few weapons as dangerous as guns generally available in a modern society.
You should also be aware that gun crime in the UK is going down. It's just that crimes with fake guns are normally included in the statistics, and there has been a sharp rise in fake gun crime (presumably because, contrary to what you suggest, making guns illegal makes it much harder for small-time criminals to get hold of them!)
But it's only your money to spend because of the infrastructure provided by the government. After all, if it wasn't for the government, those coins in your pocket would only be worth their value in scrap metal. So I think in the case of money, and other forms of property which are facilitated and protected by the government, it's arguable that people don't have an absolute, inviolable right of ownership.
(You may say that a currency could be maintained by a private institution, and perhaps it could, but right now US dollars aren't.)
How so? They're based on the mathematical concept of a function. It so happens that you can hack together this abstractiion using templates and interfaces in C++ or whatever (though you can't really have proper closures, and the syntax is ghastly). How would you write a template/interface-based version of the following?
Slashdot Mirror
I believe that Rails does qualify as self-modifying. There is code doesn't exist at design time. Nor can I step into with a debugger at run time, because there is no associated source file.
That isn't self-modifying code, that's generation of code at runtime. Runtime code generation is ugly (better to do it at compile time with macros, as in Lisp), but it's not self-modifying code. "Self-modifying code" is usually used to refer to assembly language hacks where you (say) overwrite an adress in part of your code to change where a jump instruction jumps to.
As for whether I understand the difference, it should have been clear that I do from the bracketed portion of my first reply to you.
OK, but by your logic C doesn't have pass-by-reference either, contrary to normal usage of the phrase.
Neither pass by reference nor arrays explain how the underlieing system works. Pointers do.
This is often stated but never explained. It's rubbish for a number of reasons. First, an array is a pretty good model of the underlying system. It's a linear block which can be indexed. The reference to the array is (amongst other things) a reference to the place where the block starts.
Second, C pointers are a fairly good model of a PDP11's memory architecture, but they abstract away from a lot of facts about the underlying system, such as memory segmentation/paging, and the fact that if you add 1 to a pointer to a 32-bit int, you actually get a pointer to the second byte of that integer, not the the next integer along in an array.
As I said previously, many other languages have everything C does except pointer arithmetic, and pointer arithmetic isn't really fundamental to the way in which arrays are implemented at a lower level.
Finally, it's just nonsense to state that you can't write good code without understanding the nitty-gritty of memory alllocation. You just need a basic understanding of the space behaviour of the data structures your language supports, however low-level or high-level it is. In C, this translates into a knowledge of memory allocation at a low level, because C is a low-level language, but in a high-level language it doesn't.
Wow, you're so wrong. Objects are always passed by reference, primitive types are always passed by value. (Or if you like, everything's passed by value, but there's no such thing as an object value, so you have to pass an object reference by value...)
Oh come off it. Every language (almost) has pass by reference and arrays. The only extra thing C has is pointer arithmetic, and you don't need to know anything about pointer arithmetic in order to write non-buggy and efficient code. In fact, code using pointer arithmetic tends to be slower these days, because it's hard for compilers to optimise.
And how exactly would you implement Rails' reflective object/database mapping in C?! Takes more than a string library.
But instead off using all this horrid C libraries, you could just write in a language which actually supported some high-level idioms.
And there's a lot of very useful stuff (e.g. functional programming) that you just can't do in C.
And indeed the Mafia are rather effective at limiting organised crime, since they squash other criminal organisations quite effectively. The point is that in any market, there's a natural tendency for someone to have a monopoly. The only way to prevent this (in some cases) is to have a powerful organisation prevent it from happening. This organisation can either be democratic (i.e. a government) or a mafia/dictatorship of some kind. Take your pick.
While you're working out who's to blame, the rest of us -- living somewhere in the vicinity of the real world -- are trying to work out how to fix real problems without ideological blinders.
If you want to be precise, why do you say "irregardless"?
There's nothing to it, it's just a subset of the Javascript literal syntax which happens to have a lot of library/community support (i.e. you don't have to roll your own Perl parser/generator library, or whatever).
If the soldiors aren't serving for the money, how do you account for the disproportionate numbers of (formerly?) poor people in the army?
Because the scoping itself works fine. The problem lies with variable assignment and declaration in Python being ambiguous when dealing with multiple scopes.
But if the syntax for assigning variables doesn't work nicely with lexical scoping, I think it's reasonable to say that something to do with lexical scoping isn't working properly. If Python would change it's lexical scoping rules slightly, the problem would be fixed without changing the assignment syntax. (Essentially, you could have the system work such that every line of a function introduced a new nested scope).
This is why I say incomplete, and not broken. By the same standards, I say that Perl's object model is incomplete, rather than broken. If you claim that Python's closures are 'broken', then you must also accept that Perl's object model is 'broken'.
I don't see why, given that there aren't any standard OO features missing from Perl (with the exception of enforced public/private access, but that's missing from Python too). Arguing over the definitions of "broken" and "incomplete" seems pointless to me. I've made it clear what I think is wrong with Python's closures, you can call it what you like.
When last I looked, Perl didn't treat scalars, hashes and arrays as objects.
No, but you can create your own classes which use the special syntax for built-in types (e.g. you can create your own hash class, see man perltie). IIRC, the class you create doesn't technically inherit from a standard hash class, but since Perl is a dynamic dispatch language this doesn't have any practical consequences (other people can use your custom hash object just as if it were a real Perl hash). Python's treatment of builtins has some quirks anyway, since it's only recently they've become true Python classes ("len" is not a method, etc.)
. And on the subject of things Perl doesn't have, as far as I know, it has no metaclass support, either.
Well, you can create classes programmatically, so in effect it does. See the Class::Struct module, for example, which generates structure-like classes. Perl has pretty much everything in terms of OO (including for example the ability to trap calls to non-existent methods). The syntax is a little clunky, but the actual functionality is easy enough to use.
Only in the scope of a single function, and realistically speaking, if your functions are so long that you don't know whether a local variable has been assigned or not, then perhaps your function is too long, anyway. Certainly when I'm programming in Python, functions tend to be under a dozen lines long.
True, but that basically amounts to saying "lexical scope isn't particularly useful". You have a point here I admit -- it's easy enough to get along in a language with little or no lexical scoping (e.g. C, prior to C99). But it's still anoying that closures are so limited in Python, if you like functional programming, as I do.
How is it not a problem with lexical scoping? The assignment is ambiguous because of the way lexically scoped variable declarations (don't) work in Python. Whether this is a problem with lexical scoping itself or the syntax of variable assignment in Python is really a meaningless question, since it's a problem resulting from the combination of the two. Definitional questions aside, I don't want to work in a language with "incomplete" closures when there are better alternatives.
Perl has a perfectly well-defined object model. Not sure what you mean by that. If you just mean that Python has a nicer object model, then I agree up to a point, but Perl's is at least as powerful. I don't much like OO anyway, I'm more of a functional programmer.
Ruby's OK, but it's slower than Perl, and it can't get lexical scoping quite right either.
The thing is that it's really more-or-less impossible to have satisfactorary scoping rules without explicit variable declarations. Even ignoring Python's problems with closures, you still have the problem that whenever you write "a = b", you can't be sure whether you're binding a new variable, or assigning a new value to an existing variable. (Same applies to Ruby).
So overall, I prefer Perl. It might not be as buzzword-compliant as Python or Ruby, but it doesn't try to run before it can walk.
I'm afraid it is still true. Lexical scoping has never been properly fixed in Python in relation to closures. See this link for an excellent explanation. Perl does lexical scoping just fine, and I like explicit variable declarations, even in a scripting language.
Because Python has broken lexical scoping!
Oops, "feadalist" -> "eudalist"
An armed population is the last defence against despotism.
Except when the gun freaks tend to be supporters of the most despotic government in recent American history, that is.
Hey, why not go the whole way and let everyone own tanks and ICBMs. It would be unconstitutional to prevent them, of course.
And yes, gun control in Europe is a massive feadalist conspiracy (and we thought you wouldn't notice!) Although that you might want to consider the fact that it's actually the more wealthy people in Europe who tend to be in favour of gun ownership, not us salt-of-the-earth serf types.
Just because guns aren't the only offensive weapon in existence doesn't mean that banning them doesn't make it more difficult to kill people. Despite what you say, there are very few weapons as dangerous as guns generally available in a modern society.
You should also be aware that gun crime in the UK is going down. It's just that crimes with fake guns are normally included in the statistics, and there has been a sharp rise in fake gun crime (presumably because, contrary to what you suggest, making guns illegal makes it much harder for small-time criminals to get hold of them!)
No.
But it's only your money to spend because of the infrastructure provided by the government. After all, if it wasn't for the government, those coins in your pocket would only be worth their value in scrap metal. So I think in the case of money, and other forms of property which are facilitated and protected by the government, it's arguable that people don't have an absolute, inviolable right of ownership. (You may say that a currency could be maintained by a private institution, and perhaps it could, but right now US dollars aren't.)
How so? They're based on the mathematical concept of a function. It so happens that you can hack together this abstractiion using templates and interfaces in C++ or whatever (though you can't really have proper closures, and the syntax is ghastly). How would you write a template/interface-based version of the following?
reverseList = foldl (flip cons) []
And why on Earth would you want to?
I think there was a touch of irony in the grandparent which you missed (typical American...)
SML isn't purely functional, it has side effects.