Tag: philosophy

Entries for tag "philosophy", ordered from most recent. Entry count: 32.

Warning! Some information on this page is older than 5 years now. I keep it for reference, but it probably doesn't reflect my current knowledge and beliefs.

Pages: 1 2 3 4 >

16:10
Sat
21
May 2016

What software engineering has to do with history, politics or law?

When at school, I always prefered scientific classes (like mathematics) over humanities. Among my most hated classes were: history, geography and language/literature. That's why I chose to become a programmer. But despite computer science is a scientific discipline, I can see that on a higher level, software engineering involves some humanities like, for example, history, politics or law.

History, because in software - just like in real life - you need to know what happened in the past to be able to understand the state of things we have right now. For example, in the field of graphics API-s, someone asked a question on Programmers Stack Exchange: Why do game developers prefer Windows? The best answer is the one that extensively explains how two main API-s - DirectX and OpenGL - evolved over years.

Politics, because top-level decisions are not always made based on purely technical arguments. Going back to graphics API-s, Microsoft decided to push its next-generation low-level Direct3D 12 into Windows 10 only, while Khronos Group defined Vulkan as an open, multiplatform standard. Google was rumored to design its own graphics API, was even asked by John Carmack not to do so, and it finally returned to the negotiation table with Khronos, so Android N will support Vulkan as well. Apple chose different path and did design its own graphics API - Metal. Similarly, in the GPGPU field, OpenCL is a widely supported standard, but NVIDIA succeeded in promoting its own, vendor-specific API: CUDA. HSA is yet another such initiative, led by a foundation. Among its members are: AMD, ARM, Imagination, Qualcomm, Samsung and many others, but the list lacks some big players, like Intel or NVIDIA. So developing software technology is a little bit like doing politics - "Am I strong enough to go against the others or do I need to seek allies?"

And finally, the law. Specifications of programming languages and API-s are somewhat like acts passed by the government. They are written in natual language, but should be as unambiguous as possible, precisely defining each term, specifying what is allowed and what is not. Doing something against the specification is like breaking the law - it may go unnoticed, it may even give you an advantage (like programmers notoriously relying on signed integer overlow in C++, despite formally it's an undefined behavior), but you may also "get caught" (and get a compilation error or invalid results from your program). On the other hand, a compiler or API implementor not complying to the specification is more serious problem - it's like a state official breaking the law against you. You may just accept your fate and go away (equivalent of not using broken feature and looking for some workaround) or you may report it (so the bug will be fixed in new compiler/driver/library version).

So although software engineering is a scientific/technical discipline, I think that on a higher level it can be compared to some degree to humanities like history, politics or law.

Comments (0) | Tags: philosophy | Author: Adam Sawicki | Share

18:59
Wed
11
Nov 2015

The Virtual Reality of Code

In my opinion, coding is a virtual reality with its own set of rules unlike in the physical world. In physical world, each thing has its specific location at the moment, things don't appear or disappear instantly, we have laws of energy and mass conservation. Inside a computer, we have data in memory (which is actually linear - 1D) and processors, processes and threads executing instructions of a program over time.

I have been trying for years to imagine some nice way editing or at least visualizing code, which would be more convenient (and look more attractive) than the text representation we all use. I am unsuccessful, because even if we render some nice looking depiction of a function code, its instructions, conditions and loops, drawing all the connections with variables and functions that this code uses would clutter the image too much. It's just like this virtual world doesn't fit into a 2D or 3D world.



Movie depiction of computer programs is often visually attractive, but far from being practical. This one comes from "Hackers" movie.

Of course there are ways of explaining a computer program on a diagram, e.g. entity diagrams or UML notation. I think that electrical diagrams are something in between. Electrical devices end up as physical things, but on a diagram, the shape, size and position of specific elements doesn't match how they will be arranged on a PCB. Logical representation and electrical connections between them is the only thing that matters.

Today it occured to me that this virtual reality of code also has "dimensions", in its own sense. It's evident when learning programming.

1. First, one has to understand control flow - that the processor executes subsequent instructions of the program over time and that there can be jumps caused by conditions, loops, function calls and returns. It's called dynamic aspect of the code. It can be depicted e.g. by UML sequence diagram or activity diagram.

I still remember my colleague at university who couldn't understand this. What's obvious to every programmer, was a great mystery to him as first year's computer science student. He thought that when there is a function above main(), instructions of that function are executed first and then instructions of the main function. He just couldn't imagine the concept of calling one function from the other and returning from it.

2. Then, there is so called static aspect - data structures and objects that are in memory at given moment in time. This involves understanding that objects can be created in one place and destroyed in another place and at later time, that there may be a collection of multiple objects (arrays, lists, trees, graphs and other data structures), objects may be connected to one another (the concept of pointers or references). Various relationships are possible, like one-to-one and one-to-many. In object-oriented methodologies, there is another layer of depth here, as there are classes and interfaces (with inheritance, composition etc.) and there are actual objects in memory that are instances of these classes. It can be depicted for example by entity diagram or UML class diagram.

3. Finally, one has to learn about version control systems that store history of the code. This adds another dimension to all the above, as over successive commits, developers make changes to the code - its structure and the way it works, including format of data structures it uses. Branches and merges add even more complexity to it. GUI apps for version control systems offer some way of visualizing this, whether it's showing a timeline with commits ("History") or showing who and when commited each line of a file ("Blame").

There is even more to it. Source is organized into files and directories, which may be more or less related to the structure of contained code. Multithreading (and coprocessing e.g. with GPU, SIMD, and all kinds of parallel programming) complicates imagining (and especially debugging!) control flow of the program. Program binaries and data may be distributed into multiple programs and machines that have to communicate.

It fascinates me how software is so multidimensional in its own way, while so flat at the same time (after all, computer memory is linear). I believe that becoming a programmer is all about learning how to imagine, navigate and create stuff in this virtual reality.

Comments (3) | Tags: philosophy software engineering | Author: Adam Sawicki | Share

21:25
Sun
02
Nov 2014

Agile Methods and Real Life

I've received an e-mail recently from a student asking me about what career path to choose. I generally don't feel good as an authority, but when trying to write some reasonable answer, I recalled this diagram - "The Project Paradox":

It basically says that when planning everything in advance, we have to make the most important decisions at the beginning, when we actually know the least about the project. In software development, we may know the final goal, but we usually don't know how exactly the implementation will look like and what problems will we encounter during the project (unless w already done something similar in the past). That's why agile software development methods were invented.

I think something similar happens in real life. What is more, we don't make the most important decisions like about job and marriage only by ourselves (it also depends on the decisions of others) and we don't do it by only rationally weighting pros and cons - we also follow our hearts. So instead of thinking all the time about the big, lifetime goals, it's better (it feels better and is more efficient) to just focus on the next step to do. That's also what GTD (Getting Things Done) method advices.

So in this case, I'd recommend not to consider theoretically what career path is better, more interesting, more profitable etc., but just try to do different things (like learn a bit and code some simple game, mobile app, web page, setup Linux server or whatever) and see how it feels for you to do these things.

Comments (8) | Tags: philosophy | Author: Adam Sawicki | Share

11:34
Sat
08
Sep 2012

Are Comments Unnecessary?

I generally believe that in programming there is often only one right way of thinking and who doesn't agree with it is just not experienced enough to understand it. That's why I avoid expressing my personal and more "philosophical" opinions about programming. But maybe I should? Tell me what you think in comments.

I was inspired to write this post by the list of 20 controversial programming opinions. It looks like a gist from discussion of many professionals. I like it a lot and agree with all of the points, except one.

In point 4 they claim that comments are a form of code duplication and should be avoided in favor of more readable code. I don't think that's true. In the perfect world all code comments would be unnecesary because programming language would be so clean and expressive that we could express our intentions directly in the code. But in reality there is always lots of bookkeeping / boilerplate code that we have to interlace with real logic to make any program work. Managed languages (like C#, Java) and scripting languages (like JavaScript, Python) do better job in reducing it than C and C++, but in exchange for performance.

Look at this very simple example. HLSL language has function reflect that calculates a reflected vector. If it didn't, we could easily code it in HLSL using vector arithmetic, like this:

float3 reflect(float3 i, float3 n) {
    return i - 2 * dot(i, n) * n;
}

Now what if we want to code same function in C or C++ and we use XNA Math as the math library? It would look like this:

XMVECTOR reflect(FXMVECTOR i, FXMVECTOR n) {
    return XMVectorSubtract(i, XMVectorScale(n, 2.f * XMVectorGetX(XMVector3Dot(i, n))));
}

Much better than if we coded it using D3DX math functions, but still not very readable. Don't you think that the formula for this calculation, expressed directly in some comment above this function, would help to understand it?

// i - 2 * dot(i, n) * n

Please also recall how algorithms look like when described in this Pascal-like pseudocode in computer science books. Now think about an algorithm for manipulating some complex data structure that you seen or written in the real code. Was it similar? I bet it was several times longer because of all this memory allocation and other stuff that had to be done to make it a working code.

Of course I agree comments that repeat what can already be seen in code are stupid.

// Creates thread.
void CreateThread();
// Number of threads.
UINT threadCount;

Even worse when comments replace good identifier names.

// Creates thread.
void Go();
// Number of threads.
UINT i;

But code doesn't tell everything. It doesn't tell whether particular pointer can or cannot be null, a time value is in seconds or milliseconds, a number has to be power of two etc. I like comments before functions and classes, especially in header files, as a form of documentation - no matter if in Doxygen format or not.

/*
i - Incident 3D vector, pointing towards the surface.
n - Normal 3D vector, perpendicular to the surface. Should be normalized.
Returned 3D vector points from the surface.
*/
XMVECTOR reflect(FXMVECTOR i, FXMVECTOR n);

I think encapsulation is everything. Even in real life, you press buttons on any device and use it without need to know all the electrical and mechanical details about what happens inside the box. In programming we want to use libraries, classes and functions just by using its public interface, without studying the underlying implementation. Hey, if we had to always deal with all the details down to the lowest level, we would never be able to build any complex system! Similarly, I'd like to see the mathematical formula or algorithm pseudocode without studying all the boilerplate that's in the real code. That's what documentation is for, that's what comments are for. And that's why I hate this saying "Want documentation? Just look at the code!"

Comments (1) | Tags: philosophy | Author: Adam Sawicki | Share

22:01
Wed
25
Jan 2012

Why do I Publish Source Code?

I like Open Source. Not in the way that some like Linux and hate Windows, but I just believe that to read or use a piece of code is often more helpful than to read only an abstract description of some algorithm. That's why I publish source of my personal projects. I can see many passionate programmers - like these from Warsztat - are not so enthusiastic to disclosing their sources. I was wondering why and here I'd like to share my thoughts on this subject, in hope I convince some of you to make your personal projects Open Source :)

First, I can hear an argument sometimes telling that you are ashamed of showing your code because you think it is bad. My answer to this can only be: you are probably wrong. Do you really believe that the "professional", "commercial" code inside companies - which is usually evolving for years, maintained by many people, modified to reflect constantly chaging requirements and written in a rush - is better than yours? Not necessarily. Or maybe you think that your code would be better if you put lots of additional comments in it, code in more object-oriented fashion or use more design patterns? Again, I don't think so.

You may also be afraid that someone looks at your code and tells that you are a beginner? Well, you may be right but... what's wrong with that? You code shows the level of your skill in programming and you shouldn't avoid showing who you really are. Remember that on the Internet there is always more beginner programmers who can learn from you than the advanced ones that could potentially make fun of your code. If you are afraid of headhunters searching the Internet, please keep in mind that when applying for a job, you may be asked to send samples of your code anyway - just as I was.

Second argument I can hear is: "But it's just my project, I don't want to make it Free Software developed by the community like Linux". That's a stereotype. Opening your sources doesn't mean the project cannot be developed by only you and will automatically be modified by some others programmers. Such thinking is just like when I hear somebody telling that programming in C++ means you extensively use OOP, while never use global variables, macros or printf. I've never received an email with a patch or other proposal for particular change in my code or collaboration in developing of my project. Even for my projects that are GNU GPL, I only get suggestions that I should add or modify some features.

If so, is it worth publishing source code anyway? My practice clearly answers yes, but not to start a community open source project. I sometimes receive emails asking about a piece of code for an algorithm I've decribed on my webpage, but I didn't provide code for. Programmers from around the world are constantly challenged with tasks they haven't done before, whether at work or at university. Their problems can be similar to yours. They Google for solutions. Your small niche place in the Web or a post on the forum can be of great help for such people.

Comments (0) | Tags: philosophy | Author: Adam Sawicki | Share

22:45
Mon
26
Jul 2010

A Random Thought on Over-Generalizing

I don't post next part of the description of my reflection system yet. Instead I just want to share a small thought that came to my mind today. It's about over-generalizing, over-engineering, writing overly-abstract code or however you call it. Using too much OOP is not only the matter of code perfomance, but something deeper, more ideological. Interesting blog entries about this topic are: 5 Stages of Programmer Incompetence (see "The Abstraction Freak" paragraph) and Criminal Overengineering @ yield thought, Smartness overload and Smartness overload - addendum @ mischief.mayhem.soap. A Counterpoint can be found at cbloom rants. And finally here is my idea:

It is a vicious circle. Here is how it works:

But I believe this is true only to some degree. We obviously need a general, universal code sometimes not to do the same, monotonous or error-prone work over and over again. That's why we create and use libraries. And that's why I've coded my reflection system :)

New: I can see similar vicious cycle in a programming language development, inspired by an article I've read today: Google engineer calls Java and C++ too complicated. For me it looks like this: software engineers, companies and committees develop very sophisticated programming languages because they want them to be as much general and universal as possible so developers don't have to learn and use many specialized languages for different purposes. Developers don't like to learn many new programming languages because they have bad experience from learning and using such universal, spohisticated languages.

Comments (0) | Tags: software engineering philosophy | Author: Adam Sawicki | Share

19:45
Fri
18
Jun 2010

Programmer Incompetence?

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 (0) | Tags: software engineering philosophy | Author: Adam Sawicki | Share

19:58
Sun
16
May 2010

Some Thoughts about Library Design

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 (1) | Tags: philosophy software engineering libraries | Author: Adam Sawicki | Share

Pages: 1 2 3 4 >

STAT NO AD [Stat] [Admin] [STAT NO AD] [pub] [Mirror] Copyright © 2004-2017 Adam Sawicki
Copyright © 2004-2017 Adam Sawicki