undefined | Better HN

0 pointsjopsen8y ago0 comments

I've had similar thoughts, notably as a way to side-stepping the composability limits of current parsing theory. But these limitation are increasingly worked around...

And looking at rust, I can start to imagine a future where macros are powerful enough to support a lot of declarative coding.

When coding javascript today I write code like:

    // can be imported, and api.router() mounted in express
    let api = new API(...);
    module.exports = api;    

    api.declare({
      method: 'get',
      route: '/hello-world',
      description: `bla bla bla...`,
      scopes: {AnyOf: ['some-permission-string']},
      // (more properties)
    }, (req, res) => {...});

Effectively making large parts of the app declarative. It's still far from powerful enough. But I'm not sure giving up text is the way to get more powerful building blocks.

Declaring JSON + function is super powerful in JS. In rust macros might allow us to make constructs similar to my "API" creator, but with static typing. And who knows maybe macros can expose meta-information to the IDE...

0 comments

mpweiher8y ago

Nice.

But also a workaround, right? Because it's not actually declarative, it's APIs that are made to look declarative-ish.

So there's several layers of mismatch, for example most of the active ingredients being strings, meaning you're coding mostly in the string-language embedded into JS.

We do that a lot.

Probably time to start looking at our workarounds (and Macros are another workaround) and figure out what we are actually trying to do.

jopsenOP8y ago

> But also a workaround, right? Because it's not actually declarative, it's APIs that are made to look declarative-ish.

I'm not entirely sure what you mean...

In an ideal world "API" would be a keyword, similar to how "class" is a keyword for declaring/defining classes. Example:

    API MyApi {
      constructor(defaultName) {
        this.defaultName = defaultName;
      }
    
      /** some description */
      method: get
      route:  /hello-world
      scopes: some-permission-string || other-permission-string
      {
        let name = request.query.name;
        if (!name) {
          name = this.defaultName;
        }
        response.send('hello ' + name);
      }
    
    }
    module.exports = MyApi;  // similar to how you would export a class in JS

I think something _like_ this will be doable using rust macros in the future (if not already on nightly).

Whilst my JS code, where I create an API object and call API.declare(...) for each route isn't as neat as having an "API" keyword and code-generation for said keyword, it's pretty close.

I just write the API.declare(...) as something that collects arguments, and then those can be instantiated multiple times... Similar to how a class can be instantiated multiple times.

I do similar things for loading components that depend on each other: declare dependencies, define function for loading using said dependencies -- then have some library code construct a function that loads any desired component with maximum concurrency (by analysing the DAG).

borplk8y ago

We can't and don't have to give up text.

Text is essential for humans and could be a significant part of the interface (both reading and typing).

The problem is more about the underlying unit being text.

The problematic part of text is when we just write it freely and then have to parse it back and make sense of it which has very severe consequences.

This is because in the programming environment world we are forever stuck with a "text editor" mindset.

This means we shift the complexity away from the environment and pass it on to the compiler and the programmer which is not a good place for it to be.

So you can use "nano" to write very complex programs. Some people consider that a benefit, and in one way it is. However it is also simultaneously very problematic. Because it perfectly demonstrates just how far removed the authoring tool is from the problem domain.

The way I see it is that to unlock a new generation of software development experiences there's no way but to accept that we can't forever confine the act of programming to the primitive act of writing text like a book in a text editor.

The environment needs to be much more closely connected to the problem domain so that it can further empower you to do stuff.

jopsenOP8y ago

> The problem is more about the underlying unit being text.

I think richer editing, in effect editing the AST, rather than the concrete syntax is interesting.

But I'm not convinced that it's a blocker for making more declarative code. I think macros will get us very very far. The procedural stuff in rust, has me really excited about the future.

The downside of not using text as the underlying unit of truth is that you have to reinvent an IDE, version control, conflict resolution, review tools, etc. That takes a LOT of buy-in.

If you can 90% of syntactic sugar required from macros (and the like), you can work on the actual abstractions / declarations instead of the compiler toolchain.

Just my two cents.

j / k navigate · click thread line to collapse

0 pointsjopsen8y ago0 comments

I've had similar thoughts, notably as a way to side-stepping the composability limits of current parsing theory. But these limitation are increasingly worked around...

And looking at rust, I can start to imagine a future where macros are powerful enough to support a lot of declarative coding.

When coding javascript today I write code like:

    // can be imported, and api.router() mounted in express
    let api = new API(...);
    module.exports = api;    

    api.declare({
      method: 'get',
      route: '/hello-world',
      description: `bla bla bla...`,
      scopes: {AnyOf: ['some-permission-string']},
      // (more properties)
    }, (req, res) => {...});

Effectively making large parts of the app declarative. It's still far from powerful enough. But I'm not sure giving up text is the way to get more powerful building blocks.

0 comments

mpweiher8y ago

Nice.

But also a workaround, right? Because it's not actually declarative, it's APIs that are made to look declarative-ish.

So there's several layers of mismatch, for example most of the active ingredients being strings, meaning you're coding mostly in the string-language embedded into JS.

We do that a lot.

Probably time to start looking at our workarounds (and Macros are another workaround) and figure out what we are actually trying to do.

jopsenOP8y ago

> But also a workaround, right? Because it's not actually declarative, it's APIs that are made to look declarative-ish.

I'm not entirely sure what you mean...

In an ideal world "API" would be a keyword, similar to how "class" is a keyword for declaring/defining classes. Example:

    API MyApi {
      constructor(defaultName) {
        this.defaultName = defaultName;
      }
    
      /** some description */
      method: get
      route:  /hello-world
      scopes: some-permission-string || other-permission-string
      {
        let name = request.query.name;
        if (!name) {
          name = this.defaultName;
        }
        response.send('hello ' + name);
      }
    
    }
    module.exports = MyApi;  // similar to how you would export a class in JS

I think something _like_ this will be doable using rust macros in the future (if not already on nightly).

Whilst my JS code, where I create an API object and call API.declare(...) for each route isn't as neat as having an "API" keyword and code-generation for said keyword, it's pretty close.

I just write the API.declare(...) as something that collects arguments, and then those can be instantiated multiple times... Similar to how a class can be instantiated multiple times.

borplk8y ago

We can't and don't have to give up text.

Text is essential for humans and could be a significant part of the interface (both reading and typing).

The problem is more about the underlying unit being text.

The problematic part of text is when we just write it freely and then have to parse it back and make sense of it which has very severe consequences.

This is because in the programming environment world we are forever stuck with a "text editor" mindset.

This means we shift the complexity away from the environment and pass it on to the compiler and the programmer which is not a good place for it to be.

The environment needs to be much more closely connected to the problem domain so that it can further empower you to do stuff.

jopsenOP8y ago

> The problem is more about the underlying unit being text.

I think richer editing, in effect editing the AST, rather than the concrete syntax is interesting.

But I'm not convinced that it's a blocker for making more declarative code. I think macros will get us very very far. The procedural stuff in rust, has me really excited about the future.

The downside of not using text as the underlying unit of truth is that you have to reinvent an IDE, version control, conflict resolution, review tools, etc. That takes a LOT of buy-in.

If you can 90% of syntactic sugar required from macros (and the like), you can work on the actual abstractions / declarations instead of the compiler toolchain.

Just my two cents.

j / k navigate · click thread line to collapse