Jump to content

  • Log In with Google      Sign In   
  • Create Account


if you were to make a programing language, what would you name it?


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
53 replies to this topic

#21 TheChubu   Crossbones+   -  Reputation: 4075

Posted 24 May 2013 - 10:16 AM

I'd call it "Subjective-C", it would be a language open up to interpretation...

:D


"I AM ZE EMPRAH OPENGL 3.3 THE CORE, I DEMAND FROM THEE ZE SHADERZ AND MATRIXEZ"

 

My journals: dustArtemis ECS framework and Making a Terrain Generator


Sponsor:

#22 BaneTrapper   Members   -  Reputation: 1163

Posted 24 May 2013 - 11:29 AM

"Dream no more"

Just because it would be so strong, and so efficient it would make dreams come true in moments of coding.


Current projects:
The Wanderer, 2d turn based rpg style game

www.gamedev.net/topic/641117-check-up-the-wanderer/


#23 BGB   Crossbones+   -  Reputation: 1554

Posted 24 May 2013 - 11:53 AM

hmm... there seems to be enough general interest in VM managed C to almost make me think that it might be worthwhile to go implement it...

 

likely architecture:

compiler: prior C frontend -> FRBC -> 'EXE' (package, *1)

interpreter: 'EXE' -> FRIR / JIT

 

(where FRBC is essentially a Dalvik-like Register IR).

 

luckily I already have most of the major parts...

 

using plain C though would likely require a wrapper layer to try to gloss over things like MSVCRT vs Newlib vs Glibc and similar though, though I already partly have this part as well in the form of a modified/expanded PDPCLIB + POSIX-like API wrappers. partly as a lot of "detail issues", like values of various #define's, struct layouts, ... tend to vary from one C runtime and another, so it is needed to provide a consistent C runtime to avoid stuff blowing up... (and to provide consistent DLLs to link against, ...). (note that the VM and library wrappers would still need to be ported to each target...).

 

*1: probably one of raw PE/COFF, PE/COFF+ExWAD (my current VM works this way), or raw ExWAD. (ExWAD is a WAD based format, initially based on the Quake WAD2 format... things like bytecode and metadata and so on are stored in various "lumps", more-or-less...).

 

 

hmm... "FRBC" -> "FurbyC"... seems to be available...


Edited by cr88192, 24 May 2013 - 12:32 PM.


#24 ApochPiQ   Moderators   -  Reputation: 15067

Posted 24 May 2013 - 12:42 PM

What, exactly, does "VM managed C" even mean?

#25 ysg   Members   -  Reputation: 192

Posted 24 May 2013 - 01:25 PM

I'd combine the best of Lisp and Erlang and call it Erlisp or Lilang.

#26 Alpha_ProgDes   Crossbones+   -  Reputation: 4688

Posted 24 May 2013 - 01:35 PM

I'd combine the best of Lisp and Erlang and call it Erlisp or Lilang.

 

Offtopic: Can being too expressive actually cause you to not be able to express yourself?


Beginner in Game Development? Read here.
 
Super Mario Bros clone tutorial written in XNA 4.0 [MonoGame, ANX, and MonoXNA] by Scott Haley
 
If you have found any of the posts helpful, please show your appreciation by clicking the up arrow on those posts Posted Image
 
Spoiler

#27 BGB   Crossbones+   -  Reputation: 1554

Posted 24 May 2013 - 02:11 PM

What, exactly, does "VM managed C" even mean?

 

 

the language is still C, and still behaves pretty much like plain old C and can use native-compiled libraries and so on, but rather than being compiled directly to native code, is compiled first to a bytecode format, and possibly compiled to native code for each target (such as via a JIT compiler, or maybe an AOT compiler), allowing an increased range of portability (no need to recompile a "reasonably written" application to run on various targets, provided the VM is available).

 

granted, there are a few technical hurdles which would be involved with making something like this "work reasonably well" and "not suck too badly".

 

 

for example, ideally:

requirements should be small, and it should not require a heavyweight VM runtime;

performance shouldn't be too awful (not drastically slower than direct native compilation);

ideally it shouldn't get in the way of utilizing platform-specific functionality (as-needed), and should be "reasonably transparent" (allowing direct calling and data-sharing between natively-compiled and VM managed code, IOW: ABI compatible with native code);

ideally the bytecode should be reasonably agnostic to the particular backend used (IOW: not LLVM bitcode or similar);

...

 

IOW: where it ideally still retains a lot of the relative merits of developing natively-compiled apps, while at the same time lessening the need to recompile all the code for each target.

 

 

possible secondary sub-goals:

ideally, provide some some semblance of memory protection (while using pointers), and possibly access-rights validation;

provide an "easier" target for dynamically compiled code (API functionality similar to the JVM ClassLoader facilities, *1);

provide an API for dynamic compilation ("load from source", etc...);

...

 

*1: while there would still be the option of getting RWX memory from the OS, writing into it, and then calling it, this would be CPU-architecture specific, whereas ideally the program should be able to compose its own bytecode and feed it into the Loader API, and then fetch back a compiled function-pointer or similar.

 

 

partly unresolved issues:

library / versioning issues (where different targets have different libraries or library versions, which can't really easily addressed within the confines of standard C or C++, hence why some wrapping of core APIs would be needed);

good handling of target-specific code (*2);

...

 

*2: traditional #ifdef would no longer be a particularly effective portability mechanism (due to it being handled too early in the compilation process), likely requiring a new mechanism to address a similar use-case. one possible option here would be introducing a construct for JIT time conditionals, for example: "_Ifdef(VAR) { ... }", which would be evaluated at JIT-time (as opposed to during preprocessing or at run-time). however, this mechanism would itself introduce a few new ugly problems (related to the use of OS-specific headers on other targets).

 

likely, a "simpler" solution of marking individual compilation-units as belonging to particular architectures and compiling them as-if they were running under the target in question, then the loader will skip versions of compilation units compiled for an incompatible architecture:

#pragma CompileAsIfOS(linux, WIN32, default)

#pragma CompileAsIfCPU(X86, X86_64, AArch64:linux, default)

...

 

or such...


Edited by cr88192, 24 May 2013 - 02:33 PM.


#28 Anri   Members   -  Reputation: 597

Posted 24 May 2013 - 05:11 PM

I would name my language AWESOME.cool.png



#29 ApochPiQ   Moderators   -  Reputation: 15067

Posted 24 May 2013 - 06:39 PM

the language is still C, and still behaves pretty much like plain old C and can use native-compiled libraries and so on, but rather than being compiled directly to native code, is compiled first to a bytecode format, and possibly compiled to native code for each target (such as via a JIT compiler, or maybe an AOT compiler), allowing an increased range of portability (no need to recompile a "reasonably written" application to run on various targets, provided the VM is available).

So, basically, C except with a lot of extra cruft and points of failure...


I don't understand this at all. Well-written C is already highly portable. If you want even more portability you're making a language that is no longer C. And you'd have to murder most of C to get any more portable, at which point you probably want to design a cleaner barebones language than what would be left of C so you could, y'know, actually do non-trivial stuff in it.

Adding a VM/JIT layer does not increase portability by any stretch of the imagination - if anything, it's exactly the opposite. C or nearly-C targets exist for virtually every piece of processing hardware. Your proposed solution is actually a liability for someone wanting portability, because they would have to wait for your tool chain to add support for a platform that probably already has a working C compiler.

Wanting C and a VM layer is kind of counterproductive. Either make a better language in general, or just... use C.

#30 Sik_the_hedgehog   Crossbones+   -  Reputation: 1606

Posted 24 May 2013 - 06:44 PM

who came up with the name of C(or C++) anyway?

 

Ken Thompson and/or Dennis Ritchie. C is named as such because apparently it was heavily influenced by the programming language B.

 

C++ was an expansion on C, and I'm assuming named because it is an incremental expansion over C instead of something designed completely from the ground up.

Pretty much.

 

C was named like that because it was based on B, which in turn got its name from Bell (since it was a language developed there). As for C++, it was an extension of C, so they used the increment operator to show that (but originally it was called C with classes, back when classes were the only addition to the language - thereby why some C++ source files have .cc as the filename extension).


Don't pay much attention to "the hedgehog" in my nick, it's just because "Sik" was already taken =/ By the way, Sik is pronounced like seek, not like sick.

#31 BGB   Crossbones+   -  Reputation: 1554

Posted 25 May 2013 - 01:19 AM

ApochPiQ, on 24 May 2013 - 19:44, said:
 

cr88192, on 24 May 2013 - 15:16, said:
the language is still C, and still behaves pretty much like plain old C and can use native-compiled libraries and so on, but rather than being compiled directly to native code, is compiled first to a bytecode format, and possibly compiled to native code for each target (such as via a JIT compiler, or maybe an AOT compiler), allowing an increased range of portability (no need to recompile a "reasonably written" application to run on various targets, provided the VM is available).

So, basically, C except with a lot of extra cruft and points of failure...


I don't understand this at all. Well-written C is already highly portable. If you want even more portability you're making a language that is no longer C. And you'd have to murder most of C to get any more portable, at which point you probably want to design a cleaner barebones language than what would be left of C so you could, y'know, actually do non-trivial stuff in it.

only if significant design changes were made to the language.
if the language is basically pretty much as it was before, and still conforms with the C standards, it is still C.

well written code should ideally be able to be compiled via such a tool chain, or directly as native code, and if done well, the differences here should be mostly invisible (as in, pretty much everything works just as it does in native).

though, yes, some of the mentioned features would require additional #ifdef's, but nothing new there.

though, in general: if people have to see the results of what you have done, you have done it wrong.

most likely, a person would go mix and match, using one set of tools or another, as it suits their purposes.

Quote
Adding a VM/JIT layer does not increase portability by any stretch of the imagination - if anything, it's exactly the opposite. C or nearly-C targets exist for virtually every piece of processing hardware. Your proposed solution is actually a liability for someone wanting portability, because they would have to wait for your tool chain to add support for a platform that probably already has a working C compiler.

Wanting C and a VM layer is kind of counterproductive. Either make a better language in general, or just... use C.

granted...

there are difficulties with the idea (not all of which are readily solvable), and this is partly why I have not put a whole lot of effort into this already (despite having previously already written a C compiler...).

but, there might be cases though where being able to copy binaries without recompiling could be a selling point, and if people actually cared or were interested, it could be worthwhile...

hence the whole "make it not suck" requirement, pretty much a whole lot is predicated on this one.


the problem with "better" languages is typically that it requires effort to port code to them, and none is really better for everything.

for the most part, the C/C++/Java/C#/JS/AS3/... are "sort of in about the right general area", but there is still a mess of ugly seams (different pieces of technology that still don't really play well together).

the world needs some stronger glue here (ideally, so that all this stuff can be glued together).


the rest of the matter, like actually porting the tools and tool-chain, well, who knows there...
if the code is available, then it isn't too much different than with anything else, just "another set of tools for the toolbox".

so, like, it is more about whatever might be a better or worse solution for a given use-case.
sort of like people using Emscripten to compile C into JavaScript.

a good solution in general?... probably not.
a good solution for certain use cases?... probably (probably does at least beat out trying to manually port stuff over to JavaScript, or maybe vs porting to Java so it can be shoved into a Java applet, ...).

 

 

and, hypothetically, if your app is compiled to a reasonably portable bytecode, and a VM implementation could also be written in JavaScript or Java, then suddenly, much of the need to port the whole app to JS or Java can be side-stepped...


Edited by cr88192, 25 May 2013 - 01:25 AM.


#32 OandO   Members   -  Reputation: 733

Posted 27 May 2013 - 09:08 AM

"?" Attempting anything results in undefined behaviour.



#33 ChaosEngine   Crossbones+   -  Reputation: 2290

Posted 27 May 2013 - 03:26 PM

I'd name it "Kihon" (martial arts term meaning basic or fundamental), and it would be probably be terrible, but in my fantasy, it would be a mongrel blend of python and C# with lots of explicit support for multi threading.


if you think programming is like sex, you probably haven't done much of either.-------------- - capn_midnight

#34 DvDmanDT   Members   -  Reputation: 855

Posted 27 May 2013 - 04:36 PM

There are two things I've thought about. A C# version with more functional aspects, in particular the ability to tag functions and methods as pure meaning they can have no side effects as well as immutable types (you can create immutable types, but not really language enforced). I wouldn't be the slightest surprised if this was implemented in the near future though.

 

The other one is a low-level language intended to be link compatible with C++. The idea is basically to create a cleaned up version of C++: remove/replace (or at least reduce the role of) the preprocessor, remove the requirement for stuff to be declared before use (types, functions and methods can be declared in any order and in separate files without includes), make errors of various common pitfalls (remove some implicit type casts, require initialization before use, ...), standardize default types (int is 32 bits and long is 64) and create a new "platform int" which is always the best size for the target. I want to clean up the syntax slightly. I also want to include real delegates (as in C#/.NET) into the language. I would also want to review templates and class inheritance to make the rules stricter and less easy to misuse.

 

Having a smaller, cleaner and stricter language could greatly help with readability and stability. By compiling down to standard C++ (or even C), some of the core strengths of C++ would be maintained (mature toolchains and platform adaptation).



#35 ISDCaptain01   Members   -  Reputation: 1378

Posted 27 May 2013 - 11:07 PM

EasyC

 

Basically a scripting language version of c++. Thus, allowing you to have manual memory management on the fly without recompiling. Although it would be optional, and you could turn off pointers by checking a box.You could also use it with game engines instead of something like UnrealScript, UnityScript, TorqueScript, blah blah blah. This giving c++ programmers an easy way to use scripting without learning whole 'nother language. But I have no idea what im talking about though, and no idea if this is feasible.


Edited by ISDCaptain01, 27 May 2013 - 11:13 PM.


#36 Mussi   Crossbones+   -  Reputation: 1762

Posted 28 May 2013 - 12:16 AM

Jarvis - programming can only be done verbally.



#37 BGB   Crossbones+   -  Reputation: 1554

Posted 28 May 2013 - 01:54 PM

EasyC

 

Basically a scripting language version of c++. Thus, allowing you to have manual memory management on the fly without recompiling. Although it would be optional, and you could turn off pointers by checking a box.You could also use it with game engines instead of something like UnrealScript, UnityScript, TorqueScript, blah blah blah. This giving c++ programmers an easy way to use scripting without learning whole 'nother language. But I have no idea what im talking about though, and no idea if this is feasible.

 

FWIW, some scripting languages (mine, for example), do have manual memory management, and also pointers. (FWIW, my scripting VM is technically GC'ed, but the GC is kind of slow and unreliable, so it is better to manually 'delete' things, or in other cases use structs or value-classes). it is also, in its present form, statically-typed (more or less), and generally uses a "kind-of Java-like" syntax...

 

technically, the pointers it provides are not raw "narrow pointers", but more often what I call "boxed pointers" (essentially "fat pointers"), which are typically more strictly typed and which use bounds-checking.

 

also a lot of work has been put in making it play nicely with native C code, but sadly C++ support is a bit lacking (only some of the tools support C++, and typically only a subset, and there is also the matter of supporting multiple various C++ ABI's, mostly as details like the exact physical class-layout and name mangling will often differ between one compiler and another, or one compiler version and another, ...).

 

I have a few times though thought that similar technology can be applied to C (and possibly a similar C++ subset, *1).

 

 

*1: basically, supporting classes, operator overloading, and possibly namespaces (only some of my tools presently support namespaces). templates are likely to be absent (thoughts of trying to implement this feature raise some uncertainty...).

 

a drawback of both C and C++ is that basically, if keeping the languages in their standards-compliant forms, there is no good way to make the compile times much faster than with native compilers. this need not kill off C (or C++) based scripting though, since there is still the possibility of "compile-and-cache" (where the results of compiling are stored off somewhere, and reused later). however, usable eval is a separate issue.

 

 

basis: partly in the past I had experimented with implementing/using a similar piece of technology, just it had compiled to native code (at the time, the problems of compiler performance and debugging the native code-generator, largely killed this off). compiling instead to bytecode could allow more room for an interpreter-based backend (with JIT offered on "major" targets, but otherwise allowing for a plain-C interpreter), where interpreters are a little easier to debug.

 

another issue originally was that the use of raw pointers made it too easy to crash the engine from script-code, though fat-pointers can help here, as well as at least giving "some" hope of keeping the code effectively "sandboxed" (I think it can be done, but I will probably not go into it here). note that the internal use of fat-pointers (and pointer validation, ...) could be kept largely invisible from the high-level code.

 

 

of course, there is also the "elephant in the room" that is LLVM/Clang.

 

as well as there being some other C or C++ based interpreters, and compilers to various VM backends, ...



#38 Krohm   Crossbones+   -  Reputation: 3049

Posted 29 May 2013 - 01:03 AM

Here we go for another thread cr88192 takes seriously.



#39 BGB   Crossbones+   -  Reputation: 1554

Posted 29 May 2013 - 03:05 AM

Here we go for another thread cr88192 takes seriously.

 

just responding to comments and giving information is all...

 

(mostly: my ability to spot patterns has seemingly found a pattern... and it caught some interest, but mostly in a "can it work? most probably!..." sense...).


Edited by cr88192, 29 May 2013 - 03:09 AM.


#40 Ectara   Crossbones+   -  Reputation: 2916

Posted 29 May 2013 - 03:58 AM

What, exactly, does "VM managed C" even mean?

 

 

the language is still C, and still behaves pretty much like plain old C and can use native-compiled libraries and so on, but rather than being compiled directly to native code, is compiled first to a bytecode format, and possibly compiled to native code for each target (such as via a JIT compiler, or maybe an AOT compiler), allowing an increased range of portability (no need to recompile a "reasonably written" application to run on various targets, provided the VM is available).

...

I remember writing one of those. It was the coolest thing, designing this little architecture with a C compiler, and it was so powerful and could use native libraries, and could be rigged like a normal scripting language... until I realized it could do too much. The tasks for which I needed a scripting language were so high performance, that using a general scripting VM with a language based on C resulted in it being unusably inefficient, unless I went all out and essentially made a "C to byte code to ASM" compiler, which defeated the purpose of compiling to byte code in the first place, since it wouldn't nearly save me any time, having to write JIT interpreters for every platform that already had a C compiler.

 

In the end, I wound up putting the VM on a shelf, and designing several smaller, but much, much faster VMs with more specialized languages for their purposes. It does give me great interest to see others doing similar projects, though.






Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS