msangi

Once I refactored some stringly typed C# code to use an enum with values Prod and Test instead of the two strings "Prod" and "Test".

I was relying on expressions like

  mode == "Test"

to fail to type-check to spot all the places that I needed to update.

Sadly some parts of the codebase weren't very idiomatic and had some

  "Test".Equals(mode)

This caused a bit of involuntary testing in production and thought me not to trust anything while refactoring.

Static analysis is very useful to identify unreachable code given that it can see all the code depending on it.

It doesn't help with potentially reachable but unused cpdepaths, which in my experience make up for the most of 'dead' code.

Think of the functionality in an application that nobody uses or of obsolete API version when all the clients use a more recent version.

Maintaining structure as the codebase grows is a challenge on it's own, especially when it's so big that you have multiple teams and way too many developers working on it.

At work we have a huge monolith and several smaller services. Working on the former it's never nice and my productivity is a fraction of what I can do when working on the smaller and saner projects.

I wouldn't always use a microseconds architecture. I think the best approach is to start with a modular monolith till it reaches a critical size.

I'd guess that's because it's designed for a fixed number of letters to a plate.

Monoscpace doesn't have spacing issues and possibly make the plates easier to recognize.

These are all good points.

Being on call thought me to design systems in a more resilient way.

I'm not there yet, but I really like Erlang's let it fail approach and the chaos monkey approach. Stuff will break. The more the system has been designed for it the better.

You forgot to tell us the reason why you voted leave

> As long as high paying jobs exist

Reading the news and from rumors, companies are planning to move away or at least to keep London on hold and instead hire people somewhere else.

Brexit is also weakening the pound, which means that is much easier for European companies to be competitive with London salaries.

I've been in London for almost 4 years and I've a very good position so I'll probably stick around for a while and see what happens. In the meantime, I'm having a look for better opportunities somewhere else.

The video isn't advertising this as a shell you'd use in production.

It's an interesting resource to learn how shells work and are implemented. It doesn't cover absolutely everything, but it was never meant too.

This is a neat idea.

I wonder if this can be extended to analyse unit test failures.

I'd guess one can get some interesting information from what tests fail more often. I'm thinking of being able to spot bad tests because they're too brittle or spotting bad code because it's too fragile.

Why not?

I think it's fair to assume that programmers starts the compilation either when they believe their code is correct or when they do want to get an "hint" from the compiler.

Either way, they get a valuable feedback from the compiler and that happens multiple times per day.

I like the idea of accessible code. It seems the next level after testable code.

Code with a lot of mockable dependencies is usually considered testable but sometimes it's a pain to setup.

Accessible code seems to fix this. Instead of taking dependencies, return some data so it's easy to check what your component does in isolation.

A REPL is better when prototyping but tests have a lot of value afterwards. They're repeatable and they can be used to spot regressions.

I think that the a good workflow is to do initial experiments on a REPL followed, once I get an idea of the code will look, by writing tests and the actual code that will run in production.

I feel that the focus on graphics has faded a bit in the most recent versions.

When I last gave it a try I had to manually generated the HTML document but without a (at least of of the box) syntax like jsx. If I recall correctly graphics is still there, but it's mainly used for games

It's interesting that he doesn't want to draw too much attention to actors while they are prominent in Chris Lattner's manifesto for Swift [1]

[1] https://gist.github.com/lattner/31ed37682ef1576b16bca1432ea9...

Does the panel produce the same amount of energy every season? I know that in most of Europe the production during summer months is way higher than during winter and that needs to be taken into account

It's also worth noting that a lot of quants have a pure maths/physics background rather than economics

Have a look at the author's blog and at the book repository on GitHub http://journal.stuffwithstuff.com/category/book/ https://github.com/munificent/game-programming-patterns

A common theme I find in posts criticizing Rust is that their authors take a problem they've already solved in another language, try to blindly convert it in non-idiomatic Rust and then complain because things get awkward.

I think that it's important to pick the right tool for the job and to follow the patterns of the tool you're using.

Is Rust the right tool for the task described in the post? Probably not, but it could still be used albeit it will always require more work than Python.

What's really missing is a resource showing common problems and their idiomatic solutions.

I switched from YNAB classic to http://plaintextaccounting.org/ and I'm satisfied.

If you like a command line based approach I'd recommend you to have a look.

I'm wondering how different languages implemented on top of this VM could be, especially at the semantic level.

Having different syntaxes on top of the same VM is nice and all the JVM languages show that there is room for a good variety and for different paradigms.

On the other hand, the choice of a VM sets some constraints while providing important features. Think for instance at the differences between the languages running on the JVM and the languages running on the BEAM (Erlang's VM).

I think there is a lot of untapped potential for innovative ideas at the VM-level but for some reason most of the effort goes into proposing new syntaxes that reuse the same concepts all the other languages are using.

This is a good point.

At least I find it encouraging that there are some of the newer languages that are taking errors from the past into account.

They're not going to be perfect and they surely have their own flaws, but that's something that someone will fix in a couple of decades once we will know what new ideas are actually good and bad.

Your second point is very important.

The architecture of a system depends on the load it's designed for. If you have (relatively) few users go for the easiest solution possible that work but make sure that all the components are decoupled enough that as soon as you grow and it cannot cope with the load you can throw it away and replace it with something that has adequate performance characteristics.

Greg Young did a great talk on this subject https://vimeo.com/108441214

It's not an explicit contract, but there must be an implicit one for stuff not to break

Why is this a limitation only of type-checked functions?

The problem is whether the function can or cannot handle the content of the new message and that's completely orthogonal

How does dynamic typing help if there is no contract between sender and receiver? Even in that case they​ must agree on the content of message.

Even if you insist in keeping the message untyped, with a static type system one could always convert (and possibly reject) messages as soon as they are received into a more precise type. That would keep the code that the compiler can't verify to the edges of the system.

http://joeduffyblog.com is great, albeit it's far from being daily. It has long posts about operating system and programming language design

I'm for writing idiomatic code and F# is a functional first language.

You can write object oriented code, but functional code looks so much better.

By the way, the strategy patter translates very well to functional programming. Just pass a function with the behaviour you want!

I have a three months old baby. She took away all the time to write code outside work but I feel like I'm still learning.

The trick is that when I feed her just before going to bed I always put on a conference talk or a video lecture.

This saves me from getting bored and I also found that the background talking makes her fall asleep more easily.

Absolutely! https://vimeo.com/108441214

That's indeed a very good advice.

All abstractions have a cost and no abstraction is better than the wrong abstraction.

I found this talk on the topic very interesting https://youtu.be/4anAwXYqLG8