Live data from Hacker News

Choral: Choreographic Programming for Java

choral-lang.org

11–19 of 19 posts

Re: Choral: Choreographic Programming for Java

#11
post #8

Earlier quoted context omitted.

Two things: * Unit testing is different from integration testing. They aren't interchangeable. Mainstream languages offer units of code s.a. a function, a class, a module and so on. Unit testing refers to testing the functionality implemented by a single such unit. There's no expectation that it will prove the entire program is correct, but it helps the developer to identify errors on the smallest testable level. Int…

Define a unit.

I did it in the post you replied to.

Re: Choral: Choreographic Programming for Java

#12
post #9
post #8

Earlier quoted context omitted.

Two things: * Unit testing is different from integration testing. They aren't interchangeable. Mainstream languages offer units of code s.a. a function, a class, a module and so on. Unit testing refers to testing the functionality implemented by a single such unit. There's no expectation that it will prove the entire program is correct, but it helps the developer to identify errors on the smallest testable level. Int…

Unit testing: Well, which is it? Testing a function, a class, or a module? I didn't give my definitions of testing. I said when you go out into the OO worldview, different people will call it different things, so ignore it, it's not important. Sometimes one person will call it two or three different things. E.g. Unit testing is a function testing vs. unit testing is class testing. Demeter: That's the thing I called w…

In order for you to understand what a "unit" is, you need to first consider that there are different languages with different units. The definition of a "unit" doesn't give you a concrete size, it gives you a size relative to the language or even the project you are working on. It will be something the programmers working on the project will have to agree on, when they set to design unit tests.

Other examples of relative units: pixel (they don't have a fixed size in software), portion (as in cooking: it will depend on the place the food is served, intended audience), decibels (they don't measure the absolute volume of sound, they measure how one volume corresponds to another).

But... who am I kidding? If you were intelligent enough to understand the subject of this thread, you were certainly intelligent enough to understand what a "unit" is in unit testing. You are not arguing in good faith.

> Sometimes one person will call it two or three different

This is poor ability to reason: if two people disagree it doesn't follow that everyone is right.

> If it's wrong from the outset, simply disregard it.

This is poor ability to reason: criticism of a concept is just as valid of a way to discuss the subject as is praise. Nobody should be told not to discuss the subject if they think the subject is defective.

> Demeter: That's the thing I called wishful thinking.

While providing no arguments and no evidence.

Re: Choral: Choreographic Programming for Java

#13

I only skimmed the page and it looks like a really cool idea, but I have a question about this: types to let you express things like “the Client communicates this to Service, then Service communicates that to the Login Provider, then […]” If the client needs to know about all that stuff that happens after its call to Service, isn't Service a leaky abstraction? My idea of OO, which I got from GOOS[1], is that each obj…

This is from a vaguely interested outsider, I hope an expert chimes in.

My understanding is that in choreographic programming, the protocol/choreography is considered an explicit "thing". That explicit thing is explicitly defined in one place, as opposed to the implementation being divided up across multiple places, like the client, server, etc. This is the explicit opposite of "reason[ing] about each object/microservice in isolation", at least with regards to the protocol. Since the protocol is one "thing", there is no reason for abstraction: Abstraction is for when you combine multiple "things".

In the example, the client's network code may know about internals of the service's network code, but that's not a problem. This doesn't mean that the client's business logic knows about the service's business logic. It's also not a problem that the client knows that there is a separate login provider that could be communicated with. You may be thinking, "oh, if the client knows about the login provider, it might try to talk to it directly". But no, because the entire network code is generated based on the protocol specification, and the protocol specification doesn't include this.

You might take the generated network code and break it by hand. I guess the response to that is, "please don't".

Again, I hope someone can correct this or explain it better.

Re: Choral: Choreographic Programming for Java

#15
post #8
post #7

Earlier quoted context omitted.

That's wishful OO thinking. It's led to Mockito-style testing (some people call it 'unit', others call it 'integration'). You decide that the behaviour of file.read() is that it returns a string of its contents. You judge your software correct on the basis of how it processes the returned string. Then you launch, and in the real world, the behaviour of file.read() is to return a FileHandleNotOpen exception, so you fi…

Two things: * Unit testing is different from integration testing. They aren't interchangeable. Mainstream languages offer units of code s.a. a function, a class, a module and so on. Unit testing refers to testing the functionality implemented by a single such unit. There's no expectation that it will prove the entire program is correct, but it helps the developer to identify errors on the smallest testable level. Int…

I've been working on a language that codifies a single abstract _situated_ unit of computation. It sits at the intersect of memory, process placement, callstack, lifetime, and domain graph. Because it's the only unit of structure in the language, everything is layered recursively, which means the compiler can reason about the codebase at layers that we'd normally leave to third party tooling, ci, or other infra:

https://hale-lang.org

Re: Choral: Choreographic Programming for Java

#16

Since HN is discovering choreographic programming today [1], I thought I’d share the compiler we’ve been working on for a few years now. Feel free to ask questions below and I’ll answer as best I can :) [1]: https://news.ycombinator.com/item?id=49209385

The docs link for for Wyzer give a 404 for https://wyzer-lang.vercel.app/docs/overview/01_introduction/

Re: Choral: Choreographic Programming for Java

#17

Earlier quoted context omitted.

I did it in the post you replied to.

No, you defined what you mean by "unit test". What's the unit.

> Mainstream languages offer units of code s.a. a function, a class, a module and so on. Unit testing refers to testing the functionality implemented by a single such unit.

Re: Choral: Choreographic Programming for Java

#19

Since HN is discovering choreographic programming today [1], I thought I’d share the compiler we’ve been working on for a few years now. Feel free to ask questions below and I’ll answer as best I can :) [1]: https://news.ycombinator.com/item?id=49209385

It seems there are many projects trying to find idioms and languages to describe distributed concurrent logic without programming the data transport and synchronization.
Post reply on HN