HyperC

[Salem]

Turning C into Perl, one graphic character at a time.

You turned printf into ink.
What if I want to print to stderr, or indeed any other open file?

You turned if/else into case.
What if I want to use an actual switch/case ?


> code writing efficiency
When you get past the student homework phase, you're going to be spending more time reading lots of documentation, design, other code than actually writing new code.

The modern trend is creating languages which are easy to read and understand by humans. Programs are read by humans far more often than they are written by humans (if you exclude the write once, read once, throw away student assignments).

HyperC fails so miserably on the readability scale because you seem to think that the only thing that matters is keystrokes when entering the program for the first time.

I'm reminded of this.
Question 10.2

And this.
The International Obfuscated C Code Contest

[laserlight]

So that you can easily see the value type and there is no confusion as to what is happening

That's not a bad goal, but C's printf already provides that with the format specifers. Contrast:

printf("x=%lu", x);

With HyperC:

ink "x=" unsigned long x;

It is clear that for the goal of "code writing efficiency", C's printf wins against HyperC's ink while being equal in the goal of "no confusion as to what is happening" except for the special cases of int, double and char (but then the shortcuts for these are arguably cryptic, which is a minus point for the latter), i.e., HyperC's syntax sucks when measured against its stated language design goals. Whereas if HyperC left out the type requirement:

ink "x=" x;

HyperC would win in the former; and while C might have a slight advantage in the latter, it can be mitigated by code hinting tools that are widely available among editors/IDEs these days, i.e., HyperC's syntax would now be good when measured with its stated design goals.

Furthermore, I note that in your documentation under "variables", you state that "$ = CHAR", but in post #10 you state that "$ is a string".

[Structure]

When you get past the student homework phase

next...

[Structure]

if HyperC left out the type requirement

This is an interesting concept. I would agree it sounds good and i will take a look at implementing such a thing. It actually opens up a lot of things as far as not just for ink. My only issue is being able to see the variable type quickly when looking at it.

you state that "$ = CHAR", but in post #10 you state that "$ is a string"

Aside from the confusion... like i said it's beta and i appreciate the comments.

[Structure]

FYI: this works...

@{
    $*str = "testing";
    ink "%s", str;
};

[Structure]

including files:

  :>filename.c;

using with ;
with prepends to every line.
setting with to nothing escapes it.

with someObject.;
  name = "testing";
  number = 001;
with;

using and ;
and appends to every line.
setting and to nothing escapes it;

and "\n";
  ink "line 1";
  ink "line 2";
  ink "line 3";
and;

example:

 loop 1 to 15 as i {
   with ink ; and "\n";
      "line %i", i;
   and;with;
 };

[Structure]

easy to read and understand by humans

HyperC is for developers

why does HyperC require every line of code to end in a semi-colon

so that you are free to structure code in any way you like.
such as long lines of multilines, even the whole project in one line if you want.

you seem to think that the only thing that matters is keystrokes

HyperC's syntax would now be good when measured with its stated design goals.

interesting...

[laserlight]

HyperC is for developers

Have you forgotten that (other than specialised AI), developers are humans?

so that you are free to structure code in any way you like.
such as long lines of multilines, even the whole project in one line if you want.

Why not make them optional for such cases instead? After all, what you have described are generally coding anti-patterns or would be automated (as in the case of compressed Javascript), so they shouldn't see much use being written by developers beyond obfuscated code contests.

[Structure]

Why not make them optional

Semicolon - Wikipedia

this was a divisive issue in programming languages from the 1960s into the 1980s.

two statements are placed on the same line; this is legal, because the semicolon separates the two statements.

The semicolon, as a mark separating statements, corresponds to the ordinary English usage of separating independent clauses, and gives the entire program the gross syntax of a single ordinary sentence.

[laserlight]

You should actually make an argument supporting your own language's design goals rather than just quote wikipedia.

[Structure]

When compiling you can use -x to skip HyperC compilation.
This can be used to create your own compilation structures...

using

:>filename.ext;

example

:>header.file;
int main() {
   :>main.file;
};

[Structure]

<stdio.h>;

@numbers( #one, #two) {
  ink "%i\n", one;
  case one != two {
    case one > two {
      one--;
    } || two > one {
      one++;
    };
    numbers(one,two);
  };
};

@{
    float n = 0;
    ink "Enter Number: ";
    scanf( "%f", &n );
    numbers( 1, n );
};

[Structure]

What if I want to use an actual switch/case ?

It works.

  a = 1; b = 2;
  case b == 2 {
    switch (a) {
      case 1:
        ink "it works.";
      break;
    };
  };

ink "x=" unsigned long x;

invalid.

you're going to be spending more time reading lots of documentation, design, other code than actually writing new code

false.

[laserlight]

If this is invalid:

ink "x=" unsigned long x;

Why is this valid?

ink "x=" #x;

HyperC looks to be so inconsistent as to be unusable.

Are you familiar with expressing grammar formally? At the moment it looks like you're mostly making things up and so there's no rhyme or reason as to why some syntax is valid whereas other syntax is invalid.

[Structure]

HyperC looks to be so inconsistent

These are also valid:

  printf("x=%lu", x);

  ink "x=%lu", x;

Are you familiar with expressing grammar formally?

no.

making things up

I built HyperC...