Arc Forumnew | comments | leaders | submitlogin
Programming in a vacuum (stanford.edu)
5 points by almkglor 5995 days ago | 17 comments


3 points by eds 5994 days ago | link

"When you're writing desktop software, there's a strong bias toward writing applications in the same language as the operating system. But with Web-based software, especially when you have the source code of both the language and the operating system, you can use whatever language you want."

http://www.paulgraham.com/avg.html

-----

6 points by almkglor 5994 days ago | link

We still need libraries, right?

String processing libraries especially, also database libraries, distributed message passing libraries, etc.

Everyone! Come! Let us go forth and write more Arc libraries, document them real good, and push them on Anarki!

-----

4 points by kens 5993 days ago | link

Writing libraries is a Good Thing, but trying to create a large collection of libraries for Arc strikes me as a bit of a hopeless cause. After all, Lisp hasn't been able to reach a "critical mass" of libraries and it has many, many more people involved.

I think Arc would be much better off with a way to leverage existing libraries. Easiest would be to use MzScheme's libraries, but that set of libraries is somewhat limited. (I'm currently experimenting with using MzScheme's OpenGL library from Arc; the object-oriented stuff is a big pain since it doesn't play well with Arc.)

Alternatively, if Arc had a way to access the libraries from, say, Python, .Net, or Java, it would gain access to a huge library base. A couple big problems are how to map the language datatypes between the languages, and how to get the runtimes working together.

-----

3 points by almkglor 5992 days ago | link

Maybe make an arc2jvm? Perhaps even arc2java, I'm sure a subset of Java can be made sufficiently C-like to compile down to (and we even get GC for free).

> A couple big problems are how to map the language datatypes between the languages

Bingo

-----

1 point by etal 5990 days ago | link

Looks like this is the official way to put another language on top of Java:

https://scripting.dev.java.net/

(Note their subtle language that any higher-level language running on the JVM is a "scripting" language.)

I haven't worked with it, but if it handles the mapping of Javascript's type system onto the JVM, then maybe it will do the same for Arc.

-----

1 point by almkglor 5989 days ago | link

Does it allow "script" code to be compiled down to java or jvm bytecode, or is it strictly an interpreter for the scripting language?

-----

1 point by etal 5989 days ago | link

I'm miles out of my league here, but in the interest of science I grabbed the spec, JSR-223. Here's the juice:

Introduction:

  The original goal of JSR-223 was to define a standard, portable way to
  allow programs written in scripting languages to generate web content. In
  order to do this, it is necessary to have a common set of programming
  interfaces that can be used to execute scripts in scripting engines and
  bind application objects into the namespaces of the scripts. Therefore, in
  addition to a framework for web scripting, the specification includes a
  standardized Scripting API similar to the Bean Scripting Framework. It uses
  the Scripting API to define the elements of the Web Scripting Framework.

  [...]

  There are several areas which are intentionally omitted from the
  specification:

  - The specification does not define how scripting languages should enable
    the use of Java objects in scripts, although it is assumed that the
    scripting languages implementing the specification have this
    functionality.

  - The specification does not distinguish between scripting implementations
    that compile script sources to Java bytecode and those that do not.
    Script engines that do can be used to implement the specification, but it
    is not required.

  - The specification makes no requirements of scripting languages or the
    syntax uses to invoke the methods of Java objects in the languages.

Overview:

  In this specification, a scripting engine is a software component that
  executes programs written in some scripting language. The execution is
  generally performed by an interpreter. Conceptually an interpreter consists
  of two parts: a front-end which parses the source code and produces an
  internal representation of the program known as intermediate code, and a
  back-end which uses the intermediate code to execute the program.

  The back-end of the interpreter, also known as the executor, uses symbol
  tables to store the values of variables in the scripts.

  [...]

  Scripting engines which implement the fundamental scripting interface
  defined in this specification are known as Java Script l20 Engines.
  Conceptually, a Java Script Engine can be thought of as an interpreter, but
  this may not actually be the case. For instance scripts executed by a
  single Java Script Engine may be executed internally by different
  interpreters.

Technologies:

  - Java Language Bindings – Mechanisms that allow scripts to load Java
    classes, create instances of them and call methods of the resulting
    objects.

  - General Scripting API – Interfaces and classes that allow script engines
    to be used as components in Java applications.

  The specification does not deal with issues of scripting language design or
  interpreter implementation.

So, it looks like the way you interpret, compile and execute the code is your own business, but if your own ScriptEngine implementation matches the specified API, it will work with existing Java tools and frameworks, particularly for the web. It's modeled after Rhino, so some parts of the Rhino back-end might be directly reusable.

-----

3 points by absz 5993 days ago | link

This is a good point. There is a C interface, and C has innumerable libraries, but working with C can be… icky.

-----

4 points by stefano 5994 days ago | link

What about a TODO list of needed libraries? Everyone could peek one and develop it. I'm currently working on a client side http library.

-----

3 points by almkglor 5992 days ago | link

TODO:

  A reasonably quick substring-matching library
  Database

-----

2 points by absz 5994 days ago | link

Hear hear! Let there be libraries! The school year's almost over, and I'll contribute more then. And I second the idea of a list of necessary libraries that stefano proposed.

Also, has anyone else found themselves accumulating a file of utility functions? I have one with a little fewer than 30 functions which I find generally useful. There's probably some duplication of standard stuff, but there are also things that aren't. If other people have these, we might put the common functions on Anarki.

-----

2 points by almkglor 5994 days ago | link

I suggest that such simple routines be pushed onto Anarki then.

As an aside: it would probably be a good idea to start adding docstrings to everything in Anarki; this would help catch duplication of effort.

-----

3 points by stefano 5993 days ago | link

What about automatically collecting every function/documentation pair and putting everything on the Anarki wiki?

-----

1 point by almkglor 5992 days ago | link

Err, I don't understand exactly what you mean, can you expand on this?

-----

1 point by stefano 5991 days ago | link

I mean scanning Arc files or, better, the help* table and gather information in text files formatted in a wiki-friendly format in order to easily put them on the Anarki wiki.

Edit: have a look at the file lib/help-to-wiki in Anarki (just pushed it).

-----

1 point by almkglor 5990 days ago | link

Arki doesn't support tables yet.

Also, Arki supports <arc></arc> tags, which adds the help* table entries as the mouse hover strings on symbols.

-----

1 point by etal 5990 days ago | link

I like paragraphs[-3:-1] in particular; I've had a vague sense of that idea for awhile.

In choosing how to write an app for someone else's machine, you're right, I do start with a list of what's already available to work with. Can I tweak the environment? Use shell scripts? Rely on an interpreter? Use long processes? Windows is particularly limiting, since it's hard (for me) to track down how to talk to the system outside of the standard Visual Studio portal. Everything else (e.g. py2exe) feels a bit hackish or uncertain.

However, for web and Unix applications, you don't use just one language -- your program is the whole system. An FFI is nice, but I'm happy enough to run a few background processes, call a few scripts as needed, in order to do platform-specific tasks, crunch some text, and generally solve the problems that have already been solved. (Maybe this says more about the projects I work on than programming in general.)

For the libraries that we do need -- looking at how I use Python, for instance, I see a core set of libraries that should be in the standard library for any exploratory programming -- everything in C (all operating system features), some way to get at the runtime's internals, string processing, low-level talking to databases, some concurrency support, development tools like profiling and debugging, parsers & serializers for common file formats (XML, JSON, etc.) ... and finally, a way to talk to code in other languages. Re-implement the complete Java or .NET (Mono?) libraries sounds like quite a rabbit-hole, and quite a high barrier to entry for new languages, when the core system libs and an FFI can get you most of the way there with a lot less effort.

-----