Getting over the beginer hump
-
Try humping a beginner! :) Just kidding! :) On a more serious note - best of luck with programming!
¡El diablo está en mis pantalones! ¡Mire, mire! Real Mentats use only 100% pure, unfooled around with Sapho Juice(tm)! SELECT * FROM User WHERE Clue > 0 0 rows returned Save an Orange - Use the VCF! Techno Silliness
:omg::laugh:
-
I apologize if this is the wrong place to ask this. I am still new here. I have been learning programming for a bit and have read through some books to get a basic understanding of languages and program coding. I have read "Accelerated C++" by Koenig/Moo, "Programming Visual C# 2005: The Language" by Donis Marshall, "Microsoft Visual C# 2005 Step-by-Step" by John Sharp. I feel that I have a good understanding of the C# language. I am now in the stages where I want to try to put this knowledge to use and reinforce my understanding. I'm having problems starting, though. I don't know how to 'begin' writing a program. I come up with an idea of a program that I would like to create. I start writing, but end up with just a big mess that doesn't work. In frustration I give up on the project. My code is messy and I run into problems that I didn't foresee and don't know how to tackle them. I've restarted a project a couple times as I seem to code myself into a dead end. I don't really know how to design a program and look ahead for potential pitfalls. I am looking for something that would walk a person through completion of a mildly complex program, starting from the design and planning phase and ending with a final release product. I would prefer if it didn't teach the language, as I have an understanding of that as well as reference books if I don't understand. I have looked at a lot of the computer books at my local bookstores but most just seem to be complete beginner books that teach the language, or advance books that assume you know what you are doing. I have tried to search on line for these 'intermediate' type of books, but I have have little luck. I may be using the wrong words to describe what I am looking for, though. Basically, just something to help me move from beginner to intermediate that shows/teaches good programming practices. Any references or suggestions on terms to use when searching would be greatly appreciated. Sorry about the long post.
I can recommend a great coding procedures book but it aimed more towards the PHP language. Regardless it is fantastic for almost any implementation of OOP. It also covers enterprise level coding practices. This is probably exactly what you are looking for. http://www.amazon.com/PHP-5-Objects-Patterns-Practice/dp/1590593804/sr=8-13/qid=1167548156/ref=sr_1_13/103-5825864-1732667?ie=UTF8&s=books[^]
Brad Australian -CAUTION- The previous statement may contain traces of PHP, and by reading this statement you negate the right to vote me down.
-
I apologize if this is the wrong place to ask this. I am still new here. I have been learning programming for a bit and have read through some books to get a basic understanding of languages and program coding. I have read "Accelerated C++" by Koenig/Moo, "Programming Visual C# 2005: The Language" by Donis Marshall, "Microsoft Visual C# 2005 Step-by-Step" by John Sharp. I feel that I have a good understanding of the C# language. I am now in the stages where I want to try to put this knowledge to use and reinforce my understanding. I'm having problems starting, though. I don't know how to 'begin' writing a program. I come up with an idea of a program that I would like to create. I start writing, but end up with just a big mess that doesn't work. In frustration I give up on the project. My code is messy and I run into problems that I didn't foresee and don't know how to tackle them. I've restarted a project a couple times as I seem to code myself into a dead end. I don't really know how to design a program and look ahead for potential pitfalls. I am looking for something that would walk a person through completion of a mildly complex program, starting from the design and planning phase and ending with a final release product. I would prefer if it didn't teach the language, as I have an understanding of that as well as reference books if I don't understand. I have looked at a lot of the computer books at my local bookstores but most just seem to be complete beginner books that teach the language, or advance books that assume you know what you are doing. I have tried to search on line for these 'intermediate' type of books, but I have have little luck. I may be using the wrong words to describe what I am looking for, though. Basically, just something to help me move from beginner to intermediate that shows/teaches good programming practices. Any references or suggestions on terms to use when searching would be greatly appreciated. Sorry about the long post.
Avoid that grand negus guy - his 'language' can't even cope with nested conditions!
-
Avoid that grand negus guy - his 'language' can't even cope with nested conditions!
At least he's named himself appropriately. A revolting little aged troll who takes advantage without regard to the consequences.
Software Zen:
delete this; -
Avoid that grand negus guy - his 'language' can't even cope with nested conditions!
Trollslayer wrote, in a petty and unhelpful way:
Avoid that grand negus guy - his 'language' can't even cope with nested conditions!
Actually, the Plain English language is remarkable for both its simplicity and its scope. Designed for both educational and professional use, it is simple enough for a child to learn and yet suitable for writing programs as complex as wysiwyg page editors and native-code generating compilers. And it can recreate itself in less than 3 seconds on a bottom-of-the-line Dell - which attests to the elegance and efficiency of the implementation. The "feature" you mention - and as you well know - was intentionally eliminated to avoid unnecessary complexity. But the reason you give shouldn't discourage the original poster from accepting the offer in any case. After he has learned everything else he can from the product - which is considerable - he can then turn his attention to the syntactical, semantic, and implementation issues involved in "extending" his C# version to include nested conditions. It will give him first-hand experience in the matter so he can decide, for himself, if any qualitative improvement that is realized warrants the additional complexity that this "feature" adds to the system. I'm quite sure that's more than you're offering the guy.
-
Trollslayer wrote, in a petty and unhelpful way:
Avoid that grand negus guy - his 'language' can't even cope with nested conditions!
Actually, the Plain English language is remarkable for both its simplicity and its scope. Designed for both educational and professional use, it is simple enough for a child to learn and yet suitable for writing programs as complex as wysiwyg page editors and native-code generating compilers. And it can recreate itself in less than 3 seconds on a bottom-of-the-line Dell - which attests to the elegance and efficiency of the implementation. The "feature" you mention - and as you well know - was intentionally eliminated to avoid unnecessary complexity. But the reason you give shouldn't discourage the original poster from accepting the offer in any case. After he has learned everything else he can from the product - which is considerable - he can then turn his attention to the syntactical, semantic, and implementation issues involved in "extending" his C# version to include nested conditions. It will give him first-hand experience in the matter so he can decide, for himself, if any qualitative improvement that is realized warrants the additional complexity that this "feature" adds to the system. I'm quite sure that's more than you're offering the guy.
C++/C# will serve his purposes, your languager has structural flaws which render it all but useless.
-
C++/C# will serve his purposes, your languager has structural flaws which render it all but useless.
Trollslayer wrote:
your languager has structural flaws which render it all but useless.
The ultimate test of a general purpose programming language is whether or not it can be used to reproduce itself. In other words: Can a reasonably efficient compiler for the language be conveniently written using nothing but the given language? If so, the rest is "decoration" because the language itself can be used to extend itself in any and every desirable way; nothing else is required. A language like C, for instance, satisfies these conditions; a language like SQL, on the other hand, does not. Plain English passes the test with flying colors. Using fewer than 4000 lines of simple, readable code, our compiler can reproduce itself on a minimal Windows machine in less than 3 seconds. The rest - as I've said - is decoration.
-
Trollslayer wrote:
your languager has structural flaws which render it all but useless.
The ultimate test of a general purpose programming language is whether or not it can be used to reproduce itself. In other words: Can a reasonably efficient compiler for the language be conveniently written using nothing but the given language? If so, the rest is "decoration" because the language itself can be used to extend itself in any and every desirable way; nothing else is required. A language like C, for instance, satisfies these conditions; a language like SQL, on the other hand, does not. Plain English passes the test with flying colors. Using fewer than 4000 lines of simple, readable code, our compiler can reproduce itself on a minimal Windows machine in less than 3 seconds. The rest - as I've said - is decoration.
Agreed, having a language that can re-produce itself is useful. But what if I want to make a quick query to a database and retrieve it's contents? This is more of a communication method then a language.
Brad Australian -CAUTION- The previous statement may contain traces of PHP, and by reading this statement you negate the right to vote me down.
-
Agreed, having a language that can re-produce itself is useful. But what if I want to make a quick query to a database and retrieve it's contents? This is more of a communication method then a language.
Brad Australian -CAUTION- The previous statement may contain traces of PHP, and by reading this statement you negate the right to vote me down.
Bradml wrote:
But what if I want to make a quick query to a database and retrieve it's contents?
Well, then, you'd need a query language or a point-and-click interface to accomodate you. But that language or tool would most likely be programmed in a general purpose language, like "C" or Plain English. And here again, in our opinion, a natural language query facility, would be desirable:
What were the total sales for each division last January?
instead of
SELECT SUM(SALES)
FROM TRANSACTIONS
WHERE MONTH="01"
GROUP BY DIVISION;Yes?
-
Bradml wrote:
But what if I want to make a quick query to a database and retrieve it's contents?
Well, then, you'd need a query language or a point-and-click interface to accomodate you. But that language or tool would most likely be programmed in a general purpose language, like "C" or Plain English. And here again, in our opinion, a natural language query facility, would be desirable:
What were the total sales for each division last January?
instead of
SELECT SUM(SALES)
FROM TRANSACTIONS
WHERE MONTH="01"
GROUP BY DIVISION;Yes?
-
The Grand Negus wrote:
WHERE MONTH="01"
You taught database design, yet you would use a text-based field to indicate a month. Yes, that sounds like you indeed!
J4amieC wrote:
You taught database design, yet you would use a text-based field to indicate a month.
Don't be silly, Jamie. My recommendation appears above the intentionally questionable SQL statement. I was arguing for an approach where such detailed syntactical matters are unimportant or at least hidden from the user. In the Plain English version we refer to the first month of the year simply as "January".
-
J4amieC wrote:
You taught database design, yet you would use a text-based field to indicate a month.
Don't be silly, Jamie. My recommendation appears above the intentionally questionable SQL statement. I was arguing for an approach where such detailed syntactical matters are unimportant or at least hidden from the user. In the Plain English version we refer to the first month of the year simply as "January".
The Grand Negus wrote:
In the Plain English version we refer to the first month of the year simply as "January".
That's cool, now put pen in a box and box in a pen and you will be my hero.
"Throughout human history, we have been dependent on machines to survive. Fate, it seems, is not without a sense of irony. " - Morpheus
-
J4amieC wrote:
You taught database design, yet you would use a text-based field to indicate a month.
Don't be silly, Jamie. My recommendation appears above the intentionally questionable SQL statement. I was arguing for an approach where such detailed syntactical matters are unimportant or at least hidden from the user. In the Plain English version we refer to the first month of the year simply as "January".
-
I apologize if this is the wrong place to ask this. I am still new here. I have been learning programming for a bit and have read through some books to get a basic understanding of languages and program coding. I have read "Accelerated C++" by Koenig/Moo, "Programming Visual C# 2005: The Language" by Donis Marshall, "Microsoft Visual C# 2005 Step-by-Step" by John Sharp. I feel that I have a good understanding of the C# language. I am now in the stages where I want to try to put this knowledge to use and reinforce my understanding. I'm having problems starting, though. I don't know how to 'begin' writing a program. I come up with an idea of a program that I would like to create. I start writing, but end up with just a big mess that doesn't work. In frustration I give up on the project. My code is messy and I run into problems that I didn't foresee and don't know how to tackle them. I've restarted a project a couple times as I seem to code myself into a dead end. I don't really know how to design a program and look ahead for potential pitfalls. I am looking for something that would walk a person through completion of a mildly complex program, starting from the design and planning phase and ending with a final release product. I would prefer if it didn't teach the language, as I have an understanding of that as well as reference books if I don't understand. I have looked at a lot of the computer books at my local bookstores but most just seem to be complete beginner books that teach the language, or advance books that assume you know what you are doing. I have tried to search on line for these 'intermediate' type of books, but I have have little luck. I may be using the wrong words to describe what I am looking for, though. Basically, just something to help me move from beginner to intermediate that shows/teaches good programming practices. Any references or suggestions on terms to use when searching would be greatly appreciated. Sorry about the long post.
What doesn't seem to have been mentioned by anybody is that you need to start with a reasonable understanding of what you are trying to achieve. Pick a problem, e.g. the recipe program, and then try to break it down into the requirements. For instance: The program will store recipes. The recipes will be categorised by type, e.g. Cake. Each recipe will be made up of a number of ingredients. Each ingredient will specify the type of ingredient, e.g. Sugar, and the quantity. And so on. Once you have the requirements, you can break the problem down into smaller logical units. You will also consider issues such as "Where am I going to store the recipes? In a text file, a database?". These will lead you ultimately to the design of your application. Most importantly though, don't give up if you become stuck. Ask questions. Listen to advice. Decide on what works for you.
the last thing I want to see is some pasty-faced geek with skin so pale that it's almost translucent trying to bump parts with a partner - John Simmons / outlaw programmer
Deja View - the feeling that you've seen this post before. -
I apologize if this is the wrong place to ask this. I am still new here. I have been learning programming for a bit and have read through some books to get a basic understanding of languages and program coding. I have read "Accelerated C++" by Koenig/Moo, "Programming Visual C# 2005: The Language" by Donis Marshall, "Microsoft Visual C# 2005 Step-by-Step" by John Sharp. I feel that I have a good understanding of the C# language. I am now in the stages where I want to try to put this knowledge to use and reinforce my understanding. I'm having problems starting, though. I don't know how to 'begin' writing a program. I come up with an idea of a program that I would like to create. I start writing, but end up with just a big mess that doesn't work. In frustration I give up on the project. My code is messy and I run into problems that I didn't foresee and don't know how to tackle them. I've restarted a project a couple times as I seem to code myself into a dead end. I don't really know how to design a program and look ahead for potential pitfalls. I am looking for something that would walk a person through completion of a mildly complex program, starting from the design and planning phase and ending with a final release product. I would prefer if it didn't teach the language, as I have an understanding of that as well as reference books if I don't understand. I have looked at a lot of the computer books at my local bookstores but most just seem to be complete beginner books that teach the language, or advance books that assume you know what you are doing. I have tried to search on line for these 'intermediate' type of books, but I have have little luck. I may be using the wrong words to describe what I am looking for, though. Basically, just something to help me move from beginner to intermediate that shows/teaches good programming practices. Any references or suggestions on terms to use when searching would be greatly appreciated. Sorry about the long post.
-
The Grand Negus wrote:
In the Plain English version we refer to the first month of the year simply as "January".
That's cool, now put pen in a box and box in a pen and you will be my hero.
"Throughout human history, we have been dependent on machines to survive. Fate, it seems, is not without a sense of irony. " - Morpheus
dnh wrote:
That's cool, now put pen in a box and box in a pen and you will be my hero.
I don't know if you're being facetious or not, but in Plain English we would say:
A pen is a thing...
A box is a thing...
To put a pen in a box...Where the first two statements are type definitions, and the third is a routine header. Note that the words "pen" and "box" and "put" are defined in the source code, not the compiler. As are the semantic rules; when asked, for example, to "put the box in the pen" the compiler will say "I don't know how to do that", not because we have a huge dictionary and an even larger database of relational concepts, but simply because the programmer didn't tell the thing how that is accomplished (ie, didn't include a routine for that purpose). Note also that the "names" of the pen and the box when referenced within the routine body (not shown) are simply those: "the pen" and "the box". The need to name objects that are not typically named in real life is eliminated in Plain English.
-
Trollslayer wrote:
your languager has structural flaws which render it all but useless.
The ultimate test of a general purpose programming language is whether or not it can be used to reproduce itself. In other words: Can a reasonably efficient compiler for the language be conveniently written using nothing but the given language? If so, the rest is "decoration" because the language itself can be used to extend itself in any and every desirable way; nothing else is required. A language like C, for instance, satisfies these conditions; a language like SQL, on the other hand, does not. Plain English passes the test with flying colors. Using fewer than 4000 lines of simple, readable code, our compiler can reproduce itself on a minimal Windows machine in less than 3 seconds. The rest - as I've said - is decoration.
-
Thanks for the reply. It actually isn't one specific program, I've tried many. Recipe/cooking software, personal schedule software, scaled down version of word processing, an Othello clone, etc. Ideas will pop into my head that don't seem that complex and I think that I'll be able to actually complete them, but I tend to get stuck and frustrated, mostly due to my lack of planing and design. I'll check out Code Complete. I have also been looking over the articles here at CP, though some of them are way over my head. Hopefully with time I'll be able to understand and even contribute!
hpjchobbes wrote:
mostly due to my lack of planing and design.
Before planning and design comes analysis. The nature of the subject of the software should be understood and pictured first. Sometimes diagrams can be used to accomplish this. For example diagrams like Use Cases, Class diagrams and Activity diagrams found in UML can be used to express the subject’s nature diagrammatically. The pictures of the subject will usually provide a starting point for design. After the initial design that represents the subject, most low level design is technical in nature, meaning it is focused on solving computer software related problems. Most of these problems are solved using well known design patterns[^]. Also research the Model-View-Controller[^] pattern as it is widely used in applications that include a user interface.
led mike
-
dnh wrote:
That's cool, now put pen in a box and box in a pen and you will be my hero.
I don't know if you're being facetious or not, but in Plain English we would say:
A pen is a thing...
A box is a thing...
To put a pen in a box...Where the first two statements are type definitions, and the third is a routine header. Note that the words "pen" and "box" and "put" are defined in the source code, not the compiler. As are the semantic rules; when asked, for example, to "put the box in the pen" the compiler will say "I don't know how to do that", not because we have a huge dictionary and an even larger database of relational concepts, but simply because the programmer didn't tell the thing how that is accomplished (ie, didn't include a routine for that purpose). Note also that the "names" of the pen and the box when referenced within the routine body (not shown) are simply those: "the pen" and "the box". The need to name objects that are not typically named in real life is eliminated in Plain English.
This actually sounds more complicated. Also using the word January, instead of an integer isn't efficient. I still think it has theoretical value, in the area of academia, but in business I can't see it. I can think faster in C# than I can in English at times. The English language frustrates me with its support of invalid logic. Such as the self elimintating statement: This Statement Is False. The language itself is corrupt and only works when the interpreter is on the same page with you. Too much is required to be interpreted. A pen is a thing, doesn't really mean anything. Too general and vague. How do you describe it? How do you determine its functioning? In this case its most likely visual, so an image would be needed, how do you associtate this pen with its image so that when you put it in the box the user can see it? Dunno, I'm trying to understand this some, but am missing it.
What's in a sig? This statement is false. Build a bridge and get over it. ~ Chris Maunder
-
The Grand Negus wrote:
The ultimate test of a general purpose programming language is whether or not it can be used to reproduce itself.
So by definition your compiler is obsolete?
led mike
led mike wrote:
So by definition your compiler is obsolete?
Yes, as you say, the version used to produce the current version is now obsolete, but the current version which is being used now to produce the next version will only become obsolete then. Seriously, however, the neat thing about a natural language compiler is that the earlier "syntax" accepted by the now obsolete compiler is not obsolete because it was English then and it is still English now; in other words, natural languages - in spite of their tendency to mutate - are in some ways more stable than artificial languages (which tend to sudden obsolescence).