04 Dec, 2011, LeMonseural wrote in the 1st comment:
Votes: 0
I've been playing muds for several year and all of the ones I use to play have vanished over time. I've tinkered with Merc/Godwars/Rom code mostly creating classes and skills (usually looking skills/powers/classes already implemented to create the basic frame of mine) So I decided that I wanted to run my own Godwars type mud (not just open one, rename, add a few skills and call it a modified GW.)

With that being said I picked up a Java book awhile back to get the basic concepts unique to that language as I am a beginner to programming, but I had also saw books on C++/Ruby/Python/and various other languages. My question to the Mudbytes community is what do you think a good language to start out with and learn?
04 Dec, 2011, Rarva.Riendf wrote in the 2nd comment:
Votes: 0
Quote
So I decided that I wanted to run my own Godwars type mud (not just open one, rename, add a few skills and call it a modified GW.)

Quote
With that being said I picked up a Java book awhile back to get the basic concepts unique to that language as I am a beginner to programming


You are doomed to reinvent the wheel, badly.

With that said either pick C if you really want to understand how a computer works, or whatever higher level langage if you want to be productive. (not C++)
Since you say you are a newbie programmer, you would be better off studying a well established codebase, understand how it works and then start tinkering with it. There are codebase in most langage, so pick your poison. since everything is going webbased lately, I suggest you to look for Runters one.
04 Dec, 2011, Kardon wrote in the 3rd comment:
Votes: 0
The one in which you feel most comfortable in learning and will not bog you down with low level details. Java is not a bad language to learn. Ruby, Python and C# are friendly to newcomers as well. I do not however recommend C/C++, which unfortunately is what most of the full featured stock bases are programmed in.

Do not think that most stock bases are programmed in those languages because they are superior. They are antiquated and at the time, C was the only practical language to use due to different constraints. Does this mean I'm telling you never to learn C/C++? No, not at all. Just save it for later, or you may find yourself having a lot of headache in the future trying to wrap your head around basic concepts just because of undefined behavior or some other god-awful issue with low level languages.

Just my two cents. Take it or leave it.
04 Dec, 2011, Deimos wrote in the 4th comment:
Votes: 0
My answer to that question in general is "whichever language A) allows you to implement what you want to implement in the most maintainable and easily modifiable way, and B) you're most familiar with." Of course, since you're new to programming, B isn't applicable and A is rather unhelpful for you. So, my suggestion would be to choose a dynamically typed language, since they're more user friendly for beginners. Java is an excellent language, but statically typed. It does offer garbage collection, so it's one of the friendlier statically typed languages out there.

My personal preference would be Ruby (for its elegance) or Python (for its community).

Languages like Lua, Perl, PHP, etc. are also good candidates, but come up lacking in terms of MUD-related resources. There are a few decent examples out there if you settle on one of these, though.
04 Dec, 2011, LeMonseural wrote in the 5th comment:
Votes: 0
Quote
Java is not a bad language to learn. Ruby, Python and C# are friendly to newcomers as well


The main one I was looking at was Ruby (Teensy) and from the features list and that it is a "startup" type codebase I will go with that. Although Python looks great also, maybe down the line I'll add that under my belt to.

Thanks for you guys input really helped out alot.
05 Dec, 2011, quixadhal wrote in the 6th comment:
Votes: 0
Don't forget to look at LpMUD. While implementing a driver from the ground up is always a "fun" task… it's a bit of a pain to have to rewrite all the socket-fiddling and file-handling stuff for the 97,000th time. If you want to write a game and not a socket server, LPC gives you a sandbox environment that lets you totally rewrite the game system without touching the driver.

If you really want to write a driver though, please use a language that has a string as a built-in type (not C, not C++). 99% of what you do will be to manipulate strings, and having to do it all through functions is just tedious.
05 Dec, 2011, David Haley wrote in the 7th comment:
Votes: 0
If you're going to go the C route, don't use C – use C++. There is no need to subject yourself to reinventing data structures when C++ just gives them to you. Even just C++ strings will make your life far easier.

That said, I agree with those who have said the low-level route isn't necessarily the best anyhow. A lot of conceptions around it for performance are entirely misplaced in this context.

Ultimately, though, you need to learn how to program, and that's a very different question from learning a particular language.

For your immediate goal, you probably want to pick a language that has a large ecosystem around the project you want to do. A language like Lua might be really nice for many things like scripting, but you will not find many resources to get you started in the MUD world that don't assume you already have considerable proficiency. Python and Ruby might have huge ecosystems, but not much specific to MUDs even if there are a few starter-level codebases out there.
05 Dec, 2011, LeMonseural wrote in the 8th comment:
Votes: 0
Quote
Don't forget to look at LpMUD.


Yeah I looked at Dead Souls I believe it was..I've never seen a wizhelp list so big.. It's nice being able to change everything practically right there on the mud.

Quote
Ultimately, though, you need to learn how to program, and that's a very different question from learning a particular language.


I agree. That is why I am using alot of online resources and looking to pick up some "How to" books. I figure with that + trial and error that would help me out greatly.
05 Dec, 2011, Runter wrote in the 9th comment:
Votes: 0
My advice is to actually write code in no matter what language you decide to use. If you treat it solely academic in nature you may end up knowing a lot about the language without having a fluent grasp of the syntax and the tools. In other words, start small, take what you learn, and apply it immediately. You can do it in large projects, but I feel it's far more effective use of your time to write small programs (usually from scratch) just to learn with based on whatever material you're learning from. The creation process for code is important for reinforcing what you learn. It's important because you need to know the tools, and it's important because I don't believe that just reading over code and reviewing the examples in online material or books is enough. So never copy and paste. Always type it yourself and run the code. Even if it's line for line the same. A great idea is to do little things in examples as you type them out like change variable names, function names, etc. These little tweaks themselves are reinforcement you need and proof of understanding. This may seem arbitrary, and it will lead to some spots where you forget to change that i to z, but it's beneficial even when you have to read the error output and track down that variable you forgot. Anyways, that's my 2 cents.
05 Dec, 2011, LeMonseural wrote in the 10th comment:
Votes: 0
Quote
I don't believe that just reading over code and reviewing the examples in online material or books is enough. So never copy and paste. Always type it yourself and run the code. Even if it's line for line the same.


Yeah in the Java book I was using they listed activities at the end of the chapter (also through the chapter you wrote the examples also). Rather than just doing only the two listed activities I'd do like 6-10 more changing them up each time, which helps tremendously.
05 Dec, 2011, David Haley wrote in the 11th comment:
Votes: 0
It's very nice to see somebody who has the patience to do that. :smile: That will save you all kinds of time and pain later on. When I started learning how to program I was a little young and had no patience; as a result several years were spent spinning my wheels not really making a lot of progress until I finally just sat down and did it the right way.
06 Dec, 2011, Tyche wrote in the 12th comment:
Votes: 0
Rarva.Riendf said:
With that said either pick C if you really want to understand how a computer works…


One would not get any more insight on how a computer works by learning C, than by learning either FORTRAN or COBOL.
C is a high-level language that hides how a computer works.
06 Dec, 2011, David Haley wrote in the 13th comment:
Votes: 0
Although Rarva phrased it imprecisely, it should be rather obvious to those seeking to understand the point that you are closer to the OS with C than you are with, say, Ruby.
06 Dec, 2011, Rarva.Riendf wrote in the 14th comment:
Votes: 0
Tyche said:
Rarva.Riendf said:
With that said either pick C if you really want to understand how a computer works…


One would not get any more insight on how a computer works by learning C, than by learning either FORTRAN or COBOL.
C is a high-level language that hides how a computer works.

It certainely hides way less than a langage with a garbage collector.
That is what I meant. You are way closer to the electronics than with any other langage save assembler. And it is way enough to understand how a computer works.
06 Dec, 2011, David Haley wrote in the 15th comment:
Votes: 0
And there I was trying to save you, and you went and said that C lets you understand how a computer works. :sad:
06 Dec, 2011, Rarva.Riendf wrote in the 16th comment:
Votes: 0
David Haley said:
And there I was trying to save you, and you went and said that C lets you understand how a computer works. :sad:

Ok, so tell me what C is hiding from you that prevents any understanding on the logics behind a computer. I do not see any less than assembler after that. Or maybe 'how a computer works' means actually go looking for the actual electronic shematics to know how much memory you have and how t is mapped. (and I have been there and done that in engineer school)
06 Dec, 2011, David Haley wrote in the 17th comment:
Votes: 0
How about everything about virtual memory, paging, caching, disk read efficiency, …

There are any number of things going on with the OS that are completely hidden from you. Even learning assembly isn't teaching you what's going on in there, because, again, the OS is doing an awful lot of work.

And, no, I wasn't going to the level of how the actual hardware works, I know we're talking about software. But there's oodles of stuff in software land that is completely hidden in C.
06 Dec, 2011, Rarva.Riendf wrote in the 18th comment:
Votes: 0
David Haley said:
There are any number of things going on with the OS that are completely hidden from you. Even learning assembly isn't teaching you what's going on in there, because, again, the OS is doing an awful lot of work.

When I learned assembly I had no fancy OS do any stuff for me…(on a 68k). The OS is not always there between you and the hardware, and most of the OS are themselves in C for a reason, it is the humaly readable langage that is closer to it. If you understand C ( I mean as an example not what a loop does, but how the loop itself is executed, meaning where the iterator value is stored in memory, where the jump test is, then you understand how a computer works, and understand why programs in C are causing so much security problem as well)
You will no see that with a higher level langage. Cause most of the langages will hide it from you.
06 Dec, 2011, Tyche wrote in the 19th comment:
Votes: 0
Rarva.Riendf said:
It certainely hides way less than a langage with a garbage collector.
That is what I meant. You are way closer to the electronics than with any other langage save assembler. And it is way enough to understand how a computer works.


No it really isn't.
#include "gc.h"
#include <stdio.h>
int main(int argc, char** argv) {
int i;
int * ary = GC_malloc(sizeof(int) * 10);
for (i = 0; i < 10; ++i) *(ary + i) = i;
for (i = 9; i >= 0; –i) printf("%d\n",*(ary + i));
return 0;
}


ary = Array.new
0.upto(9) {|i| ary[i] = i}
9.downto(0) {|i| puts ary[i] }


The use of C standard library routines like malloc/free is no less opaque than using a popular garbage collector, or using some
other languages new method. That's why C is so damn portable. It shields the programmer from how the operating system works
and how the processor or computer it's running on works (including memory management).
Some would suggest even C's pointer data type abstraction may well make it more difficult to grasp how computers really
work.
06 Dec, 2011, David Haley wrote in the 20th comment:
Votes: 0
Quote
When I learned assembly I had no fancy OS do any stuff for me…(on a 68k). The OS is not always there between you and the hardware, and most of the OS are themselves in C for a reason, it is the humaly readable langage that is closer to it.

OK. But people are talking about which modern OS to write a MUD on with which language, not computers that didn't have OS services.

Quote
If you understand C ( I mean as an example not what a loop does, but how the loop itself is executed, meaning where the iterator value is stored in memory, where the jump test is, then you understand how a computer works, and understand why programs in C are causing so much security problem as well)

Sorry, but I completely disagree with this. When I look at a for loop in C, it doesn't look that different from for loops in any other language. There's nothing special or machine-level about a loop that has an initialization, a test, and an increment.

I think that people tend to assume that the more magic hex incantations you have, the closer you are to what's actually happening. That's true sometimes, but not in the examples given so far here.
You were on the right track IMO at first but now you're basically saying that C is as close to how the computer works as you can get other than assembly, and I simply can't agree with that.

Again, as an example, if you are trying to write high-performance software that works with large amounts of data, not understanding the caching and paging models of the OS can kill you even if you think you're "right at machine level" with C – you really are not, and that's not really in question. There are things happening that you simply aren't controlling.
0.0/78