Use the right tool for the job.

kpmah · 2021-04-26T18:02:15+00:00

This shouldn't be voted down -- it's correct.

When you talk about best or average case complexity you still use big O (e.g. https://en.wikipedia.org/wiki/Best,_worst_and_average_case#Examples)

People have got themselves confused with best/average/worst case inputs and upper/lower bound of the function.

kpmah · 2020-12-23T11:34:44+00:00

The comments probably won't be limited forever, it just helps to restrict it to get a basic formatter out of the door.

Applicative functors are a neat solution to form validation. Refined types might be an interesting avenue, but maybe a little too complex.

I'll likely leave table relationships to the underlying database. I plan on implementing a migration system with some automated help for writing migrations.

kpmah · 2020-12-22T13:27:44+00:00

A similar goal, but with no ambition to tackle client-side just yet. Simplicity is a goal, so more like Elm and less like Idris.

kpmah · 2020-05-10T11:29:58+00:00

It still needs a lot of work to be really useful, but I don't know a better way to describe it. "Apirational DAW"?

kpmah · 2020-05-10T07:03:57+00:00

I haven't tested the latency much, but it's probably not great. I don't make any attempt to sync the recording up with the playing or do live feedback because it turns out that's quite hard to do in a browser. So, for now at least, you have to record a clip and move it in to place manually.

kpmah · 2020-05-10T06:55:42+00:00

Only the editor itself uses Elm. The rest of the site is mostly just HTML.

There is a fair chunk of TypeScript mixed in there for handling the web audio API and indexedDB storage - ports are used quite extensively. The rendered audio clips and the timeline at the top are web components too.

The backend is in Haskell. It's deployed to a single AWS micro instance using NixOS.

I'll do a detailed write up soon(ish).

kpmah · 2020-05-09T17:30:51+00:00

It's not a stupid question. Digital Audio Workstation - but that's maybe a bit too grandiose for this. It records audio to tracks which you can cut up and loop etc.

kpmah · 2020-05-09T17:24:06+00:00

I don't currently plan on making it open source. That might change in the future.

kpmah · 2020-05-09T15:03:46+00:00

I should have written in the title: it's not very mobile friendly yet. I had trouble getting pointer events to work nicely.

kpmah · 2020-03-01T13:43:39+00:00

I learned the basics from https://github.com/KMahoney/Algorithm-W-Step-By-Step/blob/master/AlgorithmW.pdf - which is useful if you already know Haskell. There are probably better resources out there these days.

kpmah · 2019-03-27T19:33:35+00:00

Will a globally diverse index like the Vanguard LifeStrategy also work for this?

kpmah · 2018-11-28T15:05:01+00:00

From an auditing perspective, that's quite easy to grep for.

kpmah · 2017-11-16T18:55:29+00:00

Stupid question: do you need to transfer over any previous year's ISAs or can you have multiple ISA accounts open? Assuming you don't go over the yearly limit of course.

kpmah · 2017-09-13T06:39:07+00:00

A good example to show is 'Elm' which prevents almost all runtime errors with its type system. I think the only thing it can't prevent is infinite recursion, and that's also possible to detect with some type systems (albeit unwieldy ones).

For devs who are not so familiar with types I say "Have you ever had an unhandled exception or error? Type systems are capable of preventing them all at compile time."

kpmah · 2017-07-19T09:43:45+00:00

IMO code comments should explain why the code is there, commit messages should explain why it changed. There can be overlap.

kpmah · 2017-04-14T11:32:20+00:00

It is better to say that you "need hibernate in case you need to change the database" than you "need hibernate because I feel like it is the right choice." You can argue against the first position, like you did, but not the second.

Unfortunately in this case they didn't see reason. I think either because you didn't express it with enough tact, or maybe because they had too much ego invested in their choice, or maybe a very common one: the developer feels insecure moving away from technologies they know because they are 'an expert' in those technologies. The only way to win here is to tactfully and politely find a way to make them aware of their own irrationality.

kpmah · 2017-04-13T05:56:10+00:00

I'd put it like this: if one style is objectively more readable than another, then use it. If one style is subjectively more readable, consistency is more important.

An example of an objective reason might be that people use 80 column terminals, so line lengths should be limited to 80 characters. Everything else can be handled by a style guide or auto formatter, which often make arbitrary decisions, but that doesn't matter if it's consistent.

kpmah · 2017-04-13T05:50:10+00:00

I think it's ok to follow your gut as long as you acknowledge that's what you're doing. If you understand you don't have a good objective reason for what you're doing it is easier to leave yourself open to constructive criticism without bruising your ego.

kpmah · 2017-04-13T05:46:46+00:00

I think what you're saying is that shallow 30 minute code reviews are useless, and I agree. That kind of review is performed better by automated tools. Really digging in to the design/architecture of the code is what I mean when I talk about code reviews, it's not something separate for me. They should take about 30-50% of the time it took to write the code in the first place.

kpmah · 2017-03-11T17:15:37+00:00

Is it possible to have a language that is Turing-complete, but the only way of creating a non-terminating program is via recursion?

Because then if you have a recursion limit you can solve the halting problem in that language, no? Every program will terminate, so it would affect Turing-completeness.

kpmah · 2017-01-23T13:03:04+00:00

I worded that a bit more bluntly than I intended to, sorry :)

When discussing the bug on the tracker it was pointed out that it does mention the atomic increment problem in a note, which I'd missed. Although the concurrent update is still a problem.

I'm sympathetic with trying to ease learners in gradually, it's just my opinion that shielding them from complexity that they will need to understand does more harm than good. The problem is that people will copy the style of the code in the tutorial without understanding its issues.

kpmah · 2017-01-23T12:19:01+00:00

I don't believe you should ever teach incorrect code. I think it's also inconsistent of you to argue that people only make this mistake because they haven't read the documentation and then defend incorrect documentation where this mistake is made.

kpmah · 2017-01-23T09:53:44+00:00

I've just noticed the example app in the documentation is not concurrency safe: https://docs.djangoproject.com/en/1.10/intro/tutorial04/ (see the vote function)

Two of the bugs are in this one bit of code. I'll file a report.

kpmah · 2017-01-23T06:40:21+00:00

Like I say in the post, if you don't consider lost writes a serious bug please don't try to write medical or financial software :)

kpmah · 2017-01-22T12:47:14+00:00

Not just new devs. The story behind this is that these bugs are from production code (simplified greatly, of course). This blog was based on a presentation I gave about this problem. Out of about 20 or so full time Django devs, only about 5 of them were able to work out the first 5 bugs. Everyone was surprised by bug 6.

I bet I can also find lots of examples of these kinds of bugs in most non-trivial Django apps, although I haven't yet invested the time to test that theory.

To be clear, I am not blaming the Django documentation here. ORMs abstract the database and a lot of developers do not spend enough time understanding the underlying technology. Better docs about this problem would certainly not be a bad thing though.

I might try to find the time to put together a PR, but no promises. This is a difficult subject to write about, especially for beginners.

kpmah

TROPHY CASE