On 7/27/2011 6:37 AM, David Goehrig wrote:
On Jul 26, 2011, at 8:45 PM, Casey Ransberger
<casey.obrie...@gmail.com <mailto:casey.obrie...@gmail.com>> wrote:
Worth pointing out that server side JS dodges this "problem." Now
that Node is out there, people are actually starting to do stuff with
JS that doesn't run on the client, so it's happening... whether or
not it's a real qualitative improvement for anyone.
Well considering that Netscape Enterprise Server 2.0 ca. 1996 (15
years ago btw) did server side JavaScript. We've seen no change at
all. I also say this having built several businesses on to of a C10k
style server with server side JavaScript for the past 8 years (a
contemporary of nginx).
BTW: I am not against JS, as, hell, my own scripting language is based
on it (and tries for ECMA-262 conformance, albeit it differs on a few
points).
in my case, its use is more intended for standalone desktop-style apps.
The lessons we collective fail to learn is that survival is not always
of the fittest, just those most realized potential of changing.
I think "fitness" and "merit" are some often misunderstood ideas.
some people seem to see it like all of the "good" solutions die and fade
away, but often most options which die/fade have problems in other
areas, and people end up overlooking important parts of the problem
space (one person overlooks economic aspects, another flexibility, a 3rd
overlooks performance, another overlooks memory footprint, ...).
the solutions which do best often tend to have the best sets of
tradeoffs and/or being well suited to a various niche, albeit typically
not being ideal in any single area.
If I've learned anything from trying to reimplement Self in JavaScript
it is that JavaScript is immensely fungible. I have in a few lines of
code working variants of lisp and forth and in a few more lines will
finish Self. Since I've written x86 assemblers in JS, I'm certain I
could turn any of these into a self hosting environment in under 1kloc.
dunno, it depends.
my guess for a JS->x86 machine-code compiler which can compile itself
and does eval/... would probably be at least around 10-25kloc.
granted, I am not necessarily the master of compact code.
my VM is presently around 450 kloc of C.
this seems fairly typical (compared with JaeggerMonkey and V8).
much more of the complexity goes into "infrastructure" though,
especially the FFI and dynamic typesystem machinery (numeric tower, OO
facilities, ...), which probably make up the bulk of the VM in its
present form.
the part for parsing/interpreting the HLL is actually fairly small part
of the whole.
actually, my native codegen seems to follow a similar pattern, with much
of the "bulk" of the code being related to things like the numeric
tower, type-conversions, endless special cases for moving a value from
location A to B (load and store operations, ...), ...
as well as things like having to gloss over the native ABIs (some ABIs,
such as the SysV/AMD64 ABI, are fairly painful to work with...).
using an abstract stack machine, it essentially means having to partly
virtualize the stack, mapping it internally to temporary variables and
registers, and utilize "magic" to get everything into the correct
registers and onto the correct place on the stack at the point the call
is made, ...
Evolving JS is a pragmatic approach to evolving the ecosystem. And
while technically nothing prevents people from building entire
operating systems in JavaScript, culturally we are adverse to it. (and
since Linux boots in a js x86 emulator I don't buy any argument
against the technical aspect)
I figure there are a few problem areas...
one would have to implement the typesystem/GC/... in JS, which would
mean needing capabilities a bit more like C at this point:
ability to write constant-memory code (and a defined machine-level
memory model);
pointers, pointer arithmetic, and pointer<->integer conversions;
...
that or:
the ability to interface directly with ASM code and/or inline assembler;
writing much of the GC and dynamic typesystem machinery in ASM.
much of the rest could probably be fairly clean though (apart from
"magic" needed to interface with the CPU or various pieces of hardware).
all of this though would likely mostly mean some language extensions,
and a well-defined ABI at this level.
some of my own stuff is built using partly hacked versions of the C
ABI's, as well as name-mangling (my notation partly derived as a mix of
the JVM/JNI notation and the IA64 C++ ABI).
partly, I would partly prefer a system where JS <-> C calls are fairly
transparent (much like C <-> C++ calls), this way, each language can be
used for what it is good at, without so much of an expectation to commit
to one or the other, and without big piles of nasty boilerplate needed
to make the interfacing work.
granted, a little fudging is needed at the borders, as direct idiomatic
C to idiomatic JS is unlikely to work entirely smoothly even if the FFI
worked "perfectly" (and in the implementation, there ends up being a bit
of typesystem overlap, where a VM may need to deal, dynamically, with a
good portion of the native C typesystem).
direct (full) C++ <-> JS interfacing would likely be a bit more complex,
especially WRT OOP (make raw C++ class be directly usable in JS, and
find some way to make JS object look to C++ like a plain class-based
object).
the above is a problem I am currently ignoring in my effort.
in my case I figure can probably just use some operator overloading on
the dynamic-references, and call it "good enough" (otherwise, C++ has to
use C-based interfacing, and I can call it "good enough").
The greatest danger we face is cultural tendency to rarify
programming, math, and computer science. For a simple system to be
widely adopted, it must conform to existing cultural constraints to
seem familiar, but only so much.
_('tk')
('does:','text:', 's | HTML("element:","span")("contains:", s, 0,
s.length)')
('does:','image:', 'u | HTML("element:","img")("src:",u)')
('does:','sound:', 'u | HTML("element:","audio")("src:",u)')
('does:','video:', 'u | HTML("element:","video")("src:",u)')
('does:','box:', '| HTML("element:","div")')
Is straight JavaScript. But it looks a little like lisp, a little like
smalltalk, and borrowed from self and forth.
I bet you can guess what it does by reading it. How it does it though would
only be obvious to a JS expert. But the GUI that makes use of it allows a child
to build web pages procedurally.
it required a bit of looking, but I guess it probably involves use of
closures or similar (each being a call which returns a closure which is
then applied).
some may depend some on whatever '_' is defined as.
in my own practice, I have often used '_' as a no-op placeholder though
(dummy arguments, unnamed variables, ...), which could potentially
conflict with using it for something like the above.
I doubt 10% of programmers will ever be able to grasp the concept of building
grammars to program. But with the right useful abstractions, the right geometry
of objects, they won't have to. We are still a long way away from having a
circularly linked directed graph as a fundamental datatype, or an n-dimensional
mapping operator that sends messages to past states of programs and returns
what the results would have been. Hell people still type linear text in vi.
I use vi sometimes as well, but generally prefer Notepad-style graphical
editors (often gedit when using Linux, currently Notepad2 on Windows).
I guess I could use SciTE if I wanted to use the same editor on both
OS's (both Notepad2 and SciTE are built on Scintilla).
I generally prefer plain editors to the likes of IDE's like Visual
Studio or Eclipse.
_______________________________________________
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc
