[Тупняк][Программазм] Неужели до сих пор нет настоящего объединённого кодинга?

Golly — многопользовательский блокнот с подсветкой синтаксиса. Но так дела не делаются, по-настоящему совместный кодинг делается в системах контроля версий.

Слушай, верни на аву азиаток с «загадочными взглядами». Не могу читать - тошнит. :)))

> Golly — многопользовательский блокнот с подсветкой синтаксиса.

Э-э-э... а не gobby разве? Для кед есть аналог - kobby. Но оба они - на движке obby, емнип.

>Слушай, верни на аву азиаток с «загадочными взглядами». Не могу читать - тошнит. :)))
Плюсую)

По сабжу: а ядро не подходит под описание?

Потому что при кодинге главное не нажимать кнопки на клаве, а думать. А средств для объединенного мышления еще не придумали.

> А средств для объединенного мышления еще не придумали.

Придумали. Называется: сначала озвучь что надумал, потом выслушай соседа, потом договорись, потом пиши.

Только вот со слушанием и с договариваемостью туго как-то.

> Слушай, верни на аву азиаток с «загадочными взглядами». Не могу читать - тошнит. :)))

Не любишь star trek?

> Потому что при кодинге главное не нажимать кнопки на клаве, а думать.

95% погромистов смотрят на тебя с недоумением.

Так тут предлагает не с одним человеком работать, а со многими. Это озвучь, что надумал, выслушай 10 человек, поспорь с ними, возьмите решение самого громко кричащего человека, пиши то, что он еще не написал, но то, что использует то, что уже написали. Такими темпами только медленнее выйдет. Из-за того, что разговаривать придется дольше, чем писать код. Накладные расходы на коммуникацию еще никто не отменял.
И еще, если 100 программистов пишут один код, то каждый программист должен быть в курсе того, что написали еще 99 человек, а это не так то просто.
Это как если бы 10 поваров готовили одно блюдо. Быстрее не выйдет.

+1

А что на меня смотреть? Я обычный д'Артаньян, такой как все.

> каждый программист должен быть в курсе того, что написали еще 99 человек, а это не так то просто

для этого гит есть

Из-за того, что разговаривать придется дольше, чем писать код. Накладные расходы на коммуникацию еще никто не отменял.

Накладные расходы на коммуникацию снижаются за счет жесткого её модерирования. А плюсы от взаимного общения сообщества при грамотной организации перекрывают эти мелкие расходы с лихвой.

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

>Придумали. Называется: сначала озвучь что надумал, потом выслушай соседа, потом договорись, потом пиши.

Здравствуйте - мы принесли вам благую весть!

>для этого гит есть
Учебник по квантовой электродинамике тоже есть. Как хорошо ее знаешь? 99 человек если напишут просто по 10 строк кода, это будет изучение 990 строк кода в день. Стандартная машинописная страница это 30 строк. В день придется изучать 33 страницы только нового кода, вырванного из контекста. И еще самому писать код между прочим.

Накладные расходы на коммуникацию снижаются за счет жесткого её модерирования. А плюсы от взаимного общения сообщества при грамотной организации перекрывают эти мелкие расходы с лихвой.

Чукча писатель? Читай топик. Имелось в виду не программирование командой, а одновременное совместное программирование.

Вкину свои пять копеек личного мнения. Ускорить совместную разработку в разы практически невозможно без зонда с интеграцией человеков в некий супер-разум. Шучу.

Лично я считаю, что нужно повышать емкость программ и делать максимально очевидные интерфейсы. В идеале, чтобы несколькими очевидными для человеческого восприятия командами можно было рулить большими структурами. В перспективе описание логики программы на пиджин-инглише. Это не Ъ, но в принципе разработку должно ускорить.

Я как-то пытался писать плагин для vim - infinoted/gobby, но забил. Есть плагин для Gedit и Emacs

Ну вот совершенно тупо, первая ссылка в гугле: http://ru.wikipedia.org/wiki/Гибкая_методология_разработки

++

> Э-э-э... а не gobby разве?

Ой, перепутал, да.

> Слушай, верни на аву азиаток с «загадочными взглядами». Не могу читать - тошнит. :)))

Тут одно видео есть, как раз в тему: http://www.youtube.com/watch?v=cqen8H1PNzw (там есть азиатки)

http://ithappens.ru/story/7693

3. Совместно работающие программисты подчиняются правилу сложения источников белого шума: суммарная эффективность равна корню из их числа.

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

>Есть ли годные подходы для многопоточного дружного программирования?


через 3 часа от разговоров голова заболит и внимание начнет рассеиваться

>Накладные расходы на коммуникацию снижаются за счет жесткого её модерирования.

Простое решение. Рулить будет бот, принимая решения след. развилки рандомом.
Плюсы:
1. Скорость, спорить будет некогда, ибо рандом, что тут спорить
2. Больше опыта будет накапливаться

минусы: качество софта снизится
Усложнённое решение: бот с небольшим AI
Сложное решение: каждый предлагает свой вариант, если у него есть, а бот уже рандомом...

> Не любишь star trek?

Да не в стар треке дело... :)

> минусы: качество софта снизится

А ведь есть некая доля вероятности того, что качество софта таки повысится. :)

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

Не спорю.

Ох, тут лучше обойтись без патентов или сразу запатентовать, ибо в далёёком будущем может сильно насолить такое