?

Log in

No account? Create an account
Previous Entry Share Next Entry
photo25

Как культуры разработки борются за место под солнцем

Почему в больших компания пишут на Java и пытаются породить Java-подобные языки (Dart, например)?



Собственно, потому, что гибкость дает преимущество небольшим коллективам из хороших разработчиков, а жесткость, шаблонность и т.д. - большим коллективам из средненьких и плохих разработчиков. Так и живем.

Оригинал взят у tonsky в Расширяемость

Ковырялся я тут на досуге во внутренностях react.js, и вот что я хочу сказать вам о JavaScript вообще.

Я познакомился с JS когда это был вполне себе простой и понятный язык. Раз: любому объекту в любой момент можно добавить любое свойство, и два: один объект может иметь прототипом второй, тогда свойства ищутся по цепочке. Всё. Конечно, эта кажущаяся простота нелегко давалась разработчикам компилятора, но нам-то, пользователям, было хорошо. Просто и гениально. Я как-то недостаточно наблюдал восторгов по поводу красоты концепции.

Реализация кое-где хромала, конечно. Свойство prototype, к примеру — не путать с идеей прототипов — настоящий бред. Если бы его быстренько — ну, в ES3 там, или раньше — зафиксили, народ бы не ныл и не просил классов. Ну или использование объектов как структуры данных-словаря, до сих пор эпичнейшие баги всплывают, типа того что на npm нельзя создать библиотеку с именем constructor. Мне кажется, именно из-за этого JS-программистов и следом вообще всю frontend-разработку не считают за «настоящее» программирование.

Но реализация — дело наживное. Главное, что языку больше ничего и не надо. Можно стандартную библиотеку доделать, добавить массивы и словари настоящие, и можно вполне писать. Питон как-то так и работает, и много что на нем можно сделать.

Я веду к тому, что в таком состоянии у языка появляется очень важное свойство — безумная, просто неконтролируемая расширяемость, какая даже рубистам не снилась. Настоящая расширяемость, модифицируемость — это не когда вам дали два гнезда и вы можете воткнуть в одно — функцию, раскрашивающую вывод, а во вторую константу, отвечающую за размер буфера. Расширяемость, в том виде в каком к ней надо стремиться — это возможность взять вещь, посмотреть как она устроена, разобрать, что-то вынуть, что-то поставить свое. Утиная типизация, подсовывание своего объекта вместо чужого, все ручки на виду и перезаписываемые. При проектировании под расширяемость надо учитывать ровно одну вещь — что ты понятия не имеешь, кто и что с твоей библиотекой захочет сделать.

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

Это приводит к тому, что почти всегда библиотеку на Кложе можно понять и можно заставить делать то, что нужно. Очень трудно загнать пользователя в угол, если только специально не прилагать усилий. Это важно, и я рад, что Кложе-сообщество подхватило этот тренд.

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


Не надо так.




UPD: Пишут, что в дарте есть мирроры. Это, мммм, интересно. Будем посмотреть, может и чего хорошего вырастет.

  • 1
jakobz January 29th, 2015
Ну хз. Если в JS менять чужие прототипы, и прочее - это же ад и кишки будут. Это не функциональный язык. Эта хреновина мутирует стейты, часто - асинхронно, при этом работает в адовом окружении, где ничего нельзя сказать точно.

Поэтому - я все-таки за затаскивание практик "больших" языков. Не только из C# с явами, но и из кложей и хаскелей тоже.

А вот конкретно реакту - не помешало бы немного вывернуться наружу, и стать ближе к тому же https://github.com/Matt-Esch/virtual-dom Но они примерно туда и едут вроде, по крайней мере от createClass своего вроде отлепились, и VDOM вроде как стандартным и простым сделают. Это хорошо.

tonsky January 29th, 2015
Мне не очень понятно, почему большие коллективы не примут какие-то такие практики http://pixelscommander.com/en/javascript/nasa-coding-standarts-for-javascript-performance/

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

Другое дело что для этих практик нужно усилие, а ад — он сам собой получается.

mr_aleph January 29th, 2015
в жесткий шаблонный Dart https://gist.github.com/mraleph/c8f91b1cc2fbd999728f upd. вынес код в гист, дабы не растягивать комментарии

Edited at 2015-01-29 12:30 pm (UTC)

wizzard0 January 29th, 2015
Мммм, мирроры - это хорошо!

Спасибо.

bvlb January 29th, 2015
"гибкость дает преимущество небольшим коллективам из хороших разработчиков, а жесткость, шаблонность и т.д. - большим коллективам из средненьких и плохих разработчиков."

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

gineer January 29th, 2015
Тут весь вопрос в том... что считать гибкостью

Есть два варианта:

написать все самому, с нуля

заююзать какие-то готовые либы, паттерны

dmih January 29th, 2015
Ну я примерно за это люблю PHP и постоянно пишу на нем, где хоть функции в цикле описывай.
И очень нервничаю, когда его двигают к "серьезному языку", выбрасывая все преимущества безбашенного метапрограммирования. В этом смысле на 100% согласен с тем же поинтом и для JS - не надо из него делать Java.

Но, говорить о том, что это вообще какая-либо ЗАМЕНА нормальному языку, это как-то непонятно. Очевидно есть проекты, где это всё очень неудобно. И есть проекты, которые в принципе на таком языке писать бессмысленно. И мне всё-таки кажется, что выбор инструмента это не функция от качества команды, а именно на 80%, всё-таки, подходит или нет.

gds January 29th, 2015
> разработчику библиотеки виднее, что выставлять наружу, а что нет

но это именно так. Модульность нужна везде. Интерфейс библиотеки -- контракт: соблюдаем его, и автор библиотеки гарантирует, что библиотека тоже его соблюдает.

gineer January 29th, 2015
\\Собственно, потому, что гибкость дает преимущество небольшим коллективам из хороших разработчиков

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

wizzard0 January 29th, 2015
1) поддержка продукта на длительных интервалах времени зависит прежде всего от документации; (где тесты или coding convention - тоже документация)
2) количество ошибок на LOC слабо зависит от выразительной плотности кода;

соответственно у нас есть 4 ситуации, а не две:
- рыхлый код, плохие доки (худший случай)
- рыхлый код, хорошие доки ("медленно, но уверенно")
- плотный код, плохие доки ("быстро, но потом неподдерживаемо")
- плотный код, хорошие доки ("быстро и вполне поддерживаемо")

т.е. да, серебряной пули не бывает, но и с твоей позицией я тоже не согласен.

gineer January 29th, 2015
Еще бы добавить два варианта,
чтобы все было как у людей,
а именно:
документации нет (код самодокументируем)
и
быдлокод.

И что это все может быть в рамках одного и того же проекта... слоями. :))

wizzard0 January 29th, 2015
Самодокументируемого кода не бывает. Бывает привычная coding convention.

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

Edited at 2015-01-29 06:37 pm (UTC)

gineer January 29th, 2015
Ну, "должны быть" не означает что так и будет.
Не нужно недооценивать идиотов. (С)

А так,
собственно, я не спорю с твоей позицией,
просто дополняю её... для полноты.

А то,
"в теории, теория и практика не отличаются" (С)

wizzard0 January 31st, 2015
> Words define, specify, contracts, and rules (and others) are all important. People can't RTFM unless there is a manual. Nearly every interface has a rule that, if broken, causes results to go haywire, causing a crash or merely nonsense in output. Crashing is easy in low level languages; nonsense is easy in high level languages. Part of design is explaining the rules. A story about usage can be effective, because people like stories, and remember them. I was going to include some fictional dialog as example, but I won't unless this sub-thread goes on. Conversations are much more interesting than plain vanilla docs.

Отличное лента принесла;)

gineer January 29th, 2015
Я вижу здесь большое сходство с работой программистов - точно так же не все идеи удается воплотить (многие слишком трудоемки), не всякая работающая программа оказывается кому-то нужна, а получивший популярность софт начинает жить своей жизнью, становясь большей реальностью, чем задачи, под которые он когда-то создавался.

http://schegloff.livejournal.com/928265.html#comments

  • 1