On Tue, Jul 26, 2011 at 11:14 PM, BGB <cr88...@gmail.com> wrote: > one can support ifdef blocks in the IL, no real problem there. >
Those seem like a problem all by themselves. Definitions are inflexible, lacking in domain of language types and lack effective support for complex ad-hoc decisions that would normally enter 'if' conditionals. Definitions are typically rigid, i.e. you cannot choose some definitions to be constant (and specialize on those) while others are mutable like regular variables. The scope of a definition is not controlled by semantics in the language, like a regular variable is. With separate compilation, definitions are often inconsistent across modules, and configuration management easily becomes a problem. > Forth and PostScript are not "unnecessarily powerful". > Sure they are. We might in the general case need Turing power, at the topmost level of a service or application, but the vast majority of a program does not need that power. By definition, any power you don't need is unnecessary. Consider PostScript: here's a language that can spend an infinite amount of time drawing in minute detail on the upper-left square inch of your document. Now, reasonable people won't write programs that do that, but they can. You should say: if they have this power and they aren't using it, they clearly have more power than they need. For developing a zoomable UI, a very nice property would be a language that always draws 'big' details before small ones (level of detail), and that allows you to draw just the visible portions or nearly so (culling). Through a lot of careful design efforts, you can create a language that has these properties - but, in turn, you will need to sacrifice some power. Now, that zoomable UI language could still be capable of drawing arbitrary images if given enough resources (time, resolution, et cetera) but the decision on how many resources to provide is external - which is as it should be. Really, unnecessary power is just a currency you should recognize and trade for useful features. > > if the HLL is somewhere along C or C++ lines (with pointers and OOP and so > on), then the IL being powerful is not the issue. > Agreed. If your alleged 'high' level language happens to be unsafe and undefined for many operations, then you have much bigger issues than the quality of your IL. > > a language much weaker than [Java or C#] is probably too weak to > be really usable in any non-trivial context. > It does seem that way, at least to someone who is only familiar with the C++ idioms. > > dataflow languages currently lack mainstream acceptance as > application-development languages. > Yet, synchronous reactive systems are widely accepted for real-time mission-critical applications. And dataflow systems are the basis for some of the most popular user-programmable application software ever (spreadsheets). Dataflow UIs are not inherently difficult to develop (though legacy integration is a pain, e.g. OpenGL strongly assumes procedural expression). But I think you skipped the point. The issue of non-algorithmic software still strongly favors distributing a higher level language. > > Procedural + OOP is probably a much better bet. > Well, they're the popular bet anyway. And today, we have a lot of buggy application software that takes too long to develop. I wonder if there's a causal relationship in there somewhere. You won't be at any risk of improving things by betting on Procedural + OOP. (4) The web model today is *extremely* constrained [...] > > can't really make sense of the above. > I'll rephrase and summarize: The web is seriously 'gimped'. There is a lot of low-hanging fruit for code-distribution. The barrier is security - authority, resource control, composition - people have reason not to trust the distribution programs. A secure, composable language can reach further and support valuable new features you've never thought about because they seem impossible today. > > doesn't matter much for applications, as you don't generally want the user > to know how it works. > normally, the program is expected to be a sort of sealed black-box for the > creators' eyes only. > > granted, this is not to say that FOSS people/... can't distribute in source > form, but not everyone > should *have* to distribute in source form. > In most cases - business apps, for example, or apps tied to a particular service - developers don't care whether the user looks under the hood. For applications, users are starting to prefer support for alternative UIs, e.g. an app might be a service with a small web-server on a configured port. The path of least resistance should be distribution in source form. > > it is like, the children peek behind the curtain, start messing with > things, ..., and find themselves in the world of copyright infringement and > IP law, and/or find themselves or their parents being faced with a lawsuit > as a result. > > keeping proprietary code hidden away thus also serves the purpose of > helping to prevent these "innocent little children" from unintentionally > committing criminal acts, ... You do have quite an imagination when it comes to protecting your status quo. Obfuscators are easily available to those companies interested in protecting innocent children. > Any good distribution language *will be* high level, though not *because* it's > high level. There are quite a few desiderata for a web language. > however, a lower-level language will be more abstracted from the high-level > language, and more opaque-looking for prying eyes (likely more important for > commercial people, one wants the code as difficult to get at as can > reasonably be done). > The most effective solution to protect code is also one of the best: write a server, don't put those 'trade-secret' algorithms on the client. A second effective solution is to use an obfuscator. But your words do suggest another option: a high-level program can model an abstract machine and 'interpret' a lower-level program. I've seen this done before: a website compiles apps to bytecode, and a developer wrote a JavaScript library to interpret the bytecode. Or, similarly, there's an x86 interpreter in JavaScript, and an example involving the Linux kernel running in JavaScript.
_______________________________________________ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
