Other Boards - Unsupported?

tage, I agree that they should be included, but the rest is just egotistical. I've plenty of friends who can't solder but write awesome software and want to play with this stuff (and have made some really cool projects without soldering).

..the reason why I don't think it is a good idea to sell the board with pin headers soldered is that the pin headers take up a lot of space, especially when they are used. that is, wires with connectors are plugged in. many users would buy the board because is is very compact. but the connectors would really make it difficult to fit the board into a small space, compared to if you just solder the wires into holes. and soldered connections are a lot more reliable than pin headers and matching connectors. so I would definitely sell the board with pin headers but not soldered. it can be difficult to remove pin headers that are soldered.

ummkay

I think I really just have to give people the option... While I think pretty much everyone is capable of soldering the connectors, it still puts a lot of people off getting started - especially if they haven't done anything like it before.

I'd prefer to just supply a bare board too - but given Espruino is all about how easy it is to get started, I think it makes a lot of sense to have one version with pins.

@Gordon,

first of all, I'd like to commend you - as simple as that. You stepped into this endeavor with the right motives, and you show an incredible spirit, creativity, dedication, perseverance - and last but not least - awesome productivity.

With most products the question is how to balance engineering and marketing. Both cost, latter opens the wallet, and - or but - first one keeps it open (after discovering that it was not just a marketing bluff and a good sales pitch). Too much engineering (time) upfront makes the money (ROI) come (back) in too late... or too little or never at all, because by the time the product hits the market, the requirements/demands have already changed (...that's why 'agile methodology' came to be to help with this dilemma - especially in the domain of software development - it helps to be shippable at any time, ...on and with every increment in business value.)

You may not have promoted Espruino with the term 'agile product development', but you live it - include it in your new home page ;-)... All of us Espruino users experience agile through Espruino's evolution of firmware and (Web) development environment. JavaScript is inherently and thus exceptionally well suited for the agile approach. The built-in, straight forward and simple extensibility is architected into its implementation of its object-orientation and runtime engine (VM). I could imagine that those aspects were crucial reasons enticing you to call Espruino into live.

The next paragraphs belong more into the topic 'About JavaScript'. I like to pick them up in this context, because for me they are part of the overall, high-level architecture of the Espruino product as a whole - and its mission to make it easily accessible to a broad community. Part of this 'easily' is guaranteed with feature rich Espruino board working righ out-of-box: plug in and use - with no hick-up(s). The (Web) development environment shows even a ready to example in the editor. Therefore, I'd better had said: just plug and play! - See yourself what got me hooked and started at http://forum.espruino.com/conversations/1781/: Running LED lights - with the three (3) on-board LEDs - controlled by three (3) buttons... oops: only one user button on the board though... ;-) Therefore: buy the original Espruino board! None of the few saved $, £, ¥, or what ever currency you prefer - may be esteemed and stable CHFs - bring you back the time you lost tinkering with this 'other' board and most likely made you gave up on it, or even worse, giving up on the technology all together,... and missing out for the rest of your life... (...what a big mouth full). Generally, I'm a 'cheap' guy - or more nicely: I like frugality - overcome with creativity - hence the software buttons ;-) - but I have no regrets what so ever having bought into the very solid engineered Espruino board. - This much for: 'Why to buy the genuine Espruino board'.

//////////////////////

As a language and implementation, JavaScript follows more Smalltalk's than Java's model: In JavaScript - as well as in Smalltalk - the prototypes or classes - respectively - can be (incrementally) extended at practically no cost, where as with Java either a subclass or a modified/extended clone has to created. JavaScript goes even further than Smalltalk: in JavaScript one can extend just one or selected particular instance(s) versus all. Agreed, with Java requiring subclasses for extensions, future coexistence/integration is much less a source for (name) conflicts. The limits of extending classes (by adding methods to the existing class) and subclassing has anyway to be overcome with composition... and even there, JavaScript has its advantages. Btw, for how to apply the class hierarchy pattern of class-based object orientation to prototype/object-based JavaScript, please take a look at http://dojotoolkit.org - in particular at http://dojotoolkit.org/documentation/tutorials/1.7/declare/. The tutorial provides a very nice, concise explanation of how prototypical/object-based object-orientation's binding happens. It helps to grasp the very dynamic oo nature of JavaScript:

It is important to have a clear understanding of prototypical inheritance. When a property is read from an object instance, the instance itself is first inspected to see if the property is defined on it. If not, the prototype chain is traversed and the value from the first object in the chain that has the property defined is returned. When a value is assigned to a property it is always on the object instance, never the prototype. The result of this is that all objects that share a common prototype will return the same value for a property defined on the prototype, unless the value has been set on the instance. This makes it easy to define default values for primitive data types (number, string, boolean) in your class declaration and update them on instance objects as needed. However, if you assign object values (Object, Array) to a property on the prototype, every instance will manipulate the same shared value. (from: Classy dojo, dojotoolkit.org)

I'd like to see something like declare natively implemented in Espruino's runtime. It hides the somewhat cumbersome, JavaScript native Xyz.prototype.abc = ... syntax and much more, such as invoking the super classe's method (which means even more reuse, more extension with less code writing - a nice feature in a memory constrained setup). The availability and use of 'declare' fosters the thinking in classes rather than a collection of functions pinned to a (pseudo) object, as seen a lot in Java with static methods of a Java class - or simply - a function library, where the subject - in this case the this-object, has to be passed as well in order to work (oo). On the other hand, it cannot be that bad. Java 8 finally learns what JavaScript was already born with: Lambda expression - functions / methods as parameters. Never too late to learn something new and become smarter... that's though true for JavaScript as well... ;) ...will see what ECMA is coming up with in the times to come.

Have a great Espruino time! - until next time - allObjects

Thanks! :)

About declare: Presumably it could be implemented inside a module for now... The problem I have is it's hard enough to cram JavaScript into such a small device, let alone other libraries too. If something like it becomes part of a later ES standard, I could definitely look at that though.