Hi, my name is Hase, and I know everything :-)
Well, except for Tcl, which someone recommended to me, and that's why I'm here - looking for a good introduction, tutorials etc.
I'm going to comment and rate the pages as I go. From a newbie-perspective, that is.
Maybe discussions would work more smoothly if I create separate "rant"-pages for some topics...
Pages I have found so far:
Maybe there should be some
What I really want is a complete "computing environment", that can do everything, fast, free, small, portable, easy to understand, quick to setup, safe, secure, well supported, etc. etc. It should be able to work with no internet, if out in the wilderness (say, working at a friend's PC).
Ok, maybe some of that needs to be tuned back a notch :-)
One part of that package would be some programming-language, because not for everything there is an app.
Well, maybe there is, but maybe I dont like it, or it has ads/spyware/cost/whatever, or it maybe just doesn't cover my usecase.
For example, a usb-stick with several partitions, say for windows, linux, data&documents.
The windows-part gets a bunch of portable apps:
Browser, Mail, Editor, Calculator, Officepackage, Imageviewer/Paint, Mediaplayer, misc.utilities.
The linux-part gets some linux-distro with software that does about the same stuff.
The data-part gets all the music/text/pics etc.
BTW, all that on a smartphone/tablet would be nice too, but maybe not "usable enough" with only a small screen and no keyboard.
For doing calculations, a spreadsheet should do.
Smallish programs can be run using Online-IDEs, for example at http://www.lua.org/demo.html , http://codepad.org/ or http://ideone.com/
Some software that is pretty standard on Linux can be used for programming too, such as awk and perl.
There are some "mainstream" programming-languages:
Then, there is thefreecountry.com and http://rosettacode.org/wiki/Category:Programming_Languages .
And "real" programs need a GUI, that means on top of the language,
some toolkit is needed for that (FLTK, GTK, QT, Tk, WxWidgets, whatever).
In short, there are lots of things that might be usable to fill this niche "programming-language", and I'm not sure what would be "best".
jorge: depending on what your background is (if you are new to programming, or just new to Tcl) a different tutorial style/content may be better, but I recommend:
http://www.cwflynt.com/CS146GameLab/
PYK 2014-09-12: Hase, welcome, and thank you for taking notes from your perspective as you go!
This is helpful to people who are working to organize the wiki to make it more useful to beginners.
You might want to join the Tcl Chatroom, where people hang out all day discussing Tcl and helping beginners.
Feel free to dive in and edit wiki pages whenever you think you can improve one.
It's a great way to get more feedback from the community, and helps to keep things up-to-date.
MiHa: Thanks for the invitation! I think my english is quite good, but not up to speed for live discussions.
PYK: I wouldn't worry about that. The Tcl Chatroom, is hands-down the best place to get quick satisfying answers to all those beginner Tcl questions, and since it's a group conversation, you can take a while to answer, especially if you let people know it takes you a while to answer.
PYK 2015-02-24: I love that you're using RS' if 0... notation to add a literate programming style to new pages like FuzzyClock!
Maybe eventually the wiki will know how to work with that notation when rendering a page.
MiHa: Well, the page about Formatting Rules / New Markup gave me some ideas !
I think it is quite useful to structure longer wikipages into **sections** for easier editing.
That, together with <<TOC>> makes the Ask-pages much more readable.
And it is also safer and easier to write/edit a single section, than the whole big page.
I finally got around to actually write some NewProgram s:
Maybe: StringDemo StringWrap
HJG 2015-05-14: Maybe an Invoice-Demo would be simple enough.
Some entry-fields, menu with just File/Quit, Edit, Print, Help/About.
moved here from the programs I posted
Example: looking for "create text" - the search shows lots of hits, but the page I want
turns out to be Tk Built-In Commands - canvas manual .
That is far from obvious.
And on that page, the thing I wanted is pathName create type ... ,
where type can be arc, bitmap, line, rect ... and, after scrolling almost all the way down, also text.
That was not the most helpful way to present the information.
In fact, I can hardly imagine the noob that would make it so far.
I think this is a serious obstacle for newcomers.
For a reference-manual this might be ok, but when looking for help to get something done, this is not enough.
Helpful people on IRC are nice to have, but shouldn't be a substitute for good docs.
And examples are also very much missing in that helpfile.
KPV This is a common complaint about Unix style man pages: they're only really helpful if you already know what you're doing.
MiHa I can see such things happening when 'the experts' write the docs, without checking how understandable/useful the endresult is.
If enough people point out such shortcomings more often, maybe the situation will improve.
I would expect links to lots of short, self-contained, working snippets of code included in such a helpfile.
RLE: @MiHa: please do not change the wiki text of existing pages to insert a carriage return after each sentence in text that you are not otherwise changing content wise. For an example, look at the difference view for the TriPeaks Solitaire page you just edited: diff view: https://wiki.tcl-lang.org/_/diff?N=13092&V=19&D=18&W=0#diff0
As best I can tell, the only real changes you made were to add some header lines and tweak the categories slightly. But deducing that those are the only changes out of the huge number of "fake changes" that resulted by your inserting a line break after each sentence is extremely difficult.
Had you not inserted those useless line breaks in the raw text, then the difference view would have shown only the changes you made (presumably new header lines and a change to the categories), rather than having your changes obscured inside of a field of fake changes.
Just follow one simple rule: unless you are modifying the content of existing text, then simply leave it alone. By doing that, the difference view will show what has really changed, helping tremendously when someone wants to see what has been modified.
MiHa: I find it hard to read long "wall of text" sections, so I fix that while I'm doing edits on a page.
The diff on this wiki may be poor, but you might want to look at the "word differences".
Even the 'word differences' expose the added fake carriage returns, which also obscures the true changes (although not quite to the extent as the line difference view). Please, if all you are doing is adding carriage returns, just don't. If you need to 'reformat' to read, then copy elsewhere to do your reformatting, don't save those changes back into the wiki.