My understanding for developing a video game, can I get some insight?

Started by
33 comments, last by owiley 8 years ago

Both western languages, countries pretty much next to each other, should be alright.

Now try to translate a language of the Eskimos to a language near the equator, say Mexicans. Eskimos have a huge number of words for 'snow' https://www.princeton.edu/~browning/snow.html A concept alien to Mexicans. Already in English, you'll have major trouble doing the translation, as you simply cannot express every subtlety of the Eskimo snow words.
No matter how hard you try, it won't fit. In addition, any English reader will fail to understand the meaning that an Eskimo intends. The reader simply does not have a matching conceptual frame.

Computer languages are not different. Prolog can only reason about facts and relations, how to put an imperative object-oriented program in there? The concept "assignment" is already alien in it.
I don't see how that counts as "easily transferred".

Similarly, Lua has co-routines, how are you going to "easily transfer" that to assembly language?


I am not saying it can't be done, but I doubt that in general you can make easy transfers. If you can you're lucky, but it's equally possible that the semantic foundation of two languages are so different that it is better to start anew rather than trying to transfer your original idea.

So how do you think these languages work? Each language translate to what the computer understand. I'm not saying noise is language instead when you imply rules to noise you could create language because the rules would transform into some meaning. Every language is translatable that doesn't mean its a one to one translation. One concept that will blow your mind is the ideal that subtraction can be done with just add operation. The ideas are basic things you want to convey. You can should be easily able to translate. Also you mentioned Functional vs OOP here you going on a tangent OOP is not a language but the rule on how to use a given language same with Functional. For instance Procedure vs OOP, C is procedural and C++ is OOP but if one looks closely one can see that you can still implement the same program in any of the two languages. However, C++ might make it easier for some problems. Functional languages are built around solving a problem on the ideal of functional tuning. This isn't to say that procedural programmer can not learn the language and not be able to solve the problem procedurally. They could also learn an opposite program tackle it from another prospective. Prospective is what you having problems with and that is common because some people can see the smaller points and not the larger picture. If you study language you will soon see the whole picture of both small sub parts and large parts. As human continue to invent one must say how was it done in the past. We see that we hardly ever invent thing that bring new concepts not tried. We have cell phones but we can trace back to telephone then telegram and so on.

I'm going to say that a library is not the language you miss understanding what is language and what is created by the language. The language is the things that is allowed to be correct. the statements, the creation of variables, and other features.

CFG is how the language is parsed while this is what the compiler does but what else does the compiler do? It translates. CFG stands for context free grammar not all language are context free. But the cfg will make up the language. Lets look at English what constructs a simple sentence? Subject verb object. But you should ask what makes these parts different and there lies things called grammam rules.

?

On the one hand, I think that you're more or less correct, that you can technically write a program in one language and approximately port it to another language (there are probably exceptions to this, but it's not something I've looked deep into, so any clarification or examples of exceptions would be appreciated). BUT that does not mean that it will work in the same way or have anything resembling a similar layout or architecture. I think if you consider it more close to translating between a language like English and a tonal language like Mandarin, such that one phoneme can have multiple meanings based on the intonation. Yes, you can technically translate between the two, but the translator must have a mastery of both language-styles (tonal and... atonal?) to do so. As such, this is a non-trivial task.

You originally suggested that the translation from one language to another is primarily syntactic, which is where you are less correct. While syntax does differ between languages, many other aspects differ to an equal or greater degree. To assume that rosettacode can substitute practice and experience with a given language is farcical.

Edit: what happened to selective quotes?

Inspiration from my tea:

"Never wish life were easier. Wish that you were better" -Jim Rohn

soundcloud.com/herwrathmustbedragons

Advertisement
So how do you think these languages work? Each language translate to what the computer understand.

Yes, they all translate to some combination of machine instructions.

The common denominator if machine language. That is however not what I see as transfer of implementation between languages. Prolog or Python does not accept machine instructions as valid input.

If you interpret your "once you properly learn the language you would know others as well" as "they all translate to some machine instructions", therefore you know all of them if you know all, I think we're done. I see both "language" and "others" here as languages that we program in. That's where I transfer my programs. The fact that other translations to some machine interpretation exist is not relevant.

Just in case you believe that you can go from language A to machine instructions, and back up to language B, that path is not possible. Machine instructions have so much freedom that the intention of the input is fully lost for automatic translation. Humans can do this, and that's called reverse engineering.

One concept that will blow your mind is the ideal that subtraction can be done with just add operation.

Oh really? You found the unary minus operator, or found 2-complement numbers?

The ideas are basic things you want to convey. You can should be easily able to translate.

My atomic synchronous distributed communication is very basic in my language, I'll await your translation to distributed C.

For instance Procedure vs OOP, C is procedural and C++ is OOP but if one looks closely one can see that you can still implement the same program in any of the two languages.

OOP versus procedural is trivial, I can do that by hand already. I don't consider that convincing proof for "If you properly learn any language you could easily transfer your ideas since all languages have a common foundation."

Please explain how to convert Lua co-routine programs to assembly language, or a Java program to Prolog.

Prospective is what you having problems with and that is common because some people can see the smaller points and not the larger picture. If you study language you will soon see the whole picture of both small sub parts and large parts.

At the University, I graduated in compiler construction, re-implementing a compiler. Id did a PhD on a compiler and run-time system of a translation from a modeling language to a real-time implementation. I have been building about about 10 compilers, and simulators, and a few dozen language transformations the last 20 years. During that time, I have co-operated with researchers, and brought in my CS language design knowledge into their research projects. In several occasions that led to journal papers.

For the last 25 years, I have been living and breathing compilers, languages, grammars (including more advanced grammars than your CFGs), parsers, type checkers, runtime-systems, syntax and language semantics at academic level. I think that qualifies at "studying language" for 25 years.

So far, you seem to believe in nice theories and big words about CFGs, and then come with bold claims that "once you properly learn the language you would know others as well".

I can see your theory working at an abstract form. However, the gap between theory and practice is a lot larger in practice, than the theory suggests. As soon as you drop from the nice abstract high level down into the mud with a Java or C program, your theory will fail. Simple things like an assignment already have different semantics in different languages. Since a CFG is only about syntax and not about semantics, your idea breaks there already. You can fix that in the grammar rules, up to some level, as beyond that, your grammar rules explodes in complexity. You can fold it into an AST, and build a full-blown compiler. In general, you can do a translation, but only for the common subset between the source and the target language. Concepts in the source language that do not exist in the target language are simply not translateable, other than by building an interpreter for the source language into the target language (see theory about T-diagrams). At that point however, you are no longer translating, you have made a software virtual machine that runs the original software. To me that does not count as a translation.

yes the structure will change and there are different syntax and for rossettacode, I would say you could if you understand the problem set better. If you can see the problem at multiple angles then yes you could achieve what you want granted if its possible for the language to be used to solve the problem. I talked about how rules are different from language to language but the answer to the problem is always in the scope of the problem. I say this because programming isn't some magical element it takes skill and understanding. What is nice about language is that we have all been doing it with out realizing it. Language evolve because of this. While mandarin is hard to learn from English speaking point of view but it is possible and the tonal atonal things are something that different in the Languages but there are much more which I know you know.

My underlying point is that when we code on the pc every single language must be converted into machine code either directly or indirectly. That is the nature of computers no matter which language we have that underlying concept will be true till the system changes. I don't think that will ever happen but I must never say never to such things. The thing is every language will have base to work from. Most of our thoughts very complex. It takes us awhile to simplify our thoughts but the he thoughts and meaning behind the thought should stay intact else the universal language would never exist. We have a universal language with math but that don't mean we all use the same symbols it mean the foundation is the same. The same can be said about programming since it is much math based. The idea is if you solve some problem with Language X and Language Y well this should be possible if X and Y hold some fundmental base that will can be used to judge all other features. This is true since all programming language run on a system can be extend into both X and Y.

If you take X and look at it core features and then look at Y core feature you will eventual notice overlapping. Remember when you said that one language don't have assignment well that isn't actually true. For that to be true would mean that the language don't run on any system comprised of processors and ram. The cpu have memory/ cache the ideal of assignment is to not explicitly store values but they will have to be stored regardless of which system you are on. why hide away assignment feature? Well it so happens that it gets abused and forms problems to our very logic and hard to debug for some cases but if there is a rule to when how it should be used we take the problem and contain it we are not correcting it. There is a small difference between corrections and containing.

Bring more Pain

So how do you think these languages work? Each language translate to what the computer understand.

Yes, they all translate to some combination of machine instructions.

The common denominator if machine language. That is however not what I see as transfer of implementation between languages. Prolog or Python does not accept machine instructions as valid input.

If you interpret your "once you properly learn the language you would know others as well" as "they all translate to some machine instructions", therefore you know all of them if you know all, I think we're done. I see both "language" and "others" here as languages that we program in. That's where I transfer my programs. The fact that other translations to some machine interpretation exist is not relevant.

Just in case you believe that you can go from language A to machine instructions, and back up to language B, that path is not possible. Machine instructions have so much freedom that the intention of the input is fully lost for automatic translation. Humans can do this, and that's called reverse engineering.

One concept that will blow your mind is the ideal that subtraction can be done with just add operation.

Oh really? You found the unary minus operator, or found 2-complement numbers?

The ideas are basic things you want to convey. You can should be easily able to translate.

My atomic synchronous distributed communication is very basic in my language, I'll await your translation to distributed C.

For instance Procedure vs OOP, C is procedural and C++ is OOP but if one looks closely one can see that you can still implement the same program in any of the two languages.

OOP versus procedural is trivial, I can do that by hand already. I don't consider that convincing proof for "If you properly learn any language you could easily transfer your ideas since all languages have a common foundation."

Please explain how to convert Lua co-routine programs to assembly language, or a Java program to Prolog.

Prospective is what you having problems with and that is common because some people can see the smaller points and not the larger picture. If you study language you will soon see the whole picture of both small sub parts and large parts.

At the University, I graduated in compiler construction, re-implementing a compiler. Id did a PhD on a compiler and run-time system of a translation from a modeling language to a real-time implementation. I have been building about about 10 compilers, and simulators, and a few dozen language transformations the last 20 years. During that time, I have co-operated with researchers, and brought in my CS language design knowledge into their research projects. In several occasions that led to journal papers.

For the last 25 years, I have been living and breathing compilers, languages, grammars (including more advanced grammars than your CFGs), parsers, type checkers, runtime-systems, syntax and language semantics at academic level. I think that qualifies at "studying language" for 25 years.

So far, you seem to believe in nice theories and big words about CFGs, and then come with bold claims that "once you properly learn the language you would know others as well".

I can see your theory working at an abstract form. However, the gap between theory and practice is a lot larger in practice, than the theory suggests. As soon as you drop from the nice abstract high level down into the mud with a Java or C program, your theory will fail. Simple things like an assignment already have different semantics in different languages. Since a CFG is only about syntax and not about semantics, your idea breaks there already. You can fix that in the grammar rules, up to some level, as beyond that, your grammar rules explodes in complexity. You can fold it into an AST, and build a full-blown compiler. In general, you can do a translation, but only for the common subset between the source and the target language. Concepts in the source language that do not exist in the target language are simply not translateable, other than by building an interpreter for the source language into the target language (see theory about T-diagrams). At that point however, you are no longer translating, you have made a software virtual machine that runs the original software. To me that does not count as a translation.

I don't have to do that since we python compiler and python virtual machine -> this will produce your answer.

compile and find the manual which tells you how each bit/byte will be treated by interpreter

Just cause you have phd don't mean you have the answer to all. This is a new and growing field not something old and well proven. The things I am saying is old and is proven. Its what we are building off of not trying to invent. We are not trying to redesign language to follow zero rules and work like magic. That's a plot out of sci-fi not seen as possible or even probable. The point is we can get to point A to point B with a language we do not want to go from B to A. That would be like giving you one number and telling you to produce the same function that produce that result with out know the input and how the function works. I'm saying you could Have A that produce C and you know that B can also produce some thing C like. Why is this possible.

Bring more Pain

Im looking at more than theory im thinking about how the system would actually work. Im looking at the process. Sure language are complex looking at english and its interesting history. I think and this is really just my take on making it simple in order to run the code something somewhere must get the instruction and then that instruction executes. But you are telling me that each language will be so vastly different that they create new instruction that was actually present for some hardware. So your computers are living and that they have a mind of there own and if we ask it to do something it might do something different each time like while I'm typing it should play random songs and then go to its favorite web site.

So to conclude yes you can translate but will it be nice no it will work like any other language hence why we call it a language I assume.

Bring more Pain

This topic is closed to new replies.

Advertisement