Learning programming

[disappoint]

I agree and disagree. Learning logic and flow is the most important part of getting into programming. This does not make you a programmer, but it is something that is essential to becoming one.

When I taught intro programming classes in the past I have had the best success with languages that abstract out the more complex parts of software development. While I feel every good developer should spend some time learning C or C++ and spend some time learning how compilers work. I really think the good fundamentals are best taught on a less forgiving language.

You could learn to ride a motorcycle on a Triumph Speed triple, but maybe it's best to start on something a little easier and less forgiving of your mistakes.

Did you mean less forgiving or more forgiving?

 

[Gerry Rzeppa]

bitdefender shows there being malware on that page? but it also shows that for routers so who knows.

There is no malware in Plain English. Since that "Heartbleed" security flaw was discovered a while back, a lot of anti-virus programs have been tightened up and we've been having trouble with some of them because (1) our source files do not have an extension like ".txt" or ".src" (we thought such things rather unnatural, linguistically speaking); and because (2) our executable does not include all of the superfluous pieces that a typical Microsoft compiler would include -- and is thus mistaken for something suspicious. Time and again we run our stuff through the analyzer at www.virustotal.com to see which anti-virus products object to our code, and time and again we report the false-positives to the various vendors. Since we're a very small company, however, they typically don't even respond -- much less fix the problem. If you run our zip file link (you don't have to download it, just paste in the link) through the analyzer at www.virustotal.com you'll see that about 72% of anti-virus products -- including Microsoft's, Kapersky's, and Symantec's -- say we're virus-free (which we are). I don't know what else to say, except to give you my personal assurance that the code -- source and executable -- is clean.

Here's the link:

www.osmosian.com/cal-3040.zip

 

[Gerry Rzeppa]

We're not going to have this debate in this thread. My note was a moderator action, not a message for you to reply to. There is an existing thread in the forum in which the merits of your idea are already being discussed. By all means make your point there. If you wish to discuss my position on this matter then post a message in the mod discussions forum and I will be happy to address your concerns.

Markbnj
Programming mod

 

[Gryz]

The determining factor to decide whether a programming language is "good", is not whether it is easy to write a program that does what you want. The deciding factor is readability.

That is why perl sucks. It is very easy to write stuff. It's impossible to read and understand it later.

If you want to learn programming, you should start with something simple. Simple, yet still elegant and readable. Java is probably too big a beast to start with. I haven't worked with Java myself. But I have never heard someone I worked with say anything positive about Java. Therefor it might be better to not pick Java as your first language.

I used to be a C programmer myself. Simple syntax. Easy stuff is often more complex in C than it is in more modern languages (especially I/O (Input/Output), string-handling, etc). But when you want to do harder stuff (managing large sets of data, write scalable code, etc) then C actually becomes relatively easier than all those modern languages which do stuff "under the hood".

Maybe you should start with C. But only briefly. Learn if-then-else, for-loops, and while-loops. Learn about functions. Learn about the scope of variables. The basic stuff. Make sure you wrote a few simple programs (simple meaning: 1-5 pages of code per program).

Once you got the very basics of C programming, you can step over to C++ or C##. I don't know C##, so I can't tell you which of the two would be better for a new programmer.

There are 2 styles of programming. Old style, also called "iterative programming". And Object-Oriented programming. OOP has taken over, since more than a decade, I guess. C++/C## and Java are all OOP. You don't want to ignore OOP. But when just starting, it is maybe better to start with old-fashioned C. Just the start. As soon as you "get it", you should switch to an OOP-language. The goal is that you start to think OOP. If you get fluent in old-style iterative programming, it might get harder to get the hang of the style of thinking of OOP.

Or you could just start with Python. Python is a lot more readable than Perl. It has the features of other modern languages (I/O, string-handling, etc). You can do OOP in Python if you wish. I'm just a little afraid that Python will be more overwhelming at the beginning.

 

[SteveGrabowski]

The determining factor to decide whether a programming language is "good", is not whether it is easy to write a program that does what you want. The deciding factor is readability.

That is why perl sucks. It is very easy to write stuff. It's impossible to read and understand it later.

If you want to learn programming, you should start with something simple. Simple, yet still elegant and readable. Java is probably too big a beast to start with. I haven't worked with Java myself. But I have never heard someone I worked with say anything positive about Java. Therefor it might be better to not pick Java as your first language.

I used to be a C programmer myself. Simple syntax. Easy stuff is often more complex in C than it is in more modern languages (especially I/O (Input/Output), string-handling, etc). But when you want to do harder stuff (managing large sets of data, write scalable code, etc) then C actually becomes relatively easier than all those modern languages which do stuff "under the hood".

Maybe you should start with C. But only briefly. Learn if-then-else, for-loops, and while-loops. Learn about functions. Learn about the scope of variables. The basic stuff. Make sure you wrote a few simple programs (simple meaning: 1-5 pages of code per program).

Once you got the very basics of C programming, you can step over to C++ or C##. I don't know C##, so I can't tell you which of the two would be better for a new programmer.

There are 2 styles of programming. Old style, also called "iterative programming". And Object-Oriented programming. OOP has taken over, since more than a decade, I guess. C++/C## and Java are all OOP. You don't want to ignore OOP. But when just starting, it is maybe better to start with old-fashioned C. Just the start. As soon as you "get it", you should switch to an OOP-language. The goal is that you start to think OOP. If you get fluent in old-style iterative programming, it might get harder to get the hang of the style of thinking of OOP.

Or you could just start with Python. Python is a lot more readable than Perl. It has the features of other modern languages (I/O, string-handling, etc). You can do OOP in Python if you wish. I'm just a little afraid that Python will be more overwhelming at the beginning.

I'd personally start off with functional programming, since you learn a lot before having to deal with state. You get the fundamentals down when you don't have to worry about your variable x having different values at different parts of the computation. I think the book SICP is a masterpiece, teaching recursion and functional programming from the beginning. I remember reading in Programming Pearls Vol 1 or 2 that they did an experiment where they went to IBM or HP or something in the mid 80s and gave their programmers 2 or 3 hours to implement binary search, and almost none of them could do it. Because that was the era when recursion was bad and everyone was doing C-style iterations, which makes such a simple algorithm actually somewhat tricky. Whereas you can just write binary search recursively with no state variables in a second as long as you know what the algorithm is. Functional programming just seems like the better way to start since it makes loop invariants trivial and since you can treat your variables like unchanging mathematical objects.

In SICP you do some pretty sophisticated stuff in the first two chapters of the book before you learn the set! procedure that allows you to change the value of a variable.

 

[Maximilian]

Pick something popular... Java and C# are the two most popular languages. Plenty of learning resources for them.

 

[Firetrak]

The determining factor to decide whether a programming language is "good", is not whether it is easy to write a program that does what you want. The deciding factor is readability.

That is why perl sucks. It is very easy to write stuff. It's impossible to read and understand it later.

If you want to learn programming, you should start with something simple. Simple, yet still elegant and readable. Java is probably too big a beast to start with. I haven't worked with Java myself. But I have never heard someone I worked with say anything positive about Java. Therefor it might be better to not pick Java as your first language.

I used to be a C programmer myself. Simple syntax. Easy stuff is often more complex in C than it is in more modern languages (especially I/O (Input/Output), string-handling, etc). But when you want to do harder stuff (managing large sets of data, write scalable code, etc) then C actually becomes relatively easier than all those modern languages which do stuff "under the hood".

Maybe you should start with C. But only briefly. Learn if-then-else, for-loops, and while-loops. Learn about functions. Learn about the scope of variables. The basic stuff. Make sure you wrote a few simple programs (simple meaning: 1-5 pages of code per program).

Once you got the very basics of C programming, you can step over to C++ or C##. I don't know C##, so I can't tell you which of the two would be better for a new programmer.

There are 2 styles of programming. Old style, also called "iterative programming". And Object-Oriented programming. OOP has taken over, since more than a decade, I guess. C++/C## and Java are all OOP. You don't want to ignore OOP. But when just starting, it is maybe better to start with old-fashioned C. Just the start. As soon as you "get it", you should switch to an OOP-language. The goal is that you start to think OOP. If you get fluent in old-style iterative programming, it might get harder to get the hang of the style of thinking of OOP.

Or you could just start with Python. Python is a lot more readable than Perl. It has the features of other modern languages (I/O, string-handling, etc). You can do OOP in Python if you wish. I'm just a little afraid that Python will be more overwhelming at the beginning.

Great response thanks... and it all makes sense theoretically, so i just need to get stuck in i guess.

I'd personally start off with functional programming, since you learn a lot before having to deal with state. You get the fundamentals down when you don't have to worry about your variable x having different values at different parts of the computation. I think the book SICP is a masterpiece, teaching recursion and functional programming from the beginning. I remember reading in Programming Pearls Vol 1 or 2 that they did an experiment where they went to IBM or HP or something in the mid 80s and gave their programmers 2 or 3 hours to implement binary search, and almost none of them could do it. Because that was the era when recursion was bad and everyone was doing C-style iterations, which makes such a simple algorithm actually somewhat tricky. Whereas you can just write binary search recursively with no state variables in a second as long as you know what the algorithm is. Functional programming just seems like the better way to start since it makes loop invariants trivial and since you can treat your variables like unchanging mathematical objects.

In SICP you do some pretty sophisticated stuff in the first two chapters of the book before you learn the set! procedure that allows you to change the value of a variable.

yes i agree WTF haha... kinda get what you are saying. But i really dont understand what you are saying, but sure i will once i start.

Pick something popular... Java and C# are the two most popular languages. Plenty of learning resources for them.

Solid advice thanks

 

[Spungo]

If you've got a Windows computer, you could try Plain English. After all, we know English is going to be around 5 - 10 years down the road!

LISP is 56 years old.
FORTRAN is 57 or so.
C is 42 years old. Lots of languages have tried to replace it, but C is still extremely popular. It must be doing something right.


I say this out of frustration, but it might be a good idea to avoid, for the time being, languages touted as being object oriented. I'm having a really hard time picking up C# because it feels like 90% of it is a complete waste of time. Object oriented programming is probably fantastic when dealing with something gigantic, but it seems to cause more problems than it solves when dealing with small scale things. I would equate it to trying to install hydraulic brakes on a bicycle. It's a kind of needless complexity that makes programming feel like a daunting task that can only be done by the smartest people.

I'll try to demonstrate this by comparing a Perl script I made for printing AutoCAD documents to the way it might be done in C# or Java.
Perl (or C or LISP) reads the way a little kid would describe the problem. It's done in order as a series of vague steps that will be defined later.
-The program starts with a list of variables and a description of each variable.
-The rest of the code is a series of functions and condition statements. There are no classes.
-Functions are lower down in the file, so the script actually starts by using functions that have not yet been written.

# check if the config folder exists. if not, create it.
use_folder($config_folder); 

# try to read the config file. this writes to variable %paths_data
read_paths($paths_file);

# check if the paths in %paths_data are valid
if (check_path($paths_data{autocad_path}) && check_path($paths_data{accoreconsole_path})) {
   print "paths are valid\n";
} else {
   get_autocad_path();
   write_paths($paths_file);
}

# select dsd file (sheet list) to publish
get_dsd_file();

# modify dsd file so it has the date stamp for pdf name
modify_dsd_file();

# create temporary publish script (.scr file)
write_publish_script();

# launch the core console to run the script. delete the temp script when finished:
if (accoreconsole_publish) {
   unlink $dsd_new_path;
   unlink $publish_script;
}

##########
# Functions are defined lower down

It's very easy to follow what's going on. The first 64 lines of the script say what all of the variables are and what the script does. The rest of the script is how it does those things, which brings the total up to 324 lines.
To me, this style of programming makes the most sense.

I know the code can be done like this in C# or Java, but that's not the way people teach it. If you read a C# or Java book, the author will try to create a class for everything, almost like they're trying to model the real world or something. It makes programming feel difficult, and that's not a good thing. Human tend to embrace things that feel easy and avoid things that feel difficult.

A C# or Java book would do the following:
start with the main program, Program.cs
1) Create a Directory class (Directory.cs)
2) Create a File class (File.cs)
3) Create an interface that will be used by Directory and File classes. (IFile.cs)
4) Define the config directory as a Directory object. The path would be an attribute.
5) Define the config file as a File object. The path is an attribute.
6) The "use_folder()" function would be written as a "Use()" method for the Directory class. Or it could be part of a constructor, such as:
Directory myDirectory = new Directory("C:/directory/etc/");
7) We don't want functions dangling out in the middle of nowhere, so we'll make the "read_paths()" function a method as part of a new class called ConfigFile (ConfigFile.cs). The config file is still a file, so we'll set File as the parent class.
8) Undo step 5. Now configFile object is a member of the ConfigFile class, not the File class.
9) I guess we could make autocad_path and accoreconsole_path attributes of the ConfigFile class.
10) Stop and figure out what we're trying to do.
11) We need some kind of method to write the paths data back to the paths file. Maybe make Save() a method of the ConfigFile class. Should we make the method accept variables? I don't know. Who cares. Let's just use some global mutable variable and try to remember what it was.


The problem isn't the language. It's how the language is presented. I could make that same convoluted monstrosity in Perl or Python, but it's less likely to happen because the people teaching those languages don't try to frame things in the most complicated way imaginable.

 

[Gerry Rzeppa]

...it might be a good idea to avoid, for the time being, languages touted as being object oriented.

A nice summary of what's wrong with object-oriented programming can be found here:

http://harmful.cat-v.org/software/OO_programming/why_oo_sucks

 

[Firetrak]

LISP is 56 years old.
FORTRAN is 57 or so.
C is 42 years old. Lots of languages have tried to replace it, but C is still extremely popular. It must be doing something right.


I say this out of frustration, but it might be a good idea to avoid, for the time being, languages touted as being object oriented. I'm having a really hard time picking up C# because it feels like 90% of it is a complete waste of time. Object oriented programming is probably fantastic when dealing with something gigantic, but it seems to cause more problems than it solves when dealing with small scale things. I would equate it to trying to install hydraulic brakes on a bicycle. It's a kind of needless complexity that makes programming feel like a daunting task that can only be done by the smartest people.

I'll try to demonstrate this by comparing a Perl script I made for printing AutoCAD documents to the way it might be done in C# or Java.
Perl (or C or LISP) reads the way a little kid would describe the problem. It's done in order as a series of vague steps that will be defined later.
-The program starts with a list of variables and a description of each variable.
-The rest of the code is a series of functions and condition statements. There are no classes.
-Functions are lower down in the file, so the script actually starts by using functions that have not yet been written.

# check if the config folder exists. if not, create it.
use_folder($config_folder); 

# try to read the config file. this writes to variable %paths_data
read_paths($paths_file);

# check if the paths in %paths_data are valid
if (check_path($paths_data{autocad_path}) && check_path($paths_data{accoreconsole_path})) {
   print "paths are valid\n";
} else {
   get_autocad_path();
   write_paths($paths_file);
}

# select dsd file (sheet list) to publish
get_dsd_file();

# modify dsd file so it has the date stamp for pdf name
modify_dsd_file();

# create temporary publish script (.scr file)
write_publish_script();

# launch the core console to run the script. delete the temp script when finished:
if (accoreconsole_publish) {
   unlink $dsd_new_path;
   unlink $publish_script;
}

##########
# Functions are defined lower down

It's very easy to follow what's going on. The first 64 lines of the script say what all of the variables are and what the script does. The rest of the script is how it does those things, which brings the total up to 324 lines.
To me, this style of programming makes the most sense.

I know the code can be done like this in C# or Java, but that's not the way people teach it. If you read a C# or Java book, the author will try to create a class for everything, almost like they're trying to model the real world or something. It makes programming feel difficult, and that's not a good thing. Human tend to embrace things that feel easy and avoid things that feel difficult.

A C# or Java book would do the following:
start with the main program, Program.cs
1) Create a Directory class (Directory.cs)
2) Create a File class (File.cs)
3) Create an interface that will be used by Directory and File classes. (IFile.cs)
4) Define the config directory as a Directory object. The path would be an attribute.
5) Define the config file as a File object. The path is an attribute.
6) The "use_folder()" function would be written as a "Use()" method for the Directory class. Or it could be part of a constructor, such as:
Directory myDirectory = new Directory("C:/directory/etc/");
7) We don't want functions dangling out in the middle of nowhere, so we'll make the "read_paths()" function a method as part of a new class called ConfigFile (ConfigFile.cs). The config file is still a file, so we'll set File as the parent class.
8) Undo step 5. Now configFile object is a member of the ConfigFile class, not the File class.
9) I guess we could make autocad_path and accoreconsole_path attributes of the ConfigFile class.
10) Stop and figure out what we're trying to do.
11) We need some kind of method to write the paths data back to the paths file. Maybe make Save() a method of the ConfigFile class. Should we make the method accept variables? I don't know. Who cares. Let's just use some global mutable variable and try to remember what it was.


The problem isn't the language. It's how the language is presented. I could make that same convoluted monstrosity in Perl or Python, but it's less likely to happen because the people teaching those languages don't try to frame things in the most complicated way imaginable.

So your saying start with pure C first?

I think it makes sense to just start from the beginning looking at this website http://www.learn-c.org/

Does that seem like a good idea?

I know i specifically need to learn a language that'll give me a basis to learn others.

 

[Spungo]

So your saying start with pure C first?

I don't really know the C language, but the answer is probably yes. After doing lots of programming examples, you'll eventually say "Damn this is complicated. This would be so much easier if I could divide this into classes." That's when you'll be ready for objects. You might even find yourself making things that resemble objects.

 

[lyssword]

start with javascript once you learn how a bit about variables/adding things making things print, move on to java and start learning advanced topics. It's easy to switch from java to c#, not sure about c++, it much much more annoying for noobs (cause of many memory leaks). If you actually learn the principles behind OO(java) language it's possible to make adjustments in other languages (c++/#)

 

[Firetrak]

I think this question is a little like asking whats your favorite colour, everyone seems to have a different one. Which is cool. What a useful thread. I think I will start with C first then go from there.

I'm busy next week or so, but i will check back in and keep you really helpful guys updated.

 

[Smoblikat]

I have a lot of fun with VB.net.

You can download visual studio free from microsoft, and from .net I have learned a lot of vbs and powershell, which is extremely useful if you are in IT.

Im not sure what your goals are, but a good starting program to make in .net is a calculator.

 

[KWiklund]

I agree with those posters who have found object-oriented programming to be a poor starting place. It's useful and valuable, but I don't think of it as a good way to learn programming because it introduces too many concepts at once.

First and foremost, you want to learn how to define problems, break them down and develop a structure for a solution. Traditional procedural programming languages work well for this. Usefully, most popular programming languages derive from this family making it fairly easy to transition from one to the other as needed. The basics of procedural programming also underpin much of what you would be doing in object-oriented languages as well.

That said, if I had to pick one from your list, I would probably recommend C/C++. You can use C++ perfectly well without ever using its object-oriented features, although you do need to be aware of the differences between the two languages if you ever have to write anything in plain C. However, I am not sure that I would say that either of these are great languages from a learning point of view. That they are relatively free-form in how they are written can lead to bad habits. On the whole, I would recommend PASCAL as a good language to begin with since it enforces many good habits. It's not a language that you'll see used very frequently in industry, so if you need to learn something useful right away, I would probably go with C++ or C#.

 

[Spungo]

First and foremost, you want to learn how to define problems, break them down and develop a structure for a solution.

It starts to get interesting when you try to solve the same problems with different approaches.

Here's a problem I've seen multiple times on the internet:
A hallway has a single row of 1000 lockers. All of them are closed initially. The hallway also has 1000 students. The first student changes the state of every locker. Since all of them start closed, that means the first student opens every locker. The second student changes the state of every second locker. Since all of them are open, he closes every second locker. The third student changes the state of every third locker. If it's open, he closes it; if it's closed, he opens it. This continues for all 1000 students. When the process is finished, which lockers are open?
The solution is that only perfect squares have an odd number of factors, so the perfect squares will be open. All other lockers will be closed. The square root of 1000 rounds down to 31, so the answer is 31 open.

When I first tried to solve this problem, I knew lockers with an odd number of factors would be open, but I didn't connect the dots to realize it was a square root thing. I made a while loop inside of a while loop to test if a locker number could be divided by the student number.
This code might be wrong. I'm not going to test it.

my $student = 1;
my $locker = 1;

while ($locker <= 1000) {                #take 1 locker at a time, test all students.
   my $factors = 0;                          #numb of factors for this locker.
   while ($student <= 1000) {            #this loop is extremely inefficient.
      if ($locker % $student == 0) {    #if it evenly divides,
         $factors++;                           #increase the number of factors by 1
      } #/if
   } #/while  
   if ($factors % 2 == 1) {                #if the num of factors cant be divided by 2,
      print "Locker $locker is open\n";  #the locker must be open.
   } #/if
   $locker++;                                 #move on to the next locker
} #/while

Notice that one line is extremely inefficient. Even if it's on locker 1, it will check all 1000 students, which is ridiculous. This code will run a lot faster if it's checking $student <= $locker instead. Then you start realizing a few more things. Factors come in pairs, so we can use that to optimize this. 1x1000 is a pair, 2x500 is a pair. If you know the first number, you can find the second number, and that would save hundreds of iterations because we only need to check the first 499. If we went up to 500, the last pair checked would be 500x2, which is the same as the 2x500 we already checked. Instead of hard coding in the number, we could put that as while ($student < ($locker / 2) ) {......
It can be optimized further to only check up to the square root, but you get the idea.

The problem can also be done using objects with states. Create a class for locker, create 1000 lockers, give it methods (functions) to change the state and to print the state. The code for doing this is about 5x longer than the loops shown above, but it feels a lot more intuitive. C# and Java people would probably approach it using objects.

Another approach would use arrays instead of objects. The index is the locker number and the value is the open/closed state of the locker.

my @lockers;                                                #will be like $lockers[1] = "open".
my @factors;                                                #will be an array of numbers.
$lockers[0] = "invalid";                                   #let's not use locker 0.
foreach my $number (1..1000) {                       #for lockers 1 to 1000,
   $lockers[$number] = "closed";                       #all start closed.
}
foreach my $locker (keys $lockers) {                 #one locker at a time, 0 to 1000
   foreach my $student (1..(int (sqrt 1000))) {     #check students 1 to square root of 1000 rounded down to an integer.
      next if ($locker == 0);                              #locker 0 is not used.
      if ($locker % $student == 0) {                   #if the locker number evenly divides by the student number,
         $lockers[$locker] = change_state($lockers[$locker]);          #define this subroutine later
      } #/if
   } #/foreach student
} #/foreach locker

foreach (@lockers) {                                       #output results
   if ($_ == "open") {
      print "Locker $_ is open.\n";
   }
}


sub change_state {
   my $state = shift;                                       #store the input parameter as $state
   if ($state == "open") {                                #things that are open,
      return "closed";                                        #return closed, or
   } elsif ($state == "closed") {                        #things that are closed,
      return "open";                                         #return open.
   } else {                                                    
      return "invalid";
   }
}

Another interesting riddle to try is this:
37 of men are standing in a circle. They're about to be captured by roman soldiers, so they decide to kill themselves. They decide that every third person will have their head cut off, and this will continue until 1 man remains. The last man can't cut his own head off, so he must stab himself in the heart. Of those 37 men, which one will need to stab himself in the heart? This is one of those problems where using objects makes things a lot easier.

 

[HumblePie]

I started with BASIC back in the day when I was a little kid and my dad was teaching me a bit.

When in highschool taking classes we learned Pascal and C.

In the military my tech school taught me Ada, FORTRAN, and C/C++. For my college degree I was taught Java and VB for my programming classes.

I have taken classes though for various programming languages concerning just about everything under the sun it feels like. I've done professional development in just about everything. Currently I do a lot of C# though with most of my work as that is mainly what the business I work at uses. That and javascript when I do web pages or sharepoint/crm plugins, and not console apps. Oh, then there is SQL, and SRSS reports I do from time to time with the occasion SSIS package.

As a professional developer, depending upon where you live, you may need to be a swiss army knife kind of programmer like me, or you might be one of the "lucky" ones that is silo-ed into one thing and can stick with it.

 

[Firetrak]

I started with BASIC back in the day when I was a little kid and my dad was teaching me a bit.

When in highschool taking classes we learned Pascal and C.

In the military my tech school taught me Ada, FORTRAN, and C/C++. For my college degree I was taught Java and VB for my programming classes.

I have taken classes though for various programming languages concerning just about everything under the sun it feels like. I've done professional development in just about everything. Currently I do a lot of C# though with most of my work as that is mainly what the business I work at uses. That and javascript when I do web pages or sharepoint/crm plugins, and not console apps. Oh, then there is SQL, and SRSS reports I do from time to time with the occasion SSIS package.

As a professional developer, depending upon where you live, you may need to be a swiss army knife kind of programmer like me, or you might be one of the "lucky" ones that is silo-ed into one thing and can stick with it.

Yeah I'm pretty sure i'll have to know many, which is why I wanted to know the best one to start out with.

To answer what my goal is. I used to be in IT full time, but I let it slide for better paying jobs where I just did a small amount of IT.

I'm totally burnt out and fed up and IT is where my heart is. So i'm taking all the tests I need to take, starting with A+, then CCNA, then the MCSE path etc.. all the while i'm doing IT consultant work.

So I figured it would be really good to also at the very least have a basic grasp of programming on top of it all.

 

[Gerry Rzeppa]

Yeah I'm pretty sure i'll have to know many, which is why I wanted to know the best one to start out with.

Once again, Plain English. Why?

1. Because it lets you easily distinguish between programming concepts (types, variables, routines, loops, etc) which are common to all programming languages) and programming syntax (which differs greatly from one language to another).

2. Because it lets you code in a syntax you already know and use every day.

3. Because it's a minimalist, back-to-basics kind of system. Simple to learn, simple to use, simple to compare with other systems.

4. Because it's free.

5. And because it comes with a personal tutor, yours truly, a programming expert who not only knows how to program in many languages, but who knows how to write compilers for those languages.

So I figured it would be really good to also at the very least have a basic grasp of programming on top of it all.

Yours for the asking: gerry.rzeppa@pobox.com

 

[soccerballtux]

I think many here are voting with what they started on.

I think many are CS majors that have little understanding of what the VM and CLR complile to.

I think many CS majors have no idea what makes efficient code. I've seen them write serial or TCP drivers that use events to pull one char at a time. These are people who went to top-5-engineering schools.

I think everyone should start with C. Learn the procedural programming. Object oriented grows naturally out of that. Then, and only then, move to Java or C#. Too many start with OOP and think it's bread and butter. Technically, it is, but you need to understand how to churn milk and knead dough before you're ready for bread and butter. Otherwise you write shit OOP.

In conclusion, people are stupid, I am smart, and my internet chair is high and mighty.

 

[njdevilsfan87]

I think many CS majors have no idea what makes efficient code. I've seen them write serial or TCP drivers that use events to pull one char at a time. These are people who went to top-5-engineering schools.

Efficient coding is something that takes time to develop AFTER you already know the basics. There's always going to be something more complex that you're going to be more interested in just getting working as opposed to spending time making sure it's efficient. Even just identifying code that is repetitive and can be condensed (and knowing how to do it) puts you beyond the introduction stage. And then being very efficient on the fly even with new projects is something that just takes years of experience, imo. I recently rewrote some code from the ground up and was amazed at how much less actual code I needed this time around, compared to the first (and how much quicker I was able to do it). But that's not a skill I developed overnight or anything even near that! And it's not like I had repetitive loops or anything silly like that in the original code.

 

[soccerballtux]

Efficient coding is something that takes time to develop AFTER you already know the basics. There's always going to be something more complex that you're going to be more interested in just getting working as opposed to spending time making sure it's efficient. Even just identifying code that is repetitive and can be condensed (and knowing how to do it) puts you beyond the introduction stage. And then being very efficient on the fly even with new projects is something that just takes years of experience, imo. I recently rewrote some code from the ground up and was amazed at how much less actual code I needed this time around, compared to the first (and how much quicker I was able to do it). But that's not a skill I developed overnight or anything even near that! And it's not like I had repetitive loops or anything silly like that in the original code.

may be, but with C you can C exactly how to make it faster. The CLR in C# is difficult to do much about besides handwave. "That sort of code is generally a bad idea" sort of thing. In C, it's science

 

[Spungo]

(English)
1. Because it lets you easily distinguish between programming concepts (types, variables, routines, loops, etc) which are common to all programming languages) and programming syntax (which differs greatly from one language to another).

I can half agree with what you're saying. By that, I mean you should start programming problems in English or whatever your primary language is. Also start with pencil and paper. Write lists, draw diagrams with arrows. Have a vague description of how the problem should be solved. Once that is done, start writing code.

I've always liked the concept of pseudocode. Vaguely describe the problem before doing anything. Suppose I want to solve that men in a circle problem using an array filled with dictionaries. That's how I would do it in Perl because it avoids using classes and objects.
-create an array called "men", index numbers 0 to 36 (total of 37 men).
-value of each is a dictionary: {"alive", true or false}. all start as true.
-create a "man" counter that starts at 0.
-whenever the man counter increases by 1, use modulus 37 on it so the counter is always in the 0-36 range.
-use the man counter as the array index to run checks on that person, such as: if (${$men[$man]}->{"alive"} == true) { do something }
-the man counter goes up regardless of the person being dead or alive.
-create an "alive" counter that starts at 0.
-do an alive_check() on each person. if they are alive, the alive counter increases by 1 and a kill_check() is done.
-if kill_check() finds the alive counter is now 3, kill that person and set the alive counter back to 0. increase the man counter by 1 to move on to the next person.
-repeat the cycle until everyone is dead.

We have the procedure solved without doing any programming. Now the only thing left to do is get the computer to do these things. That's the difficult part. Even if you have vague step by step instructions that include suggested variable names, you can't write this in C until you've worked with it a little bit.

 

[Pia]

The first programming language I learned was C++. I have taught programming on a bunch of courses at university level, mostly C and C++. Both of them are awful for a first programming language. If you are learning by yourself and don't have quality teaching and support, they are even worse.

It's not the kind of "good pain" that you struggle through and are better for it. Picking one of those as your first language is literally wasting time. Even if you specifically wanted to become a C programmer and had two years to learn, you'd be better off learning programming for a year with Python (which has massively better qualities for a starter language) and only then starting with C.

For class-based learning I actually think Racket/Scheme would be the best starting language, but it is not in common use and the materials are consequently scarce (though some that exist are amazing quality, like "How to Design Programs" aka HtDP, and "Structure and Interpretation of Computer Programs" aka SICP). That's part of why I recommend Python. Another rationale for going with Python is that if you end up moving out of it to primarily use some other language like C#/Java/C++/Scala, then Python will likely remain useful to you for scripting build systems that you use with your primary language, doing data visualization, etc.

For specific circumstances and goals, I think a case could be made for starting with Clojure, Javascript or Ruby; I'm not experienced with any of these but certainly they'd be better than C, C++ or Java. In one very specific circumstance (want to start programming in the context of developing games) C# can also be reasonable because it's what the Unity game engine uses for scripting.

 

[Gerry Rzeppa]

I've always liked the concept of pseudocode... We have the procedure solved without doing any programming. Now the only thing left to do is get the computer to do these things. That's the difficult part.

With Plain English, that "difficult part" is unnecessary because your "pseudocode" actually compiles and runs. You think in English, you code in English, and the compiler does the rest.

You still have to have all the right steps in exactly the right order, of course: it's not magic. And it's a prototype language, so it doesn't yet understand anything and everything a person might say in English. But you can teach it to understand more just by writing new code. And it understands enough so you can write everything from a "Hello, World" program to a complete development system including a native-code-generating compiler. And it definitely eliminates the need to translate your thoughts into something other than your native tongue at the end.

You seem like a bright and curious person, Spungo. I think you'd like Plain English. And I think it would give you some additional insights into what's right and wrong with other languages: why some things seem to work better (and worse) than other things. Here's the instruction manual; you can read it online -- nothing to download, nothing to install: www.osmosian.com/instructions.pdf