HN user

eeue56

86 karma
Posts0
Comments32
View on HN
No posts found.

Derw, a human written Elm fork by me, is largely self-hosted. I took that decision with inspiration from Go: 1) it gave me a large codebase which could be used to assess language features on and 2) it gave me motivation to improve generalized performance rather than focusing on the niche use cases (web-rendering).

You're missing Derw from that list: https://www.derw-lang.com/. Predates all the others, and is from a former core team member (me). I'm also the author of server-side Elm experiment known as [take-home](https://github.com/eeue56/take-home) from 11 years ago. I can see a lot of patterns in Sky's codebase which seem trained on Derw's codebase.

Also authored the first Elm-in-Elm compiler for a limited subset for json-to-elm, then leading to a pure Elm virtual-dom implementation used for elm-html-test!

Tools to help my mental health tracking[0], and sharing with others how I manage my limited amount of energy[1]. They're kind of related, since mental health impacts my energy, so I've needed to prioritize and really make sure I'm spending my time and energy on things that matter. Usually, there's a good mix of things I enjoy doing with things I gain a lot out of. I've spent a lot of time thinking about this!

I've used my app in various forms for around 5 years, rewritten multiple times. But now I'm creating surrounding tooling to help others put my mental model for personal life prioritize to use. I'm writing in the "Saving Spoons" Substack as I go, trying to explain why and how I do things, with advice for others trying to do the same thing.

[0] https://github.com/eeue56/gobaith/

[1] http://savingspoons.substack.com/

Patagonian Welsh 10 months ago

Native Welsh speaker here! It has always been a dream of mine to go to Y Wladfa, and share a bond through language with people there.

One fun fact - my dad took some higher-learning Welsh exam as an adult. They had to time the exam to match Patagonia, as they were given the exact same exam to avoid any cheating.

Oh, there were definitely multiple things wrong. Bear in mind that this was 12 years ago, so this is just what I took away with me as an on-going learning. Obviously showing errors to users is an obvious takeaway, but it's a side discussion from affordance.

Results were sent as a CSV file - basically a raw export of the data the server got, not something that was read from the DB. So the operation to save to DB and to send the email were intended to be (almost) parallel operations. The errors weren't shown to users, though there was error handling for other cases that did show the user.

We actually did test. We didn't test in the exact same conditions or environment (i.e with no internet access), as we didn't find out about the no-internet restriction until the last minute. That is covered in this paragraph:

While this bug was a costly mistake, we learned from it. Whenever we would deploy code-last minute, we'd try to test it more rigorously. If we were running a study without internet access, we'd make sure to test in the same environment. We hadn't accounted for the environment change, partially due to the short notice for the locked-down machine, but also just because we didn't test with the exact same restrictions.

Author here!

Indeed - I have an extended equivalent from CGI-bin that I'm including in the full story in the book, since running things as a script vs as a program has different implications for killing the running process. The patterns you mention here tend to be my preferred way of working - exhaustiveness checking of branches. In modern TypeScript, I enforce that via union-type error handling rather than using exceptions (which are a nightmare when it comes to affordance imo). I'm generally a functional programmer rather than an imperative programmer. But the case mentioned in the blog post was about 12 years ago now, so it didn't have the same options as we currently have.

Author here!

The way I put this practice into place involves accepting that people will just do whatever they find easiest, regardless of whether it's technically the right thing to do. I account for that when I'm designing APIs, languages ([Derw](https://www.derw-lang.com/)), frameworks, or tooling. If I make the correct thing the obvious or easiest thing to do, less people will do the incorrect thing. They will still do incorrect things, it's human nature. But they'll do it less frequently.

Author here!

In this case, I think the actual API we used would take a callback for success, and a callback for errors. I just used JS an example for how unnatural it would be to call something that exits the entire script early.

I have a big problem with promises + exceptions generally in JavaScript - much preferring union types to represent errors instead of allowing things to go unchecked. But I left that out as it was kind of a side-note from the point of affordance.

The "trendy stack" comment seems misplaced. CS is famously written in Ruby on Rails, not PHP, perhaps one of the most "trendy" stacks at the time[0]. Coincidentally, CS is also awfully slow with frequent errors. Managing all my guests when my city was in high season was usually much easier to do via WhatsApp.

To be honest, as a top host in my city, the only features that Couchsurfing was actually good for was discovery. Everything else was kinda broken or slow. It added to the charm, but it definitely wasn't much better than what you're claiming here for Couchers.

[0] https://about.couchsurfing.com/about/jobs/rails.html

I would do this instead:

  type MyEnum = {
    active: 0;
    inactive: 1;
  }

  const MyEnum: MyEnum = {
    active: 0, 
    inactive: 1,
  }

  const showAge = MyEnum.active;
  const showPets = MyEnum.inactive;

It's slightly more duplication, but a lot more readable (imo) to those unfamiliar to utility types. TypeScript also enforces keeping them in sync.

Location: Norway

Remote: Hybrid or full remote

Willing to relocate: Probably not

Technologies: TypeScript, Python, Rust, Elm, Haskell.

Resume: [LinkedIn](https://www.linkedin.com/in/noah-h-1264371ab/), [Github](https://github.com/eeue56/), [main blog](https://thetechenabler.substack.com/)

Email: Message on LinkedIn

Developer who has a passion for helping the world and others, through technology (or sometimes no-tech). At my day job, I'm passionate about helping sure we build the right thing, in the right way, by people who are happy and engaged. In the open source world, I have my own programming language, Derw. Well, technically I have 5. But only Derw is intended for production. In volunteering, I'm the board leader of Tekna's Network for Developers - Norway's largest STEM union for those with post-grad education.

I generally am very flexible, I'm more interested in the problem being solved rather than the stack used to solve it. But no Java.

Nice! I did a similar project, more focused on creating an Elm architecture framework in TypeScript here[1]). I based it on implementing virtual-dom logic for both Elm codebases and Derw's renderer. Since it's a decent amount of code, I couldn't find a good way to represent it in a blog post, and ended up making a commit-by-commit example on Github instead. Since it's FP-focused, it doesn't support useEffect/useState like this post, but rather has an external subscription/message system instead.

It does support server-side-rendering, hydratation, and async events. It's a bit different in implementation in the OP's post, but I think the most important thing any reader should take away is that at the core, virtual-doms can be quite simple with plenty of room for further optimization.

[1] https://github.com/eeue56/make-your-own-tea/pull/1

When I taught web development at university, we made sure to focus on hireable skills. Back then, that involved making a website based on a Photoshop export. That proved to be very successful, and we hired a bunch of those students over the summer since they had skills we could actually use.

That said, I think a lot of theoretical practice tasks are good for stretching knowledge and skills, so they have value too.

I recently made a full web app using only AppsScript and Google Sheets as the database, and wrote about it here [0], and open sourced it here [1]. It was a novel experience, but I felt particularly compelled by the idea of having a data store than non-devs can easily interact with while having a web app in front of it that didn't require a server to be set up. But, AppsScript is too slow for this kinda thing to be a nice experience. Zerosheets looks nice, and I'll investigate it further if I look into this idea again!

- [0] https://thetechenabler.substack.com/i/142898781/making-a-sim...

- [1] https://github.com/eeue56/simple-link-aggregator

Interesting. In the Nordics, we have a couple of sites dedicated to fact checking news stories, done by real people. I think these kinds of automated tools can be helpful too, but needs to be tied to reliable sources. This became pretty apparent to me with the tech news coverage of xz, too. Lots of accidental (or sometimes intentional?) misinformation being spread in news articles. I wrote about it a bit[0], it was pretty sad to see big international publishers publishing an article based entirely on the journalist's misunderstandings of the situation. Facts and truth is important, especially as we see gen AI furthering the amount of legitimate looking content online that might not actually be true.

[0] https://open.substack.com/pub/thetechenabler/p/trust-in-brea...

I (kinda) solved this with neuro-lingo[0] with the concept of pinning. Basically, once you have a version of a function implementation that works, you can pin it and it won't be regenerated when it's "compiled". The alternative approach would be to have tests be the only code a developer writes, and then make LLMs generate code to match the implementation for those, running the tests to ensure it's valid.

- [0] https://github.com/eeue56/neuro-lingo

Location: Oslo, Norway

Remote: Yes

Technologies: TypeScript, Python, Derw, Elm, Haskell, Go. My full range of languages is quite a bit longer - but the jewel in my crown is Derw, a language I created myself having worked with Elm for a long time. I enjoy most languages to some extent, but prefer typed functional languages where possible. The only language I won't work with is Java.

Résumé/CV: https://www.linkedin.com/in/noah-h-1264371ab/ (email/message me for the full version)

Email: noah DOT hall AT hey DOT com

I'm looking mainly for roles where I can enable others to do better. I have two blogs which I maintain: https://derw.substack.com/ and https://aftenposten.substack.com/, where you can find interesting tidbits.

At university, my co-founders and I took over teaching a few modules. We were eager to find a larger pool of students that had useful skills for a company, rather than those versed in just theoretical knowledge and Java.

To provide the students with the skills they'd need in their career, we taught them how to use real world tooling: how to make a website from a design, how to use Git, how to write backend code, identifying security risks, how to use editors that weren't JEdit or Netbeans, how to use PhoneGap, how to deploy to a server, how to use Unix.

As a result of our training, we managed to get some great students on-board. No longer were we surrounded by students who could make some ServiceFactoryBean, but instead ones who were fully capable of making real things in a real company.

It's awesome to see that MIT has a similar programme - covering all the skills that we actually did teach. Too much of university is spent theorising and not spent making students employable.

If you're curious for a successor language that has better interop - along with fixing some of the problems that I saw a lot with Elm (former core team member), check out Derw: https://www.derw-lang.com/. The blog is updated frequently with whatever I'm working on, check out the latest post talking about what features are coming to Derw this year: https://derw.substack.com/p/things-coming-to-derw-feburary-2...

And to kick things off, here's a blog post on "Why Derw?": https://derw.substack.com/p/why-derw-an-elm-like-language-th...

Mine is Derw: https://www.derw-lang.com/

It's a programming language I created after frustration with TypeScript and Elm, in order to write better type-safe code in a functional manner. There's seemless interop between Derw and TS/JS, making it more useful for working with TS codebases than Elm. It's quite production ready though there are a few things left to implement, but so far there's features like:

- A formatter

- A test framework

- A benchmarking framework

- A web framework for writing apps

- VScode extensions

- Type checking

- Output generation for TS, JS, English, Derw and Elm

- A Gitbook: https://docs.derw-lang.com/

I also have a very active blog where I write about Derw or programming in general: https://derw.substack.com/ and the Twitter for staying up to date is https://twitter.com/derwlang

I've found my last 3 Thinkpads (T480, T490, T14) to all be excellent for Linux work. No real downsides, everything works as it should. If there was one thing that's let me down, it's that their webcams aren't great with occasional audio issues. My current driver though is a Flex 5i Chromebook, running ChromeOS and Linux via Crostini. Last time I had a Chromebook, I wiped it and ran straight Linux. But now Crostini is incredible, very easy to set up and seemless with ChromeOS. It runs my dev projects without problems, along with vscode and obsidian. Make sure that the device has at least 8gb of RAM though.

I have had a few outlets for where I'd share random ideas I came up with: used to have one on the Elm slack, and also various places in work channels. I found that sharing my ideas was always fun, then when I'd implement them, I could take feedback from others to lead me in a new direction. I particularly liked difficult ideas - things that others would consider impossible or at least very hard to solve. Bouncing ideas off of others is a great way to discover what problems _other_ people are facing.

I tend to put anything other there that I consider interesting for others to see, or something that I might want to share with others. For example - ways to to abuse a type system, or how to do something weird like embedding Elm within React. The truth is that if you put out a lot of code, very few people will see any of it, unless you intentionally and directly share with them. If you're applying for a job, chose your favourite repos and send them over. If you want to avoid any form of judgement, just put a disclaimer in the readme. When it comes to games - there will never be enough open source games out there. Being able to see how something done, however hacky, will be great for hobby game programmers.

I've been toying with adding a new generator to Derw (currently targets JS, TS, Elm, English and Derw itself for formatting) that would support Go-based output. It will probably be an experimental branch later this year. Go's performance and distribution makes it an appealing target to hopefully get a faster runtime (particularly interested in making the compiler faster once self-bootstrapping is finished)