5 ms·

You could support markers stating "I swear this part is never going to use those dynamic features", disabling them for you and others. E.G: I have no problem p

You could support markers stating "I swear this part is never going to use those dynamic features", disabling them for you and others. E.G: I have no problem putting a few annotation telling Python I'm not going to and allow to override builtins in my program and it's dependancies. We could make sure those markers can only be set in __main__, and crashes with very explicit errors in the unlikely event anything down there decide to do otherwise. Indeed, many dynamic features are rarely used. They are handy from time to time, but I won't miss them for many codes.

pishpash 8y ago
How can you know the builtins and the libraries you call don't use these features, to make such guarantees? I suspect it's rather more common than it appears.
- sametmax 8y ago
  You can't at first, but you don't need to. You just write normal code, with regular unit tests. Once you are satisfy, you can start playing with optimization and see if things break or get faster. Things like monkey patching and stack inspection are the excetion rather than the rule. You may very well be able to safely disable many feature at some local level, or in prod but not dev, etc.
  - coredog64 8y ago
    One of the event workers for Django monkey patches ‘socket’. A colleague and I discovered that an hour into debugging why something was misbehaving when we switched workers.
jerf 8y ago
"You could support markers stating "I swear this part is never going to use those dynamic features", disabling them for you and others." Right now, the swing is in general to statically-typed languages that are more convenient to use, but I've thought there's room for a new dynamic scripting language that is still dynamically typed, but is written from the beginning to focus on speed. You can see some of the ideas in Julia or LuaJIT, but you pay a penalty on what can be dynamic. One of the ideas I've had is more like the "pledge" feature that OpenBSD recently introduced. Rather than stating up front "I will not use this feature", you initialize your program, do all the dynamic stuff, then push the "OK, now I'm done being dynamic" button. After that, the program "freezes" into place, and calling a function with a new type of argument it has never seen before or something becomes an error. My reasoning here is that the dynamic scripting languages tend not to use their dynamism evenly. The vast bulk of "dynamic" behavior is all done in an informal initialization phase, but then, for the bulk of the program's execution, you continue to pay for all the dynamism because the interpreter has to constantly follow the dynamic chains of functions, or even if the code is JIT'ed, the JIT has to be written to handle functions suddenly getting the "wrong" type, which at the very least means you pay for a check the static programs don't need to pay for, and generally, you may have to pay more. You set up the dynamism once at the start of the program, but pay for the ability to be dynamic later billions and trillions and so on of times over the course of the program. (Don't just think about how poorly this would work if bodged onto Python or Javascript or something, because I know such an attempt would absolutely be a disaster. That's why I'm hypothesizing someone sitting down and designing this language from scratch with these ideas in mind, so it'll have the correct affordances and paved cow paths and such to make this work. While you're at it, give your new dynamic scripting language a solid concurrency story, since none of the current ones have one, since they all grotesquely predate that as a concern. I think there's a hole in the programming language landscape here right now. Another way to think of this is "write a dynamic scripting language that is designed to have a good, simple JIT".) (Actually, for all the languages there are, I think there's several holes in the programming language landscape right now. You'd think everything would be covered, but it really isn't.)
- Sukera 8y ago
  > You can see some of the ideas in Julia or LuaJIT, but you pay a penalty on what can be dynamic. I'm sorry but I think I'm missing something here - what sort of penalty are you paying in terms of dynamicness? Can you be more specific?
  - jerf 8y ago
    I was under the impression that there are things you can't do in LuaJIT that you can do in Lua, but I'm not sure now, since I can't google it up. Regardless, Perl, Python, and Ruby have simply absurd amounts of dynamicness; you can dynamically add operator overloads to the super-superclass of some object you have in hand, or write new metaclasses then create new classes from them, or stick new implementations of __setattr__ in the middle of a class chain, etc., and the interpreter is ready for you to do it, at great runtime cost. For that sort of thing, the JIT will just give up, generally. You'll note that a lot of these things are things you don't generally have a need to do, which is precisely the thing I'm suggesting be exploited more. My understanding is that Julia is not this dynamic. (For those who may be inclined to jump to the "defense" of Julia, bear in mind I'm citing this as a good thing.) Another way of looking at my suggestion is to forbid all the things that blow out the JITs, but giving the JIT a phase it is allowed to depend on, which will take some work because, again, simply retrofitting that on to an existing language will be a nightmare in all sorts of ways. You want some deep integration into the language for this. None of the current scripting languages were designed with JITs in mind; JITs are always laboriously wrapped around them years after the fact. What if you went the other way around? (You may get Julia in that case; what if you add the ability to have a pre-pledge phase in too, though?) (Another idea: What if you write a language, or possibly language family, for truly heterogeneous computing models? What would a language that natively has a concept of CPU vs. GPU code look like? Some sort of explicit, visible management of shared data? We also see embryonic use cases where we want a low-power, cheap CPU that's still a CPU, to do some low-power basic maintenance cases, but has a high-power CPU friend that can be turned on if necessary. If there was a language that afforded such management, would we see more of that thing in cell phones and such? There's a lot of interesting places for programming languages to be created, but we tend to see so much of "it's ${some existing language}, with some slight twist, and no standard library".)
chrisseaton 8y ago
> You could support markers stating "I swear this part is never going to use those dynamic features" You shouldn't have to! The VM should be able to work this all out for you. One person puts the effort into improving the VM rather than everyone has to work around in their program.

pishpash 8y ago

How can you know the builtins and the libraries you call don't use these features, to make such guarantees? I suspect it's rather more common than it appears.

sametmax 8y ago
You can't at first, but you don't need to. You just write normal code, with regular unit tests. Once you are satisfy, you can start playing with optimization and see if things break or get faster. Things like monkey patching and stack inspection are the excetion rather than the rule. You may very well be able to safely disable many feature at some local level, or in prod but not dev, etc.
- coredog64 8y ago
  One of the event workers for Django monkey patches ‘socket’. A colleague and I discovered that an hour into debugging why something was misbehaving when we switched workers.

jerf 8y ago

"You could support markers stating "I swear this part is never going to use those dynamic features", disabling them for you and others." Right now, the swing is in general to statically-typed languages that are more convenient to use, but I've thought there's room for a new dynamic scripting language that is still dynamically typed, but is written from the beginning to focus on speed. You can see some of the ideas in Julia or LuaJIT, but you pay a penalty on what can be dynamic. One of the ideas I've had is more like the "pledge" feature that OpenBSD recently introduced. Rather than stating up front "I will not use this feature", you initialize your program, do all the dynamic stuff, then push the "OK, now I'm done being dynamic" button. After that, the program "freezes" into place, and calling a function with a new type of argument it has never seen before or something becomes an error. My reasoning here is that the dynamic scripting languages tend not to use their dynamism evenly. The vast bulk of "dynamic" behavior is all done in an informal initialization phase, but then, for the bulk of the program's execution, you continue to pay for all the dynamism because the interpreter has to constantly follow the dynamic chains of functions, or even if the code is JIT'ed, the JIT has to be written to handle functions suddenly getting the "wrong" type, which at the very least means you pay for a check the static programs don't need to pay for, and generally, you may have to pay more. You set up the dynamism once at the start of the program, but pay for the ability to be dynamic later billions and trillions and so on of times over the course of the program. (Don't just think about how poorly this would work if bodged onto Python or Javascript or something, because I know such an attempt would absolutely be a disaster. That's why I'm hypothesizing someone sitting down and designing this language from scratch with these ideas in mind, so it'll have the correct affordances and paved cow paths and such to make this work. While you're at it, give your new dynamic scripting language a solid concurrency story, since none of the current ones have one, since they all grotesquely predate that as a concern. I think there's a hole in the programming language landscape here right now. Another way to think of this is "write a dynamic scripting language that is designed to have a good, simple JIT".) (Actually, for all the languages there are, I think there's several holes in the programming language landscape right now. You'd think everything would be covered, but it really isn't.)

Sukera 8y ago
> You can see some of the ideas in Julia or LuaJIT, but you pay a penalty on what can be dynamic. I'm sorry but I think I'm missing something here - what sort of penalty are you paying in terms of dynamicness? Can you be more specific?
- jerf 8y ago
  I was under the impression that there are things you can't do in LuaJIT that you can do in Lua, but I'm not sure now, since I can't google it up. Regardless, Perl, Python, and Ruby have simply absurd amounts of dynamicness; you can dynamically add operator overloads to the super-superclass of some object you have in hand, or write new metaclasses then create new classes from them, or stick new implementations of __setattr__ in the middle of a class chain, etc., and the interpreter is ready for you to do it, at great runtime cost. For that sort of thing, the JIT will just give up, generally. You'll note that a lot of these things are things you don't generally have a need to do, which is precisely the thing I'm suggesting be exploited more. My understanding is that Julia is not this dynamic. (For those who may be inclined to jump to the "defense" of Julia, bear in mind I'm citing this as a good thing.) Another way of looking at my suggestion is to forbid all the things that blow out the JITs, but giving the JIT a phase it is allowed to depend on, which will take some work because, again, simply retrofitting that on to an existing language will be a nightmare in all sorts of ways. You want some deep integration into the language for this. None of the current scripting languages were designed with JITs in mind; JITs are always laboriously wrapped around them years after the fact. What if you went the other way around? (You may get Julia in that case; what if you add the ability to have a pre-pledge phase in too, though?) (Another idea: What if you write a language, or possibly language family, for truly heterogeneous computing models? What would a language that natively has a concept of CPU vs. GPU code look like? Some sort of explicit, visible management of shared data? We also see embryonic use cases where we want a low-power, cheap CPU that's still a CPU, to do some low-power basic maintenance cases, but has a high-power CPU friend that can be turned on if necessary. If there was a language that afforded such management, would we see more of that thing in cell phones and such? There's a lot of interesting places for programming languages to be created, but we tend to see so much of "it's ${some existing language}, with some slight twist, and no standard library".)

chrisseaton 8y ago

> You could support markers stating "I swear this part is never going to use those dynamic features" You shouldn't have to! The VM should be able to work this all out for you. One person puts the effort into improving the VM rather than everyone has to work around in their program.