typedef

Я не зря написал «open source» с маленькой буквы, потому что сегодня в фокусе моего внимания не одноименное сообщество, а сама тенденция роста количества софта, который раздают бесплатно и/или с открытыми исходниками. Скажу даже больше: я против не только открытого софта, а вообще бесплатного.

Истоки такого альтруизма программистов можно обнаружить в культуре хакеров, начавшейся аж в 60-х годах. Об этом можно почитать в замечательной книге Стивена Леви «Хакеры». В то время свободное ПО было практически единственным вариантом: рынка софта как такового не было — был рынок железа. Общей аппаратной архитектуры не было, цены были фантастически высокими, и компьютеры являлись штучным товаром, к которому софт поставлялся в виде бесплатного дополнения.

Казалось бы, раз программы кто-то пишет, то он должен получать за это соответствующее вознаграждение. Но откуда взять вознаграждение, если софт раздается бесплатно? Выходит, программисты не создают добавочной стоимости? Однако в то время такая модель распространения была естественной и протестов не вызывала по двум причинам:

1. Программисты таки создавали добавочную стоимость, но эта стоимость относилась к железу, так как компьютеры продавались вместе с набором программ. Чем лучше программы для компьютера, тем дороже его можно продать. Ну, а поскольку стандартной архитектуры не было, то открытие исходников не имело негативных последствий: все, кто мог ими воспользоваться, сначала должны были купить компьютер, с которым этот софт и так шел в комплекте.
2. В то время каждый пользователь был программистом, поэтому открытый софт был просто частью натурального обмена. Сегодня я отдал свою программу Васе, а завтра он отдаст мне свою.

Но жизнь-то — штука изменчивая, и вот, подвинув бородатых хакеров, за терминалы уселись банковские служащие и бухгалтеры. Потом все нарастающая стандартизация аппаратуры, платформенная независимость языков программирования, и вдруг — хоп! Программисты остались в меньшинстве, железо стало дешевым, а одну и ту же программу можно, хвала Юниксам, если не запустить, то уж собрать почти на любой платформе. Собственно, исчезли основные предпосылки существования опенсорса, имевшие место в 60-е и 70-е.

Но что же такое происходит? Open source мало того что не загнулся, так еще и продолжил развиваться. Сегодня уже непросто найти такую коммерческую программу, для которой бы не было аналогов с открытыми исходниками. Какие же причины побуждают программистов в наше время этим заниматься?

1. Интерес. Людям просто нравится творить. Но так как большинство программистов — не бизнесмены, и не способны продать свои творения, они их просто раздают. Впрочем, есть и идейные, которые раздают из принципиальных соображений.
2. Известность. Open source очень демократичен. Напиши хорошую программу, которой будут пользоваться миллионы, — и интерес к тебе со стороны работодателей сразу повысится. Собственные разработки с открытыми исходниками служат отличной заменой традиционным резюме: просмотрев исходники программы и историю ее разработки, можно гораздо больше узнать о разработчике, чем в ходе получасового собеседования.
3. Работодатель за это платит.

Если с первыми двумя пунктами все понятно, то третий не очень прозрачен. Приведенный ранее механизм с повышением стоимости железа за счет софта уже не работает. Тогда откуда же прибыль, чтобы платить программистам? Есть несколько вариантов:

1. Код с открытыми исходниками не является самодостаточной программой, а представляет собой некую библиотеку или фреймворк, являющиеся побочным продуктом при разработке чего-то большего. Исходники открываются, как правило, из рекламных соображений. Прибыль косвенная.
2. Компания активно использует свой же продукт с открытыми исходниками в своих разработках. Очевидно, что основная прибыль получается другими путями, а открытие исходников — просто жест доброй воли или, опять-таки, реклама. Прибыль снова косвенная.
3. Мифическая «техподдержка», о которой будет твердить не слишком подкованный апологет open source, объясняя, откуда у опенсорсников деньги берутся. Этот путь получения дохода имеет смысл разве что для крупных компаний вроде Rad Hat или Microsoft, которые могут поставлять настолько большие и сложные продукты, что для них может потребоваться обучение специалистов и поддержка (платные, разумеется).
4. Open source, вообще говоря, ничуть не противоречит коммерческому софту. Поэтому можно путем хитрого лицензирования требовать с клиентов денег, если продукт с открытыми исходниками используется в коммерческих разработках (вспомним Qt как хрестоматийный пример).
5. Научные гранты.
6. Всякие маргинальные способы вроде пожертвований или встраивания рекламы в пользовательский интерфейс (фуу).

То есть, прибыль получить можно, если хорошо постараться. А открытие исходников дает, во-первых, армию бесплатных энтузиастов-тестеров, а во-вторых, на пустом месте возникает лишнее конкурентное преимущество: при прочих равных условиях софт с открытыми исходниками (не говоря уж о бесплатном) предпочтительнее, просто потому что. Наверняка 99% пользователей в исходники не полезут, зато их будет греть мысль, что такая возможность у них есть.

Программистов, которые могут себе позволить и хотят заниматься разработкой открытого софта, подавляющее меньшинство. Качественный открытый софт убивает конкуренцию (и, в некотором смысле, прогресс) среди закрытого коммерческого софта. То есть, если разработана некоторая открытая программа, то вероятность появления успешной аналогичной (или даже чуть более функциональной) закрытой коммерческой программы исчезающе мала (пример — браузеры). Да и открытой, в общем-то, тоже. Выходит, что open source замедляет прогресс!

Я считаю, что этично будет продолжать развитие открытого софта (и открытой информации) в среде разработчиков и ученых, так как там это будет проявлением натурального обмена — там отношения не производитель-потребитель, а скорее производитель-производитель. Вот смотрите:

1. Я написал научную статью и выложил ее в открытый доступ. Это ускоряет развитие науки, так как другие ученые могут опираться на мои результаты.
2. Я написал библиотеку нечеткой логики и открыл ее исходники. Это ускоряет прогресс программирования, так как остальные разработчики могут сэкономить свое время, если им понадобятся такие функции. Если им нужно внести какие-то изменения, они берут и вносят. Здесь важно, чтобы лицензия открытого кода позволяла любое его использование, в том числе коммерческое.
3. Я написал редактор UML-диаграмм и раздаю его бесплатно. Это помогает другим разработчикам в их работе. Конечно, это убивает конкуренцию среди платных редакторов UML, но в целом служит прогрессу программирования.
4. У меня бессонница, поэтому я год ночами писал программу управления личными финансами, а так как мне лень заниматься продажами, то я раздаю эту программу бесплатно. Если программа удобная, то платные уже покупать никто не будет, даже если они немножко лучше. Конкуренцию теперь может составить только более функциональная бесплатная программа.

Итак, моя позиция по поводу всего вышеобозначенного:

• информация должна быть открытой;
• средства разработки и научные инструменты должны быть бесплатны и, возможно, открыты;
• остальные программы не должны быть бесплатными (но могут быть открытыми);
• тем не менее, если уже есть хороший открытый/бесплатный софт, то глупо было бы им не пользоваться.

(1 голосов, средний: 5.00 из 5)

 Loading ...

Версия 0.01 вышла 17 сентября 1991 года. Сегодня совершеннолетие!

Всем срочно sudo drink !

9 ноября 1983 года Том Дафф изобрел «устройство» имени себя. Вот так оно выглядело:

send(to, from, count)
	register short *to, *from;
	register count;
	{
		register n=(count+7)/8;
		switch(count%8){
		case 0:	do{	*to = *from++;
		case 7:		*to = *from++;
		case 6:		*to = *from++;
		case 5:		*to = *from++;
		case 4:		*to = *from++;
		case 3:		*to = *from++;
		case 2:		*to = *from++;
		case 1:		*to = *from++;
			}while(--n>0);
		}
	}

Такая конструкция предназначалась для раскрутки цикла копирования фрагмента памяти в регистр пословно. Развертывание сокращает количество итераций цикла и, как следствие, количество операций сравнения (в данном случае в 8 раз), тем самым слегка повышая производительность.

Чтобы лучше понять, что происходит, предлагаю читателям запустить следующую программу (я немного изменил изначальный вариант):

#include 
 
int c = 0;
int a = 10;
 
void foo()
{
    printf("%d ", c++);
}
 
void bar()
{
    printf("%d\n", a);
}
 
int main()
{
    switch (a&3) {
    case 0: do { foo(); bar();
    case 3:      foo(); bar();
    case 2:      foo(); bar();
    case 1:      foo(); bar();
	       } while((a -= 4) >= 0);
    }
    return 0;
}

Самое удивительное в этом всем — вовсе не корявое «столбчатое» форматирование. Удивительно то, что язык позволяет размещать цикл внутри блока switch. Интуитивно нам кажется, что каждый case начинает новый блок, и что нельзя соорудить блок, заключающий в себя несколько case’ов. А приведенный выше пример вообще представляется надругательством над синтаксисом C и здравым смыслом. Но стоит задуматься о том, как именно реализована конструкция switch-case, как сразу все становится на свои места:

// исходный код
switch (a) {
    case 0:
        a++;
        break;
    case 1:
        a--;
}
 
// что происходит на самом деле (примерно)
case_0:
    if (a == 1) goto case_1;
    a++;
    goto end;
case_1:
    a--;
end:

Вот так! Теперь понятно, что внутри конструкции switch можно развернуться от души, чем и не преминул воспользоваться Дафф.

Вынужден разочаровать любителей микрооптимизаций: подобное развертывание циклов выполняется современными компиляторами автоматически, и, скорее всего, намного эффективнее. Компилятор ведь может себе позволить не заботиться о чистоте кода. Так что устройство Даффа теперь интересно разве что любителям истории программирования (вроде меня).

Жаждущих подробностей отправляю к оригинальному сообщению Даффа и статье в Википедии.

(Еще не оценили)

 Loading ...

Хотя у меня пока, учитывая возраст блога, есть некоторое ощущение «разговора с пустотой», все же я не могу не поздравить всех немногочисленных моих посетителей с 0×100-ым днем в году. Это тот самый день когда нужно или не работать совсем, или сворачивать горы. У меня получилось второе: напланировал кучу дел, приехал на работу и через полтора часа уже все сделал. Остается только пожелать всем побольше таких ошибок в планировании. Или это все же сакральное влияние даты?

О серьезных вещах сегодня писать — кощунство, поэтому буду писать о полусерьезных.

В далекие-далекие годы, когда еще только-только стали появляться компьютеры на полупроводниках, а в лесах можно было встретить динозавров, появился UNIX. Дорог он нам не только фактом своего существования, но главным образом сложившейся вокруг него культурой. Ну, знаете, там были такие волосатые очкарики, которые все свое время просиживали за терминалом (при наличии такового),  пили колу и разговаривали друг с другом на языке инопланетян. Эти ненормальные идентифицировали себя «хакерами», все время писали какой-то код и ни во что не ставили интеллектуальную собственность.  Кстати, все ли знают, что UNIX изначально создавался Томпсоном как средство запуска игры Space Travel на компьютере PDP-7?

Но нужно отдать должное этим нечесаным парням: в их развлечениях родилось много полезных штук, и, в частности, язык Си. Создали его изначально не для развлечений (хотя кто-то пытается это опровергать), а для тотального переписывания Юникса. Но хакеров ведь хлебом не корми — дай любую попавшую в руки сущность разобрать, понять как работает, перекроить и раздать друзьям. Поэтому, учитывая специфику C, нетрудно было догадаться, что мерилом профессионализма, наряду с длиной волос и диоптриями близорукости, станет способность написать самую необычную, изящную, умопомрачительную и непонятную простым смертным программу. Например, такую:

typedef struct n{int a:3,
b:29;struct n*c;}t;t*
f();r(){}m(u)t*u;{t*w,*z;
z=u->c,q(z),u->b=z->b*10,
w=u->c=f(),w->a=1,w->c=z->
c;}t*k;g(u)t*u;{t*z,*v,*p,
*x;z=u->c,q(z),u->b=z->b,v
=z->c,z->a=2,x=z->c=f(),x
->a=3,x->b=2,p=x->c=f(),p
->c=f(),p->c->a=1,p->c->c=
v;}int i;h(u)t*u;{t*z,*v,*
w;int c,e;z=u->c,v=z->c,q(
v),c=u->b,e=v->b,u->b=z->b
,z->a=3,z->b=c+1,e+9>=c&&(
q(z),e=z->b,u->b+=e/c,w=f(
),w->b=e%c,w->c=z->c,u->c=
w);}int(*y[4])()={r,m,g,h};
char *sbrk();main(){t*e,*p,*o;
o=f(),o->c=o,o->b=1,e=f(),
e->a=2,p=e->c=f(),p->b=2,
p->c=o,q(e),e=e->c,(void)write
(1,"2.",2);for(;;e=e->c){q(e),
e->b=write(1,&e->b["0123456789"],
1);}}t*f(){return i||(i=1000,
k=(t*)sbrk(i*sizeof(t))),k+--i;
}q(p)t*p;{(*y[p->a])(p);}

Эта программа, например, вычисляет и выводит на stdout значение числа e с неограниченной точностью (точнее, ограниченной размером стека или терпением пользователя). Понятно, что нанимателям таких программистов очень не нравился подобный стиль. История умалчивает, сколько хакеров было уволено, пока, наконец, в 1984 году не был организован IOCCC, или, по-нашенски, Международный Конкурс На Самую Запутанную Программу На C. Это было настоящей отдушиной для недосамовыраженных профессионалов, и работодатели снова могли спать спокойно.

Среди победителей IOCCC оказалось немало известных в компьютерном мире людей. Например, Дэвид Корн (создатель оболочки ksh) в 1987 году стал одним из победителей с такой программой:

main() { printf(&unix["\021%six\012\0"],(unix)["have"]+"fun"-0x60);}

Основная интрига в том, что должно появиться на экране. Ничего сложно здесь нет, если помнить о том, что следующие две строки с точки зрения C идентичны:

a = b[1];
a = 1[b];

Плюс еще нужно знать, что unix — предопределенный символ, эквивалентный 1, если использовать gcc. В этом можно убедиться с помощью следующей команды:

$ touch foo.h; cpp -dM foo.h
...
#define unix 1
...

Если сложить два и два, получится, что программа выводит строку «unix».

Одна из моих любимых программ-чемпионов, написанная Марком Биггаром, выглядит так:

P;

Вот оно, настоящее Дао! Эта программа, в отличие от всех остальных победителей, умеет делать все. Ее нужно просто правильно скомпилировать. Например, можно заставить ее вывести «Hello, world»:

$ cc -DP="main() { printf(\"Hello, world\\n\"); }" -o beggar beggar.c
$ ./beggar
Hello, world

Нетрудно придумать, как научить программу делать и любые другие действия.

Кстати, на этом же соревновании засветился и Ларри Уолл, написавший некую линвистическую чуду-юду. Теперь понятно, откуда у Perl ноги растут. Оказывается, Уолл просто сделал язык, на котором непонятные программы писать гораздо проще, чем на C.

Пожалуй, на этом праздничный пост пора завершать. На досуге можете посмотреть исходники других победителей IOCCC, гарантированно получите массу удовольствия.

(2 голосов, средний: 5.00 из 5)
 Loading ...