• Ic. I'm living VMs/interpreters since the end of 70'... so I do not think per se that faster is better... becuase what does it help to get the execution faster but it is so difficult to get there hat the point of execution is never reached, but it could help to solve some of the issues we noticed in the past, such as making sense out of 'noise' of a 315/433MHz cheapo receiver.

    Regarding speed: The business term TCO - Total Cost of Ownership - has been created to be clear that making one thing cheap (or fast, in regard to our discussion) is not making the cut. That's why I used to explain TtM - Time to Market - is relevant when talking about creating software at the time where (Window 3.1 / OS/2 2.0) GUIs needed the (C/C++) programming of low level message handling for just everything that can happen to any (square) area on the screen... and Smalltalk was handling it just like that, but was (in the beginning until availability of JIT to platform code) not as fast as C/C++ doing it. Similar interpretative systems were available on mainframes, where still only execution speed was measured but time to market was not taken into account. With hardware getting cheaper and cheaper - still expensive at that time - development cost for the application became the more challenging point.

    I notice in you thoughts a similar pattern but going in a different direction: what's the point of speed when the battery - or whatever power source is available / affordable - is drained befor the POST - Power On Self Test - completed, and the actual code is never even reached. With the IoTs going that direction that even my glasses should tell me - or my networked nearfield servers in the rooms and on my body - where I've misplaced them, and still should be very light weight... should they?

    Looking forward to things hatching in your space. Have a great weekend!

About

Avatar for allObjects @allObjects started