[gameprogrammer] Re: Daydreaming, questioning....

From: Mark Oleschuk <shorty_1280@xxxxxxxxxxx>
To: <gameprogrammer@xxxxxxxxxxxxx>
Date: Wed, 21 Oct 2009 10:48:13 -0600
>>> What I want is a language that is designed to make use of massive

>>> amounts of memory and hundreds or thousands of hardware threads that

>>> contains all the libraries I am likely to ever need and the ability to

>>> easily integrate libraries I didn't imagine I would ever need.

>>>

>>> Yeah, but what about efficiency? Let's define language efficiency as

>>> the amount of your life you have to spend to write a program a

>>> complete program. Or, as the ratio of the number of programs you can

>>> write in a year using different languages. If I can write one major

>>> program a year in C, and 1.5 per year in C++ then I want to be able to

>>> write 10 in Stonewolf. Which would make Stonewolf 10 times more

>>> efficient in terms of my life span than C. (BTW, if Stonewolf actually

>>> lets me get to 3 I would consider it a wonderful achievement.)


Depending on how brilliant you are the code itself wouldn't have to be 
inefficient. The compiler would not include all the library's that the program 
wouldn't use so it could be as fast as c++.  

So basically what i am seeing here is an idea for making an engine building 
language?  That actually wouldn't be a bad idea.  I am a huge c fanatic.  In my 
mind c is really the only language and every other language is just c designed 
so you cant shoot yourself in the foot so easy.  If the stonewolf language 
itself is actually designed only around building engines i could see a use for 
it.  I build game engines all the time for fun and the grunt work is 
unbelievable no mater the language (i tend to use JAVA for that sort of stuff). 
 I find that in order to implement any new idea i have to basically start from 
scratch.  The idea is not without merit but in my humble opinion if you 
specialize the language enought then it will have a use.  If you try to 
generalize it ... prob end up a flaming bag of crap on your steps.


Mark



Date: Tue, 20 Oct 2009 14:52:08 +0200
Subject: [gameprogrammer] Re: Daydreaming, questioning....
From: pjmlp@xxxxxxxxxxxxx
To: gameprogrammer@xxxxxxxxxxxxx

Smalltalk and Eiffel are two good examples of languages where everything is 
object based, and the mapping from higher
level data to native types happens as a compiler optimization step, which is 
quite nice for us as developers.


On Tue, Oct 20, 2009 at 2:22 PM, Charlie Lobo <charlie.lobo@xxxxxxxxx> wrote:

I'd also look into this newfangled OO thing people talk about.
Agents seem to be a pretty reasonable way to think of parallelism, and the 
issues of a typing system that doesn't give preference to native types seems 
reasonable.



On Tue, Oct 20, 2009 at 3:29 AM, Paulo Pinto <pjmlp@xxxxxxxxxxxxx> wrote:


Mostly Scala and F#, but with an eye on Haskell as well.

I work on IT, and these are the languages that might eventually win the hearts 
of some programmers.

Personally I would like that Scala gets ahead, specially because I am a 
Java/Python programmer by



day.

But the ML syntax has a special place on my heart, which leads me then to F# 
and Haskell, because
my university used to have lots of classes that required the use of Caml, which 
made the syntax stick to



my brain. Not sure if that is so positive. :)

So regardless of what some people might think of Microsoft, and their dubious 
actions from time to time,
I do appreciate the effort they are doing with F# and Haskell to make 
functional programming more mainstream.




Cheers,
Paulo

On Tue, Oct 20, 2009 at 3:15 AM, Bob Pendleton <bob@xxxxxxxxxxxxx> wrote:



On Mon, Oct 19, 2009 at 3:33 PM, Paulo Pinto <pjmlp@xxxxxxxxxxxxx> wrote:

> Hi Bob,

>

> those sound really nice ideas.

>

> I tend to think that many people still live on the stone age of computing by

> restraining themselves to C or

> similar languages.

>

> I rather get myself productive in a higher level language and only recode in

> low level language like C, the

> application parts that really need it. Sometimes the speed of the

> application is good enough and no part

> gets rewritten.

>

> Personally I am spending my hobby programming time with functional

> languages, that are seeing a renaissance

> with the availability of multi-core.



Interesting. Which ones? I played with several back in the early '80s.

And if you count Lisp among them then I was doing Lisp going back to

the early '70s. The fact is that most of my best ideas are stolen

directly from functional languages, the concept of actors, and good

old communicating sequential processes. The rest are based on watching

humans, from second graders to post docs, from newbies to seasoned

software engineers, trying to write code without going nuts.



Bob Pendleton



>

> Good luck for your project, you have quite a few nice ideas.

>

> Paulo

>

> On Mon, Oct 19, 2009 at 8:36 PM, Alan Wolfe <alan.wolfe@xxxxxxxxx> wrote:

>>

>> "First off, the majority of languages (I almost said *all* but I do not

>> know *all* languages) were designed around the idea that resources are

>> scarce"

>>

>> "I want message passing and

>> multithreading to be so intrinsic in the language that you get them

>> without even thinking about it."

>>

>> Honestly i was thinking "great, yet another language!" when i started

>> reading but your ideas are interesting and i think there's some good

>> potential here (:

>> On Mon, Oct 19, 2009 at 11:18 AM, Bob Pendleton <bob@xxxxxxxxxxxxx> wrote:

>>>

>>> Thanks to everybody who replied. I haven't replied because I figured I

>>> needed some time to let my fevered imaginings simmer down.

>>>

>>> I'm going with the language #4 plus muxing in some of #5.

>>>

>>> A bunch of you expressed interest in helping with the stonewolf

>>> programming language. So, I'm going to post my thoughts on the subject

>>> here and see what you folks think about what I want to do.

>>>

>>> First off, what am I thinking about, why do I think we need a new

>>> language? There are lots of reasons. Most of them are outside of what

>>> is IMHO the "normal" way of looking at programming languages.

>>>

>>> First off, the majority of languages (I almost said *all* but I do not

>>> know *all* languages) were designed around the idea that resources are

>>> scarce. Think about C and C++. C was designed in the '72 and C++ was

>>> designed starting in '79. In '79 I bought 16 kilobytes of ram for my 2

>>> megahertz z80 for $110 which is $327 in 2009 dollars. In '72 I could

>>> not afford to buy 16KB of ram. It was too expensive.

>>>

>>> OTOH, a little over a month ago I bought 4 gigabytes of RAM for $50.

>>> That 2009 $50 has the same buying power as $9.68 in '72 and $16.82 in

>>> '79 (we had a lot of inflation during the '70s).

>>>

>>> What is my point? Those two languages were designed when a megabyte

>>> was a *huge* amount of memory. In the '70s the hacker slang for a

>>> megabyte of RAM was "moby" as in the great white whale. The basic

>>> assumption forced on language designers was that memory was scarce and

>>> expensive. The same goes for processors. My aging AMD 64 dual core

>>> processor has more computing power than was available from all the

>>> computers on my university campus combined. The computer graphics chip

>>> on my mother board was literally science fiction in the '70s. Top of

>>> the line multimillion dollar graphic displays were used in the 1982

>>> movie "Wrath of Kahn". Right now you can get better graphics

>>> technology for $10 in the discount bin at Goodwill.

>>>

>>> Another scarcity assumption drove the complete separation of

>>> C/C++/Java from their libraries. C was designed for embedded systems,

>>> telephone switches, where you could not assume that you would have a

>>> keyboard, or a disk, so all I/O was removed from the language. The

>>> same happened for things like the math library. In the bad old days

>>> only expensive mainframes (multimillion dollar machines) had floating

>>> point hardware. Even some of the biggest supercomputers didn't have a

>>> hardware floating point divider. You kept as much out of the language

>>> as possible because a runtime library couldn't add more than a few

>>> kilobytes to user programs if you expected the programs to fit in

>>> memory. Now days I can have hundreds of megabytes of runtime library

>>> and it won't affect my ability to run a program. In the future I can

>>> have a multigigabyte runtime and not worry about it at all.

>>>

>>> Even though languages like Java and C# were designed much later they

>>> carry forward a bunch of the assumptions of scarcity found in older

>>> languages like C and C++.

>>>

>>> The result of these assumptions is that programmers have to spend a

>>> great deal of time worrying about things like "does the interface use

>>> and int16 or an int32?". Why should I have to do that? Why not just be

>>> able to use a "number"? Why should I care how it is represented? I

>>> want to break all the assumptions I see built into these languages.

>>> Why did I have to write my net2 library? Why shouldn't a modern

>>> language just support asynchronous network IO the way it supports

>>> doing a floating point divide?

>>>

>>> Ok, a bunch of you just went Huh? what about efficiency? Well the way

>>> I see it is we will have at least two levels of programming going on.

>>> Just like we currently do with game engines. One level of programming

>>> worries about making things super efficient so the game runs fast

>>> enough, these are the engine programmers. The other level are the so

>>> called scripters. These are people who actually write the game but

>>> they do it in a language like Lua or Python that is embedded in the

>>> game engine. The scripters don't have to worry so much about the

>>> efficiency of their code because it is all written to use highly

>>> efficient code that already exists. If the scripters need a new

>>> feature they don't usually write it in the scripting language, they

>>> get someone else to write it in a language like C++ and add it as an

>>> interface that they can use.

>>>

>>> One way to think of it is to think of a language with all the parts

>>> (and much more) of a game engine built into the language rather than

>>> having a language built into a game engine. I really want a lot more

>>> than that.

>>>

>>> What I want is a language that is designed to make use of massive

>>> amounts of memory and hundreds or thousands of hardware threads that

>>> contains all the libraries I am likely to ever need and the ability to

>>> easily integrate libraries I didn't imagine I would ever need.

>>>

>>> Yeah, but what about efficiency? Let's define language efficiency as

>>> the amount of your life you have to spend to write a program a

>>> complete program. Or, as the ratio of the number of programs you can

>>> write in a year using different languages. If I can write one major

>>> program a year in C, and 1.5 per year in C++ then I want to be able to

>>> write 10 in Stonewolf. Which would make Stonewolf 10 times more

>>> efficient in terms of my life span than C. (BTW, if Stonewolf actually

>>> lets me get to 3 I would consider it a wonderful achievement.)

>>>

>>> I also want to get as far away from C based syntax as I can without

>>> creating something worse. I want control structures that can be

>>> automatically converted into high level parallel code. I want to make

>>> executable code a true full fledged data type so it is easy to

>>> replicate it across a "cloud" and to make it part of a class in a

>>> database. I want unicode to be built in from the beginning and not

>>> tacked on as an after thought. I want message passing and

>>> multithreading to be so intrinsic in the language that you get them

>>> without even thinking about it.

>>>

>>> So, that is what I want, what do you think?

>>>

>>> Ok, I thought I would start out with a fevered rant and see what kind

>>> of a reaction I get. I have actually been writing a speculative

>>> specification in fits and starts for 5 or 6 years. I'm holding off on

>>> posting any of that because I want to get other people thinking about

>>> all this without tainting your imaginations.

>>>

>>> Currently I'm messing around with what I call plumbing code just

>>> trying to see what I can do to make it fit into a Unicode world. I

>>> haven't found a suitable parser generator, I'm real picky about error

>>> reporting and recovery, so I'm planning to just do a hand coded

>>> recursive descent parser. And, I'm committed to using C++ as the

>>> implementation language. Lots of good reasons for using C++. The best

>>> one being that C++ makes a great extension language for Stonewolf.

>>>

>>> Bob Pendleton

>>>

>>>

>>> On Fri, Sep 18, 2009 at 1:36 PM, Sami Näätänen <sn.ml@xxxxxxxxxxxxxxx>

>>> wrote:

>>> > On Thursday 17 September 2009 20:00:59 Bob Pendleton wrote:

>>> >> Ok, so I'm sitting here thinking about what I am going to work on

>>> >> next. Right now I am finishing up work on atomic ops for SDL 1.3 and I

>>> >> have promised to work on multiple device handling for SDL 1.3 on

>>> >> Linux. (it is sort of messed up right now.) But, that won't take a lot

>>> >> of time, I hope, so I'm thinking about new projects. So, I thought I

>>> >> would ask what you folks thought about some ideas and see if maybe

>>> >> y'all could make some suggestions?

>>> >>

>>> >> In no particular order....

>>> >>

>>> >> 1) Write the space war game I always wanted to write. Yeah, that one,

>>> >> or is it three? No, I think there are least 20 games in that bag.

>>> >>

>>> >> 2) Write yet another 3D drawing/layout program. This would be the kind

>>> >> of program you need for drawing 3D items and doing level layout and

>>> >> design. Trouble is there are a million of these. Reason for doing it:

>>> >> I've never seen one that took less than *months* to learn to use. Or,

>>> >> they only run on Windows or Mac so I've never tried them :-).

>>> >>

>>> >> 3) Build a planet sim so you can create game worlds without having to

>>> >> do it by hand. This one popped out while I was thinking about #1. I

>>> >> spent a lot of time learning just how hard it is to subdivide a

>>> >> sphere. Spheres are really nasty.

>>> >>

>>> >> 4) Stonewolf, the programming language:  I have started at least 8

>>> >> times to develop a language designed for multimedia apps whose design

>>> >> is aimed at the future, not the past. Designed for 64 bit address

>>> >> spaces, terabyte disks, and hundreds of cores. I have settled on the

>>> >> name, Stonewolf. Two things that a language needs are a cool name and

>>> >> a developer with a beard. Seriously, look it up. All the cool

>>> >> languages were developed by people with beards. The name is important

>>> >> too. Consider that three of the greatest languages in the history of

>>> >> computing, Lisp, Scheme, and Smalltalk, were all pretty much killed by

>>> >> their names. No real programmer wants to spend all day lisping,

>>> >> scheming, or making smalltalk.

>>> >>

>>> >> 5) Spend the time meditating, reading sutras, and practicing Kung Fu.

>>> >> At least I would feel a lot better :-)

>>> >>

>>> >> Except for #5, I would, of course, blog writing and otherwise make

>>> >> lots of noise about what I was doing.

>>> >>

>>> >> Comments? Flames?

>>> >

>>> > Well I would do 4th first.

>>> > Then use it to do 1st and give the first try for the language (As a

>>> > proof that

>>> > it is complete).

>>> > Now it is time to do the 2nd and 3th in parallel using Stonewolf of

>>> > course.

>>> >

>>> > Oh and mux some 5 to the whole period to balance everything.

>>> >

>>> > PS. I would like to help as much as I can manage in that language

>>> > design and

>>> > development.

>>> >

>>> > ---------------------

>>> > To unsubscribe go to http://gameprogrammer.com/mailinglist.html

>>> >

>>> >

>>> >

>>>

>>>

>>>

>>> --

>>> +-----------------------------------------------------------

>>> + Bob Pendleton: writer and programmer

>>> + email: Bob@xxxxxxxxxxxxx

>>> + web: www.TheGrumpyProgrammer.com

>>>

>>> ---------------------

>>> To unsubscribe go to http://gameprogrammer.com/mailinglist.html

>>>

>>>

>>

>

>







--

+-----------------------------------------------------------

+ Bob Pendleton: writer and programmer

+ email: Bob@xxxxxxxxxxxxx

+ web: www.TheGrumpyProgrammer.com



---------------------

To unsubscribe go to http://gameprogrammer.com/mailinglist.html










                                          
_________________________________________________________________
New: Messenger sign-in on the MSN homepage
http://go.microsoft.com/?linkid=9677403
References:
- [gameprogrammer] Re: Daydreaming, questioning....
  - From: Paulo Pinto
[gameprogrammer] Re: Daydreaming, questioning....

Other related posts:
