https://miasap.se/obnc/data-abstraction.html
The examples near the top use the more familiar OOP approach, while the example at the bottom uses message sending.
2,544 karma · joined August 15, 2007
https://miasap.se/obnc/data-abstraction.html
The examples near the top use the more familiar OOP approach, while the example at the bottom uses message sending.
Please note: working proficiency in Dutch is strictly required for these roles, and we kindly ask for no automated applications. The rest of this post will continue in Dutch.
Wij zijn een non-profit die zich inzet om lesmateriaal voor scholen beter, betaalbaarder en flexibeler te maken, in zowel digitale als gedrukte vorm.
Werktijden en kantoordagen zijn flexibel en worden in overleg bepaald op basis van de rol. Wij bieden een competitief salaris.
Technologiestack: Git monorepo, TypeScript, Yjs en React, een beetje Python, OpenTofu/Terraform, Scaleway, managed PostgreSQL en managed Kubernetes.
Openstaande rollen:
- Senior/Lead Platform & DevOps Engineer
- Senior Backend Engineer/Architect
- Senior Frontend Engineer
- Senior Full-Stack Engineer
E-mail jobs[at]openeducation.foundation met (HN) + de functienaam in het onderwerp, samen met een korte introductie en een link naar je LinkedIn-profiel en/of GitHub. Als er van beide kanten een goede match lijkt te zijn, plan ik graag een kennismakingsgesprek in.
How would that work? Do you have a link?
We are a non-profit working to make teaching materials for schools better, more affordable, and more flexible, in both digital and print formats.
Working hours and office cadence are flexible and agreed based on the role. Dutch proficiency is required. We offer highly competitive compensation.
Technology stack: Git monorepo, TypeScript, Yjs and React, some Python, OpenTofu/Terraform, Scaleway, managed PostgreSQL, and managed Kubernetes.
Open roles:
- Senior/Lead Platform & DevOps Engineer
- Senior Backend Engineer/Architect
- Senior Frontend Engineer
- Senior Full-Stack Engineer
E-mail jobs[at]openeducation.foundation met (HN) + de functienaam in het onderwerp, samen met een korte introductie en een link naar je LinkedIn-profiel en/of GitHub. Als er van beide kanten een goede match lijkt te zijn, plan ik graag een kennismakingsgesprek in.
Thanks, I think that would work fine in most cases if you can open your editor with the 'prev' version and the current version in 2 panes (or in diff mode).
Do I understand correctly that if 2 people add a lot of information to one issue only one of them 'wins' and becomes visible? Or is it more subtle?
If only the latter one becomes visible, how do you get to the edits of the other person and 'merge' it again?
What if the pretty advanced e-government system decides it will not be unblocked?
> I use a mix of Markdown and Gherkin
Gherkin also has a Markdown based syntax that is not well known:
https://github.com/cucumber/gherkin/blob/main/MARKDOWN_WITH_...
I prefer that to the 'verbose' original syntax. MDG also renders nicely in code forges.
The UX actually matters, and TUIs are generally built for effectiveness and power (lazygit being an excellent example). But once you start adding mouse clickable tabs, buttons, checkboxes etc. you left the UX for TUIs behind and applied the UX expected for GUIs, it has become a GUI larping as a TUI.
That works great in practice, Gherkin even has a markdown dialect [1].
If you combine it with a tool like aico [2] you can have a really effective development workflow.
[1] https://github.com/cucumber/gherkin/blob/main/MARKDOWN_WITH_...
It does 2 things that are very important, 1: reviewing should not be done last, but during the process and 2: plans should result into verifyable specs, preferably in a natural language so you can avoid locking yourself into specific implementation details (the "how") too early.
The actual explanation (using code blocks) is almost impossible to read and comprehend.
https://github.com/superlucky84/fp-pack?tab=readme-ov-file#s...
Still, this approach is very useful for most business logic, too bad most programming languages don't provide a nice syntax for this.
While I appreciate Charm's aesthetics, I worry it leans too heavily on GUI paradigms, like popovers and buttons, rather than prioritizing the optimal keyboard efficiency used in traditional text-based interfaces.
Rust also offers it, but you need to specify it on the call side as well.
I am curious about your thoughts on var parameters (i.e. mutable references), as in:
proc increment(var x: int)
begin
x := x + 1
end
var i: int
begin
i := 10
increment(i) // i is now 11
end