matthewwarren

Yeah, I suspect the BBC had a very specific remit and they would've been in trouble if they'd got into too much competition with existing manufacturers/companies.

They are very much a publicly funded corporation, so everything they do has to fit with that.

> I'm buying my youngest step-child a Micro:bit for Christmas. Well, I say it's for him...

I think that I'll be doing something similar ;-)

Oh yeah, I'd forgotten about the RM machines, they were pretty cool as well!

Just noticed that the BBC have re-released some of their archive of 'BBC Micro' related TV programmes from the 1980's, see https://www.bbc.co.uk/iplayer/group/p031v2bg (probably UK only)

I knew that a lot of work went into MicroPython, but I didn't appreciate that is was all done by community volunteers. That's very impressive!

Hmm, I completely missed that, thanks for pointing it out (https://makecode.com/language#static-compilation-vs-a-dynami...)

I assumed that the PXT worked the same as MicroPython, but it seems like it actually compiles directly to machine code, nice!

> Most of my colleagues from the UK went through a similar curve, taking in Atari and Amiga machines at home not just as games machines but piqued by their capability to produce software of their own.

Yep, that's exactly my programming history!

> The UK 8-bit market was one of the biggest economic helpers the country has had in generations. We then went about squandering it.

Yeah, such a shame that happened. I wonder why?

There's seems to be a known bug related to this, see https://github.com/lancaster-university/microbit-dal/issues/....

Well, I was basing that on my own age!! (born in the early 80's, still just-about in my 30's).

But yes, I guess I should've extended it a bit :-)

For some background on the design decisions, here's the 'Key design constraints' from https://github.com/sparkslabs/microbit-prototype/tree/master... (the technical specs of the microbit prototype, written in Dec 2014) :

> Programmable - The device must be reprogrammable

> Simple to program - via a graphical browser based UI

> Small - maximum 5cm x 5cm

> Cheap - manufacture cost must be approximately £2 or less when produced in large scale - for example batches of 100,000 units

Well you can wire it up to eternal devices easily enough.

Also take a look at some of the ideas on this page, http://microbit.org/ideas/projects/.

(thanks for the info about 'littlebits', I'd not heard about that, taking a look now)

I'm not sure about that, of course it is limited compared to the Raspberry Pi.

But, have you ever watched a kid use one and within 5 mins be able to have their name scroll across the screen or make a simple Paper/Scissors/Stone game using the accelerometer? They get pretty excited about it!

Yeah I guess that's another way of achieving the same result. I'd think I would've preferred regular Customer Support to working in a factory!

Thanks for the info on Java generics, I always assumed that it 'erased' everything. I didn't appreciate that it would actually need to keep some info around, to make things work.

Yeah I've seen several 'Abusing C#' by him, but it turns out he'd not seen this particular example before, see https://twitter.com/matthewwarren/status/928326856687915008

Yeah that's a good point, CoreCLR only has the single/main AppDomain code and Rotor was only 'sort of' .NET 2.0, but with a different GC and JIT.

So without asking Don Syme himself we can only guess.

> I'm not sure if fullblown .Net CLR implementation was released yet

No and AFAIK they don't plan to. There's 'Reference Source' [0], but that's the Base class libraries only, not the CLR itself.

[0]: referencesource.microsoft.com

Well played ;-)

(I love a good pun!!)

Hmm, I would've thought that this would be easier for the Java compiler to handle, because it uses type erasure for generics. So in metadata, everything is just 'Object' rather than exact types, but I'm no Java expert, so I could be wrong?

Hmm, that's a really good question.

I did a quick search in AppDomain.cpp [0] for 'generic' and there's quite a few comments/variables that mention it. Maybe this [1] is one of the tricky interactions?

[0]: https://github.com/dotnet/coreclr/blob/master/src/vm/appdoma... [1]: https://github.com/dotnet/coreclr/blob/master/src/vm/appdoma...

Thanks for the link. I thought I'd read all the Eric Lippert articles related to my post, but I missed this one

Yeah, that sums up the problem!

> Indeed, especially considering how bad the exponential fit is for working set, it is pretty evident that it is not just growing exponentially, but faster than that.

Yeah I suck at maths, according to this comment https://lobste.rs/s/j4545s/dos_attack_against_c_compiler#c_n..., it's actually 'double exponential'

> When it really is not obvious at all what is going on.

Yeah, I guess I actually meant to say 'it's very obvious that it's increasing quickly', but as you say, it doesn't read like that!!

Yeah, I guess I should've added 'So if it takes 3 mins to compile your code .. in the C# compiler'

But either way, I'm glad you enjoyed it.

> As someone who used to spend a lot of time in C++ and LTCG I got a good laugh out of this(aside from the crashing part, ICE are always a bad thing). Our release link was ~40 minutes on each change.

A long time ago I did some C++, so I know it can take longer, although I don't think I ever worked on something with 40 min build times!

Thanks so much for your replies, very informative.

r.e. 'JIT v Interpreted', I should've checked wikipedia, it backs up what you're saying:

> Most often this consists of translation to machine code, which is then executed directly, but can also refer to translation to another format

From https://en.wikipedia.org/wiki/Just-in-time_compilation

Firstly, thanks for writing it!

Here's my questions (assuming you can remember from 6+ years ago):

1) What was the hardest part of .NET to understand and/or implement?

2) Were there any surprising things about the .NET runtime/specification that you learnt about along the way?

3) Should JIT.c really be called Interpreter.c :-)

(Genuine Question) Is an article only considered good if it generates a large discussion?

What about if people read it, found it thought provoking, but didn't have anything to add, to discuss?

> Had I read an article opening with the sentence: «Here is a .NET runtime alternative which is however 100 times slower…», I would have quickly dismissed it

I deliberately didn't start with Benchmarks, pretty much for that reason! Plus I put a huge caveat in before I showed the results.

> This article is right, the DotNetAnywhere code really seems a gem, well worth to study!

Glad you think so as well, that's exactly the reason that I wrote about it. It's relatively unknown and if nothing else it's a really useful resource (whether it's suitable for production is another matter)

Yeah, the GC code is certainly not optimal (in terms of memory usage), but I don't know if that means you can't trust it.

At least in the simple tests I did it behaved as expected, but I know that testing a GC for correctness is not a simple task!!

> The memory issues with DNA are frighting.

Which memory issues do you mean? The items that are covered in this section http://mattwarren.org/2017/10/19/DotNetAnywhere-an-Alternati... ('Garbage Collector') or something else?

LOL, yeah I completely missed that one!!

I've just updated the post, 'log4net' makes in into the top 10 now.