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

EC>>Т.е. тебе нет разницы какой код сопровождать: просто плохой или изощрённо плохой?

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

VD>А тебе я сочусвую. Я бы просто не стал выбирать из плохого и очень плохого.

Тебя опять подводит знание русского — с чего ты взял, что передо мной стоит подобный выбор? Потому, что я считаю, что плохой код сопровождать труднее?

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

Опять какие-то домыслы — я здесь ниразу не озвучил своё отношение к макросам. Видимо Nemerle благотворно влияет на способность фантазировать и читать между строк, что ты постоянно мне приписываешь мысли, которые я не высказывал.

VD>Это заставляет писать код без IDE. Да и не еао197 об этом говорить. Он вообще пишет код без приличной IDE и на языках где до рантайма о типах вообще ничего сказать нельзя. Они все у него в подсознании.

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

VD>Чья бы кобыла мычала.

Опять те же симптомы — я ничего не имею против Nemerle, более того я искренне желаю ему успеха, мне просто хотелось бы более уравновешенного диалога о нём, а не постоянного упоминания его к месту и не к месту, что только раздражает, как безвкусная реклама пива по телику.

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

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

EC>>В сообщении говорится, что Влад отрицает, а не Nemerle

VD>Цитаты, плиз, того что я отрицаю.

Ещё раз — в том сообщении сказано, что ты отрицаешь:

Влад, ты не понимаешь сущности. В пропаганде чего-то нового ты действуешь как типичный science-freak, говоря что все предыдущее — это полная #####. Чем отличается нормальный учёный от фрика? Нормальный ученый никогда не отрицает предыдущих теорий.

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

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

VD>Скорее ты злословишь.

VD>ЗВ

VD>Вообще, есть четкая закономерность. Когда EvilChild ставит плюс или смайлик, то в письме наезд или злословие.
VD>Мне даже страшно кода он иногда ставит хорошие оценки. Сразу возникает ощущение, что что-то не так сказал.

Меня радует, что у тебя с чуством юмора всё в порядке.
Даже скажу внушает некоторый оптимизм.

P.S. просто у меня нет столько энергии и времени как у тебя писать в форум в таких количествах, посему оценка и смайл мой инструмент.

Здравствуйте, Андрей Хропов, Вы писали:

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

FR>>Здравствуйте, Андрей Хропов, Вы писали:


АХ>>>Да, в общем то и желания не возникало. Слишком неудобно по-моему.

FR>>У бумаги есть большой плюс когда надо рисовать схемки, картинки, мне например при проектировании помогает.

АХ>А в чем проблема рисовать их на компе?

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

АХ>Особенно удобно если много стандартных элементов (блоки, стрелки). Их на компе и ворочать можно.

Удобно оформлять уже готовое. Творить не удобно

Здравствуйте, Андрей Хропов, Вы писали:

АХ>На бумаге в процессе brainstormingа непременно каракули получатся.
АХ>Любой whiteboard и то лучше (на нем стирать можно).

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

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

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

E>Здравствуйте, Андрей Хропов, Вы писали:

АХ>>На бумаге в процессе brainstormingа непременно каракули получатся.
АХ>>Любой whiteboard и то лучше (на нем стирать можно).

E>Все, приплыздец случился. Все что я могу сказать сквозь приступы смеха из под стола -- бумага, карандаш и ластик.
Ластик — это ужас:

1) придется пользоваться карандашом, который бледнее ручки или маркера.
2) хорошо работает только для черного карандаша
3) От него все равно остаются следы (весьма неопрятные), да и зачастую бумага мнется от активного трения
4) трение занимает время
5) от него остается мусор

Собственно недостатки карандаша которым придется в этом случае пользоваться:

1) Он тупится и ломается. Его надо точить.
2) Он заканчивается. Нужен новый.

Ну мне честно просто смешно обсуждать достоинства и недостатки таких "технических средств". Пользование бумагой — какой-то жуткий консерватизм. Купи планшет и нормальный монитор.

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

Пардон, что так поздно отвечаю — на мыло мне почему-то твой ответ не пришел, а Янус я загружаю раз в неделю (как лечение от RSDN addict).

ЗХ>>Интересно. Можно подробнее?

VD>Подробнее см. карринг и частичное применение.

Хм... В принципе, существует Ruby-библиотека скажем, позволяющая выполнять карринг. Она скорее proof-of-concept, но вполне работоспособная.
То есть, возможно, как и паттерн-матчинг, карринг может быть имитирован в "языке с разумно гибким синтаксисом"? Впрочем, не уверен, что у такого решения не будет фундаментальных недостатков.

VD>>>5. Сопоставление с образцом (pattrn matching) и алгеброические типы.
ЗХ>>Вот как раз сопоставление с образцом я не упомянул среди радикально крутых фич Немерла — исключительно потому, что язык с разумно гибким синтаксисом таки позволяет сделать это в виде библиотеки.

[...]

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

VD>Ну, да давай проведем следственный эксперемент. Вот придуманный мной пример:

Влад, вопрос очень интересный, поэтому я его в новой ветке попробую рассмотрю в decl, ок?

VD>>>7. ООП. Тут с одной стороны конкурентов много, но с другой качественная реализация ООП есть далеко не везде. Например, Питон я точно не могу назвать качествнной реалзацией. Руби чуть лушче, но все же тоже не дотягивет.

ЗХ>>И это, если можно, подробнее немножко.

VD>Подробнее лучше у FR. Лично для меня ЯП не имеющий защиты членов. И оперирующий разными странными вещами вроде __хзч__ вряд ли может является приемлемой реализацией ООП. И то что ЯП можно подкрутить на метапрограммировании как-то не очень радует. Ведь есть языки которые не надо подкручивать. А подкручиваение это всегда тормоза (для скриптов) и выбрасывание своего времени.

Угу, я понял. Но это скорее к одному Питону претензии.
А Руби где "недотягивает"?

ЗХ>>Ну, необходимость серьезной смены синтаксиса — вопрос не вполне однозначный.

VD>Речь не о смене синтаксиса. Речь об улучшении языка с целью повышения его уровня. Как правильно заметил Грэхем, порой чтобы сделать некоторую задачу на более низкоуровневом языке нужно написать интерпретатор более высокоуровневого. Так вот расширение синтаксиса — это возможность расширения компилятора основного языка с целю повышения его уровня.

Тут, вроде как, опять разница в статическом/динамическом подходе. То есть, Руби/Питон позволяют повышать уровень языка — но эти конструкции будут вычисяться на этапе выполнения, а не компиляции.

Кстати, я (вдохновленный Немерлом) прикинул, что на Руби тоже возможно сделать синтаксические макросы: есть библиотека ParseTree, дающая доступ к полному AST; этот AST можно поменять; есть библиотека ruby2ruby, позволяющая безгеморройно генерить руби-код на основе любого AST'а.
То есть, теоретически, некое расширение, которое выполняется после разбора программы, но до начала интерпретации, и модифицирует AST программы — вполне возможно.

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

VD>Ну, вот Немереле тоже не позволяет сделать это на 100%. Но я уверен, что его разумные пределы более широки и это более разумно. Причем надо учитывать, то что без информации о типах многое сделать не удается. А скриптовые метасредсва основанны на тексуальных движках. Плюс в них вообще не просто получить информацию о типах (она динамична). Это не позволяет реализовать некоторые задумки. А значит мы имеем место меенее мощьного решения.

Это тоже интересный момент. Хорошо бы на каком-то понятном примере его рассмотреть.
(уточняю — моя цель, не доказать, что Nemerle плох; а прикинуть, где Руби меня ограничиваеть и что с этим можно сделать).

ЗХ>>Итого, (не считая пока фич, для которых я попросил объяснений), остается статическая типизация и ее производные (строгость, серьезная поддержка со стороны IDE). Так?

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

Да вот я же это обсуждение и затеял, чтобы, как уже было сказано, "прикинуть, где Руби меня ограничиваеть и что с этим можно сделать". Мне вообще пофиг, мощнее ли А, чем Б. Для меня вопрос стоит так: "какие фичи А я еще не понимаю".

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

VD>Думаю, ты ошибашся. Кибернэйт заработает и так. Профайлер уже работает. Я, например, компилятор под ДотТрэйсом гонял еще месяца два назад. wpf и т.п. тоже думаю прикрутим.

профайлером ты меня порадовал, порадовал

VD>PS

VD>А без мата нельзя?

случайно проскочило

я считаю, у рсдн-а несколько совершенно дурацких черт:
одна из них — запрет на мат и "падонковщину"

мне мат работать и жить помогает!

M>Просто я считаю, что необходимо минимизировать количество связей на одного человека.
M>Иногда без их увеличения не обойтись, но если от них можно избавится, то нужно стараться это делать.

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

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

ага, работал в подобной конторе

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

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

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

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

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

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

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

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

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

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

вывод такой — чем светлее голова (собственная) — тем лучше, и не только в программинге

PI>>а в будущем будут другие (нелибовые) фигни типа wpf, к которым немерле уже не получит интеграции

АХ>Да нет, тут все не так плохо, wpf — он языконезависимый, код там генерируется через тот же CodeDom, CodeDom генератор у нас в компиляторе есть, так что добавить поддержку wpf — не так уж и сложно.

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

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

E>Кстати еще на тему "модификации" синтаксиса без непосредственного изменения синтаксиса. В Scala By Example приводится задачка:
E>можно ли реализовать цикл repeat с заданным синтаксисом:
Это примитив. Всего-лишь синтаксический сахар для чего-то вроде:

[Record] class repeatLoop
{
    action : void->void;
    public until(condition : void->bool) : void
    {
        action();
        // так будет логичнее для repeat until, чем в исходном примере
        while(!condition())
            action();
    }
}
mutable i = 0;

repeatLoop(() => { System.Console.WriteLine($"i=$i"); i++ }).until(() => i >= 4);

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

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

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

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

здесь

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

E><...поскипано...>
PI>>вот, как я сейчас понимаю, основная аппетитность Немерле — в возможности статической реализации многих чисто динамических (как казалось ранее) трюков
E><...поскипано...>
PI>>- типичная демонстрация DSL-эмбеддинга, но синтаксис становится более "родным" — я выполняю чекинг в компайл-тайм

E>Извини, но ты высказался в данном случае совсем не в тему. Речь шла о том, что конструкция:

как раз в тему — о расширениях синтаксиса

E>Вообще любой встроенный DSL в Ruby -- это всего лишь программа в стандартном синтаксисе Ruby, которая выполняет обращения к какому-то специализированному API.

слышал, Фаулер юзает Руби... может он не знает о существовании Немерле?
всегда комфортней сидеть на 1 (большом) стуле, чем на 2-3 взаимосвязанных стульях...

но я тут ступил на неизведанную большей частью территорию, поэтому пока буду молчать по этому поводу

PI>>короче, сейчас я начал одну систему на немерле, которая прямо скажем, укладывается лучше в динамику, и вроде как, только в неё.

LCR>Хм, понимаю. Мне приходится жуткие кренделя вырисовывать (на Йаве) из-за отсутствия нормальных динамических свойств в языке. У тебя либо получится, либо будет очень полезный опыт. В любом случае — успехов тебе .

спасибо, будем пробовать

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

LCR>Блин!

внатуре блин... ещё и банят ни за что

может, дело в русском менталитете? если кто-то ламак, то надо ему обязательно сказать: "ты — ламо"
а если из америки прислали диктофон — то надо возле него наганом стрельнуть... (из рассказа)
и нужно обязательно доказать, что кто-то ламо, потому что он — не ты...

а может, дело в специфичном чувстве юмора (помню случай, поверил соседу — спросил где найти кряк эн, он ответил на сайте эн.. зашел на сайт — предлагают активикс... я грю активикс ставить? — да, ставь конечно!... — это у него такая шутка юмора была, я потом целый день винду переустанавливал)

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

Vermicious Knid,

VK>В Nemerle разработчики зачастую не добавляют такие вещи из принципа, дабы не замусоривать дизайн ядра языка. Кроме того, по сравнению с макросами у такого подхода есть один очень большой недостаток — производительность. Замыкания это вещь далеко не бесплатная.

Смею заметить, что макросы — это вещь тоже далеко небесплатная.

VK>Реализация с помощью макросов сможет сделать этот цикл действительно обычным циклом. И это будет работать в десятки раз быстрее, чем всякие извращения с замыканиями.

Извращения? Надеюсь, этот экстремальный речевой оборот не для того, чтобы подчеркнуть некторую ущербность замыканий по сравнению с макросами... ИМО, ФВП — это обычная, совершенно прозрачно читаемая конструкция.

Здравствуйте, Андрей Хропов, Вы писали:

АХ>Ну мне честно просто смешно обсуждать достоинства и недостатки таких "технических средств". Пользование бумагой — какой-то жуткий консерватизм. Купи планшет и нормальный монитор.

Ну ты, блин, даёшь! Может ему ещё и на Немерле вместо C++ начать программировать?

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

VK>>В Nemerle разработчики зачастую не добавляют такие вещи из принципа, дабы не замусоривать дизайн ядра языка. Кроме того, по сравнению с макросами у такого подхода есть один очень большой недостаток — производительность. Замыкания это вещь далеко не бесплатная.

LCR>Смею заметить, что макросы — это вещь тоже далеко небесплатная.

Макросы влияют только на скорость компиляции.

VK>>Реализация с помощью макросов сможет сделать этот цикл действительно обычным циклом. И это будет работать в десятки раз быстрее, чем всякие извращения с замыканиями.

LCR>Извращения? Надеюсь, этот экстремальный речевой оборот не для того, чтобы подчеркнуть некторую ущербность замыканий по сравнению с макросами... ИМО, ФВП — это обычная, совершенно прозрачно читаемая конструкция.

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

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

PI>я считаю, у рсдн-а несколько совершенно дурацких черт:
PI>одна из них — запрет на мат и "падонковщину"

Мат и подонковщина заразны. Небольшое послабление и очень быстро сайт превратится в помойку. Убеждаться в этом уже приходилось не раз. Так что давай не будем.

PI>>я считаю, у рсдн-а несколько совершенно дурацких черт:
PI>>одна из них — запрет на мат и "падонковщину"

IT>Мат и подонковщина заразны.
заразны конечно, но это не болезнь

IT> Небольшое послабление и очень быстро сайт превратится в помойку.
а так он типа — средоточие чистоты и квинтэссенция мысли

IT> Убеждаться в этом уже приходилось не раз. Так что давай не будем.
ну я тут типа гость...

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

LCR>Смею заметить, что макросы — это вещь тоже далеко небесплатная.
LCR>Извращения? Надеюсь, этот экстремальный речевой оборот не для того, чтобы подчеркнуть некторую ущербность замыканий по сравнению с макросами...
IT уже ответил, я с ним согласен.

LCR>ИМО, ФВП — это обычная, совершенно прозрачно читаемая конструкция.
Только до тех пор, пока ими не пытаются эмулировать расширения синтаксиса. В частности, неявное создание замыканий я не считаю прозрачно читаемой конструкцией. Когда вызываешь некий метод объекта, все таки не ожидаешь, что его параметр может превратиться в замыкание. А тем более не ожидаешь увидеть вместо нормального списка параметров(ограниченного привычными круглыми скобками) какой-то непонятный блок кода.