ollysb

This makes sense in countries where education is publicly funded, it's there to broaden the knowledge and culture of the population. If you're having to take a huge loan to do it then you start having to do a ROI calculation.

What a breath of fresh air, the old docs really were showing their age.

Interested to see how this plays out. Given the level of mimicry that AI can now achieve how do actors, musicians and artists safeguard the likeness, sound or style that they've developed?

For that matter it would be nice to expand any function call in place. That way you could view a full call stack in a single view.

In many countries the official Libre app now supports bluetooth continuous updates on Libre 2 and 3. That said I do much prefer xdrip4ios.

Anecdotal of course but this isn't my experience at all, I don't know of any current or ex-colleagues that are working in offices at all. I think in southern Europe it's common to have more onsite.

The incentives are to get the code out the door then improve things later, if it's worth it. There's a lot of risk in product development, it iften doesn't make sense to craft the perfect software when there's a chance that it won't see the adoption that was hoped for.

Gardening leave is usually for positions where the employee holds competitive information on active deals etc. During the gardening leave they're under NDA which allows for their competitive information to go stale before starting at a new company.

Doing it with `with` is definitely the community standard. There are attempts like https://github.com/vic/ok_jose to make it more like "do" notation.

Keathley did a good job discussing this in https://keathley.io/blog/good-and-bad-elixir.html#:~:text=Av.... The preferred style is to specify the errors in separate functions e.g.

    def main do
      with {:ok, response} <- call_service(data),
           {:ok, decoded}  <- decode(response),
           {:ok, result}   <- store_in_db(decoded) do
        :ok
      end
    end

where call_service, decode and store_in_db return the specific errors like {:error, :bad_request}, {:error, :conflict}.

It makes sense in principle. I wonder if the incentives work though, usually the people that suffer from the bad prep aren't the same people that are responsible for prepping the meeting. It could perhaps work though if people were free to decline meetings which hadn't been prepped, that way if you wanted people to attend you'd have to do the legwork to make it worth their time.

If they'd had slick WordPress templates they probably would have used them too.

Everyone has their moments no? In person Richard seemed like a super nice guy and the many lectures he did for Elm really showed a passion for helping improve the day to day experience for developers. He was also super active on the forums and slack helping people out.

ChatGPT is a great UI to both though

Amsterdam has 3.5 times the number of bikes vs cars. An outlier for sure but evidence at least that it's an alternative people can be happy with.

You'd use a switch over the ADT and extract the values as appropriate. This is method dispatch vs function dispatch. In practice you can do the same things with either, but they reflect the focus on behaviour (OO) vs data (FP).

This is definitely an FP vs OO thing. If you wanted to refer to the value in an ADT you'd introduce a new type to refer to it, which in Elm would be:

    type Message 
        = IncrementBy Amount
        | DecrementBy Amount
        | Set Amount

    type Amount = Amount Int

Obviously this is a contrived example - you wouldn't bother if you were dealing with an Int but once the message gets more complicated it can make sense.

I'm more than happy with either of those variations. My favourite though would be Elm's syntax ;)

    type Message 
        = IncrementBy Int
        | DecrementBy Int
        | Set Int

That syntax does look a lot nicer and makes sense if you're going to do OO anyway. I do wonder if it's trying to shoe horn OO into functional clothing but seems practical nonetheless. Primary constructors would definitely be a welcome change.

Wow this looks great. One to watch for the future.

I've been working with Elixir and Elm the last few years but recently have been working on a mobile app in Flutter. While the recent changes are a good step in the right direction (being able to express ADTs and records) it does feel like an iteration away from being ergonomic.

Regarding sealed types, I'm not really sure why you'd choose these over type unions, in practice they're often used to describe things like events for reducers and using sealed is incredibly verbose compared to the equivalent in for instance typescript.

    type Message = 
        | { type: 'IncrementBy', value: number }
        | { type: 'DecrementBy', value: number }
        | { type: 'Set', value: number };

vs

    sealed class Message {}

    class IncrementBy extends Message {
      final int value;
      IncrementBy(this.value);
    }

    class DecrementBy extends Message {
      final int value;
      DecrementBy(this.value);
    }

    class Set extends Message {
      final int value;
      Set(this.value);
    }

In a real app this noise really adds up making it difficult to get an overview of the types.

Record types are nearly there, but currently there isn't a way to update the records which really hobbles them in day to day use (it looks there will be record spreading coming though so this is hopefully temporary).

This my experience on an iphone 12. The UX doesn't really work for me yet but I absolutely love the concept, will keep an eye on it (would sign up for a mailist if you have one).

Elixir doesn't currently have a type system built into the compiler. There is a separate package Dialyzer which does type checking but it would be fair to characterise it as a bolt-on rather than part of the core tooling. Work is now underway[1] to create a type system based on "set-theoretic types" though this is still considered experimental and may never be added to Elixir.

[1] https://elixir-lang.org/blog/2022/10/05/my-future-with-elixi...

You can use opaque types to encode constraints that the type system isn't able to express. That way you can have factory functions that apply any logic that's required before allowing construction of the opaque type. Now whenever that opaque type is referred to there's a guarantee that the data it contains satisfies your desired constraint.

Started exploring machine learning in Python 6 months ago. Despite all the resources for learning Pandas I couldn't ever get to a point where it seemed coherent. It felt like a grab bag of tricks that accomplished various different jobs. Polars on the other hand felt really consistent and logical. Instead of having to google how to do so something in Pandas I could generally just figure out how to do it by combining the the simpler operations that Polars provides.

I wonder if they're displacing other sugars with Honey. Speaking as a diabetic I find it very hard to believe that a spoonful of Honey in the morning is going to improve my day :)

https://www.roc-lang.org/ looks very interesting, it's from Richard Feldman who's done a ton to promote Elm over the years and also happens to work at NoRedInk.

You can use XGBoost for both classification and regression. See https://xgboost.readthedocs.io/en/stable/python/python_api.h...

Darts gives you a lot of options, including newer deep learning approaches like NBEATS and NHiTS.

https://unit8co.github.io/darts/

Wow, this makes a huge difference, to the point where I can type without even looking at the keyboard (tried with and without looking).