It's not just indexing, it happens with indirect JMP as well. JMP ($01FF) would read the low byte from $01ff and the high byte from $0100 instead of $0200.
With classic screen-editor BASIC, you can just type in PRINT "1+1=";1+1 and immediately see the results. Once you've entered in a program, you can interactively do things like A=3:GOSUB1000 and try out a sub-portion of their code.
This sort of interactivity is completely lost in programming languages that have an edit/compile/run cycle, to the detriment of stark newbies getting to play around with the language and just "try stuff".
Lisp is my main development language. It and some of the other dynamic languages of today do keep that interactive prompt for the user, letting newbies play and letting seasoned developers test/debug very quickly. When it comes to being beginner-friendly, I think this interactivity with the language environment is the most important aspect, and it doesn't have to be tied to just "simple" beginner languages.
I believe this speaks to how the human race has grown out of its own imagination when it comes to technology since it entered the digital age.
Or maybe the movie simply wasn't very imaginative, or at least was less imaginative than the original. The movie had very little to do with technology, besides being a visual backdrop. It was just another "problem in fantasyland" movie that didn't capitalize on anything besides the audio/visual aspect.
Along came "computers" and - you know what's coming next - exceedingly rapidly, all that incredibly valuable "parallel" expertise was lost, in favour of single-step, single-process algorithms.
There's a stark difference in time scale. If you have 3 important steps that need to be done, you can have 3 people working on it for a few minutes each, double-check and cross-check their answers, and the next step happens when all are ready. In a computer, each step can be mechanically expected to perform the right answer, for many task-oriented problems, in a very small period of time. So much so that the overhead of setting up parallelism for those tasks and coordinating their results is slower than just performing them in series, plus is much more work than the human counterpart of dividing & conquering a task.
Now, for a programmer to parallelize and coordinate more complex procedures is a different programming design challenge than just "Here's what needs to get done, sic humans on it until it's finished" and "Here's the procedure that needs to be carried out, encode it into the computer" which is what things have been based on so far. It's not hard, just different. Procedures are generally serially specified, even if only because that's a side effect of streaming human communication/linguistic style.
I don't mind a nicely presented UI. What I *do* mind is UI effects that actually take time. Transitions, fades, and smooth expansions/collapsing of elements cause you to have to wait needlessly for your computer to perform a completely unproductive, time-taking activity, instead of immediately performing the requested visual change. The amount of time these things take up is incredibly noticeable when dealing with a UI-heavy workflow that you're well versed in, and turning them off IMO yields much better mental flow through the process.
It's these things that actually *reduce* productivity. UIs looking nicer may not increase productivity, but processing a plain non-animated UI vs a nicely polished non-animated UI most likely isn't too different in CPU utilisation either, much less human-noticeable time.
Re:The writing was idiotic (Spoilers?)
on
Tron: Legacy
·
· Score: 1
Computer clothes look like clothes. Walls look like walls, floors look like floors, doors look like doors. You can actually slam the door, in a computer. If you drive a computer car on a computer racetrack, your tires leave computer rubber on the road (rubber?). There are clouds in the sky (why?), and ships use thrusters to fly around (is there even air?). Basically, this wasn't the world of Tron from the first movie -- it was Attack of the Clones with extra neon.
This was my biggest gripe with the movie. It wasn't a digital world, it was just another slightly magical world. Nothing seemed to work differently from ours. The original Tron screwed around with physics & materials in much more fundamental ways, giving a very unique quantized/binary feeling to everything. They sorely missed out on that opportunity to inject the world with a much more "computerized" nature and give it its own identity.
Look at a tile floor in a bathroom when you're stone-cold sober. Stare between the tiles, allow your eyes to lose focus, and tell me that after 15 seconds or so you don't see the lines start to dance.
I'll bite. I don't know what you did to your eyes & perceptive coherence due to your admitted substance use, but when I stare at square tile patterns (and I've been amused by such effects since childhood), the eyes get "used" to the pattern and it starts to fade away. There's no motion, just an increased blurriness and lack of definition around things that are getting "burned" into your eyes. Then if I look away, a rock-solid reverse imprint shows up clear as day on whatever other surface I look at. There's no motion in either case, and if you have dancing/jittering effects going on, I'd be more inclined to attribute that to some sort of minor dysfunction than the lack thereof, especially as the "temporarily burn an image into your eyes" is a common optical illusion experienced by many without report of jittering.
No. Spices and sauces are the primary "give taste" factor (except for the connoisseur differences in quality behind grades of the base food), regardless if it's a meat dish or vegetable.
2. So, um yeah. You agree as well then? And really, it's not as much a Lisp issue as it is a threaded GC issue. As reiterated below, most GC developers claim that GC tricks and performance are tied much more to what the OS allows than to any language specific features.
3. If you have dynamic code, I would trust the compiler to generate type dispatching code that would be faster than doing manual dispatch from a statically typed language, especially for primitives, or in complex type analysis cases.
Consider the simple case of manually using function dispatch tables in C vs using virtual dispatch in C++. In the latter, the compiler has a higher-level idea of what's going on, and can allocate and dedicate resources in a much more targeted way than a general lookup, dedicate a register to the "this" pointer, etc.
Sure, if you use less powerful languages, they do less for you, and you're stuck bolting on higher-order functionality with semantics that the compiler does not know about and cannot tailor optimizations toward. That's not really a benefit.
Except for keeping the dataflow with the control flow
How is that Lisp-specific? That's a general programming issue.
write barriers for the GC
There is no GC-related code injection in the machine language for writes in any of the modern Lisp disassemblies I've seen.
the language is too dynamic to be statically checked
SBCL does compile-time type inference, removing dynamic checks and bit tags wherever it can. Only where it still needs the dynamic checks & behavior does it insert code to do so. In any Lisp, using the declaration system should eliminate any applicable runtime ambiguities as well.
Have you ever used SBCL's disassembler to see what's going on underneath? Especially when you've got reasonable declares set up? We don't need specialized hardware to run Lisp fast anymore. Of course, if you're on Windows and need things like threading then CCL's quite reasonable as well.
Sure, specialized hardware would undoubtedly be faster than running on general purpose CPUs (as would be the case for any situation), but the translation from Lisp-speak to general assembly-speak is very good.
I've never understood this. I've seen numerous left-handed people write without that wonky "from above the line of print" wrist-twisted posture many seem to use. The writing hand goes _under_ the line of text you're writing (re the vertical dimension of the paper), whether lefty or righty. No weird contortions, no obscuring.
You used "morality" and "bank" in the same context.
Are you sure the porn industry doesn't have something like a higher credit card purchasing fraud rate by its customers, which makes servicing their accounts unprofitable?
So if I'm an adult, and I'm a webmaster, how does this affect me? Stop abusing this word.
I'm drinking without drinking alcohol. I'm gaming without gambling. My adult media content is not adolescent gratuitousness, but challenging and informative content that requires some life experience to appreciate. My adult language is educated and domain terminology that children might not understand yet.
17 years professionally, longer than that hobby. Every project I undertake is more technically challenging than the last, and the programming pipe dreams I had as a kid are quickly becoming closer to reality.
I'm in my mid-30s, and have already long experienced exactly what you describe, and agree 100%. We also do use codegen heavily to create a *maintainable* fast pipe between "problem to solve" to "solution".
Of course, going the entrepreneur route does force some of those issues, as solving the customer's problems is what puts food on the table, not just cranking code and keeping a boss off your back. But even then, quite a bit of my increase in perspective came well before, when I realized that what I want to build in terms of my own hobby interests requires more than just me working on it, if I want to reach my creative goals in this lifetime.
Slashdot Mirror
Wait, people still listen to music on the radio?
It's not just indexing, it happens with indirect JMP as well. JMP ($01FF) would read the low byte from $01ff and the high byte from $0100 instead of $0200.
Great post/sig combo. ;-)
With classic screen-editor BASIC, you can just type in PRINT "1+1=";1+1 and immediately see the results. Once you've entered in a program, you can interactively do things like A=3:GOSUB1000 and try out a sub-portion of their code.
This sort of interactivity is completely lost in programming languages that have an edit/compile/run cycle, to the detriment of stark newbies getting to play around with the language and just "try stuff".
Lisp is my main development language. It and some of the other dynamic languages of today do keep that interactive prompt for the user, letting newbies play and letting seasoned developers test/debug very quickly. When it comes to being beginner-friendly, I think this interactivity with the language environment is the most important aspect, and it doesn't have to be tied to just "simple" beginner languages.
I believe this speaks to how the human race has grown out of its own imagination when it comes to technology since it entered the digital age.
Or maybe the movie simply wasn't very imaginative, or at least was less imaginative than the original. The movie had very little to do with technology, besides being a visual backdrop. It was just another "problem in fantasyland" movie that didn't capitalize on anything besides the audio/visual aspect.
Along came "computers" and - you know what's coming next - exceedingly rapidly, all that incredibly valuable "parallel" expertise was lost, in favour of single-step, single-process algorithms.
There's a stark difference in time scale. If you have 3 important steps that need to be done, you can have 3 people working on it for a few minutes each, double-check and cross-check their answers, and the next step happens when all are ready. In a computer, each step can be mechanically expected to perform the right answer, for many task-oriented problems, in a very small period of time. So much so that the overhead of setting up parallelism for those tasks and coordinating their results is slower than just performing them in series, plus is much more work than the human counterpart of dividing & conquering a task.
Now, for a programmer to parallelize and coordinate more complex procedures is a different programming design challenge than just "Here's what needs to get done, sic humans on it until it's finished" and "Here's the procedure that needs to be carried out, encode it into the computer" which is what things have been based on so far. It's not hard, just different. Procedures are generally serially specified, even if only because that's a side effect of streaming human communication/linguistic style.
I don't mind a nicely presented UI. What I *do* mind is UI effects that actually take time. Transitions, fades, and smooth expansions/collapsing of elements cause you to have to wait needlessly for your computer to perform a completely unproductive, time-taking activity, instead of immediately performing the requested visual change. The amount of time these things take up is incredibly noticeable when dealing with a UI-heavy workflow that you're well versed in, and turning them off IMO yields much better mental flow through the process.
It's these things that actually *reduce* productivity. UIs looking nicer may not increase productivity, but processing a plain non-animated UI vs a nicely polished non-animated UI most likely isn't too different in CPU utilisation either, much less human-noticeable time.
nuff said.
Computer clothes look like clothes. Walls look like walls, floors look like floors, doors look like doors. You can actually slam the door, in a computer. If you drive a computer car on a computer racetrack, your tires leave computer rubber on the road (rubber?). There are clouds in the sky (why?), and ships use thrusters to fly around (is there even air?). Basically, this wasn't the world of Tron from the first movie -- it was Attack of the Clones with extra neon.
This was my biggest gripe with the movie. It wasn't a digital world, it was just another slightly magical world. Nothing seemed to work differently from ours. The original Tron screwed around with physics & materials in much more fundamental ways, giving a very unique quantized/binary feeling to everything. They sorely missed out on that opportunity to inject the world with a much more "computerized" nature and give it its own identity.
Look at a tile floor in a bathroom when you're stone-cold sober. Stare between the tiles, allow your eyes to lose focus, and tell me that after 15 seconds or so you don't see the lines start to dance.
I'll bite. I don't know what you did to your eyes & perceptive coherence due to your admitted substance use, but when I stare at square tile patterns (and I've been amused by such effects since childhood), the eyes get "used" to the pattern and it starts to fade away. There's no motion, just an increased blurriness and lack of definition around things that are getting "burned" into your eyes. Then if I look away, a rock-solid reverse imprint shows up clear as day on whatever other surface I look at. There's no motion in either case, and if you have dancing/jittering effects going on, I'd be more inclined to attribute that to some sort of minor dysfunction than the lack thereof, especially as the "temporarily burn an image into your eyes" is a common optical illusion experienced by many without report of jittering.
How many companies even HAVE a Chief Privacy Strategist?
And how in the world were they able to score Optimus Prime for the job?
And protecting against that is what your immune system is for. Let it do its job.
No. Spices and sauces are the primary "give taste" factor (except for the connoisseur differences in quality behind grades of the base food), regardless if it's a meat dish or vegetable.
2. So, um yeah. You agree as well then? And really, it's not as much a Lisp issue as it is a threaded GC issue. As reiterated below, most GC developers claim that GC tricks and performance are tied much more to what the OS allows than to any language specific features.
3. If you have dynamic code, I would trust the compiler to generate type dispatching code that would be faster than doing manual dispatch from a statically typed language, especially for primitives, or in complex type analysis cases.
Consider the simple case of manually using function dispatch tables in C vs using virtual dispatch in C++. In the latter, the compiler has a higher-level idea of what's going on, and can allocate and dedicate resources in a much more targeted way than a general lookup, dedicate a register to the "this" pointer, etc.
Sure, if you use less powerful languages, they do less for you, and you're stuck bolting on higher-order functionality with semantics that the compiler does not know about and cannot tailor optimizations toward. That's not really a benefit.
Except for keeping the dataflow with the control flow
How is that Lisp-specific? That's a general programming issue.
write barriers for the GC
There is no GC-related code injection in the machine language for writes in any of the modern Lisp disassemblies I've seen.
the language is too dynamic to be statically checked
SBCL does compile-time type inference, removing dynamic checks and bit tags wherever it can. Only where it still needs the dynamic checks & behavior does it insert code to do so. In any Lisp, using the declaration system should eliminate any applicable runtime ambiguities as well.
Have you ever used SBCL's disassembler to see what's going on underneath? Especially when you've got reasonable declares set up? We don't need specialized hardware to run Lisp fast anymore. Of course, if you're on Windows and need things like threading then CCL's quite reasonable as well.
Sure, specialized hardware would undoubtedly be faster than running on general purpose CPUs (as would be the case for any situation), but the translation from Lisp-speak to general assembly-speak is very good.
It can make the Jupiter run in less than twelve parsecs.
I've never understood this. I've seen numerous left-handed people write without that wonky "from above the line of print" wrist-twisted posture many seem to use. The writing hand goes _under_ the line of text you're writing (re the vertical dimension of the paper), whether lefty or righty. No weird contortions, no obscuring.
"Plug computing" ((c) Marvell) is the successor of that direction. There's stuff like this hitting the market, though still single-core for now.
Once these new Cortex A9s are more in the wild, I'd expect them to find a home in the wall wart machines as well.
You used "morality" and "bank" in the same context.
Are you sure the porn industry doesn't have something like a higher credit card purchasing fraud rate by its customers, which makes servicing their accounts unprofitable?
Nah, just whining a bit. It's a real irritation when your innocuous actions fit a misappropriated label.
Thank you! Now, if others would follow suit in actually speaking directly like that, the world would be that little bit of a better place. :)
So if I'm an adult, and I'm a webmaster, how does this affect me? Stop abusing this word.
I'm drinking without drinking alcohol.
I'm gaming without gambling.
My adult media content is not adolescent gratuitousness, but challenging and informative content that requires some life experience to appreciate.
My adult language is educated and domain terminology that children might not understand yet.
17 years professionally, longer than that hobby. Every project I undertake is more technically challenging than the last, and the programming pipe dreams I had as a kid are quickly becoming closer to reality.
I'm in my mid-30s, and have already long experienced exactly what you describe, and agree 100%. We also do use codegen heavily to create a *maintainable* fast pipe between "problem to solve" to "solution".
Of course, going the entrepreneur route does force some of those issues, as solving the customer's problems is what puts food on the table, not just cranking code and keeping a boss off your back. But even then, quite a bit of my increase in perspective came well before, when I realized that what I want to build in terms of my own hobby interests requires more than just me working on it, if I want to reach my creative goals in this lifetime.