APL Wiki|
⇤ ← Revision 1 as of 2010-01-04 14:08:49
Size: 3686
Comment:
|
← Revision 2 as of 2010-01-04 14:39:34 ⇥
Size: 2728
Comment:
|
| Deletions are marked like this. | Additions are marked like this. |
| Line 1: | Line 1: |
| ## page was renamed from SamplePage = SamplePage = |
= A Positive Outlook for APL = |
| Line 4: | Line 3: |
| ~-<<SeeSaw(section="table-of-contents", show="true", seesaw="false", toshow="<<(Show>> table-of-contents)", tohide="<<(Hide>> table-of-contents)", speed="Slow")>>-~ <<TableOfContents>> |
A lot of the content of sites like comp.lang.apl is very depressing, and must surely generate a poor impression of APL is stumbled upon by the curious or new-to-APL. |
| Line 7: | Line 5: |
| == Overview == First thing to note is that this page is useful only when displayed in the Text editor. |
I personally think that the future for APL can be very positive, but we need to generate a positive attitude in the things we say and write. Here are a few random seeds - please feel free to amend and append as you wish. |
| Line 10: | Line 7: |
| This page contains examples of the most common (but not all) formatting tasks. It is probably the easiest way to find out how to solve every-day formatting problems. | == The Future is More Valuable than the Past == |
| Line 12: | Line 9: |
| For a complete reference see HelpOnEditing | Let's stop all of the "when I were a lad and remember how I dropped the card deck for APL-1130" reminiscences. Nobody cares unless they were there. Forever falling into this mode helps people who want to think of APL in the past tense. The Wikipedia entry on APL is a particular disgrace (and control of its content seems to lie with people who know nothing of APL). |
| Line 14: | Line 11: |
| == Paragraphs without and with embedded APL code == When writing a paragraph, remember that in HTML whitespace is ignored. So this is shown as an ordinary paragraph while when editing it you will see that it is not. Not exactly at least. |
== There's Nothing Wrong with Being Replaced == |
| Line 17: | Line 13: |
| . Note that a blank at the beginning of a line provokes indention. | One of APL's great strengths has to have been that it has allowed people to formulate software solutions without having to concern themselves with computer architecture. If the solutions crystalise into "products" or "business-critical infrastructure", there's no harm in handing them over to other specialists - doing this frees the innovators to move on and address new problem areas. |
| Line 19: | Line 15: |
| You can embed APL code in a paragraph: `{{⍵/⍨2=+⌿0=⍵∘.|⍵}⍳⍵}` is an example. | == We are Already Interoperating with Other Software == |
| Line 21: | Line 17: |
| One paragraph is separated from another by a blank line. | Not only is APL portable across platforms, we are already handling matters like extracting data from corporate databases. Harangues about how we need to develop bridges to things like SQL are doing APL a disservice, we are already doing it (but not necessarily telling the world). |
| Line 23: | Line 19: |
| == APL Code == To enter a block of APL code: |
== APL's Original Concept is Still Valid == |
| Line 26: | Line 21: |
| {{{ Prim←{{⍵/⍨2=+⌿0=⍵∘.|⍵}⍳⍵} Prim 10 2 3 5 7 }}} Note that a blank at the beginning provokes indention as it does with ordinary paragraphs: |
Too often we take for granted APL's genesis as a tool for communication between people, and the value of all the thought and practice that was put in before any executable APL became a reality. This has given us an intellectual solidity that's absent in much of computing. It's at our peril that we stray from the guiding principles handed down by the likes of Iverson and Falkoff in the interests of "convenience". Not only in the language itself, but in how we use it when we develop our applications. |
| Line 33: | Line 23: |
| . {{{ Prim←{{⍵/⍨2=+⌿0=⍵∘.|⍵}⍳⍵} Prim 10 2 3 5 7 }}} |
== There's Room for the Professional APLer == |
| Line 39: | Line 25: |
| == Links == There are all sorts of different links available. See HelpOnLinking for all details. The most common links can be divided into three categroies: |
There's been a lot of talk about "domain experts" and "domain-specific languages". Which seems in danger of belittling the professional APLer. There's a role there, doing things like creating introductory material; offering consultancy services to make domain-generated software robust, maintainable and speedy. |
| Line 42: | Line 27: |
| * '''Local links''', e.g. links to pages within the same wiki * '''Interwiki links''', e.g. links to pages in other wikis * '''Ordinary links''', e.g. links to other places on the web |
That's all from me for the nonce, let's see if this essay can mutate into something useful. I'd rather be "doing stuff" than writing about it. |
| Line 46: | Line 29: |
| === Local Links === ==== CamelCase links ==== By using !CamelCase one creates an '''''implicit ''''' or '''''automatic''''' link in !MoinMoin. This is by far the easiest way to create a link. ==== Pages with blanks in their name ==== If their is a page with the name "This is a valid Page name", you can link to it: [[This is a valid Page name]] ==== Other local links ==== This is an example of a [[SamplePage|fully-fledged description]] (don't click at this link!) of where a link will point to but without showing the page name at all. This kind of link is called a '''free link'''. === Interwiki links === To link to the APL-related page in the Wikipedia: WikiPedia:APL_programming_language This can also be a free link: [[WikiPedia:APL_programming_language|Information about APL in the Wikipedia]] === Ordinary links === If you want the URL itself to be the link text: http://www.vector.org.uk/ Or as a free link: [[http://www.vector.org.uk/|Vector, the respected magazine of BAA]] === Preventing links === The fact that !CamelCasing creates a link automatically is sometimes unwanted. For example, when you refer to the software package !SubVersion, you might or might not want it to become a link. == Bold, italic und stuff == This is '''bold''', this is ''italic'' and this is '''''both'''''. You can also --(cross out)-- pieces of text; nice feature to emphasize a change. == Lists == Note the blank at the beginning of each line in the editor - won't work without it! === Ordered Lists === 1. First entry 1. Second entry === Unordered Lists === * An entry * Another entry == Tables == Table are not exactly easy in !MoinMoin I am afraid. ||||||||<rowclass="odd">'''Main Customers''' || ||VW ||Germany || ||<rowclass="odd">BMW ||Germany || ||Vauxhall ||UK || ||<rowclass="odd">Toyota ||Japan || ||Saab ||Sweden || == Headings == === Sub Headings === ==== Sub-sub Headings ==== |
A Positive Outlook for APL
A lot of the content of sites like comp.lang.apl is very depressing, and must surely generate a poor impression of APL is stumbled upon by the curious or new-to-APL.
I personally think that the future for APL can be very positive, but we need to generate a positive attitude in the things we say and write. Here are a few random seeds - please feel free to amend and append as you wish.
The Future is More Valuable than the Past
Let's stop all of the "when I were a lad and remember how I dropped the card deck for APL-1130" reminiscences. Nobody cares unless they were there. Forever falling into this mode helps people who want to think of APL in the past tense. The Wikipedia entry on APL is a particular disgrace (and control of its content seems to lie with people who know nothing of APL).
There's Nothing Wrong with Being Replaced
One of APL's great strengths has to have been that it has allowed people to formulate software solutions without having to concern themselves with computer architecture. If the solutions crystalise into "products" or "business-critical infrastructure", there's no harm in handing them over to other specialists - doing this frees the innovators to move on and address new problem areas.
We are Already Interoperating with Other Software
Not only is APL portable across platforms, we are already handling matters like extracting data from corporate databases. Harangues about how we need to develop bridges to things like SQL are doing APL a disservice, we are already doing it (but not necessarily telling the world).
APL's Original Concept is Still Valid
Too often we take for granted APL's genesis as a tool for communication between people, and the value of all the thought and practice that was put in before any executable APL became a reality. This has given us an intellectual solidity that's absent in much of computing. It's at our peril that we stray from the guiding principles handed down by the likes of Iverson and Falkoff in the interests of "convenience". Not only in the language itself, but in how we use it when we develop our applications.
There's Room for the Professional APLer
There's been a lot of talk about "domain experts" and "domain-specific languages". Which seems in danger of belittling the professional APLer. There's a role there, doing things like creating introductory material; offering consultancy services to make domain-generated software robust, maintainable and speedy.
That's all from me for the nonce, let's see if this essay can mutate into something useful. I'd rather be "doing stuff" than writing about it.