Tuesday, February 19, 2019

The Zepton Class for Core Functionality


For the Zepton programming language, I am trying to develop a "core" class of functionality that is static attributes an methods that are implicitly included with a static import into the generated Java code for a Zepton program. This core class is Zepton.java, and will be a nexus of input, output, utility, and other functionality that is available in multiple Java classes--but is implicit for a Zepton program.

More specifically with an example:

package zepton.demo;

prog helloWorldUserName {
do
  println("Hello World!!!");
  println();

  print("What is your name?->");
  String userName = readln();
  printf("Hello: %s %n", userName);

  exit(0);
}

When transcompiled into Java code the result is the Java class:

package zepton.demo;

import static zepton.lang.Zepton;

public final class helloWorldUserName extends Object {

  private helloWorldUserName(){}

  public final static void main(final String[] args){

    println("Hello World!!!");
    println();

    print("What is your name?->");
    String userName = readln();
    printf("Hello: %s %n", userName);

    exit(0);
  }

}

Users learning to program on the Java platform using Zepton do not need to focus on peripheral details that a full Java class will entail, nor need focus on the details of such classes as java.lang.Runtime, java.lang.System, etc. The implicit static import is "auto-magically" generated by the transcompiler.

So, the problem and issues are around the "core" Zepton class with the implicit functionality. But in writing the core functionality, I'm running into some issues with the Java programming language--going back to the fundamentals has revealed some fundamental glitches or design flaws in Java.

The strength of the Zepton programming language is it is an extension of Java, with a program structure and concept. But this is also the weakness...adding a cool new feature is possible, but it will be Zepton-centric and the user will have to "unlearn" this feature...and the two groups of users are learning Java but don't want to drown in the Java vastness, and a user that wants a quick-and-dirty program without all the Java trimmings and accoutrements.

So for the core Zepton.java class, I am avoiding extending Java with Zeptonic-only features, but still want the core Zepton feature class--competing requirements for something so foundational--more on this as I codify.

No comments:

Post a Comment

Note: Only a member of this blog may post a comment.