Hello Friends, I have a question and I needed an experienced programmer to answer me

This is a discussion on Hello Friends, I have a question and I needed an experienced programmer to answer me within the General Discussions forums, part of the Community Boards category; Originally Posted by MK27 That's preposterous. If you want to count your infancy and childhood as time spent learning problem ...

  1. #31
    Reverse Engineer maxorator's Avatar
    Join Date
    Aug 2005
    Location
    Estonia
    Posts
    2,318
    Quote Originally Posted by MK27 View Post
    That's preposterous. If you want to count your infancy and childhood as time spent learning problem solving, okay. But if you are trying to claim that you spend most of your time as a programmer doing problem solving sans coding, I'm kind of curious what kind of programming that amounts to.
    Actually I have spent quite a lot of time doing problem solving. If I can't think of an original problem, I try IOI or USACO tasks.

    Quote Originally Posted by MK27 View Post
    The time it takes to get a basic grasp of "algorithms" as concept if you can program, and you have never heard the word "algorithm" before -- less than one day, most likely less than 1/2 hour.
    In that time you can explain that an algorithm is something that takes input, processes it and gives output. Nothing more. For example how long would it take to thoroughly complete and understand all the chapters of CLRS? And that's only the tip of the iceberg. A very small tip of it.

    The time it takes to understand and implement a particular algorithm -- 10 minutes to two weeks.
    That's assuming you KNOW how to implement it. But algorithms can be very complex - there are problems only a few programmers are able to solve. It's not like reading a novel. It's not like "I have 30% of it figured out. I will figure the rest out tomorrow." Problem solving is trying to tackle the problem in different ways. Sometimes you will spend hours without any breakthroughs. It's science. It's art.

    The time it takes to learn a new language at a basic level -- days to weeks.

    The time it takes to learn something resembling a level of expertise or mastery with a language -- months and years.
    There's only one language to master - the programming logic, or pseudocode, whatever you call it. The rest is details.

    If I can choose between a book about a programming language or a book about algorithms, data structures et cetera, I choose the latter. That's why I've never bought a book about a programming language.
    Last edited by maxorator; 04-25-2010 at 02:18 PM.
    "The Internet treats censorship as damage and routes around it." - John Gilmore

  2. #32
    spurious conceit MK27's Avatar
    Join Date
    Jul 2008
    Location
    segmentation fault
    Posts
    8,300
    Quote Originally Posted by maxorator View Post
    There's only one language to master - the programming logic, or pseudocode, whatever you call it. The rest is details.
    Totally and completely disagree with this, that was my point about python generators (nb, I don't use python personally) and OOP. Pseudocode is a pointless wet paper bag in that case, unless it looks exactly like OOP in a real language. In that case, your pseudo code is not generic -- it could not be used in C/C++, etc.

    Which I guess there is the joke about python being pseudo code. However, I still think knowing some of the "details" about real syntax can save you way more time, and result in much better code, than anything you will get out of sitting around pseudocoding.

    I'm also kind of guessing that 95-99% of what you do is in one language only and always has been, so this is your perspective. I'm gonna say C/C++ is a single language in this sense, because they use the same basic syntax and rules (with slight variation).

    The fact that there are many complex algorithms in the world is interesting, but irrelevant. All you are saying there is that some things are harder than other things. You could spend your entire life just reading about algorithms and never programming at all. Likewise, you could spend your entire life programming and never bother to read about algorithms at all. So there is enough to do in both realms to occupy everyone forever. That does not make it worthwhile in the pursuit of some goal beyond just learning algorithms and churning out code.
    Last edited by MK27; 04-25-2010 at 02:34 PM.
    C programming resources:
    GNU C Function and Macro Index -- glibc reference manual
    The C Book -- nice online learner guide
    Current ISO draft standard
    CCAN -- new CPAN like open source library repository
    3 (different) GNU debugger tutorials: #1 -- #2 -- #3
    cpwiki -- our wiki on sourceforge

  3. #33
    (?<!re)tired Mario F.'s Avatar
    Join Date
    May 2006
    Location
    Portugal
    Posts
    7,510
    I partially agree with max.

    I think that on the subject of programming languages, syntax is the least relevant aspect. They do tend to be grouped into families, so it's fair to assume moving from one family of languages to another may be a bit of a hurdle. (It was a little hard for me to revisit Delphi just last year. The syntax was giving me trouble).

    But I think the real hurdle, where the notion that the programming language matters in the context I think is being debated here, is programming paradigms. That's what can take years to master. And where a switch from one paradigm to another may involve a completely different process to solve the same problem.

    EDIT: As for pseudo-code, I'd drop it as an example, Max. Pseudo-code does not necessarily -- neither it has to -- map to a syntax in any way. It simply describes a process. It has no functional use beyond its descriptive ability.
    Last edited by Mario F.; 04-25-2010 at 02:42 PM.
    The programmer’s wife tells him: “Run to the store and pick up a loaf of bread. If they have eggs, get a dozen.”
    The programmer comes home with 12 loaves of bread.


    Originally Posted by brewbuck:
    Reimplementing a large system in another language to get a 25% performance boost is nonsense. It would be cheaper to just get a computer which is 25% faster.

  4. #34
    Reverse Engineer maxorator's Avatar
    Join Date
    Aug 2005
    Location
    Estonia
    Posts
    2,318
    Quote Originally Posted by MK27 View Post
    The fact that there are many complex algorithms in the world is interesting, but irrelevant. All you are saying there is that some things are harder than other things. You could spend your entire life just reading about algorithms and never programming at all. Likewise, you could spend your entire life programming and never bother to read about algorithms at all. So there is enough to do in both realms to occupy everyone forever. That does not make it worthwhile in the pursuit of some goal beyond just learning algorithms and churning out code.
    You don't have to read that much about algorithms. You can program them. And by doing that you improve your chances of solving the next problem. And by a problem I mean one that needs a creative solution that is not just a copy-paste from an algorithm book. Algorithm books just give you a jump start. They show you how many different ways there are to solve a problem. It's inspiration. No matter how many algorithm books you read, you still have to use your own head if you face a real problem. This means it's not good to only read about them - the best way is to mostly solve problems and sometimes read if you find something that could improve your way of thinking.
    "The Internet treats censorship as damage and routes around it." - John Gilmore

  5. #35
    spurious conceit MK27's Avatar
    Join Date
    Jul 2008
    Location
    segmentation fault
    Posts
    8,300
    Fair enough. I'm not going to press the point because that implies a polemic that I think is a little silly, or that I think studying algorithms is useless, which I don't. And polemics for it's own sake is just entertainment

    However, "problem solving" is not going to help me learn how to program the for the linux kernel or the apache request cycle. That means studying a specific technology, which is more a language oriented task.

    Quote Originally Posted by Mario F. View Post
    But I think the real hurdle, where the notion that the programming language matters in the context I think is being debated here, is programming paradigms. That's what can take years to master. And where a switch from one paradigm to another may involve a completely different process to solve the same problem.
    And paradigms are essentially artifacts of languages, which is why I used the OOP example.

    Pseudo-code does not necessarily -- neither it has to -- map to a syntax in any way. It simply describes a process. It has no functional use beyond its descriptive ability.
    I'd rather see examples/description in any real language rather than pseudo code, to be honest. I've done the Java "hello world" afternoon because of that. Maybe when I find a real machine with paper tape sliding back and forth and "TURING" stamped on the side I'll change my mind. Which is not to say that turing completeness is not an entertaining thing to contemplate, but please: when was the last time this contemplation meant anything to a piece of code you wrote?

    Most of all, my motive for feeling this way is a conviction that using more than one language seriously, in earnest, regularly, provides a bigger perspective than not doing so. That implies you learn something from the language and the way it works. I learnt a lot about perl by learning C, and a lot about C++ from perl. I am not a platonist, so I don't really see the significance or value of contemplating an "ur-sprach", either wrt to human or artificial languages; to me it's better to focus on C/C++ or perl rather than on the possibility of this "one language to master - the programming logic". It's not a necessary concept at all, nothing is accomplished pursuing it, and reifying it probably even worse.
    Last edited by MK27; 04-25-2010 at 03:38 PM.
    C programming resources:
    GNU C Function and Macro Index -- glibc reference manual
    The C Book -- nice online learner guide
    Current ISO draft standard
    CCAN -- new CPAN like open source library repository
    3 (different) GNU debugger tutorials: #1 -- #2 -- #3
    cpwiki -- our wiki on sourceforge

  6. #36
    Reverse Engineer maxorator's Avatar
    Join Date
    Aug 2005
    Location
    Estonia
    Posts
    2,318
    Quote Originally Posted by Mario F. View Post
    EDIT: As for pseudo-code, I'd drop it as an example, Max. Pseudo-code does not necessarily -- neither it has to -- map to a syntax in any way. It simply describes a process. It has no functional use beyond its descriptive ability.
    Actually my point was that if you know how to describe a process, you're only a small step away from programming it. So basically: "mastering pseudocode" = learning how to describe processes = learning how to solve problems. It's a metaphor.
    "The Internet treats censorship as damage and routes around it." - John Gilmore

  7. #37
    (?<!re)tired Mario F.'s Avatar
    Join Date
    May 2006
    Location
    Portugal
    Posts
    7,510
    Quote Originally Posted by maxorator View Post
    Actually my point was that if you know how to describe a process, you're only a small step away from programming it. So basically: "mastering pseudocode" = learning how to describe processes = learning how to solve problems. It's a metaphor.
    Ok, I can see your point. Taken.

    Just one pet pevee though. Pseudo-code has been, at least for me, only useful after the fact; as a means to describe to others a found and tested solution. I never, that I remember, even once used pseudo-code during the analysis stage.

    In retrospect, having worked integrated in teams for maybe 90% of my career, I could find that curious. Can it be that not even once I felt the need to describe to my team mates a possible solution to a problem, or them to me? The answer is yes, of course. But that has been done always through code. Pseudo-code couldn't help us, really. It would just get in the way. We would then have to map that to the programming language and test. And what if the solution is not ideal? Go back to pseudo-code?

    Pseudo-code doesn't really help you reach a solution; it simply describes it, after the fact. It's a good publishing tool. The ability to solve the problem is tied to the programming language, your knowledge of it and how well you dominate the programming paradigm you propose solving the problem with.

    Pseudo-code in programming is the equivalent of English in aeronautics. It is great to explain how planes fly, but you needed math to actually find why they fly.
    Last edited by Mario F.; 04-25-2010 at 05:17 PM.
    The programmer’s wife tells him: “Run to the store and pick up a loaf of bread. If they have eggs, get a dozen.”
    The programmer comes home with 12 loaves of bread.


    Originally Posted by brewbuck:
    Reimplementing a large system in another language to get a 25% performance boost is nonsense. It would be cheaper to just get a computer which is 25% faster.

  8. #38
    spurious conceit MK27's Avatar
    Join Date
    Jul 2008
    Location
    segmentation fault
    Posts
    8,300
    Quote Originally Posted by Mario F. View Post
    Pseudo-code has been, at least for me, only useful after the fact; as a means to describe to others a found and tested solution. I never, that I remember, even once used pseudo-code during the analysis stage.

    In retrospect, having worked integrated in teams for maybe 90% of my career, I could find that curious.
    Pretty interesting, but makes sense. AND I'd wager that it's true for 90% of other programmers. Like I said:

    I'd rather see examples/description in any real language rather than pseudo code, to be honest. I've done the Java "hello world" afternoon because of that. Maybe when I find a real machine with paper tape sliding back and forth and "TURING" stamped on the side I'll change my mind.

    I am not a platonist, so I don't really see the significance or value of contemplating an "ur-sprach", either wrt to human or artificial languages; to me it's better to focus on C/C++ or perl rather than on the possibility of this "one language to master - the programming logic". It's not a necessary concept at all, nothing is accomplished pursuing it, and reifying it probably even worse.
    That's not to say there is no such thing as logic, just that you have it PERFECTLY incorporated right there in the/a real programming language. ABSTRACTING anything from that and trying to refer to the "universal logic of programming" in terms of some language that no one uses to program with seems misguided to me (that is, a heritage of Platonism, which infects many of our institutions at the highest level). Those real languages are the product of applied logic.* I'd also bet dollars to donuts that Anglo-American philosophy (which is very logic centric) has completely collapsed as a field since I was in university because all those new students would rather study programming in a post WWW world. Abstract pure logic is a dead horse of some sort. Probably a unicorn or Pegasus.

    * so put on your pompous ass coat when you stray from that, please
    Last edited by MK27; 04-25-2010 at 05:45 PM.
    C programming resources:
    GNU C Function and Macro Index -- glibc reference manual
    The C Book -- nice online learner guide
    Current ISO draft standard
    CCAN -- new CPAN like open source library repository
    3 (different) GNU debugger tutorials: #1 -- #2 -- #3
    cpwiki -- our wiki on sourceforge

  9. #39
    Reverse Engineer maxorator's Avatar
    Join Date
    Aug 2005
    Location
    Estonia
    Posts
    2,318
    Pseudocode is what's in your head before you translate it into a specific programming language. At least this is the way it works for me. I never think of a problem in the context of a specific language. But when I need to write it, I always use a real programming language.
    "The Internet treats censorship as damage and routes around it." - John Gilmore

  10. #40
    spurious conceit MK27's Avatar
    Join Date
    Jul 2008
    Location
    segmentation fault
    Posts
    8,300
    Quote Originally Posted by maxorator View Post
    Pseudocode is what's in your head before you translate it into a specific programming language. At least this is the way it works for me. I never think of a problem in the context of a specific language. But when I need to write it, I always use a real programming language.
    Again, I'm guessing that when you say "I always use a real programming language" you mean C/C++ 95% or more of the time. I'm not knocking that, I'm just suggesting something about the nature of the "pseudocode" in your head. This idea about "translation" sounds very artificial/false to me. That's like saying, I don't think in English, I think in ur-sprach, then I translate it into English when I talk. There is some truth to that, but it is not so clean cut. And in fact, it's mostly English.

    I think if you had to work in a number of (high level) languages all the time, you might find you tend to approach (significant aspects of) a problem in terms of the language you are suppose to use at the time (eg: class or no class? generator or no generator? regexp or no regexp?). If it's always the same language, you won't notice this.

    There are similarities and there are differences. The desire to reduce or eliminate the differences is misguided(/Platonic) -- you loose possibilities there. Hence, "reductionism". It does have a place, but it's limited. Like pseudocode.

    I'd rather think in C/C++ (or perl, etc) than think in pseudocode.
    Last edited by MK27; 04-25-2010 at 06:31 PM.
    C programming resources:
    GNU C Function and Macro Index -- glibc reference manual
    The C Book -- nice online learner guide
    Current ISO draft standard
    CCAN -- new CPAN like open source library repository
    3 (different) GNU debugger tutorials: #1 -- #2 -- #3
    cpwiki -- our wiki on sourceforge

  11. #41
    Super Moderator VirtualAce's Avatar
    Join Date
    Aug 2001
    Posts
    9,596
    I never think of a problem in the context of a specific language.
    This much I agree with. When it comes to figuring out the general solution or approach to a problem that is not a language specific issue. However at some point the design becomes implementation and at that point the programmer must figure out how to implement said solution or approach in the language of choice. So at some point the problem does become a language specific issue. It does not mean the problem can not be solved and thus the solution implemented in other languages but it does mean you, as the programmer, must figure out how to implement said algorithm in a specific language. Sometimes the approach does become language specific for language specific issues such as performance, memory management, etc,. etc. Sure the algorithm and solution is the same but the impl of it is prob very different from language to language.

    So for me during design I would wholly agree you would never think of the problem in terms of language A or B. But during implementation there comes a point at which one must think of the problem in terms of language A or B in order to be effective. Personally pseudo-code has never helped me one bit. I find UML class diagrams much more informative and also prefer sequence diagrams over pseudo code.

    But alas we digress from the topic. Back to the OP's original question. The general consensus here is that you can indeed become a programmer if you so desire. If you are young and about to enter your college years then go for it and study CS or EE. If you are older and not able to do this then you could do some online classes, create a personal portfolio of your best at-home projects to show what you can do, and then send out your resume to companies that fit the bill for you. Probably the biggest hurdle in programming yet also the biggest help is what you see here in this thread. You can't get two or more programmers in the same room to agree on everything nor agree on very many things. However it is my opinion that this kind of banter and going back and forth in a team atmosphere produces some very good software in the end provided there is leadership and guidance along the way. At some point compromises must be made and as the team begins to focus on the same goal whilst everyone puts forth their best efforts that is where magic happens. Software development is primarily about teamwork and being a team player.
    Last edited by VirtualAce; 04-25-2010 at 09:00 PM.

  12. #42
    Registered User Sharke's Avatar
    Join Date
    Jun 2008
    Location
    NYC
    Posts
    303
    I meddle with code off and on in my spare time and really enjoy it. Oftentimes I've thought about whether or not I could eventually get good enough to actually work as a coder, but to be honest I have absolutely no idea what programming jobs actually entail, as in what they expect you to know, how fast they expect you to work, what kind of paradigms you should have under your belt etc.

    Part of my problem is that aside from reading the occasional book and getting the syntax down, I've pretty much learned how to construct programs through trial and error. As a result, I have absolutely no confidence that if I showed one of my programs to a professional programmer, he wouldn't look at it and laugh. Years ago I learned how to program with AMOS on the Amiga. The manual pretty much just went through the syntax and the commands one by one and yet I managed to piece together a pretty major application with a funky GUI that I programmed completely from scratch. All the algorithms in the program were the result of brute force thinking and I have no idea whether I was being really clever, or way off.

    I'm just starting to read Steve McConnell's excellent "Code Complete" and that's giving me some more confidence in terms of knowing how things are done in the professional world...conventions, paradigms, style etc. It also gives you an insight into how development teams work. I know I'll never have time to go to college, I'm 37 and running a pretty time intensive business (which is why I got back into coding, to write some console based programs in C to help me with the employee scheduling and the books etc). And although I still think of myself as a complete newbie, I have just managed to get through all 27 of the excellent "Programming Paradigms" lectures on Stanford's YouTube channel, which made me realize that I have a deeper facility with C (and even Scheme!) than I ever thought I had. I'm pretty sure a sizable proportion of working programmers were self taught, so there's hope for me yet!

Page 3 of 3 FirstFirst 123
Popular pages Recent additions subscribe to a feed

Tags for this Thread


1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21