The Jutty Fork

Objectives

• users:

  1. accessible to J newbies and experts alike
  2. No GUI, just console, but a USABLE console. J - Unix - TTY
  3. the same jutty on all platforms: portability in favour of special features
  4. requires only POSIX (or even pre-POSIX) runtime evironment
  5. integrated help (DoJ, quickref, libs), without the need for a web browser or the Internet. (Remember k's \?)
  6. integrated debugging of tacit code
  7. sanitized & documented dev tools
  8. sanitized & documented stdlib
  9. portability at the J level (no IF_LINUX32 etc.)
  10. no JAL (with multi-stage deployment and "remote source")

• portability of the source:

  1. portability in favour of special features
  2. requires only POSIX or even pre-POSIX build evironment (no specialized frameworks such as "cmake" or "qt").
  3. automated (self-configuring) builds with minimal manual intervention
  4. minimized #ifdefs in the C code
  5. SYS_FOO-#defines (implying all of OS, compiler used, architecture and supported features) should be abandoned; instead perhaps a single SYS_POSIX
  6. portability at the C level in favour of conditional code at the J level. (regex, sockets)
  7. source suitably structured for various package systems

• much better unix-style integration

  1. proper man pages
  2. unix-style installation with clear separation between (a) the installed J system and (b) the users' scripts; easy J upgrades without destroying local scripts.
  3. more unix-like behaviour (eg., current directory and path treatment)
  4. Less reinvention of the wheel but openess to existing unix tools.
  5. better interfaces to other unix tools (2!:0 without having stderr simply discarded). Examples: gnuplot, tcl/tk.
  6. "add-on libs" not (badly) duplicated with J but supposed to be taken from the host and its pkg management (optimized libs (lapack!), security-maintained).
  7. native packages for various unix/linux distributions

• language and lib:

  • long-term stability as a promise?
  • should avoid the perl trap (too many versions, too much of a lib)
  • should avoid the Haskell trap (too complex build => no platforms)