Автор оригіналу: Пол Грем (Paul Graham)
Оригінал: Defining Property

Photo by Invisible Lens Photography/Flickr

В дитинстві я читав книжку з історіями про відомого японського суддю XVIII сторіччя, якого звали Оока Тадаске (Ooka Tadasuke). Одна зі справ, яку він судив була порушена власником ресторану. Бідний студент, що міг дозволити собі лише рис, їв його насолоджуючись запахом інших смачностей, які доносились із ресторану. І власник хотів заставити студента заплатити за запахи, які він із задоволенням нюхав. Студент же крав запах їжі!

Я часто згадую цю історію, коли чую як RIAA та MPAA звинувачують людей у крадіжці музики чи кінострічок.

Трактувати запахи як чиюсь власність звучить для нас просто смішно. Але я можу придумати ситуацію, коли можна було б брати гроші і за запах. Просто уявіть, якби ми жили на місячній базі і купували повітря по літрам. Тоді можна з легкістю уявити і підмішування запаху до цього повітря в якості небезкоштовного бонусу.

Причина, того, що право власності на запах виглядає для нас повною маячнею в тому, що на Землі на це ніхто б не повівся. Але ж цілком можливо це спрацювало б на місячній базі.

Те що вважається власністю залежить від того, що можна взагалі сприймати за власність. І останнє може не лише змінюватись з часом, а вже змінилось. Люди завжди (для деяких визначень слів “люди” та “завжди”) сприймали за власність те, що вони носили з собою. Але прадавні люди, що займались збиральництвом, наприклад, ніколи не сприймали землю як власність в тому сенсі як ми зараз. [1]

Причина того, що так багато людей і досі думають, що у власності є лише одне незмінне визначення полягає в тому, що це визначення змінюється дуже повільно. [2] Але воно зараз якраз перебуває в стані трансформації. Рекордингові лейбли та кінематографічні студії звикли продавати своє добро ніби це повітря, що йде по трубах на місячній базі. Але з появою комп’ютерних мереж ми ніби переселилися на планету з атмосферою, якою можна дихати. Дані передаються зараз як запах. Але через прийняття бажаного за дійсне та короткострокової жадібності, лейбли та студії поставили себе на місце власника ресторану, звинуваючуючи користувачів в тому, що вони крадуть їх запахи.

(Причина через яку я кажу про короткострокову жадібність полягають в тому, що люди, які керують лейблами та студіями більше розраховують на бонуси, аніж на капітал. Якби вони працювали на капітал, то шукали б шляхи як використати технології замість того, аби протистояти їм. Та створювати нове – це дуже довго. Їхні бонуси залежать від цьогорічного прибутку, а найкаращий спосіб збільшити цей прибуток – це вичавити більше грошей з того, що вони вже мають.)

То що це значить? Невже люди не мають права брати гроші за свій контент? На це питання немає єдиної відповіді. Люди мусять мати змогу брати гроші за контент, коли це працює.

Під “працює” я маю на увазі щось більш суттєве, аніж “коли у них просто є така можливість”. Я маю на увазі, що люди можуть брати за нього гроші тоді, коли їм не треба заставляти суспільство робити це. Тобто компанії, що продають запахи на місячній базі можуть, звісно, продовжувати продавати їх на Землі, якщо вони успішно пролобіюють закони, які заставлять нас дихати через трубки і тут (навіть якщо нам це вже не потрібно).

Божевільні заходи по захисту прав, які зараз проводять лейбли та студії, дуже нагадують подібну ситуацію. Газетам та журналам теж непереливки, але вони принаймні занепадають з гідністю. RIAA та MPAA заставили б нас дихати через трубки, якби змогли.

Зрештою, все зводиться до здорового глузду. Коли ви зловживаєте правоохоронною системою, аби масово засудити випадкових людей в якості показовго покарання, чи лобіюєте закони, що спотворили б Інтерент, аби пройшли, то це по факту доказ того, що ви використовуєте визначення власності, яке вже не працює.

От тут дуже корисно мати працюючу демократію та багато незалежних країн. Якби у світі був єдиний авторитарний уряд, лейбли та студії купили б закони, які встановили те визначення власності, яке їм хочеться. Але на щастя є ще країни, які не є copyright-колоніями США і навіть в самих США політики все ще бояться електорату у великих кількостях. [3]

Людям, які керують у США може не подобатись, коли виборці чи інші країни відмовляються схилитись перед їхньою волею, але і ми зацікавлені в тому, аби люди, що намагають змінити закони заради власних інтересів, не мали чим нам дорікнути. Приватна власність – це дуже корисна ідея і, можливо, взагалі однин з найкращих винаходів людства. Досі кожне нове визначення приносило нам збільшення матеріального достатку [4]. Думаю, що не буде помилкою припустити, що і нове теж. Це було б трагедією, якби ми всі були змушені використовувати застарілу версію просто тому, що деякі впливові люди занадто ледачі аби оновити його.

Примітки

[1] Якщо вам цікаво дізнатись більше про збирачів, рекоменду. книжки Елізабет Машал Томас (Elizabeth Marshall Thomas): The Harmless People та The Old Way.

[2] Зміна визначення власності зазвичай спричиняється технологічним прогресом, щоправда оскільки технологічний прогрес прискорюється, цілком можливо, що і швидкість зміни визначення власності буде мінятися частіше. А це означає, що суспільству варто з граціозно пристосовуватися до цих змін, так як вони траплятимуться все частіше і частіше.

[3] Наскільки мені відомо термін “copyright-колонія” вперше використав Myles Peterson.

[4] Стан технології це не просто функція від визначення власності. Вони впливають одне на одне. І таким чином ви не можете з власної волі змінити визначення власності не зачепивши (зазвичай зашкодивши) розвиток технологій. Історія СРСР – яскравий тому приклад.

Нарешті в мене дійшли руки перекласти ще одну повчальну статтю Пола Грема про мови програмування, яку я вже згадував у минулому перекладі про “дух міста”. Зазвичай подібні “євангелістичні” речі я сприймаю вельми критично, оскільки я чудово знаю, що срібних куль не існує, але тим не менш думаю, що основна ідея вірна. Читаючи статтю зробіть поправку на те, що вона написана в 2003-му, тобто майже десятиріччя тому і з тих пір дещо змінилося, а Lisp вже не одна така мова-д’Артаньян

Велика подяка Тарасу за виправлення купи помилок

Автор оригіналу: Пол Грем (Paul Graham)
Оригінал: Beating the Averages

Photo by AlicePopkorn

Влітку 1995-го я та мій друг Роберт Морріс запустили стартап під назвою Viaweb. Нашою метою було написати програмне забезпечення, що дозволило б користувачам створювати власні онлайн-магазини. Інновацією на той час було те, що наш софт працював на нашому сервері, а інтерфейсом були звичайні веб-сторінки.

Я впевнений, що у багатьох людей виникла подібна ідея в той час, але наскільки я знаю, Viaweb був першим web-додатком. Це виглядало настільки ново для нас, що ми навіть компанію назвали аби підкреслити це: Viaweb, бо наше програмне забезпечення працювало “через Веб” (англ. “via Web”, – прим. пер.), а не на персональному комп’ютері.

Іншою назвичністю було те, що наш софт було написано здебільшого на мові програмування Lisp. Це був один із найперших великих додатків націлених на кінцевого користувача, написаних на Lisp, який до того часу був прерогативою університетів та дослідницьких лабораторій. [1]

Таємна зброя

Ерік Реймонд написав ессе під назвою “Як стати хакером” і в ньому, окрім усього іншого, він розповідає майбутнім хакерам про мови, які варто вивчати. Він пропонує розпочати з Python та Java, тому що їх просто вивчити. Серйозний хакер також захоче вивчити C, аби хакати Unix, та Perl для системного адміністрування й cgi-скриптів. І нарешті справжні хакери-аксакали мають подумати про Lisp:

Його варто вивчити хоча б заради просвітлення, яке ви отримаєте, коли нарешті осягнете його; цей досвід зробить вас кращим програмістом на решту вашого життя навіть якщо ви майже не будете його використовувати сам по собі.

Це той самий аргумент, який ви чуєте, коли говорять про вивчення латини. Вона не забезпечить вас роботою, якщо ви, звісно, не мітите у професори, але покращить ваш розумовий процес і допоможе краще опанувати інші потрібні вам мови, наприклад англійську.

Але хвилиночку. Ця метафора не поширюється так сильно. Причина того, що знання латини не забезпечить вас роботою тому що нею ніхто не розмовляє. Якщо ви писатимете латиною, ніхто вас не зрозуміє. Але Lisp – це мова програмування і комп’ютер розмовляє тією мовою, якою до нього спілкуєтсья програміст.

Тож якщо Lisp зробить з вас кращого розробника, як стверджує Ерік, то чому не використовувати його? Якщо художнику дати пензля, який дозволить йому стати кращим художником, то мені здається, що він почав би використовувати його у всіх своїх роботах, чи не так? Я не намагаюсь поглузувати з Еріка Реймонда. В цілому його порада – слушна. Те що він каже про Lisp – це загальноприйнятий міф. Але в цьому міфі є суперечність: Lisp зробить вас кращим розробником, але ви не будете його використовувати.

А чому ні? Зрештою, мови програмування – це всього на всього інструменти. І якщо Lisp справді вирощує кращих програмістів, використовуйте це. А якщо ні, то кому він здався?

І це не теоретичне запитання. Програмне забезпечення – дуже конкурентний бізнес, схильний до природних монополій. І компанія, яка писатиме софт краще і швидше при інших рівних умовах витіснить конкурентів з ринку. І коли ви запускаєте стартап – ви це відчуєте дуже швидко. Стартап – це пан або пропав. Ви або станете багатим, або не отримаєте нічого. Якщо в стартапі ви зробите ставку на не ту технологію, конкуренти розмажуть вас по стінці.

Роберт та я, обидва знали Lisp непогано і ми не бачили жодної причини не довіритись власним інстинктам і обрати його. Ми знали, що всі інші пишуть софт на C++ чи Perl. Але ми також знали, що це ще нічого не означає. Якби ви обирали технологію з цих міркувань, то писали б під Windows. Коли ви обираєте технологію краще ігноруйте те що роблять інші і думайте лише про те, що працюватиме найкраще.

Це особливо справедливо по відношенню до стартапів. У великих компаніях ви можете робити лише те, що роблять інші великі компанії. Але у стартапі ви не можете робити те, що роблять інші стартапи. І я не думаю, що багато людей це розуміють навіть у стартапах.

Середня велика компанія росте приблизно на 10% за рік. Тож якщо ви керуєте великою компанією і працюєте як середньостатистична велика компанія, то ви можете розраховувати, що ви і зростати будете як середньостатистична велика компанія: на 10% в рік.

Звісно ж, ситуація зі стартапами – аналогічна. Якщо ви робите все як середній стартап, ви очікуєте на середню продуктивність. Проблема в тому, що для стартапа середня продуктивність дорівнює провалу. Коефіцієнт виживання у стартапів набагато менший за 50%. Тож якщо ви започатковуєте стартап – краще робіть щось дуже дивне. Якщо ви цього не робите – чекайте проблем.

Тоді в 1995 ми знали те, чого не розуміли наші конкуренти, а деякі не розуміють і досі: коли ви пишете ПЗ, яке працює на ваших серверах, то ви можете самі обрати будь-яку мову, яку захочете. Коли ви пишете програми для ПК, то ваші вподобання будуть схилятися до того, що найближче до ОС під яку ви пишете. Десять років тому (відносно моменту написання статті, тобто 2003 р., – прим. пер.) під розробкою ПЗ малося на увазі написання програм на C. Але з web-додатками, особливо коли у вас є програмні коди як ОС, так і мови програмування, ви можете обрати будь-яку мову.

Ця нова свобода, щоправда, палка з двома кінцями. Коли ви можете обирати будь-яку мову, треба вже замислитись на вибором: яку? Компанії, які роблять вигляд, що нічого не змінилося ризикують одного разу помітити, що їх конкуренти так не думають.

Якщо обирати будь-яку мову, то яку? Ми обрали Lisp. З одного боку очевидним було, що швидка розробка дуже важлива на цьому ринку. Ми розпочинали з чистого листа, тож компанія, яка могла б запропонувати нові можливості раніше інших, отримувала перевагу. Ми знали, що Lisp – це гарний вибір для того, аби писати софт швидко, а серверні додатки збільшували цей ефект тим, що ви могли релізитись тої ж хвилини, коли код було написано.

Якщо інші компанії не хотіли його використовувати – нам же ліпше. Він зробив нас передовиками, але ми не відмовлялись від будь-яких поступок. Коли ми розпочинали Viaweb, ми нічого не тямили в бізнесі. Ми нічого не знали про маркетинг, чи найм працівників, чи залучення інвестицій, чи роботу з клієнтами. У жодного з нас навіть не було досвіду справжньої роботи. Єдина річ, яку ми робили добре – це написання софту. І ми сподівались, що це допоможе нам. Ми використовували будь-яку перевагу, яку могли собі забезпечити.

Можна сказати, що використання Lisp було експериментом. Нашим припущенням було те, що пишучи софт на Lisp ми могли б впроваджувати нові можливості швидше за наших конкурентів. А оскільки Lisp дуже високорівневий, нам не потрібна була б велика команда розробників, тому наші витрати мали бути значно меншими. Якщо це так, то ми могли б запропонувати кращий продукт за менші гроші і отримати прибуток. Ми б забрали всіх користувачів, а конкуренти не отримали б жодного і пішли б з ринку. Це те на що ми сподівались.

Які ж результати нашого експерименту? В певному сенсі дивовижно, але це спрацювало. Ми мали багато конкурентів, приблизно 20-30, але жоден з них не міг з нами тягатись. Ми мали WYSIWYG-майстерню створення онлайн магазинів, яка працювала через web, але виглядала як додаток для ПК.. У наших конкурентів були CGI скрипти. І могли завжди попереду них по функціональним можливостям. Інколи, у розпачі, конкуренти намагалися реалізувати щось, чого не було у нас. Але цикл розробки на Lisp був настільки швидким, що ми могли реалізувати їх аналог за день чи два після того, як конкуренти анонсували їх у прес-релізі. До того часу, коли журналісти що висвітлювали прес-реліз дзвонили нам, у нас вона вже теж була.

Для наших конкурентів це мабуть здавалося якоюсь таємною зброєю, що ми робили реверс-інжінірінг їх даних, або що. І ми справді мали таємну зброю, але вона була набагато простішою, аніж вони думали. Ніхто не здавав нам новини про їхні фічі. Просто ми могли розробляти софт швидше, аніж будь-хто міг собі уявити.

Коли мені було років дев’ять, я отримав книжку “День Шакала” Фредеріка Форсайта. Головним героєм був вбивця, якого найняли “прибрати” президента Франції. Він мав пройти повз поліцію, аби дістатися до номера з якого було видно маршрут президента. Він пройшов повз них перевдягнувшись стариганом у лахмітті, якого вони б ніколи не запідозрили.

Наша таємна зброя була чимось подібна. Ми писали наш софт на дивній мові пристосованій лише для створення штучного інтелекту з дивним синтаксисом повним дужок. Роками мене дратував подібний опис Lisp. Але зараз це працювало нам на благо. У бізнесі нема нічого більш цінного, аніж технічна перевага, яку ваші конкуренти навіть не розуміють. В бізнесі як і на війні елемент несподіванки там само важливий як і сила.

Отож, мені трохи ніяково казати, але я ніколи не говорив публічно про Lisp поки ми працювали у Viaweb. Ми ніколи не згадували про нього в ЗМІ, а якщо виконати пошук по сайту компанії, то знайшлася б лише згадка двох книжок у моїй біографії. І це не випадковість. Стартап має давати настільки мало інформації, наскільки можливо. Якщо вони не знали на чому ми писали чи їм було все одно, я намагався підтримувати цей статус-кво. [2]

Люди, які розуміли наші технології найкраще – це клієнти. Їм було все одно на якій мові було написано Viaweb, але вони помічали, що все працювало справді чудово. Вони могли створювати чудові онлайн магазини буквально за хвилини. І таким чином, в основному завдяки їх порадам, ми отримували все більше клієнтів. На початку 1996-го у нас було 70 магазинів. На кінець 1997 – вже 500, а шість місяців потому, коли нас купив Yahoo!, у нас уже було 1070 користувачів. Зараз під маркою Yahoo Store цей софт досі є лідером на ринку. Це одна з найбільш прибуткових частин Yahoo і магазини створені завдяки ньому стали основою Yahoo Shopping. Я покинув Yahoo в 1999, тож не знаю скільки зараз у них користувачів, але остання цифра, яку я чув – це 20000.

Blub-парадокс

Що ж такого чудового в Lisp? І якщо він такий чудовий, то чого він не використовується масово? Ці питання виглядають риторичними, але насправді на них є прямі відповіді. Lisp чудовий не тому, що там приховано якусь магію, котру видно лише утаємниченим, а просто тому, що це найпотужніша доступна мова. І причина чого вона не дуже поширена в тому, що мови програмування це не просто технології, а й певні розумові звички, які перебороти дуже і дуже складно. Звісно, обидві відповіді вимагають пояснення.

Я почну із шокуюче суперечливої заяви: мови програмування відрізняються за своєю потужністю.

Думаю навряд знайдеться багато людей, які заперечуватимуть, що вискорівневі мови програмування більш потужні за машинний код. Більшість програмістів погодяться, що зазвичай писати на машинній мові – це не дуже гарна ідея. Натомість краще використовувати високорівневі мови і дати можливість компілятору перевести її в машинний код за вас. Цю ідею зараз навіть використовують у апаратному забезпеченні: з 80-х років набори інструкцій розроблялися для компіляторів, а не для людей.

Кожен знає, що писати всю програму вручну в машинних кодах неправильно. Але мало хто розуміє, що цей принцип можна узагальнити: якщо у вас є вибір мов програмування, то при всіх інших рівних умовах правильно обрати найбільш потужну. [3]

Є багато виключень з цього правила. Якщо вам потрібно написати програму, яка має тісно співпрацювати з програмою написаною на певній мові, то краще використовувати саме ту мову. Якщо ви пишете програму, яка робить щось дуже просте, типу обробки чисел чи бітових маніпуляцій, можливо краще використовувати менш абстрактні мови, тим паче, що це може дати помітний приріст у швидкодії. Якщо ж ви пишете маленьку програмку “на викинути”, найкраще використати ту мову, у якої найбільш підходящий набір бібліотечних функцій. Але в цілому для розробки ПЗ вам варто використовувати найбільш потужну (і достатньо ефективну) мову програмування яку тільки зможете, а використання всього іншого – помилка того ж типу, хоч і в меншій мірі, як і програмування в машинних кодах.

Ви бачите, що машинні коди дуже низькорівневі. Але в певному загальноприйнятому сенсі всі високорівневі мови програмування вважаються еквівалентними. Але вони такими не є. Технічно термін “високорівнева мова” не має під собою чіткого визначення. Немає чіткої границі між машинними мовами з одного боку та всіма високорівневими мовами з іншого. Мови розподіляються по спектру [4] абстрактності від найбільш потужних і до машинних мов, які самі по собі різняться за потужністю.

Наприклад Cobol. Cobol – високорівнева мова в тому сенсі, що він компілюється в машинний код. Але ви що, правда сперечатиметесь, що Cobol не є еквівалентом, наприклад, Python? Та він мабуть ближчий до машинних мов, аніж до Python.

А як щодо Perl 4? Між Perl 4 та Perl 5 в мову були додані лексичні замикання. І більшість Perl-хакерів погодяться, що Perl 5 потужніший за Perl 4. Але визнаючи це, ви також визнаєте що одна високорівнева мова може бути потужніша за іншу високорівневу мову. І невмолимим є висновок, що окрім певних винятків, ви повинні використовувати найпотужнішу доступну мову.

Щоправда цю ідею рідко доводять до кінця. Після певного віку програмісти рідко добровільно змінюють мовні вподобання. Яку б мову вони не використовували, вони вважають її “достатньо хорошою”.

Програмісти дуже прив’язуються до улюблених мов і я не хочу образити нічиїх почуттів, тому я поясню все на прикладі гіпотетичної мови Blub. Blub знаходиться рівно посередині спектру абстрактності. Він не є найбільш потужним, але значно потужніший за Cobol чи машинний код.

І насправді наш гіпотетичний Blub-розробник не буде використовувати жоден з них. Звісно, він не писатиме в машинних кодах. Для цього є компілятори. А щодо Cobol, то він не знає як на ньому написати все, що йому треба. У нього ж просто немає X (бідь-яка фіча Blub на ваш вибір).

До тих пір поки гіпотетичний Blub-розробник дивиться на спектр вниз він знає, що він дивиться вниз. Мови менш потужні за Blub очевидно менш потужні, бо в них нема тих можливостей до яких він звик. Але коли цей розробник подивиться в іншу сторону, вверх по спектру потужності, він не розумітиме, що дивиться вверх. Все, що він бачить – це лише дивні мови. Він мабуть навіть вважає їх еквівалентними Blub по потужності, але з усіма цими незрозумілими заморочками. Blub для нього “достатньо гарний”, бо він думає на ньому.

Коли ми поглянемо на те саме з точки зору програміста, який використовує мову, що знаходиться вище по спектру потужності, ми побачимо, що він дивиться на Blub згори. Як на ньому взагалі можна писати? У нього ж нема Y!

По індукції лише програмісти, що дивляться з висоти достатньої аби оцінити всю різницю в потужності різних мов можуть сказати які з них насправді найбільш потужні (і мабуть це саме те, що мав на увазі Ерік Ремонд, коли казав, що Lisp зробить з вас кращого розробника). Ви не можете довіритись думці інших через Blub-парадокс:: всі задоволені тією мовою, якою їм доводиться користуватись, тому що вона диктує їм те як писати.

Я знаю це із власного досвіду як старшокласник, що писав програми на Basic. Ця мова навіть рекурсію не підтримує. Важко уявити написання програми без використання рекурсії, але тоді мені її геть не бракувало. Я думав на Basic. І я був його гуру. Знав всі його трюки.

П’ять мов, що рекомендує Ерік Реймонд, розташовані в різних точках спектру потужності. Питання відносних відстаней між ними дуже чутлива тема. Я б помістив Lisp на його вершину. І аби підкріпити це твердження я скажу про одну з речей, якої мені бракує в чотирьох інших. Я думаю: “як на них взагалі можна щось написати без макросів?” [5]

Багато мов мають особливість, яка називається називається макросами. Але макроси Lisp унікальні. І хочете – вірте, хочете – ні, але це пов’язано з дужками. Дизайнери Lisp засунули туди ці дужки не просто аби відрізнятись від інших. Для Bulb-програміста код на Lisp виглядає дивно. Але дужки там не просто так. Вони очевидний доказ фундаментальної різниці між Lisp там всіма іншими мовами.

Код на Lisp конструюється з об’єктів Lisp. І не в тому тривіальному сенсі, що програмний код складається з символів, а рядки – це один з типів даних що підтримується мовою. Код на Lisp після його прочитання парсером представляє собою структуру даних, яку можна обійти.

Якщо ви розумієте як працюють компілятори, то зрозумієте, що справа не в тому, що у нього дивний синтаксис, а в тому, що у нього його немає. Ви пишете програми у вигляді дерева, які насправді генеруються в нетрях компіляторів, що парсять інші мови. Але ці дерева повністю доступні з вашої програми. Ви можете писати програми, які ними маніпулюватимуть. В Lisp ці програми називаються макросами. Це програми, що пишуть програми.

Програми, що пишуть програми? Вам це взагалі потрібно? Не дуже, якщо ви думаєте на рівні Cobol. Ввесь час, якщо ви думаєте на рівні Lisp. Зручно було б якби я міг навести тут приклад потужного макросу і сказати: “Ось! Як вам таке?” Але якби я це зробив, це виглядало б повною тарабарщиною для людини, яка не знає Lisp; і тут не вистачить місця, аби описати все, що вам потрібно знати, аби зрозуміти його значення. В Ansi Common Lisp я намагався проходити всі теми якомога швидше і все одно дістався до макросів лише на 160-й сторінці.

Але я думаю, що зможу навести приклад, який може бути переконливим. Програмний код Viaweb редактора складався з макросів на 20-25%. Макроси важче писати, аніж звичайні функції Lisp і використовувати їх там де це не обов’язково – ознака поганого тону. Тому кожен макрос в тому коді був там, тому що він мав там бути. Це означає, що як мінімум 20-25% коду програми роблять речі, які не так-то легко зробити засобами інших мов. Яким би скептиком не був Blub-програміст відносно моїх заяв про потужність Lisp, цього має бути достатньо аби розпалити його зацікавленість. Ми не писали код заради власного задоволення. Ми були крихітним стартапом і програмували щосили аби звести технічні мури між нами та нашими конкурентами.

Підозріла людина може почати цікавитись а чи не було тут якоїсь відповідності? Великий шматок нашого коду робив речі майже неможливі в інших мовах. Наш софт робив речі, які були неможливі для софту наших конкурентів. Можливо це речі пов’язані. Я заохочую вас розплутати цей клубок самостійно. Можливо у того старигана в лахмітті приховано щось, що так одразу і не побачиш.

Айкідо для стартапів

Я не розраховую переконати всіх вчити Lisp. Мета цієї статті була не змінити чийсь світогляд, а підштовхнути людей, яких цікавить Lisp – людей, які знають що він потужний, але побоюються, що його дуже рідко використовують. У конкурентному середовищі це перевага. Потужність Lisp примножується тим фактом, що ваші конкуренти цього не розуміють.

Якщо ви думаєте використовувати Lisp у стартапі, не переживайте, що не всі вас зрозуміють. Вам навпаки краще сподіватись на цей статус-кво. І скоріш за все так і буде. Така природа мов програмування: програмісти задовольняються тим, що в них є. Апаратне забезпечення змінюється набагато швидше ніж звички, тому практики програмування вже відстають від потужності процесорів на 10-20 років. У закладах типу Массачусетського технологічного університету пишуть програми на високорівневих мовах з середини 60-х, але багато компаній продовжували писати програми в машинних кодах аж до 80-х. Я впевнений, що багато хто продовжував писати на машинних мовах поки процесор, як бармен, що взяв, закрив заклад і просто пішов додому, нарешті залишив їх не при справах переходом на RISC інструкції.

Звичайні технології змінюються швидко. Але мови програмування інші: вони представляють собою не просто технологію, а те як програмісти мислять. Вони наполовину – технології, а наполовину – релігія. [6] І середньостатистична мова (тобто будь-яка мова, якою користується середньостатистичний програміст) розвивається зі швидкістю айсберга. Garbage collection, що з’явився в Lisp ще у 60-х зараз вважається гарною річчю. Runtime-типізація теж набирає популярність. Лексичні замикання, що з’явились в Lisp ще на початку 70-х зараз лише з’явились на “радарах”. Макроси, запропоновані в Lisp в середині – 80-х і досі “terra incognita”

Очевидно, що середньостатистична мова має неймовірну інерцію. Я не пропоную протистояти цій потужній силі. Я пропоную цілком протилежне: як і людина, що займається айкідо – використовуйте це проти своїх суперників.

Якщо ви працюєте у великій компанії – це буде нелегко. Вам складно буде переконати тупуватого начальника дозволити написати щось на Lisp, коли він лише щойно прочитав, що якась інша мова програмування приречена на успіх, як пророкували мові Ada 20 років тому. Але якщо ви працюєте у стартапі, у якого ще немає тупуватого начальства, ви можете використати Blub-парадокс на власну користь: використати технологію, яку ваші конкуренти, скуті середньостатистичними мовами, ніколи не зможуть перевершити.

Якщо ви хоч колись зустрінетесь зі стартапами, ось підказка як можна легко їх оцінити. Подивіться кого вони наймають на роботу. Все, що написано у них на сайті – це стокові фото та всяка лірика, але опис вакансій розповість про те, що ж саме вони хочуть зробити, або вони набирають не тих людей.

За роки роботи у Viaweb я прочитав багато описів вакансій. Нові конкуренти, здається, з’являлись нізвідки майже кожен місяць. Перша річ, яку я перевіряв після їх online-демо, це відкриті вакансії. Після кількох років я вже розумів, які компанії могли представляти потенційну загрозу, а які – ні. Чим більше звичних речей було в описів вакансій, тим меншу небезпеку вона представляла. Найбільш безпечними були ті, що вимагали досвід роботи з Oracle. Про них можна було одразу забути. Вам також не треба було особливо переживати відносно компаній, що шукали C++ та Java розробників. Якщо компанія шукала розробників на Perl чи Python – її вже треба було остерігатися, адже це компанії, де принаймні за технічну сторону відповідали справжні хакери. Якби я зустрів опис вакансії на місце Lisp-розробника, то це мене б дуже сильно занепокоїло.

Примітки

[1] Viaweb складався з двох частин: редактор, насписаний на Lisp за допомогою якого люди будували сайти та система замовлень написана на C. Перша реалізація була написана на Lisp майже повністю, бо система замовлень була дуже простою. Пізніше ми додали ще два модулі: генератор картинок написаний на C та back-office менеджер написаний здебільшого на Perl.

У січні 2003 Яху випустила нову версію редактора написану на C++ та Perl. Але важко було сказати, що це вже не був Lisp, бо для того, аби переписати код на C++ їм фактично довелось написати власний інтерпретатор: програмні коди генератора сторінок, наскільки мені відомо, досі написані на Lisp.

[2] Роберт Морріс каже, що мені не треба було цього приховувати, бо навіть якби наші конкуренти знали, що ми використовуємо Lisp, вони не зрозуміли б чому: “Якби вони були достатньо розумними для цього, то самі використовували б Lisp.”

[3] Всі мови рівнопотужні в сенсі еквівалаентності машині Тюрінга, але програмісти ніколи не мають на увазі саме цю еквівалентність (ніхто ж не пише для машини Тюрінга). Потужність про яку говорять програмісти складно визначити формально, але одним із способів описати її буде: можливість мови більш потужної може бути реалізована на мові менш потужній лише шляхом написання інтерпретатора більш потужної мови. Якщо у мові А є оператор для видалення пробілів з рядка, а у мові Б – ні, то це не робить мову А більш потужною, бо ви можете написати функцію, яка робитиме те саме в Б. Але якщо А підтримує, скажімо, рекурсію, а Б – ні, то це вже не реалізуєш простим написанням бібліотечної функції.

[4] Примітка для нердів: можливо це решітка, що звужується догори; форма не має значення, але ідея в тому, що там є принаймні частковий порядок.

[5] Це трохи невірно трактувати макроси як окрему фічу. На практиці їх користь значно збільшується завдяки іншим можливостям Lisp типу лексичних замикань та залишкових параметрів.

[6] В результаті порівняння мов програмування або приймає вид релігійних воєн, або книжок для школярів показово нейтральних, як взірець гуманізму. Люди, що знаю ціну своєму часу та душевний спокій оминають цю тему. Але це питання релігійне лише наполовину; його варто вивчати, особливо якщо ви хочете винайти нову мову.

Photo by Matt Olson

Вчора випадково наткнувся на одне цікаве есе відомого у ІТшних колах Пола Грема. Чесно кажучи, я раніше думав, що він пише лише про ІТ та LISP. Одна з найбільш надихаючих його статей на цю тематику – “Перемогти посередність”, а тут був дещо здивованим, що він досить цікаво пише і “за життя”. Звісно, не з усіма пунктами можна погодитись, але джерело для роздумів вельми цікаве.

Цікаво, а про що каже Київ?

Автор оригіналу: Пол Грем (Paul Graham)
Оригінал: Cities and Ambition

Великі міста приваблюють амбітних людей. Ви відчуваєте це, коли гуляєте таким містом. Сотнями тонких натяків місто каже вам: ти здатен на більше, старайся з усіх сил.

Дивує те, наскільки різними будуть ці послання. Нью-Йорк в першу чергу скаже вам: тобі треба заробляти більше грошей. Звісно, цих послань значно більше. Будь модним. Виглядай гарно. Але найголосніше лунають слова про те, що ти маєш бути багатим.

Що мені подобається в Бостоні (чи скоріше Кембріджі) це те, що його послання: будь розумним. Сядь і прочитати всі ті книжки, які тобі треба.

Інколи ти отримуєш дивні відповіді, коли питаєшся про що каже місто. Наприклад, Кремнієва долина насправді каже тобі: стань більш могутнім. Хоча те, що там поважають розум теж правда.

Але це не те саме, про що каже Нью-Йорк. Влада багато чого значить і в Нью-Йорку, але Нью-Йорк буде вражений лише вашим статком, навіть якщо він всього-на-всього дістався вам у спадщину. У Кремнієвій долині нікого не цікавлять ваші гроші, окрім, хіба що, агентів з нерухомості. Що цікавить Кремнієву долину – це міра твого впливу на світ. Причина, чому людей цікавлять Ларрі та Сергій – не їх багатство, а той факт, що вони володіють Google, від якого залежать практично всі.

_____

Наскільки важливо те, про що каже місто? З власного досвіду скажу: багато. Можливо вам здається, що маючи сильний дух вам вдасться не зважати на власне оточення. Вплив місця проживання мав би бути мізерно малий. Але якщо поцікавитись історичними фактами, то зрозуміло, що він не настільки вже й незначущий. Більшість персоналій, що творили великі справи, були згуртовані у кількох місцях, де ці справи, власне, і творилися на той час.

Ви можете відчути силу духу міста з того, про що я писав раніше у випадку з Леонардо Міланським. Практично всі італійські художники XV сторіччя, про яких ви чули, були з Флоренції попри те, що Мілан був не меншим за розмірами. Люди у Флоренції мали генофонд ідентичний Міланському, тож можна припустити, що у Мілані народився й інший художник з природнім талантом не гіршим за Леонардо. Що ж з ним сталося?

Якщо навіть хтось зі здібностями не гіршими ніж у Леонардо не зміг подолати силу оточення, то ви думаєте, що зможете?

Я не можу. Я дуже впертий, але я не пробував би воювати з цією силою. Я б краще використав її. І я довго думав про те, де жити.

Я завжди уявляв Берклі ідеальним місцем – той самий Кембрідж, але з гарним кліматом. Але коли я спробував пожити там пару років тому виявилось, що я помилявся. Беркі каже тобі: живи краще. Життя у Берклі дуже цивілізоване. Мабуть це те місце в Америці, де виходець з Північної Європи почував би себе як вдома. Але воно не сповнене амбіціями.

Photo by Vinoth Chandar

Зараз я розумію, що нема нічого дивного в тому, що настільки приємне місце приваблює людей, які більш за все цінують рівень життя. Кембрідж з гарним кліматом, виявляється, зовсім не Кембрідж. Люди, яких ви зустрінете в Кембріджі потрапили туди не випадково. Вам потрібно піти на жертви, аби бути там. Він дорогий, бруднуватий, і погода там часто жахлива. Тому люди, яких ви зустрінете там, – це ті люди, що воліють жити разом із найрозумнішими навіть попри те, що це означає жити в дорогому, брудному місці з жахливою погодою.

Під час написання цих рядків мені здається, що Кембрідж є інтелектуальною столицею світу. І я розумію, що це звучить як безглузда заява. Але що робить її ближчою до правди, так це те, що подібні заяви про інші місця будуть звучати ще більш безглуздо. Американські університети здаються мені найкращими, якщо судити по амбіціям їх студентів. І яке інше місто Америки може зробити серйознішу заяву? Нью-Йорк? Там багато розумних людей, але вони губляться в набагато більшому потоці первісних людей у костюмах. Район затоки Сан-Франциско теж налічує багато розумників, але знову ж таки – вони сильно розбавлені; там є два чудових університети, але вони знаходяться далеко один від одного. Гарвард та Массачуссетський Технологічний Інститут знаходяться практично поруч по мірках Західного узбережжя і вони оточені близько 20 іншими коледжами та університетами. [1]

Кембрідж являється містом, чия основна промисловість – ідеї. Так само як для Нью-Йорку – гроші, а у Кремнієвій долині – стартапи.

_____

Говорячи так про міста ми в першу чергу маємо на увазі їх населення. З давніх давен міста були єдиним великим скупченням людей, тож ці два поняття є синонімами. Але з тих прикладів, що я навів ми також бачимо наскільки все змінюється. Нью-Йорк – класичний мегаполіс. А Кембрідж – лише частина міста, А Кремнієва долина – і того менше (Сан Хосе хоч і видає з себе столицю Кремнієвої долини насправді нею не є. Це всього лиш 178 квадратних кілометрів у ньому).

Можливо Інтернет це змінить ще більше. Можливо колись найбільш важлива спільнота, до якої ви будете належати, буде віртуальною і не залежатиме від того, де ви мешкаєте фізично. Але я б на це не закладався. Фізичний світ має дуже високу швидкість передачі даних і деякі слова, якими говорять міста не можна вимовити у віртуальному світі.

Одне з найбільш захоплюючих речей які можна відчути приїхавши до Кембріджа навесні – це гуляти вулицями надвечір, коли можна бачити кімнати будинків. Гуляючи ввечері по Пало-Альто ви не побачите нічого, окрім блакитного кольору телеекранів. У Кембріджі ви побачите стелажі вщент забиті багатообіцяючими книжками. Мабуть Пало-Альто 1960-го нагадував-таки Кембрідж, але зараз нізащо не скажеш, що колись там був університет. Сьогодні це лише один з багатих сусідів Кремнієвої долини. [2]

Місто розмовляє з тобою ніби ненароком – речами, що ви бачите у вікнах, чи обривками розмов, що ви підслухали. Це не те, що ви можете знайти, а те, що вам ні за що не вимкнути. Один із професійних ризиків у Кембріджі – це підслухати розмову людей, які використовують питальну інтонацію у стверджувальних реченнях. Але загалом я все таки оберу Кембріджські розмови, аніж Нью-Йоркські чи Кремнієвої долини.

Моя подруга, що переїхала до Кремнієвої долини наприкінці 90-х сказала, що найгіршою річчю там була низька якість підслуханих розмов. Тоді я подумав, що вона занадто ексцентрична. Звісно, бува цікавим підслуховувати, але невже якість цих розмов настільки важлива, щоб із-за неї обирати місце проживання? Тепер я розумію що вона мала на увазі. Розмови, які ти почув розкажуть тобі про людей, серед яких ти знаходишся.

Photo by Mathieu Thouvenin

Наскільки б рішучо ви не були налаштовані, не піддатися впливу людей навколо буде дуже важко. Звісно, це не означає, що ви будете займатись лише тим, що очікує від вас місто, але вас знеохотить, коли ніхто навколо не поділятиме ваші зацікавлення.

Є певний дисбаланс між заохоченням та знеохоченням. Такий само як між надбанням та втратою грошей. Більшість людей переоцінюють зменшення прибутків: вони працюватимуть краще, аби не втратити долар, аніж аби заробити зайвий. Так само незважаючи на те, що навколо багато людей, які достатньо сильні аби не робити те, що вони мали б робити в певному середовищі, є лише кілька людей здатних продовжувати займатись справою на яку начхати всім навколо.

Тому що амбіції певною мірою несумісні, а захоплення чимось – це гра з нульовою сумою. Кожне місто має тенденцію зосереджуватись на одному типі амбіцій. Причина чому Кембрідж – інтелектуальна столиця полягає не лише в тому, що там сконцентровані розумники, а ще й в тому, що люди там нічим іншим не переймаються. Професори в Нью-Йорку та в районі затоки Сан-Францско – люди другого сорту. Звісно, лише до тих пір поки вони не почнуть колотити гроші чи клепати стартапи відповідно.

Це все підштовхує нас до відповіді на питання, яке люди з Нью-Йорку задають з часів краху дот-комів: чи зможе Нью-Йорк перерости у осередок стартапів та стати суперником Кремнієвої долини? Одна причина, чому це дуже малоймовірно – це те, що людина, яка почне стартап в Нью-Йорку буде вважатись мешканцем другого сорту. [3] В Нью-Йорку вже є те, що його мешканці цінять набагато більше.

В довгій перспективі це може зашкодити Нью-Йорку. Владу нових технологій з часом можна перевести у гроші. Таким чином піклуючись більше про гроші та менше про владу (аніж Кремнієва долина) Нью-Йорк визнає ті самі речі, але повільніше. [4] І насправді він вже програє долині на власному полі: співвідношення мешканців Нью-Йорку та Каліфорнії, що входять до Forbes 400 (400 найбагатших американців) зменшився з 1.45 (81:56), коли список було вперше опубліковано в 1982 до 0.83 (73:88) у 2007.

Photo by Linear Marlin

Не всі міста розмовляють. Лише ті, що є осередками певних амбіцій. І часто складно сказати про що говорить місто не поживши там. Я розумію про що говорить Нью-Йорк, Кембрідж та Кремнієва долина, бо я жив там по кілька років. Вашінгтон та Лос-Анджелес, здається, теж розмовляють, але я не прожив там достатньо, щоб з певністю сказати про що саме.

Значущою у Лос-Анджелесі мені здається слава. Там є Список людей на яких найбільший попит. Вами будуть захоплюватись, якщо ви будете в цьому списку, або дружитимете з кимось із нього. Окрім цього все інше схоже на Нью-Йорк, хіба що з більшим значенням привабливої зовнішності.

У Вашінгтоні найбільше цінуються ваші зв’язки. Там потрібно бути “інсайдером”. На практиці все працює аналогічним до Лос-Анджелеса чином. Там теж є Список і ви маєте бути або в ньому, або знати когось із нього. Єдина різниця – це те яким чином формується Список. І навіть це не так вже і суттєво відрізняється.

Наразі слова Сан-Франциско схожі на Берклі: ти маєш жити краще. Але це зміниться, коли достатня цількість стартапів оберуть Сан-Франциско замість Долини. Під час бульбашки дот-комів там були передвісники краху: потурання примхам типу придбання дорогих офісних меблів. Навіть зараз я з підозрою ставлюсь до стартапів, що обирають Сан-Франциско. Але коли там з’явиться критична маса гарних стартапів це перестане бути примхами, тому ще центр Кремнієвої долини зміститься туди.

Я не знайшов нічого подібного Кембріджу по інтелектуальним амбіціям. Оксфод та Кембрідж (Англійський) нагадують Ітаку чи Ганновер: слова звучать, але не настільки гучно.

Париж був колись значним інтелектуальним центром. Якби ви поїхали туди в XIV сторіччі можливо він говорив би голосом Кембріджа. Але я пробував трохи пожити там минулого року і зрозумів, що амбіції його мешканців – не інтелектуальні. Париж каже: роби все стильно. І мені це сподобалось. Париж – єдине місто в якому я жив, де люди щиро цінують мистецтво. У Америці лише кілька багатіїв купують оригінальні витвори мистецтва, але і там не знайдеш чогось більш цінного, але з менш відомим авторами. А у вікнах парижан надвечір помітно, що люди там справді цінують зображення на картинах. З усіх міст що я знаю, у Парижі найцікавіше піддивлятись [5].

Є ще кілька слів, що я чув від міст. У Лондоні ви все ще (ледь-ледь) почуєте слова про те, що ви маєте бути більш аристократичним. Якщо прислухатись, то це саме можна почути в Парижі, Нью-Йорку та Бостоні, але зараз я мабуть і не почув би цього, якби не намагався відчайдушно знайти цю хвилю, щоб дізнатись чи залишилось щось від радіостанції.

_____

Photo by Ryan Hyde

Тож повний список ідей, які і я почерпнув від міст це: багатство, стиль, мода, приваблива зовнішність, слава, політична влада, економічна влада, інтелект, соціальний статус та рівень життя.

Мені стало недобре, коли я вперше зробив цей список. Я завжди вважав амбції гарною річчю, але зараз я зрозумів, що це тому, що я враховував лише близькі мені амбіції. Якщо дописати все, чого можуть прагнути в житті люди, цей список виглядатиме не так вже привабливо.

Розглянувши його більш детально я побачив кілька дивних з історичної точки зору речей. Наприклад, зовнішня привабливість не була б у списку років так 100 тому (хоча водночас була б там 2400 років назад). Це зажди було прерогативою жінок, але наприкінці XX сторіччя схоже, що це стало мати значення і для чоловіків. Я не впевнений чому саме – можливо збіг кількох обставин: збільшення влади жінок, збільшення впливу акторів як моделей та той факт, що люди працюють у офісах: ви не можете красуватись у одязі, який занадто крикливий для заводського цеху, тож доводиться красуватись власним тілом.

Мода – інша річ, яку не видно було 100 років тому. Чи було? Це означає знати що є що. Тож можливо вона просто підмінила частину соціального статусу, яка полягала у тому, аби завжди бути “в курсі”. Це могло б пояснити чому моду так цінують в Лондоні: це друга версія традиційного англійського задоволення від неясних знаків, які розуміють лише утаємничені.

Чи має хтось, хто хоче творити великі справити жити у великому місті? Ні. Всі великі міста надихають на ті чи інші амбіції, але не вони єдині. Для деяких робіт достатньо мати поруч кілька талановитих колег. Економічна влада була б у списку і 100 років тому, але її значення змінилося. Раніше вона означала контроль над значними людськими та сировинними ресурсами. Зараз вона означає здатність спрямовувати розвиток технологій і багато з людей здатних на це геть не багатії: типовий приклад – лідери проектів з відкритим кодом. Капітани Індустрії минулих часів мали лабораторії з розумними людьми, які створювали для них нові технології. Нова порода капітанів це розумники самі по собі.

Оскільки ця сила привертає все більше уваги, інша випадає зі списку: соціальний статус. Я думаю, що ці речі пов’язані. Економічна влада, багатство, соціальний статус – різні назви одного і того ж у різних його фазах: економічна влада перетворюється на багатство, а багатство – на соціальний статус. Тобто погляд на предмет захоплення всього лиш піднімається вище по струмку.

_____

Що пропонують міста – це аудиторію та джерело однодумців. Це не так критично для математиків та фізиків, де вам не потрібен ніхто, окрім однодумців, а завдяки чітким критеріям оцінки знайти потрібних людей дуже легко. У таких сферах як математика та фізика все що вам потрібно – це відділ з правильними коегами. А знаходитись він може будь-де: наприклад, в Лос-Аламос, штат Нью-Мексико.

У таких сферх як мистецтво, література чи технології потужне середовище має вирішальну роль. У них найкращі не завжди зручно гуртуються на найкращих університетських кафедрах та дослідницьких лабораторіях – частково тому, що у цих випадках талант складніше оцінити, а частково тому, що їм не потрібно спиратись на освітні чи дослідницькі гранти, щоб розвиватись. Саме для цих хаотичних сфер найкраще перебувати у великому місті: вам потрібно заохотливе відчуття, що люди навколо вас цінують те, що ви робите і оскільки вам потрібно буде шукати однодумців самостійно вам потрібен набагато більший вибір, який запропонує лише велике місто.

Вам не треба проживати все життя у великому місті, щоб отримати з цього користь. Найважливіші роки – це початок та середина вашої кар’єри. Точно не є необхідністю зростати у великому місті, як і не має значення чи підете ви в ньому до коледжу. Для більшості студентів коледжу світ з кількох тисяч людей й так достатньо великий. До того ж у коледжі вам ще не випаде найскладніше завдання: знайти собі новий виклик.

От коли ви зробите наступний і набагато складніший крок вам в нагоді стане місце, де можна буде знайти однодумців та натхнення. І вам можна буде покинуте це місце, коли ви знайдете і те, і інше. Імпрессіоністи жили по типовому шаблону: вони народжувались по всій Франції (Піссарро народився на Карибах) і помирали по всій Франції, але що було визначальним у їх житті – це роки проведені разом в Парижі.

Photo by Mohamed Muha

Поки ви ще не знаєте чим будете займатись і де саме знаходиться центр ваших устремлінь, найліпше було б пожити у кількох містах поки ви ще молоді. Ви не відчуєте про що говорить місто не поживши там і навіть не зможете сказати чи воно розмовляє взагалі. Часто інформація буде неправдивою: я спробував жити у Флоренції, коли мені було 25 думаючи, що це буде осередок мистецтва, але схоже, що я спізнився на 450 років.

Навіть коли місто є живим центром амбіцій ви не зможете сказати напевно чи воно резонує саме з вашими поки самі не почуєте його. Коли я переїхав у Нью-Йорк я був дуже вражений. Це захоплююче місце. Тож мені знадобився деякий час, аби зрозуміти, що я не схожий на його мешканців. Я продовжував шукати Кембрідж у Нью-Йорку. Схоже, що він знаходився на його околицях: околицях, до яких летіти годину літаком.

Деякі люди у 16 років знають чим будуть займатись, але у більшості амбітних дітей, амбіції здаються ненаправленими. Вони просто знають, що будуть робити щось значуще. Просто ще не визначились будуть вони рок-зіркою, чи нейрохірургом. І в цьому нема нічого поганого. Але якщо у вас типова амбітність, то вам потрібно буде знайти своє місце проживання методом спроб та помилок. Можливо ви спочатку знайдете місце, де вам буде комфортно і тільки тоді визначитесь зі своїм покликанням.

Примітки

[1] Це одна з переваг того, що університети у вашій країні не підконтрольні державі. Коли держава визначає як розподілити ресурси, політизований підхід змушує розширювати географію. Жоден уряд не розмістить два найкращі університети в одному місті, якщо це не столиця (але це спричинить інші негаразди). Та науковці схильні гуртуватись не менше, аніж інші і за наявності свободи вибору використають ті ж переваги.

[2] У Пало-Альто все ще є кілька старих професорів, але вони поступово вимирають і їх будинки перетворюються на вульгарні котеджі для віце-президентів бізнес-департаментів.

[3] Скільки разів ви читали про засновників стартапів, що продовжували жити невибагливо, коли їх компанії злітали? Хто продовжував одягати джинси та футболки, водити старі машини, які купили ще в університетські часи і т.д.? Якби ви спробували зробити це в Нью-Йорку, то на вас би дивились як на лайно. Якщо ви йдете у фешенебельний ресторан у Сан-Франциско в джинсах та футболці – вони приязні до вас; хтозна хто ви такий? Але не в Нью-Йорку.

Одина з ознак потенціалу міста як технологічного центру – це кількість ресторанів, куди піджак для чоловіка – необхідний елемент дрес-коду. Згідно Zagat (http://www.zagat.com/): жодного у Сан-Франциско, , Лос-Анджелесі, Бостоні та Сіетлі. 4 у Вашінгтоні, 6 у Чікаго, 8 у Лондоні, 13 у Нью-Йорку та 20 у Парижі.

(В списку Zagat “Ritz Carlton Dining Room” у Сан-Франциско вимагає піджак, але я не міг в це повірити і передзвонив перевірив – це неправда. Насправді єдиний ресторан на всьому Західному узбережжі, що вимагає піджак – це “The French Laundry” у Долині Напа)

[4] Ідеї – це ще один крок вище по течії від економічної влади, тож не виключено, що інтелектуальні центри типа Кембріджа одного дня зможуть випередити Долину як та у свій час Нью-Йорк.

Зараз це малоймовірно. Наразі Бостон все більше і більше відстає. Єдина причина чому я згадав цю можливість – те, що шлях від ідеї до стартапу останнім часом став набагато коротшим. Зараз парі хакерів набагато простіше заснувати стартап, аніж це було 10 років тому. Якщо екстраполювати це ще на 20 років, можливо баланс почне зміщуватись назад. Я б не закладавіся на це, але не закладався б і проти цього.

[5] Якщо Париж – це місце, де найбільше цінують мистецтво, то чому Нью-Йорк став центром арт-бізнесу? Тому що в XX сторіччі мистецтво як бренд відділилося від мистецтва самого по собі. Нью-Йорк – це місце з найбагатшими покупцями, але все, що вони вимагають від мистецтва – це бренд. А оскільки бренд можна заснувати на будь-чому з достатньо незрозумілим стилем, то можна використовувати і локальні витвори.

Оригінал тут.

оригінал

оригінал

P.S. Хоч комікс трохи не про це, але написане в третій частині коміксу – дуже влучне насправді. Мну в певному сенсі відчув це коли відпочивав у Лисячій бухті, коли за три дні проникся духом свободи настільки, що якби захотів міг вільно стягнути плавки на “цивільному” пляжі біля найближчого до бухти санаторію, який ми проходили по дорозі з ринку. Це відчуття: “от захочу – і зроблю, і пофіг на них всих” насправді одне з найприємніших станів душі, які я колись відчував.

оригінал

оригінал

оригінал

Деякі найбільш цікаві речі, якщо буде не геть вже ліньки, і надалі перекладатиму…

У Visual Studio .NET здається досить дивна система додавання та управління такими ресурсами як растрові зображення та локалізовані рядки. Воно працює не завжди, воно нелогічне, інструменти управління вельми бідні і, нарешті, воно погано задокументоване.

Цей документ і посібник допоможе привести все до ладу.

Концепція

Ось чому все виходить не так як треба:

У Visual Studio .NET багато ресурсів вже не зберігаються у .RC файлах. Замість цього редактор форм напряму маніпулює вашим VB чи C# кодом коли вам треба щось візуально відредагувати.

Але нам дійсно все ще потрібні інші типи ресурсів. Нам потрібні графічні ресурси такі як растрові зображення та іконки так само як і залежні від локалі рядки. Вони зазвичай зберігаються в одному чи багатьох .RESX файлах, які входять у проект Visual Studio.

Таким чином щоб використовувати ці ресурси у вашому програмному коді вам необхідно знати як:

• Створити RESX файли.
• Додавати зображення та інші типи ресурсів до RESX файлу.
• Завантажити ресурс у вашому коді.

Отож, почнемо…

Створення RESX файлу

Visual Studio .NET зберігає ресурси типу растрових зображень, іконок та локалізованих рядків у файлах з розширенням .RESX. Насправді ці файли є звичайними XML файлами в яких всі бінарні ресурси кодуються в BASE64.

Коли ви компілюєте проект, то компілятор перетворює ці файли в бінарні з розширенням .resource, а потім лінковщик підключає їх у результуючий файл EXE чи DLL.

Додати новий RESX файл в проект елементарно: просто клацніть правою кнопкою миші на проекті в “Solution Explorer”, оберіть “Add/Add New Resource” і додайте новий “Assembly Resource File”.

Додавання ресурсів до RESX файлу

А отут починаються веселощі: у Visual Studio не передбачено ніяких засобів для візуального редагування ресурсів у файлі RESX. На щастя, Лютц Роедер (Lutz Roeder) створив інструмент під назвою Resourcer який можна використовувати для їх редагування.

Щоб додати растрове зображення до RESX файлу:

Запустіть Resourcer.
1. Відкрийте у Resourcer’і ті RESX файли які ви додали до проекту Visual Studio.
2. Виберіть “Add”/”Add File”.
3. Коли з’явиться ділог, введіть ім’я файлу з растровим зображенням і символічне ім’я під яким його вміст буде збережено у файлі RESX. Після натискання на кнопку “ОК”, вміст файлу буде закодовано у BASE64 і розміщено в RESX під іменем, яке ви обрали.
4. Збережіть файл RESX вибравши “File”/”Save”.

От і все. До речі, вам більш не треба тримати власне сам файл растрвого зображення, оскільки в RESX файлі зберігається його повноцінна копія.

Використання ресурсів з вашого програмного коду

А ось так треба завантажувати ресурс під час виконання програми:

По-перше, вам потрібно знати під яким іменем Visual Studio помістило цей ресурс у результуючому EXE файлі. Кожен проект Visual Studio має простір імен, який з ним асоційований.

Кожен проект Visual Studio має асоційоване з ним ім’я простору імен (даруйте за тавтологію). Клацнувши двічі на файлі проекту в Solution Explorer, а потім вибравши пункт Properties ви побачите діалог, який дозволить обрати “Простір імен по замовчуванню” (“Default Namespace”). Visual Studio додасть всі ресурси в результуючий EXE-файл під іменем, яке утворюється з імені по замовчуванню та іменем RESX файлу.

Нехай ваш простір імен по замовчуванню називається MyCompany.MyProject, а RESX-файл називається SomeResources. Тоді ці ресурси знаходитимуться у результуючому виконуваному файлі під іменем MyCompany.MyProject.SomeResources.

Щоб отримати доступ до ресурсів з вашого коду вам потрібно буде створити екземпляр ResourceManager:

ResourceManager resourceManager = new ResourceManager
               ("MyCompany.MyProject.SomeResources", GetType ().Assembly);

Потім щоб отримати растрове зображення ви використовуватимете символічне ім’я, яке ви вказали, коли додавали його до файлу RESX використовуючи Resourcer:

Bitmap image = (Bitmap)resourceManager.GetObject ("MyBitmapName");

Якщо ви спробуєте створити менеджер ресурсів використовуючи неправильне ім’я, або ви ввели неправильне ім’я коли викликали ResourceManager.GetObject, то фреймворк викине MissingManifestResourceException.

От і все. Насолоджуйтесь

Додаток

Я щойно отримав листа від Яна Гріффіта (Ian Griffiths). Він пише, що є простіший спосіб зберігати незалежні від локалі ресурси (зазвичай іконки та бітмапки) в проекті. Просто додайте їх до проекту як і будь-який інший файл, а потім виставте їх Build Action в Embedded Resource.

Хоча їх завантаження все одно буде нетривіальним. Нехай ви хочете завантажити растрове зображення. Найпростіший спосіб – це використати конструктор класу Bitmap в формі:

Bitmap (Type type, string resource);

Перший параметр – це тип, що “володіє” ресурсом, а другий – це власне ім’я ресурсу.

А ось тепер починається нетривіальність: завантажувач ресурсів намагається завантажити ресурс з іменем, яке складається з імені простору імен до якого відноситься параметр type та власне імені ресурсу. Таким чином якщо ви всередині методу класу MyCompany.MyProject.MySubProject.MyClass спробуєте завантажити ресурс з іменем MyBitmap.bmp виконавши:

Bitmap bitmap = new Bitmap (GetType (), "MyBitmap.bmp");

То завантажувач ресурсів спробує завантажити його як ресурс з іменем MyCompany.MyProject.MySubProject.MyBitmap.bmp.

Як же зберегти ресурс під таким іменем? Ім’я ресурсу в маніфесті формується з імені простору імен по замовчуванню та імені файлу. Таким чином якщо ваш простір імен по замовчуванню називається MyCompany.MyProject то вам залишається лише назвати файл з бітмапкою MySubProject.MyBitmap.bmp.

Лінк на оригінал: http://jelovic.com/articles/resources_in_visual_studio.htm

Простори імен – дуже потужна особливість мови C++. Ця стаття не вчитиме синтаксису просторів імен, вона просто покаже як їх варто використовувати.

Простори імен лише обгортають всі імена, що в нього входять в якесь інше ім’я. Наприклад:

namespace net {
    class Socket {
        ...
    };
}

...

net::Socket socket;

Завдяки цьому ми впевнюємося, що якщо дві бібліотеки матимуть свої реалізації класу Socket, то якщо вони назвуть свої простори імен по-різному, ваша програма зможе їх використовувати без яких би то не було конфліктів.

Але це викликає ще одне питання: якщо дві незалежні компанії вирішать писати мережеві бібліотеки, то який шанс, що вони будуть робити реалізацію класу з назвою Socket? Я так думаю, що вірогідність цього відсотків 100.

Нам також подобається, коли простори імен легко набираються, що означає, що вони мають бути довжиною в 2-4 символи. З урахуванням цього, який шанс, що обидві компанії назвуть свій простір імен “Net”? 5 відсотків? 10 відсотків?

Як би там не було, це показує, що простори імен не вирішують цю проблему повністю – вони просто зменшують вірогідність її виникнення.

Рішення промислового рівня

Розв’язком цієї проблеми є використання довгих, унікальних назв простору імен, а потім їх включення в програму під коротким псевдонімом (alias).

Тож компанія, що розробляє мережеву бібліотеку напише щось типу:

namespace net_33843894 {
    class Socket {
        ...
    };
}

де номер після “net_” має бути згенеровано генератором випадкових чисел. Нехай цей код розміщено в файлі заголовків з назвою.

Далі бібліотека продається клієнту, який вирішує використати її в проекті. Клієнт тоді описує свій власний спеціалізований для проекту файл заголовків з назвою типу і наступним вмістом:

#include <netlib>

namespace net = net_33843894;

Щойно ми створили власний псевдонім для простору імен для бібліотеки, який діє лише в межах нашого проекту. Якби простір імен “net” вже було зайнято іншою бібліотекою, то ми могли б обрати інше ім’я: net2, sock, чи ще щось. Тоді не виникало б ніяких конфліктів імен.

Спрощуючи все

Розумним було б зробити з бібліотекою щось таке, щоб вона стала простішою для користувача. В ідеалі він мав би клацнути двічі на інсталяційному файлі і бібліотека негайно стала б доступною у його середовищі розробки (IDE). Далі він просто набирав би “#include <yourlib>” і використовував її, щоб створити щось корисне.

Але якщо користувачу доведеться створювати свій заголовок для кожного заголовку вашої бібліотеки, то доведеться постійно страждати, використовуючи її. Не кожному це буде до смаку.

Розв’язком цієї проблеми є забезпечення розумних значень по замовчуванню, але дозволивши йому можливість змінити їх, якщо вони не підійдуть. Це можна зробити за допомогою макродиректив в файлі заголовків:

namespace net_33843894 {
    class Socket {
        ...
    };
}

#ifndef NO_NET_33843894_ALIAS
    namespace net = net_33843894;
#endif

Таким способом можна надати логічне значення по замовчуванню для простору імен, а якщо воно вже зайняте, то користувач зможе введенням макросу NO_NET_33843894_ALIAS уникнути створення псевдоніму “net”.

Сучасні компілятори

Повідомлення про помилки це справжній кошмар при використанні шаблонів. З довгими назвами просторів імен ми зробимо їх ще жахливішими.

На жаль, жоден з компіляторів, якими я користуюсь, недостатньо розумний, щоб використовувати найкоротший з доступних псевдонімів у повідомленнях про помилки. Тобто навіть коли ви використовуєте аліас “net”, то повідомлення про помилку при використанні класу Socket буде посилатись на net_33843894::Socket. Що не дуже то читабельно.

Тому я зазвичай йду на маленьку хитрість. Вона працює лише в заголовках, що містять виключно inline-функції (оскільки вона діє лиш на актуальні імена, що використовуються лінковщиком), але в мене їх достобіса. Якщо макрос NO_NET_33843894_ALIAS не визначено, то я використовую коротке ім’я як ім’я простору імен, а довге – як псевдонім:

#ifdef NO_NET_33843894_ALIAS
namespace net_33843894 {
#else
namespace net {
#endif
    class Socket {
        ...
    };
}

#ifndef NO_NET_33843894_ALIAS
    namespace net_33843894 = net;
#endif

І повідомлення про помилки стають більш зрозумілими.