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

"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 <http://www.thegrumpyprogrammer.com/>
>
> ---------------------
>  To unsubscribe go to http://gameprogrammer.com/mailinglist.html
>
>
>

Other related posts: