[dev] Suckless design in Games
What game libraries are suckless? (SDL, OpenGL) What programming language is best for games? (C, Python, or Go)
Re: [dev] Suckless design in Games
I do not believe there's a suckless games library. The world of game coding is a different animal, and the libraries do what they say, we hope, and so we use them. It depends on the game. Most games want an Object Oriented Language, simply because the OO design is the best for something dealing with the manipulation of objects. The problem is the lack of a good OO language. I don't really know Go that well, but feel C and Go are bad places to start for game design. --Sean Somebody claiming to be Matthew Bauer wrote: > What game libraries are suckless? (SDL, OpenGL) > > What programming language is best for games? (C, Python, or Go) >
Re: [dev] Suckless design in Games
On Mon, Aug 9, 2010 at 10:14 PM, Sean Howard wrote: > Most games want an Object Oriented Language, simply because > the OO design is the best for something dealing with the manipulation of > objects. hahahah Most Meaningless Tautology Award for 2010 -- # Kurt H Maier
Re: [dev] Suckless design in Games
On Mon, Aug 09, 2010 at 09:02:53PM -0500, Matthew Bauer wrote: What game libraries are suckless? (SDL, OpenGL) What programming language is best for games? (C, Python, or Go) Surely you jest? -- Kris Maglione He hoped and prayed that there wasn't an afterlife. Then he realized there was a contradiction involved here and merely hoped that there wasn't an afterlife. --Douglas Adams
Re: [dev] Suckless design in Games
On Mon, Aug 09, 2010 at 10:14:02PM -0400, Sean Howard wrote: > It depends on the game. Most games want an Object Oriented Language, > simply because the OO design is the best for something dealing with > the manipulation of objects. The problem is the lack of a good OO > language. I don't really know Go that well, but feel C and Go are bad > places to start for game design. "OO design" is one of the most meaningless and harmful buzzwords in the history of computing.
Re: [dev] Suckless design in Games
* Matthew Bauer [2010-08-09 21:02:53 -0500]: > What game libraries are suckless? (SDL, OpenGL) > > What programming language is best for games? (C, Python, or Go) i consider this approach fairly nice and simple for 'flashgames': http://repo.hu/projects/animator/ reads drawing commands from stdin (optionally) writes events to stdout so game logic can be a separate process in whatever language (of course it has limitations eg only vector graphics, no bitmap operations like blitting and audio has to be handled separately)
Re: [dev] Suckless design in Games
A lot of the old-school games were written in assembly or C, so I believe it is quite possible to make excellent games with low level languages, and that the OO approach is unnecessary. That's my contribution to the conversation :). On 10 August 2010 20:23, Szabolcs Nagy wrote: > * Matthew Bauer [2010-08-09 21:02:53 -0500]: >> What game libraries are suckless? (SDL, OpenGL) >> >> What programming language is best for games? (C, Python, or Go) > > i consider this approach fairly nice and simple for 'flashgames': > http://repo.hu/projects/animator/ > > reads drawing commands from stdin > (optionally) writes events to stdout > > so game logic can be a separate process in whatever language > > (of course it has limitations eg only vector graphics, > no bitmap operations like blitting and audio has to be > handled separately) > >
Re: [dev] Suckless design in Games
On Mon, Aug 09, 2010 at 09:02:53PM -0500, Matthew Bauer wrote: > What game libraries are suckless? (SDL, OpenGL) > > What programming language is best for games? (C, Python, or Go) > Just hack on the Quake source ftp://ftp.idsoftware.com/idstuff/source/ pgpzUiBtFaZeH.pgp Description: PGP signature
Re: [dev] Suckless design in Games
I used to work for a small video game company. When I started we were making AGB games (Game Boy Advance) and all of our programming was in C (a bit of perl for auto-generated code). When we started working on NDS (Nintendo DS) games we switched to C++. Overall I think C++ worked better for us for a number of reasons, but the for-most reason is simply that games are object oriented. That said, it's not like we had any problems writing games in C. We still took an "object oriented" approach. It's important for me to clarify what I mean by object oriented however. Mostly this just meant encapsulation/grouping. A sprite would have a coordinate, a memory location in VRAM, etc. Inheritance in C++ was used, but sparingly and only when it made sense. Generally game programmers uses composition over inheritance. For example, a Player Entity can have either an ISA or HASA relationship with a sprite or 3D model depending on how you think about it and design it. In general it is preferable to use HASA relationships for everything as otherwise you end up with a ton of extra/useless code and complex, twisted diamond shaped inheritance graphs. Overall C++ lets you model game objects a little better (in my opinion) than C. That said, C is more than up to the task, and some of the greatest games have been written in C (pretty much everything by id software pre-Doom 4). Some of the best libraries are also written in C, like the two you mentioned: OpenGL and SDL. TL;DR - C++ makes some things nicer but you have to be careful because it can be tempting to add complexity. C is great for games. SDL is an excellent library to get started with, and has been used in some AAA titles (Unreal Tournament on Linux, for example). OpenGL is the standard for 3D on everything except WIndows/XBox. P.S. - If you are going to develop on Windows, XNA is pretty good. At this years Global Game Jam my team used C#/XNA. I went in with a very minimal understanding of C# and almost no XNA experience and managed to complete a 2D multiplayer game in 48 hours. Microsoft went through a lot of trouble to make things fairly obvious (although it still has its quirks). -Niki Yoshiuchi On Tue, Aug 10, 2010 at 2:43 AM, Jacob Todd wrote: > On Mon, Aug 09, 2010 at 09:02:53PM -0500, Matthew Bauer wrote: > > What game libraries are suckless? (SDL, OpenGL) > > > > What programming language is best for games? (C, Python, or Go) > > > Just hack on the Quake source ftp://ftp.idsoftware.com/idstuff/source/ >
Re: [dev] Suckless design in Games
Suckless programs like dwm or plan9 tools just do what they have to in a fast, simple, efficient way and extra non-necessary features are not welcome. Sure you can code a game in a way which sucks less, but I think that it's not so easy to say "Less is more" when the main purpose is to entertain. -- Wyrmskull
Re: [dev] Suckless design in Games
Hey, On 10 August 2010 14:51, lordkrandel wrote: > Sure you can code a game in a way which sucks less, but I think > that it's not so easy to say "Less is more" when the main purpose > is to entertain. I'm not sure I agree with you. There are lots of examples of games about which their simplicity is the most attractive thing. Such games are also particularly addictive. You may not be able to use the "less is more" approach if you plan on producing yet another throw-away FPS, but I think it works well if you're prepared to be creative. cls
Re: [dev] Suckless design in Games
On 10/08/2010 16.09, Connor Lane Smith wrote: On 10 August 2010 14:51, lordkrandel wrote: Sure you can code a game in a way which sucks less, but I think that it's not so easy to say "Less is more" when the main purpose is to entertain. I'm not sure I agree with you. There are lots of examples of games about which their simplicity is the most attractive thing. cls As in all fields of art, the purpose goes beyond "effectiveness" and "semplicity" or "productivity". Sure a simple design can be more attractive and addictive, but they say, de gustibus non dispuntanda est. -- Wyrmskull
Re: [dev] Suckless design in Games
On 10 August 2010 15:18, lordkrandel wrote: > As in all fields of art, the purpose goes beyond "effectiveness" > and "semplicity" or "productivity". Sure a simple design can be > more attractive and addictive, but they say, de gustibus non > dispuntanda est. By "simple" I do not mean "smaller", but rather, "elegant". When writing a program you must ensure that the code is both efficient (science) and understandable (linguistics), but also that the surface with which people interact is both easy (psychology) and beautiful (art). "The cart is more than the sum of its parts." This is what I mean by simplicity, and it is very much a matter of taste. So while I agree that the purpose goes beyond effectiveness and productivity, I think simplicity is the very essence of Art. cls
Re: [dev] Suckless design in Games
> So while I agree that the purpose goes beyond effectiveness and > productivity, I think simplicity is the very essence of Art. cls Do you live in a protestant country? I live in Italy, we have seen plenty of aesthetics. The classical "natural perfection" of the ancient Greek art, Baroque art, Mannerism, the sharp edges of Futurism... I personally don't like to mix personal taste with pragmatism. If anyone wants to build a game with a simple design, and probably very addictive, "Monaco" could be a good start. It has won come IGF prize this year. I bet there could be a suckless implementation with Nethack-like user interface. http://www.pocketwatchgames.com/Mwyim/ No need for examples of bloated games I guess. -- Wyrmskull
Re: [dev] Suckless design in Games
if a youtube video is the only reference for this game it just doesn't exist. i wrote pag SO MANY years ago. the source is magic, so dont try to understand it, because i decided to develop only when I was drunk and this was the result: http://hg.youterm.com/pag On 08/10/10 17:04, lordkrandel wrote: > So while I agree that the purpose goes beyond effectiveness and > productivity, I think simplicity is the very essence of Art. cls Do you live in a protestant country? I live in Italy, we have seen plenty of aesthetics. The classical "natural perfection" of the ancient Greek art, Baroque art, Mannerism, the sharp edges of Futurism... I personally don't like to mix personal taste with pragmatism. If anyone wants to build a game with a simple design, and probably very addictive, "Monaco" could be a good start. It has won come IGF prize this year. I bet there could be a suckless implementation with Nethack-like user interface. http://www.pocketwatchgames.com/Mwyim/ No need for examples of bloated games I guess.
Re: [dev] Suckless design in Games
Should I add "It also has a Facebook page"? :) Yeah, it doesn't exist. Yet. But the idea and the video are not bad. I just wanted to show something simple and modern, even if it's probably sucky code. On 10/08/2010 17.06, pancake wrote: if a youtube video is the only reference for this game it just doesn't exist. -- Wyrmskull
Re: [dev] Suckless design in Games
On 10 August 2010 16:04, lordkrandel wrote: > Do you live in a protestant country? > I live in Italy, we have seen plenty of aesthetics. No, I don't. England is officially neither Catholic nor Protestant. Not that Christianity has had much influence on my beliefs, and thanks to the Internet where one lives has little influence on one's tastes. > I personally don't like to mix personal taste with pragmatism. I believe that form and function are so intimately intertwined that pragmatism without aesthetic is meaningless. cls
Re: [dev] Suckless design in Games
> I believe that form and function are so intimately intertwined that > pragmatism without aesthetic is meaningless. > > cls I believe that real life context greatly affects one's tastes. Psychology is one's own history, with all the experiences life brings. I lived 16 years without Internet and I'm 26. If you want a tool to be functional, it may be required to have a certain shape - either if I like that shape or I don't. Art also has an objectively undefinable function, so you can't decide what a functional art form is. Simplicity is one arbitrary choice. I like Mozart and Minimalism just as much as I like Dadaism or free Jazz, even if they have different forms and subjective functions. It takes me quite some time to write in my crappy english by the way :) -- Wyrmskull
Re: [dev] Suckless design in Games
On 10/08/2010, lordkrandel wrote: > I believe that real life context greatly affects one's tastes. > Psychology is one's own history, with all the experiences life brings. I agree, though I have tended to be influenced by subcultures, so my beliefs and tastes are not really "British". > Art also has an objectively undefinable function, so you can't decide > what a functional art form is. Simplicity is one arbitrary choice. While form has no definable function, function must have form. It is the creator's duty to decide what form it will take, whether they are a painter or a programmer. But simplicity is an art form, not a function. > It takes me quite some time to write in my crappy english by the way :) Your English is actually very good; sorry for wasting your time. ;) (This is very philosophical for a software development mailing list.) cls
Re: [dev] Suckless design in Games
I think it's great that this is what this list does with a simple question about game toolkits -- # Kurt H Maier
Re: [dev] Suckless design in Games
... and SDL still sucks in dwm. Just my 2 cents.
Re: [dev] Suckless design in Games
Depends on how u use it On 10/08/2010, at 22:08, Jakub Lach wrote: > ... and SDL still sucks in dwm. > > Just my 2 cents. > > >
Re: [dev] Suckless design in Games
pancake wrote: > Depends on how u use it Maybe I should have phrased it clearer, or is there already a workaround making possible spawning a SDL using program window in non-reparenting wm? e.g. window spawned is blank, I observed same behaviour in scrotwm also.
Re: [dev] Suckless design in Games
On Tue, Aug 10, 2010 at 8:13 PM, Connor Lane Smith wrote: > On 10 August 2010 15:18, lordkrandel wrote: > > As in all fields of art, the purpose goes beyond "effectiveness" > > and "semplicity" or "productivity". Sure a simple design can be > > more attractive and addictive, but they say, de gustibus non > > dispuntanda est. > > By "simple" I do not mean "smaller", but rather, "elegant". When > writing a program you must ensure that the code is both efficient > (science) and understandable (linguistics), but also that the surface > with which people interact is both easy (psychology) and beautiful > (art). "The cart is more than the sum of its parts." This is what I > mean by simplicity, and it is very much a matter of taste. So while I > agree that the purpose goes beyond effectiveness and productivity, I > think simplicity is the very essence of Art. > Although I've "known" C++ for some time, it was only today that I found out about the Boost Graph Library. Browsing through the code, I realized the potential and power of template programming that is being exercised by experts. The level of abstraction that is being employed in the code is simply awe inspiring. It made me want to go back to the books and read up on template metaprogramming all over again. What I saw today in C++ was something that didn't meet my eye for a long time. I've often imagined C++ to be a sledgehammer solution to satisfy the wants of people who draw class diagrams and write "software", while I was always content with "programming" in C. Sophistication isn't always necessary but simplicity can be limiting. The BGL is a great example (IMHO) at showing what one can achieve with the language features that are part of C++ today. Somtimes we necessarily have to carry the weight of a more cumbersome language to achieve just that much more. Excuse me for the rant. I hope I haven't left the impression of being a C++ fanboy. It's just a case in point. I am more convinced, today more than ever, that simplicity shouldn't be a goal but rather an outcome -- of the design decisions that go into the project. It's a useful thing to have but sometimes we can do better without it. Chillu
Re: [dev] Suckless design in Games
On Tue, Aug 10, 2010 at 5:40 PM, Chidambaram Annamalai wrote: > Although I've "known" C++ for some time, it was only today that I found out > about the Boost Graph Library. Browsing through the code, I realized the > potential and power of template programming that is being exercised by > experts. The level of abstraction that is being employed in the code is > simply awe inspiring. It made me want to go back to the books and read up on > template metaprogramming all over again I hope to god this is a magnificent troll. There is nothing simple, beautiful, or elegant about Boost. -- # Kurt H Maier
Re: [dev] Suckless design in Games
On Wed, Aug 11, 2010 at 3:12 AM, Kurt H Maier wrote: > On Tue, Aug 10, 2010 at 5:40 PM, Chidambaram Annamalai > wrote: > > Although I've "known" C++ for some time, it was only today that I found > out > > about the Boost Graph Library. Browsing through the code, I realized the > > potential and power of template programming that is being exercised by > > experts. The level of abstraction that is being employed in the code is > > simply awe inspiring. It made me want to go back to the books and read up > on > > template metaprogramming all over again > > I hope to god this is a magnificent troll. There is nothing simple, > beautiful, or elegant about Boost. > I didn't argue BGL was simple. But I'd certainly consider it elegant. Of course I haven't seen too many well designed pieces of software for my opinion to count much, as I have few references to compare it against. Some of the abstractions that are being expressed in BGL are really nice. I have many specific examples in mind but I won't bore anyone any further. I suppose you have browsed through the sources an don't find anything novel in them. In which case, I certainly would like to know what you consider elegant. Then, maybe I can learn to appreciate good design? Chillu
Re: [dev] Suckless design in Games
On Tue, Aug 10, 2010 at 7:32 AM, Matthew Bauer wrote: > What game libraries are suckless? (SDL, OpenGL) > > What programming language is best for games? (C, Python, or Go) > Although it's not a library, Simon Tataham's puzzle collection is a large set (34?) of small and addictive (unequal, solo, cube, net and map are my favorites) games. The code is remarkably modular and most games share a lot of boilerplate code. It's written in C and it's very flexible with the choice of GUI toolkits etc. It has been ported to Android even. Chillu
Re: [dev] Suckless design in Games
An idea I had the other day, and this is for dealing with data compartmentation in games, was to write a game in C and use sqlite for all the data. I've never used sqlite so I don't know how the performance would go, but it seems like a good idea to store all the data in a relational database as it makes it less likely that the data structures would have to be refactored during development and it allows me to avoid having to use 'objects'.
Re: [dev] Suckless design in Games
On Wed, Aug 11, 2010 at 10:09:00AM +1000, Alex Hutton wrote: > An idea I had the other day, and this is for dealing with data > compartmentation in games, was to write a game in C and use sqlite for > all the data. I've never used sqlite so I don't know how the > performance would go, but it seems like a good idea to store all the > data in a relational database as it makes it less likely that the data > structures would have to be refactored during development and it > allows me to avoid having to use 'objects'. > But then you're using a database. Why not use a filesystem? Quake, Doom, and the games based off those engines (half-life, &c) do. pgpvKPZpuJ6N7.pgp Description: PGP signature
Re: [dev] Suckless design in Games
You're right, that would be even simpler. I was thinking about whether or not the 'relational' abilities of the database would come in handy but I haven't come up with any definite uses for them yet. On 11 August 2010 10:18, Jacob Todd wrote: > On Wed, Aug 11, 2010 at 10:09:00AM +1000, Alex Hutton wrote: >> An idea I had the other day, and this is for dealing with data >> compartmentation in games, was to write a game in C and use sqlite for >> all the data. I've never used sqlite so I don't know how the >> performance would go, but it seems like a good idea to store all the >> data in a relational database as it makes it less likely that the data >> structures would have to be refactored during development and it >> allows me to avoid having to use 'objects'. >> > But then you're using a database. Why not use a filesystem? Quake, Doom, and > the games based off those engines (half-life, &c) do. >
Re: [dev] Suckless design in Games
On Wed, Aug 11, 2010 at 11:04:24AM +1000, Alex Hutton wrote: > You're right, that would be even simpler. I was thinking about whether > or not the 'relational' abilities of the database would come in handy > but I haven't come up with any definite uses for them yet. join(1)
Re: [dev] Suckless design in Games
Thanks, join looks very useful. Actually a while ago I was talking to some web developer friends and I was talking about writing a CMS that uses flat files and no databases, but they thought I was crazy... don't know why I've started to conform to the database crowd :). Though from looking at sqlite it is not as overly complex as other systems; the whole database can be loaded into memory and there's no 'database server'. On 11 August 2010 12:56, Josh Rickmar wrote: > On Wed, Aug 11, 2010 at 11:04:24AM +1000, Alex Hutton wrote: >> You're right, that would be even simpler. I was thinking about whether >> or not the 'relational' abilities of the database would come in handy >> but I haven't come up with any definite uses for them yet. > > join(1) > >
Re: [dev] Suckless design in Games
On Wed, Aug 11, 2010 at 1:09 AM, Alex Hutton wrote: > An idea I had the other day, and this is for dealing with data > compartmentation in games, was to write a game in C and use sqlite for > all the data. I've never used sqlite so I don't know how the > performance would go, but it seems like a good idea to store all the > data in a relational database as it makes it less likely that the data > structures would have to be refactored during development and it > allows me to avoid having to use 'objects'. I don't know what granularity of data you're thinking of storing in the database. If it's very fine grained data then I'd expect you're going to hit concurrent writing lock-scaling problems (see, eg http://www.sqlite.org/faq.html#q5 ) Part of the reason why systems like git or hg don't use a standard database for their backends is that a general purpose database generally has limited means for expressing which subsets of the data are independent, and hence what the minimal locking is for writers (and reading whilst something may be writing), whereas, eg, the git backend knows due to the data struture and code design that it can do _almost_ everything without locking. (That's part of why it scales to things like Ingo Molnar's automated "Merge every single patch in every single remotely relevant patch queue into one mammoth kernel and try and boot it for regression testing".) One of the big advantages of "conceptual objects" (whether they're actual language objects) is that since they can have different implementations they can have different access semantics. As I mentioned in a different thread, if you look at a lot of "praised" old code it's perfectly well designed for the realities of computer architecture at the time it was written, but nowadays a lot of it is either "middlingly effectively written" or sometimes "PLEASE, PLEASE don't write code that way" examples. Just because new innovations aren't a magic bullet and are often overhyped doesn't meant they're worthless. Personally, I think it's a shame that there's no widespread language that has compiler/run-time support for "immutable once set-up" variables in this multicore age. (You can have a design in which a variable your design treats as immutable in C, but there's no inherent support, eg, for detecting violations or cloning copies for core's with a different cache, etc.) -- cheers, dave tweed__ computer vision reasearcher: david.tw...@gmail.com "while having code so boring anyone can maintain it, use Python." -- attempted insult seen on slashdot
Re: [dev] Suckless design in Games
On Tue, 10 Aug 2010 17:35:26 +0100 Connor Lane Smith wrote: > On 10/08/2010, lordkrandel wrote: > > I believe that real life context greatly affects one's tastes. > > Psychology is one's own history, with all the experiences life brings. > > I agree, though I have tended to be influenced by subcultures, so my > beliefs and tastes are not really "British". This list is a subculture itself (as is the 9fans list). > > It takes me quite some time to write in my crappy english by the way :) > > Your English is actually very good; sorry for wasting your time. ;) Indeed. > (This is very philosophical for a software development mailing list.) I thought this mailing list was *about* the philosophy of software development. Robert Ransom signature.asc Description: PGP signature
Re: [dev] Suckless design in Games
On Tue, 10 Aug 2010 17:57:08 +0200 lordkrandel wrote: > Art also has an objectively undefinable function, so you can't decide > what a functional art form is. Simplicity is one arbitrary choice. I'll let Uriel describe the value of the idea that ‘art [] has an objectively undefinable function’; his vocabulary is better suited to that task than mine. I will, however, point out one consequence of that idea: the most noticeable difference between abstract art and abstract mathematics is that abstract mathematics has some aesthetic value. Abstract art can now consist of a canvas painted one color, or mere splatters of paint (or other substances) on a surface; contrast that with the Mandelbrot and Julia sets, or the Hilbert and Peano space-filling curves and von Koch snowflake, or the elegant complexity which arises from the simple axioms of group theory. A pure mathematician does his work to satisfy his curiosity; an abstract artist does his work merely to see what he can get away with. I will also point out that a game does have a function -- to be fun. > I like Mozart and Minimalism just as much as I like Dadaism or free > Jazz, even if they have different forms and subjective functions. I hope you aren't suggesting that Mozart *is* minimalist. Robert Ransom signature.asc Description: PGP signature
Re: [dev] Suckless design in Games
* Chidambaram Annamalai [2010-08-11 03:26:22 +0530]: > I didn't argue BGL was simple. But I'd certainly consider it elegant. Of no it's not elegant graph algorithms are too versatile to do elegantly what boost tries to do (eg boost tries to operate on a generic graph type which cannot work as different graph representations often require different algorithms also space-time and other important tradoffs cannot be expressed this way) in bgl a shortest path algorithm has 12 arguments some of them are type parameters some of them are objects with various methods defined on them generic programming is mixed with oo inheritence all over the place (good luck figuring out the error message you get when you miss something) the entire library is implemented in header files (so compile time is guaranteed to be huge) using boost involves a fair amount of c++ trickery and boilerplate looking at boost examples i can not believe someone found this elegant elegant code reads like pseudo code boost is nothing like the code you find in algorithm books (i hoped that you were just trolling)
Re: [dev] Suckless design in Games
On 11/08/2010 2.09, Alex Hutton wrote: An idea I had the other day, and this is for dealing with data compartmentation in games, was to write a game in C and use sqlite for all the data. I've never used sqlite so I don't know how the performance would go, but it seems like a good idea to store all the data in a relational database as it makes it less likely that the data structures would have to be refactored during development and it allows me to avoid having to use 'objects'. SQL databases Less Harmful: Tutorial D, pq, BigTable, plain old hierarchical filesystems. from http://harmful.cat-v.org/software/ by Uriel -- Wyrmskull
Re: [dev] Suckless design in Games
On Wed, Aug 11, 2010 at 12:24 PM, Szabolcs Nagy wrote: > * Chidambaram Annamalai [2010-08-11 03:26:22 > +0530]: > > I didn't argue BGL was simple. But I'd certainly consider it elegant. Of > > no it's not elegant > > graph algorithms are too versatile to do elegantly what boost tries to do > (eg boost tries to operate on a generic graph type which cannot work > as different graph representations often require different algorithms > also space-time and other important tradoffs cannot be expressed this way) > Have you even bothered to look through the sources? You really have absolutely NO idea what you're talking about. The whole idea behind BGL is to decouple the storage schemes from the algorithms so that you can write O(M + N) code to support O(M*N) template instances. And there is no point if this abstraction had a severe penalty on the runtime performance. BGL exactly knows which algorithm to use for a particular storage mode because intelligence is built into it using traits. The hierarchial design (which is conceptually like OO inheritance) is to elimiate code bloat almost entirely, by only instantiating template classes that are absolutely essential. RTFM: http://portal.acm.org/citation.cfm?id=320385.320428 in bgl a shortest path algorithm has 12 arguments some of them are type > parameters some of them are objects with various methods defined on them > generic programming is mixed with oo inheritence all over the place > Template metaprogramming uses static polymorphism which is an entirely different beast from OO inheritance that uses dynamic polymorphism.
Re: [dev] Suckless design in Games
On Tue, Aug 10, 2010 at 12:39:24PM -0700, Robert Ransom wrote: > This list is a subculture itself (as is the 9fans list). wait what? i thought this list *was* the 9fetish^wfans list M.
Re: [dev] Suckless design in Games
I will, however, point out one consequence of that idea: the most noticeable difference between abstract art and abstract mathematics is that abstract mathematics has some aesthetic value. Abstract art can now consist of a canvas painted one color, or mere splatters of paint (or other substances) on a surface; contrast that with the Mandelbrot and Julia sets, or the Hilbert and Peano space-filling curves and von Koch snowflake, or the elegant complexity which arises from the simple axioms of group theory. A pure mathematician does his work to satisfy his curiosity; an abstract artist does his work merely to see what he can get away with. An artist is moved by curiosity about the world and himself just as scientists do in a rational way. The author satisfies this need through his work. You can find beauty in both a paint and a formal description of a theory. One can write songs to have a better and full understanding of what he is feeling and to try to convey his emotions to others, just like mathematicians convey their knowledge about the world through axioms, rules, laws, models. I will also point out that a game does have a function -- to be fun. Define in an objective way: to be fun. :P It is not a tool like hammers, "cat" command or applied maths. I'm thinking about applied coding, pure coding, and applied pure coding. Sounds almost like Kant xD I like Mozart and Minimalism just as much as I like Dadaism or free Jazz, even if they have different forms and subjective functions. I hope you aren't suggesting that Mozart *is* minimalist. It was an example of "elegance", to pinpoint the delta with Dadaism. Robert Ransom -- Wyrmskull
Re: [dev] Suckless design in Games
Robert Ransom dixit (2010-08-10, 23:12): > > I like Mozart and Minimalism just as much as I like Dadaism or free > > Jazz, even if they have different forms and subjective functions. > > I hope you aren't suggesting that Mozart *is* minimalist. He most definitely is (along with Chopin, I'd argue) – at the opposite end you'd find Bruckner, Wagner and Berlioz. Flame away, I'm on holiday. -- [a] pgph7IFwpuoBn.pgp Description: PGP signature
Re: [dev] Suckless design in Games
On Wed, 11 Aug 2010 10:16:07 +0200 lordkrandel wrote: > > I will, however, point out one consequence of that idea: the most > > noticeable difference between abstract art and abstract mathematics is > > that abstract mathematics has some aesthetic value. Abstract art can > > now consist of a canvas painted one color, or mere splatters of paint > > (or other substances) on a surface; contrast that with the Mandelbrot > > and Julia sets, or the Hilbert and Peano space-filling curves and von > > Koch snowflake, or the elegant complexity which arises from the simple > > axioms of group theory. A pure mathematician does his work to satisfy > > his curiosity; an abstract artist does his work merely to see what he > > can get away with. > > An artist is moved by curiosity about the world and himself just > as scientists do in a rational way. The author satisfies this need > through his work. You can find beauty in both a paint and a formal > description of a theory. One can write songs to have a better and > full understanding of what he is feeling and to try to convey his > emotions to others, just like mathematicians convey their knowledge > about the world through axioms, rules, laws, models. They are not abstract artists. Their works of art have functions. (A work's function includes ‘feeding its creator(s)’ surprisingly often.) > > I will also point out that a game does have a function -- to be fun. > Define in an objective way: to be fun. :P Oh goody. A philosopher. A computer game is a computer program whose creator intended primarily that human beings enjoy interacting with it. If you want an objective definition of ‘to enjoy’, ask a neurologist; they are finally starting to understand this sort of simple emotion. As I understand it, a human being (or other animal) enjoys an activity if the activity causes certain cells in his/her/its brain to produce and/or release dopamine. If you want an objective definition of ‘intended’, ‘interacting’, ‘computer program’, ‘human being’, ‘animal’, ‘cell’, ‘brain’, ‘dopamine’, ‘produce’, ‘release’, or ‘neurologist’, *** *** *** *** *. Uriel can elaborate on that if you want (or if you don't want). To the extent that this list has a topic, it seems to be ‘the philosophy of computer programming’. That does not mean that any of us want to read the kind of crap [that *is* a noun, right?] that university departments of Philosophy emit. > It is not a tool like hammers, "cat" command or applied maths. > I'm thinking about applied coding, pure coding, and applied pure coding. > Sounds almost like Kant xD *** *** *! > >> I like Mozart and Minimalism just as much as I like Dadaism or free > >> Jazz, even if they have different forms and subjective functions. > > I hope you aren't suggesting that Mozart *is* minimalist. > > It was an example of "elegance", to pinpoint the delta with Dadaism. Well, at least you have a glimmer of sanity. Robert Ransom signature.asc Description: PGP signature
Re: [dev] Suckless design in Games
A computer game is a computer program whose creator intended primarily that human beings enjoy interacting with it. I was just arguing that the idea of "suckless design" may fit not so well in game programming. That's why at a certain point I answered a message in a private way but then the reply came on the mailing list. Sorry for the "crap". > To the extent that this list has a topic, it seems to be ‘the > philosophy of computer programming’. That does not mean that any of > us want to read the kind of crap [that *is* a noun, right?] that > university departments of Philosophy emit. Suckless dev also means discussing about what "suckless design" is. I'll never quit saying: If you are not interested, do not read, do not reply. I'll get back when I have a -n lines patch so you will all be happy. Robert Ransom -- Wyrmskull
Re: [dev] Suckless design in Games
On Wed, 11 Aug 2010 11:19:37 +0200 lordkrandel wrote: > > A computer game is a computer program whose creator intended primarily > > that human beings enjoy interacting with it. > > I was just arguing that the idea of "suckless design" may fit not so > well in game programming. That depends on what the game's target audience enjoys. I cease to enjoy the Battle for Wesnoth when I have to manage well over a dozen units each turn, by hand, with a lousy GUI, and I forget what I was trying to *do* with each unit. I think I would enjoy a game with the same logic, but with the ability to set user-designed AIs for units and/or groups of units added to the frontend. The easiest way to allow that is probably to chop the GUI out of the game client and connect the two using a well-designed, well-specified protocol (preferably built on 9P). That would have the side effect of moving BfW slightly closer to the ‘suckless’ ideal. (Not noticeably closer, though; have you *seen* its WML data format?) If designed and implemented properly, a game can be quite suckless, and still have an interface that mainstream gamers (I know, that sounds like an oxymoron) enjoy interacting with. A suckless game should make interfaces that other audiences would enjoy easy to add, whether that is part of the definition of ‘suckless’ or just a side effect. > That's why at a certain point I answered a message in a private way > but then the reply came on the mailing list. Sorry for the "crap". I'm glad you aren't one of those professional philosophers (they *would* ask for more precise definitions of “neurologist” and “dopamine”). Your message was not crap, and objectively defining “to be fun” (by defining “to enjoy”; an activity is fun if the animals participating in it enjoy it) was probably useful, but I do NOT want to go one step beyond that down the road of trying to precisely define everyday words in terms of other words -- the sophists have done enough damage to society with their word games already. > > To the extent that this list has a topic, it seems to be ‘the > > philosophy of computer programming’. That does not mean that any of > > us want to read the kind of crap [that *is* a noun, right?] that > > university departments of Philosophy emit. > > Suckless dev also means discussing about what "suckless design" is. Good point, although I consider that an aspect of the philosophy of computer programming. We're never going to agree on how to define “suckless design”, but it'll be fun to try to find out what it means. (Through heated discussion, of course.) > I'll never quit saying: If you are not interested, do not read, do not > reply. I am interested in discussing useful philosophy. I am also very interested in keeping “grue” and “bleen” off this list. (For those of you who have not been exposed to that bit of modern sophistry, “grue” does not refer to the monsters in Zork here.) > I'll get back when I have a -n lines patch so you will all be happy. ??? Code size isn't the only measure of complexity. Sometimes, one program needs to be made larger in order to keep the complexity of a larger system down. Let's start another flame war: I think pacman (the Arch Linux package manager) is too simple to manage packages well. Seriously. Robert Ransom signature.asc Description: PGP signature
Re: [dev] Suckless design in Games
* Chidambaram Annamalai [2010-08-11 13:12:46 +0530]: > Have you even bothered to look through the sources? You really have yes although it was a couple of years ago last time i used bgl > to decouple the storage schemes from the algorithms so that you can write > O(M + N) code to support O(M*N) template instances. And there is no point if > this abstraction had a severe penalty on the runtime performance. BGL > exactly knows which algorithm to use for a particular storage mode because > intelligence is built into it using traits. The hierarchial design (which is this is a misconception about bgl and c++ generic programming in general you can treat certain aspects of the algorithms but not everything genericity is only available where the designers thought about it (eg you cannot reuse a stack in dfs graph traversals of various graphs because it is hardcoded in boost) this usually ends up in a lot of configurability where users don't need it, but the result is still not flexible enough for practical problems that's why everyone ends up implementing their own containers instead of using stl in a bigger c++ project (eg by adding concurrency support or using different tradeoffs in the algorithm design, so eventhough stl is very generic it is still not flexible enough) intuition tells that generic code allows easy replacement of components but this is a fallacy: - the designer must know how the code will be used in advance and decompose the algorithms that way - the users need to know a lot more about the internal implementation, how an abstract component interacts with others (the more fine grained the generic code the more difficult to use it) (it's not true that you can easily write your own graph represantation to use it with boost you need to know a lot of details) (from the docs a lot of semantic detail is not clear, eg can you modify a graph from a visitor? boost uses iterators and in many datastructure modifications invalidates them) - when an algorithm is used in the most simple and usual way, genericity causes a lot of unnecessary boilerplate, confusion about the api, and cryptic compiler error messages (to find the shortest path in a simple directed graph with int edge weights, i still have to fill the template arguments http://www.boost.org/doc/libs/1_43_0/libs/graph/example/dijkstra-example.cpp this is not elegant code) i experimented with various types of genericity for algorithms here is one approach: implement the algorithm in the simplest way for the most useful types etc. then when you need it for a specific task then copy the code and apply appropriate modifications in the source (often s/type1/type2/g) it turns out that with this approach it's often easier to change a component without screwing things up than by understanding all the gory details of a generic api like boost adapting an algorithm for your usecase usually takes less than an hour and the result is readable customized code, easy to debug, easy to edit > Template metaprogramming uses static polymorphism which is an entirely > different beast from OO inheritance that uses dynamic polymorphism. yes, each of them has quirks and the user of the library should deal them (using various concepts together the complexity of the result is the product of the complexity of each part, not the sum) my argument is that this amount of abstraction just not worth the effort (at least in c++)
Re: [dev] Suckless design in Games
On Wed, Aug 11, 2010 at 10:32:15AM +0200, Antoni Grzymala wrote: > > I hope you aren't suggesting that Mozart *is* minimalist. > > He most definitely is (along with Chopin, I'd argue) – at the opposite > end you'd find Bruckner, Wagner and Berlioz. Flame away, I'm on holiday. Mozart and Chopin really have nothing to do with Minimalism. Some of Mozart's pieces are maybe light (but not all of them, like Don Giovanni or Kyrie Eleison from Requiem), and Chopin may be elegant, but Minimalism is a seperate genre of music, represented by composers like John Adams, Steve Reich and Philip Glass. One of the big differences is the theme development, Minimalists use none of the classical forms of Mozart or Chopin, but rather a repetitive form of slow progression. No flames, just information :) Eivind
Re: [dev] Suckless design in Games
On Wed, Aug 11, 2010 at 9:13 PM, Eivind Michael Skretting wrote: > > Mozart and Chopin really have nothing to do with Minimalism. Some of Mozart's > pieces are maybe light (but not all of them, like Don Giovanni or Kyrie > Eleison from Requiem), and Chopin may be elegant, but Minimalism is a > seperate genre of music, represented by composers like John Adams, Steve > Reich and Philip Glass. > > One of the big differences is the theme development, Minimalists use > none of the classical forms of Mozart or Chopin, but rather a repetitive > form of slow progression. You are technically right, but this "minimalism" is nothing more than a name tag. Opponents of Steve Reich & Philip Glass may say their music has needless repetitions. To contrast, consider Bach's Chaconne: "On one stave, for a small instrument, the man writes a whole world of the deepest thoughts and most powerful feelings." Is this a minimalist piece, even when it's 15min long? As a former composition student, I would say it is. I think the essence of minimalism is that one take away as much as one possibly can. It's interesting that in this meaning, minimalism is not just the opposite of bloat, but also denotes some kind of balance. -- @chickamade
Re: [dev] Suckless design in Games
On 11 August 2010 15:35, Anh Hai Trinh wrote: > I think the essence of minimalism is that one take away as much as one > possibly can. > > It's interesting that in this meaning, minimalism is not just the > opposite of bloat, but also denotes some kind of balance. "The simplicity of wabi-sabi is best described as the state of grace arrived at by a sober, modest, heartfelt intelligence. The main strategy of this intelligence is economy of means. Pare down to the essence, but don’t remove the poetry. Keep things clean and unencumbered, but don’t sterilize. (Things that are wabi-sabi are emotionally warm, never cold.) Usually this implies a limited palette of materials. It also means keeping conspicuous features to a minimum. But it doesn’t mean removing the invisible connective tissue that somehow binds the elements into a meaningful whole." -- Leonard Koren It seemed appropriate, and I just adore that quote. cls
Re: [dev] Suckless design in Games
On 11 August 2010 05:28, Alex Hutton wrote: > Thanks, join looks very useful. Actually a while ago I was talking to > some web developer friends and I was talking about writing a CMS that > uses flat files and no databases, but they thought I was crazy... > don't know why I've started to conform to the database crowd :). > Though from looking at sqlite it is not as overly complex as other > systems; the whole database can be loaded into memory and there's no > 'database server'. Databases are all too often used when flat files would do. Only in certain circumstances do a database's benefits outweigh its overhead. You are right, though - if you do have to use a relational database, SQLite is often the way to go. cls
Re: [dev] Suckless design in Games
On Wed, Aug 11, 2010 at 1:05 PM, Szabolcs Nagy wrote: > i experimented with various types of genericity for algorithms > here is one approach: > implement the algorithm in the simplest way for the most useful types > etc. then when you need it for a specific task then copy the code and > apply appropriate modifications in the source (often s/type1/type2/g) > > it turns out that with this approach it's often easier to change > a component without screwing things up than by understanding all > the gory details of a generic api like boost > > adapting an algorithm for your usecase usually takes less than an hour > and the result is readable customized code, easy to debug, easy to edit I spent a while working for a company that used that philosphy (albeit in Matlab). As someone who didn't write the original algorithms (so I didn't have the slowly accumulated knowledge from having been the one who wrote them) it was a complete nightmare because there were various implementations of a basic algorithm, all different subsets of the bugs that had ever existed in the algorithm development depending on when and who they'd branched from. Worse, once this had been done for a while the using code sometimes grew to depend on some of the "bugs" (rather than biting the bullet and consolidating them and dealing with the fallout) so you had to basically keep in mind what peculiarities this particular implementation of the algorithm had (which of course was always from memory because even in this case, the original code writers frown on you putting comments about what bugs their code has). And of course, because "if you can't see that the code has broken, don't poke it" when a bug was fixed in one implementation the other implementations weren't checked whilst memories were fresh. Unified implementations would have required more up-front work, but would I think have been less work overall. (The people who had actually written the rats maze of code disagreed; it's difficult to see how much was partly because it was their baby.) All of your points have some validity, but given the choice between one algorithm implementation with a complex BUT EXPLICIT API and multiple "implementations of some algorithm that does something along these lines" with simple APIs, personally I'd take the one implementation. -- cheers, dave tweed__ computer vision reasearcher: david.tw...@gmail.com "while having code so boring anyone can maintain it, use Python." -- attempted insult seen on slashdot
Re: [dev] Suckless design in Games
On 10 August 2010 22:56, Chidambaram Annamalai wrote: > I suppose you have browsed through the sources an don't find anything novel > in them. In which case, I certainly would like to know what you consider > elegant. Then, maybe I can learn to appreciate good design? I haven't even heard of Boost until now, and I don't know C++, but I have looked at some elegant, and a lot of not-so-elegant, code. I used to consider Plan 9 to be elegant, but as I've grown more familiar with the source behind the concepts, I'm not quite so sure anymore. (Heretic!) Amongst my most admired code is xv6[1], a modern x86 reimplementation of UNIX V6 by Russ Cox, Frans Kaashoek, and Robert Morris. Having hacked around with the source while I was writing my own kernel, I have to say, it really is beautiful. (A lot of credit must go to Ken Thompson, Dennis Ritchie, et al for the original V6, of course.) cls [1]: http://pdos.csail.mit.edu/6.828/xv6/
Re: [dev] Suckless design in Games
On Wed, Aug 11, 2010 at 09:35:48PM +0700, Anh Hai Trinh wrote: > I think the essence of minimalism is that one take away as much as one > possibly can. > Then one should exclude Chopin from that definition. In regard to the "needless repetitions" of Reich and Glass, that is much of what the style is about. The music is more about structures and patterns than melody and harmony. On a end note, the original mention of Minimalism was with a capital "M", so I figured the discussion needed some clearing-up. Eivind
Re: [dev] Suckless design in Games
On Wed, Aug 11, 2010 at 10:08 PM, Eivind Michael Skretting wrote: > On Wed, Aug 11, 2010 at 09:35:48PM +0700, Anh Hai Trinh wrote: >> I think the essence of minimalism is that one take away as much as one >> possibly can. >> > > Then one should exclude Chopin from that definition. What do you mean exactly? His A major Prelude is probably the shortest piece of music that exists (20~ seconds) and amongst the most beautiful. If that is not minimalistic, I don't know what is. Chopin is, after all, most famous for his _miniature_ pieces. > On a end note, the original mention of Minimalism was with a capital > "M", so I figured the discussion needed some clearing-up. Point taken. -- @chickamade
Re: [dev] Suckless design in Games
Eivind Michael Skretting dixit (2010-08-11, 16:13): > > He most definitely is (along with Chopin, I'd argue) – at the opposite > > end you'd find Bruckner, Wagner and Berlioz. Flame away, I'm on holiday. > > Mozart and Chopin really have nothing to do with Minimalism. Some of Mozart's > pieces are maybe light (but not all of them, like Don Giovanni or Kyrie > Eleison from Requiem), and Chopin may be elegant, but Minimalism is a > seperate genre of music, represented by composers like John Adams, Steve > Reich and Philip Glass. > > One of the big differences is the theme development, Minimalists use > none of the classical forms of Mozart or Chopin, but rather a repetitive > form of slow progression. > > No flames, just information :) I'm well aware of the style represented by Reich, Glass et al., however: Anh Hai Trinh dixit (2010-08-11, 21:35): > You are technically right, but this "minimalism" is nothing more than > a name tag. > > Opponents of Steve Reich & Philip Glass may say their music has > needless repetitions. > > To contrast, consider Bach's Chaconne: "On one stave, for a small > instrument, the man writes a whole world of the deepest thoughts and > most powerful feelings." Is this a minimalist piece, even when it's > 15min long? As a former composition student, I would say it is. > > I think the essence of minimalism is that one take away as much as one > possibly can. And this is exactly the essence of Chopin's music – absolute necessary minimum (with regards to the style and the times around which Chopin's work was created, perhaps you have to get to know Chopin's music quite well to actually appreciate this). Quoting Antoine de Saint-Exupéry: „Perfection is reached, not when there is no longer anything to add, but when there is no longer anything to take away.” Which could easily be said about Chopin's music as much as Bach and Mozart (taking into account different stylistic considerations). Though the two latter are probably not as even in high-quality work (see below). Anh Hai Trinh dixit (2010-08-11, 22:29): > >> I think the essence of minimalism is that one take away as much as one > >> possibly can. > >> > > > > Then one should exclude Chopin from that definition. Definitely not! > What do you mean exactly? His A major Prelude is probably the shortest > piece of music that exists (20~ seconds) and amongst the most > beautiful. If that is not minimalistic, I don't know what is. Chopin > is, after all, most famous for his _miniature_ pieces. I would argue about that: the mid-sized Impromptus, Ballades, Fantaise and Barcarolle (and the lateish-largish Mazurkas and Nocturnes) are probably his best works, but the entire published (by him) body of work is of such high quality, that it's pretty difficult to discuss which particular works are “best”. As to the “shortest piece ever written contest”, I'm certain there are lots others, a tiny e-flat-minor prelude (about three lines) by Scriabin immediately springs to mind. Almost Haiku (if not for the late romantic style :)). > > On a end note, the original mention of Minimalism was with a capital > > "M", so I figured the discussion needed some clearing-up. > > Point taken. Yeah, I just had a knee-jerk reaction to “Mozart *not* being minimalist” (without the capital “M”), which in my opinion, and by the above account he certainly is. -- [a]
Re: [dev] Suckless design in Games
On Wed, Aug 11, 2010 at 10:29:18PM +0700, Anh Hai Trinh wrote: > On Wed, Aug 11, 2010 at 10:08 PM, Eivind Michael Skretting > wrote: > > On Wed, Aug 11, 2010 at 09:35:48PM +0700, Anh Hai Trinh wrote: > >> I think the essence of minimalism is that one take away as much as one > >> possibly can. > >> > > > > Then one should exclude Chopin from that definition. > > What do you mean exactly? His A major Prelude is probably the shortest > piece of music that exists (20~ seconds) and amongst the most > beautiful. If that is not minimalistic, I don't know what is. Chopin > is, after all, most famous for his _miniature_ pieces. Well, first of all, as have been mentioned, it's not about lenght. And Chopin's harmonies is in no way minimalistic (meaning "simple"), and all the trills and (argh, don't remember the english word... lots-of-tones) is more the work of a piano virtuoso than a "minimalistic" composer. He did, after all, write things down like he played it, which resultet in different editions to different publishers, in the same period of time! Well, isn't this a fun discussion to have in a programmer's mailing list :) Eivind
Re: [dev] Suckless design in Games
On Wed, Aug 11, 2010 at 11:20 PM, Eivind Michael Skretting wrote: >> >> What do you mean exactly? His A major Prelude is probably the shortest >> piece of music that exists (20~ seconds) and amongst the most >> beautiful. If that is not minimalistic, I don't know what is. > > Well, first of all, as have been mentioned, it's not about lenght. Email me off-list about this if you want to discuss this point further but no matter what angle you look at this piece, there is just no way it is not minimalistic. > And Chopin's harmonies is in no way minimalistic (meaning "simple"). Not for that particular piece. In general, nowadays, Chopin's harmony is considered to be in the Common Practice Period and are well understood by second-semester harmony students. It is not simple, but certainly not complex. Chopin's harmony to a music student is like a heap to a programmer. (obviously this is just a way of saying) -- @chickamade
Re: [dev] Suckless design in Games
On Wed, Aug 11, 2010 at 11:06 PM, Antoni Grzymala wrote: > > I would argue about that: the mid-sized Impromptus, Ballades, Fantaise > and Barcarolle (and the lateish-largish Mazurkas and Nocturnes) are > probably his best works, but the entire published (by him) body of > work is of such high quality, that it's pretty difficult to discuss > which particular works are “best”. The ballades are quite unique, but the rest you mention is a bit of bloat to me. Chopin sucks at larger forms. If the only Chopin collection to survive is the Preludes, I would still consider him top notch. I believe I'm not alone on this position. minimalism ftw! -- @chickamade
Re: [dev] Suckless design in Games
On Thu, Aug 12, 2010 at 12:08:13AM +0700, Anh Hai Trinh wrote: > On Wed, Aug 11, 2010 at 11:20 PM, Eivind Michael Skretting > wrote: > >> > >> What do you mean exactly? His A major Prelude is probably the shortest > >> piece of music that exists (20~ seconds) and amongst the most > >> beautiful. If that is not minimalistic, I don't know what is. > > > > Well, first of all, as have been mentioned, it's not about lenght. > > Email me off-list about this if you want to discuss this point further > but no matter what angle you look at this piece, there is just no way > it is not minimalistic. > > > And Chopin's harmonies is in no way minimalistic (meaning "simple"). > > Not for that particular piece. In general, nowadays, Chopin's harmony > is considered to be in the Common Practice Period and are well > understood by second-semester harmony students. It is not simple, but > certainly not complex. Chopin's harmony to a music student is like a > heap to a programmer. (obviously this is just a way of saying) Well, just to finish, I am a music student, so I do know what I am talking about, and that it's complexity is a matter of what it's compared to (I think I understand Chopin's harmony better than heaps, by the way). Thanks for the argument, anyway! Eivind
Re: [dev] Suckless design in Games
> > to decouple the storage schemes from the algorithms so that you can write
> > O(M + N) code to support O(M*N) template instances. And there is no point
> if
> > this abstraction had a severe penalty on the runtime performance. BGL
> > exactly knows which algorithm to use for a particular storage mode
> because
> > intelligence is built into it using traits. The hierarchial design (which
> is
> this is a misconception about bgl and c++ generic programming in general
>
> you can treat certain aspects of the algorithms but not everything
> genericity is only available where the designers thought about it
> (eg you cannot reuse a stack in dfs graph traversals of various graphs
> because it is hardcoded in boost)
>
> this usually ends up in a lot of configurability where users don't
> need it, but the result is still not flexible enough for practical
> problems
>
I really haven't used bgl in any serious way like a project or so. So maybe
what you're saying is true.
BGL's flexbility might become a problem in itself as it requires knowing so
much that, it becomes a library by experts and for experts. This is a rather
unfortunate outcome. I am far from a language expert but I think such
problems arise because syntactically C++ does not provide sufficient
flexibility for expressing abstractions without writing extensive amounts of
code to make it abundantly clear as to what you're trying to do.
that's why everyone ends up implementing their own containers instead
> of using stl in a bigger c++ project
> (eg by adding concurrency support or using different tradeoffs in the
> algorithm design, so eventhough stl is very generic it is still not
> flexible enough)
>
> intuition tells that generic code allows easy replacement of components
> but this is a fallacy:
> - the designer must know how the code will be used in advance
> and decompose the algorithms that way
> - the users need to know a lot more about the internal implementation,
> how an abstract component interacts with others
> (the more fine grained the generic code the more difficult to use it)
> (it's not true that you can easily write your own graph represantation
> to use it with boost you need to know a lot of details)
> (from the docs a lot of semantic detail is not clear, eg can you modify
> a graph from a visitor? boost uses iterators and in many datastructure
> modifications invalidates them)
> - when an algorithm is used in the most simple and usual way, genericity
> causes a lot of unnecessary boilerplate, confusion about the api, and
> cryptic compiler error messages
> (to find the shortest path in a simple directed graph with int edge
> weights, i still have to fill the template arguments
>
> http://www.boost.org/doc/libs/1_43_0/libs/graph/example/dijkstra-example.cpp
> this is not elegant code)
>
You have a point here. I have written python code during my graph theory
course to implement algorithms on graphs and they turned out to be
remarkably clear and concise. I recall that being able to use dictionaries
to implement the adjacency lists and the lack of strong typing requirements
led to very readable code. Here's one that computes the all paths between
two vertices in a directed graph:
#!/usr/bin/env python
graph = {'A': ['B', 'C'],
'B': ['C', 'D'],
'C': ['D'],
'D': ['C'],
'E': ['F'],
'F': ['C']}
def find_all_paths(G, start, end, visited = []) :
for i in G[start] :
if i not in visited :
if i == end :
yield [start] + [i]
else :
for j in find_all_paths(G, i, end, visited + [start]) :
yield [start] + j
start, end = 'A', 'D'
for i in find_all_paths(graph, start, end):
print i
i experimented with various types of genericity for algorithms
> here is one approach:
> implement the algorithm in the simplest way for the most useful types
> etc. then when you need it for a specific task then copy the code and
> apply appropriate modifications in the source (often s/type1/type2/g)
>
> it turns out that with this approach it's often easier to change
> a component without screwing things up than by understanding all
> the gory details of a generic api like boost
>
> adapting an algorithm for your usecase usually takes less than an hour
> and the result is readable customized code, easy to debug, easy to edit
>
I had written some C code for a programming assignment and my experiences
parallel what you describe here. It had no dependencies on external
libraries and everything was done from scratch (ok that wasn't a choice I
had -- assignment remember :)). It turned out to be fairly simple to
implement and use and most importantly maintain. I can go back to the code
today and still understand most things quickly.
> > Template metaprogramming uses static polymorphism which is an entirely
> > different beast from OO inheritance that uses dynamic polymorphism.
> yes, each of them has quirks and the user of the
Re: [dev] Suckless design in Games
On Wed, Aug 11, 2010 at 8:37 PM, Connor Lane Smith wrote: > On 10 August 2010 22:56, Chidambaram Annamalai > wrote: > > I suppose you have browsed through the sources an don't find anything > novel > > in them. In which case, I certainly would like to know what you consider > > elegant. Then, maybe I can learn to appreciate good design? > > I haven't even heard of Boost until now, and I don't know C++, but I > have looked at some elegant, and a lot of not-so-elegant, code. I used > to consider Plan 9 to be elegant, but as I've grown more familiar with > the source behind the concepts, I'm not quite so sure anymore. > (Heretic!) > Interesting. May I ask what languages you are familiar with? > Amongst my most admired code is xv6[1], a modern x86 reimplementation > of UNIX V6 by Russ Cox, Frans Kaashoek, and Robert Morris. Having > hacked around with the source while I was writing my own kernel, I > have to say, it really is beautiful. (A lot of credit must go to Ken > Thompson, Dennis Ritchie, et al for the original V6, of course.) > Thanks for pointing me to beautful code! I will definitely take a look at this. Chillu
Re: [dev] Suckless design in Games
On 11 August 2010 19:15, Chidambaram Annamalai wrote: > Interesting. May I ask what languages you are familiar with? C, Python, and Java, mostly, with some Ruby, Vala, Awk, etc on the side. I've just never had a reason to learn C++, really. cls
Re: [dev] Suckless design in Games
On Fri, Aug 13, 2010 at 9:45 PM, Connor Lane Smith wrote: > On 11 August 2010 19:15, Chidambaram Annamalai > wrote: > > Interesting. May I ask what languages you are familiar with? > > C, Python, and Java, mostly, with some Ruby, Vala, Awk, etc on the > side. I've just never had a reason to learn C++, really. > I wanted to learn Clojure some time back, Clojure being a nice functional language that also parallelizes easily (given that the code can be parallelized). I still consider my abilities lacking because of not being able to implement concurrently executing code in the languages I know. Project Euler seems like a nice place to start if I wanted to learn Clojure.. :) Coming to think of it, I never had a reason to learn C++ too. We were forced to learn it in school and it stuck. Actually we had a choice between C++ and biology and I thought I knew better ;) --chillu
