• Announcements

    • khawk

      Download the Game Design and Indie Game Marketing Freebook   07/19/17

      GameDev.net and CRC Press have teamed up to bring a free ebook of content curated from top titles published by CRC Press. The freebook, Practices of Game Design & Indie Game Marketing, includes chapters from The Art of Game Design: A Book of Lenses, A Practical Guide to Indie Game Marketing, and An Architectural Approach to Level Design. The GameDev.net FreeBook is relevant to game designers, developers, and those interested in learning more about the challenges in game development. We know game development can be a tough discipline and business, so we picked several chapters from CRC Press titles that we thought would be of interest to you, the GameDev.net audience, in your journey to design, develop, and market your next game. The free ebook is available through CRC Press by clicking here. The Curated Books The Art of Game Design: A Book of Lenses, Second Edition, by Jesse Schell Presents 100+ sets of questions, or different lenses, for viewing a game’s design, encompassing diverse fields such as psychology, architecture, music, film, software engineering, theme park design, mathematics, anthropology, and more. Written by one of the world's top game designers, this book describes the deepest and most fundamental principles of game design, demonstrating how tactics used in board, card, and athletic games also work in video games. It provides practical instruction on creating world-class games that will be played again and again. View it here. A Practical Guide to Indie Game Marketing, by Joel Dreskin Marketing is an essential but too frequently overlooked or minimized component of the release plan for indie games. A Practical Guide to Indie Game Marketing provides you with the tools needed to build visibility and sell your indie games. With special focus on those developers with small budgets and limited staff and resources, this book is packed with tangible recommendations and techniques that you can put to use immediately. As a seasoned professional of the indie game arena, author Joel Dreskin gives you insight into practical, real-world experiences of marketing numerous successful games and also provides stories of the failures. View it here. An Architectural Approach to Level Design This is one of the first books to integrate architectural and spatial design theory with the field of level design. The book presents architectural techniques and theories for level designers to use in their own work. It connects architecture and level design in different ways that address the practical elements of how designers construct space and the experiential elements of how and why humans interact with this space. Throughout the text, readers learn skills for spatial layout, evoking emotion through gamespaces, and creating better levels through architectural theory. View it here. Learn more and download the ebook by clicking here. Did you know? GameDev.net and CRC Press also recently teamed up to bring GDNet+ Members up to a 20% discount on all CRC Press books. Learn more about this and other benefits here.
Sign in to follow this  
Followers 0
Nathan2222_old

What's in a language that makes you like it

64 posts in this topic

To me, Flexibility in a languages approach are the most fun. I wrote a lot of PHP in my profession, and what I like about it is there is always something new about the language to discover. Whether it's a complete paradigm shift or just a minute change that rocks your world, PHP is the reeses peanut butter cup of programming languages: there's no 'wrong way'. 

 

I don't like something that in of itself IS the framework, I want to write in a language that can CREATE frameworks. Getting close to the metal is a thrill.

 

 

But ultimately I just like something thats clean and makes sense to read. Growing up I've gotten very used to ECMA Syntax through Javascript and Actionscript2; Java syntax and style through Java, Actionscript 3, and C#; and C like syntax through .. well C and C++ and the tones of C style scripting languages out there.

 

Python hasn't been very good at making me look at it and think "man that's beautiful I should use that" even though that's it's primary goal. Ruby as well just doesn't make a lot of sense to me on the surface. But that style of language just isn't MY style is all heh

0

Share this post


Link to post
Share on other sites

To me, Flexibility in a languages approach are the most fun. I wrote a lot of PHP in my profession, and what I like about it is there is always something new about the language to discover. Whether it's a complete paradigm shift or just a minute change that rocks your world, PHP is the reeses peanut butter cup of programming languages: there's no 'wrong way'. 

 

I don't like something that in of itself IS the framework, I want to write in a language that can CREATE frameworks. Getting close to the metal is a thrill.

 

 

But ultimately I just like something thats clean and makes sense to read. Growing up I've gotten very used to ECMA Syntax through Javascript and Actionscript2; Java syntax and style through Java, Actionscript 3, and C#; and C like syntax through .. well C and C++ and the tones of C style scripting languages out there.

 

Python hasn't been very good at making me look at it and think "man that's beautiful I should use that" even though that's it's primary goal. Ruby as well just doesn't make a lot of sense to me on the surface. But that style of language just isn't MY style is all heh

 

agreed.

 

I am not much of a fan of Python, Ruby, or Lua syntax either.

of these, Lua seems to be the less bad option though...

 

I prefer C mostly for its power, and C++ has some nice features to add onto this.

 

Java has a nice syntax in some ways, albeit it is at times a bit verbose and cumbersome, and its ability to interface with native code is notably not-so-good.

 

C# is also pretty good, but its tool support isn't quite so great on non-Windows targets.

 

a few times I am also wishing that either it would support a few more of the missing C features, or provide operator overloading to make them easier to fake. for example, I like being able to fill array members via "*t++=...;", however, in C# it is necessary to either wrap it and use a method call, or to use real pointers and need to mark the code as unsafe.

 

well, and the ability to call static methods via an object instance (like with virtual methods) would be nice.

 

 

a drawback of C, C++, Java, and C#, is the general absence of implementations providing the ability to compile them dynamically at runtime.

I suspect this is likely one of the major motivators for the use of both a compiled language and a scripting language in the same project.

 

there is some difficulty though (in a language design and implementation sense) in trying to make a language that works equally well as both an implementation language and a scripting language.

0

Share this post


Link to post
Share on other sites

a drawback of C, C++, Java, and C#, is the general absence of implementations providing the ability to compile them dynamically at runtime.

I suspect this is likely one of the major motivators for the use of both a compiled language and a scripting language in the same project.

 

there is some difficulty though (in a language design and implementation sense) in trying to make a language that works equally well as both an implementation language and a scripting language.

 

 

See Roslyn which enables things like ScriptCS.

0

Share this post


Link to post
Share on other sites

After using a few languages I've come to the conclusion that closures and lambda expressions are one of the key things required in a language. Objects are important (but not inheritance or polymorphism). Strong typing with optional weak typing of objects is important. For speed having access to stack and heap allocation (with pointers) and being able to reinterpret memory for low level optimization is useful. (Especially when doing anything with binary). Other than good threading support and operator overloading not much else is required. Syntactically I prefer mandatory braces using a C# style for the standard library. Inline JSON syntax is also important. I'd be pretty fine if JS and C# had a baby that was raised by C++. There's still obviously feature missing. Having attributes that support lambda expressions being one. Also having a language that supports adding parser rules inline. Like including modules that adds language features for specific applications or syntactic sugar. I digress, also SIMD intrinsics built into the language.

Edited by Sirisian
0

Share this post


Link to post
Share on other sites

To me, Flexibility in a languages approach are the most fun. I wrote a lot of PHP in my profession, and what I like about it is there is always something new about the language to discover. Whether it's a complete paradigm shift or just a minute change that rocks your world, PHP is the reeses peanut butter cup of programming languages: there's no 'wrong way'. 
 
I don't like something that in of itself IS the framework, I want to write in a language that can CREATE frameworks. Getting close to the metal is a thrill.
 
 
But ultimately I just like something thats clean and makes sense to read. Growing up I've gotten very used to ECMA Syntax through Javascript and Actionscript2; Java syntax and style through Java, Actionscript 3, and C#; and C like syntax through .. well C and C++ and the tones of C style scripting languages out there.
 
Python hasn't been very good at making me look at it and think "man that's beautiful I should use that" even though that's it's primary goal. Ruby as well just doesn't make a lot of sense to me on the surface. But that style of language just isn't MY style is all heh

 
there is some difficulty though (in a language design and implementation sense) in trying to make a language that works equally well as both an implementation language and a scripting language.

maybe it's better to not have a compiled scripting language.
0

Share this post


Link to post
Share on other sites

 

 

To me, Flexibility in a languages approach are the most fun. I wrote a lot of PHP in my profession, and what I like about it is there is always something new about the language to discover. Whether it's a complete paradigm shift or just a minute change that rocks your world, PHP is the reeses peanut butter cup of programming languages: there's no 'wrong way'. 
 
I don't like something that in of itself IS the framework, I want to write in a language that can CREATE frameworks. Getting close to the metal is a thrill.
 
 
But ultimately I just like something thats clean and makes sense to read. Growing up I've gotten very used to ECMA Syntax through Javascript and Actionscript2; Java syntax and style through Java, Actionscript 3, and C#; and C like syntax through .. well C and C++ and the tones of C style scripting languages out there.
 
Python hasn't been very good at making me look at it and think "man that's beautiful I should use that" even though that's it's primary goal. Ruby as well just doesn't make a lot of sense to me on the surface. But that style of language just isn't MY style is all heh

 
there is some difficulty though (in a language design and implementation sense) in trying to make a language that works equally well as both an implementation language and a scripting language.

maybe it's better to not have a compiled scripting language.

 

 

That has nothing to do with it.  A scripting language is like a first aid kit - it provides a simple way to get basic tasks done and it's not intended to write complicated programs. just like a first aid kit is not intended to be used for surgery.  And therein lies the problem, if you keep the language basic you can't use it easily for writing an OS (for example), if you make the language too complicated, the scripts become far too much for the program trying to run them.

0

Share this post


Link to post
Share on other sites

To me, Flexibility in a languages approach are the most fun. I wrote a lot of PHP in my profession, and what I like about it is there is always something new about the language to discover. Whether it's a complete paradigm shift or just a minute change that rocks your world, PHP is the reeses peanut butter cup of programming languages: there's no 'wrong way'. 
 
I don't like something that in of itself IS the framework, I want to write in a language that can CREATE frameworks. Getting close to the metal is a thrill.
 
 
But ultimately I just like something thats clean and makes sense to read. Growing up I've gotten very used to ECMA Syntax through Javascript and Actionscript2; Java syntax and style through Java, Actionscript 3, and C#; and C like syntax through .. well C and C++ and the tones of C style scripting languages out there.
 
Python hasn't been very good at making me look at it and think "man that's beautiful I should use that" even though that's it's primary goal. Ruby as well just doesn't make a lot of sense to me on the surface. But that style of language just isn't MY style is all heh

 
there is some difficulty though (in a language design and implementation sense) in trying to make a language that works equally well as both an implementation language and a scripting language.

maybe it's better to not have a compiled scripting language.
 
That has nothing to do with it.  A scripting language is like a first aid kit - it provides a simple way to get basic tasks done and it's not intended to write complicated programs. just like a first aid kit is not intended to be used for surgery.  And therein lies the problem, if you keep the language basic . . . if you make the language too complicated, the scripts become far too much for the program trying to run them.
so you can have a compiled scripting language? I thought they should be interpreted so that you can do things at runtime.

you can't use it easily for writing an OS (for example)

;)
0

Share this post


Link to post
Share on other sites


so you can have a compiled scripting language? I thought they should be interpreted so that you can do things at runtime.

 

I wasn't trying to say that scripting languages could be compiled, just that that isn't the reason why it's hard to write a single language that's good for both scripting and writing applications.  That being said, there's no inherent reason that user created scripts couldn't be compiled.   It's just not normal.

0

Share this post


Link to post
Share on other sites

so you can have a compiled scripting language? I thought they should be interpreted so that you can do things at runtime.


A number of scripting languages (including Lua) do offer the ability to compile to bytecode, and in fact a text chunk will be compiled on the fly when it is loaded. Then there are things like LuaJIT which is a re-implementation of the VM and a just-in-time compiler for Lua that compiles Lua script down to native machine code and can achieve a quite significant performance increase over "vanilla" Lua.
 
For me, I like a language if it allows me to do what I need to do without a whole bunch of hoop-jumping to do it. Lua+LuaJIT is my preferred high-level tool loadout, and C++ is my preferred low-level tool. The C++ layer provides the performance critical stuff (rendering abstraction, etc...) while the Lua layer provides the expressiveness necessary to quickly prototype and implement the high level things like enemy AI, spell and skill execution, and so forth.
0

Share this post


Link to post
Share on other sites

My favorite languages are all derived from C; C++, C#, and Objective-C.

Although Objective-C is quite - different - in the ways that it does things (making classes, for example), once you get used to it it starts to become really easy.

C++ I like because it's a lot more cross-platform and is capable of pretty much everything short of time travel!

C# is probably my absolute favorite for its legibility, its speed (of development), and its now cross-platform support thanks to the Mono project.  Without it, Unity probably would suck. :P

0

Share this post


Link to post
Share on other sites

so you can have a compiled scripting language? I thought they should be interpreted so that you can do things at runtime.

 

 

It's a bit of a definition nightmare. One definition of a script is that it's shipped and/or deployed in source form, run by (or made runable by) another tool/program/whatever that is also shipped/deployed.

 

There are two main usages for scripting languages however. 1) To alter/extend the behavior of a program in a simpler maner, usually without recompiling and possibly after deployment of the core product/program. In this case, the scripts would be interpreted or compiled on the fly/just in time. 2) To be able to use a simpler language for some logic, potentially suited for "less technical people". In this case, the "scripts" may be shipped/deployed in compiled form for performance or obfuscation.

 

So it depends on why you are using a scripting language.

0

Share this post


Link to post
Share on other sites
The replies have been really insightful.
Another question. What are those syntatical features you love the most in your language (i hope it doesn't seem similar)?
puts "hello world" and cout << "hello world";.
I prefer puts.
0

Share this post


Link to post
Share on other sites

What are those syntatical features you love the most?
puts "hello world" and cout << "hello world";.
I prefer puts.

 

I personally believe (and quite a few others of my acquaintance do, too) that the stream paradigm with overloaded bit-shift operators was kind of a mistake. In the beginning, it seemed like they were so delighted about that ability to overload operators that they kind of went a little bit crazy. C++ streams make the typical C++ Hello World one of the more confusing and obtuse ones out there. I think that if C++ were started anew today, the streams with << and >> operator overloads would be done differently.

0

Share this post


Link to post
Share on other sites

What are those syntatical features you love the most?
puts "hello world" and cout << "hello world";.
I prefer puts.

 
I personally believe (and quite a few others of my acquaintance do, too) that the stream paradigm with overloaded bit-shift operators was kind of a mistake. In the beginning, it seemed like they were so delighted about that ability to overload operators that they kind of went a little bit crazy. C++ streams make the typical C++ Hello World one of the more confusing and obtuse ones out there. I think that if C++ were started anew today, the streams with << and >> operator overloads would be done differently.
it really does look unnatural.
0

Share this post


Link to post
Share on other sites

 

so you can have a compiled scripting language? I thought they should be interpreted so that you can do things at runtime.


A number of scripting languages (including Lua) do offer the ability to compile to bytecode, and in fact a text chunk will be compiled on the fly when it is loaded. Then there are things like LuaJIT which is a re-implementation of the VM and a just-in-time compiler for Lua that compiles Lua script down to native machine code and can achieve a quite significant performance increase over "vanilla" Lua.
 
For me, I like a language if it allows me to do what I need to do without a whole bunch of hoop-jumping to do it. Lua+LuaJIT is my preferred high-level tool loadout, and C++ is my preferred low-level tool. The C++ layer provides the performance critical stuff (rendering abstraction, etc...) while the Lua layer provides the expressiveness necessary to quickly prototype and implement the high level things like enemy AI, spell and skill execution, and so forth.

 

 

 

bytecode, at least, is pretty much standard for scripting languages.

 

usually, if bytecode or similar is not used, and input text or ASTs are executed directly, the language is "impractically slow" (often around 10k or 100k times slower than native), whereas typically with a bytecode interpreter, it is usually possible to get within 50x-100x of native.

 

though, people have used some non-bytecode representations for interpretation with some success (typically linked lists or trees of objects), bytecode also has the advantage of being easier to store on disk and use later, and can also slightly better decouple the front-end logic from the back-end interpreter logic.

 

a JIT just takes things a step further, typically compiling the bytecode to native machine-code at runtime, then the native-code version is executed.

although a JIT can't usually optimize nearly as aggressively as an offline / batch compiler, it can usually get "pretty close" to native code speeds (it depends more on language and VM design and similar than the specifics of the JIT).

 

 

otherwise, a lot also comes down to language design and how the compilers and tools are implemented:

C and C++ are generally compiled directly to machine code, via offline tools;

Java and C# are generally compiled to bytecode (via offline tools), then the VM will JIT-compile them to native code;

script-languages are typically compiled to bytecode at run-time, then sometimes JIT compiled.

 

experimentally, it is possible to compile C and C++ dynamically (like a script language), however some things in the language design (particularly headers and the way declarations and similar work, ...) get in the way of implementing a fast compiler. also if implemented in a standards-conformant way, it is also "poor" as a scripting language, namely that it requires a lot of code to do things (making it less useful for interactive entry), and (short of internal fudging), it is far too easy to crash the host application. addressing these issues would break the standard in some fairly fundamental ways.

 

with Java and C# it is a lot closer, mostly boiling down to language design subtleties and awkwardness tradeoffs.

 

with script-languages, they are typically a lot better for small fragments and are typically very dynamic.

however, many often skimp out on lots of things needed for more serious coding or for general scalability, so one is left with a language often lacking much good support for being able to use libraries, and turning into an awful mess as code moves past a few thousand lines (this is where more traditional "compiled language" features tend to do well).

 

a compromise is possible though.

 

 

if you have a language that can both be batch compiled, as well as loaded as script-code fragments and dynamically compiled at run-time, supports features to be usable from small code fragments (as can be written interactively), supports both static and dynamic typing, supports things like packages/namespaces and classes, can more easily use code from C libraries (*), ... then things can be a little nicer.

 

*: though in my VM, this requires use of batch tools to process headers and, in some cases, to generate stub-code (usually for exporting stuff to C land).

usually this can be combined with any native code into the form of a DLL. usually for imports from C land, it isn't very fussy (it imports pretty much everything from the seen headers which are reachable via DLL imports). though, some things in C-land have been black-listed (mostly for security reasons).

 

IME, static types and classes, while not particularly advantageous for small code fragments, become a fair bit more useful as code gets larger (for organization, and for things like the compiler helpfully informing the programmer that they messed up their argument list or similar). they also have an advantage of being easier to optimize. though, also having both static and dynamic types can be fairly useful (dynamic types can be fit into a static type system by seeing them as a type-of-type, so in many practical regards, seeing static and dynamic types as opposed is a false dichotomy, and can offer an advantage for cases where, in fact, one is actually dealing with multiple types at run-time).

 

 

however, to support both use-cases, a language tends to require both sets of feature-sets, typically resulting in something a little bigger and more complex than either would be on its own (a scripting language with the full feature-set of a traditional compiled language thrown on, or seen the other way, a traditional compiled language having to deal with a lot of the added complexities of supporting dynamic features).

 

for example, to support both the feature-sets of C and JavaScript, the actual compiler and VM ends up a bit more complicated than either a C or JavaScript compiler or VM would be on their own, and a superset of C, JavaScript, and C#, adds that much more. though, on the positive side, the language can do a little more nifty stuff... (and complexity isn't usually as big of a deal in-practice as it is in-concept).

Edited by BGB
0

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now
Sign in to follow this  
Followers 0