Also see WUFFS for a special purpose language which leans really hard on refinement to deliver safety with socks-blown-off performance in a specific niche.
The vast majority of programming languages would be terrible for production code in a real business setting. We share and discuss them here not because we're looking for something to replace the big few languages at work but because the niche and obscure ones often explore very interesting ideas.
One of the devs here. We plan to release an updated code generator (jolie2java) that will make it easy to do exactly that. (For Java, but Jolie is already designed to support other langs as well in the future.)
Specifically, you'll be able to use Jolie to write (tech-agnostic) APIs and then implement them in Java, using types automatically generated from the Jolie APIs.
This is good to hear - the big problem I have with justifying more niche languages is that I have to ultimately use some niche library at some point that only exists for more established languages.
I hope you guys try to make a first class transpiled language.
I'm pretty sure you've heard of at least one person named Jolie: https://en.wikipedia.org/wiki/Angelina_Jolie - but of course she's not French, I guess her parents picked the name because it sounded nice, and she thought it sounded so nice that she picked it as her stage name...
on the basis that there aren’t many kids named Pretty by their English speaker parents, surely it’s more likely that a non-French speaker would name their kid Jolie
Jolie stands for 'pretty/beautiful/attractive' in feminine form in french and is sometimes used as a noon when mentioning a person more often in a condescending manner.
It is used in industry, yes, but is still quite niche. For example I know of journalism tools at media companies, document systems, websites, and a payroll system. It's definitely used as a stable platform in a few places but could use more libraries (things are getting active there though, plus you can reuse anything from the Java world).
A lot of this looks similar to what GraphQL with something like Apollo Federation gives you:
1. A contract-first language where all of your queries (reads) and mutations (writes) are defined in the GraphQL type language.
2. Refinement types can be implemented with directives or custom scalars.
3. The "built for the networked age" section is very similar to what Apollo Federation gives you - the ability to move implementations of part of your GraphQL API service to different servers with end clients being unaware.
4. Protocol agnositic - technically GraphQL is protocol agnostic but in really nobody cares because everyone uses HTTP or Websockets.
It's a pragmatic one. It has no false negatives, and there's rarely a reason to care about false positives. (Especially not where a stricter regex would (be the only mechanism to) catch it, but a fake-but-valid address wouldn't trivially bypass it.)
Yeah, I agree, I think I'd have written that myself, but I don't think I'd reject it in review on that basis. I don't agree with sibling comment that it's 'shitty', it's trivially improved sure but it basically doesn't matter - if you want it to be actually correct you need to send an email to it for verification anyway.
Otherwise we can start saying not just not empty, it also needs no other @s etc. and before you know it we're rivalling the actually correct attempt up-thread. If you just want to catch typos, encourage entering real address (not just a space or full stop to fill mandatory field) then any basic thing is something, a compromise between legibility and how much it'll catch, we know there's a tonne of (mainly adversarial) bad input it'll miss, that's fine.
Too bad - if that's my email address and you're rejecting it, I'm going to sue you for denying service arbitrarily and win. Not every country is the USA.
Email address specs turn out to be rather complicated.
I really wish people wouldn't code their own checks rather than use already existing standards. Some languages like Java even include proper checks in their standard library: https://java.net/projects/javamail
Several jobs back I had no end of arguments with some Java devs about not writing their own checks, that kept routinely failing on legitimate addresses.
But why do you even need to validate that email? Send the subscriber a confirmation link - if they get it then it was valid, if not then it's on them to fix the situation in whatever way they find fit.
A single massive and unreadable regex isn't an appropriate way to validate a spec that complex. With its complexity it can't be logically evaluated- only tested, whereas a function that breaks the spec out into steps/parts is going to be a lot more maintainable, readable, and auditable.
It really is, I wonder if anyone has tested that extensively. It's so complex that just by reading it I don't think anyone would be able to confirm it matches the RFC correctly.
[0] https://docs.jolie-lang.org/v1.11.x/language-tools-and-stand...
dependant types are not refinement [0]
ts and rust have ideas to have them[1], but not so officially
[0]https://www.reddit.com/r/dependent_types/comments/ay7d86/wha...
[1]https://en.m.wikipedia.org/wiki/Refinement_type
The premise was interesting but working with it was bad.
Maybe it improved in the last 5/6 years, but I doubt it's used for many (or any) real use case.
I'm guess eventually this will be the way but not for a while.
Specifically, you'll be able to use Jolie to write (tech-agnostic) APIs and then implement them in Java, using types automatically generated from the Jolie APIs.
I hope you guys try to make a first class transpiled language.
According to data from INSEE (France's Census Bureau equivalent), since 1925, only 6 babies were named Jolie in 2011 and then 5 more in 2018.
There's a Joline which you'd pronounce pretty much like jolie as the n is very weak, but it's barely more popular.
Anyway, jolie does mean pretty, but it's not really a name (11~0 at this scale).
I'm guessing the other commenters are right, GP probably meant "Julie".
A more common last name is Joly which is old form from joli, the masculine form of jolie.
No? Most software I use is a single service (in a sense that it's compiled to a single executable).
It is, however, the first time that I see the 'airbender explanation'. Nicely done!
The docs are overly wordy and in desperate need of editing.
It claims it's a language, but it looks more like a DSL on top of Java with non-obvious syntax.
It's been around since 2014? Is it used for anything serious? Or just riding the microservices gravy train?
The docs really need some love.. : - )
1. A contract-first language where all of your queries (reads) and mutations (writes) are defined in the GraphQL type language.
2. Refinement types can be implemented with directives or custom scalars.
3. The "built for the networked age" section is very similar to what Apollo Federation gives you - the ability to move implementations of part of your GraphQL API service to different servers with end clients being unaware.
4. Protocol agnositic - technically GraphQL is protocol agnostic but in really nobody cares because everyone uses HTTP or Websockets.
The RFC says:
so I think the bit in front of the @ has to be non-empty.Otherwise we can start saying not just not empty, it also needs no other @s etc. and before you know it we're rivalling the actually correct attempt up-thread. If you just want to catch typos, encourage entering real address (not just a space or full stop to fill mandatory field) then any basic thing is something, a compromise between legibility and how much it'll catch, we know there's a tonne of (mainly adversarial) bad input it'll miss, that's fine.
very.”(),:;<>[]”.VERY.”very@\\ "very”.unusual@strange.example.com
Which country are you claiming this entirely implausible legal scenario would work in?
I really wish people wouldn't code their own checks rather than use already existing standards. Some languages like Java even include proper checks in their standard library: https://java.net/projects/javamail
Several jobs back I had no end of arguments with some Java devs about not writing their own checks, that kept routinely failing on legitimate addresses.