Main Site Documentation

I LOVE TinyCLR


#1

I just had to say that! I really LOVE it … the guys won’t let me say more!!


#2

Well you are the BOSS, so do tell more! Or t ell us when you will spill the beans.


#3

Agreed! You really haven’t given us anything to get excited about yet. Don’t delay any further!!!


#4

I love that I am realigning all my code to get one code base to produce full framework apps, RPi apps, or G120 apps. I just wish I could use generics in my driver implementations, but one can suffice for now…


#5

I love generics - they can enable faster development, and clearer, reusable and maintainable code. But generics are syntactic sugar that have a non-trivial cost to the size of the firmware (more opcodes, more complex opcodes, bigger and more complex type and introspection firmware). Generics can also have a negative impact on heap size, heap fragmentation, and program size, depending on how you use them.

So, as much as I would love to have generics, they pay off at compose-time by shifting some costs to compile-time and run-time. So, you benefit once with quicker/easier coding, but then pay the cost every time you run.

NETMF has always been about trading memory and cycles for easier programming. Your code runs perhaps 100x slower, and with a 2x or larger total footprint in exchange for a quicker development cycle. You can pay that off by buying larger chips for the task than you might have for an equivalent native-code implementation (again, benefit once, pay for every copy). Even given NETMF’s role as a development lubricant, the addition of generics to M4-class chip sets seems to me to be on the wrong side of the diminishing returns curve.

[fwiw, in my opinion, async/await is also in this class - it’s just compiler tricks to do stuff you can already do]


#6

@ mcalsyn - I agree completely with the async/await compiler generated state machine for trivial stuff. But the TPL API on the other hand is still valuable in the micro space.


#7

@ eddie_garmon - Agreed. I am also prepared to be pleasantly surprised if someone produces a suitably slim generics implementation so that the benefit-in-coding exceed the cost-at-runtime.


#8

Maybe there will be TinyPLINQ too?

(Because it is fun to say TinyPLINQ)


#9

Generics have all those negative runtime impacts specifically because they [em]aren’t[/em] simply syntactic sugar. Java’s generics are syntactic sugar, simple compile-time type erasure, but .NET’s generics definitely aren’t.


#10

@ godefroi - True, but I have not heard when the G30 will be running Java.

[Edit: In other words, you have made a completely true statement, but one that is irrelevant to the discussion about the content of TinyCLR]


#11

@ mcalsyn - You said that generics are syntactic sugar. If .NET generics were syntactic sugar, they’d be in NETMF already. They’re not syntactic sugar, so don’t expect them in NETMF (or TinyCLR) unless something changes very significantly.

If you want to run Java on your G30, then IS2T can probably help you with that: http://www.microej.com/


#12

@ godefroi - Well, setting aside pedantry over the ‘sugar’ term, they don’t enable something you can’t otherwise do. They do enable arguably better coding patterns. How they compare to Java under the covers still strikes me as pretty irrelevant.

And that’s an interesting link, but I get through my day pretty comfortably without Java. If it ever comes around as the best tool for the job, I’ll circle back to that site.


#13

@ mcalsyn - I really didn’t want to derail this discussion with an argument, but if you don’t understand the differences between generics as implemented by .NET and type erasure as implemented by Java, then you probably should look into it, and you’ll then understand why I say that I believe generics are NOT coming to NETMF in its current form.

To say that generics don’t enable you to do something you couldn’t otherwise do is misleading; nothing about any turing-complete language enables you to anything you can’t do in any other turing-complete language. That definitely doesn’t mean that generics aren’t a highly desirable feature.


#14

like a dog with a bone…


#15

@ mcalsyn - I’ve drug you down to my level, now I’ll beat you with experience.


#16

@ Gus, hurry up and let us know what it is already. We’re descending into madness over here.


#17

@ Gus - Na. Take your time. I’m looking forward to a cage match.


#18

@ ianlee74 - yep :wink:


#19

lol, but just remember that virtual instances for the following dev environments are currently being prepped:




and seriously, if it isn’t open source, no matter how much I love C#/ / .Net, these will be the options…


#20

While I completely agree with you and express my frustration at GHI’s decision to go closed source at every turn, I’m totally lost at how this reply has anything to do with anything that was said before it :think: