Sadly |> seems rather annoying to type on non-English keyboards. So far using an English language keyboard has always caused slow downs to emerge on other language ones. I think it became a major big detractor from functional languages at large. I know this is somewhat off topic, but maybe here someone does have experience with how to handle this in a better better way than learning and unlearning all the time. Bonus point of it’s easily portable between multiple computers with different OSs and keyboards.
It still amazes me that non-English Latin keyboard layouts exist! My native script is not latin, so the only thing I saw until my late 20ies is people just using two layouts, RU and EN, and switch between them with ctrl+shift. It was a revelation that people from Latin-script languages don’t do that, and tend to use a single layout that is a superset of English. I assumed that anyone outside of English speaking countries just uses two layouts!
You don’t need interfaces to be built into a language. If you have higher order functions and sum types then your language is powerful enough to implement them.
That said, they’re not used very much in Gleam and languages like Gleam.
In practice it is very rare in Gleam to have an interface like that. We prefer to solve specific problems rather than generalised version of them. This typically results in code that is easier to understand and modify, and often it runs faster.
I feel like it’s a very common problem to want to be able to swap in different implementations of eg some service. Like let’s say you need to send transactional emails, and you use Mailgun, so you define an interface that abstracts over that so you can swap it out with a test instance for your unit tests. Or one day the business decides to migrate from Mailgun to Sendgrid, so you need to swap that out in your implementation. If you use an interface, it prevents the impact from spreading everywhere throughout your codebase.
But yeah, the article you linked is helpful–you just manually create the implementations for interfaces which are just ‘types’.
Bearing in mind that I haven’t programmed in Gleam before now and this is probably not considered good gleam code, I imagine this is one way you could do it:
Edit: Apparently Gleam already has iterators implemented in the standard library! Seems almost identical to this representation, just with some user-defined types.
Sadly
|>seems rather annoying to type on non-English keyboards. So far using an English language keyboard has always caused slow downs to emerge on other language ones. I think it became a major big detractor from functional languages at large. I know this is somewhat off topic, but maybe here someone does have experience with how to handle this in a better better way than learning and unlearning all the time. Bonus point of it’s easily portable between multiple computers with different OSs and keyboards.It still amazes me that non-English Latin keyboard layouts exist! My native script is not latin, so the only thing I saw until my late 20ies is people just using two layouts, RU and EN, and switch between them with ctrl+shift. It was a revelation that people from Latin-script languages don’t do that, and tend to use a single layout that is a superset of English. I assumed that anyone outside of English speaking countries just uses two layouts!
It’s a bit annoying with my keyboard so I’ve a snippet/keybind to insert it. Might be worth trying.
Kinda surprised that no one has run into a need for interfaces (eg Java) yet. Or if they have, maybe kept quiet about it? 🤔
You don’t need interfaces to be built into a language. If you have higher order functions and sum types then your language is powerful enough to implement them.
That said, they’re not used very much in Gleam and languages like Gleam.
I tried, but I couldn’t find a way to express something like this in Gleam:
And have it be implemented by different types. What am I doing wrong?
Re: not used much in languages like Gleam, Elixir has protocols which basically do what I’m talking about…
Here’s a post that goes into this in detail: https://mckayla.blog/posts/all-you-need-is-data-and-functions.html
In practice it is very rare in Gleam to have an interface like that. We prefer to solve specific problems rather than generalised version of them. This typically results in code that is easier to understand and modify, and often it runs faster.
I feel like it’s a very common problem to want to be able to swap in different implementations of eg some service. Like let’s say you need to send transactional emails, and you use Mailgun, so you define an interface that abstracts over that so you can swap it out with a test instance for your unit tests. Or one day the business decides to migrate from Mailgun to Sendgrid, so you need to swap that out in your implementation. If you use an interface, it prevents the impact from spreading everywhere throughout your codebase.
But yeah, the article you linked is helpful–you just manually create the implementations for interfaces which are just ‘types’.
Yup you got it. If you have higher order functions then you have the ability to implement interfaces.
Bearing in mind that I haven’t programmed in Gleam before now and this is probably not considered good gleam code, I imagine this is one way you could do it:
Full example here.
Edit: Apparently Gleam already has iterators implemented in the standard library! Seems almost identical to this representation, just with some user-defined types.