Programming, graphics, games, media, C++, Windows, Internet and more...
Entries for tag "philosophy", ordered from most recent. Entry count: 34.
# Programmer Incompetence?
Fri
18
Jun 2010
Today I'll be a little more philosophical, of course in terms of programming philosophy ;) I manage a long list of Web addresses I'd like to visit in my free time (which I gather mostly from Twitter) and today I've visited these two places:
They reminded me of my old thought that on the way of mastering the art of programming there is no such thing as diversity - no place for personal preferences that would be only a matter of taste, like favorite music. There is usually only one correct path. All the good practices and solutions are just a function of what do you want to do and what technologies do you use. I constantly learn stuff, interact with programmers better than me as well as observe and talk to these who just start their adventure in the programming world. From all these experiences I can see that there usually is a single, correct solution or the way of thinking about simply anything. The one who doesn't agree with it is just not "mature" enough to be able to see that. Another sad truth is that this "maturing" process cannot be accelerated - one can read about the "correct" way but just rejects it until he will come to it by himself.
I especially like the 5 Stages of Programmer Incompetence entry. Here is my self-diagnosis against its points:
Comments | #software engineering #philosophy Share
# Some Thoughts about Library Design
Sun
16
May 2010
Much has been said about designing good user interface, whether for desktop applications, websites or games. There are whole books available about GUI design and even this year's IGK-7'2010 conference featured two lectures about the interface in games. But what about interfaces for programmers?
I can't find much about the rules of good library API design and I believe there is much to say in this subject. I only know The Little Manual of API Design written by Jasmin Blanchette from Trolltech/Nokia, one of the creators of Qt library (thanks for the link Przemek!). There is also a blog entry about Math Library, which is quite interesting. Inspired by it, I've came up with a general thought that you cannot have all the following features when designing a library and its API, you have to choose 2 or 3 of them and make some compromise:
I think some patterns and best practices as well as some anti-patterns could be found when you look at interfaces of many libraries. Maybe I'll post some more of my thoughts on this subject in the future. In the meantime, do you know any other resources about API design?
Comments | #philosophy #software engineering #libraries Share
# My Theory of Communication
Mon
31
Aug 2009
Today is the Blog Day. I'm not going to link the blogday.org website or apply their advices about recommending other blogs, but instead I want to present my little theory explaining what's the place of blogging and tweeting among other forms of communication.
I think that communication and knowledge sharing can be seen as a spectrum, where each form has its place between two extremes - first is writing/reading a book and the second is a casual real-life chat. I hope this diagram explains everything:
So if you only like to read books and you disregard communication via the Internet and casual chatting or the opposite - you are used to only write and read short messages to your friends and you never read books or write long letters - then think for a while whether your way of communication is really better than others or maybe your beliefs make you losing some of the opporunities from this full spectrum that you may enjoy...
Comments | #philosophy #web Share
# About the Guy Who Made Love
Sat
22
Aug 2009
Today I want to talk a bit about what's the dream of almost every passionate game developer. It seems very hard or almost impossible to achieve, but younger amateurs still hope that they will manage to do it someday. Of course I'm talking about making a 3D MMO game.
As it turned out for me today (thanks for the link KriS!), it actually IS possible. I'm talking about the game called Love written entirely by one person - Eskil Steenberg. He have coded all the software from modeling tools through network protocol and renderer until game mechanics. To see it working I recommend watching these videos. The game is powered by his engine called Quel Solaar, which is actually available for download.
I must admit I haven't been impressed so much for a long time. I suppose the amount of time and passion that had to be put into this code is enormous. Graphical style and gameplay, as well as the user interface of his tools are very unusual and surprising. And all of this is made by one guy...
I recommend watching his lecture from this year's Assembly party titled Developing the technology behind "Love". You can see many technical details and if you don't want to watch the entire one hour video, at least watch the beginning (where he talks about his "smarter way of doing things") and the ending (where he expresses his thoughts about the value of good tools).
BTW it's also nice to watch new videos from GC 2009 of the CryEngine 3. "What you see is what you play" and instant asset update (including textures) - that's how good game editor should look like :)
Comments | #software engineering #networking #web #rendering #games #events #engine #demoscene #philosophy #tools Share
# How Do People Write Bad Code
Wed
05
Aug 2009
Recently yarpen posted some thoughts about source code scalability on his blog. His blog entries are always very valuable and this time he touched broader subject which is connected to software antipatterns.
I want to expand this subject further and think a bit about how is such bad code created (we all agree that non-scalable code is bad, right? :) In my personal opinion it's generally caused by the lack of thinking. For example, if a coder have to code something (or, how some people would like to say: to solve a problem), he should first consider what possible solutions are. This may be choice of a technology, programming languages and libraries, some design patterns, algorithms, data structures or even names for some objects. If he doesn't think about it, he just selects the first option that came to his mind without considering alternatives and thus risks that he didn't make the best possible decision.
Next, the coder should design his solution. Designing is all about thinking before doing. If he skips this step, he may meet during his coding a situation when sees he came the wrong way and now he must refactor or even delete big part of his code and then just... rethink it :) I like the saying It's better to think twice before you start coding than to code twice before you start thinking.
:)
The same applies to all changes made to an existing code. If somebody have to change something in a program, he'd better review the code carefully to discover and understand its architecture. If he just starts making changes to the code, he risks that he will break some hidden assumptions in some aspects of the code (like variable values, objects lifetime, order of function calls etc.) and thus create bugs.
The reason behind writing poor code may be rush. If a coder wants to code something as quick and simply as possible (or his boss tells him to do it this way), he will do ugly hacks and never refactor anything, even if some refactoring is necessary at this point. Of course this it to bad code and will backfire in the future, when the code will have to be changed and it will turn out to be totally unscalable. So we obviously see that such attitude is just the lack of thinking.
But this problem may also be something deeper. I can see that some coders just always write bad, unscalable code by their nature. I don't want to offend anyone, but I think maybe that's the crucial difference between junior and more experienced programmers. To work as a programmer, everyone needs to "speak fluently" his programming language to freely express his thoughts using it, but experienced programmers are also able to see a bigger picture - some invisible assumptions and more abstract concepts behind the code. They see words like "handle", "manager", "alignment", "serialization", "callback" and hundreds of other terms (anyone thought about creating coder's dictionary with words like these?) and just knows what hides behind them.
Three days after yarpen's entry there appeared a blog entry about code documentation on EntBlog. It describes two main types of documents - API documentation and technical articles. I fully agree with this text. I value documentation very much and I think that good documentation is another piece of this big puzzle.
They say that there are two types of people: these who make backups and these who will make it
:) I think it's the same with writing good code and documentation. It's just the matter of thinking forward.
Comments | #software engineering #philosophy Share
# Fanatyzm obiektowy i mania wrapowania
Tue
31
Mar 2009
Napisałem mały felieton, esej czy jak to się tam nazywa (polonista ze mnie kiepski :) Zwykle nie lubię narzekać, wolę pozytywnie podchodzić do życia. Nie lubię też wygłaszać swoich poglądów (bo "poglądy są jak d*** - każdy ma swoje, ale po co je pokazywać" ;) Jednak tym razem postanowiłem podzielić się swoimi przemyśleniami na temat programowania obiektowego. Tekst nosi tytuł Fanatyzm obiektowy. Właściwie to ten tekst umieściłem w dziale Download już dawno temu, ale dzisiaj dopisałem do niego nowy rozdział - "Mania wrapowania". Zapraszam do czytania i komentowania.
Comments | #software engineering #philosophy #c++ Share
# O wyższości wyszukiwania nad wybieraniem
Tue
10
Feb 2009
Mam wrażenie, że w rozwoju interfejsów użytkownika za szczyt wygody dawniej uważane było pokazanie listy jakiś elementów do wybrania przez kliknięcie myszką. Natomiast teraz jasne staje się, że lepiej pozwolić użytkownikowi zacząć wpisywać jakiś wyraz do wyszukania i od razu pokazywać listę pasujących wyników. Taką możliwość mamy np. w:
Comments | #philosophy #gui Share
# Filozofia #2 - Układ odniesienia
Wed
25
Jul 2007
Jakie współrzędne ma punkt? To oczywiście zależy od układu odniesienia. W grafice 3D stosujemy różne układy współrzędnych - współrzędne globalne świata, współrzędne lokalne modelu, kamery, Image Space, Bone Space, Interial Space i jeszcze inne.
Wielu ludzi stara się zrobić coś w ich mniemaniu wielkiego, coś co inni docenią, za co będą podziwiani, co po nich zostanie. Wtedy przychodzi ktoś drugi, kto robi to samo szybciej, lepiej, albo ktoś kto stwierdza, że to wszystko jest głupie i bez sensu. I wg swoich kryteriów ma rację.
Wszystko jest względne. Tym lepiej się żyje, im szybciej człowiek to zauważy i się z tym pogodzi. Gdziekolwiek w przestrzeni jesteś, zawsze ktoś może znaleźć układ odniesienia, w którym twoja pozycja wynosi zero.
