In particular, we should keep in mind the goals of lowering the floor (making it easier for beginners to get started) and raising the ceiling (increasing the flexibility and capabilities of the platform).

Yes, I LIKE that - especially the "lowering the floor" - good for us "slow learners" in programming. Ya'll folks who seem to "talk hex & binary" amaze me with the knowledge of inter workings of code stuff.

This Arduino stuff is really great - so ya'll just keep up the GREAT work.

Ya'll folks who seem to "talk hex & binary" amaze me with the knowledge of inter workings of code stuff.

Computers are the most complex machines mankind has ever created. With that said, at their core, they really are nothing more than very fast player pianos with really long song reels.

Code is nothing more than an abstraction of those holes in the song reel (addresses and data bytes) to something more "human readable". All a compiler does (this is a simplification, of course) is take those human readable bits, and translates them into a series of binary representations which are, at heart, on-off switches connected via a very complex arrangement of NAND/NOR gates (because any and all logic may be represented by combinations of such) that describe a virtual wiring network, one which can change from one state (or machine/cpu cycle) to the next.

One place where it gets really fun is microcode - this is code used internally by the processor, programmed at the factory; an abstraction on an abstraction, if you will.

<tangent ahead>

Wanna know the crazy thing? We could've had calculating machines (not necessarily computers as we know them; it would take the abstraction theory work of Church and Turing to make the mental shift away from calculation to that of general purpose symbol manipulation a reality, something which wasn't really being thought about in Babbage's time, though I bet a real system like his would have spurred it, much as it did for both Church and Turing in the 1940's) nearly one hundred years prior to when we did have them, had Babbage chose to use relays (and binary logic) instead of gears (and decimal notation, which was more suitable to mechanical implementation). Don't get me wrong, Babbage's machine could've brought us a great leap forward had there been the financial backing for it (among other reasons); it was certainly a Turing complete device. However, Babbage would've had an easier time implementing his ideas had he used Boole's binary notation and logic system (something Babbage would've had knowledge of; he did hold the Lucasian chair for a while, after all), along with relay logic. The relays existed, the power sources also existed (batteries, at a minimum). Space would've been an issue, but the Engines he designed were already behemoths, had they been built. The relays could've been miniaturized as well. I can speculate why he didn't do it; it would seem most likely the thought never occured to him (calculation with electricity would have to wait for Herman Hollerith and the 1890 US census, which ultimately begat IBM), or if it had, he couldn't see how the size of a relay could be made smaller (though that would seem unlikely), or that relays were very unreliable at the time (a possibility - most relay-like devices were used for telegraph usage as sounders; it wasn't until the latter half of the 1800's that relays were used for switching and other purposes, especially with the advent of multiplexed telegraphy, stock tickers, alarms, and telephones).

Most of the complexity of code is only in your mind; high-level C/C++ code is really a simplification of what goes on down at the metal (if you have ever performed hand assembly at the hex level, you know what I mean - several old-timers here, I know, do, actually). Could things be made simpler? Of course they could, but you can only get so simple before you get to a point where it becomes impossible to do complex things.

I will not respond to Arduino help PM's from random forum users; if you have such a question, start a new topic thread.

I do several simple projects with kids. It would be nice to be able to do a tabular layout, rather than scroling like crazy, so we can easily see what we want to show.An example is simple data monitoring, where we want to see, say, the minimum, maximum and most recent value. Scrolling is distracting and unnecessary.

I'd be happy with something like a very simple vt100, i.e. - clear screen- move to row, column (and then be able to print)- clear current row to spaceThese could be 'magic' characters, but things like Serial.clearScreen(), Serial.cursorTo(), Serial.clearRow() would be okay.

It'd be helpful if '\r' did return to the start of the line (this is broken on my Mac). But I'd be okay with Serial.startOfLn(), or something.

This would reduce the need to write a processing program (which is beyond most of the kids I have in the few hours available), or resort to cutting and pasting into a file or spreadsheet, just to get a reasonable output printed.

I agree with gbulmer that providing the ability to do a tabular layout would be very desirable, although I would vote for implementing this in the print statement. This would enable LCD, Ethernet and any other classes that inherit print capability to also align columns of values using the same code. So my vote is to add some simple formatting capability to print that controlled the width and padding of a printed value would enable a sketch to align columns on any output device that supported print.

That's not to say that serial monitor would not benefit from enhancements, particularly the support of'\r' so that output can be kept to the same line. But if Arduino core development resources are limited, then more sophisticated Serial terminal functionality can be obtained by using one of the many open source Serial utilities that can be downloaded for free.

Serial.println("x", x, "y", y, "z", z); I'd like improvements of the serial monitor to provide:a. clear screen/window,b. position the text cursor to a specific row and column for subsequent print (maybe position within current row)c. clear current rowd. return text cursor to start of line with '\r' (rather than forcing a newline)

I don't mind how it is achieved. mem would prefer it not to consume precious Arduino team time, and suggest that it could be an existing Open Source terminal.

On the Arduino side, I would expect these capabilities to be nicely wrapped up as methods in the Serial class to make it easy to use. The same capability may be exposed as 'magic' characters which could be embedded in character strings and Serial.print()'ed.

mem and I would like it to be easier to create tabular output.

I would be satisfied with something that returns the character length of each type of printed item, e.g. if Serial.print(int) prints on the serial monitor, then Serial.length(int) would return the number of characters that would be printed. Then I'd like something to make it easy to pad with spaces, e.g. Serial.pad(int) would print 0 or more spaces. That would be enough for me to do tabular layouts.

I like gbulmer's suggested enhancements to serial monitor, and I would add one more - an option to send '\r' at the end of the string when the Send button is pressed to make it easier for a sketch to determine the end of an input string.

think that tabular output is needed as much with LCD as with Serial, so would want to see something along the lines of roypardi's suggestion that includes the ability to control the padding between fields so they can be lined up.

The ability to print multiple fields can be done now using a method published by Mikal Hart here: http://www.arduino.cc/playground/Main/StreamingOutputIts syntax is a C++ standard but I wonder if it looks a little scary to non-technical people?

so for me, the higher priority is something simple that can print a line at a time that includes control over the width of a field so printed values can line up on serial or lcd (or ethernet).

The ability to print multiple fields can be done now using a method published by Mikal Hart here: http://www.arduino.cc/playground/Main/StreamingOutputIts syntax is a C++ standard but I wonder if it looks a little scary to non-technical people?

Took a look at that link. I'm not exactly non-technical but I have no idea what the relevant line (below) is doing. Does this compile as is? class T?

The ability to print multiple fields can be done now using a method published by Mikal Hart here: http://www.arduino.cc/playground/Main/StreamingOutputIts syntax is a C++ standard but I wonder if it looks a little scary to non-technical people?

I used to write C++ professionally (before Java and Erlang came along , and I was fine with the "<<" operator overloading on Streams. IMHO, we got a bit 'punchy' back in those days, and used overloaded operators for anything and everything. I felt it had got to a point where the editor needed to be smarter than me to figure out which code was actually going to be applied, so that it could show me the appropriate definition.

IMHO, one of the beautiful aspects of Arduino is the taste and restraint that the team has used to keep things clear and approachable.

I have no objection to folks using operator overloading. But I feel it is hard enough for new programmers to get to a point where they are happy to manipulate bits with "<<" and ">>", and that overloading to create different semantics may create confusion. I feel that is not what Arduino is about (I realise I am not an authority). I would beg that overloading "<<" for printing be eschewed in Arduino's IDE examples, as it seems a leap too far for the new programmer.

If folks want a more compact way to print, just overload a new member function so that it can be used like:

Serial.out("y=").out(y).out(" x=").out(y<<3).newline();

I accept this is not as pretty and compact as the "<<" overloaded operator, but it reduces confusion compared to:

Serial.print(long);which also doesn't compile. (AFAIK, the page history says it has been like this since 22nd January.)

(I apologise for not fixing it. I was tempted to fix it, but I wanted to leave it so folks looking at the entire example can see and appreciate how hard this stuff is. I'd only read this as a result of mem's post, and I 'read' it more than once, and missed it :-( )

I would observe that this has been referenced several times in this thread, and presumably read, and no one has raised this concern. I think it suggests that it is not easy to understand.

As I mentioned in my earlier post, I do think that the C++ syntax looks a little scary to beginers. I am not clear what concern you feel has not been raised?

mem - let me reword my post to make it clearer. I apologise for causing further confusion.

The 'concern' was that there was an error in the playground example, and we all missed it, which set off alarm bells in my head (but I do suffer from Tinnitus occasionally :-))

Quote

The IDE syntax highlights the keyword so the bug is easy to spot:

That's true, but this example illustrates how easy it is to make a mistake and not see it. It was their for more than 2 months, and it wasn't spotted. I assume several of us read it as a result of this thread, and it still wasn't spotted.

In this case, colour hadn't helped get it right. I didn't read it as an error as quickly in the overloaded version, as in the simple print() version. Maybe I'm just weird, but did you have the same experience?

Also, I feel colour should be used to help, but not be a replacement for clarity. Colour is a valuable visual overloading to convey meaning, but it can't be the only mechanism because most playground pages, books and examples are monochrome, not colour. (After all, some folks are colour blind, or have problems seeing at all)

Quote

I hope this post doesn't come across as argumentative, ...

No, now that I think I've "got you" I read this as helpful

Quote

..., I suspect we are in agreement that a simpler way to format output would be most welcome.

Almost in agreement. I'd like to have a way to format output for a tabular display, but I am unwilling to sacrifice simplicity and clarity of the majority of simple cases to get it.

Serial.print("x ");Serial.print(x);Serial.print(" y ");Serial.print(y);Serial.print(" z ");Serial.println(z); is okay with me, because it looks plausible. I can show people how to create their own functions (pointing out setup() and loop() are examples). I can explain that there is a further idea of 'class' which they can investigate, which accounts for the 'Serial.' part. Folks seem okay with this.

Serial << ""x " << x << " y " << y << " z " << z << endl;I agree with you, this is scary syntax. This feels like a big leap. It is nifty, and, in context of C++, clever. This is one of the few areas where I always disagree with a very dear friend (who was the first person in Europe to have a C++ compiler). I think it is clever rather than clear, especially if you also try to use "<<' to mean shift left.

[edit]Given that we are often working at low-level, writing embedded-style code, the shift-left meaning of "<<" seems more important than the convenience of using "<<" for output.[/edit]

IMHO, for the subset of C++ required to understand the majority of the Arduino language, we do not need operator overloading and template classes.

Serial.println("x", x, "y", y, "z", z); as an alternative. This would require a varargs mechanism for folks to write their own, and I'd prefer them to master 'class' and member function overloading before I'd tackle that one.

This may be a mistake in roypardi's email, but I don't like the notion that println would expand "x" to "x " (presumably because it is the first string?), and "y" to " y ". I assume it should have been written

Summary: - please don't use overloading of any operators to introduce any new meanings beyond C in File->Examples- this implies, please don't use "<<", to mean print in Examples- the fact that the "<<" overloading of print playground example had an error for two months suggests that there may be some issues with using operator overloading, though I accept that is not definitive- if you really want a more compact way to print, consider new member functions, like out() or p(), which can be chained, but please keep that out of Examples too.

HTHGB-)

[edit]It is pretty easy to explain to programmers coming to the Arduino that the Arduino language is C with some great libraries, and helpful C++ additions. No one seems to panic. If I say it is C++, folks start to look a bit skittish, and I have to calm them down [/edit]

I can agree, but they seem to figure out that cut & paste is helpful, and they have few preconceptions about how hard it should be.

[edit]IMHO, it is us, the folks with experience of several alternatives who have the most problems with it because we have the baggage that "it can be so much neater". My experience of folks new to this stuff is, "well, it makes sense, it's a bit of typing, I'll just do it".

I'm not saying we should accept an ungainly approach simply because beginners know no better. I'm just saying it doesn't seem to be as annoying as, for example, watching the screen scroll past like crazy when all you are looking for is two numbers changing.[/edit]

If this were a whole new language, then I can imagine that it could be neater. I just feel overloading "<<" brings more pain that relief.

Warning: Dreamy rant alertI prefer to live within the constraints of a popular existing language (C++), which is a pretty good fit for what we use it for, and which has relevance in industrial contexts, and is not a toy language.

I like that the Arduino team has the taste and talent to make the barrier to entry so low that children, who have never programmed in their lives before, can get to grips with it in less than ten minutes.

I like that folks don't need to learn about C++ 'class' and can still produce wonderful, amazing things.

I like that the full power of C++ is snuggled their under the covers, so that if I really need to use it, I can.

Arduino really is a work of genius. I look at the 'competition', who have this example of genius in front of them, and who could "stand on the shoulders of giants". I see that Arduino is still amazingly good. IMHO the "Arduino Language" is better than any other examples I've seen. It is the things that are used with delicacy and taste that I admire most. Others can't resist using extra features, and seem to end up requiring quite a lot of sophistication to understand what is happening. Less is more :-)

End: of Dreamy rant

I am not saying the Arduino Language is perfect, just better than the other examples I've seen, especially for beginners to embedded programming.

Serial.o("x ").o(x).o(" y ").o(y).o(" z ").o(z).endln();I admit, I don't like it much, but it is less to type

I think it is only slightly better than "<<" for print, from the perspective of the concepts you'd need to do it yourself.

But much better than "<<" overloading print from a beginners perspective, especially if you also want to use bit manipulation with left-shift.

IMHO, it is also better to avoid operator overloading for the sake of a Java or C programmer, and Java is one of the most poplar professional programming languages in the world, and C, reputedly, the most popular embedded programming language (tussling with assembler?). I think they would get that Serial.o().o().o() approach.