2: The “ease you can get something up and runnning” with OpenGL days have never applied to shaders. Shader programming has always required time and effort, simply in understanding how they all interrelate together. That “ease” comes in the form of the fixed-functionality of OpenGL.
That’s not to say that writing simple test code that uses shaders isn’t also done with ease.
Of course, having access to AllegroGL’s automatic extension loading mechanism helps 
1: The ISA isn’t necessarily not human readable. ARB_vp is human readable; the ISA wouldn’t be terribly far removed from it.
People have been talking about byte-code representations and parse trees. “isn’t necessarily not human readable” also implies “could perhaps be non-human readable”.
2: The “ease you can get something up and runnning” with OpenGL days have never applied to shaders. Shader programming has always required time and effort, simply in understanding how they all interrelate together. That “ease” comes in the form of the fixed-functionality of OpenGL.
If you look in the OpenGL programming guide they use simple arrays to create data for use by DrawArrays or DrawElements in thier examples. You can make an array of chars for use by ARB_vertex_program in a simular way. Although you will no doubt later move to using external model and shader files for flexibility. If using the shading language requires an offline compile step this in no longer possible.
It’s not in binary. The ISA would be stored as text.
This has nothing do with it whether its binary or text. If it is produced by an offline compiler it needs to be loaded into the program somehow.
Do you really think that they re-parse each line as it is used? Lua can be pre-compiled into a nice, neat binary form on disk. I can’t say about Python, but I wouldn’t be surprised. And, even if there is no off-line Python compiler, the moment it gets loaded, it is converted into a memory representation of that code. Compiled, as it were.
You mean just like a shader language will be parsed and compiled when the shader is loaded? You mean my analogy was exact? “I’d say that the argument has gone pretty well for my side”. Only because people get exasparated with debating tactics like the above and stop bothering. Just like I am after this last post.
People have been talking about byte-code representations and parse trees. “isn’t necessarily not human readable” also implies “could perhaps be non-human readable”.
While I, personally, think it might not be unreasonable to have a byte-code form in addition to the regular text format, I would suggest that text be the accepted way of feeding in ISA shaders. Otherwise, it becomes too difficult to write trivial shaders. Parsing a text assembly-esque shader isn’t really so difficult; it’s not that much more expensive than parsing the binary byte-code (which still must retain various high-level syntax).
You can make an array of chars for use by ARB_vertex_program in a simular way.
…
I don’t follow. How is building a vertex array at all similar to building a vertex shader? Besides the fact that they are both stored in memory?
If it is produced by an offline compiler it needs to be loaded into the program somehow.
So do textures, meshes, etc. Loading such things has nothing to do with OpenGL.
You mean just like a shader language will be parsed and compiled when the shader is loaded? You mean my analogy was exact?
Yes, and no.
As I pointed out, Lua can, and frequently is, compiled offline, and loaded as a post-compiled substrate that is then used by the Lua interpreter. Which is precisely how the ISA scheme works.
Only because people get exasparated with debating tactics like the above and stop bothering. Just like I am after this last post.
If you want to go on believing that, it is your perogative. However, a number of people have seen the arguments for what they are, weighed the evidence, and found that a lower-level approach to a glslang would be benificial on a number of fronts, while still providing enough high-level constructs to optimize on a variety of architectures.
Even 3DLabs agrees with me, as aboeing pointed out (except for the part about using a byte-code rather than text).