msangi

This is a valid point, but now you have two ways of representing a square and you need the coversion functions.

It's better than nothing as you can guarantee that an instance of Square is a square, but you still need to handle squares disguised as Rectangle.

You could throw in dependent types and force rectangles to have different width and height, but that doesn't really help in getting nicer API.

If I had to do something like this in a real program I would take these issues as a sign that I need to step back and re-evaluate my design. I'd look at what I want to use these types for and try to come up with the best approach for that specific case.

This is interesting.

I find that inheritance as a code reuse tool pushes developers in the direction of taking whatever class they have and tuck some new properties to a subclass.

On the other hand, if you realise that a square is a rectangle with the same width and height, why should you bother at all with creating a new class? A new constructor (or an helper function) should be all you need

http://craftinginterpreters.com/ part 2 (still a work in progress) will show you how to write a VM and compile a language to its bytecode.

It won't be the JVM but it could be a good start

That's great. I implement part 1 in Rust and I'll do the same for the second part

The second part (not finished yet) shows you how to build a VM and compile Lox (the toy language used in the book) too run on it.

They are great. Currently the 'A compiler from scratch' episode is free to watch in case you want to have a preview

I cannot believe you're serious with that condesending example.

Putting people from Cambridge and Oxford on the pedestal is yet another example of what's wrong with Britain.

This also shows in the way they work: people from Europe get the work done and move on to the next task. People from Cambridge and Oxford try hard to be smart and come up with solutions so complex that, when they work at all, have the net effect of slowing everyone down.

Note that he is using Hyper, which is a low level library. The article mentions [Rocket](https://rocket.rs/guide/getting-started/), which has higher level API.

Note that it's still going to require extensions

This is a good point, but on the other hand it's sad too see that 0.18 has been abandoned and there are pull request that would fix bugs being ignored.

I don't mind that 0.19 is taking long time to be released, what bothers me is that there are no bugfix release for 0.18

I think that the main problem with Elm is that Evan wants to design the perfect system.

This is of course a laudable goal but I think that clashes with the complexity of the real world.

A consequence of this is that if you want to do something Evan spent time designing a solution for you're going to have an awesome experience, he is a great designer, but on the other hand as soon as you try to do something different you're out of luck.

This has the nice effect that what's there is really nice but there is no middle ground and you either get something that is well deisigned and extremely polished or nothing at all.

I am a happy syncthing user too.

I use Restic https://github.com/restic/restic to cover the encrypted backup use case

Don't forget about hedge funds. Judging from the messages I get from recruiters there are plenty of them.

Their offer total compensations significantly above 100k£

I've played with Elm a while ago and it's been a very nice experience.

I wouldn't use it for any frontend work just because I believe that it's possible to avoid single page apps if possible, but if I had to write a SPA I'd reach for Elm.

The only thing that makes me worried is that Elm 0.18 has been out for quite a while now and most of the development has been carried on behind the scenes by Evan.

This is good because it gives the time to the language to evolve in a coherent way instead of being a collection of bolted on features, but it also means that for outsiders is a bit hard to track progress in the language

Probably https://www.teamblind.com/

Have a look at Patchwork, which runs over the decentralised Scuttlebot https://github.com/ssbc/patchwork

Thanks for the advice, following people made it much more interesting.

I also started to appreciate what's the price for decentralization: after following just a couple of users I already have several hundreds megabytes downloaded.

This is an extremely interesting project, but when I logged in I found it difficult to find someone to interact with.

It might be that I joined a pub with very little traffic, I haven't spent much time on it and I plan to have another look when I have some free time.

You might like http://www.includeos.org/

Wouldn't you need backwards compatibility anyway to avoid the need of upgrading all the services at the same time?

Is the video available?

And the dynamically loaded code could use a UsedImplicitly annotation

Wait, I thought that Uncle Bob said that programmers should just be 'professional' and stop being sloppy instead of reaching for tools that can help them

http://blog.cleancoder.com/uncle-bob/2017/10/04/CodeIsNotThe...

In my opinion it's been a while that his articles have been rather bad

What really makes the difference in terms of maintainability is how easy is to run the tests and how much they're automated.

What's important is to have test coverage and to keep exercising it when the code changes.

The best way to achieve this depends case by case. Sometimes unit tests are better, sometimes integration test is the way to go.

I think that, as it already happens today, different classes of problems are going to be solved with different techniques.

Do you have a clear specification and expect exact results? "Software 1.0" is the best choice.

Do you have problems that are computationally intractable, or simply a huge amount of data and you can accept an approximate solution? This is where "Software 2.0" makes sense. It's already being used and it will keep expanding.

The factors that will determine the ration between "Software 1.0" and "Software 2.0" will likely be: * how much we will be willing to accept approximate solutions * how easy it will be to collect the training data and to train a neural network.

I can totally imagine an hybrid model where there is going to be a lot of "Software 1.0" with some black boxes trained using machine learning techniques.

I'm not very convinced we will have many 100% "Software 1.0" applications. That works well for some specific problems (like AlphaGo Zero mentioned in the article) but many other domains don't map that well to a machine learning problem.

I would find "under 10 minutes" to be a quite annoying amount of time, especially if I'm paying for them the premium rate that some customer services have.

The impact of using Jenkins should be easy to measure with metrics like "number of new version of the application released per week", "time it takes a commit to get released" or even "number of rollbacks caused by a buggy version".

With a continuous delivery pipeline setup you'll release often and the new version will work. And that's great from the business point of view.

This reminds me of pixel spirit: a tarot cards deck with beautiful pictures made from shaders.

https://github.com/patriciogonzalezvivo/PixelSpiritDeck/blob...