усы2

Стой под стрелой

Поступки и мысли, о которых могу вспомнить не краснея

Previous Entry Поделиться Next Entry
Гости из будущего
усы2
tonsky

Какое-то время назад в комменты на HN пришел Алан Кей и отвечал на вопросы. Одна из тем дискуссии, естественно, куда computer science двигаться дальше.

Думать и разговаривать об этом трудно, потому что ответа никто не знает, а заглядывать в будущее никто не умеет. Кроме того, участники разговора часто по-разному оценивают уровень рассуждений — такое даже в этом ЖЖ происходит постоянно. Есть несколько способов смотреть на программистскую действительность:

  1. Я это использую или могу использовать.
  2. Я знаю, как это сделать
  3. Никто не знает, как это сделать
  4. Никто не знает, что делать

Подавляющее большинство дискуссий происходят на уровне 1. Это уровень How-to и Experience reports. Здесь речь идет о готовых, уже существующих инструментах, которые можно взять с полки. Не подумайте, что тут не о чем говорить — применимость инструментов, эксплутационные качества, взаимные сравнения. Но здесь речь всегда о том, что уже есть, готово, состоялось, сделано кем-то другим, известно как факт, дано нам свыше.

Статьи, написанные на уровне 2, уже вызывают сложности с восприятием, когда их пытаются интерпретировать на уровне 1. Здесь речь идет о том, что предлагается сделать. Новая идея, новый подход, новая библиотека, новый язык — их еще не существует, но конкретика, как это должно выглядеть, уже есть. Естественно, возникает огромное сопротивление — просто потому, что доступ к уровню 1 гораздо проще, чем к уровню 2. Люди очень хорошо видят препятствия (они есть уже сейчас), но с плохо оценивают выигрыш (его никто пока не видел). Я говорю на собственном опыте в том числе — многие вещи я очень легко пропускаю в первый раз, но начинаю ценить, когда они уже состоялись и все вокруг с ними носятся.

Кое-как я, впрочем, научился с этим работать:

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

Итого мы либо получаем оценку на основе предыдущего опыта (это уже было и выступило вот так, если вы думаете, что будет по-другому, нужно что-то делать по-другому), либо получаем, что оценку дать нельзя. Результат не очень практичный, но зато согласуется с наблюдениями. Как минимум это помогает не игнорировать идеи, результат которых может быть потенциально существенным. Т.е. мы избавились от ложноотрицательных оценок.

А дальше начинается совсем интересное. Третий уровень — никто не знает как это сделать. Но здесь хотя бы понятно, что именно сделать — т.е. понятны проблемы. Ситуация похожа на второй уровень, только конкретных предложений пока нет. Тут проходят интересные дискуссии о возможных решениях и их недостатках. Аналогично со вторым уровнем, где мы оценивали пользу, тут можно прикидывать реализуемость тех или иных подходов. Схема очень похожа, и ложноотрицательных результатов тоже надо бояться. Интересная особенность этого уровня — решения пока нет ни у кого — означает, что искать его нужно за пределами текущего комплекса знаний, out of the box. Совет:

Дискуссия на третьем уровне очень важна, потому что позволяет прогрессу двигаться инкрементально.

И наконец четвертый уровень — никто не знает, что делать. Ничего не понятно, ничего не известно. Кое-что, впрочем, и тут можно сказать:

  • Глобально хочется программы быстрее, больше, надежнее, самостоятельнее, доступнее.
  • Почти наверняка можно сделать лучше, чем сейчас.
  • В целом понятны способности человека и что надо ориентироваться на них (см. предыдущий пост).

Это совсем космический уровень и у меня не хватает эрудиции описать, что тут происходит. Именно этот уровень отвественен за качественные скачки в computer science, и он почти недостижим последовательным решением сегодняшних проблем из уровней 2–3. Один из предложенных Аланом способов, как можно работать на этом уровне:

Главное, на что я хочу обратить внимание — всегда важно понимать контекст, в котором идет обсуждение. Скажем, спор «почему C++ программистам не нужен Go» идет в контексте первого уровня — две вполне конкретные технологии, данные нам свыше. Заявление «Go был бы лучше, если бы в нем...» это уже второй уровень. Комментарии в духе «это уже есть в Хаскелле» — с первого уровня. Ответ «там не такое же потому-то и потому-то» — опять второй. Третий уровень — это что-то из серии «чисто декларативная система могла бы кардинально снизить сложность», никто такого не видел, но в принципе цель благородная. Ну или попроще — «нужна какая-то модель для программирования в распределенной конкурентной среде» :)

Еще пример: «вот что может JavaScript» — первый. «Вот так можно было бы сделать JavaScript производительнее» — второй. «Как приспособить JavaScript для написания больших программ» — третий. Этот вопрос перешел бы на второй уровень, если бы в любом другом языке эту проблему решили, кстати.

Четвертый уровень — это из серии «в будущем программировать сможет каждый», «в каждой железке будет компьютер» и т.п. Непонятны ни конкретика, ни проблемы, но хочется, чтобы так было.


  • 1
> «Как приспособить JavaScript для написания больших программ» — третий. Этот вопрос перешел бы на второй уровень, если бы в любом другом языке эту проблему решили, кстати.

Тут интересно узнать, какой объем программ вы считаете "большим". И почему, по-вашему, мнению, другие языки ее не решают (например, такие языки, как Ada, Eiffel, Java или C#)?

> Четвертый уровень — это из серии «в будущем программировать сможет каждый», «в каждой железке будет компьютер» и т.п. Непонятны ни конкретика, ни проблемы, но хочется, чтобы так было.

"хочется, чтобы так было" в совокупности с вопросом "Как приспособить JavaScript для написания больших программ" явно указывают на необходимость еще одного уровня. Чего-то вроде "никто не знает, зачем это нужно, а следовало бы знать".

> Тут интересно узнать, какой объем программ вы считаете "большим". И почему, по-вашему, мнению, другие языки ее не решают (например, такие языки, как Ada, Eiffel, Java или C#)?

Для меня после 200 строк Java (ну без учёта фетишей вроде пакетов и импортов, полного кода строк 300-400). Дальше время разработки растёт примерно как квадрат сложности. "Не решают" не совесем корректная формулировка, скорее "решают существенно хуже чем необходимо промышленности". Порог "большая" зависит от человека и немного отодвигается тренировками, но насколько я понимаю даже для олимпиадников-мутантов он в пределах пары тысяч.

> "хочется, чтобы так было" ... а следовало бы знать"

Я вчера наблюдал пример зачем. Искали с менеджером по продажам вариант продажи мне ништяка. Схема такая, он слушает мои запросы, тыкает мне в избранные места буклетика, по одобрению ищет в одной табличке ТТХ, в другой табличке цены, в третьей применимые акции/скидки/свои маркетинговые замуты, транслирует мне результаты я их переписываю на бумажку. Пропускная способность системы полбита в секунду. Нанять программиста/дизайнера/тестера чтобы сделали доменно-специфичный и удобный поисковик конторе явно не по бюджету. Наколхозить из Access/импорт/запрос? Да я зам с 10 годами опыта буду эту конструкцию день собирать и по полчаса писать запросы.

Edited at 2016-07-12 06:50 (UTC)

> Порог "большая" зависит от человека и немного отодвигается тренировками, но насколько я понимаю даже для олимпиадников-мутантов он в пределах пары тысяч.

Интересно, кто тогда создает приложения в миллионы строк кода. Причем не только на Java, C# или Eiffel, в которых это делать не так уж и сложно, а даже в C++ и в C?

Большая не значит не выполнимая. Просто цена не пропорциональна сложности.

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

Ну хорошо. Тогда в вашем представлении что такое "большие программы"?

Т.е. если программа делает много, но содержит большой объем простого кода, то это плохая большая программа? Типа большая куча кирпичей и не более того.

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

Боюсь, что серьезно на это ответить можно только "Спасибо, поржал".

Я не очень понимаю, что вы пытаетесь сказать? Что большие программы писать легко и приятно? Что в программировании нет проблем, достаточно только приложить много усилий?

Это я не могу понять, что вы подразумеваете под большими программами. Такое впечатление, что вы пытаетесь говорить о чем-то своем. Например, о том, как расширить возможности одного человека. Типа того, что сейчас для одного человека пределом является объем в 3-5KLOC в месяц (на языке вроде Java или C#). А хотелось бы раз 10 больше. Но, опять же, для одного человека.

Тогда как мне казалось, что понятие большой программы уже давно общепринято -- это программа, объем и/или сложность которой многократно превосходит возможности одного разработчика. Откуда следует необходимость командной разработки. А технические средства, которые бы сделали коллективную разработку больших программ возможными (т.е. приемлемыми по срокам и стоимости) появились, если не ошибаюсь, еще в конце 1970-х и в 1980-х годах. Это модульность и абстракция данных. Ну и, соответственно, языки программирования, которые это поддерживали из коробки. Например, Modula-2, Ada, Eiffel (хотя Eiffel в меньшей степени), Oberon. Плюс к тому сборщик мусора, который был и раньше, но именно с 1980-х мощности компьютеров выросли настолько, что широкое применение языков и сред с GC стало возможным. Именно это и стало технической основой для разработки программ в миллионы и десятки миллионов строк кода в приемлемые сроки и с приемлемой стоимостью.

Это если брать техническую составляющую. Которая, как показывает опыт того же C++, является не такой уж доминирующей. При разработке больших программ гораздо более важным являются нетехнические составляющие -- координация, распространение знаний, контроль, интеграция и пр.

Интересно вы спрашиваете у человека "какую программу он считает большой. А сами используйте термины: "приемлемый" , "многократно", "техническая составляющая", "доминирующей".
Т.е спрашивайте хуйню и хуйню порите. Это от крестов такое у вас?


  • 1
?

Log in

No account? Create an account