Everywhere I look I see people saying that dm is based off of c but recently I have given up coding in java and c# and moved back to the basics to learn Python. I have noticed that python is almost exactly like dm except that byond is more oriented to games and simplicity. Does anyone else here who programs in python agree with me?
Edit: Here is a snippet of some basic code.
import time as t
print "I am Ovan."
yourname = str(raw_input("What is your name? "))
print "Welcome to the world " + yourname + "."
t.sleep(5)
Python also uses a system of incriments similar to the way dm does.
ID:132549
 Jun 17 2010, 4:50 pm
|
|
C++:
cout<<"Hello world!"; DM: world<<"Hello world!" If C++ gets filled with extra line, it'll be exactly same: #define world cout world<<"Hello world!"; All programming languages have similarities, but I'd say DM is more C++ than Python. Prove me otherwise if you think I'm wrong. | |
I haven't gotten far into python but it feels like dm to me. The idea for indentions instead of brackets was a great idea because it makes it far easier to understand and work with.
| |
Akushumi wrote:
I haven't gotten far into python but it feels like dm to me. The idea for indentions instead of brackets was a great idea because it makes it far easier to understand and work with. But that is about as far as the similarities go. The other things you tried to say were similar, I could not see how you find any similarities. The specific other things you mentioned are more similar to C++. | |
I think you're wrong, and it's a matter of paradigm.
No multiple inheritance. No pure virtuals or abstraction. "Light" standard library set compared to a heavy one. Operator overloading. Templating. Strong-typed. No use of the offside-rule in large block statements. Exceptions. Signal traps. No inherent platform independence. And so on. But, I don't need to prove you wrong, as it's your opinion, not a fact of life. Syntax really doesn't define the usability of a language beyond your first 6 months experience with it. | |
@Stephen - Im just saying from what I've seen it's similar and I was just wondering. If I was right. I'm sure that when I get farther in I will understand why it's not if you say it's not. I just recently started learning python yesterday and that's why I said that I haven't gotten far in.
@The other post - Great job being a repeat of what was already said. What you said made no sense. Because your saying what I said sounds more like c++ when the other things I mentioned are from python o.O | |
Seems to me like DM is kind of a bastard child of several different languages, however when it comes to making object based worlds it's fantastic, by far the simplest code I've ever had to work with and as such, I find myself able to do some incredible things with it. The kicker for me was just allowing alpha levels and larger icons (as of recently).
On top of that, a lot of people say that Byond is only a 2d platform. technically, it isn't, it's 3d, however there's no built in engine to get a POV capable of seeing these objects. besides that though, there's no 3d capability for objects themselves, so the world is 3d but the objects are 2d so in all reality, it's capable of 3d, as turning the client to see other directions is possible, though A: directions are limited due to tiles and b: the icons don't have states for each angle or side. however if a lot of work went into it, not only could a POV be made for 3d views, but the 8 directions might be expanded as well as allowing 3D objects in place of icons. imagine it though, even without the 3D objects, the directions and the POV would bring us to the point of making games like Doom, or Quake... kinda. perhaps later on we'll get some of that functionality, maybe with 6.0 or 7.0, maybe later, maybe sooner. who knows? Either way if the code stays simple and the built in engine gets better. we're looking at some serious games in the future. | |
Bravo1 wrote:
it's capable of 3d, as turning the client to see other directions is possible, though A: directions are limited due to tiles and b: the icons don't have states for each angle or side. however if a lot of work went into it, not only could a POV be made for 3d views, but the 8 directions might be expanded as well as allowing 3D objects in place of icons. imagine it though, even without the 3D objects, the directions and the POV would bring us to the point of making games like Doom, or Quake... kinda. I've done that before, but it doesn't make it any more 3D, and it doesn't make it look like Doom. I was helping with a Zelda fangame once upon a time where I included the Zelda "Z-targetting" that was introduced in the N64 Zelda games. I then made it so you could rotate your view around, and that it would automatically rotate to face your target while Z-targetting, and I made it so your view of objects changed properly depending on which side you were viewing, so you could see the backs and sides of objects. This was a nasty pain for large, multi-tile objects since certain parts of the object will actually be in different places depending on your point of view (for example, 2-tile high object with "head" at base.z+1 will be at base.z-1 when viewed from behind). Anyway, it ended up being a big waste of time, because it was not worth it. Being restricted to N,S,E,W directions for viewpoints instead of full 360 degree rotation made it clunky and difficult for players to use. | |
I had made a post stating that I was wrong about something, and that you guys were right, so please, I'm doing it again here, don't take the things I say too seriously unless I specifically say so.
in this case you guys are right, i was just trying to add a skewed opinion, maybe get a laugh or an interesting response. However if I apologize and correct what I said so that people don't misunderstand, then please, do not delete my post, because doing so makes people who read this thread think that I'm serious as they have not seen my return statement, as you have deleted it. so please, unless you want me to look like a jacka$$ then don't delete my post and if you do then I just have to say that you're very spiteful and I'm sorry if I've ever done anything to you, I just hope it doesn't happen again. (and to keep it on topic, my response to this thread: maybe. it depends on your opinion. | |
I see what you mean by the no-braces idea, but it's not one of the first.
In fact, dating back to 1967, Simula was the first actual OO language to practice any anti-curly-brace programming. Then following Simula would be Pascal, then Eiffel, etc, etc. Point being, languages that are similar to DM are all over, but it's just not that interesting to some of us. Kudos on the find, though. | |
'begin' and 'end' are worse braces. Simula, Pascal, and Eiffel don't count.
It's not a matter of not using braces, it's a matter of not requiring special tokens to delimit blocks, other than the indentation that you'd be using with special tokens anyway. | |
I agree, it really cuts down on what exactly you can do with it in some cases, besides that, who wants to actually spend the time typing the words out? yes it's only a mere moment to do so but brackets just save space and time.
| |
It doesn't actually limit the expressiveness of a language - as long as it has block structure and blocks can be arbitrarily nested, whether you do it with {}, begin/end, or just indentation is irrelevant.
The benefit is that even if you use {},begin/end, or some other block delimiter, you'll be indenting. That is, there are two representations of the block structure - one that draws programmer's eyes more than the other, and one that is actually used by the compiler. Having programmers thing about the program structure in a manner subtly different to the compiler is just asking for mistakes. The delimiters aren't necessary. They're mostly just there because it makes compiling easier. Programmers shouldn't have to adapt to match compilers. | |
Bravo1 wrote:
perhaps later on we'll get some of that functionality, maybe with 6.0 or 7.0, maybe later, maybe sooner. who knows? The jump to 3D would make many things more complicated. Limiting games to being 2D tile-based lets BYOND have a lot of useful built-in functionality (movement, density, areas/turfs). If you don't have some limit on what types of games you can develop its hard to create useful, built-in features. I think your best bet for an alternative POV would be to embed a Java applet in a BYOND game. You should be able to get the Java applet talking to a BYOND game with client.Topic and the BYOND game to talk to the applet with output (invoking a JavaScript function that passes data to the applet). | |
that just may work, with that and pixel movement as well as editing pixel_z with movement, you might be able to pull off a ray-cast look perhaps. definitely something to chew on.
| |
If you read through a good Python book you could make the transition with ease, I think. It would be nice to >have a more complete "bible" on everything BYOND but I wouldn't say it's essential. I lol'd when I saw this. I got farther into python and it still feels like DM to me. | |
Dan came up with the indentation-for-braces completely independently of Python. I thought it was brilliant, and was disappointed to know that he wasn't the original founder of the concept. Neither of us had ever used (or even heard of) Python back then.