Obviously you shouldn’t do this, it won’t work out… Believe me. Ok, ok, try it yourself. You’ve been warned.
Posts Tagged ‘coding’
Who says code cannot give good advice?
Monday, October 11th, 2010Battlelancer.com Design Refresh 2010
Sunday, January 17th, 2010Why Mono Doesn’t Suck or Grow Up, Please!
Sunday, June 28th, 2009I stumbled over this post on Slashdot today: Why Mono Doesn’t Suck. I definetely recommend anyone reading this one. Below is a short excerpt I believe is most important, it reminds us to grow up in terms of developing software.
Some people are “for” things. They are for Freedom, or for technical superiority, or for a sports team, or whatever. Some people are “against” things. They are against political candidates, or Microsoft, or people from certain places, or whatever. Some people define themselves on the basis of what they want, others on the basis of what they do not want. Mono causes immense anger amongst that second group – specifically, people who use GNU/Linux not because they are “for” anything, but because they are “against” Microsoft. This can be easily seen – using names like “Microshaft” or “Micro$oft” or similar childish attempts to define a “them and us” situation and ridicule the “them”. Mono is symbolic – it is Free (something they are supposedly in favour of), but Free on the basis of something sourced from the Great Satan – an inexcusable mix.
Many of those who advertise themselves as anti-Mono are, quite frankly, frightening. Calling for the deaths of Microsoft employees (see comments on Boycott Novell), or trying to have people who make positive comments about Mono fired (see recent comments on Ubuntu mailing lists), or making insinuations about anyone who does not agree with them (see pretty much every news post on Boycott Novell itself) – this is ugly behaviour, the absolute worst kind of advert for the “Free Software community” imaginable. If people want to be “against” Mono, then there are sane ways to do it – for example, by working on or packaging alternative software. Calling for people to be expelled from Free Software communities because they don’t work on apps you like is, in short, the antithesis of supporting Freedom. If the anti-Mono crowd want to be taken seriously, then they need to UNDERSTAND what they fight against – they need to have sufficiently intimate knowledge of what Mono is, how it works, and why, in order to know where to direct their energies (and general shouts of “ZOMG! MICRO$HAFT!” isn’t well-directed). I would LOVE to see some high-quality apps for GNOME written in, say, Java or Python – as the competition would only result in better applications. Read all at apebox.org
Furthermore I read about an example that developing software the grown-up style really works. It’s the people over at NASA who develop the shuttle software (and hell lot more) with a kind of precision someone in a regular enterprise can only dream of. You really get it that documentation really matters in all stages which comes to its heights in their all-ever-developed-code error and mistake database.
So for the good of it: let’s grow up ladies an gentleman!
Axum – experimental, parallel, managed
Tuesday, May 12th, 2009It was only a matter of time that Microsoft would push out another experimental developing language which maybe be part of a future product. Obviously (but I did not really see different announcements) Axum is a multi-core, better said, parallel computing optimized language.
As far as I read their documentation (I only read the first few pages, promised to read more later) their concept goes away from object-oriented to some agent-based style. The idea is you having to define agents which can be server and/or client, receiving, sending and acting upon. These agents communicate through so called channels making their interaction message-based: a source agent sends a request, getting a response from the target agent. As they say “Axum defines agents and their interactions”. The following is a “Hello-World” program in Axum:
using System;
agent Program : Microsoft.Axum.ConsoleApplication
{
override int Run(String[] args)
{
Console.WriteLine("Hello, World!");
}
}This is nothing spectacular as no communication is involved. Let’s look at another example they showed off, a Fibonacci program:
using System;
using Microsoft.Axum;
using System.Concurrency.Messaging;
agent MainAgent : channel Microsoft.Axum.Application
{
function int Fibonacci(int n)
{
if( n<=1 ) return n;
return Fibonacci(n-1) + Fibonacci(n-2);
}
int numCount = 10;
void ProcessResult(int n)
{
Console.WriteLine(n);
if( --numCount == 0 )
PrimaryChannel::ExitCode <-- 0;
}
public MainAgent()
{
var numbers = new OrderedInteractionPoint();
// Create pipeline:
numbers ==> Fibonacci ==> ProcessResult;
// Send messages to numbers:
for( int i=0; i<-- 42-i;
}
}The pipeline above establishes a very basic dataflow, saying where to move the resulting data. The key is the function method: it does not interact with any outside operations, so Axum automatically spawns as many threads “it deems necessary for the most efficient execution of the program.” This allows for good scalability through many-core systems.
I barely scratched the surface and this language is still preview, so give it a spin, tell me important stuff I missed out, whatever. Have fun!
By the way, on their team blog are some reactions to some user’s first impressions and explanation of some design choices and more from DevLabs is here (including Popfly – a web meshup tool and CHESS – a Heisenbugs tracking tool).




