PI>>что в условиях экс-ссср (фактического отсутсвия специализированного it-образования) трудно найти хорошего документёра, тестера и программера — это факт. напоминаю, Брукс работал в IBM — туда студентов не нанимали.
К>Ты настолько не уважаешь экс-ссср?
моя Родина — СССР, и я советский человек, в хорошем смысле этого слова
но факт остается фактом: математическое образование — (было) хорошее, как нигде, а вот кибернетику, как продаждную девку империализма, по традиции травили вплоть до 80-х.
плюс специалист, если он разбирается хорошо в технологиях, и на "edge" технологий, что называется, — он пойдет зарабатывать деньгу в софт-компанию, нежели останется учить в институте.
в общем, говорить об этих грустностях не хочется...
К>Есть мнение, что найти этих же тестеров, программистов и прочих здесь примерно также сложно как и там
не знаю, в США не был — но судя по всему, образовательная система по части софт-технологий у них на высоте.
К> Только вот зарплаты и требования будут несколько различаться для представителя тех же США и, допустим, Питера. Чем софверные конторы и пользуются, если ты не заметил...
та ну, как бы уже давно заметил
Здравствуйте, eao197, Вы писали:
E>Не очень-то лично мне хочется запускать в коммерческую эксплуатацию систему, написанную на языке, у авторов которого нет времени на исправления в нем ошибок.
Ты теплое с мягким не путай. Ошибки в языке — это ошибки дизайна. Их обычно исправляют в течение нескольких лет, а как правило вообще не исправляют, а просто другой язык придумывают .
Ошибки в конкретном компиляторе — это ошибки его реализации. Если ты это имеешь в виду, то так и скажи — интересный язык, но я считаю, что единственный имеющийся на сегодня компилятор пока не достиг уровня качества, необходимого для промышленной разработки.
А Linux не боишься использовать? А у него те же проблемы:
Здравствуйте, Андрей Хропов, Вы писали:
E>>Не очень-то лично мне хочется запускать в коммерческую эксплуатацию систему, написанную на языке, у авторов которого нет времени на исправления в нем ошибок.
АХ>Ты теплое с мягким не путай. Ошибки в языке — это ошибки дизайна. Их обычно исправляют в течение нескольких лет, а как правило вообще не исправляют, а просто другой язык придумывают .
Тогда расшифруй мне, что имел в виду разработчик Nemerle, когда говорил
Well, as you probably noticed our support for implementing features and fixing bugs is not very fast.
ошибки в компиляторе или в языке?
В любом случае разработчики поддвержают, что где-то ошибки есть и быстро исправлять они их не могут.
АХ>Ошибки в конкретном компиляторе — это ошибки его реализации. Если ты это имеешь в виду, то так и скажи — интересный язык, но я считаю, что единственный имеющийся на сегодня компилятор пока не достиг уровня качества, необходимого для промышленной разработки.
Я скажу так: для меня язык не сильно интересный, да и единственный имеющийся на сегодня компилятор пока не достиг уровня качества, необходимого для промышленной разработки. Поскольку версии 1.0 доступной для скачивания еще несколько дней назад я не видел.
АХ>А Linux не боишься использовать?
Нет, поскольку условия диктуют заказчики. Они чаще всего конкретно указывают какой именно дистрибутив и версия должна использоваться. Так что они сами отвечают за свои желания.
АХ>А так как всегда в open source — берешь код и за дело.
Никогда не правил исходники Linux и желания не было -- просто скачивал более свежие версии. Благо для Linux-а они регулярно выходят.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Ну, на конец-то вы заговорили о чем-то интресном. Пофлэйммим...
ЗХ>Тут интересная корреляция с понятием "мощности" языка (по-моему у Грэма где-то есть об этом, когда он Лисп воспевает): добавление в язык некоторых "фич" увеличивает лаконичность и выразительность кода действительно на порядки.
Парадокс Блаба
Что же в Lisp'е такого прекрасного? Если он такой замечательный, почему его не используют все? Казалось бы, риторические вопросы, но на самом деле на них есть прямые ответы. Lisp настолько хорош не тем, что в нем есть некое волшебное качество, видимое только его приверженцам, а тем, что он — самый мощный язык программирования из существующих.
И причина того, что все вокруг пишут не на Lisp'е, заключается в том, что выбор языка программирования — вопрос не только технологии, но также и привычки, а ничто не меняется так медленно, как привычки. Конечно, оба эти тезиса требуют разъяснений.
Я начну с шокирующего утверждения: языки программирования отличаются друг от друга своей мощностью.
По крайней мере мало кто будет спорить, что высокоуровневые языки более мощные, чем машинный язык (машинный код и ассемблеры – VladD2). Большинство программистов согласятся, что, как правило, программировать стоит не на машинном языке, а на каком-нибудь языке высокого уровня, переводя программу в машинный код с помощью компилятора. Сейчас эта идея получила даже аппаратное воплощение — с восьмидесятых годов команды процессоров разрабатываются скорее для компиляторов, чем для программистов.
Каждый знает, что писать всю программу вручную на машинном языке — ошибочно. Но гораздо реже понимают то, что существует и более общий принцип: при наличии выбора из нескольких языков ошибочно программировать на чем-то, кроме самого мощного, если на выбор не влияют другие причины (VladD2: выделено мой, мне кажется эта мысль очень важна, ведь если, например, более мощный язык не обеспечивает приемлемой производительности, то его выбор так же будет не оправданным).
Все языки одинаково мощные, если рассматривать их с точки зрения эквивалентности машине Тьюринга, но это не та мощь, которая важна программисту. (Никто ведь не хотел бы программировать машину Тьюринга). Мощь языка, в которой заинтересован программист, возможно, трудно определить формальными методами, однако одно из объяснений этого понятия заключается в свойствах, которые в менее мощном языке можно получить, только написав на нем интерпретатор для более мощного языка. Если в языке A есть оператор для удаления пробелов из строк, а в языке B его нет, это не делает A более мощным, чем B, так как в B можно написать процедуру, которая делала бы это.
Но, скажем, если язык A поддерживает рекурсию, а B — нет, это нечто, что нельзя исправить написанием библиотечных функций (VladD2: в прочем бывает так, что средствами языка B в принципе можно решить проблему, решение ее столь сложно, что решение это можно назвать чисто теоретическим).
Есть много исключений из этого правила. Если вы пишете программу, которая должна тесно взаимодействовать с программой, написанной на определенном языке, возможно, окажется разумным писать новую программу на том же языке.
Если вы пишете программу, которая должна делать что-то очень простое, вроде численной обработки больших массивов данных или манипуляций с битами, можно использовать язык не самого высокого уровня абстракции, тем более что программа будет слегка быстрее (VladD2: и то не факт).
Если вы пишете короткую программу, которую используете один раз и выбросите прочь, возможно, следует использовать тот язык, который имеет лучшие библиотечные функции для данной задачи.
Но в целом для программного обеспечения нужно использовать самый мощный (и приемлемо эффективный) язык из всех доступных. Отличный от этого выбор — это ошибка такого же рода, как программирование в машинных кодах, хотя и с меньшими негативными последствиями.
Понятно, что уровень машинного языка очень низок. А высокоуровневые языки часто рассматриваются как одинаковые, по-крайней мере, так принято считать. Но это не так. Технический термин "язык программирования высокого уровня" не обозначает ничего определенного. Не существует четкой границы между множеством "машинных" языков с одной стороны, и множеством "высокоуровневых" с другой. Языки распределены в континууме (возможно, не просто континуум, а некая структура, уменьшающаяся кверху;
важна здесь не форма, а сама идея о том, что существует, по крайней мере, частичный порядок) абстрактности, начиная от самых мощных "языков высокого уровня" вниз к "машинным языкам", которые, в свою очередь, тоже отличаются друг от друга по мощности.
Возьмем Cobol. Cobol — язык высокого уровня, так как компилируется в машинный язык. Но станет ли кто-нибудь утверждать, что по мощности Cobol эквивалентен, скажем, Python-у? (VladD2: учитывая свой опыт общения на форумах RSDN скажу, что несомненно скажет ) Возможно, он ближе к машинному языку, чем Python.
А как насчет Perl четвертой версии? В Perl 5 в язык были добавлены лексические замыкания (lexical closures). Большинство Perl хакеров согласятся, что Perl 5 мощнее, чем Perl 4. Но раз вы это признали, вы признали, что один высокоуровневый язык может быть мощнее другого. Из этого неизбежно следует, что использовать нужно самый мощный язык.
Впрочем, из этого утверждения редко делается вывод. Программисты старше определенного возраста редко меняют язык по своей воле. Они будут считать достаточно хорошим тот язык, к которому привыкли.
Программисты очень привязываются к своим любимым языкам, а я не хочу оскорбить ничьи чувства, поэтому я объясню свою позицию, используя гипотетический язык с названием Блаб.
Блаб попадает в середину континуума абстрактности. Это не самый мощный язык, но он мощнее, чем Cobol или машинный язык.
И на самом деле, наш гипотетический программист на Блабе не будет использовать ни Cobol, ни машинный код. Для машинных кодов есть компиляторы. Что же касается Cobol-а, наш программист не знает, как на этом языке вообще что-то можно сделать. В Cobol-е ведь даже нет возможности X, присутствующей в Блабе!
Когда наш гипотетический Блаб-программист смотрит вниз на континуум мощности языков, он знает, что смотрит вниз. Менее мощные, чем Блаб, языки явно менее мощны, так как в них нет некой особенности, к которой привык программист. Но когда он смотрит в другом направлении, вверх, он не осознает, что смотрит вверх. То, что он видит, — это просто "странные" языки. Возможно, он считает их одинаковыми с Блабом по мощности, но со всяческими сложными штучками. Блаба для нашего программиста вполне достаточно, так как он думает на Блабе (выделено мной – VladD2).
Когда мы поменяем точку обзора программиста, используя любой язык программирования выше по континууму мощности, мы обнаружим, что теперь программист смотрит на Блаб сверху вниз. «Как же можно что-то сделать, используя Блаб? В нем отсутствует даже конструкция Y!»
Используя метод индукции, приходишь к выводу, что только те программисты, которые понимают самый мощный язык, в состоянии осознать полную картину разницы в мощности между различными языками (видимо, именно это имел ввиду Эрик Реймонд, когда говорил о том, что Lisp сделает вас лучше как программиста). Следуя парадоксу Блаба, нельзя доверять мнению других: другие программисты довольны тем языком, который используют, потому что этот язык определяет способ их программистского мышления.
Я знаю это из своего опыта, когда учился в старших классах школы и писал программы на Бейсике. Этот язык не поддерживал даже рекурсию. Трудно представить написание программ без рекурсии, но в то время мне это было не нужно. Я думал на Бейсике. Я был спец. Мастер всего, что изучил.
Пять языков, которые советует хакерам Эрик Реймонд, находятся в разных точках континуума мощности, и то, где они находятся относительно друг друга, — тонкий вопрос. Я скажу, что Lisp находится на вершине континуума. И чтобы поддержать это утверждение, я скажу о том, чего мне не хватает, когда я смотрю на остальные пять языков. Как же можно что-то сделать с ними, думаю я, без свойства Z? И самое большое Z — это макросы. (Рассматривать макросы как отдельное свойство — это немного неправильно. На практике их польза увеличивается такими свойствами Lisp'а, как лексические замыкания и частичная параметризация (rest parameters) – аналогичная возможность в Nemerle назевается «частично применение (partial application) – VladD2».
Во многих языках есть что-то, называющееся макросом. Но макросы в Lisp'е уникальны (на сегодня это так только если глядеть на другие языка с высоты Lisp-а, но об этом позже – VladD2). То, что делают макросы имеет отношение, верите вы или нет, к скобкам. Создатели Lisp'а добавили все эти скобки в язык не для того, чтобы отличаться от других. Скобки в Lisp'е имеют особый смысл, они — внешнее свидетельство фундаментальной разницы между Lisp'ом и другими языками.
Программа на Lisp'е состоит из данных. И не в том тривиальном значении, что исходные файлы содержат символы, а строки — один из типов данных, поддерживаемых языком. После прочтения программы парсером Lisp код состоит из готового к использованию дерева структур данных.
Дело не в том, что в Lisp'е странный синтаксис, скорее, его нет вообще. Программы пишутся в готовых синтаксических деревьях, которые в других языках генерируются парсером во время разбора исходного текста. Эти синтаксические деревья в Lisp'е полностью доступны вашим программам, и вы можете писать программы, которые изменяют эти деревья. В Lisp'е подобные программы называются макросы. Это программы, которые пишут программы.
Программы, которые пишут программы? И когда же такое может понадобиться?
Не очень часто, если вы думаете на Cobol'е. И постоянно, если вы думаете на Lisp'е. Было бы удобно, если бы я дал пример мощного макроса и сказал бы: "Вот! Смотрите!". Но если бы я и привел пример, для того, кто не знает Lisp, он выглядел бы не более чем белиберда. Рамки данной статьи не позволяют изложить все необходимое для понимания подобного примера. В книге Ansi Common Lisp я старался излагать материал как можно быстрее, но даже так я не добрался до макросов раньше страницы 160.
Однако мне кажется, что я могу дать убедительный аргумент. Исходный текст редактора Viaweb на 20-25 процентов состоял из макросов. Макросы сложнее писать, чем обычные функции Lisp'а, и считается дурным тоном использовать их там, где можно без них обойтись. Поэтому каждый макрос в той программе был необходим. Это значит, что примерно 20-25 процентов кода в программе делают то, что нельзя просто сделать на других языках.
Как бы скептически ни относился Блаб-программист к моим заявлениям о таинственной мощи Lisp'а, это должно его заинтересовать. Мы не писали этот код для своего собственного развлечения. Мы были маленькой компанией, и программировали так, как только могли, чтобы возвести технологический барьер между нами и нашими конкурентами.
Пытливый читатель может задаться вопросом, а нет ли здесь взаимосвязи? Некоторая большая часть кода делала нечто, что очень сложно сделать на других языках. Получившееся в результате программное обеспечение делало то, что программное обеспечение наших соперников делать не могло. Возможно, между этими фактами есть связь. Я советую вам подумать в этом направлении. Возможно, это все не просто старческие бредни.
ЗХ> ЗХ> ЗХ>Другое дело, что (холивар! холивар!) я, честно говоря, не вижу, какие из возможностей Nemerle делают его на порядок круче других языков с поддержкой ОО и функционального программирования (примем, что синтаксические макросы — мощный, но не единственный инструмент контроля синтаксиса; а type inference увеличивает более надежность, нежели продуктивность).
Может быть не хочешь видить? Или не можешь увидить?
Ладно, попробую объяснить. Но как не странно вопрос этот не так прост.
Дело в тмо, что Грехем ошибается когда говорит о континуме языков как о прямой линии. Раельно континум языков многомерен. Есть разные направления совершенствования ЯП (повышения их мощьности в теминалогии Грехема). И разные языки приуспевают в разных измерениях.
Чтобы не заниматься бездарной философией коей уподабляются почти все в этой теме предлагаю уйти от умных слов вроде котнинума и использовать более приземленное поняитие — возможности (фичи).
Какими возможностями обладает Nemerle? Кстати, прежде чем продолжить хочу заметить, что эту тему превратил в тему "Казалось бы причем тут Немерле?" не я, и даже не Вольфхаунд. Так что не надо с больной головы на здоровую (это я нашим уважаемым аксокалам, стрпер все же как то не красиво ). Если чесно, то я уже переболел стадией восхищения и неуверенности. Моя позиция по поводу этого языка полностью сформировалась. Он и Скала это будущее мэйнстрима и все кто ждет стада чтобы последовать за ним, не всилах преодолеть свои привычки или кому просто не нравится дотнет или ява меня попросту не интересуют. Так что просьба воспринимать мой ответ исклчительно как мое мнение, а не предложение поспорить.
Это элементарно. Вот его краткое описание:
1. Статически тпизированный язык с возможностью явной динамики. Это не ново так как дотнет, Ява даже VB 4-6 уже давно дают подобные возможности. Собственно тут у Непреле много соседей: (речь идет только о мэнйстриме, так что не задавайте вопросы "а почему нет языка Х?". Эрлэнг и Скалу я приплел откровенно говоря не корректно, но все же это языки о которых в послденее время говорят, а значит они интересены в нашем анализе) С, С++, Паскаль, Дельфи, Ява, C#, O'Caml, VB, Хаскель, Скала. Причем С, С++, Хаскель и O'Caml не предоставляют управляемых динамических возможностей, а стало быт менее мощьны.
2. Типобезопасный язык. Тут аналогами будут: Ява, C#, O'Caml, VB, Хаскель и динамические JScript, Руби, Питон, Смолток, Скала и Эрлэнг.
3. Строгость. Я понимаю под этим словом то как компилятор пытается выявить проблемы в программе. Тут среди реальных конкурентов прорисовываются уже только C#, O'Caml, Скала и Хаскель. Причем допускаю, что O'Caml и Хаскель имеют даже более мощьный контроль кода.
4. Функции как первоклассные значения. (ФВП — это просто не верный термин, так как почти во всех современных ЯП есть ФВП). Тут конкурентами Немерле являются: C#, Руби, Питон, Смолток, O'Caml, Хаскель, Скала, Эрэнг. Причем только O'Caml и Хаскель столь же мощьны как Немерле. Отсальные языки как имеют те или иные проблемы в этом вопросе. Ну, да не странно, ведь кроме Эрлэнга остальные языки не принято называть ФЯ.
5. Сопоставление с образцом (pattrn matching) и алгеброические типы. Тут конкуренты: O'Caml, Хаскель, Скала и Эрэнг. Причем сопоставление с образцом это настолько мощьная вещь в плане повышения мощьности языка, что уже одного его отсуствия достаточно, чтобы назвать язык устаревшим. Конечно все тоже самое можно делат на if-ах, но паттерн-матчинг позволяет решать многие задачи куда проще. Он реально повышает уровень программ.
6. Вывод типов. Спорный вопрос, но все же я считаю, что опускание лишних деталей позволяет делать код несколько более высокоуровневым. К тому же код реально становится более кратким. Это само по себе не приемущество, но без этого просто не мыслемо применение функционального стиля. Современный C# (2.0) отлично демонстрирует, что без вывода типов использование функционального стиля становится не эффективным. Здесь у нас конкуренты: Скала, Хаскель, ОКамл и все скрипты.
7. ООП. Тут с одной стороны конкурентов много, но с другой качественная реализация ООП есть далеко не везде. Например, Питон я точно не могу назвать качествнной реалзацией. Руби чуть лушче, но все же тоже не дотягивет. Но в любом случае из этого списка резко исчизают Хаскель и Эрлэнг.
8. Автоматическое управление памятью. Тут опять проще говорить о том, кто выбывает. Это конечно же С++.
9. Умная IDE, отладка и другие прелести автоматизации программирования и проектирования. Тут пожалуй единственный пункт где пока что в аутсайдерах сам Немерле, а лидерами являются C# и Java (возможно в скором времени дела будут неплзхо обстаять и у Скалы). Однако мы лично работаем над устранением этого недостатка и в ближайшем будущем у Немерла появится IDE не хуже чем у лидеров. Причем я отвественно заявляю, что Риби и Питон вообще никогда не получат IDE такого качества, потому что эти языки не предоставляют нужной метаинформации во время разработки. Ну, разве что для них напишут подсистему вывода типов, но тогда эти языки перейдут в другой класс и сделают нехилый шаг по направлению Немерлетизации .
10. Возможности расширения. Тут конкуренты только O'Caml и Lisp. Причем оба языка резко проигрывают Немерле так как не позволяют получать метаинформацию о типах. Это делает их значительно менее мощьными. С другой стороны нельзя не отметить, что возможности по модификации АСТ у Лиспа и даже у O'Caml-а несколько выше. Хотя реально это мало что дает, так как возможности по модификации АСТ у Немерле тоже нехилые. Кстати, это пожалуй единственный пункт где из списка на прочь выбывает скала. По поводу скриптов можно сказать, что с одной стороны те их них что поддерживают метапрограммирование тоже вохоят в эту категорию, но с другой их метапрограммирование не позволяет серьезно менять синтаксис. Хотя тут я могу ошибаться. Так что можно оставить их вписывание сюда на усмотрение читателя.
11. Встроенная поддержка параллелизма. Тут в списке остается только Эрлэнг. Но Немерле, ОКамл и Лисп позволяют добавить подобнрые фрэймворки в виде библиотеки. Так что пункт не столь очевиден.
12. Производительность получаемого кода. Тут у нас резко пролетают все скрипты. Причины даже не хочется обсуждать. Разговоры о компиляции мне тоже тут не интересны. Чудес не бывает. Или это уже будет не скрпт, или он будет фигово компилироваться.
Теперь остается пробежать список и понять, что в итоге Немерле остался в одиночистве. Все конкуренты отсеялись на тех или иных этапах.
Конечно можно сказать, что кому-то некоторые пункты могут оказаться не важными, но факт отсается фактом.
Ближе всех, что не удивительно, к Немерлу подобралась Скала. Из "старичков" пожалуй ближе всех ОКамл. Но в виду полной не дружбы с динамикой, весьма странного для мэйнстрима синтаксиса и некоторых других особенностей лично я его не рассматриваю как серозного конкурента. Мэйнстрима ему никогда не видать. Однако для некоторых задач некоторым людям он может оказаться неплохим выбором.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Первое что хочется сказать, что все перчисленной не полностью лежит на моей совести.
MS>Вот сначала был MS-DOS и язык Си. ...оргазма — Ооо!... MS>Потом пошел Windows — ...Ооо! ...круто! MS>Потом ... C++ ...MFC. ...оргазма — Ооо... MS>Потом ...OLE и OLE2 ....оргазма — Ооо... MS>Потом ...ATL ...Ооо! Круто... MS>....венгерская нотация это правильно и круто.... если ты не используешь венгерскую нотацию, то ты неуч...Ооо, круто! MS>Потом ...венгерская нотация ...Выплюньте! ...оргазма — Ооо! MS>Потом ...C# ...оргазма — Ооо MS>Ну а теперь кто-то вбросил девку по имени Nemerle в полк.
Я искренне удивлен такому восприятию этого сообщения. Все что здесь перечисленно — это всго лишь прогресс! Точнее наблюдение за прогрессом одного из людей. Наблюдения из своей узкой нишки. Такие же наблюдения были и у тех кто кричал Юникс... оргазм... Линукс... оркгазм... паймы... оргразм... ну и т.п. в перемешку с "ооо... оргазм".
Я не пойму, что кто-то был такой умный, что еще выходя из под сотла пешком знал, что дос и С это плохо? Или что плохо АТЛ или еще что-то?
Я прошел очень похожую школу и не вижу ничего удивительного или странного в перечисленном. Разберем списочек еще раз.
MS>Вот сначала был MS-DOS и язык Си. ...оргазма — Ооо!...
Ага. До этого были БВК и ХЗЧ с корированием в маш-кодах с журнала Раидио или ЕС-ХХХХ с 40 килобайтами оперативки на полк, делением времени между этим полком, вылетами на каждом шагу, перфокартами, отладкой по листинку размером в коробку бумаги и т.п.
Да после этого персоонралка с личными 640 килами памяти, личным же винтом и Си были даже не Ооо... орказм... А ААА!!!! ЁЁЁ УУУУУУУУУУУУУУУУУУУ . Но потом все приелось. Памтяи стало больше, языки лучше... мы подросли.
MS>Потом пошел Windows — ...Ооо! ...круто!
Да потом было Windows с все тем же Си. Но он уже не казался стольк крут. Зато ГУИ бы действительно крут. А программировать его в собитийной иделолгии было действительно здорово. И это действительно было круто... тогда... для многих...
MS>Потом ... C++ ...MFC. ...оргазма — Ооо...
Да, потом был С++ и Дельфи. У кого-то МФЦ, у кого-то ВЦЛ, а у кого-то вообще ОпенЖЛ и это действительно было круто... тогда!
Но многие так и остались на С++ и Дельфи.
MS>Потом ...OLE и OLE2 ....оргазма — Ооо...
Да, потом был COM! И это действительно было круто. А те кто в это время уже не смог вэехать, в что что динамика и компонетность предоставляет новые возможности уже тогда начали ворчать...
Но многие так и остались на COM.
MS>Потом ...ATL ...Ооо! Круто...
Да, да. И это действительно было круто!!! КОМ стал не только интересен архитектурно, но его уже стало возможно писать и писать относительно не соложно. Многие в это же время заметили разные ВБ котоыре упрощали работу с КОМ-ом куда более радикально. И это позволило им начать размышлять над тем, что все таки в С++ и АТЛ что-то не так.
Но многие так и остались на ATL.
MS>....венгерская нотация это правильно и круто.... если ты не используешь венгерскую нотацию, то ты неуч...Ооо, круто!
Но многие так и остались на венгерске...
MS>Потом ...венгерская нотация ...Выплюньте! ...оргазма — Ооо!
Но многие так и остались на выплюньте венгерку...
MS>Потом ...C# ...оргазма — Ооо
Но многие так и остались на C#.
MS>Ну а теперь кто-то вбросил девку по имени Nemerle в полк.
Но многие так и останутся на...
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, PhantomIvan, Вы писали:
PI>если бы не это неприятие в сущности хай-ендового языка,
На самом деле нет никакого неприятия. Наши замечательны критики вообще не пробовали то что они критикуют. Те кто пробовали уже как минимум говорят куда осторожнее.
Ну, а основные крикуны кричат даже не потому, что им не нравится язык или еще что. Их больше всего раздражает, что об этом говрю я. И у меня не мания величия.
Защищать же Немерле просто нет необходимости. Тут некому и нечего доказывать. Они и сами понимают перспективность языка, но свои личные роблемы (от лени, но ориентации на черт знает какие платформы) не мозволяет им это сделать.
Факт в том, что люди реально пописавшие на этом зяыке в течении месяца уже ничего плохого о языке не говорят.
Что касается пропаганды, то я уже просто ржу под сталом читая этот форум. В нем с утра до вечера группа дображелателей поминает мое имя в суе в то врея как я эти темы еще не читал.
На лицо четкая контрпропагада. От сюда и все это дерьмо льющееся в мою сторону. Ну, да это змечательно, так как мы вместе работаем на одно доброе дело. Мы популяризируем новый перспективый грамотно спроектированный язык. Так что еао197 я по праву могу назвать своим коллегой. Он уже давно популяризирует Немерле бльше меня. А ведь я занимаюсь этим специально, а он явно на по зову души!
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
E>Продвижение в этой области + возможно еще некоторое улучшение в документации / тьюториалах, по моему мнению, — хороший план развития для Nemerle.
E>Проблема в том, что у меня и Михал не так-то много времени для этого, учитывая, что (особенно для Михала) это не очень "интересная" работа...
E>Не очень-то лично мне хочется запускать в коммерческую эксплуатацию систему, написанную на языке, у авторов которого нет времени на исправления в нем ошибок.
Думаещь откровенная ложь сможет изменить мнение людей? Ведь любой находящийся в зравом уме понимает, что из процитированных слов никак нельзя сделать вывод, что у автор "нет времени на исправления в нем ошибок". Эти слова означают, что ребята банально работают на основной работе и время их ограничено. Дай бог каждому исправлять ошибки так быстро как это делают они. По карйней мере они это делают намного лучше чем автор Ди.
Уверен, что релиз Немерле будет в первой половине 2007 года. Так что ожешь каверкать слова как хочешь. В отличии от Гебельса чем чудовещнее твоя ложь, тем смешнее будет смотреть на нее через каких-то пол года.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
E>Well, as you probably noticed our support for implementing features and fixing bugs is not very fast.
E>ошибки в компиляторе или в языке? E>В любом случае разработчики поддвержают, что где-то ошибки есть и быстро исправлять они их не могут.
Давай я расшифрую. Мужики обладают редким качеством в наши дни — скромностью. Они считаю, что их работ не так быстра как хотелось бы. Хотя лично я оцениваю ее очень даже неплхой. Особенно если учесть, что ее фактически делают два человека.
Так что прежде чем выхваить цитату из контекста и начать делать далеко идущие выводы лучше дочитать до конца и проанализировать общую суть сказанного. А сказано в общем-то то, что язык будут доводить до ума и релизить. Причем в ближайшем будущем.
Наша интеграция тоже потихоничку выходит к состоянию когда ее можно будет использовать. И скорее всего язык будет зарелизен вместе с ней. Интересно много в мире релизится зыков (не монстро-корпорациями) сразу с поддержкой IDE?
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Ну, на конец-то вы заговорили о чем-то интресном. Пофлэйммим...
ЗХ>>Тут интересная корреляция с понятием "мощности" языка (по-моему у Грэма где-то есть об этом, когда он Лисп воспевает): добавление в язык некоторых "фич" увеличивает лаконичность и выразительность кода действительно на порядки.
VD>Ага. У него есть замечательная притча о Блаб-программисте: VD>http://www.nestor.minsk.by/sr/2003/07/30710.html
Угу, я именно это и имел в виду
ЗХ>> ЗХ>> ЗХ>>Другое дело, что (холивар! холивар!) я, честно говоря, не вижу, какие из возможностей Nemerle делают его на порядок круче других языков с поддержкой ОО и функционального программирования (примем, что синтаксические макросы — мощный, но не единственный инструмент контроля синтаксиса; а type inference увеличивает более надежность, нежели продуктивность).
VD>Может быть не хочешь видить?
"не хотеть" — мне неинтересно.
Я, как известно, бездельник с широким кругом интересов. То есть я могу себе позволить к абсолютно любой новой идее относиться как "так, что здесь новенького и как это поможет change my mind?" (If It's Not Nailed Down, Steal It — Если это не прибито, укради это).
У меня в принципе нет технологии, которую я собираюсь защищать всю жизнь. Любая новая технология оценивается с 2ух точек зрения:
1. не стоит ли мне перейти на нее прямо сейчас? (не будет ли мне с ней настолько комфортнее, что оно того стоит)
2. какие тут есть новые интересные невиданные мной идеи?
По пункту (1) я Немерл не рассматриваю из-за чисто технических причин (я не хочу быть привязанным к .Net и не собираюсь эту тему обсуждать); по пункту (2) я его ковыряю потихоньку и согласен признать, что в нем куча интересного.
VD>Или не можешь увидить?
Ну, тут я ничего не могу сказать. Если я не могу увидеть, скорее всего я и не вижу, чего я не вижу
VD>Ладно, попробую объяснить. Но как не странно вопрос этот не так прост. VD>Дело в тмо, что Грехем ошибается когда говорит о континуме языков как о прямой линии. Раельно континум языков многомерен. Есть разные направления совершенствования ЯП (повышения их мощьности в теминалогии Грехема). И разные языки приуспевают в разных измерениях.
Допустим.
VD>Чтобы не заниматься бездарной философией коей уподабляются почти все в этой теме предлагаю уйти от умных слов вроде котнинума и использовать более приземленное поняитие — возможности (фичи).
Давай.
VD>Какими возможностями обладает Nemerle?
VD>Это элементарно. Вот его краткое описание: VD>1. Статически тпизированный язык с возможностью явной динамики. VD>2. Типобезопасный язык. VD>3. Строгость. VD>4. Функции как первоклассные значения. VD>5. Сопоставление с образцом (pattern matching) и алгеброические типы. VD>6. Вывод типов. VD>7. ООП. VD>8. Автоматическое управление памятью. VD>9. Умная IDE, отладка и другие прелести автоматизации программирования и проектирования. VD>10. Возможности расширения. VD>11. Встроенная поддержка параллелизма. VD>12. Производительность получаемого кода.
VD>Теперь остается пробежать список и понять, что в итоге Немерле остался в одиночистве. Все конкуренты отсеялись на тех или иных этапах.
VD>Конечно можно сказать, что кому-то некоторые пункты могут оказаться не важными, но факт отсается фактом.
(тут получился некоторый оверквотинг, но мне хотелось одновременно оставить полный список фич, и поговорить про некоторые отдельные фичи в подробностях)
Хотелось бы оговорить, что когда я говорил о "фичах, однозначно делающих язык на порядок более мощным" — я имел в виду именно фичи, про которые можно однозначно сказать есть/нет; те фичи, которые "бывает такое а бывает сякое", можно обсуждать только в рамках флейма (мощнее ли статическая типизация динамической — вопрос решаемый каждым для себя лично).
VD>3. Строгость. Я понимаю под этим словом то как компилятор пытается выявить проблемы в программе. Тут среди реальных конкурентов прорисовываются уже только C#, O'Caml, Скала и Хаскель. Причем допускаю, что O'Caml и Хаскель имеют даже более мощьный контроль кода.
Да, здесь я в общем готов согласиться, что возможность гибко и мощно задавать ограничения, проверяемые все скопом _до_ начала выполнения, можно считать очень мощной возможностью.
То есть я-то лично привык писать в парадигме "сделай настолько маленький модуль, что в нем физически не может быть ошибок", но когда мне приходится возвращаться "к реальности" (решать "некрасивые" задачи вроде автоматизации производства) этого зачастую оказывается недостаточно.
VD>4. Функции как первоклассные значения. (ФВП — это просто не верный термин, так как почти во всех современных ЯП есть ФВП). Тут конкурентами Немерле являются: C#, Руби, Питон, Смолток, O'Caml, Хаскель, Скала, Эрэнг. Причем только O'Caml и Хаскель столь же мощьны как Немерле. Отсальные языки как имеют те или иные проблемы в этом вопросе.
Интересно. Можно подробнее?
VD>5. Сопоставление с образцом (pattrn matching) и алгеброические типы.
Вот как раз сопоставление с образцом я не упомянул среди радикально крутых фич Немерла — исключительно потому, что язык с разумно гибким синтаксисом таки позволяет сделать это в виде библиотеки.
#это воспроизведение кусочка вашего спора с Мамутом Nemerle vs. Erlang. И это чистый Рубиdef printTag(*arg)
arg.pmatch(String){|tag|
printTag(tag, [])
} ||
arg.pmatch(String, []){|tag|
"<#{tag}>"
} ||
arg.pmatch(String, Array){|tag, attr|
"<#{tag}#{printAttrs(attr)}>"
} ||
arg.nomatch!
end
VD>7. ООП. Тут с одной стороны конкурентов много, но с другой качественная реализация ООП есть далеко не везде. Например, Питон я точно не могу назвать качествнной реалзацией. Руби чуть лушче, но все же тоже не дотягивет.
И это, если можно, подробнее немножко.
VD>9. Умная IDE, отладка и другие прелести автоматизации программирования и проектирования. [...] Причем я отвественно заявляю, что Риби и Питон вообще никогда не получат IDE такого качества, [...]
Ну, это опять же кусочек бесконечного флейма. Я не готов в него опять встрять.
С одной стороны, перейдя с какой-никакой IDE (VC++) на полностью текстовые файлы + командный интерпретатор (Ruby и command-line tools из VS), я чувствую себя вполне неплохо.
С другой стороны, я не выполнял существенных объемов работы на языках с серьезным IDE с поддержкой рефакторинга, то есть просто не знаю вкуса устриц.
VD>10. Возможности расширения. [...] По поводу скриптов можно сказать, что с одной стороны те их них что поддерживают метапрограммирование тоже вохоят в эту категорию, но с другой их метапрограммирование не позволяет серьезно менять синтаксис. Хотя тут я могу ошибаться. Так что можно оставить их вписывание сюда на усмотрение читателя.
Ну, необходимость серьезной смены синтаксиса — вопрос не вполне однозначный.
Скриптовые языки, хотя и не позволяют определить настолько явно новые элементы, как Немерле (то есть полный syntax definition) имеют разумную гибкость и лаконичность синтаксиса, чтобы считать их возможности расширения неплохими.
VD>12. Производительность получаемого кода. Тут у нас резко пролетают все скрипты.
Ну, тут же опять можно вернуться к вопросу "достаточной производительности". Поэтому мне тяжело назвать это "фичей, повышающей мощность на порядок".
Итого, (не считая пока фич, для которых я попросил объяснений), остается статическая типизация и ее производные (строгость, серьезная поддержка со стороны IDE). Так?
Здравствуйте, VladD2, Вы писали:
VD>Я искренне удивлен такому восприятию этого сообщения.
Влад, да не парься ты так. Я же не со зла — чисто дурака повалять захотелось. Жизнь человека состоит из перманентной рутины и редких моментов веселья. Ну и вот.
Кстати, ситуация с COM/OLE навевает мне закон Мэрфи — "Если начальник приказал что-то сделать, не спеши. Может поступить отменяющее указание". Все эти комы и оле я никогда не понимал. Ну потому что создавалось впечатление, что это все — не более чем куча говнища, копаться в которой не очень приятно. И теперь вся эта куча пролетела мимо меня как фанера над Парижем. Есть повод задуматься...
McSeem
Я жертва цепи несчастных случайностей. Как и все мы.
Здравствуйте, VladD2, Вы писали:
VD>Защищать же Немерле просто нет необходимости.
Есть! Законы социума таковы, что любую, даже самую прогрессивную идею надо продвигать. И продвигается она всегда с усилиями. Так всегда было и будет.
VD>Что касается пропаганды, то я уже просто ржу под сталом читая этот форум. В нем с утра до вечера группа дображелателей поминает мое имя в суе в то врея как я эти темы еще не читал.
Влад, ты не понимаешь сущности. В пропаганде чего-то нового ты действуешь как типичный science-freak, говоря что все предыдущее — это полная #####. Чем отличается нормальный учёный от фрика? Нормальный ученый никогда не отрицает предыдущих теорий. Типа что, после ОТО Энштейна Ньютоновская физика сразу утратила смысл?! Да нет, не утратила. Мы до сих пор ей замечательно пользуемся, в игровых моделях в том числе. Даже более того — геоцентрическая система Птолемея до сих пор имеет смысл. Если я моряк в океане и мне надо сориентироваться по звездам и планетам, то какая мне на фиг разница, что там вокруг чего во Вселенной вертится?!
А ты как раз и строишь свою аргументацию на полной отстойности всего что было. А не на преимуществах нового. Понимаешь в чем разница? То есть, ты действуешь по типичной схеме саенс-фрика, на корню отвергающего квантовую физику. Неправильно это, этим ты ничего не добьешься кроме личной неприязни.
Мат запикан. — Кодт
McSeem
Я жертва цепи несчастных случайностей. Как и все мы.
Здравствуйте, PhantomIvan, Вы писали:
PI>вот мы плавно подошли к противоречию: PI>предположим, все 4 у тебя — "светлые головы" PI>одно из двух: либо задача делится на 4 равные части, либо к примеру, это одна функционально односвязная часть. PI>если первое, то каждый из твоих программеров — как бы хирург, лишенный помощи своей "операционной бригады" (тестирует сам, документирует сам, утилиты пишет сам)
Тестеры отдельно, программисты отдельно.
Юнит тесты пишутся программистами.
Документация пишется во время разработки благо набрать три слеша и получить заглушку для описания метода не сложно. И кому лучше знать, как описать функцию, если не программисту, который ее реализовывал. + Практика Review, которая проверяет не только код, но и комментарии\документацию к нему. Что мы делаем не так ? PI> смещаются на менее "умные" задачи — типа написания юнит-тестов.
Написать хороший юнит тест сможет только программист, который отвечает за реализацию. А полноценные тесты на развернутой системе, это уже тестер естественно. PI>(для юнит-тестов нужен менее опытный в программировании тестер).
-1
... << RSDN@Home 1.2.0 Therion — Under Jolly Roger >>
Здравствуйте, PhantomIvan, Вы писали:
PI> типично русский подход "наберём студентов и научим их" бруксом не рассматривается.
Этот "типично русский подход" работает и в Индии, и в Китае, и в Японии. Такие дела.
PI> напоминаю, Брукс работал в IBM — туда студентов не нанимали.
Меня терзают смутные сомнения (с)
Здравствуйте, McSeem2, Вы писали:
MS>Кстати, ситуация с COM/OLE навевает мне закон Мэрфи — "Если начальник приказал что-то сделать, не спеши. Может поступить отменяющее указание". Все эти комы и оле я никогда не понимал.
Когда я на 2-м курсе института, понял что из простейшей программы на Делфи я могу использовать возможность вордового спеллчекера, это просто разорвало мой мозг. Ведь можно встроить точно так же и Эксель, и Фотошоп, и... Это было ощущение неограниченных возможностей. СОМ — это А чем отличаются OLE, COM, ActiveX, я до сих пор не знаю
Зы. Директ Х тоже предоставляет небор COM интерфейсов. Без них не было бы так просто подключать различные кодеки к проигрывателю. Более того, различные проигрыватели используют одни и те же кодеки, установленные в системе. И это хорошо.
... << RSDN@Home 1.2.0 Offspring, The — Have you ever >>
M>Зы. Директ Х тоже предоставляет небор COM интерфейсов. Без них не было бы так просто подключать различные кодеки к проигрывателю.
Имелось ввиду без СОМ интерфейсов вообще, а не именно ДиректХ-совых.
... << RSDN@Home 1.2.0 Offspring, The — Have you ever >>
Здравствуйте, VladD2, Вы писали:
VD>Теперь остается пробежать список и понять, что в итоге Немерле остался в одиночистве. Все конкуренты отсеялись на тех или иных этапах.
Очень похоже, что есть четыре градации лжи: просто ложь, наглая ложь, статистика и сравнение языков программирования от VladD2.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, VladD2, Вы писали:
VD>Так что прежде чем выхваить цитату из контекста и начать делать далеко идущие выводы лучше дочитать до конца и проанализировать общую суть сказанного. А сказано в общем-то то, что язык будут доводить до ума и релизить. Причем в ближайшем будущем.
Как раз это лично для меня и означает, что в данный момент рискованно ставить свою зарплату и свои проекты в прямую зависимость от языка, который еще будут доводить до ума.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Небольшая поправочка. Немерле включает в себя практически все полезные идеи языков, который были до него. Точно так же, как теория относительности включает в себя физику Ньютона как частный случай.
Так что никто не говорит "всё, что было раньше — отстой". Это ты уже сам выдумал.
Здравствуйте, eao197, Вы писали:
E>Но на подходе мы, скептики и консерваторы. Для которых новый язык это всего лишь лишние заморочки по переходу на новый инструмент.
Отсутствие интереса к новому — верный признак профессионального загнивания. Так что я надеюсь, вы не будете спешить.
— но судя по всему, образовательная система по части софт-технологий у них на высоте. 
