mckinney

This is already implemented with manifold's unit expressions, but is made richer and more readable via concatenative features. For instance, '1.5 * USD' is not as readable as simply '1.5 USD'. However, unit expressions leverage operators for dimensional arithmetic:

Force f = 5 kg * 9.807 m/s/s; // result: 49.035 Newtons

Area space = (20ft + 2in) * (37ft + 7.5in); // result: 758 37/48 ft²

All unit expressions internally store amounts as SI units, which enables interunit expressions.

Length height = 6 ft + 4 cm; // mix SI and US units

out.println(height.to(ft)); // display any unit

You aren't limited to units. Generally, any concatenative sequence can be implemented. Like ranges:

IntegerRange range = 1 to 5;

Here the `to` identifier's type implements reactions to Number types to produce range types, which enables:

for (int i: 1 to 5) { out.println(i); }

See the manifold project's Unit and Science modules:

Units: https://github.com/manifold-systems/manifold/tree/master/man...

Science: https://github.com/manifold-systems/manifold/tree/master/man...

Ha! I implemented "concatenative" programming for Java as Binding [1] (or Unit) expressions, but had no idea. Seriously, never came across that term before this post.

The idea with binding expressions is the type of expression A and the type of expression B implement "reactions" with one another in order to form a binding expression when they are lexically adjacent.

65 mph

The type of `mph` defines a post reaction method with the type of `65` as an argument that results in type Rate. As I understand it this is concatenative, right?

Another example:

Money payment = 1.5M USD;

There are tons of these.

Concatenative programming in general feels like it should have a more prominent place in mainstream languages. Just my take.

[1] https://github.com/manifold-systems/manifold/tree/master/man...

So, choke the oceans too? Which is it? Is corn-derived ethanol a fabulous "renewable energy", or is it yesterday's bad idea?

Except, if not for environmentalism, this mess would not exist.

California policy makers' (ardent environmentalists) "Low Carbon Fuel Standard" require 10% corn-derived ethanol in gasoline sold in the state. Are they not environmentalisting hard enough?

And end government subsidized corn vis-à-vis ethanol production.

I suggest you do a bit of reading if you truly don't understand that corn ethanol is widely considered a "renewable fuel."

Thank you!

Yes, Manifold already supports Java 15 multi-line strings (aka text blocks) like this:

    var myValue = """
    [>.js<]
      function foo() {
        return "hi";
      }  

      foo();
    """;

You can embed a resource fragment as either a declaration or a value. You use a string to embed a value fragment as with the JS example above. Note the [>.js<] header indicates the resource type for the string, similar to your annotation. As you surmised, an expression such as a string literal cannot be annotated.

Right, but that is just syntax highlighting. This is resolving the content of the string type-safely, at compile-time.

> but is there really a need to have this kind of language interoperability at compile time?

Well, if you want to leverage Java's static type system (and why not?), the answer is, yes. I imagine you'd want type and member references to the other language to resolve statically using the compiler, right? Similarly, why not have the same functionality in your IDE? Plus code completion, usage searching, refactoring?

Now, as I mentioned in an earlier comment, the embedding part of this addresses just a small segment of use-cases e.g., scoped query editing. The vast majority of other cases work directly against resource files, type-safely. Read more about that here:

https://github.com/manifold-systems/manifold

> Good IDE lets you move between the resource file and the code with a single click.

Well, not exactly. Most IDEs do NOT support clicking through a generated method call to the corresponding element in a resource file. Manifold is all about that. See it in action: http://manifold.systems/images/graphql.mp4

The Manifold fragments discussed here address only a narrow band of use-cases where embedding the resource improves the dev experience, like with queries and such. It's not for everyone, though.

At compile-time manifold-js[1] parses JS and generates Java types (stubs), which forward execution to rhino at runtime. Basically, JS seamlessly mapped onto Java's type system.

[1] https://github.com/manifold-systems/manifold/tree/master/man...

Hi, you can blame me for this. It's a Java compiler plugin[1], which is similar to an annotation processor, but can hook into the compiler at a much earlier stage, which allows it to contribute to all phases of the compiler, including the Parser phase. The Manifold plugin takes full advantage of this, hence its ability to analyze comments, contribute to bytecode generation, etc.

[1] https://docs.oracle.com/javase/8/docs/jdk/api/javac/tree/com...

In most cases, the devs that should be concerned about debugging generated code are the authors of the generator. If there are bugs in released code, consumers of the API should file against them. In any respect, as I mentioned in a previous comment when a resource is selected you can view its generated source via Edit | View Java Source.

You can see the generated code in the IDE via Edit | View Java Source when a resource is selected. And you can debug it as well. Sort of the best of both worlds. What makes Manifold most interesting, however, is the entire dev experience when used in the IDE. This short screencast demonstrates some of that: http://manifold.systems/images/graphql.mp4

But the main idea with this is to avoid the pitfalls of conventional code generation such as GQL Code Generator. See "The Big Picture"[1] in the core docs.

[1] https://github.com/manifold-systems/manifold/tree/master/man...

The Manifold project[1] provides string interpolation for Java. You enable it as a Java compiler plugin, it's pretty cool.

[1] https://github.com/manifold-systems/manifold/tree/master/man...

It's both. If the popularity of new languages is any measure, static languages have quietly won the static v. dynamic war over the last few years: TypeScript, Kotlin, Swift, etc. Also considering the onslaught of static type checkers and compilers for otherwise dynamic languages such as Ruby, Python, etc. One must conclude static type analysis is everything, or at least it appears to be. IDEs are for the most part measured by how well they incorporate static analysis with features such as deterministic code completion, navigation, usage searching, refactoring, and the like. New IDEs for old static languages are finally arriving such as CLion. Not that IDEs can't be built for dynamic languages, they can, but they tend to be less efficient and less capable because static type analysis is so much more difficult to achieve due to the inherent nondeterminism.

I'd wager a lot of developers, good ones, share your sentiments. Git is a well designed, dependable SCM, there is no question. But its command line UI is awful, far too close to the metal. I'm not at all surprised though, it's a UNIX cultural thing -- ignore the 80/20 rule and use the command line for everything. Compare installing anything on Linux vs. Windows. It's ridiculous.

Yes, marketing a "visual" programming tool for non-programmers always struck me as a bit reckless, if not dishonest. But ObjectVision was fun while it lasted though. The way it automatically connected ("linked") with desktop databases was impressive for its time.

The Manifold JSON compiler plugin[1] pairs nicely with IntelliJ's JSON support. It's the only type-safe, truly schema-first framework I've encountered (that's also fully integrated into an IDE).

[1] https://github.com/manifold-systems/manifold/tree/master/man...

Ha!

Nice. While I suppose Pascal did suffer a bit from its "learning language" beginnings, it was wildly popular as Delphi.

If only Anders/Borland had designed Delphi as a VM, similar to the JVM. Of course he did that for MS with J++ (and then C#), but had Borland done it first with Delphi, would MS still have squashed them? Probably.

As for the Introduction posted here, Nice! Well written and densely informative. Refreshing to see some focus on Pascal.

One feature I'd like to see borrowed in other languages: Class references. In my experience this feature would be extremely useful for code generators, say in Java. For instance, you get virtual static methods and constructors. Man, that would be nice.