I've started cooperation with one guy from Oulu, and we are continuing direct chat about language construction.

There is also an idea of protecting our ideas.

If you want to participate in that mail thread - send mail to moc.oohay|akipat#moc.oohay|akipat.

The main problem itself is text parser itself - how to make it happen. And how often language syntax itself needs
to be changed ?

If you have ever considered a perl programming language - it's syntax is evolving so fast that you can find
picture like this on internet: http://www.axis-of-aevil.net/archives/img/2003_08/p6_cover.jpg

As for text parsers there are quite many different alternatives, like

1. old school tools / define/C based - tools like lex, yacc, bison.
Really complex to use. (You will put every single gadget into rocket itself)

2. new school tools - boost::Spirit / C++.
Suffers from over heavy templates. Complex to use because of mysterious template errors.

3. http://www.antlr.org/article/list
ANother Tool for Language Recognition v3.
Recently updated - needs to be studied.

P.S. Must study alternative 3.

However we're not only intrested in parsing custom languages, we are intrested in
generating / printing language back from trees (Abstract syntax trees) - as well
as being easily to change language structure itself, which would trigger language
files (E.g. source codes) could be changed at the same time.

Keeping a list of what I have already analyzed on mono project.
In order to compile mono you will need to follow instructions from here:
http://shana.iidbbs.com/en/mono_cygwin_tutorial.html

Try to follow instructions in exactly the same order as written there.

When configuring cygwin - always use "Default Text File Type" as "Unix / binary".

For windows XP you will need to modify home folder, by setting HOME environment variable, like mentioned in here:
http://www.joomlawebserver.com/freebsd/remote-access/03.-creating-a-cygwin-home-drive.html
(See Setting the HOME environment variable in Windows)

I by myself installed mono binaries into C:\Program Files\Mono-1.2.6, after that .bashrc will contain followin set up:

PATH=.:/usr/local/bin:/usr/bin:/bin:/usr/X11R6/bin:/cygdrive/c/Program\ Files/Mono-1.2.6/bin
PKG_CONFIG_PATH=.:/lib/pkgconfig:/cygdrive/c/Program\ Files/Mono-1.2.6/lib/pkgconfig
LD_LIBRARY_PATH=.:/usr/local/lib:/usr/lib:/lib:/cygdrive/c/Program\ Files/Mono-1.2.6/lib
export PATH PKG_CONFIG_PATH LD_LIBRARY_PATH

Additionally to that I had installed glib2-devel package (with cygwin) - that one needs to ne UNINSTALLED - otherwise
mono cannot be even configured.

"./autogen.sh " command works only with sources obtained over svn, I by myself took mono-package from mono website, and then
you need to run ./configure and make.
When extracting .tar.gz files it is recommended to use unix utilities -
gunzip <.gz file>
tar -xvf <.tar file>
instead of windows winzip - I have noticed that it processes unix linefeeds incorrectly causing that ./configure cannot be executed
after .tar.gz extraction.

Apparently compilation can last for quite long time (45 minutes to 2 hours) - so I'm awaiting for it to complete currently.

Mono definition:
http://en.wikipedia.org/wiki/Mono_%28software%29

Intermediate language is one thing which always facinated me - it tries to abstract all existing assembly languages and create
cpu/machine neutral intermediate / "assembly" language. Intresting thing about it is that it support quite many operating systems,
except symbian os. But PC's x86 and mobile devices armv5 cpu architectures are supported at least.

Advantages of IL as I see is that you don't need to have virtual machine - similar in java, where java byte code is interpretted,
causing java VM to become slow down factor in java development. (Java classes are quite slow in execution)
But IL can be interpretted by virtual machine as well - I remember seeing some IL language execution support made by some company
for symbian os. So IL can be both - interpretted by virtual machine, or native - code generated on fly. (And faster because of it)

I finally have reliazed how correct approach to reuse (ideas/design/source code/libraries) needs to be done.
Quite often people discuss about white box reuse - copy pasting source codes lines from one place to another, or
black box reuse - attaching whole libraries / source code to your project. With black box reuse you can achieve much more,
since you don't have to rewrite same thing twice, but disadvantage of it is that if underlaying code is badly implemented
or have weaknesses in design or testing, reuse will cause problems to appear.

I think the correct approach should be always "grey box" reuse. Meaning that you try to apply black box reuse, but looking in more details
what you have underneath. Underlaying (reused) project/library must be 1. replacable 2. have highest code standards / testing coverage in use.
If it's not - then you can fine tune it on your own, or make your own modifications so it would become better than previous attempt.

Ok… Where I'm heading with this one - is to mono project.
I've downloaded it, and it looks quite huge project by itself. Which is a first indication of it's weaknesses.
Some source codes contain up to 12'000 lines of code. Image to be a responsible of this nightmare… :)

Anyway - code quality of mono itself is quite high, but the whole mono infrastructure is made by mono project itself
(mono's allocation methods, mono's assetions.) It might be so, that for cross platform project there is no other way.

Quite large project anyway… A lot of digging will be needed.

Another idea I'm currently testing is automated modification of hand-written source code. It's like code generation, but with human writing the code, and algorithm upkeeping it. For example imagine a ball bouncing around in a box. Source code contains starting coordinate of this ball, but we can also update this coordinate in runtime. Just press "save" and next time code compiled and executed ball will start bouncing from different location.

This approach could lead to some interesting results. Imagine for example copying this bouncing ball - we'll have to clone some code-parts, recompile and reexecute whole program just to process "ctrl+v" keystroke. :) Just love the complexity and "hackness" of this approach.

Some similar ideas to this project - simplification of language.

Before 'Simple language' I have made some code for binary data generation and parsing.
First approach was to generate code which performs generate/parse.
Second approach I've took more advanced approach - trying to make type reflection / data type reflection technique.
(Not using .NET because working in such environment where it's not available)

First was much more simpler than second one, however second approach had more superior features, like
printing complex data types, estimating encoded data size, tracing decode/encode operations.

Library can handle dynamic data types, e.g.
typedef struct
{
uint8 length;
char s[length];
}c_string;

But then I've hit accross the need to use syntax like 'length +1' or 'length - 1', etc…
After that I've ended up of writing "simple calculator" which tried to calculate
simple formulas.

But then I've realized that instead of writing calculator I've could generate a code
for calculator. And this would be next approach, which needs to be tried out..

Most intresting idea why I've came into the need of new language is because
I have found plenty of internet examples, which performed something similar
to encode/decode library, however they used different names, like "Serialization",
"marshalling" (microsoft), data type reflection.

What I've learned from this - is that
you can have synonyms whichs only disturb software development work -
it's difficult if not impossible to find out analogue solution if it were ever developed.

In Microsoft documentation I've came accross 'class' and 'struct' code examples where
in both there were functions - meaning that there is basically no difference between those
two. If there is no difference - why do we need them both ?

Same problem applies not only to software development, but to other areas as well.

One of the hell where this problem is unleached is microsoft development network documentation
(MSDN) - it's size already measured in Giga bytes (over 2 Gb last time I've checked).
Even if I would like to read it fully at some point
of time, it would take a lot of time. And you can find at least 4 different implementations of string class
there. Intresting - isn't ?

The main problem here is not about the productivity - it's really easy to make documentation,
the problem is with how it differs compared to other implementations (what is common, what is uncommon,
reusability "level"), and what advantages / disadvantages it brings along.

Internet is having currently the same problem - it's "exploding".

I by myself have done some code generation as well as project files generation - one problem against which I hit right away -
is that autogenerated code modifies the timestamp of file, and after that synergy (similar system to cvs - coherent versioning system)
thinks that code were updated, even through no changes appeared in the file. I've walked around this problem by making
read-compare-modify_if_needed generation technique.

Previously I've made some generation code, as well as parsing. Now I think that these two cases must never be separated - since
they are performing almost the same thing. Where in one function you have encode_uint8, encode_uint32, on second you have
decode_ same data types.

In programming there exists quite many cases when similar functionality is combined into the same function call / or interface
- e.g. SendReceive. I think the same approach must be used for generation of code / parsing.

One example is how currently most of code generation works - they don't care about code parsing afterwards.
Meanwhile in GDB (debugger) I have found a mention that they require to know stack depth of each function call, what needs
assembly code parsing. This is example use case that could potentially reside in the same code.

About macro's approach - I'm not going deeper in C++ syntax, I'm currently intrested in code generation techniques (Either IL or assembly).
Btw - I think you are going into too much details. We could start from simpler case/example.

Must say I'm confused. For years all the "experts" were saying that copy-pasting is bad, macros are evil, and that we need scripting languages to get rid of compilation step.
And now they feel so satisfied and proud of adding additional complexity of using multiple syntaxes (xml and some base language) and adding additional step to program execution (code generation step), and introducing copy/paste-automatization where code can no longer be changed directly (but only through some code-generating algorithm).

So, here come my few short observations on this subject:
1. In the link above implementation would be much shorter to use c++ macros like "DEFINE_MAP(IDOK, 1)".
2. Paul Graham is one of the few people who where praising macros, because of their ability to generate code. He was talking about Lisp's language-extensions.
3. It's easier to use Search-and-replace to change multiple instances of copy-pasted code. Automatization is always the root of all evil. Same goes for code-generation-automatization.
4. Compilation step can be made just as invisible as virtual-machine-based execution. By optimizing things needed to be compiled (for example by using dll-files) and using program-state-serialization code-changes to a running c++ program can be made really fast. And by fast I mean real-time fast.

Proponents claim a particular language makes it easier to express and understand concepts in one area, and more difficult in others (the various computer languages may be seen as this kind of constructed language).

It's true that when you first start to use new technology, you tend to think in concepts it defines. But I would argue that this is not a good thing, and in fact should be Learned to be avoided. There doesn't really exist a technology that would be worth "thinking" in. :)

For example php-language allows you to generate html code, but should this concept really affect your thinking? Here's a good way to go around this html-code-generating "feature":

 $title_variations = 1*($person_id!="") + 2*($email!=""); { if($title_variations==0)print" <b>$name</b> ";if($title_variations==1)print" <b>$name ($person_id)</b> ";if($title_variations==2)print" <b><a link=mailto:$email>$name</a></b> ";if($title_variations==3)print" <b><a link=mailto:$email>$name ($person_id)</a></b> "; // Note: Idea of this example is in the alignment of previous if-checks. It's hard to ensure that with stupid browsers, but all if-checks should align to the same indentation. } 

So, does that mean that programming languages are more like unavoidable evil, that suppresses programmer's expressiveness and imagination?
Ok, that's of course an exhaduration, but what I'm trying to say is that it wouldn't probably be enough to just change syntax of a program definition for new programming language be useful. Language should be designed to solve some small but really complex problem in such a way that somehow circumvents all the pitfalls of object-oriented, functional and other programming paradigms. Then this new programming language would be trully great.

Code Generation Network

http://llvm.org/

Needs to be checked out…

2. Yes, concrete examples does not exists, because language itself does not exists.

If you look for example Lojban language: http://lojban.org/publications/level0/brochure/pref.html
then you can find out that Lojban language was developed within 1966 - 2001 years.
There exists large list of people involved in language creation.

However dispite of cooperation / development - there is less than 2 tousands people
http://www.lojban.org/tiki/tiki-index.php?page=Frequently+Asked+Questions+About+Lojban&bl#G4
which are using Lojban. I by myself did not know anything about Lojban until started to analyze
constructed languages.

What we can learn from this ?

1. Language creation might take long time (we are talking about years)
(Do I want to spend x years of making something unusable, weird or unknown ?)

2. Language must be done with cooperation with other people.
One person cannot construct new popular language on it's own.

3. In Lojban word 'mi' could mean 'I/me/my'. What I'm intrested in here
is not only why it is done so, but also a background ideas behind it.
It would be quite helpful if someone who made this Lojban word originally
would tell why it is done so, and compare how it's done in other languages.

Question: Author of Simple language did not gave any concrete example on 'Simple language' ?!

http://simplelanguage.wikidot.com/local--files/forum:start/NewLanguage_v0_2.ppt

Disadvantages:
- Cryptic language name.
- Less popular than Esperanto: The current number of Lojban speakers, although indeterminable, is much lower than for Esperanto.
- Does not alter existing meaning of terms, only renames them. (Missing refining / resorting in vocabulary / terminology which I would like
to achieve with Simple language)
- Cannot be executed as computer code. (And might be not designed for that purpose as well)

Advantages:
- Language is designed to be easily parsable by computer.

Software Product Line Practice - Architecture Definition:
http://www.sei.cmu.edu/productlines/frame_report/arch_def.htm

Meaning that we try to identify lower layer first (E.g. how pc code generation could be done) and then try to map against
higher layers (How simple language will look like).

I have already hit accross sentence like -

http://en.wikipedia.org/wiki/Constructed_language
Proponents claim a particular language makes it easier to express and understand concepts
in one area, and more difficult in others (the various computer languages may be seen as this kind of constructed language).

This means that if we take english for example and modify it slightly and get new language - will it be simpler or more difficult to use ?
It could go in both directions actually. In order to make it easier, we need to try different expressions / phrases / programming approaches
in order to find out which would be most suitable one for us to use.

My primary goal is to start from english - (Simple language = english) and then iterate in right direction. (Simplify, structurize)
There exists hundred different languages - what will make simple language better than other?
So the correct approach would be to "design" or clearly write why we used this approach or that approach.

In following book - "The Peopleware Papers – Notes on the human side of software"
(Author: Larry L.Constantine ISBN: 0-13-060123-3) - you can find following text:

This view tends to lose sight of vital information. In general, when only the work product is preserved, we know what we got in the end but not how we got it. How the software was generated, the decisions along the way, are essential part of process. Do we want to trust to memory? Do we care only about our mistakes or do we also want to learn from them?

A particular problem with groups that keep only the end product of software development is that they do not preserve a record of what they didn’t do. Often it can be as important to know what approaches were rejected and for what reasons as to know which were selected. This is vital information to have when it comes to future versions or systems or to preserve for when the current system goes down the tubes. (page 18)

I want to apply the same approach - we log/ keep history of everything what we do, because important is not only "Simple language", but
it's history - how it was made.

I believe that general discussion must be kept in parallel, as well as some practical approach
could be applied as well. Previously I had one forum - and it's main problem - it was too
"political" - nothing practical born from it. We should avoid of being too abstract.

But from where to start ? I believe that in order to build egypt pyramid, you need first to master
basics (=stones). Without stones there is not way you can build large system.

I had an idea to start from some "hello world" application for pc, and compare how the same operation
looks in real life - person coming into room and saying "hello world". :-)
After that we need to extract basic elements in this action - that's person, application,
action: saying.
We could adapt some words from "Toki Pona" language:
http://www.tokipona.org/
(I like Toki Pona because of it's simplicify, but this is again my preference, you may like something else)

how person is defined there, and refine what we mean under person or application - what is common
and what is uncommon.

After refining whole problem - we could construct hello world in "Simple language".

And this kind of "analysis - sort - refine - understand" rounds needs to be done for all words or
operands in programming language.

Always start from really simple cases, and complex cases are built from simple cases.
It's important to return back to simple case in case complex case starts to become too complex -
it often refers that redesign is needed.

One thing which I'm currently trying to think through - generating C/C++ code does not allow
automatic execution of that code, but I would prefer to execute it right away after code (C/C++)
would be created. In that sence microsoft IL or assembly would be better alternative from where to start.

Mono project is dealing currently with being able to translate microsoft IL into assembly code (pc side)

http://en.wikipedia.org/wiki/Mono_(software)
http://www.mono-project.com/Main_Page

but what I have checked from there - there still exists some unresolved issues.
Also I haven't seen mono-project being widely in use yet.

Gnu compiler collection (Gcc) project has also something related to common
language infrastructure:
http://gcc.gnu.org/projects/cli.html ,
where front end basically refers to fact that gcc parses IL,
and backend means that gcc can produce IL from source codes.

If you have ever analyzed gcc v4, it's architecture and so on - it
it really complex - however complexity mostly comes from
what gcc needs to support (different languages).

If you have ever analyzed microsoft common language
infrastructure - you can find the same complexity there as well.

I believe both projects are going in a wrong direction, right direction
is simple language. Merely because simple language could simplify
complexity (on both - natural and programming languages) and
bring people closer to computer world and vice versa, and people
closer to people (improoved communication, it's efficiency)