text:
Computer Programming/Functional programming

Functional programming is a paradigm that treats computer programs as mathematical functions. When programming in a pure functional style, we do not manipulate states and variables (things that change value), but focus entirely on constants and functions (things that never change). Another distinguishing feature of functional programming (FP) is that functions are treated as first class citizens. Programs written in a functional style often consist of functions that take other functions as input. This is a key feature of FP languages because it makes it very easy to build modular programs. The result is that software written in FP languages tend to be very concise. Indeed, one group of programmers in Utrecht University was able to build a tool for "constructing, editing and analyzing Bayesian networks" in only 10 000 lines of Haskell code, graphical interface included. An equivalent program in Java took 200 000 lines, twenty times as much.

Want to learn more? You could
 * See functional programming /At a glance/ just to have a quick overview
 * Visit the wikibook for a functional programming language, for example, Haskell (see also Scheme and Common Lisp).
 * Read the article below (which is aimed at programmers from an imperative background)

See also Procedural programming.

Introduction
Programmers are procrastinators. Get in, get some coffee, check the mailbox, read the RSS feeds, read the news, check out latest articles on technical websites, browse through political discussions on the designated sections of the programming forums. Rinse and repeat to make sure nothing is missed. Go to lunch. Come back, stare at the IDE for a few minutes. Check the mailbox. Get some coffee. Before you know it, the day is over.

The only thing, every once in a while challenging articles actually do pop up. If you're looking at the right places you'll find at least one of these every couple of days. These articles are hard to get through and take some time, so they start piling up. Before you know it, you have a list of links and a folder full of PDF files and you wish you had a year in a small hut in the middle of the forest with nobody around for miles so you could catch up. Would be nice if someone came in every morning while you're taking a walk down the river to bring some food and take out the garbage.

I don't know about your list, but a large chunk of the articles in mine are about functional programming. These generally are the hardest to get through. Written in a dry academic language, even the "ten year Wall Street industry veterans" don't understand what functional programming (also referred to as FP) articles are all about. If you ask a project manager in Citi Group or in Deutsche Bank1 why they chose to use JMS instead of Erlang they'll say they can't use academic languages for industrial strength applications. The problem is, some of the most complex systems with the most rigid requirements are written using functional programming elements. Something doesn't add up.

It's true that FP articles and papers are hard to understand, but they don't have to be. The reasons for the knowledge gap are purely historical. There is nothing inherently hard about FP concepts. Consider this article "an accessible guide to FP", a bridge from our imperative minds into the world of FP. Grab a coffee and keep on reading. With any luck your coworkers will start making fun of you for your FP comments in no time.

So what is FP? How did it come about? Is it edible? If it's as useful as its advocates claim, why isn't it being used more often in the industry? Why is it that only people with PhDs tend to use it? Most importantly, why is it so damn hard to learn? What is all this closure, continuation, currying, lazy evaluation and no side effects business? How can it be used in projects that don't involve a university? Why does it seem to be so different from everything good, and holy, and dear to our imperative hearts? We'll clear this up very soon. Let's start with explaining the reasons for the huge gap between the real world and academic articles. The answer is as easy as taking a walk in the park.

A Walk In The Park
Fire up the time machine. Our walk in the park took place more than two thousand years ago, on a beautiful sunny day of a long forgotten spring in 380 B.C. Outside the city walls of Athens, under the pleasant shade of olive trees Plato was walking towards the Academy with a beautiful slave boy. The weather was lovely, the dinner was filling, and the conversation turned to philosophy.

"Look at these two students", said Plato carefully picking words to make the question educational. "Who do you think is taller?" The slave boy looked towards the basin of water where two men were standing. "They're about the same height", he said. "What do you mean 'about the same'?", asked Plato. "Well, they look the same from here but I'm sure if I were to get closer I'd see that there is some difference."

Plato smiled. He was leading the boy in the right direction. "So you would say that there is nothing perfectly equal in our world?" After some thinking the boy replied: "I don't think so. Everything is at least a little different, even if we can't see it." The point hit home! "Then if nothing is perfectly equal in this world, how do you think you understand the concept of 'perfect' equality?" The slave boy looked puzzled. "I don't know", he replied.

So was born the first attempt to understand the nature of mathematics. Plato suggested that everything in our world is just an approximation of perfection. He also realized that we understand the concept of perfection even though we never encountered it. He came to conclusion that perfect mathematical forms must live in another world and that we somehow know about them by having a connection to that "alternative" universe. It's fairly clear that there is no perfect circle that we can observe. But we also understand what a perfect circle is and can describe it via equations. What is mathematics, then? Why is the universe described with mathematical laws? Can all of the phenomena of our universe be described by mathematics?2

Philosophy of mathematics is a very complex subject. Like most philosophical disciplines it is far more adept at posing questions rather than providing answers. Much of the consensus revolves around the fact that mathematics is really a puzzle: we set up a set of basic non-conflicting principles and a set of rules on how to operate with these principles. We can then stack these rules together to come up with more complex rules. Mathematicians call this method a "formal system" or a "calculus". We can effectively write a formal system for Tetris if we wanted to. In fact, a working implementation of Tetris is a formal system, just specified using an unusual representation.

A civilization of furry creatures on Alpha Centauri would not be able to read our formalisms of Tetris and circles because their only sensory input might be an organ that senses smells. They likely will never find out about the Tetris formalism, but they very well might have a formalism for circles. We probably wouldn't be able to read it because our sense of smell isn't that sophisticated, but once you get past the representation of the formalism (via various sensory instruments and standard code breaking techniques to understand the language), the concepts underneath are understandable to any intelligent civilization.

Interestingly if no intelligent civilization ever existed in the universe the formalisms for Tetris and circles would still hold water, it's just that nobody would be around to find out about them. If an intelligent civilization popped up, it would likely discover some formalisms that help describe the laws of our universe. They also would be very unlikely to ever find out about Tetris because there is nothing in the universe that resembles it. Tetris is one of countless examples of a formal system, a puzzle, that has nothing to do with the real world. We can't even be sure that natural numbers have full resemblance to the real world, after all one can easily think of a number so big that it cannot describe anything in our universe since it might actually turn out to be finite.

A Bit of History3
Let's shift gears in our time machine. This time we'll travel a lot closer, to the 1930s. The Great Depression was ravaging the New and the Old worlds. Almost every family from every social class was affected by the tremendous economic downturn. Very few sanctuaries remained where people were safe from the perils of poverty. Few people were fortunate enough to be in these sanctuaries, but they did exist. Our interest lies in mathematicians in Princeton University.

The new offices constructed in Gothic style gave Princeton an aura of a safe haven. Logicians from all over the world were invited to Princeton to build out a new department. While most of America couldn't find a piece of bread for dinner, high ceilings, walls covered with elaborately carved wood, daily discussions by a cup of tea, and walks in the forest were some of the conditions in Princeton.

One mathematician living in such lavish lifestyle was a young man named Alonzo Church. Alonzo received a B.S. degree from Princeton and was persuaded to stay for graduate school. Alonzo felt the architecture was fancier than necessary. He rarely showed up to discuss mathematics with a cup of tea and he didn't enjoy the walks in the woods. Alonzo was a loner: he was most productive when working on his own. Nevertheless Alonzo had regular contacts with other Princeton inhabitants. Among them were Alan Turing, John von Neumann, and Kurt Gödel.

The four men were interested in formal systems. They didn't pay much heed to the physical world, they were interested in dealing with abstract mathematical puzzles instead. Their puzzles had something in common: the men were working on answering questions about computation. If we had machines that had infinite computational power, what problems would we be able to solve? Could we solve them automatically? Could some problems remain unsolved and why? Would various machines with different designs be equal in power?

In cooperation with other men Alonzo Church developed a formal system called lambda calculus. The system was essentially a programming language for one of these imaginary machines. It was based on functions that took other functions as parameters and returned functions as results. The function was identified by a Greek letter lambda, hence the system's name4. Using this formalism Alonzo was able to reason about many of the above questions and provide conclusive answers.

Independently of Alonzo Church, Alan Turing was performing similar work. He developed a different formalism (now referred to as the Turing machine), and used it to independently come to similar conclusions as Alonzo. Later it was shown that Turing machines and lambda calculus were equivalent in power.

This is where the story would stop, I'd wrap up the article, and you'd navigate to another page, if not for the beginning of World War II. The world was in flames. The U.S. Army and Navy used artillery more often than ever. In attempts to improve accuracy the Army employed a large group of mathematicians to continuously calculate differential equations required for solving ballistic firing tables. It was becoming obvious that the task was too great for being solved manually and various equipment was developed in order to overcome this problem. The first machine to solve ballistic tables was a Mark I built by IBM - it weighed five tons, had 750,000 parts and could do three operations per second.

The race, of course, wasn't over. In 1949 an Electronic Discrete Variable Automatic Computer (EDVAC) was unveiled and had tremendous success. It was a first example of von Neumann's architecture and was effectively a real world implementation of a Turing machine. For the time being Alonzo Church was out of luck.

In late 1950s an MIT professor John McCarthy (also a Princeton graduate) developed interest in Alonzo Church's work. In 1958 he unveiled a List Processing language (Lisp). Lisp was an implementation of Alonzo's lambda calculus that worked on von Neumann computers! Many computer scientists recognized the expressive power of Lisp. In 1973 a group of programmers at MIT's Artificial Intelligence Lab developed hardware they called a Lisp machine - effectively a native hardware implementation of Alonzo's lambda calculus!

Functional Programming
Functional programming is a practical implementation of Alonzo Church's ideas. Not all lambda calculus ideas transform to practice because lambda calculus was not designed to work under physical limitations. Therefore, like object oriented programming, functional programming is a set of ideas, not a set of strict guidelines. There are many functional programming languages, and most of them do many things very differently. In this article I will explain the most widely used ideas from functional languages using examples written in Java (yes, you could write functional programs in Java if you felt particularly masochistic). In the next couple of sections we'll take Java as is, and will make modifications to it to transform it into a usable functional language. Let's begin our quest.

Lambda calculus was designed to investigate problems related to calculation. Functional programming, therefore, primarily deals with calculation, and, surprisingly, uses functions to do so. A function is a very basic unit in functional programming. Functions are used for almost everything, even the simplest of calculations. Even variables are replaced with functions. In functional programming variables are simply aliases for expressions (so we don't have to type everything on one line). They cannot be modified. All variables can only be assigned to once. In Java terms this means that every single variable is declared as final (or const if we're dealing with C++). There are no non-final variables in FP. final int i = 5; final int j = i + 3;

Since every variable in FP is final two fairly interesting statements can be made. It does not make sense to always write the keyword final and it does not make sense to call variables, well... variables. We will now make two modifications to Java: every variable declared in our functional Java will be final by default, and we will refer to variables as symbols.

By now you are probably wondering how you could possibly write anything reasonably complicated in our newly created language. If every symbol is non-mutable we cannot change the state of anything! This isn't strictly true. When Alonzo was working on lambda calculus he wasn't interested in maintaining state over periods of time in order to modify it later. He was interested in performing operations on data (also commonly referred to as "calculating stuff"). However, it was proved that lambda calculus is equivalent to a Turing machine. It can do all the same things an imperative programming language can. How, then, can we achieve the same results?

It turns out that functional programs can keep state, except they don't use variables to do it. They use functions instead. The state is kept in function parameters, on the stack. If you want to keep state for a while and every now and then modify it, you write a recursive function. As an example, let's write a function that reverses a Java string. Remember, every variable we declare is final by default5.

String reverse(String arg) { if(arg.length == 0) { return arg; }    else { return reverse(arg.substring(1, arg.length)) + arg.substring(0, 1); } }

This function is slow because it repeatedly calls itself6. It's a memory hog because it repeatedly allocates objects. But it's functional in style. You may be interested why someone would want to program in this manner. Well, I was just about to tell you.

Benefits of FP
You're probably thinking that there's no way I can rationalize the monstrosity of a function above. When I was learning functional programming I was thinking that too. I was wrong. There are very good arguments for using this style. Some of them are subjective. For example, people claim that functional programs are easier to understand. I will leave out these arguments because every kid on the block knows that ease of understanding is in the eye of the beholder. Fortunately for me, there are plenty of objective arguments.

Unit Testing
Since every symbol in FP is final, no function can ever cause side effects. You can never modify things in place, nor can one function modify a value outside of its scope for another function to use (like a class member or a global variable). That means that the only effect of evaluating a function is its return value and the only thing that affects the return value of a function is its arguments.

This is something unit testers will find very useful. You can test every function in your program only worrying about its arguments. You don't have to worry about calling functions in the right order, or setting up external state properly. This means you can spend less time worrying about writing mocks, stubs and other forms of fake objects and less time verifying that setup and tear down methods are run by the test suite. All you need to do is pass arguments that represent edge cases. If every function in your program passes unit tests you can be a lot more confident about quality of your software than if you were using an imperative language. In Java or C++ checking a return value of a function is not sufficient - it may modify external state that we would need to verify. Not so in a functional language.

Debugging
If a functional program doesn't behave the way you expect it to, debugging it is a breeze. You will always be able to reproduce your problem because a bug in a functional program doesn't depend on unrelated code paths that were executed before it. In an imperative program a bug resurfaces only some of the time. Because functions depend on external state produced by side effects from other functions you may have to go through a series of steps in no way related to the bug. In a functional program this isn't the case - if a return value of a function is wrong, it is always wrong, regardless of what code you execute before running the function.

Once you reproduce the problem, getting to the bottom of it is trivial. It is almost pleasant. You break the execution of your program and examine the stack. Every argument in every function call in the stack is available for your inspection, just like in an imperative program. Except in an imperative program that's not enough because functions depend on member variables, global variables, and the state of other classes (which in turn depend on these very same things). A function in a functional program depends only on its arguments, and that information is right before your eyes! Furthermore, in an imperative program examining a return value of a function will not give you a good idea of whether the function behaves properly. You need to hunt down dozens of objects outside its scope to verify that it performed correct actions. In a functional program all you have to do is look at the return value!

Walking through the stack you look at arguments passed to functions and their return values. The minute a return value doesn't make sense you step into the offending function and walk through it. You repeat this recursively until the process leads you to the source of the bug!

Concurrency
A functional program is ready for concurrency without any further modifications. You never have to worry about deadlocks and race conditions because you don't need to use locks! No piece of data in a functional program is modified twice by the same thread, let alone by two different threads. That means you can easily add threads without ever giving conventional problems that plague concurrency applications a second thought!

If this is the case, why doesn't anybody use functional programs for highly concurrent applications? Well, it turns out that they do. Ericsson designed a functional language called Erlang for use in its highly tolerant and scalable telecommunication switches. Many others recognized the benefits provided by Erlang and started using it. We're talking about telecommunication and traffic control systems that are far more scalable and reliable than typical systems designed on Wall Street. Erlang systems are simply rock solid.

The concurrency story doesn't stop here. If your application is inherently single threaded the compiler can still optimize functional programs to run on multiple CPUs. Take a look at the following code fragment:

String s1 = somewhatLongOperation1; String s2 = somewhatLongOperation2; String s3 = concatenate(s1, s2);

In a functional language the compiler could analyze the code, classify the functions that create strings s1 and s2 as potentially time consuming operations, and run them concurrently. This is impossible to do in an imperative language because each function may modify state outside of its scope and the function following it may depend on it. In functional languages automatic analysis of functions and finding good candidates for concurrent execution is as trivial as automatic inlining! In this sense functional style programs are "future proof" (as much as I hate buzzwords, I'll indulge this time). Hardware manufacturers can no longer make CPUs run any faster. Instead they increase the number of cores and attribute quadruple speed increases to concurrency. Of course they conveniently forget to mention that we get our money's worth only on software that deals with parallelization problems. This is a very small fraction of imperative software but 100% of functional software because functional programs all support parallelization out of the box.

Hot Code Deployment
In the old days of Windows in order to install updates it was necessary to restart the computer. Many times. After installing a newer version of a media player. With Windows XP the situation has improved significantly, yet it still isn't ideal (I ran Windows Update at work today and now an annoying system tray icon won't go away until I restart). Unix systems have had a better model for a while. In order to install an update you only need to stop relevant components, not the whole OS. While it is a better situation, for a large class of server applications it still isn't acceptable. Telecommunication systems need to be up 100% of the time because if dialing emergency is not available due to upgrades, lives may be lost. There is no reason Wall Street firms need to bring down their systems to install software updates over the weekend.

An ideal situation is updating relevant parts of the code without stopping any part of the system at all. In an imperative world this isn't possible. Consider unloading a Java class at runtime and reloading a new definition. If we were to do that every instance of a class would become unusable because the state it holds would be lost. We would need to resort to writing tricky version control code. We'd need to serialize all running instances of the class, destroy them, create instances of the new class, try to load serialized data into them hoping the loading code properly migrates the data to work with the new instance. On top of that, every time we change something we'd have to write our migration code manually. And our migration code would have to take special care not to break relationships between objects. Nice in theory, but would never work well in practice.

In a functional program all state is stored on the stack in the arguments passed to functions. This makes hot deployment significantly easier! In fact, all we'd really have to do is run a diff between the code in production and the new version, and deploy the new code. The rest could be done by language tools automatically! If you think this is science fiction, think again. Erlang engineers have been upgrading live systems without stopping them for years.

Machine Assisted Proofs and Optimizations
An interesting property of functional languages is that they can be reasoned about mathematically. Since a functional language is simply an implementation of a formal system, all mathematical operations that could be done on paper still apply to the programs written in that language. The compiler could, for example, convert pieces of code into equivalent but more efficient pieces with a mathematical proof that two pieces of code are equivalent7. Relational databases have been performing these optimizations for years. There is no reason the same techniques can't apply to regular software.

Additionally, you can use these techniques to prove that parts of your program are correct. It is even possible to create tools that analyze code and generate edge cases for unit tests automatically! This functionality is invaluable for rock solid systems. If you are designing pace makers and air traffic control systems such tools are almost always a requirement. If you are writing an application outside of truly mission critical industries, these tools can give you a tremendous edge over your competitors.

Higher Order Functions
I remember learning about the benefits I outlined above and thinking "that's all very nice but it's useless if I have to program in a crippled language where everything is final." This was a misconception. Making all variables final is crippled in a context of an imperative language like Java but it isn't in a context of functional languages. Functional languages offer a different kind of abstraction tools that make you forget you've ever liked modifying variables. One such tool is capability to work with higher order functions.

A function in such languages is different from a function in Java or C. It is a superset - it can do all the things a Java function can do, and more. We create a function in the same manner we do in C:

int add(int i, int j) { return i + j; }

This means something different from equivalent C code. Let's extend our Java compiler to support this notation. When we type something like this our compiler will convert it to the following Java code (don't forget, everything is final):

class add_function_t { int add(int i, int j) { return i + j;    } } add_function_t add = new add_function_t;

The symbol add isn't really a function. It is a small class with one function as its member. We can now pass add around in our code as an argument to other functions. We can assign it to another symbol. We can create instances of add_function_t at runtime and they will be garbage collected when we no longer need them. This makes functions first class objects no different from integers or strings. Functions that operate on other functions (accept them as arguments) are called higher order functions. Don't let this term intimidate you, it's no different from Java classes that operate on each other (we can pass class instances to other classes). We can call them "higher order classes" but nobody cares to because there is no strong academic community behind Java.

How, and when, do you use higher order functions? Well, I'm glad you asked. You write your program as a big monolithic blob of code without worrying about class hierarchies. When you see that a particular piece of code is repeated, you break it out into a function (fortunately they still teach this in schools). If you see that a piece of logic within your function needs to behave differently in different situations, you break it out into a higher order function. Confused? Here's a real life example from my work.

Suppose we have a piece of Java code that receives a message, transforms it in various ways, and forwards it to another server. class MessageHandler { void handleMessage(Message msg) { // ...        msg.setClientCode("ABCD_123"); // ...        sendMessage(msg); }    // ... }

Now imagine that our system has changed and we now route messages to two servers instead of one. Everything is handled in exactly the same way except the client code - the second server wants it in a different format. How do we handle this situation? We could check where the message is headed and format the client code differently, like this: class MessageHandler { void handleMessage(Message msg) { // ...        if(msg.getDestination.equals("server1") {             msg.setClientCode("ABCD_123");         } else {             msg.setClientCode("123_ABC");         }         // ...         sendMessage(msg);     }     // ... }

This approach, however, isn't scalable. If more servers are added our function will grow linearly and we'll have a nightmare updating it. An object oriented approach is to make MessageHandler a base class and specialize the client code operation in derived classes: abstract class MessageHandler { void handleMessage(Message msg) { // ...        msg.setClientCode(getClientCode); // ...        sendMessage(msg); }    abstract String getClientCode; // ... } class MessageHandlerOne extends MessageHandler { String getClientCode { return "ABCD_123"; } } class MessageHandlerTwo extends MessageHandler { String getClientCode { return "123_ABCD"; } }

We can now instantiate an appropriate class for each server. Adding servers becomes much more maintainable. That's a lot of code for such a simple modification though. We have to create two new types just to support different client codes! Now let's do the same thing in our language that supports higher order functions: class MessageHandler { void handleMessage(Message msg, Function getClientCode) { // ...        Message msg1 = msg.setClientCode(getClientCode); // ...        sendMessage(msg1); }    // ... } String getClientCodeOne { return "ABCD_123"; } String getClientCodeTwo { return "123_ABCD"; } MessageHandler handler = new MessageHandler; handler.handleMessage(someMsg, getClientCodeOne);

We've created no new types and no class hierarchy. We simply pass appropriate functions as a parameter. We've achieved the same thing as the object oriented counterpart with a number of advantages. We don't restrict ourselves to class hierarchies: we can pass new functions at runtime and change them at any time with a much higher degree of granularity with less code. Effectively the compiler has written object oriented "glue" code for us! In addition we get all the other benefits of FP. Of course the abstractions provided by functional languages don't stop here. Higher order functions are just the beginning.

Currying
Most people I've met have read the Design Patterns book by the Gang of Four. Any self respecting programmer will tell you that the book is language agnostic and the patterns apply to software engineering in general, regardless of which language you use. This is a noble claim. Unfortunately it is far removed from the truth.

Functional languages are extremely expressive. In a functional language one does not need design patterns because the language is likely so high level, you end up programming in concepts that eliminate design patterns all together. Once such pattern is an Adapter pattern (how is it different from Facade again? Sounds like somebody needed to fill more pages to satisfy their contract). It is eliminated once a language supports a technique called currying.

Adapter pattern is best known when applied to the "default" abstraction unit in Java - a class. In functional languages the pattern is applied to functions. The pattern takes an interface and transforms it to another interface someone else expects. Here's an example of an adapter pattern: int pow(int i, int j); int square(int i) { return pow(i, 2); }

The code above adapts an interface of a function that raises an integer to an integer power to an interface of a function that squares an integer. In academic circles this trivial technique is called currying (after a logician Haskell Curry who performed mathematical acrobatics necessary to formalize it). Because in FP functions (as opposed to classes) are passed around as arguments, currying is used very often to adapt functions to an interface that someone else expects. Since the interface to functions is its arguments, currying is used to reduce the number of arguments (like in the example above).

Functional languages come with this technique built in. You don't need to manually create a function that wraps the original, functional languages will do that for you. As usual, let's extend our language to support this technique. square = int pow(int i, 2);

This will automatically create a function square for us with one argument. It will call pow function with the second argument set to 2. This will get compiled to the following Java code: class square_function_t { int square(int i) { return pow(i, 2); } } square_function_t square = new square_function_t;

As you can see, we've simply created a wrapper for the original function. In FP currying is just that - a shortcut to quickly and easily create wrappers. You concentrate on your task, and the compiler writes the appropriate code for you! When do you use currying? This should be easy. Any time you'd like to use an adapter pattern (a wrapper).

Lazy Evaluation
Lazy (or delayed) evaluation is an interesting technique that becomes possible once we adopt a functional philosophy. We've already seen the following piece of code when we were talking about concurrency:

String s1 = somewhatLongOperation1; String s2 = somewhatLongOperation2; String s3 = concatenate(s1, s2);

In an imperative language the order of evaluation would be clear. Because each function may affect or depend on an external state it would be necessary to execute them in order: first somewhatLongOperation1, then somewhatLongOperation2, followed by concatenate. Not so in functional languages.

As we saw earlier somewhatLongOperation1 and somewhatLongOperation2 can be executed concurrently because we're guaranteed no function affects or depends on global state. But what if we don't want to run the two concurrently, do we need to run them in order? The answer is no. We only need to run these operations when another function depends on s1 and s2. We don't even have to run them before concatenate is called - we can delay their evaluation until they're required within concatenate. If we replace concatenate with a function that has a conditional and uses only one of its two parameters we may never evaluate one of the parameters at all! Haskell is an example of a delayed evaluation language. In Haskell you are not guaranteed that anything will be executed in order (or at all) because Haskell only executes code when it's required.

Lazy evaluation has numerous advantages as well as disadvantages. We will discuss the advantages here and will explain how to counter the disadvantages in the next section.

Optimization
Lazy evaluation provides a tremendous potential for optimizations. A lazy compiler thinks of functional code exactly as mathematicians think of an algebra expression - it can cancel things out and completely prevent execution, rearrange pieces of code for higher efficiency, even arrange code in a way that reduces errors, all guaranteeing optimizations won't break the code. This is the biggest benefit of representing programs strictly using formal primitives - code adheres to mathematical laws and can be reasoned about mathematically.

Abstracting Control Structures
Lazy evaluation provides a higher order of abstraction that allows implementing things in a way that would otherwise be impossible. For example consider implementing the following control structure: unless(stock.isEuropean) { sendToSEC(stock); }

We want sendToSEC executed unless the stock is European. How can we implement unless? Without lazy evaluation we'd need some form of a macro system, but in a language like Haskell that's unnecessary. We can implement unless as a function! void unless(boolean condition, List code) { if(!condition) code; }

Note that code is never evaluated if the condition is true. We cannot reproduce this behavior in a strict language because the arguments would be evaluated before unless is entered.

Infinite Data Structures
Lazy languages allow for definition of infinite data structures, something that's much more complicated in a strict language. For example, consider a list with Fibonacci numbers. We clearly can't compute an infinite list in a reasonable amount of time or store it in memory. In strict languages like Java we simply define a Fibonacci function that returns a particular member from the sequence. In a language like Haskell we can abstract it further and simply define an infinite list of Fibonacci numbers. Because the language is lazy, only the necessary parts of the list that are actually used by the program are ever evaluated. This allows for abstracting a lot of problems and looking at them from a higher level (for example, we can use list processing functions on an infinite list).

Disadvantages
Of course there ain't no such thing as a free lunch™. (Unless you're lucky.) It seems that lazy evaluation comes with a number of disadvantages. Mainly that it is, well, lazy, and sometimes doesn't allow the programmer to also be so to their heart's content, meaning, you need to employ some workarounds in certain cases. There are real world problems that require strict evaluation. For example consider the following: System.out.println("Please enter your name: "); System.in.readLine;

In a lazy language you have no guarantee that the first line will be executed before the second! This means, if laziness were an absolute principle, we wouldn't be able to do IO, to use native functions in any meaningful way (because they need to be called in order since they depend on side effects), and couldn't interact with the outside world! If we were to introduce primitives that force ordered code execution we'd lose the ability of reasoning about our code mathematically (which would take all of the benefits of functional programming with it). Fortunately not all is lost. Mathematicians got to work and developed a number of tricks to ensure code gets executed in particular order in a functional setting. So we really get the best of both worlds! These techniques include continuations, monads, and uniqueness typing. In this article we'll only deal with continuations. We'll leave monads and uniqueness typing for another time. Interestingly, continuations are useful for many things other than enforcing a particular order of evaluation. We'll talk about that as well.

Continuations
Continuations to programming are what the Da Vinci Code supposedly is to human history: an amazing revelation of the greatest cover-up known to man. Well, maybe not, but they're certainly revealing of deceit in the same sense as square roots of negative numbers.

When we learned about functions we only learned half truths based on a faulty assumption that functions must return their value to the original caller. In this sense continuations are a generalization of functions. A function must not necessarily return to its caller and may return to any part of the program. A "continuation" is a parameter we may choose to pass to our function that specifies where the function should return. The description may be more complicated than it sounds. Take a look at the following code: int i = add(5, 10); int j = square(i);

The function add returns 15 to be assigned to i, the place where add was originally called. After that the value of i is used to call square. Note that a lazy compiler can't rearrange these lines of code because the second line depends on successful evaluation of the first. We can rewrite this code block using Continuation Passing Style or CPS, where the function add doesn't return to the original caller but instead returns its result to square. int j = add(5, 10, square);

In this case add gets another parameter - a function that add must call with its result upon completion. In this case square is a continuation of add. In both cases j will equal 225.

Here lays the first trick to force a lazy language to evaluate two expressions in order. Consider the following (familiar) IO code: System.out.println("Please enter your name: "); System.in.readLine;

The two lines don't depend on each other and the compiler is free to rearrange them as it wishes. However, if we rewrite this code in CPS, there will be a dependency and the compiler will be forced to evaluate the two lines in order! System.out.println("Please enter your name: ", System.in.readLine);

In this case println needs to call readLine with its result and return the result of readLine. This allows us to ensure that the two lines are executed in order and that readLine is evaluated at all (because the whole computation expects the last value as a result). In case of Java println returns void but if it were to return an abstract value (that readLine would accept), we'd solve our problem! Of course chaining function calls like that will quickly become unreadable, but it isn't necessary. We could add syntactic sugar to the language that will allow us to simply type expressions in order, and the compiler would chain the calls for us automatically. We can now evaluate expressions in any order we wish without losing any of the benefits of FP (including the ability to reason about our programs mathematically)! If this is still confusing, remember that a function is just an instance of a class with one member. Rewrite above two lines so that println and readLine are instances of classes and everything will become clear.

I would now wrap up this section, except that we've only scratched the surface of continuations and their usefulness. We can write entire programs in CPS, where every function takes an extra continuation argument and passes the result to it. We can also convert any program to CPS simply by treating functions as special cases of continuations (functions that always return to their caller). This conversion is trivial to do automatically (in fact, many compilers do just that).

Once we convert a program to CPS it becomes clear that every instruction has some continuation, a function it will call with the result, which in a regular program would be a place it must return to. Let's pick any instruction from above code, say add(5, 10). In a program written in CPS style it's clear what add's continuation is - it's a function that add calls once it's done. But what is it in a non-CPS program? We could, of course, convert the program to CPS, but do we have to?

It turns out that we don't. Look carefully at our CPS conversion. If you try to write a compiler for it and think about it long enough you'll realize that the CPS version needs no stack! No function ever "returns" in the traditional sense, it just calls another function with the result instead. We don't need to push function arguments on the stack with every call and then pop them back, we can simply store them in some block of memory and use a jump instruction instead. We'll never need the original arguments - they'll never be used again since no function ever returns!

So, programs written in CPS style have no stack but have an extra argument with a function to call. Programs not written in CPS style have no argument with a function to call, but have the stack instead. What does the stack contain? Simply the arguments, and a pointer to memory where the function should return. Do you see a light bulb? The stack simply contains continuation information! The pointer to the return instruction in the stack is essentially the same thing as the function to call in CPS programs! If you wanted to find out what continuation for add(5, 10) is, you'd simply have to examine the stack at the point of its execution!

So that was easy. A continuation and a pointer to the return instruction in the stack are really the same thing, only a continuation is passed explicitly, so that it doesn't need to be the same place where the function was called from. If you remember that a continuation is a function, and a function in our language is compiled to an instance of a class, you'll realize that a pointer to the return instruction in the stack and the continuation argument are really the same thing, since our function (just like an instance of a class) is simply a pointer. This means that at any given point in time in your program you can ask for a current continuation (which is simply the information on the stack).

Ok, so we know what a current continuation is. What does it mean? When we get a current continuation and store it somewhere, we end up storing the current state of our program - freezing it in time. This is similar to an OS putting itself into hibernation. A continuation object contains the information necessary to restart the program from the point where the continuation object was acquired. An operating system does this to your program all the time when it context switches between the threads. The only difference is that it keeps all the control. If you ask for a continuation object (in Scheme this is done by calling call-with-current-continuation function) you'll get an object that contains the current continuation - the stack (or in a CPS case the function to call next). You can store this object in a variable (or alternatively, on disk). When you choose to "restart" your program with this continuation object you will "transform" to the state of the program when you grabbed the continuation object. It's the same thing as switching back to a suspended thread or waking up an OS from hibernation, except you can do it again and again. When an OS wakes up, the hibernation information is destroyed. If it wasn't, you'd be able to wake up from the same point over and over again, almost like going back in time. You have that control with continuations!

In what situations are continuations useful? Usually when you're trying to simulate state in an application of inherently stateless nature to ease your life. A great application of continuations are web applications. Microsoft's ASP.NET goes to tremendous lengths to try and simulate state so that you can write your application with less hassle. If C# supported continuations half of ASP.NET's complexity would disappear - you'd simply store a continuation and restart it when a user makes the web request again. To a programmer of the web application there would be no interruption - the program would simply start from the next line! Continuations are an incredibly useful abstraction for some problems. Considering that many of the traditional fat clients are moving to the web, continuations will become more and more important in the future.

Pattern Matching
Pattern matching is not a new or innovative feature. In fact, it has little to do with functional programming. The only reason why it's usually attributed to FP is that functional languages have had pattern matching for some time, while modern imperative languages still don't.

Let's dive into pattern matching with an example. Here's a Fibonacci function in Java: int fib(int n) { if(n == 0) return 1; if(n == 1) return 1; return fib(n - 2) + fib(n - 1); }

And here's an example of a Fibonacci function in our Java-derived language that supports pattern matching: int fib(0) { return 1; } int fib(1) { return 1; } int fib(int n) { return fib(n - 2) + fib(n - 1); }

(Do not try with higher numbers since this algorithm isn't suited for higher numbers due to $$\mathcal{O}(2^n)$$ time complexity; fib(35) will already take a considerable amount of time)

What's the difference? The compiler implements branching for us.

What's the big deal? There isn't any. Someone noticed that a large number of functions contain very complicated switch statements (this is particularly true about functional programs) and decided that it's a good idea to abstract that away. We split the function definition into multiple ones, and put patterns in place of some arguments (sort of like overloading). When the function is called, the compiler compares the arguments with the definitions at runtime, and picks the correct one. This is usually done by picking the most specific definition available. For example, int fib(int n) can be called with n equal to 1, but it isn't because int fib(1) is more specific.

Another possibility, which you find in Haskell, is to check the patterns in the order they are defined (one of the few cases where the order of the expressions in a functional program matters, but most of your code can be written in any order you wish, which is very convenient.) For example, a function's argument might be tested against three patterns, fun (x < 100), fun (x < 1000), fun (x = anything), and when called with x = 50 the first instance of its definition will be used, although x = 50 also would fit the other two. (And in a mathematical sense, taking into account negative numbers, none of these definitions is more specific since the sets of matching patterns all have the same infinite size.) In this system you usually order your definitions so that the more specific ones come first, which automatically encompasses the other way of deciding which instance of the function will be used.

Pattern matching is usually more complex than our example reveals. For example, an advanced pattern matching system will allow us to do the following: int f(int n < 10) { ... } int f(int n) { ... }

When is pattern matching useful? In a surprisingly large number of cases! Every time you have a complex structure of nested ifs, pattern matching can do a better job with less code on your part. A good function that comes to mind is a standard WndProc function that all Win32 applications must provide (even though it's often abstracted away). Usually a pattern matching system can examine collections as well as simple values. For example, if you pass an array to your function you could pick out all arrays in which the first element is equal to 1 and the third element is greater than 3.

Another benefit of pattern matching is that if you need to add or modify conditions, you don't have to go into one huge function. You simply add (or modify) appropriate definitions. This eliminates the need for a whole range of design patterns from the Gang of Four book. The more complex your conditions are, the more pattern matching will help you. Once you're used to it, you start wondering how you ever got through your day without it.

Closures
So far we've discussed features in the context of "pure" functional languages - languages that are implementations of lambda calculus and don't include features that conflict with Church's formalism. However, many of the features of functional languages are useful outside of lambda calculus framework. While an implementation of an axiomatic system is useful because it allows thinking about programs in terms of mathematical expressions, it may or may not be practical. Many languages choose to incorporate functional elements without strictly adhering to functional doctrine. Many such languages (like Common Lisp) don't require variables to be final - you can modify things in place. They also don't require functions to depend only on their arguments - functions are allowed to access state outside of their boundaries. But they do include functional features - like higher order functions. Passing functions around in impure languages is a little bit different than doing it in the confines of lambda calculus and requires support for an interesting feature often referred to as lexical closure. Let's take a look at some sample code. Remember, in this case variables aren't final and functions can refer to variables outside of their scope: Function makePowerFn(int power) { int powerFn(int base) { return pow(base, power); }   return powerFn; } Function square = makePowerFn(2); square(3); // returns 9

The function makePowerFn returns a function that takes a single argument and raises it to a certain power. What happens when we try to evaluate square(3)? The variable power isn't anywhere in scope of powerFn because makePowerFn has returned and its stack is long gone. How can square work, then? The language must, somehow, store the value of power somewhere for square to work. What if we create another function, cube, that raises something to the third power? The runtime must now store two copies of power, one for each function we generated using makePowerFn. The phenomenon of storing these values is called a closure. Closures don't only store arguments of a host function. For example, a closure can look like this: Function makeIncrementer { int n = 0; int increment { return ++n; } } Function inc1 = makeIncrementer; Function inc2 = makeIncrementer; inc1; // returns 1; inc1; // returns 2; inc1; // returns 3; inc2; // returns 1; inc2; // returns 2; inc2; // returns 3;

The runtime manages to store n, so incrementers can access it. Furthermore, it stores various copies, one for each incrementer, even though they're supposed to disappear when makeIncrementer returns. What does this code compile to? How do closures work behind the scenes? Fortunately, we have a back stage pass.

A little common sense goes a long way. The first observation is that local variables are no longer limited to simple scope rules and have an undefined lifetime. The obvious conclusion is that they're no longer stored on the stack - they must be stored on the heap instead8. A closure, then, is implemented just like a function we discussed earlier, except that it has an additional reference to the surrounding variables: class some_function_t { SymbolTable parentScope; // ... }

When a closure references a variable that's not in its local scope, it consults this reference for a parent scope. That's it! Closures bring functional and OO worlds closer together. Every time you create a class that holds some state and pass it to somewhere else, think of closures. A closure is just an object that creates "member variables" on the fly by grabbing them from the scope, so you don't have to!

What's next?
This article only scratches the surface of functional programming. Sometimes a small scratch can progress to something bigger and in our case it's a good thing. In the future I plan to write about category theory, monads, functional data structures, type systems in functional languages, functional concurrency, functional databases and much more. If I get to write (and in the process learn) about half of these topics my life will be complete. In the meantime, Google is our friend.

Comments?
If you have any questions, comments, or suggestions, please drop a note at [mailto:coffeemug@gmail.com coffeemug@gmail.com]. I'll be glad to hear your feedback.

1When I was looking for a job in the fall of 2005 I often did ask this question. It's quite amusing how many blank stares I got. You would think that at about $300,000 a piece these people would at least have a good understanding of most tools available to them.

2This appears to be a controversial question. Physicists and mathematicians are forced to acknowledge that it isn't at all clear whether everything in the universe obeys the laws that can be described by mathematics.

3I've always hated history lessons that offer a dry chronology of dates, names, and events. To me history is about the lives of people who changed the world. It is about their private reasons behind their actions, and the mechanisms by which they affected millions of souls. For this reason this history section is hopelessly incomplete. Only very relevant people and events are discussed.

4When I was learning about functional programming I was very annoyed by the term "lambda" because I couldn't really understand what it really means. In this context lambda is a function, the single Greek letter was just easier to write in a mathematical notation. Every time you hear "lambda" when talking about functional programming just translate it in your mind to "function".

5Interestingly Java strings are immutable anyway. It's rather interesting to explore the reasons for this treachery, but that would distract us from our goal.

6Most functional language compilers optimize recursive functions by transforming them to their iterative alternatives whenever possible. This is called a tail call optimization.

7The opposite isn't always true. While it is sometimes possible to prove that two pieces of code are equivalent, it isn't possible in all situations.

8This is actually no slower than storing on the stack because once you introduce a garbage collector, memory allocation becomes an O(1) operation.


text:
Computer Programming/Functional programming/At a glance

Characteristics
for (i=0; i<100; i:=i+1) { /* do some stuff */} . In such cases we generally write recursive functions to do the same computation.
 * First-class functions. In functional languages, functions are just data, and can be passed to and returned from other functions as desired.
 * Immutability. In functional programming, the use of mutable variables is generally "discouraged", which is to say functional languages usually make the programmer go out of her way to create a variable whose value can change, or they disallow the practice altogether. While this may sound like an onerous restriction, in practice it has essentially no impact on the programs you can comfortably express; it turns out, rather, that the choice of using mutable or immutable variables is usually a matter of efficiency.
 * Recursion. Without mutable variables, we don't write loops like

Features
Here are some typical features of functional languages

 * tuples
 * parametric polymorphism
 * type inference
 * pattern matching
 * laziness

The languages
There are many so-called functional languages. The most widely used pure functional languages (that is, ones whose programs have no side effects) are Haskell and Erlang. Other popular functional languages which are not pure in the strict sense but still support the functional programming style in its full splendor are ML, Objective Caml, Scheme and Lisp.

license: Creative Commons - Attribution Share-Alike - https://creativecommons.org/licenses/by-sa/4.0/


text:
C Programming/Libraries

A library in C is a collection of header files, exposed for use by other programs. The library therefore consists of an interface expressed in a  file (named the "header") and an implementation expressed in a   file. This  file might be precompiled or otherwise inaccessible, or it might be available to the programmer. (Note: Libraries may call functions in other libraries such as the Standard C or math libraries to do various tasks.)

The format of a library varies with the operating system and compiler one is using. For example, in the Unix and Linux operating systems, a library consists of one or more object files, which consist of object code that is usually the output of a compiler (if the source language is C or something similar) or an assembler (if the source language is assembly language). These object files are then turned into a library in the form of an archive by the ar archiver (a program that takes files and stores them in a bigger file without regard to compression). The filename for the library usually starts with "lib" and ends with ".a"; e.g. the libc.a file contains the Standard C library and the "libm.a" the mathematics routines, which the linker would then link in. Other operating systems such as Microsoft Windows use a ".lib" extension for libraries and an ".obj" extension for object files. Some programs in the Unix environment such as lex and yacc generate C code that can be linked with the libl and liby libraries to create an executable.

We're going to use as an example a library that contains one function: a function to parse arguments from the command line. Arguments on the command line could be by themselves:

-i

have an optional argument that is concatenated to the letter:

-ioptarg

or have the argument in a separate argv-element:

-i optarg

The library also has four declarations that it exports in addition to the function: three integers and a pointer to the optional argument. If the argument does not have an optional argument, the pointer to the optional argument will be null.

In order to parse all these types of arguments, we have written the following "getopt.c" file:

The interface would be the following "getopt.h" file:

At a minimum, a programmer has the interface file to figure out how to use a library, although, in general, the library programmer also wrote documentation on how to use the library. In the above case, the documentation should say that the provided arguments  and   both shouldn't be null pointers (or why would you be using the   function anyway?). Specifically, it typically states what each parameter is for and what return values can be expected in which conditions. Programmers that use a library, are normally not interested in the implementation of the library -- unless the implementation has a bug, in which case he would want to complain somehow.

Both the implementation of the getopts library, and programs that use the library should state, in order to refer to the corresponding interface. Now the library is "linked" to the program -- the one that contains the main function. The program may refer to dozens of interfaces.

In some cases, just placing  may appear correct but will still fail to link properly. This indicates that the library is not installed correctly, or there may be some additional configuration required. You will have to check either the compiler's documentation or library's documentation on how to resolve this issue.

What to put in header files
As a general rule, headers should contain any declarations and macro definitions (preprocessor s) to be "seen" by the other modules in a program.

Possible declarations:
 * struct, union, and enum declarations
 * typedef declarations
 * external function declarations
 * global variable declarations

In the above  example file, one function  is declared and four global variables (,  ,  , and  ) are also declared. The variables are declared with the storage class specifier  in the header file because that keyword specifies that the "real" variables are stored elsewhere (i.e. the   file) and not within the header file.

The  trick is colloquially called include guards. This is used so that if the  file were included more than once in a translation unit, the unit would only see the contents once. Alternatively,  in a header file can also be used to achieve the same thing in some compilers (  is an unportable catchall).

Linking Libraries Into Executables
Linking libraries into executables varies by operating system and compiler/linker used. In Unix, directories of linked object files can be specified with the -L option to the cc command and individual libraries are specified with the -l (small ell) option. The -lm option specifies that the libm math library should be linked in, for example.

title: C Programming/Libraries


text:
User:TwinRiver

アバウトミィ
東京出身、東京在住の勉強のできない学生です. 2004年03月上旬より参加. 日本語の翻訳、作成を予定しています. …とは言っても自分もまだまだ勉強中の身(学生ですし). ですが…皆様よろしくお願いします<(_ _)>

指針…？？
とりあえず日本語：英語版の翻訳からこつこつとやって行きたいな、と思っています. 目処がついたら日本についての周辺知識やらなにやら、こつこつ増やしてみたいです.

title: User:TwinRiver


text:
User:Lesath~enwikibooks

Just editing some books in german, currently

Java

I like this project!

There is alway one indirection more you can think of...

title: User:Lesath~enwikibooks


text:
File:Work notstate Engineering Thermodynamics.png

work done


text:
File:Closed system Engineering Thermodynamics.png

closed system


text:
File:Joule Engineering Thermodynamics.png

Joule Temperature


text:
User:Nerd~enwikibooks

http://www.wikipedia.de/wiki/Benutzer:Nerd

title: User:Nerd~enwikibooks


text:
File:Throttling Engineering Thermodynamics.png

throttling


text: User:Vuara/Transcendental Meditation (MMY Gita)


text: User:Vuara/Cosmic Law (MMY Gita)

title: User:Vuara/Cosmic Law (MMY Gita)


text:
User:JaF893

Why did I join wikibooks? I joined wikibooks so that I could publish my A-level revision notes on the web and at the same time contribute to the open-source community. Most of my contributions to wikibooks are simply copies of my a-level notes only with greater detail. Hopefully, someone will find them useful. Why JaF893? JaF is my initials - my full name is Joseph Adam Farish. The 893 suffix comes from the japanese card game Oicho Kabu. Oicho Kabu is simillar to blackjack except that the aim is to get a total of 19. In Japanese, Ya means 8, ku means 9 and za means 3. Since 8+9+3 = 20, it is a worthless score. Similarly the Yakuza or Japanese mafia serve no purpose within Japanese scoiety.

Links

My Blog - Self explanatory Diamondback Rock - My Dad's band My Wiktionary - My 'sister' page on wiktionary Mozilla Firefox hints and tips - A useful hread on Overclockers UK with tips for using the Mozilla Firefox Browser.

title: User:JaF893


text:
Puzzles/Statistical puzzles

 * /3 Bags of Marbles/
 * /Summing n/
 * /The Pentagon/
 * Buffon's Needle
 * /A Bug Running/

title: Puzzles/Statistical puzzles


text:
Puzzles/Statistical puzzles/3 Bags of Marbles

Puzzles | Statistical puzzles | 3 Bags of Marbles

You have three bags, each containing two marbles. Bag #1 contains two white marbles, bag #2 contains two black marbles, and bag #3 contains one white marble and one black marble.

You pick a random bag and take out one marble. Given that this is a white marble, what is the probability that the remaining marble from the same bag is also white?

solution


text:
Puzzles/Statistical puzzles/3 Bags of Marbles/Solution

Puzzles | Statistical puzzles | Puzzles/Statistical puzzles/3 Bags of Marbles | Solution

2/3, or approximately 66.7%

Reasoning
The most common wrong answer is 50%. This is due to the misconception that you are given the information that you have picked either bag #1 or bag #3 [Challenge: This is not a misconception - This information is already provided in the question - a fact]. This is not the case, as explained below:

Label each of the marbles: bag 1 contains 1a and 1b, bag 2 contains 2a and 2b, and bag 3 contains 3a (white) and 3b (black). Because you picked a random bag and a random marble, each marble has an equal chance of being picked. Given that you picked a white marble, you have the following distribution:

First marble:
 * 1a: 1/3
 * 1b: 1/3
 * 2a: 0 (black ball was not picked)
 * 2b: 0 (black ball)
 * 3a: 1/3
 * 3b: 0 (black ball)

Given this information, we look at each situation:
 * 1a: You have picked bag #1, so the second marble must be 1b, a white marble.
 * 1b: You have picked bag #1, so the second marble must be 1a, a white marble.
 * 3a: You have picked bag #3, so the second marble must be 3b, a black marble.

If you are in the first two situations, your second marble will be a white marble, therefore, adding 1/3 and 1/3, you get 2/3 chance of getting a white marble

Note: This solution is INCORRECT - see the section titled "Correct Answer" below.

Algebraic explanation
Let W be the event of drawing a white marble, WW be the event of drawing from bag 1 (two white).

Then P(WW | W) = P(WW ∧ W) / P(W) = P(WW) / P(W) = (1/3) / (1/2) = 2/3.

'''Note: This is an algabraic representation of the INCORRECT solution above. Please see the "Correct Answer" section below.'''

Correct answer
Correct answer - 50% - is commonly considered wrong, but really - past events have no influence on future probabilities at all (You cannot count "You have picked bag #1" twice. You just either did it or not). Right now You have one white marble in your hand and knowledge, that another one is either black or white depending on which bag (out of two) you selected.

Challenge: You essentially just start by picking a marble--and there are three white marbles. Two of those white marbles are in the same bag as another white marble; so, given that you've picked one of the three white marbles, 2/3 of the time its pair matches--right?

Rebuttal: You're thinking about this wrong - since you picked a white marble, you know you have chosen from either bag #1 or bag #3. Now, there are only two possible outcomes - either you have bag #1, in which case the other marble is white, or bag #3 in which case it's black. And the probability is 50% that the other marble in your chosen bag is white.


text:
Korean/Lesson I1

Korean Conversation, Level I, Lesson 1: Greetings
Welcome to the first conversation lesson for learning Korean. By now you should be familiar with hangeul (the Korean writing system) and how to form syllables. If you are not yet familiar with hangeul, see Korean/Alphabet. It is highly recommended that you know these basics before you embark on learning how to make sentences and commencing dialogue.

In this first section, we will introduce basic Korean sentence structure, basic vocabulary, and greetings in Korean. Note that the following dialogue uses the formal, very polite -습니다/습니까 verb endings, which are appropriate for introduction into the Korean language, however, is seldom used within everyday conversation in Korea, save for several set phrases, such as thank you, excuse me, etc.

 * 시작할까요?
 * (Shall we start?)

Dialogue
The simple dialogue below is between Korean native 찬호 and Joseph (조세프) from America. Joseph is interested in Korean culture and language, and was able to meet 찬호 through a program in his school. Here, they meet for the first time:

 * 찬호: 안녕하십니까, 조세프 씨?
 * 조세프: 네. 안녕하십니까, 찬호 씨?
 * 찬호: 만나서 반갑습니다.
 * 조세프: 저도요. 저는 집에 갑니다.
 * 찬호: 네. 안녕히 가십시오.
 * 조세프: 안녕히 계십시오.

Overview
The conversation began with 찬호 asking this:

 * 찬호: 안녕하십니까, 조세프 씨?

Here, we learn our first bit of Korean. "안녕하십니까?" is a common formal greeting in Korean. It literally means "Are you at peace?". "씨" is a title which means "Mr". Joseph replied like this:

 * 조세프: 예. 안녕하십니까, 찬호 씨?

"예" means "yes". Then Joseph asked 찬호 the same question. Typically, the response to "안녕하십니까?" is "예", but it is not necessary to respond that way, as we learn from 찬호's response:

 * 찬호: 만나서 반갑습니다.

"만나서 반갑습니다" means "Nice to meet you." This can also be shortened to "반갑습니다", but since 찬호 and Joseph have first met, it is best to be as polite as possible. "만나서" means "because we've met".

 * 조세프: 저도요. 저는 집에 갑니다.

Here, we learn some important things about making a Korean sentence. "저" means "I," and "저도요" means "Me too". Then Joseph says: "저는 집에 갑니다." This means "I go home." We'll dissect this sentence more in just a moment. First, let us finish analyzing the conversation:

 * 찬호: 예. 안녕히 가십시오.
 * 조세프: 안녕히 계십시오.

Look carefully at how each says "Good bye" to each other. 찬호 says "안녕히 가십시오" while Joseph says "안녕히 계십시오" Why do their replies differ from each other? Well, Joseph is leaving, while it is assumed that 찬호 is staying. So, 찬호 tells Joseph to "Go in peace" (like spock!) and Joseph tells 찬호 to "Stay in peace." It may sound funny, but that's how it works in Korea. Remember these two carefully and try not to mix them up!

Grammar: "I go home."
The short sentence 저는 집에 갑니다 ("I go home.") reveals a great deal of usable grammar:

Let's discuss 는, 에, and 갑니다. As mentioned above, 저 means "I". In Korean, "는" marks the primary topic of a sentence. Joseph is talking primarily about himself, so he says "저는". Note that if the primary topic ends in a consonant, "는" changes to "은" so it's easier to pronounce. So, if Joseph wanted to talk primarily about his house (집) instead of himself, he would say "집은".

"에" is in a similar class of elements (called "particles"), but it marks the location, such as "to school (학교에), to the bathroom (화장실에)," and so forth. However, if Joseph wanted to say "to me", he would say "저에게", not "저에." The difference is that "에" means "to that thing or place" and "에게" (the dative particle) means "to that person." This is an important distinction to remember, but even if you make a mistake, a Korean will probably still understand.

Finally, we see the verb, "갑니다." Now, if you were to look up "go" in a Korean dictionary, it would probably say "가다." This is the verb's unconjugated dictionary or "base" form. "가" is the actual root of the verb, or "Verb Stem" (VS). When we put the verb into a Korean sentence, it must be conjugated. The standard, polite statement conjugation in Korean is {VS + ㅂ/습니다}. What does this mean? This means we take the verb stem (가) and add "ㅂ니다" if the stem ends in a vowel and "습니다" if the verb stem ends in a consonant. In this case, "가" ends in a vowel, so we slip the ㅂ under it (갑) and add "니다" = "갑니다". If the verb was "먹다 (to eat)" then we would add "습니다" because the verbstem ends in a consonant (먹). Thus, we have "먹습니다." A special thing to remember about this is, when conjugated, the verb is actually pronounced "감니다" like there's a ㅁ on the bottom. This is because of a special pronunciation rule called "nasalization" which we won't discuss here, but keep it in mind.

In order to make a question, the form is {VS + ㅂ/습니까}. An astute student would see something like that in "안녕하십니까", which is actually a question. So, if 찬호 wanted to ask "Do you go (are you going)?" he would ask "갑니까?" (Remember pronunciation: "감니까"). Armed with this information, we can now make a statement or a question with almost any verb.

Vocabulary: 어휘

 * 안녕하십니까? - a formal greeting
 * (만나서) 반갑습니다 - "Nice to meet you."
 * 안녕히 가십시오 - "Good bye" (to someone who is leaving)
 * 안녕히 계십시오 - "Good bye" (to someone who is staying)
 * 네 - "yes"
 * 아니요 - "no"
 * 저 - "I"
 * 집 - "house"
 * 학교 - "school"
 * 가다 - "to go"
 * 먹다 - "to eat"

Grammar: 문법

 * VS + ㅂ니까 - Question, use when VS ends in vowel (e.g.: 가 -> 갑니까)
 * VS + 습니까 - Question, use when VS ends in consonant (e.g.: 먹 -> 먹습니까)
 * VS + ㅂ니다 - Statement, when VS ends in vowel (e.g.: 가 -> 갑니다)
 * VS + 습니다 - Statement, when VS ends in consonant (e.g.: 먹 -> 먹습니다)
 * N + 은/는 - Topic particle (은use when N ends in consonant, 는use when N ends in vowel)
 * N + 에 - Location particle (to that thing/place)
 * N + 에게 - Dative particle (to that person)

Practice: 연습
Conjugate the following verbs into statement form (VS + ㅂ/습니다) and question form (VS + ㅂ/습니까?). Click "▶" to check your answers:

Determine whether the topic marker should be "은" or "는":

Determine whether the particle should be "에" or "에게":

title: Korean/Lesson I1


text:
Hindi/Introduction

हिन्दी

 The word "Hindi" written in Devanagari

Usage
While the language has emigrated to all parts of the world, the noteworthy use of the language is in its country of origin - India. A large number of languages and dialects are spoken there, and no single one is spoken by all. The proper term for the form of Hindi used in northern India is Hindustani which is spoken in and around Delhi and borrows equally from other languages such as Urdu and Punjabi. Hindi though, is the most widely understood (~80%) and spoken (~66%) language in the region.
 * Click here for more on this topic

Writing System
Hindi is written in the Devanagari script (देवनागरी) a left-to-right writing system with a very characteristic top line. Several other languages such as Marathi, Nepali and Sanskrit use the Devanagari script.

History
Hindi originated in 17th century by the mixing of the Polulau languages of the areas around Delhi (capital of India) with Urdu and Persian (brought in by Muslim rulers from the west).

Hindi is derived from Prakrit from which the Indo-Aryan languages are derived. Hindi is heavily influenced by Urdu and even Persian, although it still retains the Devanagari script of Sanskrit.

Spoken Hindi and spoken Urdu are so similar that they are mutually intelligible by native speakers. In their literary forms, however, Hindi borrows more heavily from Sanskrit while Urdu borrows vocabulary from Persian and Arabic.

Other resources

 * eg.A hindi Website
 * eg.A hindi news information Website
 * eg.A hindi webdirectory
 * Wikipedia article about the Hindi language
 * Hindi-Urdu phrasebook on Wikivoyage

title: Hindi/Introduction


text:
Dichotomous Key/Lagomorpha

1

 * Ear length
 * Short -
 * Elongated -

title: Dichotomous Key/Lagomorpha


text:
Cookbook:Chicken

| Basic foodstuffs | Meat and poultry

Chicken is a type of poultry meat.

Characteristics
Overall, chicken meat is quite mild compared to other meats. It can be broadly divided into dark and white meats; dark meat has more fat and myoglobin and is overall more flavorful, while white meat are leaner and much milder. As a chicken gets older, the lower breastbone ossifies, making its stiffness a way to measure the age of the bird.

Varieties
While there are different breeds of chicken, the varieties in cooking are primarily distinguished by age/size, as well as by sex in some cases.
 * Poussin: small and/or very young; less than 1 pound (450 g).
 * Broiler/fryer: young; about 7 weeks old; 2½–4½ pounds (1–2 kg); tender and leaner meat.
 * Rock Cornish game hen: young and small broiler/fryer; 1–2 pounds (0.5–1 kg).
 * Roaster: mid-age; 3–5 months old; 5–7 pounds (2.25–3.25 kg); tender meat.
 * Capon: castrated male; 4–8 months old; 4–7 pounds (1.75–3.25 kg); tender, light meat with relatively high fat.
 * Stewing/baking hen: mature female; 10–18 months old; tougher but more flavorful meat.
 * Cock/rooster: a mature male chicken with coarse skin and tough, dark meat.

Cuts
Chickens may be used in their entirety, or they may be broken down into the following main cuts and sub-cuts.

Breast
Chicken breast is considered white meat and is generally lean and somewhat dry. It can be subdivided into the following:

 * Breast: Large section of muscle from the chest of the bird; often sold boneless
 * Tenderloin: Sections between the breast and ribs

Wing
The wing is another type of white meat, and it is often eaten as a snack food. It consists of the following:

 * Drumette: Upper part of the wing
 * Flat or wingette: Middle part of the wing
 * Tip: Very end of the wing; rarely eaten on its own

Leg
The leg is considered dark meat and is less lean than white meat. It may be sold whole, but it may also be separated into the following:

 * Thigh: Upper part of the leg
 * Drumstick: Lower part of the leg

Other

 * Giblets (including heart, liver, gizzard)
 * Head
 * Feet
 * Neck
 * Kidneys
 * Intestines
 * Lungs

Selection and storage
The best source for chicken is a reputable butcher or market, and ideally one who can tell you how the chicken was raised, slaughtered, and processed. Whole plucked and cleaned chickens are common and cheapest per-pound, but packages of specific cuts are also widely available.

If you can smell the meat, it should be fresh, with no hint of spoilage or off odors. Unless it has just been slaughtered, the meat should be cold to the touch and have no significant discoloration. Air-chilled chicken will have less retained fluid than water-chilled. It's a good idea to make sure the raw meat is well-segregated from any food that may be eaten raw in order to avoid cross-contamination. Avoid leaving the chicken at room temperature for prolonged periods. Store fresh chicken in the refrigerator, and use it within a few days. For prolonged storage, it can be well wrapped in plastic and frozen—it will technically be safe indefinitely, though it can become freezer-burned after several months.

When purchasing fully cooked rotisserie or fast food chicken, be sure it is hot at time of purchase. Use it within a couple hours, or cut it into pieces and refrigerate/freeze it. Eat within 3–4 days.

Safety
As on any perishable meat, fish, or poultry, bacteria can be found on raw or undercooked chicken—one common contaminant of raw chicken is Salmonella. These must be destroyed by thorough cooking of any food to 71 °C (160 °F). Make sure to defrost chicken safely, as you would any other raw meat.

Use
As an overall mild-tasting meat, chicken is suited for a range of preparations. Generally the method of cooking is determined by the tenderness of the chicken and its cut. Younger varieties (see above) can be quickly fried or broiled, mid-age roasters and capons are good roasted, and older and tougher varieties must be slow- and moist-cooked in order to tenderize the meat. Breast meat is good for cutlets as well as slivered and stir-fried, and the legs are good when baked/roasted. The carcass, neck, and feet are excellent for use when making chicken stock.

title: Cookbook:Chicken


text:
Cookbook talk:Chicken

This module uses text adapted from the public domain US Department of Agruculture article FOCUS ON: Chicken.

I see where alll the imperial measures come from, but seriously, got metric? This articcle is hard to read fro someone not used to the imperial system, and I know someone who knows what he's talking about can fix it quickly. I can't. Off course I can enter the numbers in a converter, but you need nice and rounded numbers for the material to be remembered, and I have no idea what goes on in a kitchen most of the time. --Kasperl (Forgot to log in)
 * I think I got most of them, please check. Gentgeen 19:46, 21 Sep 2004 (UTC)

Featured
This module was the featured ingredient on the main Cookbook page from September 6, 2004 - September 30, 2004. Gentgeen 12:36, 6 Sep 2004 (UTC)

Is there no simple, basic roasting recipe?

brining
needs a section on brining

Internationalism
"in America today"? obviously this reads as if the expected readership is exclusivley american - bad wikimanship

 * It's taken directly from a public domain USDA document. Please update as necessary. (ie, ) Gentgeen 00:08, 10 January 2007 (UTC)

Defrosting?
''Do not cook frozen chicken in the microwave or in a slow cooker. However, chicken can be cooked from the frozen state in the oven or on the stove. The cooking time may be about 50% longer.'' This is a quote from the defrosting section, near the end of the current article. I have heard from many sources that frozen or partially-frozen meat and poultry should not be cooked, and can in fact be dangerous in that the meat will likely remain uncooked in parts. I am going to add a note in this section that the food should always be checked to ensure that it is cooked through.

more defrosting. It says when defrosting with cold water to change the water every 30 minutes, but i think a frozen chicken would keep the water cold anyways, much colder than tap water anyways. Here in Australia, we must be careful with wasting water needlessly. I have not edited the page because I am no expert on the matter, plus im new to trying to contribute to wiki so i dont want to make my first move a dumb one -gaspah

title: Cookbook talk:Chicken


text:
Arabic/Arabic alphabet

Here are all the official letters of the Arabic alphabet in order.

The following image shows which letters have an equivalent in the English language. Note that the r differs from the English one; it is a trill like in Spanish and Russian.

Because you know English, you have an advantage that speakers of other Western European Languages don't have:

The rest of the letters have no true English equivalents. Before you learn them they will sound silent, or seem like another letter. We will learn to pronounce and recognize these letters later.

Arabic Letters have tails

Some Arabic letters have extra parts to them. These parts are only written at the end of words, and a few of them are optional. Look at the picture above. These extra parts have been cut off and brightened so you can see the important part of each letter. Without the extra parts, you see what letters look like at the beginning of words.

Some letters
In the picture before the one above, there were some letters that didn't seem to have any extra parts. Some don't. These don't connect to letters after them—connecting them to letters after them would make words very difficult to read, and is not allowed. We boxed these letters in the picture directly above. Some letters do connect to letters after them, but don't have tails; instead, the whole shape of the letter changes. These letters are circled above, and their different shapes are shown in the picture below..

Explanation
Arabic letters change shape according to their place within a word. Usually this means not writing a tail, because the letter is not at the end of the word. But because Arabic is meant to be written mainly by hand, there are also other changes (i.e., shortcuts) that make writing easier. Here is an important shortcut. Because the shortcut is always used in handwriting, it has made its way into Arabic printing. Notice how the hole in the middle and final forms of the letter get covered presumably due to thick ink. This comes from calligraphy, Arabic has an incredibly rich calligraphic history.

There are even more shortcuts (mainly ligatures) that we will cover later. Just in case you didn't notice, Arabic is written and read from right to left.

The Arabic alphabet is very focused on representing sounds. Some of the sounds may be hard to distinguish for English speakers. See Arabic sounds and Wikipedia:Arabic Alphabet for more details on sounds.

The alphabet does not have capital letters (letters especially designed for names or certain grammar cases). But the way letters are written does depend on the location of the letter in a word. A letter at the beginning of a word (initial) is often written slightly different from the same letter at the ending of a word (final), or somewhere in between (medial).

The easiest way to learn the language is to try to recognize certain shapes in the letters (like hooks, bows, and points). Based on these shared shapes, the letters can be divided in shape groups. See Arabic alphabet (by group) to learn more on how to tell the written shapes apart, and how to write them.

= Synthetic table =
 * ''Note that 'a' is pronounced as the sound 'a' in 'cat' or the sound 'u' in 'but'.

Each Arabic letter is made up of two parts: a shape, a number of dots. Rules for all writing systems using the Arabetic (writing using Arabic shapes, with dots) system. The following Rules apply.

 * 1) Every letter consists of a shape with no dots or some dots.
 * 2) The placement (above or below) is important. A shape with a dot underneath is not the same letter as the same shape with a dot above.
 * 3) The number of dots is important. A shape with one dot is a different letter than the same shape with a different number of dots.

In Arabic Arabetics, dots can only be above or below the shape, never both at the same time. The way the dots are placed relative to each other, (i.e. diagonally, vertically, in a triangle) does not make different letters.

title: Arabic/Arabic alphabet


text:
User:Sj

Welcome to my user page. For more details, or to get in touch by email, please visit me on Wikipedia or Meta.

About me
I loved the main page design as of mid-2009. I am interested in the multilingualism and naming conventions of this project, and hope to get more people to come work on language texts in German and Spanish. As of 2014 I'm on the advisory board of Boundless Learning, which also builds freely licensed textbooks (which should be portable into WB projects).

Interesting projects

 * Import the awesome Light and Matter book series.
 * Import material from CK12 books (single format) from before they switched licenses to CC-NC :/.
 * Import material from Boundless (single format) and Saylor (multi-format, multi-license) books.
 * Add cheatsheets and summaries of programming languages, as Oracle Programming/SQL Cheatsheet, ASP Notes, TCL and ADP, ...
 * Cleaning up Orphans and the Cookbook; fixing talk page redirects and interwiki deletions
 * Upload the Whole Earth Catalog and making it editable. See User:Sj/Whole Earth Catalog for a start.  Improving the old content with modern information about the same texts and categories.  (free copyright license granted by original publishers, Steward Brand/Kevin Kelly.  Copies of 5 volumes donated for scanning.)
 * The reading room archives need some cleaning up again... to cull out good project ideas and combine them into a persistent thread/idea-page.
 * Outreach: Someone needs to follow up with each of the external authors who have considered publishing on Wikibooks, and those free-content authors who have not. There are many free-content text generators, from ck12 to Ben Crowell, whose books are not represented on WB.  If this can't be fixed immediately, there should be a wikiproject discussing reasons and options.
 * Similarly: add transcripts of Khan videos from before they switched licenses
 * Get professors and universities that are putting CC-BY and CC-SA material online to synch those efforts with Wikibooks (or give us programmatic access, and build scripts to maintain a version here).

Older projects:
 * Getting Blogging 101 folks to migrate their wiki here.
 * Getting interesting source materials for wikibooks onto wikisource for cross-Project collab.

title: User:Sj


text:
Talk:Arabic

Untitled
I started my arabic project in German. [] We can share our stuff and translate it.

Purpose
What is the intended level of instruction of this book? It's not clear what the intent is in the book itself. I think the purpose and outcomes should be made more clear in an introduction. Also, is anyone actively working on it? 13 Dec 2011

GARG - Gnu Arabic Grammar
Here are the beginnings of a Modern Arabic Grammar Guide. Anybody who has an interest in helping should take part in the planning section.

Collection Point - Articles for the Grammar Guide can be entered here. More information is on the site.

Edited Work - Please do not make any more changes on in this section - instead start a discussion.

(Translation of Arabisch - Original document by Zorro 16:00 GMT 29/02/04)

Some lost pages
With the changes in History, I noticed there are some pages of an anonymous writer that were left out of your table of contents. They are: I deem the naming conventions should change (someone must take the responsibility of moving them), and useless stuff should be removed. --Wizard0 13:29, 18 Feb 2005 (UTC)
 * Sounds - Arabic sound identification system symbols, which seems to be orphaned, and
 * Some_history, which was a link on that page.

numbers
added a section for arabic numerals.

This is twoThirty
I have been adding a lot of material to this wikiBook. The last thing I added was the new section for learning Arabic reading and writing. Once it is done, we should be able to delete the original learn to read Arabic section called "Fundamentals", because it will be useless. For the new learning to read and write Arabic, excercises are needed, especially copying excercises (to practice writing, but this requires the use of pictures I assume).

After this wikibook is done, a graduated phrase book (going from basic phrases to more complex phrases, including translation and word-for-word translation) should be created for Arabic. Also, a transcription (subtitles written out) for some old Arabic cartoons would help (especially if they are downloadable off the internet (Grendizer comes to mind)). If there is already a wiki for cartoons and transcribing them, tell me (I highly doubt that there are any).

 إلى اللقاء

Section, dialectical clarity
This section on Arabic is an unclear mix of colloquials and of MSA. It should be revised with a goal of one dialect in mind.

(Sorry for the multiple revisions, I'm new.)

Monoglot 03:48, 24 March 2006 (UTC)

Reply to: Dialectecal clarity
Thank you for the comment. I agree that it should have one dialect in mind. I deleted the non-MSA sections.

The changing transliteration system has been wasting time. I'll focus on making the Arabic alphabet part high quality, and then using the Arabic alphabet only for the other parts. This wikibook needs a great amount of planning. The task is really big. I think after the Arabic writing system, we should focus on Arabic grammar, providing examples, and vocabulary. --TwoThirty 07:20, 27 March 2006 (UTC)

Dialectical Decision
I have decided to omit the colloquial languages in this book. We will focus on Standard Arabic.

Perhaps, they will be included in a final chapter, to help people who have mastered the language to be able to understand most colloquialized Arabic speech. For the following reasons: --TwoThirty 00:11, 2 April 2006 (UTC)
 * 1) There is more demand for learning it than there are for the colloquials.
 * 2) The colloquials are not the general Arab language. All Arabs understand Standard Arabic.
 * 3) You need Standard Arabic to read and write.
 * 4) Most Arabs can speak Standard Arabic.
 * 5) Each colloquial is limited in dominance to a region.
 * 6) You need Standard Arabic to understand the Qur'aan.
 * 7) Understanding Standard Arabic makes it easier to understand more than one Arabic colloquial.
 * I second that. You can also understand the new with MSA and a lot of TV programs, so it's far from just a formal written or Quranic language. --Atitarev (talk) 00:06, 19 February 2008 (UTC)

Cleaning up pages
I don't have a problem with major contributors trying to remove content from the Wikibooks they are working on, and I try to leave that up to the participants on each seperate Wikibook.

Every once in awhile I find a page like Arabic/Basic Sentences/ain't which has been blanked, and I'm not sure if the person who blanked the page would like it deleted or not. Information is the key here, and simply removing all of the content does not automatically remove the page from our database.

If you really think the page is useless and will not contribute to your Wikibook, or that you have covered the content elsewhere and really don't need that page any more, please use the following "page markup tag" to let administrators and any other interested person know why you think the page needs to be removed:

I use this myself even to get a second opinion on semi-questionable pages, and it gives the opportunity to give a reason for its removal. Otherwise, I have to try and form my own opinion on the matter. It also takes me quite a bit more time to review a page that has been blanked and not marked up with the delete tag, keeping me from other items on Wikibooks. --Rob Horning 15:33, 5 April 2006 (UTC)

Arabic lessons
Arabic is becoming more and more important in today's world, so Wikibooks should definitely have lessons for it. I started learning Arabic, but only know the script and a few basic expressions so far. I'd love to see further lessons here.

Have you seen the article on creating a language course on Wikibooks? I think it's quite useful. Also, you may want to have a look at the course format I found works best for students: Bite-sized language lessons.

Regarding the lessons teaching how to read and write, I found it very useful to give the students words to practise that he should already be able to recognise: English words that Arabic borrowed (e. g. the one for sandwich), Arabic words that are found in English (e. g. algebra?), common personal names (e. g. Ahmed) and the names of cities and countries. Students will find it easier and more fun to read words when they can guess the meaning. Otherwise they're learning two things at once: a foreign script and foreign words, which can be discouraging.

Anyways, just my two cents. Good luck!

Junesun 15:32, 29 June 2006 (UTC)

Thank you for making this "book". I like Arabic language. It's cool. Keep up the good work. :)

Alphabet module is *not* complete
While all of the letters may be properly described in the "Alphabet" page, it in no way teaches the reader the letters. Specifically, there should be step-by-step exercises to transliterate/read the script, starting with a couple letters, then building to the full alphabet (because the whole thing at once simply goes in one ear and out the other), including how to pronounce each one. --RealGrouchy 19:16, 12 April 2007 (UTC)

Proposed Wikibook Format
I'm back, and ready to bring this wikibook to life. I have reorganized the links so that it isn't so difficult to find the more complete version that teaches about four letters at a time.

Be sure to add your suggestions, or reserve a section to write on the Wikibook proposed plan, at the bottom of the main page. I have some new suggestions about incorporating all forms of Arabic, in order to have a more realistic and more useful wikibook. But leaving it up to the user as to which dialects they need exposure to. --TwoThirty 09:18, 13 August 2007 (UTC)

Pronunciation
This book really needs some pronunciation .ogg files. So, any native speakers out there want to make lessons? As of now the easiest thing would be to read down lists: numbers, months, days, alphabet, etc. Anything simple will do. Hopefully if we get enough native speakers interested we can get into doing more then we can actually get real lessons. But some basic pronunciations are needed. Just make sure to provide as much information about accent as possible: fusha preferably but at least make it clear if you are speaking in dialect.

For those of us who can't really speak Arabic or have accents so bad it would not help anyone maybe we can make some drills that way anyone with a good accent can just read down the list and upload it instead of making the lessons themselves. gren グレン 04:23, 16 September 2007 (UTC)
 * Agree with this but someone has to do the job, preferably a native speaker. By the way, do you know how to create .ogg files? --Atitarev (talk) 23:56, 18 February 2008 (UTC)
 * Audacity is a free audio recorder that can do .ogg's Josterhage (talk) 17:23, 28 July 2008 (UTC)
 * Thanks, now we need to find a native speaker willing to do the job :) --Atitarev (talk) 12:02, 14 August 2008 (UTC)

CanI...
Can I use this lesson in my Wikibooks(malay).Putera Luqman Tunku Andre (talk) 07:16, 2 September 2008 (UTC)

Vowels / diacritics
My previous comments were a little hasty, I reviewed the pages more and clearly there is more vowel marking than I thought there was. One of my issues is that it seems inconsistent, and it certainly seems like there is a tendency to assume certain things (such as sukoon via no vowel where a vowel is expected). I will say that it is not easy to tell what standard the writer is keeping with these vowel markings. A page describing how the marking is being done, and a clear check for consistency in the policy, is in order. It is also extremely difficult where markings are visible to discern which marks belong to which lines in many places due to line-height being too small, but this is a simple matter of addressing formatting issues as time goes by. In any case, I also suggest cross-coördinating with the English and Arabic Wiktionaries (which could be abetted by Meta). this raven is icy (talk) 04:52, 25 September 2009 (UTC)

Category IV
Arabic is a category IV language, not a category III.

Orphaned page
Arabic/Some history is not linked to from any other page, and thus is orphaned. The page itself looks like it needs major cleanup. I'd like the contributors here to make a decision on what to do with the page. It looks like all the content there is already covered better on other pages, so my initial response would be to speedy delete it (especially as the last edits were in 2006) but I'm instead putting up notice here in case there's material that could be merged into other articles.

I've also put up Arabic/Arabic vowels for speedy deletion as it is also orphaned and doesn't seem to have any content not better covered on other pages. Xerol Oplan (talk) 05:22, 25 May 2010 (UTC)

 * N.B. 'Arabic vowels' deleted 27th May; topic was better covered in the Arabic/LearnRW/a i u, and Arabic/LearnRW/fatHamodules of the book. Reece   (Talk)   (Contributions)  23:10, 26 May 2010 (UTC)

title: Talk:Arabic