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

Originally Posted by MK27

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.

Originally Posted by MK27

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.

Originally Posted by maxorator

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.

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.

Originally Posted by MK27

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.

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.

Originally Posted by Mario F.

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.

Originally Posted by Mario F.

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.

Originally Posted by maxorator

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.

Originally Posted by Mario F.

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

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.

Originally Posted by maxorator

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.

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.