E>Под "спецификой дотнета", надо полагать, подразумевается то, что из Nemerle можно использовать ранее написанный на C#/VB.NET код? Т.е. достаточно переучить существующих .NET программистов на Nemerle и можно будет продолжать существующие проекты на Nemerle даже не переписывая унаследованного кода?
да, это я имел в виду
E>Можно услышать ответы на эти вопросы? Только, если можно, без обычных наездов на личные качества и умственные способности собеседника. Эти вопросы актуальны не только для Nemerle, но и для любого другого языка (не только языка), который только начинает свое существование вне рамок группы энтузиастов.
вообще не хотел отвечать, но раз ты просишь
(не хотел, потому что ты явно не собираешься работать с Немерле, а я своё время должен беречь..)
E>Тогда может быть объяснишь, что должно сподвигнуть руководителей проектов переводить свои коллективы с испытанных и имеющих просто фантастическую поддержку языков (C#/VB) на Nemerle? C#/VB -- это огромное количество документации, форумов, книг, инструментов. Это обученные сотрудники, которые заняты решением своих прикладных задач. Это уже проторенный путь с известными рисками и уже сложившейся инфраструктурой, в который вложено не мало сил и средств.
да
E>Чем ты будешь убеждать менеджеров, которые озабоченны датой сдачи "вчера" очередного проекта, что находящийся в бета версии экспериментальный OpenSource язык с нулевой историей применения в коммерческих разработках настолько выгоден, чем C#/VB, что нужно будет выделить внеплановые ресурсы и время на переобучение персонала под Nemerle?
да
E>Чем ты будешь убеждать...[skip]... а жена пилит, что ребенку нужно новые сапожки идти выбрать, а... Большинство таких проблем не имеют никакого отношения к качеству языка программирования, зато они гораздо важнее, чем какой-то там новый язык, который сможет поднять (?, ну пусть даже) производительность труда. Тем более, что эта повышенная производительность будет означать всего лишь увеличение количества получаемых от начальства заданий.
понимаешь ли, у каждого из нас есть проблемы по жизни — у кого то больше, у кого то меньше.
кто-то болеет, у кого-то жена пилит, кто-то занимается баклушами на работе, и отхватывает поэтому.
поэтому, программисты — это такие абстрактные сущности, которые сидят внутри каждого из нас, и занимают, у кого-то 10%, у кого-то 90% жизнедеятельности.
и проблемы остальных процентов меня не волнуют, и люди ценны настолько, насколько они выкладываются по работе/изучению/тому, что действительно ценно.
если кто-то занимается программированием, но на самом деле, нифига им не занимается — я предлагаю отправить его в топку (ладно, в Бангалор, мы не звери).
конечно, у меня, у тебя, у каждого есть быт — если у кого-то быт занимает всю жизнедеятельность, могу лишь посочуствовать, и отправить его в Бангалор (ну или в /dev/null, куда больше нравится).
прогресс делают не они, и я бы даже сказал, работу делают не они (а что это за работа такая? индусский кодинг?)... короче, это нет смысла обсуждать.
E>Это только выглядит оффтопиком. Но, если вы хотите перевести Nemerle в мейнстрим, то нужно считаться с тем, что мейнстрим должен быть по силам и желаниям даже самым равнодушным и малоспособным программистам. Даже индусам. Даже обленившимся русским, мнящим себя самыми программистыми программистами в мире. Sun с Java и MS с .NET это прекрасно понимают.
ну, я даж не знаю, кем этих людей заменить... скажи честно, тебя волнуют судьбы глупых и равнодушных к программированию программистов?
E>Что останется от самого Nemerle, если запретить в нем использование макросов
сразу говорю, предпосылка неверная
нельзя запрещать использование макросов в Немерле
это девальвирует саму идею языка
E> (а как здесь уже говорилось, это нужно сделать, дабы оградить проекты от черезмерно изобретательных велосипедостроителей) и отбросить функциональные вещи (которые многие не будут применять, так же как многие не применяли в свое время ООП должным образом)?
то останется от немерле один голый сишарп
E> Намного ли такой урезанный под мейнстримовые условия Nemerle будет круче того же C#? И чем он так соблазнит VB программистов?
я не думаю, что "VB-программист" — непротиворечивое словосочетание
E> Без книг, без учебных курсов, без сертификации и прочей лабуды, которая создает имидж "солидного", "серьезного", "мейнстримового" языка.
да, ты во многом прав здесь, и даже пишешь без кривляний
поэтому, не растекаясь мыслию по древу, признаю, что ты прав
совсем тупым программерам Немерле просто не под силу
чем менее ты опытный и более ты глуп, тем больше времени уйдёт на изучение языка
отсюда с необходимостью следует, что полностью мейнстрим-доминейшена Немерле не видать
хочется тешить себя надеждой, что он выступит в роли инструмента для самых рулезных чуваков из мейнстрима
но это касается "полной версии" Немерле — на сишарпном его подмножестве вовсю можно писать уже через час после установки на комп (для тех, кто знает сишарп, достаточно мануала на пару страниц)
но если Немерле окажется невостребованным мейнстримом, то и ладно
на нём буду программить я и ещё пачка рулёзных парней — и этого достаточно
и будет достаточно до тех пор, пока Немерле будет поддерживать полный backward compatibility с мейнстримом
если же развитие мейнстрима пойдёт по некоторой другой, отличной от теперешней, ветке, а немерлисты не будут поспевать адаптировать язык+инструментарий под новые реалии,
мне придётся прыгать на другой язык+инструментарий...
и чтоб такого не случилось, нужно всё-таки комьюнити чуть побольше
я ответил на твой вопрос?
Здравствуйте, PhantomIvan, Вы писали:
PI>(не хотел, потому что ты явно не собираешься работать с Немерле, а я своё время должен беречь..)
я не собираюсь работать с Немерле просто исходя из того факта, что в нашей конторе нужна реальная кросс-платформенность, и даже не вчера, а позавчера. Поэтому мы используем Java/C++/Ruby.
PI>если кто-то занимается программированием, но на самом деле, нифига им не занимается — я предлагаю отправить его в топку (ладно, в Бангалор, мы не звери). PI>конечно, у меня, у тебя, у каждого есть быт — если у кого-то быт занимает всю жизнедеятельность, могу лишь посочуствовать, и отправить его в Бангалор (ну или в /dev/null, куда больше нравится). PI>прогресс делают не они, и я бы даже сказал, работу делают не они (а что это за работа такая? индусский кодинг?)... короче, это нет смысла обсуждать.
Вот именно такое отношение к делу мне и не нравится. Объем работы, который выполняют обычные программисты, трудно переоценить. Образно выражаясь, подобные мне фанатики программирования могут лихо клепать склеты программ, но вот на цепляние "мяса" к этим костям у меня запала уже не хватает. Однако, я знаю людей, которые очень хорошо это делают, и которых никаким боком не волнует существование, скажем, Haskel-я или вклад в индустрию Lisp-а. И вместо изучения алгебраических типов они с большим удовольствием часок-другой поиграют в футбол. Зато это их стараниями выполняются большие и ответственные проекты.
E>>Это только выглядит оффтопиком. Но, если вы хотите перевести Nemerle в мейнстрим, то нужно считаться с тем, что мейнстрим должен быть по силам и желаниям даже самым равнодушным и малоспособным программистам. Даже индусам. Даже обленившимся русским, мнящим себя самыми программистыми программистами в мире. Sun с Java и MS с .NET это прекрасно понимают.
PI>ну, я даж не знаю, кем этих людей заменить... скажи честно, тебя волнуют судьбы глупых и равнодушных к программированию программистов?
Меня волнует вот что: если я выбираю язык/платформу, на котором в будущем будут разрабатываться продукты компании, то я несу ответственность за последствия этого выбора. В том числе и за то, как новые люди, подключившиеся к работе после меня будут осваивать этот язык, как много ляпов будет совершаться в процессе перехода на новую платформу, какими инструментами будет поддерживаться разработка, какова будет ситуация с документацией, как будут относиться те заказчики, которые предъявляют требования к используемым технологиям. И пр. и пр. В таких условиях наличие паттерн-матчинга и макросов в языке на данный (подчеркиваю, данный) момент будет полностью девальвированно отсутствием толковой русскоязычной литературы по языку и отсутствием поблизости одного-двух гуру, которых можно взять за жабры и попросить рассказать, почему же вот именно этот матчинг нифига не матчит, хотя и был тупо скопирован из исходника этого гуру.
Вот такие вот мысли на сейчас. Если с Nemerle все будет в порядке, то лет через пару ситуация может коренным образом поменяться. И, к сожалению, так дела обстоят не только с Nemerle, но и со Scala, и с D.
PI>но если Немерле окажется невостребованным мейнстримом, то и ладно PI>на нём буду программить я и ещё пачка рулёзных парней — и этого достаточно PI>и будет достаточно до тех пор, пока Немерле будет поддерживать полный backward compatibility с мейнстримом
Собственно об этом prVovik и сказал.
PI>я ответил на твой вопрос?
Да. Спасибо.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eao197, Вы писали:
E>Под "спецификой дотнета", надо полагать, подразумевается то, что из Nemerle можно использовать ранее написанный на C#/VB.NET код? Т.е. достаточно переучить существующих .NET программистов на Nemerle и можно будет продолжать существующие проекты на Nemerle даже не переписывая унаследованного кода?
*
E>Тогда может быть объяснишь, что должно сподвигнуть руководителей проектов переводить свои коллективы с испытанных и имеющих просто фантастическую поддержку языков (C#/VB) на Nemerle?
А что сподвигло их перейти на эти языки в своё время?
E>C#/VB -- это огромное количество документации, форумов, книг, инструментов. Это обученные сотрудники, которые заняты решением своих прикладных задач. Это уже проторенный путь с известными рисками и уже сложившейся инфраструктурой, в который вложено не мало сил и средств.
Дело в том, что Немерле не противопоставляет себя ни чему из вышеперечисленного. Немерле это всё только дополняет. Весь опыт, полученный при разработке под .NET остаётся востребованным. При чём, чем глубже этот опыт, тем лучше. Это вовсе не выглядит как переход, ну скажем, с DOS на Windows, когда пришлось выбросить все свои наработки. Это даже не изучение какого-то дополнительного языка, например, Руби, в дополнение к C++. Это скорее похоже на переход с C# 2.0 на C# 4.0. Все наработки, все знания, вся используемая документация, всё это остаётся с нами.
По-поводу документации. Конечно, хорошо бы собрать всё, что уже есть в один документ, систематизировать это и заполнить пробельные места. Но даже того, что есть сейчас во многих случаях вполне достаточно. Да и, если често, скажи мне, к какой документации ты обращаешься чаще, к документации по библитекам или по языку?
E>Чем ты будешь убеждать менеджеров, которые озабоченны датой сдачи "вчера" очередного проекта, что находящийся в бета версии экспериментальный OpenSource язык с нулевой историей применения в коммерческих разработках настолько выгоден, чем C#/VB, что нужно будет выделить внеплановые ресурсы и время на переобучение персонала под Nemerle?
Вменяемый персонал переобучивается с C# на Немерле за считанные часы. В этом вся фишка. Самая большая проблема — это усвоить, что типы теперь указываются не так:
int i;
а так:
i : int;
E>Чем ты будешь убеждать самих разработчиков, что они должны отложить успешно используемый ими в данный момент инструмент и взятся за что-то совершенно новое, да еще с заметным привкусом функциональщины? В любой более-менее крупной команде изрядный процент программистов весьма сдержано относится к необходимости переобучения. И совсем без энтузиазма относятся к переходу на какие-то новые инструменты. Это только активные авторы сообщений на RSDN все такие из себя прогрессивные, языки новые без остановки изучают, иногда даже что-то применяют. А в реальности многие хотят разобраться с тем, куда этот долбаный фокус ввода на форме пропадает, и почему в отчете последняя строчка сьезжает, или почему этот SQL запрос слишком долго работает, или какого он здесь вообще сидит, если через полтора часа трансляция Лиги Чемпионов начинается, а жена пилит, что ребенку нужно новые сапожки идти выбрать, а... Большинство таких проблем не имеют никакого отношения к качеству языка программирования, зато они гораздо важнее, чем какой-то там новый язык, который сможет поднять (?, ну пусть даже) производительность труда. Тем более, что эта повышенная производительность будет означать всего лишь увеличение количества получаемых от начальства заданий.
Ещё раз. Чем руководствовались эти программисты при переходе на C#/Java?
E>Что останется от самого Nemerle, если запретить в нем использование макросов (а как здесь уже говорилось, это нужно сделать, дабы оградить проекты от черезмерно изобретательных велосипедостроителей) и отбросить функциональные вещи (которые многие не будут применять, так же как многие не применяли в свое время ООП должным образом)? Намного ли такой урезанный под мейнстримовые условия Nemerle будет круче того же C#? И чем он так соблазнит VB программистов? Без книг, без учебных курсов, без сертификации и прочей лабуды, которая создает имидж "солидного", "серьезного", "мейнстримового" языка.
Запрещать надо не использование макросов, а их написание. Да и, честно говоря, думаю, что запрещать ничего не надо будет. Написание макросов относится к задачам, подобным написанию фреймворков. Этим обычно занимаются наиболее опытные девелоперы в команде. Дело остальных прилежно использовать написанное.
E>Можно услышать ответы на эти вопросы? Только, если можно, без обычных наездов на личные качества и умственные способности собеседника. Эти вопросы актуальны не только для Nemerle, но и для любого другого языка (не только языка), который только начинает свое существование вне рамок группы энтузиастов.
Эти ответы уже не раз здесь звучали. Сводятся они к тому, что язык себя ничему не противопоставляет, не пытается всё разрушить до освнования, а затем построить новый мир. Это, конечно же, не завоевание Немерле, это завоевание CLR. Заслуга же самого язык в том, что он максимально приближен к C# и позволяет осуществлять переход с него очень плавно и безболезненно. Мне лично понадобилось всего пару часов для ознакомления с Немерле, после чего потекли слюнки и зачесались руки.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, cl-user, Вы писали:
CU>А можно забыть про "нравится/не нравится" в отношении ЯП? А то сразу приходит на ум, что женщины выбирают автомобиль в первую очередь по цвету.
И правильно делаю. Им на него ведь еще долго смотреть прийдется. Да и вторая очередь у них тоже иногда есть...
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, R.K., Вы писали:
RK>Под "Над" разумею "Код". Компилятор GHC скомпилирует код с этим модулем. Другие — скорее всего нет. Но если есть хоть один компилятор (кстати, он наиболее продвинутый), значит TemplateHaskell можно считать законной частью языка, но, естественно, не стандарта.
Весьма странные суждения. Если бы все компиляторы и интерпретаторы (или хотя бы несколько) поддерживали бы это расширение, то конечно.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Зверёк Харьковский, Вы писали:
ЗХ>К слову сказать, есть такая типа сверх-современная идея, как конструирование запросов к БД из list comprehensions (слова для гугления — kleisli, язык программирования links, в какой-то степени и LINQ "про это"). ЗХ>Лично мне она нравится
Да, из этой. Но чесно говоря к лист-компрехеншонс у меня двойственое отношение. С одной стороны конечно получается сжато, но с другой ведь понять то что получилось очень не просто. В синтаксисеп лист-компрехеншонс откровенно опускаются многие вещи и он превращается в шифровку (особенно в сложных случаях). Это приводит к тому, что для чтения лист-компрехеншонс нужно долго тренироваться. Другими словами проявляется основная болезнь Лиспа когда после некоторого объема для неподготовленного человека все это првращается в темный лес.
ЗХ>Таким образом, "вместо синтаксиса SQL использовать <подставьте-ваш-язык-если-он-достаточно-функционален>" — не такая уж идиотская идея
Не спорю. Но сам предпочитаю обходиться функцями. Что-то типа:
def res = source.Filter(_.Name.Like("V%")).Map(x => (x.Name, x.LastName)).Sort(x => x[0]);
Этот код отфильтрует всех у кого имя начинается на 'V' преобразует список в список кортежей содержаших имя и фамилиюи отсортирует список по имени.
У такого подхода и возможностей по больше будет. Ведь всегда можно новую фукнцию дописать.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Andrei N.Sobchuck, Вы писали:
ANS>Не устаю поражаться абсолютизму в твоих словах. Логи по гигу. Сейчас взял проверил — слил 10 логов в один и прогнал через grep — работает.
А что по гигу-то, а не по 10? И сколько он работал?
Ладно. Это все равно демагогия и пустой треп. Греп не более чем утилита. К самим шел-скриптам отношения не имеет. Его без проблем можно оформить библиотекой и использовать из скриптов на любом языке. Так что это вопрос наличия библиотечного класса или функции для решения нектоторого класса задач.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Сергей, Вы писали:
С>Да, собственно, они существуют уже довольно-таки давно.
Не знаю, не знаю. Когда-то вообще ничего небыло. Потом что-то появилось от МС, но оно было платное.
С>Это все можно сказать и про любые другие инструменты. А если есть опыт работы с unix-системами, то изучать дополнительно ничего и не надо — они аналогичны одноменным никсовым утилитам.
А если нет? Мне однобуквенные сокращения совсем не нравятся. А комплита и т.п. нет.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, eao197, Вы писали:
E>Просто у меня сложилось такое впечатление от твоих постов здесь и в теме Write in Nemerle.
А у меня сложилось впечатление, что ты кроме Руби и С++ времен 80-ых годов ничего не видел, отсал от жизни лет так на 20, не хочешь замечать приемуществ которые дают современные технолгии и все рвемя излеваешь маргинальщину по поводу и без повод.
Давай это обсудим?
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Курилка, Вы писали:
К>>>Нет там потоков. К>>>В том весь и смысл, что параллельность получается не на потоках ОС, т.е. нет постоянных переключений контекста, что позволяет ускорить работу приложения (при наличии нескольких процессов).
VD>>Ты бы разобрался в том что обсуждаешь, а потом бы разговоры вел. Чушь ведь несешь. К>Ты бы читал сначала, прежде чем отвечать, Влад, это уже просто из раза в раз повторяется.
Я то читаю очень даже внимательно. Погляди на выделенное. Это заблуждения. Ничего ускорить они не позволяют (Эрлэнг не волшебная палочка). Они позволяют реализовать параллельное (точнее псевда-параллельное) исполнение нескольких зеленых потоков (Эрлэнг-процессы). Но они будут исполняться на одном физическом потоке ОС. И для реального распараллеливания прийдется создать втрой поток ОС и запустить на нем другие зеленые потоки.
К>И? Я говорил что-то противоположное этом?
Да.
К> Я же гововорил, что нет постоянного переключения между тредами
Да, но и нет ускорения выполнения на многопроцессором железе по сравнению с тупым созданием несколькоих потоков ОС.
К> (что было бы в реализации процессов чисто на потоках). И именно засчёт этого и получается выигрыш.
Ну, что же. Предлагаю тупо провести эксперемент. Берем классичкий алгоритм QuickSort и реализуем его на Эрлэнг и каком-то языке дотнета (Шарпе или Немерле). Причем в дотнетом языке вручную распараллелим выполнение метода на потоках (по числу процессоров в системе). Уверен, что Эрлэнг сольет.
К>И твои слова как раз являются описанием того, что я имел в виду. Чуть более подробным.
Я бы так не сказал.
К>Просто фантом сказал, что будет много круче из-за разницы между потоками явы и .нет. Я же сказал, что это тут совсем не существенно (возможно многопроцессорность сделает это более значимым, но это другая тема).
Вы оба не правы. Эрлэнг хорош не тем что он куруто распараллеливает выполнение на разных процессорах. Эрлэнг крут своей моделью паралеллизма. Он обеспечивает автоматическое и безконфликтное распараллеливание. Это позволяет выполнять (псевдо) параллельно множество нерисорсоемких задач. При этом мы избавлены от необходимости думать о синхронизации. Но за это мы платим разбиением алгоритма на отдельные процессы и обязаны обемниваться данными между ними с помощью сообщений. Такой подход очень хорош когда надо обеспечить отклик множеству параллельных клиентов. Но практически ничего не дает в алгоритмическом плане.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
ЗХ>>К слову сказать, есть такая типа сверх-современная идея, как конструирование запросов к БД из list comprehensions (слова для гугления — kleisli, язык программирования links, в какой-то степени и LINQ "про это"). ЗХ>>Лично мне она нравится
VD>Да, из этой. Но чесно говоря к лист-компрехеншонс у меня двойственое отношение. С одной стороны конечно получается сжато, но с другой ведь понять то что получилось очень не просто. В синтаксисеп лист-компрехеншонс откровенно опускаются многие вещи и он превращается в шифровку (особенно в сложных случаях). Это приводит к тому, что для чтения лист-компрехеншонс нужно долго тренироваться. Другими словами проявляется основная болезнь Лиспа когда после некоторого объема для неподготовленного человека все это првращается в темный лес.
ЗХ>>Таким образом, "вместо синтаксиса SQL использовать <подставьте-ваш-язык-если-он-достаточно-функционален>" — не такая уж идиотская идея
VD>Не спорю. Но сам предпочитаю обходиться функцями. Что-то типа: VD>
VD>def res = source.Filter(_.Name.Like("V%")).Map(x => (x.Name, x.LastName)).Sort(x => x[0]);
VD>
VD>Этот код отфильтрует всех у кого имя начинается на 'V' преобразует список в список кортежей содержаших имя и фамилиюи отсортирует список по имени.
VD>У такого подхода и возможностей по больше будет. Ведь всегда можно новую фукнцию дописать.
Мы говорим об одном и том же, я просто шире трактую понятие list comprehension Мой код на Ruby, вдохновленный языком links:
employees.select{|e| e.name == 'John' && e.salary > 50}.sort_by{|e| e.age}[2,10]
#generates "select * from Employees where name = 'John' and salary > 50 order by age limit 2,10"
Синтаксически, это, конечно, не "классический list comprehension", но семантически — вполне себе.
Здравствуйте, IT, Вы писали:
IT>А что сподвигло их перейти на эти языки в своё время?
По поводу C# не знаю. Нет среди моих знакомых тех, ктобы сейчас работал на C#. В основном Java, C, C++, Python.
А VB -- это язык с очень большой историей. И стал популярным, поскольку некоторые типы ПО для Windows было разрабатывать гораздо проще, чем на C/C++.
IT>Да и, если често, скажи мне, к какой документации ты обращаешься чаще, к документации по библитекам или по языку?
На момент обучения -- к документации по языку. Мне, например, существующая документация по Scala не понравилась. Часть слишком поверхностная, часть слишком сложная. От документации по Nemerle у меня пока тоже впечатление не ахти.
E>>Чем ты будешь убеждать менеджеров, которые озабоченны датой сдачи "вчера" очередного проекта, что находящийся в бета версии экспериментальный OpenSource язык с нулевой историей применения в коммерческих разработках настолько выгоден, чем C#/VB, что нужно будет выделить внеплановые ресурсы и время на переобучение персонала под Nemerle?
IT>Вменяемый персонал переобучивается с C# на Немерле за считанные часы. В этом вся фишка. Самая большая проблема — это усвоить, что типы теперь указываются не так:
IT>
IT>int i;
IT>
IT>а так:
IT>
IT>i : int;
IT>
Это и все? Единственный аргумент к руководству?
IT>Ещё раз. Чем руководствовались эти программисты при переходе на C#/Java?
Еше раз. Ну не видел я продуктов, которые бы переписывались на C#.
А Java начилась с апплетов, которые вообще ни на чем писать нельзя было. Затем был опять Web, но уже серверная часть, которую на Java было делать проще, чем CGI C/Perl. Так что шел переход программистов в новую нишу с использованием новых языков.
IT>Написание макросов относится к задачам, подобным написанию фреймворков. Этим обычно занимаются наиболее опытные девелоперы в команде.
IT>Заслуга же самого язык в том, что он максимально приближен к C# и позволяет осуществлять переход с него очень плавно и безболезненно. Мне лично понадобилось всего пару часов для ознакомления с Немерле, после чего потекли слюнки и зачесались руки.
Я так и не понял зачем кто-то будет менять C# на Nemerle сейчас.
Не всем же нужна compile-time генерация в собственном фреймворке.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, VladD2, Вы писали:
ANS>>Не устаю поражаться абсолютизму в твоих словах. Логи по гигу. Сейчас взял проверил — слил 10 логов в один и прогнал через grep — работает. VD>А что по гигу-то, а не по 10?
изначально размер преполагался в 10 гигов.
VD>На 10 гигах сдохнит скорее всего что угодно
двумя постами выше...
VD>Ладно. Это [b]выделю что именно: VD>А что по гигу-то, а не по 10?[/b]] все равно демагогия и пустой треп.
VD>Греп не более чем утилита.
и тем не менее работает. изначально предпологалось что она отвалится.
VD>К самим шел-скриптам отношения не имеет.
хм... а что имеет?
если конструкции вида
x=`cat ~/log/log.log`
y=`echo $x | grep bla`
отработают, значит имеет
Здравствуйте, VladD2, Вы писали:
VD>А у меня сложилось впечатление, что ты кроме Руби и С++ времен 80-ых годов ничего не видел, отсал от жизни лет так на 20, не хочешь замечать приемуществ которые дают современные технолгии и все рвемя излеваешь маргинальщину по поводу и без повод.
VD>Давай это обсудим?
А разве мое участие для этого необходимо? Имхо, ты прекрасно справишься сам.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
VladD2 wrote: > ANS>Не устаю поражаться абсолютизму в твоих словах. Логи по гигу. Сейчас > взял проверил — слил 10 логов в один и прогнал через grep — работает. > > А что по гигу-то, а не по 10? И сколько он работал?
Сумма 10.
> Ладно. Это все равно демагогия и пустой треп. Греп не более чем утилита. > К самим шел-скриптам отношения не имеет. Его без проблем можно оформить
Вполне имеет. Shell-скрипты пишут для исполнения на unix-подобных
системах, которые должны примерно быть похожими хоть на какой-то
стандарт: POSIX, SUS, SysV. И в любом случае grep должен быть. Так что в
shell-скриптах наличие grep считается гарантированным.
> библиотекой и использовать из скриптов на любом языке. Так что это
И таскать за собой, очевидно. Потому как поставить на систему shell без
sed и grep может только злобный Буратино, а вот поставить реализацию
любого другого языка программирования и не поставить grep — вполне принято.
> вопрос наличия библиотечного класса или функции для решения нектоторого > класса задач.
А весь Framework — это тоже просто библиотечный код для C#? Shell и grep
в любом стандарте описаны или нет одновременно.
Здравствуйте, Андрей Хропов, Вы писали:
АХ>Здравствуйте, eao197, Вы писали:
E>>Этот порочный круг существует не только для Nemerle, но и для, например, D или Scala. Механизм адаптации новых технологий уже описан
. И даже выведен рецепт привлечения на свою сторону прагматиков -- нужно найти для языка нишу и выпустить в этой нише killer app.
АХ>Не обязательно даже узкую нишу. Просто достаточно иметь success story, которая ясно показывает почему именно сильные стороны языка привели к этому success.
АХ>Вот Python он вроде как-то постепенно набирал популярность, а не резко как Ruby.
E>>Когда продвижением технологии занимается крупная корпорация (вроде Sun с Java или Microsoft с .NET) такая ниша находится более менее быстро. Хотя даже в этом случае период адаптации языка затягивается на годы. E>> А вот в случае OpenSource поиски своей ниши и ожидание своего killer app может порядком затянуться. Например, Ruby пришлось ожидать почти девять лет, чтобы ворваться в мейнстрим посредством RubyOnRails.
АХ>Да, вот тут один товарищ начал разработку Scala with Sails. Возможно это может претендовать на роль killer app для Scala.
Знаешь, такое ощущение, что после рельсов стало просто хорошим тоном делать эти вебфреймворки. И уже никого ими не удивишь, думаю. Так что killer app имхо должен делать что-то именно новое, дабы привлечь внимание широкой аудитории. А так получается, что идёт переписка одного и того же без значительных изменений.
Здравствуйте, VladD2, Вы писали:
VD>Если только они написаны очень криво. Вообще-то регексы переводятся в ДКА, а это дин из самых эффективных средств прасинга.
Хм. Читал недавно толстую книжку про регэкспы. Автор утверждает, что в Java и .Net — НКА. Наиболее продвинутый движок в Tcl — ДКА/НКА в зависимости от. Где регэкспы ДКА уже не помню. Может в grep?
Если нам не помогут, то мы тоже никого не пощадим.
