Search Results

Search found 175 results on 7 pages for 'paradigms'.

Page 1/7 | 1 2 3 4 5 6 7  | Next Page >

  • What are algorithmic paradigms?

    - by Vaibhav Agarwal
    We generally talk about paradigms of programming as functional, procedural, object oriented, imperative etc but what should I reply when I am asked the paradigms of algorithms? For example are Travelling Salesman Problem, Dijkstra Shortest Path Algorithm, Euclid GCD Algorithm, Binary search, Kruskal's Minimum Spanning Tree, Tower of Hanoi paradigms of algorithms? Should I answer the data structures I would use to design these algorithms?

    Read the article

  • Cost of maintenance depending on paradigms

    - by Anto
    Is there any data on which paradigms allow for code which is easier/cheaper to maintain? Certainly, independantly of the chosen paradigm, good design is cheaper to maintain than bad, but there should probably be major differences coming only from the paradigm choice. Unstructured programming, for instance, generates very messy code (spaghetti code) which is expensive to maintain. In object oriented programming, implementation details are hidden and thus it should be pretty cheap to change those. In functional programming, there are no side effects, thus there is lesser risk of introducing bugs during maintainance, which should be cheaper. Is there any data on which paradigms are the most cost-efficient when coming down to maintenance? If no such data exists, what is your take on the question?

    Read the article

  • Paradigms fit for UI programming

    - by Inca
    This is a more specific question (or actually two, but they are related) coming from the comments of OOP technology death where someone stated that OOP is not the right paradigm for GUI programming. Reading the comments there and here I still have the feeling there are things to learn: which programming paradigms are considered good fits and why are they better than others (perhaps with examples to illustrate?) I removed the tk-example from the title and question

    Read the article

  • Differences & Similarities Between Programming Paradigms

    - by DaveDev
    Hi Guys I've been working as a developer for the past 4 years, with the 4 years previous to that studying software development in college. In my 4 years in the industry I've done some work in VB6 (which was a joke), but most of it has been in C#/ASP.NET. During this time, I've moved from an "object-aware" procedural paradigm to an object-oriented paradigm. Lately I've been curious about other programming paradigms out there, so I thought I'd ask other developers their opinions on the similarities & differences between these paradigms, specifically to OOP? In OOP, I find that there's a strong focus on the relationships and logical interactions between concepts. What are the mind frames you have to be in for the other paradigms? Thanks Dave

    Read the article

  • Can aptitude for learning Programming paradigms be influenced by culture or native language's gramma

    - by DVK
    It is well known that different people have different aptitudes regarding various programming paradigms (e.g. some people have trouble learning non-procedural, especially functional languages. Some people have trouble understanding pointers - see Joel Spolsky's blog for musings on that. Some people have trouble grasping recursion). I was recently reading about a study that looked at how the grammar of someone's native language affected their speed of learning math. Can't find that article now but a quick googling found this reference. That led me to wondering whether someone's native culture or first language might affect their aptitude towards various programming paradigms. I'm more curious about positive influences - e.g. some trait that make it easier/faster for someone to learn a particular paradigm, for example native language grammar being very recursion-oriented. To be clear, I'm looking for how culture/language grammare may affect the difference between aptitude of the same person towards various paradigms as opposed to how it affects overall aptitude towards programming between different persons. Important: the only answers I'm interested in are either references to scientific studies, or personal observations from someone intimately familiar with a particular culture/language, including from their own experience. E.g. I'm not interested in your opinion of how Chinese being your first language affects anything unless you speak Chinese or worked with extremely large set of Chinese-native programmers extensively. I'm OK with your guesstimates not based on scientific studies, but please be sure to supply your reasoning about plausible causes of your observation. I'm not interested in culture-bashing (any such commends will be deleted or flagged for deletion). I'm also not particularly interested in culture-building - we all know Linus is from Finland and Tetris was written in Russia and Larry Wall is an American. Any culture/nation can produce a brilliant mind in any discipline. I'm interested in averages.

    Read the article

  • Visual Programming paradigms

    - by Rego
    As the number of "visual" OS's such as Android, iOS and the promised Windows 8 are becoming more popular, it does not seem to me that we programmers have new ways to code using these new technologies, due to a possible lack in new visual programming languages paradigms. I've seen several discussions about incompatibilities between the current coding development environment, and the new OS approaches from Windows 8, Android and other tablets OS's. I mean, today if we have a new tablet, it's almost a requirement for coding, to have, for instance, an external keyboard (due it seems to me it's very difficult to program using the touch screen), exactly because the coding assistance is not conceived to "write" thousands of lines of code. So, how advanced should be the "new" visual programming languages paradigms? Which characteristics these new paradigms would be required?

    Read the article

  • Are there still completely new programming languages and -paradigms to be born?

    - by llasa
    Are there still completely new programming languages and -paradigms (which will actually go mainstream and still be used decades after their appearance) to be born? What I'm talking about are groundbreaking things like the rise of object oriented programming, C++, or PHP. With new programming languages I mean that they actually are completely different from what you know, as different as when you set a guy who used assembler for a decade, and even programmed some kind of 3D game in it, in front of something as high-level as PHP, Ruby or Python? Which new paradigms and programming languages are there to come? What could be different about them? Who will possibly create them and how fast will they rise?

    Read the article

  • An Alphabet of Eponymous Aphorisms, Programming Paradigms, Software Sayings, Annoying Alliteration

    - by Brian Schroer
    Malcolm Anderson blogged about “Einstein’s Razor” yesterday, which reminded me of my favorite software development “law”, the name of which I can never remember. It took much Wikipedia-ing to find it (Hofstadter’s Law – see below), but along the way I compiled the following list: Amara’s Law: We tend to overestimate the effect of a technology in the short run and underestimate the effect in the long run. Brook’s Law: Adding manpower to a late software project makes it later. Clarke’s Third Law: Any sufficiently advanced technology is indistinguishable from magic. Law of Demeter: Each unit should only talk to its friends; don't talk to strangers. Einstein’s Razor: “Make things as simple as possible, but not simpler” is the popular paraphrase, but what he actually said was “It can scarcely be denied that the supreme goal of all theory is to make the irreducible basic elements as simple and as few as possible without having to surrender the adequate representation of a single datum of experience”, an overly complicated quote which is an obvious violation of Einstein’s Razor. (You can tell by looking at a picture of Einstein that the dude was hardly an expert on razors or other grooming apparati.) Finagle's Law of Dynamic Negatives: Anything that can go wrong, will—at the worst possible moment. - O'Toole's Corollary: The perversity of the Universe tends towards a maximum. Greenspun's Tenth Rule: Any sufficiently complicated C or Fortran program contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of Common Lisp. (Morris’s Corollary: “…including Common Lisp”) Hofstadter's Law: It always takes longer than you expect, even when you take into account Hofstadter's Law. Issawi’s Omelet Analogy: One cannot make an omelet without breaking eggs - but it is amazing how many eggs one can break without making a decent omelet. Jackson’s Rules of Optimization: Rule 1: Don't do it. Rule 2 (for experts only): Don't do it yet. Kaner’s Caveat: A program which perfectly meets a lousy specification is a lousy program. Liskov Substitution Principle (paraphrased): Functions that use pointers or references to base classes must be able to use objects of derived classes without knowing it Mason’s Maxim: Since human beings themselves are not fully debugged yet, there will be bugs in your code no matter what you do. Nils-Peter Nelson’s Nil I/O Rule: The fastest I/O is no I/O.    Occam's Razor: The simplest explanation is usually the correct one. Parkinson’s Law: Work expands so as to fill the time available for its completion. Quentin Tarantino’s Pie Principle: “…you want to go home have a drink and go and eat pie and talk about it.” (OK, he was talking about movies, not software, but I couldn’t find a “Q” quote about software. And wouldn’t it be cool to write a program so great that the users want to eat pie and talk about it?) Raymond’s Rule: Computer science education cannot make anybody an expert programmer any more than studying brushes and pigment can make somebody an expert painter.  Sowa's Law of Standards: Whenever a major organization develops a new system as an official standard for X, the primary result is the widespread adoption of some simpler system as a de facto standard for X. Turing’s Tenet: We shall do a much better programming job, provided we approach the task with a full appreciation of its tremendous difficulty, provided that we respect the intrinsic limitations of the human mind and approach the task as very humble programmers.  Udi Dahan’s Race Condition Rule: If you think you have a race condition, you don’t understand the domain well enough. These rules didn’t exist in the age of paper, there is no reason for them to exist in the age of computers. When you have race conditions, go back to the business and find out actual rules. Van Vleck’s Kvetching: We know about as much about software quality problems as they knew about the Black Plague in the 1600s. We've seen the victims' agonies and helped burn the corpses. We don't know what causes it; we don't really know if there is only one disease. We just suffer -- and keep pouring our sewage into our water supply. Wheeler’s Law: All problems in computer science can be solved by another level of indirection... Except for the problem of too many layers of indirection. Wheeler also said “Compatibility means deliberately repeating other people's mistakes.”. The Wrong Road Rule of Mr. X (anonymous): No matter how far down the wrong road you've gone, turn back. Yourdon’s Rule of Two Feet: If you think your management doesn't know what it's doing or that your organisation turns out low-quality software crap that embarrasses you, then leave. Zawinski's Law of Software Envelopment: Every program attempts to expand until it can read mail. Zawinski is also responsible for “Some people, when confronted with a problem, think 'I know, I'll use regular expressions.' Now they have two problems.” He once commented about X Windows widget toolkits: “Using these toolkits is like trying to make a bookshelf out of mashed potatoes.”

    Read the article

  • Precising definition of programming paradigm

    - by Kazark
    Wikipedia defines programming paradigm thus: a fundamental style of computer programming which is echoed in the descriptive text of the paradigms tag on this site. I find this a disappointing definition. Anyone who knows the words programming and paradigm could do about that well without knowing anything else about it. There are many styles of computer programming at many level of abstraction; within any given programming paradigm, multiple styles are possible. For example, Bob Martin says in Clean Code (13), Consider this book a description of the Object Mentor School of Clean Code. The techniques and teachings within are the way that we practice our art. We are willing to claim that if you follow these teachings, you will enjoy the benefits that we have enjoyed, and you will learn to write code that is clean and professional. But don't make the mistake of thinking that we are somehow "right" in any absolute sense. Thus Bob Martin is not claiming to have the correct style of Object-Oriented programming, even though he, if anyone, might have some claim to doing so. But even within his school of programming, we might have different styles of formatting the code (K&R, etc). There are many styles of programming at many levels. Sp how can we define programming paradigm rigorously, to distinguish it from other categories of programming styles? Fundamental is somewhat helpful, but not specific. How can we define the phrase in a way that will communicate more than the separate meanings of each of the two words—in other words, how can we define it in a way that will provide additional meaning for someone who speaks English but isn't familiar with a variety of paradigms?

    Read the article

  • What is the precise definition of programming paradigm?

    - by Kazark
    Wikipedia defines programming paradigm thus: a fundamental style of computer programming which is echoed in the descriptive text of the paradigms tag on this site. I find this a disappointing definition. Anyone who knows the words programming and paradigm could do about that well without knowing anything else about it. There are many styles of computer programming at many level of abstraction; within any given programming paradigm, multiple styles are possible. For example, Bob Martin says in Clean Code (13), Consider this book a description of the Object Mentor School of Clean Code. The techniques and teachings within are the way that we practice our art. We are willing to claim that if you follow these teachings, you will enjoy the benefits that we have enjoyed, and you will learn to write code that is clean and professional. But don't make the mistake of thinking that we are somehow "right" in any absolute sense. Thus Bob Martin is not claiming to have the correct style of Object-Oriented programming, even though he, if anyone, might have some claim to doing so. But even within his school of programming, we might have different styles of formatting the code (K&R, etc). There are many styles of programming at many levels. So how can we define programming paradigm rigorously, to distinguish it from other categories of programming styles? Fundamental is somewhat helpful, but not specific. How can we define the phrase in a way that will communicate more than the separate meanings of each of the two words—in other words, how can we define it in a way that will provide additional meaning for someone who speaks English but isn't familiar with a variety of paradigms?

    Read the article

  • Is the “jQuery programming style” a kind of Reactive programming?

    - by Peter Krauss
    jQuery is a Javascript library and framework, but when we are programming with jQuery into DOM problems/solutions, we can practice a style quite different of programming... We can read about jQuery at Wikipedia, The set of jQuery core features — DOM element selections, traversal and manipulation —, enabled by its selector engine (...), created a new "programming style", fusing algorithms and DOM-data-structures This question is similar to the "subquestion-3" of this question but not so generic. The focus here is about this new kind of "programming style"... So, the question: Is the "jQuery programming style in DOM context" a new paradign? Or it is more one example of reactive programming (not "cell-oriented" but "DOM-node oriented") or another one? We have no "standard taxonomy of paradigms", so, please, in your answer, indicate also your "best choice for Wikipedia Paradign". Example: if you understand that "jQuery programming DOM" is like "awk filtering data", your choice can be event-driven.

    Read the article

  • What programming languages should every computer science student be taught?

    - by Anto
    What languages (or classes (as in paradigms) of programming languages, plus a recommended language of that class) should every computer science student be taught in college according to you? Motivate your answers; why that language? What use will one have from it? What concepts does it teach (better than language X does)? Note/clarification: This question is about computer science with heavy focus on software engineering, not pure computer science. It is still computer science education and not software engineering education which is the focus.

    Read the article

  • Practical guide to programming paradigms ?

    - by Pierre
    I think I might be misunderstanding the whole thing and I am looking for some programming wisdom. When faced with a programming challenge, I feel the most important question is "which programming paradigm(s) are better suited to handle it, and how to apply them". A distant second is "which language to use". Yet it seems that most of the programming related content I stumble upon on the Internet has it exactly backwards and focuses mostly on the language choice. An object-oriented solution is fundamentaly the same, whether it's implemented in c++, Java or PHP... So where is the paradigm centered content? Where is the "practical guide to programming paradigms and implementations" and other literature helping bringing real-world and programming concepts together? Note: I already know about "Programming Paradigms for Dummies: What Every Programmer Should Know" from Peter Van Roy.

    Read the article

  • What's The Difference Between Imperative, Procedural and Structured Programming?

    - by daniels
    By researching around (books, Wikipedia, similar questions on SE, etc) I came to understand that Imperative programming is one of the major programming paradigms, where you describe a series of commands (or statements) for the computer to execute (so you pretty much order it to take specific actions, hence the name "imperative"). So far so good. Procedural programming, on the other hand, is a specific type (or subset) of Imperative programming, where you use procedures (i.e., functions) to describe the commands the computer should perform. First question: Is there an Imperative programming language which is not procedural? In other words, can you have Imperative programming without procedures? Update: This first question seems to be answered. A language CAN be imperative without being procedural or structured. An example is pure Assembly language. Then you also have Structured programming, which seems to be another type (or subset) of Imperative programming, which emerged to remove the reliance on the GOTO statement. Second question: What is the difference between procedural and structured programming? Can you have one without the other, and vice-versa? Can we say procedural programming is a subset of structured programming, as in the image?

    Read the article

  • Introducing functional programming constructs in non-functional programming languages

    - by Giorgio
    This question has been going through my mind quite a lot lately and since I haven't found a convincing answer to it I would like to know if other users of this site have thought about it as well. In the recent years, even though OOP is still the most popular programming paradigm, functional programming is getting a lot of attention. I have only used OOP languages for my work (C++ and Java) but I am trying to learn some FP in my free time because I find it very interesting. So, I started learning Haskell three years ago and Scala last summer. I plan to learn some SML and Caml as well, and to brush up my (little) knowledge of Scheme. Well, a lot of plans (too ambitious?) but I hope I will find the time to learn at least the basics of FP during the next few years. What is important for me is how functional programming works and how / whether I can use it for some real projects. I have already developed small tools in Haskell. In spite of my strong interest for FP, I find it difficult to understand why functional programming constructs are being added to languages like C#, Java, C++, and so on. As a developer interested in FP, I find it more natural to use, say, Scala or Haskell, instead of waiting for the next FP feature to be added to my favourite non-FP language. In other words, why would I want to have only some FP in my originally non-FP language instead of looking for a language that has a better support for FP? For example, why should I be interested to have lambdas in Java if I can switch to Scala where I have much more FP concepts and access all the Java libraries anyway? Similarly: why do some FP in C# instead of using F# (to my knowledge, C# and F# can work together)? Java was designed to be OO. Fine. I can do OOP in Java (and I would like to keep using Java in that way). Scala was designed to support OOP + FP. Fine: I can use a mix of OOP and FP in Scala. Haskell was designed for FP: I can do FP in Haskell. If I need to tune the performance of a particular module, I can interface Haskell with some external routines in C. But why would I want to do OOP with just some basic FP in Java? So, my main point is: why are non-functional programming languages being extended with some functional concept? Shouldn't it be more comfortable (interesting, exciting, productive) to program in a language that has been designed from the very beginning to be functional or multi-paradigm? Don't different programming paradigms integrate better in a language that was designed for it than in a language in which one paradigm was only added later? The first explanation I could think of is that, since FP is a new concept (it isn't new at all, but it is new for many developers), it needs to be introduced gradually. However, I remember my switch from imperative to OOP: when I started to program in C++ (coming from Pascal and C) I really had to rethink the way in which I was coding, and to do it pretty fast. It was not gradual. So, this does not seem to be a good explanation to me. Or can it be that many non-FP programmers are not really interested in understanding and using functional programming, but they find it practically convenient to adopt certain FP-idioms in their non-FP language? IMPORTANT NOTE Just in case (because I have seen several language wars on this site): I mentioned the languages I know better, this question is in no way meant to start comparisons between different programming languages to decide which is better / worse. Also, I am not interested in a comparison of OOP versus FP (pros and cons). The point I am interested in is to understand why FP is being introduced one bit at a time into existing languages that were not designed for it even though there exist languages that were / are specifically designed to support FP.

    Read the article

  • Why did visual programming never take off and what future paradigms might change that?

    - by Rego
    As the number of "visual" OS's such as Android, iOS and the promised Windows 8 are becoming more popular, it does not seem to me that we programmers have new ways to code using these new technologies, due to a possible lack in new visual programming languages paradigms. I've seen several discussions about incompatibilities between the current coding development environment, and the new OS approaches from Windows 8, Android and other tablets OS's. I mean, today if we have a new tablet, it's almost a requirement for coding, to have, for instance, an external keyboard (due it seems to me it's very difficult to program using the touch screen), exactly because the coding assistance is not conceived to "write" thousands of lines of code. So, how advanced should be the "new" visual programming languages paradigms? Which characteristics these new paradigms would be required?

    Read the article

  • What Functional features are worth a little OOP confusion for the benefits they bring?

    - by bonomo
    After learning functional programming in Haskell and F#, the OOP paradigm seems ass-backwards with classes, interfaces, objects. Which aspects of FP can I bring to work that my co-workers can understand? Are any FP styles worth talking to my boss about retraining my team so that we can use them? Possible aspects of FP: Immutability Partial Application and Currying First Class Functions (function pointers / Functional Objects / Strategy Pattern) Lazy Evaluation (and Monads) Pure Functions (no side effects) Expressions (vs. Statements - each line of code produces a value instead of, or in addition to causing side effects) Recursion Pattern Matching Is it a free-for-all where we can do whatever the programming language supports to the limit that language supports it? Or is there a better guideline?

    Read the article

  • UI message passing programming paradigm

    - by Ronald Wildenberg
    I recently (about two months ago) read an article that explained some user interface paradigm that I can't remember the name of and I also can't find the article anymore. The paradigm allows for decoupling the user interface and backend through message passing (via some queueing implementation). So each user action results in a message being pased to the backend. The user interface is then updated to inform the user that his request is being processed. The assumption is that a user interface is stale by definition. When you read data from some store into memory, it is stale because another transaction may be updating the same data already. If you assume this, it makes no sense to try to represent the 'current' database state in the user interface (so the delay introduced by passing messages to a backend doesn't matter). If I remember correctly, the article also mentioned a read-optimized data store for rendering the user interface. The article assumed a high-traffic web application. A primary reason for using a message queue communicating with the backend is performance: returning control to the user as soon as possible. Updating backend stores is handled by another process and eventually these changes also become visible to the user. I hope I have explained accurately enough what I'm looking for. If someone can provide some pointers to what I'm looking for, thanks very much in advance.

    Read the article

  • I need books for procedural programming

    - by Student
    Please suggest books for procedural programming. I need to know the core principles/patterns of procedural programming. So it doesn't matter if the book using any language to convey the procedural programming principles, be it pure C or others languages. Nowadays it is difficult to find ones. Even google and amazon searches didn't give me a satisfactory books. You may vote to close this question but please recommend books in comment section.

    Read the article

  • Which paradigm to use for writing chess engine?

    - by poke
    If you were going to write a chess game engine, what programming paradigm would you use (OOP, procedural, etc) and why whould you choose it ? By chess engine, I mean the portion of a program that evaluates the current board and decides the computer's next move. I'm asking because I thought it might be fun to write a chess engine. Then it occured to me that I could use it as a project for learning functional programming. Then it occured to me that some problems aren't well suited to the functional paradigm. Then it occured to me that this might be good discussion fodder.

    Read the article

  • Why (not) logic programming?

    - by Anto
    I have not yet heard about any uses of a logical programming language (such as Prolog) in the software industry, nor do I know of usage of it in hobby programming or open source projects. It (Prolog) is used as an academic language to some extent, though (why is it used in academia?). This makes me wonder, why should you use logic programming, and why not? Why is it not getting any detectable industry usage?

    Read the article

  • Is a Model Driven Architecture in Language Oriented Programming (MPS) feasible at this time

    - by Steven Jeuris
    As a side project I am developing some sort of DSL where I describe a data model, and generate desired code files from it. I believe this is called Model Driven Architecture. My partial existing implementation uses C#, CodeDOM, XML and XSLT to do this manually. I discovered there already exist better environments to do this in. The one which fascinated me the most is called MPS, which follows the Language Oriented Programming paradigm. This article, written by a cofounder of JetBrains was a real eye opener for me. I truly believe LOP has a very good chance of becoming the next big programming paradigm once it has broader support. From my short experience with MPS, I noticed it is still mainly Java-oriented. My question is, how feasible is it to generate code files for other (multiple) languages instead of just Java. I don't need full language support from the start, so preferably, I need to be able to implement a language in a agile way. E.g. first support only one type, add access modifiers, ... Perhaps some other (free) environment already provides this out of the box. P.S.: I find it important to have a lot of control over the naming conventions and such of the generated code. This is one of the reasons why I started my own implementation.

    Read the article

  • Empirical evidence for choice of programming paradigm to address a problem

    - by Graham Lee
    The C2 wiki has a discussion of Empirical Evidence for Object-Oriented Programming that basically concludes there is none beyond appeal to authority. This was last edited in 2008. Discussion here seems to bear this out: questions on whether OO is outdated, when functional programming is a bad choice and the advantages and disadvantages of AOP are all answered with contributors' opinions without reliance on evidence. Of course, opinions of established and reputed practitioners are welcome and valuable things to have, but they're more plausible when they're consistent with experimental data. Does this evidence exist? Is evidence-based software engineering a thing? Specifically, if I have a particular problem P that I want to solve by writing software, does there exist a body of knowledge, studies and research that would let me see how the outcome of solving problems like P has depended on the choice of programming paradigm? I know that which paradigm comes out as "the right answer" can depend on what metrics a particular study pays attention to, on what conditions the study holds constant or varies, and doubtless on other factors too. That doesn't affect my desire to find this information and critically appraise it. It becomes clear that some people think I'm looking for a "turn the crank" solution - some sausage machine into which I put information about my problem and out of which comes a word like "functional" or "structured". This is not my intention. What I'm looking for is research into how - with a lot of caveats and assumptions that I'm not going into here but good literature on the matter would - certain properties of software vary depending on the problem and the choice of paradigm. In other words: some people say "OO gives better flexibility" or "functional programs have fewer bugs" - (part of) what I'm asking for is the evidence of this. The rest is asking for evidence against this, or the assumptions under which these statements are true, or evidence showing that these considerations aren't important. There are plenty of opinions on why one paradigm is better than another; is there anything objective behind any of these?

    Read the article

  • How do I overcome paralysis by analysis when coding?

    - by LuxuryMode
    When I start a new project, I often times immediately start thinking about the details of implementation. "Where am I gonna put the DataBaseHandler? How should I use it? Should classes that want to use it extend from some Abstract superclass..? Should I an interface? What level of abstraction am I going to use in my class that contains methods for sending requests and parsing data?" I end up stalling for a long time because I want to code for extensibility and reusability. But I feel it almost impossible to get past thinking about how to implement perfectly. And then, if I try to just say "screw it, just get it done!", I hit a brick wall pretty quickly because my code isn't organized, I mixed levels of abstractions, etc. What are some techniques/methods you have for launching into a new project while also setting up a logical/modular structure that will scale well?

    Read the article

1 2 3 4 5 6 7  | Next Page >