Rusky

Last Login:
January 31, 2012
Warn:

Rank:
Member



User Profile
Follow

Hits: 21,398
Joined August 15, 2006
Games (3)

VKEC
March 01, 2007
Slippy's Adventure
April 11, 2007
Penguin
March 18, 2011
Examples (2)

Platform Engine
February 15, 2008
Accelerating View Example
April 12, 2007
Favorite Users
Dev - Sort these by name
Favorite Games


Language Design
Posted on February 21, 2011 at 20:09

So, before I begin, how can I update my submissions? Do I just resubmit them or is that not implemented (yet) in v3?

---

C is a relatively nice high-level assembly language. C++ is the kitchen sink sitting on top of that, so you can do lots of things with it but it can be painful. I'm sure this will be disputed, so I'll get to it in a minute. Java is a simplification of C++, but in some places it oversimplified like with "a.setFoo(a.getFoo() + 3)." Scala and C# move back toward C++, but they're both still on VMs and designed for high level applications.

That leaves us with few options for low-level and/or performance-sensitive projects like game engines, operating system kernels, embedded applications and almost anything else fun. Contemporary, well-supported, easily-accessible and well-enough designed languages include C, C++ and... well, anything else fails to meet our requirements.

It's obviously possible to write large projects in C (e.g. the Linux kernel) but it's not the best-designed of languages. All the little things like type conversions, declaration syntax, scope and namespaces and verbosity make C more painful than it could be. Then larger-scale issues like polymorphism (ad-hoc/inclusion and parametric), higher-level functions and type safety go out the window.

C++ almost had to be based on C to become popular, so it inherits a lot of its problems. In addition, it's just a big kitchen sink bolted on top, so it lacks the elegance of languages like Smalltalk that a lot of its ideas come from. Larger projects have to enforce restrictions on different allowed subsets of features (Google eliminates exceptions, RTTI and multiple inheritance in the interest of compatibility, less fragile code and consistency).

I would like to design a systems-level programming language that can be as efficient as C but can also be much more expressive and easy to use than C++. Rather than designing by committee to build a checklist of features, it would need to have a unifying idea, like Lisp, Smalltalk, Haskell or Go. The systems-level programming world needs something like that.

Rather than starting from C or C++, I'll start from scratch. The goal will be to use a small, easily-learned feature set that will allow a large range of simple, concise designs. Things like Lisp macros, Haskell type classes, Smalltalk/Objective-C message passing, etc. Haskell comes closer to this than Smalltalk, in that its type system is much stronger than C's (although it would need some tweaking to allow the required control over memory layout, etc.), but still allows all the uses of C++ virtual function calls, CLOS multimethods and OOP-style namespaces.

Anyone have any stories of things they'd have liked to be able to express in their favorite programming language but couldn't without resorting to verbosity, repetition or some ugly hack or other?


34 Results
1 2 Next

Java, dude, Java's the future. Don't knock Perl either.
Posted by Juju February 21, 2011 20:58 - 3.4 years ago
| [#01]

Unless Oracle makes you pay for Java in the future.
Posted by Ferret February 21, 2011 21:04 - 3.4 years ago
| [#02]

I actually agree that some of Java's commands are annoying.

System.out.println();

versus

cout

Which would you rather type if you were running short on time?
Posted by Kilin February 21, 2011 21:15 - 3.4 years ago
| [#03]

Oracle won't make you pay for Java, they'll just stop listening to people so everything that /almost/ made it into the next version won't. And we'll be stuck with decades-old technology while everyone else uses something else.

Also, cout is almost as bad. Try formatting any number in any way other than the default. :shudder:
Posted by Rusky February 21, 2011 21:19 - 3.4 years ago
| [#04]

How about plain English? That would be interesting. Like LOL code or whatever thats called.

Include would be like "Load file file.txt"
Rectangle would be like "Draw rectangle 32 wide and 16 tall, outlined red, filled in blue.
Posted by Scott_AW February 21, 2011 21:44 - 3.4 years ago
| [#05]

Ugh, let's not even go there. You'd either need some kind of natural language processing or Watson-like heuristics, which can make mistakes sometimes and are thus *not* a good idea, or a strict syntax which is misleading because you can't really just use "plain English" anymore.

Syntax-wise, I think the best idea is to just pick something simple and semi-established. As long as it's not painful to express things in your chosen syntax (like C declarations), it doesn't matter too much what it is exactly.
Posted by Rusky February 21, 2011 21:52 - 3.4 years ago
| [#06]

Wuss.
Posted by Scott_AW February 21, 2011 21:59 - 3.4 years ago
| [#07]

tl;dr?
Posted by Misconstruct February 21, 2011 22:46 - 3.4 years ago
| [#08]

JUST SHUT UP AND GET BACK TO PROGRAMMING YOUR GAMES IN C++!
Posted by CyrusRoberto February 21, 2011 22:50 - 3.4 years ago
| [#09]

tl;dr: C and C++, the biggest real options for low-level/performance sensitive projects, are not as nice to use as higher-level languages like C#, Lisp, Python, etc. I want to design a better low-level language.

Also nobody answered my question :<>
Posted by Rusky February 21, 2011 22:52 - 3.4 years ago
| [#10]

Dude I program my games in drag and drop, it's the newest and bestest programming language ever.
Posted by Misconstruct February 21, 2011 22:53 - 3.4 years ago
| [#11]

This makes me cry.
Posted by Rusky February 21, 2011 23:03 - 3.4 years ago
| [#12]

I know C# and Java. I personally like C# more, unless you want a web app. Screw Silverlight then and go to java or whatever.
Posted by Cpsgames February 21, 2011 23:53 - 3.4 years ago
| [#13]

I find Java has oversimplified things too much, I prefer C++ to it, but at the end of the day, as long as I can avoid ASM while programming PCs I'm happy. The only problem with C++ is that occasionally one has to resort to the odd hack, or resort to bad practices (like overloading primitive data types).

Designing a programming language isn't too hard, implementing a compiler and/or assembler on the other hand can be a real pain in the ass. Just one bit of advice, if you do design a language, beware of feature creep, have a very clear outline.
Posted by Undeadragons February 22, 2011 11:57 - 3.4 years ago
| [#14]

I know I'm a bit late on this, but here you go anyway.

Quote
Also, cout is almost as bad.

I wasn't talking about efficiency or implementation. I was only talking about how painful it is to type longer commands a thousand times. Cout and System.out.println were just examples, and obviously you don't use those all the time, since we're no longer writing programs for users to open in the command prompt.
Posted by Kilin February 22, 2011 13:06 - 3.4 years ago
| [#15]

Designing any old programming language isn't hard, but what's the point of that? The point of designing a programming language is to make something better than the feature-blobs we have now (in other words, having a "clear outline" as you say). That's just as difficult as implementing a compiler.

I was talking about the syntax of iostreams as well. They're often at least as verbose as System.out.println once you start actually printing things instead of just typing their names. C++ does have a slight edge on Java in the syntax/verbosity area, but it's really not much better. Compare it to scripting languages or functional languages and you'll see what I mean.
Posted by Rusky February 22, 2011 15:27 - 3.4 years ago
| [#16]

You don't even have to worry about syntax with drag and drop, baby!
Posted by Misconstruct February 22, 2011 15:30 - 3.4 years ago
| [#17]

Well of course designing a solid programming language can be tricky, the trade-off is design time & implementation complexity vs. distance from machine code. That being said, given that you seem to have an idea of what such a feature set would be, it wouldn't be too hard, so long as you stick to it.

I do agree with you though, whilst there is a lot of power to be derived from lower lever languages, they often have problems due to how they were created, C++ is probably one of the better ones, but as C was somewhat haphazard in it's creation and C++ was meant to be a superset of it, C++ suffers from many of the same problems that plague C. Java is another good option, but in it's endeavour to have a more rigid architecture than C/C++, it has enforced the whole rigid class system to the point of absolute frustration. Functional and scripting languages are quite often much more limited in what they can do, but as a trade off are often much more expressive. There is a reason there are few languages that are powerful and also expressive.

But I tell you what, I for one would be game if this ends up being more than simply a thought, I have designed a simple programming language (for a uP I designed), but it would be interesting to take a shot at a real programming language.
Posted by Undeadragons February 22, 2011 22:17 - 3.4 years ago
| [#18]

A lot of the ideas I've been considering are ways to bring the expressiveness of functional languages to a lower level language. For example, Haskell uses type classes for polymorphism rather than class hierarchies with virtual functions. This gives several advantages over C++ and can be implemented just as or more efficiently. However, type classes in Haskell are not applied to traditional object-oriented open inheritance hierarchies. Combining both of these would solve real problems in real projects.

A type class in Haskell is similar to an interface. They are equivalent to the now-dead C++0x concepts and concept maps, but at runtime. A typical type class is Eq:
class Eq a where
(==) :: a -> a -> Bool
(/=) :: a -> a -> Bool
This means that any object of a type in the Eq class can be compared for equality with another object of that type. The cool part is that you don't make types members of classes as part of their definitions, but rather as separate instance declarations:
instance Eq MyType where
a == b = -- compare equality
a /= b = !(a == b)

This means you can make any arbitrary type "implement" any arbitrary "interface" without modifying the type. You can combine different libraries yourself, and the instance declarations are only scoped where you put them, so you don't have to modify third party code and you don't have to do Ruby-style monkey patching that can interfere with unrelated systems.

Now, the types in Haskell are closed- in other words, you can't add new ones to the "hierarchies." If you have a parse tree or a type that uses collision testing, it's all declared in one place:
data Node = Name String | Number Double | Binary Op Node Node
Adding new types means messing with the original definition. In C++, you have
class Node { virtual void foo() = 0; }
class Name : public Node { string name; virtual void foo() { /* ... */ } }
// add more from wherever you like, even dynamically link them
Now, imagine both of them together. Instead of making a bunch of Node children, you instance them for your type class for code generation, and then in your optimization library have them instance a different class without modifying their definitions. With real multiple dispatch as well, you can completely eliminate the need for the visitor pattern- a two-parameter Visitor type class on the visitor and the visitable types could be instanced, without modifying the AST library, for any kind of operation on the parse trees you like.
Posted by Rusky February 22, 2011 23:45 - 3.4 years ago
| [#19]

D is kinda cool.
Posted by ludamad February 22, 2011 23:49 - 3.4 years ago
| [#20]

34 Results
1 2 Next

Recent Activity
 
Active Users (0)