Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[blackmagechill]

I'm trying to learn python. It's a lot like that time I tried to learn ruby, except python has cleaner syntax. Anybody got any ideas as to where to get started?

[Mego]

Hook one of these (http://www.arduino.cc/) up to a mechanized club and a speaker and I'll write a program that beats you over the head to remind you to learn to program!

Those things are so cool. I want one so bad.

I'm trying to learn python. It's a lot like that time I tried to learn ruby, except python has cleaner syntax. Anybody got any ideas as to where to get started?

Imo, the best way to learn a language is to dive in head-first. Try Project Euler for problems that will introduce you to a lot of Python's features by forcing you to use them in order to find the solutions. Also, The Python Documentation is a very handy reference.

[MadocComadrin]

Hook one of these (http://www.arduino.cc/) up to a mechanized club and a speaker and I'll write a program that beats you over the head to remind you to learn to program!

I can't be aaaaarrrrsed!

Hmm, then we'll have to dearse you.

[SolarShado]

Hook one of these (http://www.arduino.cc/) up to a mechanized club and a speaker and I'll write a program that beats you over the head to remind you to learn to program!

Those things are so cool. I want one so bad.

Yes.

I saw online somewhere a couple months a similar device for $8... now I can't find it again

Was pleasantly surprised to see arduinos in Radio Shack the other day though...

[Nadaka]

Hmm. Would it be worthwhile for me to share an alternative to XML/JSON here? I am 99% certain that no one here needs such a thing. But who knows what people might find interesting.

[Mego]

We are programmers. We always like looking at alternatives. You never know when something might work better for a project.

(yes)

[Siquo]

Lay it down on us, brother!

[Nadaka]

MNML

Spoiler: Preface: (click to show/hide)

What is bad about XML:
1: verbosity. each element name is repeated twice, and each of those names is enclosed in its own set of braces.
2: whitespace. xml has fiddly rules for what white space is and is not important, and there are inconsistent implementations in the interpretation of this (thank you microsoft).
3: validity. An entire document must be well formed or discarded entirely. Combine this with the single root element requirement and you have a format unsuitable for streaming data sources.
4: There is more, but screw it for the moment.

What is bad about json:
json has difficulty serializing certain types of objects. In javascript all objects are arrays and all arrays are objects. JSON notation has difficulty dealing with this because it does not allow setting named attributes on arrays, nor does it allow putting values into an object as if it was an array, even though both are possible and indeed frequent in javascript.

Spoiler: Introduction: (click to show/hide)

M    Model-driven
N    Non-xml
M    Markup
L    Language


The actual definition of this acronym is subject to change. The goal of MNML is to create a simple, efficient but effective language to replace the use of XML and/or JSON as a data transport and storage specification in web development. I will use every day English to describe the language explicitly as well as provide a formal grammar.

Spoiler: Overview: (click to show/hide)

this section provides an overview of the structure and format of MNML. The MNML language consists of collections, attributes, values, words, whitespace and comments. Collections and words are collectively referred to as elements. A MNML document minimally consists of an implied root collection, its attributes and its child elements. The implied root container allows conventional text documents to be valid MNML code if they do not contain MNML reserved characters.

A collection is a container structure that can contain 0 or more other elements. When writing MNML, a collection is enclosed by square brackets"[]". Inside that enclosure are the attributes and member elements of the collection. An element within a collection is a child of the collection. The collection containing an element is called the elements parent. The ancestors of an element are its parent and all of the ancestors of its parent including the root collection.

An attribute is a named property of a collection that may or may not have a value associated with it. A collection may only have a single instance of a given attribute. When writing MNML, an attribute always starts with an at "@" character and attributes must come before member elements within a collection. After the starting "@" character, an attribute may only contain any reserved characters.

A value is an element associated with an attribute of a collection. When writing MNML, a value is separated from its attribute by a semi-colon ";".

A word is a basic token in the MNML language with arbitrary meaning. A word consists of any number of consecutive printable non-whitespace characters. A word can include MNML reserved characters by using an escape sequence. A valid MNML document may consist only of words if desired, this means that text documents are valid MNML documents if they do not contain reserved characters.

Whitespace consists of the space, horizontal tab, new line characters and any other unicode whitespace character. Presence of whitespace is used to separate words from other words and from attributes and values. Whitespace is not required to seperate attributes, collections or values from other attributes, collections or values nor is whitespace requited to seperate collections from words. The type, amount and arrangement of whitespace used has no bearing on the meaning of a MNML document at all.

Comments are for documenting the markup used with MNML. When writing MNML, a comment is enclosed by parenthesis "()".

Reserved characters for MNML are '@', ';', '(', ')', '[', ']' and '\'. These can be escaped by using the and '\' character. Other escape sequences include space '\s', tab '\t', new line '\n' and collapse whitespace '\c' as well as unicode character representation '\U0000' where 0000 is the codepoint of a unicode character. These escape sequences produce characters that may be part of words. The purpose of the '\c' escape sequence is to allow words to be separated by whitespace in the document and parsed separately, even if they would normally be displayed together. For instance this may be used to separate punctuation from the words of a sentence.

Spoiler: Example MNML compliant document: (click to show/hide)

@title;[@huh?|what? This is the title of this document.]
@some;stuff
This is some content of the document. (this is a comment) [this is some more content and is the 8th element in the root element.] [@foo This has/is a foo.] [@bar;baz This things bar is baz.] \n \( \c this is not a comment but is on a new line. The parenthesis are separate words, but should have no visible whitespace displayed. \c \) [this element has 5 words.]

Spoiler: Formal Grammar(new): (click to show/hide)

Note: The '_' character is being used as a seperator to indicate that some form of whitespace must be present.
Note: The '-' character is being used as a seperator to indicate that no form of whitespace may present.
Note: The word epsilon is being used in place of the traditional epsilon character.
Note: There may be some reording of rules and epsilon optimizations, or minor errors, but I have a headache.
Note: nonWhitespaceNonReservedCharacter is not defined because fuck grammar.

document -> attributes childElements | elements

attributes -> attribute attributes | epsilon

attribute -> @attributeName value

attributeName -> attributeCharacter-attributeCharacters

attributeCharacters -> nonWhitespaceNonReservedCharacter-AttributeCharacters | epsilon

value -> ; element | epsilon

element -> [ elementContinued | word

elementContinued -> attributes moreElements elementClose | elements elementClose

elementClose -> ]

word -> character-characters

character -> escapedCharacter | nonWhitespaceNonReservedCharacter

escapedCharacter -> \-sequence

sequence -> reservedCharacter | s | t | n | c | u-codePoint

reservedCharacter ->  [ | ] | ( | ) | \ | @ | ;

codePoint -> digit-digit-digit-digit

digit -> 0 |  1 |  2 |  3 |  4 |  5 |  6 |  7 |  8 |  9

characters -> character-characters | epsilon

moreElements -> _ elements | epsilon

elements -> element moreElements

javascript implementation:
pending...

java implementation:
pending...

c# implementation
pending...


Edited for spelling: I think I over used separate: because I mis-spelled it a lot.

[Stargrasper]

Life sucks.  Since I don't actually have time to read that much thread, has anyone wanted/needed me for anything in the last 40 pages or so?  PM me if I take too long to answer.  Sorry folks.

[malloc]

MNML

Reminds me of http://xkcd.com/927/
Good luck.

But either way, XML is not too bad. It really depends on the implementation, rather the format.

[Siquo]

MNML

Hmmm. Too many reserved characters, and how would you discern between strings and non-strings ("25" is not 25)?
I can see it having a use, but I probably won't.
Also, I keep reading it as MNML...

[Nadaka]

MNML

Hmmm. Too many reserved characters, and how would you discern between strings and non-strings ("25" is not 25)?
I can see it having a use, but I probably won't.
Also, I keep reading it as MNML...

I don't differentiate between "25" and 25 at this time. Both are words. Though "25" is a 4 character word containing quotation mark characters, and 25 is a 2 character word only containing digits. In order to differentiate them in the spec, I would need to add quote marks to the reserved character list, and because strings as such are technically an enclosure, i should probably use a matching pair of markers, and the closing quite character is not on the standard keyboard.

I think the reserved character list is as minimal as it can be without increasing the size of an encoded stream and using multi-character tokens. I could eliminate comments, but then there would be no comments. I need a set of paired enclosure characters for collections and an escape sequence start character. Eliminating the attribute start character and value separator character creates an ambiguous grammar. Both can be eliminated only if there are no named attributes. The attribute start character can only be eliminated if there are no attributes without values, in that case only an value separator is needed to indicate the presence of an attribute value pair. And the value separator can only be eliminated if an attributes value is always a collection, in that case the separator will be the opening character of a collection following the attribute name.

And I was actually considering adding 1 or 2 additional reserved characters to provide type information (so you can distinguish between "25" and 25 for instance).

[Siquo]

Adding "string" support decreases the number of errors you can get, because suddenly all reserved characters inside a string are no longer reserved (except " ). Especially having to escape () is going to be a pain.

[Nadaka]

I'll consider it. And strings are something people kind of expect to be able to do. Though it may raise some issues with encoding. When do you use strings vs a sequence of words?



This is a bunch of words.

"This is a single string."

"This" "is" "a" "bunch" "of" "strings."

[Siquo]

True, depends totally on what you aim to do with it.
If you want to replace JSON and XML (and that is how I interpreted it), expect people to not give a shit about arbitrary partmentalisation of string data called "words". Spaces are characters, too, you know. Those poor, misunderstood whitespaces... Always discriminated against by the black letters, never allowed to appear more than once, or they'll be... "trimmed". Man, the stories I could tell you.