ok what are the rules
-
Pierre Leclercq wrote:
Just out of curiosity, what is your favorite/working programming language?
Plain English, of course.
Pierre Leclercq wrote:
even though that requires a relational<->OO layer.
Not really. The in-house system we've been using for the past eight years is a relational "pagebase" where virtually no unnecessary translations between the stored data and the presentation of that data for viewing and manipulation are made. This particular program is called PERSPECTIVE and was written in Pascal. I can email you a 100-page PDF describing the system if you're interested. Just ask: help@osmosian.com.
The Grand Negus wrote:
Plain English, of course.
What is this? I mean are you kidding, or could you show a link describing it?
-
Pierre Leclercq wrote:
Should we really get back to this kinds of discussions?
No, because I don't want to :zzz: right now :laugh:
I'd like to help but I don't feel like Googling it for you.
Me neither :)
-
ok i'll bite ... do you really consider data hiding, loose coupling, re-use through sane inheritance and function overloading to be bad things? i would have to ask what level of software systems you have worked on but these concepts have been shown to work in the real world for large mc systems ... yet you throw it all away based upon some notion that procedural code is the one true way? classes are procedural code in their member functions ... it's just that the whole entity is wrapped in a "safe" package for consumption really when you say such things as "oo programming is a mistake" you really dont give yourself any credibility here where your audience is largely made up from some of the best programmers in the world sheesh
Here's the short answer, and we can go from there: we've developed a wide variety of major applications - including super-fast native-code compilers and super-smooth wysiwyg page layout programs - conveniently and efficiently without those things. So we haven't found them helpful or necessary. And we're more than willing to share our code and our ideas so others can see another way of doing things. Further comment on objects can be found here in this thread: [^] And further information about why we think our product is important can be found here: [^] Our two-page manifesto is on our website (www.osmosian.com).
-
Here's the short answer, and we can go from there: we've developed a wide variety of major applications - including super-fast native-code compilers and super-smooth wysiwyg page layout programs - conveniently and efficiently without those things. So we haven't found them helpful or necessary. And we're more than willing to share our code and our ideas so others can see another way of doing things. Further comment on objects can be found here in this thread: [^] And further information about why we think our product is important can be found here: [^] Our two-page manifesto is on our website (www.osmosian.com).
-
And that syntax seems better to you?
"oven = new oven(cookie)"
instead of this Plain English code:
Put the cookies in the oven.
which you nearly typed in anyway (as a comment)! C'mon, folks. We're trying to get into the 21st century here...
but saying you cannot avoid the usability of OOP and in a fair bigger scenario like nature (concepts of oop are basically from there if you read them in a bit detail ) supporting one technology is good thing like saying India is great but opposing other is like saying Xyz is not a good country why it is not and how can i say that without any experience of living in Xyz instead saying this shows that Xyz is a great country cause i targeted it and it has some thing great that i am jealous of :)
it is good to be important but it is more important to be good
-
The Grand Negus wrote:
Plain English, of course.
What is this? I mean are you kidding, or could you show a link describing it?
Pierre Leclercq wrote:
The Grand Negus wrote: Plain English, of course. What is this? I mean are you kidding, or could you show a link describing it?
No, all the programs we write now we write in Plain English. The current Plain English development system - including unique interface, simplified file manager, hexadecimal dumper, efficient text editor, native-code-generating compiler/linker, and wysiwyg page-layout facility (for documentation) is written entirely in (the previous version of) Plain English. The entire program is less than a megabyte in size, recompiles itself in less than 3 seconds on a bottom-of-the-line Dell, and requires no installation program or special runtime libraries. Why we think it's an important product is summarized here: [^] Our goals and what you can do to help can be found in the two-page Manifesto on our website: www.osmosian.com.
-
The number one rule is: Sometimes you need to break the rules, including this one.
Matt Gerrans
:laugh: :laugh: :laugh: :laugh: :laugh:
it is good to be important but it is more important to be good
-
:laugh: :laugh: :laugh: :laugh: :laugh:
it is good to be important but it is more important to be good
Good point - never write something that doesn't make sense, because it conforms to some external rule.
Christian Graus - C++ MVP
-
Shog9 wrote:
IMHO, if your team is determined to argue, they'll find something to argue about.
No doubt.
Shog9 wrote:
Orthogonality should be a goal in and of itself - whether the code is orthogonal or procedural.
I use the term in the sense of "keeping separate things separate". It does not seem reasonable to us to hang verbs underneath nouns - or nouns underneath verbs, for that matter. Procedural programming tends to keep the two separate. In one 25,000-line Pascal program we wrote some time ago, for example, we only had two source files, called "nouns" and "verbs". It was a remarkably convenient and effective organization. In case you haven't run across my standard dissertation regarding cookies and ovens and baking, I'll repeat it here: In the object approach, a cookie is an object, and an oven is an object. Fine so far. But should we say "cookie.bake(oven)" or "oven.bake(cookie)" or something else, like "abstract.bake(cookie,oven)". We think all these options are unnatural, and prefer this actual Plain English code:
A cookie is a...
An oven is a...
To bake some cookies in an oven...Where the nouns and the verbs are "related" to the verb in the routine header (the third line above), but do not "hang" underneath each other - or under some artificial abstract class - as they would in the object approach. And we find the syntax much easier to think about, type in, and read, to boot. On a more philosophical note, we all know that cookies don't bake themselves, nor do ovens bake cookies without assistance (as the object model would lead us to believe). Someone bakes cookies in an oven. But the object approach - in great part due to the philosophical orientation of its creator - tries to ignore the existence of the active agent who is necessarily "outside" the system. If you get my drift...
The Grand Negus wrote:
On a more philosophical note, we all know that cookies don't bake themselves, nor do ovens bake cookies without assistance (as the object model would lead us to believe). Someone bakes cookies in an oven. But the object approach - in great part due to the philosophical orientation of its creator - tries to ignore the existence of the active agent who is necessarily "outside" the system. If you get my drift...
As you note, i don't give my oven a list of instructions. The processor for cookies is a human, but this can be implied, and the recipe i write out might well have a bigger focus on nouns (ingredients) than verbs (actions performed on them). In fact, recipes traditionally are written with a very few key verbs, interpreted by context:
Mix: 1/2 cup milk, 3 egg yolks (beaten) 1/4 cup brown sugar Fold in: 3 egg whites (whipped to soft peaks)
Behind this procedural list of instructions, the mechanics of separating eggs, beating the yolks, whipping the whites, the distinction between mixing and folding... is hidden. The differences between measuring milk and brown sugar are assumed to be known by the processor. "measure 1/4 cup brown sugar using brown sugar measuring method" is unnecessary, as the processor knows to use the method appropriate for each ingredient. Polymorphism in action. Correct me if i'm wrong, but it seems that a big part of your argument against OO has to do with the syntax. While i'd agree that there is room for improvement in the syntax used for OO in C-derived languages, i don't find the English sentence structure a particularly appealing substitute. Perhaps this is just my personal taste, but it generally takes me twice as long to write an English description of an algorithm than it does to codify the algorithm in my language of choice (of course, my notes are nominally in English, but as a series of diagrams and brief annotations intended to jog my memory, wholly unsuitable for communicating my ideas with anyone).
---- I just want you to be happy; That's my only little wish...
-
Kevin McFarlane wrote:
Quite harsh but I agree we should avoid deep nesting (McConnell suggess no deeper than 3). But in my experience almost no-one does.
Agreed; almost no-one does. But we do, and we've found it a good idea to do so. And we've written significant programs with no nesting at all to prove the point. We believe it (1) streamlines the design, (2) increases readability, and (3) improves reliability.
When I said almost no-one does this should not be taken to imply that I approve of the practice! :) Most programmers (probably not CPers) are very poor in this regard. But the type of people who post to CP are more likely to be the type of people who care about programming.
Kevin
-
Shog9 wrote:
IMHO, if your team is determined to argue, they'll find something to argue about.
No doubt.
Shog9 wrote:
Orthogonality should be a goal in and of itself - whether the code is orthogonal or procedural.
I use the term in the sense of "keeping separate things separate". It does not seem reasonable to us to hang verbs underneath nouns - or nouns underneath verbs, for that matter. Procedural programming tends to keep the two separate. In one 25,000-line Pascal program we wrote some time ago, for example, we only had two source files, called "nouns" and "verbs". It was a remarkably convenient and effective organization. In case you haven't run across my standard dissertation regarding cookies and ovens and baking, I'll repeat it here: In the object approach, a cookie is an object, and an oven is an object. Fine so far. But should we say "cookie.bake(oven)" or "oven.bake(cookie)" or something else, like "abstract.bake(cookie,oven)". We think all these options are unnatural, and prefer this actual Plain English code:
A cookie is a...
An oven is a...
To bake some cookies in an oven...Where the nouns and the verbs are "related" to the verb in the routine header (the third line above), but do not "hang" underneath each other - or under some artificial abstract class - as they would in the object approach. And we find the syntax much easier to think about, type in, and read, to boot. On a more philosophical note, we all know that cookies don't bake themselves, nor do ovens bake cookies without assistance (as the object model would lead us to believe). Someone bakes cookies in an oven. But the object approach - in great part due to the philosophical orientation of its creator - tries to ignore the existence of the active agent who is necessarily "outside" the system. If you get my drift...
The Grand Negus wrote:
On a more philosophical note
Come on. Have you heard of a guy named Descartes? (I think therefore I am). He did an excellent work thinking about how to think. He developed what is called today the top-down approach. This way of thinking is particularly useful, and has been applied successfully in many disciplines, and led to fruitful solutions. For software it was very useful too. That's the underlying concept for procedural computing. But software remains a discipline with its own particularities. And as projects became larger and larger, it appeared this approach had some drawbacks (especially for evolving the systems). (See Meyer on this). So OOP brings in a very nice concept, I mean bottom-up approach. Top-down remains a must for designing a system, but bottom-up provides extremely valuable features for implementing software systems. (procedural remains useful for small and low level code, but the days of 64k central memory are over)
-
Consider reading this http://www.netobjectives.com/download/Code%20Qualities%20and%20Practices.pdf[^]
Hey, Richard, this looks quite good from a casual glance. I'll print it out and read it tomorrow. I've already read their Design Patterns book.
Kevin
-
Hey, Richard, this looks quite good from a casual glance. I'll print it out and read it tomorrow. I've already read their Design Patterns book.
Kevin
If you require details of related matters then post your needs. Also, note that some time ago I posted details of Microsoft's Architecture Journal. Well, Journal 9 has just been issued. For you and others who might want a hard copy delivered to your home/work address or wishing to download PDF's of all issues of this journal, point your browser at www.architecturejournal.net[^]
-
Consider reading this http://www.netobjectives.com/download/Code%20Qualities%20and%20Practices.pdf[^]
Interesting article - but I have real issues with the first two points.
Developers, Developers, Developers, Developers, Developers, Developers, Velopers, Develprs, Developers!
We are a big screwed up dysfunctional psychotic happy family - some more screwed up, others more happy, but everybody's psychotic joint venture definition of CP
Linkify!|Fold With Us! -
there were few discussions about rules for programming few days ago i am working in a company which is newly started and only two programmers there and no one to guide except CP so what are the rules which you follow and think i should also follow :):)
- Get a grip on the logic of what you are trying to accomplish before you start. ie. Understand exactly what it is you are trying to accomplish
- Use the right tool for the job. Ignore anyone who says you *must* use such-and-such a tool or technique.
- Learn the concepts of programming. Memory management, design patterns, organising your code into the correct peices (objects, procedures, files, namespaces)
- Understand the concepts of the technology you are using. Object oriented, web based, crazy anonymous functions. Learn the tools.
- Write pretty code. Forcing yourself to write good looking code will force you to take a look at the structure, the comments, the way it's broken up, and as a consequence it will be easier for someone else to read and check
- Write comments in code. Relevant comments. Lots of useful, relevant comments.
- Learn to test and debug
- Learn how to rip chunks out of your code and replace it as the specs change. And they will change. Never, ever believe that there is such a thing as a final spec sheet.
- Keep learning.
- Be good to your Mother.
cheers, Chris Maunder
CodeProject.com : C++ MVP
-
- Get a grip on the logic of what you are trying to accomplish before you start. ie. Understand exactly what it is you are trying to accomplish
- Use the right tool for the job. Ignore anyone who says you *must* use such-and-such a tool or technique.
- Learn the concepts of programming. Memory management, design patterns, organising your code into the correct peices (objects, procedures, files, namespaces)
- Understand the concepts of the technology you are using. Object oriented, web based, crazy anonymous functions. Learn the tools.
- Write pretty code. Forcing yourself to write good looking code will force you to take a look at the structure, the comments, the way it's broken up, and as a consequence it will be easier for someone else to read and check
- Write comments in code. Relevant comments. Lots of useful, relevant comments.
- Learn to test and debug
- Learn how to rip chunks out of your code and replace it as the specs change. And they will change. Never, ever believe that there is such a thing as a final spec sheet.
- Keep learning.
- Be good to your Mother.
cheers, Chris Maunder
CodeProject.com : C++ MVP
Chris Maunder wrote:
Get a grip on the logic of what you are trying to accomplish before you start. ie. Understand exactly what it is you are trying to accomplish
This is a fun when the client is vague about their requirements.
I'd like to help but I don't feel like Googling it for you.
-
Where is the hypocrisy in recommending the best we have to offer, on-topic, to someone who is looking for good ideas regarding programming? We wrote the thing for this very purpose; why shouldn't we offer it?
The Grand Negus wrote:
why shouldn't we offer it?
Because it's free advertising in the lounge, or did you forget already? Who stands to get paid if he actually does decide to use PEP?
Jeremy Falcon A multithreaded, OpenGL-enabled application.[^]
-
there were few discussions about rules for programming few days ago i am working in a company which is newly started and only two programmers there and no one to guide except CP so what are the rules which you follow and think i should also follow :):)
Amar Chaudhary wrote:
so what are the rules which you follow and think i should also follow
Ok, here's the general lowdown...
- Code Complete is a great book, this is no exaggeration.
- OOP is nice, but it's not always the answer. Don't be afraid to not use it (they have OOP zealots, that don't know a thing about what they preach), and don't be afraid to use it either (they have procedural zealots, that don't know a thing about what they preach either).
- PEP is a joke. He took a couple of nice ideas, screwed them up badly, and made a cult out of it.
Jeremy Falcon A multithreaded, OpenGL-enabled application.[^]
-
Chris Maunder wrote:
Get a grip on the logic of what you are trying to accomplish before you start. ie. Understand exactly what it is you are trying to accomplish
This is a fun when the client is vague about their requirements.
I'd like to help but I don't feel like Googling it for you.
i coded sitting on the client side and have experience of that there i used to make report out of reports which there existing software cannot produce for one report the back office head sit beside me and give me the details of what is to be done i asked for the complete details for what is to be accomplished he told me to do that part first so i did that took me two days (merging three different reports , taking rates from two different exchanges keeping the record of rates etc) then i approached him with that report for further instructions he see my report and one (main) of the three reports i have merged and compared them the figures were exactly same he said it OK then i asked that why he asked me to calculate that figure which is already in the same report he just blushed after that i take extra care for what is required :):)
it is good to be important but it is more important to be good
-
Amar Chaudhary wrote:
so what are the rules which you follow and think i should also follow
Ok, here's the general lowdown...
- Code Complete is a great book, this is no exaggeration.
- OOP is nice, but it's not always the answer. Don't be afraid to not use it (they have OOP zealots, that don't know a thing about what they preach), and don't be afraid to use it either (they have procedural zealots, that don't know a thing about what they preach either).
- PEP is a joke. He took a couple of nice ideas, screwed them up badly, and made a cult out of it.
Jeremy Falcon A multithreaded, OpenGL-enabled application.[^]
Jeremy Falcon wrote:
PEP is a joke.
I thought that when the Osmosian guys posted those articles some months ago. Couldn't make any sense of the coding and it looked like something I would have gotten agitated over.
I'd like to help but I don't feel like Googling it for you.