Здравствуйте, FR, Вы писали:

FR>С того что разговор шел про это

цитирую:

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

А остальным это почему-то не мешает. Может быть, ты просто ищешь обоснования решению, которое ты и так уже принял, не задумываясь об этом? Это очень известное явление в психологии

FR>пока ты не влез.

А что, здесь мнения принимаются только от ограниченного круга лиц? И кто определяет этот круг?

Здравствуйте, Cyberax, Вы писали:

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

C>1. Поддержка работы в автономном режиме, без какой-либо runtime-библиотеки.
C>2. You don't pay for what you don't use.
C>3. Возможность оптимизаций до уровня корпуса компьютера (в том числе
C>работа без GC).
C>4. Возможность системного программирования.
C>5. Широчайшая портабельность (в том числе, например, на архитектуры с
C>36-битными процессорами).

Это не "идеи языка", это "особенности реализации". Сам по себе язык не мешает внедрить любую из этих фич. Хотя для этого нужно отвязываться от CLI, а решить задачу создания равного по функционалу рантайма — это дьявольски сложно.

Здравствуйте, VladD2, Вы писали:

E>>Я, например.

VD>Ты? А не ты ли тут расхваливал Руби рассказывая как ты на нем залудил замену мэйк-у?

Там нет ни грамма изменения синтаксиса языка. Ни одного нового ключевого слова или конструкции в язык добавлено не было.

Здравствуйте, VladD2, Вы писали:

VD>Здравствуйте, PhantomIvan, Вы писали:

E>>>Угу, в распечатке.
PI>>никогда не печатал проги... хотя попробую, может это прикольно...


VD>:))) Я плякаль...

VD>Вообще на лицо столкновение поколений. Одно всю жизнь возилось с простынями кода и тупо не приняло мир IDE и автоматизации, а второе никогда не видело простыни от ЕС-ки.
VD>Тут понимания никогда не достичь. Самое обидное, что я вас обоих понимаю.

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

Никакие браузеры и суперредакторы с подсветками и свёртками не дадут такого удобства для _анализа_ текста программы.

Ну а потом можно и в IDE лезть — для набивки, компиляции и отладки. Там, где он, разумеется, применим:) С моими сетевыми демонами толку от него как зайцу от стоп-сигнала...

В общем, каждому овощу своё место. И где ты нашёл невозможность понимания — ХЗ.

P.S. Кстати о ЕС'ках: простыни — понятно, но 80-е годы были уже временами массового распространения IDE, хоть они так и не назывались. Primus, JEC, Vector и прочие — чем они существенно хуже современных IDE? Показать ошибку не могут — это да, приходилось распечатку вывода компилятора ловить с принтера. А отредактировать текст не выходя из редактора, сохранить, запустить задание компиляции, то же — выполнения, сформировать данные на входе, посмотреть данные на выходе (если поданы в раздел библиотеки, сиречь файл по тогдашнему) — всё было.

Здравствуйте, VladD2, Вы писали:

E>>Дай бог, чтобы так и было. Чтобы какой-нибудь умелец не захотел сделать более продвинутый Nemerle.Concurency.async, чем в стандартной библиотеке.

VD>Даст бог и найдутся множество умельцев которые реализуют множество вариаций Nemerle.Concurency. Тогда я смогу выбрать лучшую, а может быть склею из нескольких то что нужно именно мне.

Ну посмотри на количество библиотек поддержки многопоточности для C++ и попробуй выбрать лучшую.
Хочешь такого же для Nemerle?

Здравствуйте, VladD2, Вы писали:

PI>>>в немерле ответ на "шо це таке" обычно получаешь при наведении на икс и получении хинта

E>>Угу, в распечатке.

VD>Ой, а можно уточнить как часто ты печатешь код? И в каких объемах?

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

Здравствуйте, PhantomIvan, Вы писали:

M>>>>А кто будет эту спеку писать ?

PI>>>спеку пишет архитектор

К>>И чем дольше цепочка, тем проще она рвётся

PI>еще раз повторяю, вы тут не со мной спорите, а с Бруксом — Брукс говорит

Брукс говорит

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

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

PI> исключительно о сложных, больших, стабильных промышленных системах (OS/360 тому пример)
PI>из этих характеристик с необходимостью следует, что составные части системы должны быть тщательно протестированы
С этим собственно никто не спорит.

PI>с необходимостью следует, что эти системы не может разрабатывать кучка гениальных универсальных программеров команды из нескольких сотен специалистов — это то количество, на котором
PI>ваши насмешки
???
Кстати про несколколько сотен специалистов
Брукс продолжает там же :

Это также
наводит на мысль, что желательно разрабатывать системы возможно меньшим
числом людей.

С чем я абсолютно согласен.

PI>должны смениться как минимум уважением к людям, которые смогли "заставить это работать",
Дык собственно на Брукса никто и не неезжал.

PI>потому что agile-методологии очень вряд ли с этим смогли бы справиться
Доказательства ? Есть подозрение что "тяжелые" методологии в неумелых руках погребли бы проект под кучей никому не нужной документации. А в умелых руках и "agile" принесли бы свои плоды.

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

Итак, насчет бюрократизированных технлогий.
Опять же Брукс.

Вывод прост: если над проектом работают 200 человек, включая
менеджеров, являющихся наиболее знающими и опытными программистами, увольте
175 бойцов, и пусть менеджеры снова займутся программированием.

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

Далее

В этом и состоит изъян идеи маленькой активной команды: для создания
по- настоящему крупных систем ей потребуется слишком много времени.

Спорить бессмысленно имхо.

PI>а обсуждать "операционные бригады" Брукса, не понимая (забыв), в чем их суть — недостойно
До сегодняшнего утра я помнил, что есть главный хирург, и ему помогает команда, которая обеспечивает всяческую поддержку. Но в свете последнего поста решил освежить память

А теперь к операционным бригадам.

Предложение Миллза

Предложение ИМХО не эвиватентно догме.

... Чтобы нарисовать картину работы такой команды с включением всех мыслимых видов поддержки, я позволю себе вольное обращение к метафорам.
Хирург. Миллз называет его главным программистом. Он лично определяет
технические условия на функциональность и эксплуатационные характеристики
программы, проектирует ее, пишет код, отлаживает его и составляет документацию.

Хм. Ты действительно был прав здесь Re[18]: MIT переходи со схемы на...

Автор: PhantomIvan
Дата: 22.11.06

, признаю.

Но все же позволю себе рассмотреть идею операционных групп в том случае если это не система уровня OS/360, а чуть поменьше. С некоторыми замечаниями от себя.

Второй пилот. Это второе "я" хирурга, может выполнять любую его работу,
но менее опытен. Его главная задача — участвовать в проектировании, где он
должен думать, обсуждать и оценивать... Часто второй пилот представляет свою бригаду при обсуждении с другими группами функций и интерфейса.

А если операционная группа одна ?

Он хорошо знает весь
код программы.

Весь код? ВСЕЙ системы уровня Os/360 ?
Или все же своей части ? Вернее части своей бригады. Дык в "agile" методологиях, это требование распространяется на всех программистов. Впрочем, я думаю в тяжелых тоже.

Он может даже заниматься написанием кода, но не несет
ответственности за какую-либо его часть.

Мммм... Ээээ. Написание кода без ответсвености ? Is no good.
Хотя возможно здесь подразумевается, что конкретно на него задачи никакие не ставятся.

Администратор. Хирург — начальник, и ему принадлежит последнее слово в
отношении персонала, прибавок к жалованью, помещений и т.п., но на эти дела
он должен тратить как можно меньше времени.

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

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

Насколько я вижу, администратор — аналог ПМ-а.

Редактор. Обязанность разработки документации лежит на хирурге. Чтобы
она была максимально понятна, он должен писать ее сам. Это относится к
описаниям, предназначенных как для внешнего, так и для внутреннего
использования.

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

Задача редактора — взять созданный хирургом черновик или
запись под диктовку, критически переработать, снабдить ссылками и
библиографией, проработать несколько версий и обеспечить публикацию.

К обязанностям и без того загруженного хируга добавилась диктовка,или составление черновика для редактора. А помимо этого наверняка еще и проверить, что получилось из документации после "критической переработки". То есть для большой системы я уверен, что будет целый штат документописателей, ака редакторов, но для маленькой команды я сомневаюсь в необходимости такого человека. Как делается у нас. Документация(юнит тесты, комментарии к методам, классам, из которых автоматически генерируется .chm с документацией) пишется программистами. В то время, как они работают над конкретной задачей. Если что-то меняется, то за обновление документации отвечают тоже программисты. Если бы был редактор, то ему пришлось бы объяснять что именно изменилось, на что именно изменилось, этц. Дополнительная бюрократия и потеря времени. Повторюсь, для проектов меньших, чем Os/360. После того, как программисты обновят документацию, проводится review, во время которого проверяется и код, и комментарии к нему, и юнит тесты. Если находится какой-то несоответствие, на программиста вешается баг в багтрекере. Можешь не верить, но такая система действительно работает. Потому что программисту проще написать хорошую документацию один раз, чем через пару месяцев мучительно вспоминать, что же там было, для того, чтобы самому вспомнить или кому-то объяснить.

Два секретаря. Администратору и редактору нужны секретари. Секретарь
администратора обрабатывает переписку, связанную с проектом, а также
документы, не относящиеся к продукту.

Я не знаю, как было в 1975 году, может действительно нужны были секретари. Сечас на роль секретаря вполне подойдет Outlook или его аналог.

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

Svn? Cvs? SourceSafe?

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

К выделенному однозначно +1.

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

Для выделенного мы используем юнит тесты.

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

Я не знаю что такое каталогизированные процедуры, но специализированные утилиты и макробиблиотеки(компоненты?) в сегодняшних реалиях чаще всего используются готовые.

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

Тестер ?

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

Вообще идея конечно хорошая. Но что мешает хорошему программисту быть языковедом ?
А еще есть rsdn.ru, google, которые обеспечивают доступ к практически неограниченному коллективному разуму.

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

Выделенное даже не хочется комментировать.

а также обеспечивает концептуальную целостность продукта.

Концептуальную целостность продукта обеспечивает архитектура и постоянные Review.

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

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

В хирургической бригаде различий интересов нет, а
разногласия единолично решаются хирургом. Эти два различия — отсутствие
разбиения задачи и отношение подчиненности — позволяют хирургической бригаде
действовать uno animo.

Как я говорил выше, различий интересов у нас тоже нет, у нас есть цель сделать продукт, а не самоутвердиться. Поэтому вся команда действует uno animo.

В статье Бейкера3 сообщается об одной проверке такой концепции бригады,
проведенной в ограниченном масштабе. Как и предсказывалось, результаты
оказались великолепными.

Не совсем понятно что значит "в ограниченном масштабе". А если бы результаты не оказались великолепными, то и статьи бы не было скорее всего.
BTW в библии XP Кента Бека, описывается большой проект C3, успешно завершенный при помощи XP. Я уверен, что и для RUP такие примеры найдутся.

Масштабирование
...
Успех при масштабировании обусловливается коренным улучшением
концептуального единства каждого участка, ведь количество проектировщиков
уменьшилось в семь раз. Поэтому можно привлечь к работе над задачей 200
человек, и необходимость координации умственных усилий потребуется всего для
20 из них — хирургов.

Правильно разбейте задачу на подзадачу и будет вам счастье. Если я правильно понял.

Iтогi падведьом..(с) Лесь

Если из операционной команды Брукса удалить языковеда, редактора, двух секретарей, интсрументальщика и делопроизводителя, то в сухом остатке будет.

Хирург, помощник хирурга, отладчик, администратор.
Или в переводе на мою систему ценностей : хороший программист, хороший программист, тестер, ПМ.

Учитывая, что по Бруксу тестеры и ПМ-ы могут разделяться между несколькими командами,
систему по которой работаем мы, можно представить как 2 команды из 2-х программистов, тестеры, ПМ.

На основании этого я считал, что работаю в команде, аналогичной операционной бригаде Брукса. Но с учетом сегодняшних реалий.

Возможно я не прав, что ж поделать.

ЗЫ. Брукс — ЧЕЛОВЕЧИЩЕ, но к любые методологии и идеи необходимо критически оценивать.

Здравствуйте, PhantomIvan, Вы писали:

PI>по крайней мере, о какой цепочке речь идёт я не понял, если структура большой команды — иерархическая, с архитекторами во главе

И? В иерархии нет цепочек? Тут Mirrorer всё рядом уж совсем по полочкам разложил
Речь о цепочке от "автора идеи" до того, кто реализует и применяет.

Здравствуйте, PhantomIvan, Вы писали:

PI>и тем более недостойно вести себя в стиле "не согласный я! с обоими!"
В соседнем посте я позволил себе покритиковать операционные бригады со свойственной мне "космической же глупостью"

PI>по крайней мере, о какой цепочке речь идёт я не понял, если структура большой команды — иерархическая, с архитекторами во главе
В начале соседнего поста.
кратко — цепочка (архитектор-программист-тестер) длиннее чем (программист) или (архитектор-программист). Поэтому рискну дать "совет космического масштаба" и возможно "космической же глупости". При возможности, цепочку общения необходимо сокращать.

ЗЫ. Скорее всего идея не моя, и где-то уже проскакивала.

Здравствуйте, VladD2, Вы писали:

VD>Здравствуйте, FR, Вы писали:

FR>>Подкручивание в питоне реализованно так что тормозов не будет, метаклассы работают аналогично compile time для языков со статической типизацией.

VD>Оно делается во время компиляции в байткод? Что-то не верится. Да и откровенно говоря не верится, что при подобном подкручивании не будет проблем в других местах. У той же IDE обязательно крышу снесет.

Оно будет делатся при инстанцировании класса (не создание объектов класса а именно при создании самого класса). Обычно это происходит при первом импорте модуля.

FR>>В случае питона метаклассы и подобные вещи не имеют ничего общего с текстуальными макросами,

VD>Из твоих примеров я сделал обратный вывод. Возможно что я конечно ошибаюсь.

Странно что ты сделал такой вывод, примеры были очень близки к примерам от создателей немерле.

FR>> и информация о типах и даже полная интроспекция в них вполне доступны.

VD>Вот это уже точно фигня. Попробуй напирмер реализовать мета-код аналогичный моему макросы SupportRelocation:
VD>http://nemerle.org/svn/nemerle/trunk/macros/compiler.n

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

VD>В лучшем случае ты прийдешь к рантайм-интерпретации. А это по скорости равносиельно использованию рефлексии в дотнете.

Ты просто не хочешь понимать что я тебе уже объяснял, это аналог compile time выпролняется только при создании класса и не влияет на скорость работы объектов этого класса.

FR>>Проблема в том что реально измерить мощность языков очень тяжело, оценка во многом получается субъективной.

VD>Тяжело. Не спорю. Нр я стараюсь быть объективным.

Угу стараешся

FR>>Мне кажется ты чуть выше очень правильно описал свое понимание динамики:

FR>>

FR>>И от того тебе кажется, что что-то не важно, а что-то является всего лишь непонятным извращением.

VD>Тебе кажется. Со всем о чем я веду речь я работал. Я конечно могу ошибаться в частностях (какой язык на каком уровне реализует ту или инуб возможность). Но я пточно понимаю о чем идет речь. В цитате же говорится о непонимании обсуждаемых вещей.

Дьявол он в деталях
Я пока сам плотно не поработал с динамикой был примерно такого же мнения о ней как и ты.

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

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

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

VD>Я не хочу возвращаться к "Статика вс. Динамика". В данном случае я указавал на совокупность возможностей (которую Грэхем назвал континумом). И на то что она у Немерла на сегодня объективно больше.

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

VD>От того я им и занимаюсь. Причем как бы не хотелось злым языкам вроде еао197 это представлять в виде пропаганды, в отличии от них я пытаюсь быть объектвным и реально работаю над увеличеним возможностей языка и их качества. Наша Интеграция со Студией — это реальный вклад. И делаю я его потому, что отчетливо понимаю перспективность языка и то, что без нашго вклада он так и может остаться "перспективным чудом" вроде ОКамла или Лиспа.

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

Здравствуйте, VladD2, Вы писали:

VD>Здравствуйте, FR, Вы писали:

FR>>Питон тоже позволяет и даже добавлен и даже до того как на свет появились Скала и Немерле

VD>Раз так, то было бы интересно и полезно если кто-нибудь (не будем показывать пальцем) описал бы его возможности. Провел бы тесты. И привел бы примеры исползования. Если бы это было оформлено в виде статьи, то было бы вообще круто.

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

Здравствуйте, AndreiF, Вы писали:

AF>Здравствуйте, FR, Вы писали:

FR>>С того что разговор шел про это

AF>цитирую:
AF>

AF>Но я бы игрался в качестве хобби с немерле намного активнее и скажем так даже пропогандировал его здесь и в других местах, если бы Влад не вел себя так как ведет

AF>

AF>А остальным это почему-то не мешает. Может быть, ты просто ищешь обоснования решению, которое ты и так уже принял, не задумываясь об этом? Это очень известное явление в психологии

FR>>пока ты не влез.

AF>А что, здесь мнения принимаются только от ограниченного круга лиц? И кто определяет этот круг?

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

Здравствуйте, VladD2, Вы писали:

VD>Здравствуйте, FR, Вы писали:

FR>>Для икс это плохо, посмотри ту же тему про D, если бы там не было горлопанов от немерле было бы гораздо лучше для всех, вместо этого получилась очередная тема-помойка.

VD>Для икс плохо не это. Для икс плохо, что он родился одновременно с языками которые лучше чем он.

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

VD>В свое время я читал историю одного культуриста, который и сейчас дал бы фору очень многим, но он стал мистером олимпия (высшее достижение в этой области) только один или два раза. И все почему? Да потому, что рядом был теперешний губернатор калифорнии. И он был объективно лучше.

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

VD>Та же фигня с Ди. Если бы он родился в 85-ом, то уверен, что С++ не прожил бы и года.

Очень спорно, у C++ были тогда достойные конкуренты (тот же objective C) но стал популярным именно C++.

FR>>Так может стратегия "все в дерьме, одни мы в белом" ущербна и стоит ее пересмотреть?

VD>Стратегия в другом. Стратегия подогревать ваще желагия кидаться какашками попутно крича слово Немереле.

Давай я буду лезть в каждую тему про немерле и пропагандировать там например рефал(как малоизвестную тут вещь), как скоро тебя станет тошнить об любого упоминания о рефале?

Здравствуйте, VladD2, Вы писали:

VD>Здравствуйте, FR, Вы писали:

FR>>Нет ты совсем ни причем, во всем виновата твоя манера поливать все кроме твоих любимых игрушек грязью.

VD>Да, нет. Я тебя сто раз ловил за спором со мной когда ты был вполне со мной согласен. У вас ребяты барекадная болезнь. Вы не привыкли мыслить без стада.

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

FR>>Если бы у тебя не было такой привычки, то у тебя был бы еще один (скорее больше) активный стороник Немерле в моем лице.

VD>Ну, ты еще не потерян для общества.
VD>Вот не делил бы мир на полюса и вообще было бы замечательно.

Тут не делить уже не получится

Здравствуйте, VladD2, Вы писали:

VD>Здравствуйте, FR, Вы писали:

FR>>DirectX и без COM был бы не хуже.

VD>DirectX был бы плох на чем бы его не сделали. Его проектирвоали маньяки.

До восьмой версии да, дальше вполне терпимо.

VD>Надо будет глянуть, что МС приготовил на замену Менеджед обертки для него.

Вроде чуть лучше но тоже не шедевр.

Здравствуйте, PhantomIvan, Вы писали:

PI>>>так, вношу три замечания:
PI>>>0. я так понимаю, имеется в виду Влад, ну то понятно

FR>>не только

PI>а кто ещё? WolfHound? я?

Давай обойдемся без списков врагов народа

FR>>Для икс это плохо, посмотри ту же тему про D, если бы там не было горлопанов от немерле было бы гораздо лучше для всех, вместо этого получилась очередная тема-помойка.

PI>>>я предлагал создать отдельный форум для Немерле... 2 раза... но этот нехороший Влад...
PI>он меня ещё в других темах обижал




PI>короче, сейчас я начал одну систему на немерле, которая прямо скажем, укладывается лучше в динамику, и вроде как, только в неё.
PI>посмотрим, что из этого получится... если совсем плохо будет, попробую лисп (схему? template haskell? другую динамику?) :

haskell не динамика. Проще всего питон или руби.

PI>в любом случае, самой сущности (essence) динамики я не понимаю




FR>>Так может стратегия "все в дерьме, одни мы в белом" ущербна и стоит ее пересмотреть?

PI>по моим наблюдениям, императивщики более приземленные, сидят максимум на .net-разделе в форуме, и не дергаются зря

А в C++ разделе кто сидит?

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

А приверженцы динамики не могут быть еще и функциональщиками?

PI>среднему кодеру нужен серьезный пинок под зад (бутсой хотя бы билли гейтса, не меньше), чтобы он хотя бы туториал с сайта немерле прочел, я уж не говорю прохавал фишку ФП
PI>хотя я гоню (слишком пессимистичен) — например, я знаю софт-контору (хорошая репутация в моем городе), их отдел по исследованию и внедрению нового в программировании давно знает о немерле... я подозреваю, что они там сидят ждут, когда мы тут интеграцию долабаем... (а компиляторщики заявят "проверено, багов нет")

PI>если посмотреть на вещи более оптимистично, может быть
PI>- функциональщики (более приверженные к динамике — традиционно так сложилось) увидят, что на статическом типизировании теряется не так уж много гибкости (естественно, нужно менять стиль)

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

PI>- статические чуваки, такие как я, может быть, поймут что в цепочке ...-> nemerle -> ... следующий шаг — чистая динамика (кто знает, такой вариант тоже есть, хотя пока что я очень сомневаюсь)



PI>- какая-нибудь контора размером больше 100 человек наконец прохавает, что nemerle — это оно, и поможет зацепить язык за инструментарий (вплоть до asp.net-рельс) и стабилизировать эти средства, а мы вместо этого займемся собственно использованием языка, и исследованием пределов его возможностей (пока особо не видно)
PI>- ну, само оптимистично, это конечно, что рсдн-комьюнити наконец прохавает фишку "монолитности" в чем бы то ни было, будь то создание систем на одном и том же языке/среде, а не на россыпи технологий (прикручивая php к си, к примеру); или контрибьюшен к немерле, выносящее язык в положение "русского" языка (когда можно было бы говорить, что Немерле родом из Польши-России)

PI>да и вообще здешний рсдн мягко говоря, агрессивный — вместо того, чтоб рассказывать, кто где как что успешно использовал, бесконечный спор про то, как хрен редьки не слаще
PI>за другие сайты говорить не буду, но в конференции немерле тон спокойно-деловитый, например
PI>язык длиннее рук?

Просто в конеренцию немерле не пролезли пропагандисты других языков

PI>>>ну, думаю, он вас использует для грязного пиара этого языка

FR>>Толку то.

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

У многих рефлекс на агрессивную рекламу.

Здравствуйте, Kisloid, Вы писали:

K>Здравствуйте, eao197, Вы писали:

E>>Угу, в распечатке.
E>>А попробуй ты с ходу сказать какой тип будет у переменной result:
E>>

E>>#pragma indent
 
E>>using System
E>>using System.Console
E>>using System.Math
 
E>>def makeDistrib(trxCount : int, quantums : int)
E>>    mutable r : list[int] = []
E>>    mutable remainingTrx = trxCount
E>>    mutable remainingQuantums = quantums
E>>    foreach (_i in [1..quantums])
E>>        r ::= Round((remainingTrx :> double) / remainingQuantums,
E>>                MidpointRounding.AwayFromZero) :> int
E>>        remainingTrx -= r.Head
E>>        --remainingQuantums
E>>    r.Rev
 
E>>def result = makeDistrib(2, 6)
E>>WriteLine($"$result")
E>>

E>>не прибегая к помощи IDE.

K>Без помощи IDE только по этому коду могу предоположить, что list[int], правильно?

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

M>кратко — цепочка (архитектор-программист-тестер) длиннее чем (программист) или (архитектор-программист). Поэтому рискну дать "совет космического масштаба" и возможно "космической же глупости". При возможности, цепочку общения необходимо сокращать.

в огромных проектах там из архитекторов цепочка, потом из программеров цепочка, тестеры сбоку и т.п.
нужно не цепочки сокращать, нужно, по мнению Брукса, четче разделение функций между специалистами проводить

(скиппед)

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

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

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

Здравствуйте, PhantomIvan, Вы писали:

PI>но ты должен понимать, что Брукс говорит, об огромных проектах с неизбежной и необходимой бюрократизацией, где даже в существующих условиях поднять производительность можно, снабдив каждого программиста парой-тройкой вспомогательных людей
+1
Просто я считаю, что необходимо минимизировать количество связей на одного человека.
Иногда без их увеличения не обойтись, но если от них можно избавится, то нужно стараться это делать.
В принципе программист и так снабжен парой тройкой вспомогатлеьных людей- админы, тестеры, пм, может еще кто.
PI>и ты должен понимать, что на маленьких мобильных командах никакие законы Брукса не выполняются (за исключением основных) в таких командах попросту пофиг, какая там методология выбрана для разработки
Я больше скажу Пофиг и методология, и светлость голов, до тех пор, пока есть необходимый результат. Имея готовый движок для создания веб-магазинов, и требование создать не особо сложный магазин, можно посадить студента и дизайнера и получить замечательный результат.

PI>- все решает человеческий фактор, чем "светлее" головы тем лучше
+1

PI>и все равно, результат будет тот же — продукт сделан относительно в срок, стабилен, целостен
Эх, если бы всегда так было

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


PI>наверное, ни ты, ни я в таких проектах не принимали участие, поэтому не видели огромных жоп огромных проектов
Я видел огромные жопы небольших проектов. Не думаю что для разработчиков оно будет сильно отличаться. А для организации да, денег будет потеряно много.

PI>вот поэтому Брукс — человечище, благодаря своему (теперь классическому) труду, хоть как то оперирующим понятием "huge" проект, и обсуждающим фундаментальные социально-сложностные ограничения, лежащие в основе вышеупомянутых жоп (провалы в этой сфере довольно часты, надо полагать)
В целом +1, но провалы как были при Бруксе, так и продолжаются сейчас. В этом не Брукс виноват само собой Но факт остается фактом.

В общем того, этого