[флейм] perl - гавно
Согласен.
Perl совсем-совсем непригоден? Вот жалость.
Это где-то на microsoft.com написано?
Это где-то на microsoft.com написано?
:Нет, собственный вывод
Это где-то на microsoft.com написано?
:Ну я вообще не сторонник флеймваров, в особенности про Perl
Perl совсем-совсем непригоден? Вот жалость.
Сам больше 3 лет под mod_perl писал... Но пока ещё не слышал о крупном продукте/решении, где бы Perl играл ключевую роль.
> Но пока ещё не слышал о крупном продукте/решении, где бы Perl играл ключевую роль.
А что, есть какие-то проблемы, чтоб их решать?
Люди не продукты и решения ищут, а просто берут и делают как им надо.
Подборка success stories находится гуглом за 5 минут.
А что, есть какие-то проблемы, чтоб их решать?
Люди не продукты и решения ищут, а просто берут и делают как им надо.
Подборка success stories находится гуглом за 5 минут.
:Я вроде чётко написал, что непригоден именно в большой, промышленной разработке.
Люди не продукты и решения ищут, а просто берут и делают как им надо.
Я вроде чётко написал про гугл.
Ну и? Думаешь, я этих success stories за годы программирования на перле не начитался? Среди них нет ни одной системы, где бы заказчик платил, скажем, больше 50 килобаксов в год за поддержку и где бы perl являлся ключевой технологией.
> Среди них нет ни одной системы, где бы заказчик платил, скажем, больше 50 килобаксов в год за поддержку
Дешевизна поддержки - это теперь недостаток технологии?
Дешевизна поддержки - это теперь недостаток технологии?
Одну и ту же яму выкопать можно
1) сотней солдат с сапёрными лопатками;
2) одним человеком на экскаваторе.
В армии предпочитают способ (1 так как это тогда получается большая промышленная разработка.
1) сотней солдат с сапёрными лопатками;
2) одним человеком на экскаваторе.
В армии предпочитают способ (1 так как это тогда получается большая промышленная разработка.
Ок, берём - real time gross settlement system. Система, нужная в любой стране мира. Вот тебе пример большой системы.
На перле таких систем пока не написали Если вдруг напишут - может дешевле поддержка будет, а пока - так. Только навряд ли напишут 
На перле таких систем пока не написали
Если вдруг напишут - может дешевле поддержка будет, а пока - так. Только навряд ли напишут > Система, нужная в любой стране мира.
Объясняю.
Каждому, кто сталкивается с этим, нужно как-то прикрыть свою жопу,
чтоб его не расстреляли как врага народа, или как террориста, в зависимости от традиций его страны.
Нужно, чтобы за каждый возможный провал было на кого-то другого показать пальцем, как на виновника.
Это - проблема, и ей нужно - именно решение.
Тут приходят на помощь большие компании, которых не расстреляешь,
и за несколько мегабаксов предоставляют нужное решение.
Синтаксис языка тут не играет никакой роли.
Объясняю.
Каждому, кто сталкивается с этим, нужно как-то прикрыть свою жопу,
чтоб его не расстреляли как врага народа, или как террориста, в зависимости от традиций его страны.
Нужно, чтобы за каждый возможный провал было на кого-то другого показать пальцем, как на виновника.
Это - проблема, и ей нужно - именно решение.
Тут приходят на помощь большие компании, которых не расстреляешь,
и за несколько мегабаксов предоставляют нужное решение.
Синтаксис языка тут не играет никакой роли.
Поискал гуглом про это дело, нашёл несколько рекламных буклетов.
Нигде не упомянуты языки, на которых оно реализовано.
Просто потому, что это неважно!
Нигде не упомянуты языки, на которых оно реализовано.
Просто потому, что это неважно!
Логично. Только это не открытие для меня.
Поверь, любая из этих больших компаний была бы счастлива, если бы могла взять, нанять нескольких суперрюхастых разработчиков на Perl, создать им все условия для творчества и в итоге за разумное время получить RTGS. Так нифига, чудес не бывает...
Поверь, любая из этих больших компаний была бы счастлива, если бы могла взять, нанять нескольких суперрюхастых разработчиков на Perl, создать им все условия для творчества и в итоге за разумное время получить RTGS. Так нифига, чудес не бывает...
> Поверь, любая из этих больших компаний была бы счастлива
А вот не верю. Обычно такое делается стартапами, а не большими компаниями.
А вот не верю. Обычно такое делается стартапами, а не большими компаниями.
> Нигде не упомянуты языки, на которых оно реализовано.
Ну так давая я тебе расскажу. Если современные системы, то C++. Если старые, на мейнфреймах ещё - тогда точно не знаю, но думаю, что что-нибудь более древнее типа кобола... Ни о каких Java и .NET как правило и речи нет. Разве что для веб-интерфейсов.
> Просто потому, что это неважно!
Конечно неважно - неважно для клиента, которому и предназначены эти буклеты. А разработчикам ещё как важно.
Ну так давая я тебе расскажу. Если современные системы, то C++. Если старые, на мейнфреймах ещё - тогда точно не знаю, но думаю, что что-нибудь более древнее типа кобола... Ни о каких Java и .NET как правило и речи нет. Разве что для веб-интерфейсов.
> Просто потому, что это неважно!
Конечно неважно - неважно для клиента, которому и предназначены эти буклеты. А разработчикам ещё как важно.
> Ну так давая я тебе расскажу. Если современные системы, то C++. Если старые, на мейнфреймах ещё - тогда точно не знаю, но думаю, что что-нибудь более
> древнее типа кобола...
Легко видеть, что синтаксис Perl позволяет писать не хуже, чем на этих языках.
То есть, дело не в этом.
> древнее типа кобола...
Легко видеть, что синтаксис Perl позволяет писать не хуже, чем на этих языках.
То есть, дело не в этом.
> А вот не верю. Обычно такое делается стартапами, а не большими компаниями.
Не знаю насчёт обычно, а в моём примере среди всех вендоров ни одного стартапа.
Не знаю насчёт обычно, а в моём примере среди всех вендоров ни одного стартапа.
:Именно. Писать, но не читать.
Легко видеть, что синтаксис Perl позволяет писать не хуже, чем на этих языках.
На С++ тоже хватает способов написать нечитаемый код.
Просто не надо так делать, и всё.
Просто не надо так делать, и всё.
> Не знаю насчёт обычно, а в моём примере среди всех вендоров ни одного стартапа.
Правильно, крупные заказы стартапам не дают, по причинам, изложенным выше.
Правильно, крупные заказы стартапам не дают, по причинам, изложенным выше.
Ага. Только программистов, качественно пишущих на C++ на рынке пока существенно больше, чем качественно пишущих Perl-программистов.
> Только программистов, качественно пишущих на C++ на рынке пока существенно больше
Фрагменты кода на C++, которые я видел в чужих программах, мне обычно были непонятны.
В отличии от кода на perl.
Ну и опять же, солдат с лопатами в армии больше, чем экскаваторов.
Фрагменты кода на C++, которые я видел в чужих программах, мне обычно были непонятны.
В отличии от кода на perl.
Ну и опять же, солдат с лопатами в армии больше, чем экскаваторов.
Талантливый "солдат с лопатой" к 40 годам становится "генералом" и рулит проектами, в которых участвуют куча солдат и экскаваторов. А у машиниста экскаватора далеко не такие радужные перспективы карьерного и профессионального роста.
Так и программисты на Перл: в больших компаниях они не водятся, а в маленьких компаниях потолок слишком низок.
Так и программисты на Перл: в больших компаниях они не водятся, а в маленьких компаниях потолок слишком низок.
У перла как минимум есть следующие минусы:
1. Перловые модули сложно продавать
2. Отсутствие IDE
3. Отсутствие технологий уровня JSP/ASP (по крайней мере я таких не видел)
4. Сложность стыковки с чужими модулями (как снизу, так и сверху).
5. Отсутствие статической типизации - сложность с оптимизацией критических мест.
6. АФАИК, работа с базами тоже происходит на низком уровне.
1. Перловые модули сложно продавать
2. Отсутствие IDE
3. Отсутствие технологий уровня JSP/ASP (по крайней мере я таких не видел)
4. Сложность стыковки с чужими модулями (как снизу, так и сверху).
5. Отсутствие статической типизации - сложность с оптимизацией критических мест.
6. АФАИК, работа с базами тоже происходит на низком уровне.
> Одну и ту же яму выкопать можно
> 1) сотней солдат с сапёрными лопатками;
> 2) одним человеком на экскаваторе.
Есть одно большое НО:
в большом проекте есть большой объем работы, который проще отдать "солдатам":
например, разработка формочек под капризы заказчика,
рисование отчетов,
настройка под конкретного заказчика
стыковка с другими программами
и т.д.
Соответственно всегда получается, что, кроме, эскаватора нужно еще несколько человек с лопатами, причем, у этих челов с лопатами - квалификация низкая.
Соответственно необходимы средства (язык, среда и т.д.) - которая позволяют легко совместить зскаватор и лопаты, а также сделать чтобы ошибки этих лопат были легко обнаружимы и несильно сказывались на работоспособности всей системы.
У перла - таких средств очень мало, у С++ - больше, у .Net-а/Java-ы еще больше.
> 1) сотней солдат с сапёрными лопатками;
> 2) одним человеком на экскаваторе.
Есть одно большое НО:
в большом проекте есть большой объем работы, который проще отдать "солдатам":
например, разработка формочек под капризы заказчика,
рисование отчетов,
настройка под конкретного заказчика
стыковка с другими программами
и т.д.
Соответственно всегда получается, что, кроме, эскаватора нужно еще несколько человек с лопатами, причем, у этих челов с лопатами - квалификация низкая.
Соответственно необходимы средства (язык, среда и т.д.) - которая позволяют легко совместить зскаватор и лопаты, а также сделать чтобы ошибки этих лопат были легко обнаружимы и несильно сказывались на работоспособности всей системы.
У перла - таких средств очень мало, у С++ - больше, у .Net-а/Java-ы еще больше.
> Талантливый "солдат с лопатой" к 40 годам становится "генералом"
Это если не только лопатой умеет орудовать.
> Так и программисты на Перл: в больших компаниях они не водятся, а в маленьких компаниях потолок слишком низок.
Не совсем так. Сегодняшняя маленькая компания завтра может стать крупной - раз.
В маленькой компании легче занять руководящую позицию - два.
"Программист на $lang" - неудачник по определению, в отличии от просто программиста - три.
Это если не только лопатой умеет орудовать.
> Так и программисты на Перл: в больших компаниях они не водятся, а в маленьких компаниях потолок слишком низок.
Не совсем так. Сегодняшняя маленькая компания завтра может стать крупной - раз.
В маленькой компании легче занять руководящую позицию - два.
"Программист на $lang" - неудачник по определению, в отличии от просто программиста - три.
> У перла как минимум есть следующие минусы:
ни один из которых не связан с богатым синтаксисом
ни один из которых не связан с богатым синтаксисом
> ни один из которых не связан с богатым синтаксисом
посмотри второе замечание
посмотри второе замечание
> У перла - таких средств очень мало, у С++ - больше, у .Net-а/Java-ы еще больше.
Только в нескольких областях, где всё уже поделено, и бодаются крупные компании вроде Microsoft, Sun и Oracle.
Другим оставлена лишь работа лопатами под присмотром прапорщика.
Только в нескольких областях, где всё уже поделено, и бодаются крупные компании вроде Microsoft, Sun и Oracle.
Другим оставлена лишь работа лопатами под присмотром прапорщика.
где можно увидеть строгое определение синтаксиса perl?
А нафига оно надо, без строгого определения семантики?
И я не говорю, что perl - идеальный язык, а говорю, что обычно его критики
не попадают в тазик.
И я не говорю, что perl - идеальный язык, а говорю, что обычно его критики
не попадают в тазик.
> Только в нескольких областях, где всё уже поделено, и бодаются крупные компании вроде Microsoft, Sun и Oracle.
При желании можешь и ты поучаствовать, также как участвует Borland, Rational и т.д., главное, чтобы у тебя был продукт, который позволяет совместить эскаватор и лопаты.
При желании можешь и ты поучаствовать, также как участвует Borland, Rational и т.д., главное, чтобы у тебя был продукт, который позволяет совместить эскаватор и лопаты.
с Perl 5 знакомы? Ну так вот это пример того, как немеряное количество syntactic sugar + многие годы развития могут сделать язык неприменимым в большой разработке (=промышленной разработке).perl позволяет программировать плохо. Не надо заявлять, что любая программа на perl плохая.
Ага. Только программистов, качественно пишущих на C++ на рынке пока существенно больше, чем качественно пишущих Perl-программистов.С этим согласен.
4. Сложность стыковки с чужими модулями (как снизу, так и сверху).В чём заключается?
Но пока ещё не слышал о крупном продукте/решении, где бы Perl играл ключевую роль.А что должен играть прям ключевую? вообще то создавался он совсем для другого. С парсингом логов, с работой с базой, генерацией отчетов, выборок и т.п. успешно справляется. Причем с большими объемами данных. Всегда считал, что пока ключевую роль отводится либо си++ (си либо java. А perl хороший всего лишь помощник.
Но пока ещё не слышал о крупном продукте/решении, где бы Perl играл ключевую роль.Request Tracker
Это rt крупный проект-то ?
Лично я знаю, что в проекте HSPComplete учавствуют порядка 20 perl программистов. Вот это еще более менее кандидат на крупные проекты
Лично я знаю, что в проекте HSPComplete учавствуют порядка 20 perl программистов. Вот это еще более менее кандидат на крупные проекты
а у вас веб на чём программируют?
> В чём заключается?
Невозможность статической линковки.
Проблемы с созданием и подключением dll-ек.
Невозможность статической линковки.
Проблемы с созданием и подключением dll-ек.
Только программистов, качественно пишущих на C++ на рынке пока существенно больше, чем качественно пишущих Perl-программистов.Я тут еще прокомментирую. Устраивался я на работу в компанию Inline. Прихожу к ним, и мне говорят: типа есть вакансия на perl и есть на С, что выбираешь? Только вот у ведущего perl программиста зарплата $1200, а y ведущего на С - $1400. Я им говорю: "А почему у perl программиста меньше?" Они говорят: "Ну потому что у них уровень ниже среднестатистически". Я говорю: "Вот я по собеседованию могу стать и тем и другим. Ясен пень, что я выберу С. Потому что из любви к искусству никто не будет терять 200 бачей. И так сделает каждый на моём месте. Таким образом, в итоге на место perl программиста вы возьмёте самого слабого из всех. А потом будете заявлять, что они слабее среднестатистически".
И мне кажется, что подобная политика весьма распостранена. Получается такая самоподдерживающаяся система, которую трудно разрушить.
> Невозможность статической линковки.
Зачем она нужна для языка интерпретатора? Как ты её себе представляешь?
> Проблемы с созданием и подключением dll-ек.
Насколько мне известно, в операционных системах UNIX проблем нет.
Зачем она нужна для языка интерпретатора? Как ты её себе представляешь?
> Проблемы с созданием и подключением dll-ек.
Насколько мне известно, в операционных системах UNIX проблем нет.
Это rt крупный проект-то ?Ну я не заявлял, что он самый крупный. Просто недавно видел его в инете и решил привести в пример.
perl, c
Тут вот еще какое соображение. Почти всегда чистые perl программисты начинали с веба и это оказало не самое хорошее влияние на качество их кода. В веб программировании очень часто качество не нужно, можно сляпать на коленке и все.
perl, cВот к вопросу о крупных проектах. Mail.ru, Rambler используют perl.
Тут вот еще какое соображение. Почти всегда чистые perl программисты начинали с веба и это оказало не самое хорошее влияние на качество их кода. В веб программировании очень часто качество не нужно, можно сляпать на коленке и все.Угу. Хотя мнение, что в вебе качество не нужно тоже необосновано. Просто сложилась такая традиция, что веб не требует качества, поэтому веб программисты дешевы и имеются в избытке. Если странный человек пытается делать качественно, то начальство смотрит на него косо: "тоже мне, системный архитектор нашелся". Как следствие мы имеем очередную самоподдерживающуюся систему.
Еще как правило в веб программировании
1) нужно делать все быстро
2) часто переделывать уже сделанную работу
Поэтому писать качественно, проектировать и продумывать систему - это непозволительная роскошь. Конкурентное преимущество имеет человек, который пишет быстро, который быстро может выдать на гора более-менее работающий результат. Увы, но такова жизнь.
1) нужно делать все быстро
2) часто переделывать уже сделанную работу
Поэтому писать качественно, проектировать и продумывать систему - это непозволительная роскошь. Конкурентное преимущество имеет человек, который пишет быстро, который быстро может выдать на гора более-менее работающий результат. Увы, но такова жизнь.
Самое главное, что в веб программирование - ошибки очень легко исправить.
Если в десктоп-софте (не говоря уже о hard-софте) цикл (реальная работа у пользователя - обнаружение ошибки - исправление - установка пользователю исправленной версии) - занимает месяцы, то в веб-софте - это часы/дни.
Также веб-софт монолитен, не надо задумываться о переносимости, работе с другим окружением и т.д.
Если в десктоп-софте (не говоря уже о hard-софте) цикл (реальная работа у пользователя - обнаружение ошибки - исправление - установка пользователю исправленной версии) - занимает месяцы, то в веб-софте - это часы/дни.
Также веб-софт монолитен, не надо задумываться о переносимости, работе с другим окружением и т.д.
Весело так мой пост переименовали в "perl - гавно". И это при том, что я на нём написал больше, чем на всех остальных языках вместе взятых
Здесь было высказано много интересных мыслей насчёт перла. Очень со многим из сказанного я согласен. Но хочу ещё раз подчеркнуть, что я хотел сказать в первом (теперь) моём посте про Perl.
Есть понятие "syntactic sugar". Кто-то (теперь уже в другой ветке) высказался в духе, что, грубо говоря, как добавят "syntactic sugar" в C# - будет круто. Я не уверен, что это будет полезно языку C#, потому что, как мне кажется, из-за этого он может не стать "промышленным" языком (как C, C++ и Java).
Здесь было высказано много интересных мыслей насчёт перла. Очень со многим из сказанного я согласен. Но хочу ещё раз подчеркнуть, что я хотел сказать в первом (теперь) моём посте про Perl.
Есть понятие "syntactic sugar". Кто-то (теперь уже в другой ветке) высказался в духе, что, грубо говоря, как добавят "syntactic sugar" в C# - будет круто. Я не уверен, что это будет полезно языку C#, потому что, как мне кажется, из-за этого он может не стать "промышленным" языком (как C, C++ и Java).
> Только вот у ведущего perl программиста зарплата $1200, а y ведущего на С - $1400.
Ага. У меня в фирме ещё круче. Perl и Python за языки программирования вообще не считают. Вот и приходится временами делать сайт на комбинациях типа PL/SQL + mod_plsql + XSLT.
Ага. У меня в фирме ещё круче. Perl и Python за языки программирования вообще не считают. Вот и приходится временами делать сайт на комбинациях типа PL/SQL + mod_plsql + XSLT.
P.S. Особый кайф - генерить Javascript на страницах при помощи XSLT: нормальную обработку ввода пользователей (всяческих ошибок в смысле) так проще сделать, чем на PL/SQL...
Особый кайф - генерить Javascript на страницах при помощи XSLT:нормальную обработку ввода пользователей (всяческих ошибок в смысле) так проще сделать, чем на PL/SQL...
это как ?
поясни плз.
или я что то совсем не понимаю - или ты пытаешься тут сравнить 2 принципиально разных типа контроля за вводом данных ..............
принципиально разных типа контроля за вводом данныхдумаю речь не о контроле, а о фидбэке контроля. Т.е. из pl\sql для простоты юзеру говорится только "шэф, все пропало" а не конкретно в каком поле какая ошибка, а это уже по возможности проверяется джаваскриптом на этапе ввода.
Ага, именно как сказал. Сайт для интранета + сделать надо было максимально быстро, поэтому один уровень проверки - на клиентах.
> главное, чтобы у тебя был продукт, который позволяет совместить эскаватор и лопаты.
не только продукт, а ещё и новая область применения, не занятая пока гигантами
то есть придумывать что-то чуть-чуть получше, чем тот же C# и .Net framework, не имеет смысла для мелкой компании
в то время как Microsoft может придумать и внедрить что-то чуть-чуть получше (да и с этим вон спорят) чем Java
а нужно что-то несравнимо лучшее, позволяющее делать то, что раньше считалось невозможным
не только продукт, а ещё и новая область применения, не занятая пока гигантами
то есть придумывать что-то чуть-чуть получше, чем тот же C# и .Net framework, не имеет смысла для мелкой компании
в то время как Microsoft может придумать и внедрить что-то чуть-чуть получше (да и с этим вон спорят) чем Java
а нужно что-то несравнимо лучшее, позволяющее делать то, что раньше считалось невозможным
То есть на промышленном языке нужно скажем писать так:
А вот так уже плохо:
for (int i=0, n=a.length; i<n; i++) {
a[i]++;
}
Слишком коротко, да?
for my $x (@a) { $x++; }
Вот так, например, уже плохо:
Не знаю, правда, кто так будет писать в здравом уме
$_++ for (@a);
Не знаю, правда, кто так будет писать в здравом уме
или даже вот так
map {$_++} @a; > кто так будет писать в здравом уме
я даже не знал, что это возможно
но даже от таких штук эффект всего лишь локальный
я даже не знал, что это возможно
но даже от таких штук эффект всего лишь локальный
Есть такой момент - когда особо любознательный начинающий программист узнаёт про такие возможности , он по первому времени ими таки пользуется.
> но даже от таких штук эффект всего лишь локальный
глобальная беда - например, то, что программисту поднять свой уровень владения Perl-ом до ОО-программирования может быть нелегко (по сравнению с другими языками, с Python или Ruby, например).
глобальная беда - например, то, что программисту поднять свой уровень владения Perl-ом до ОО-программирования может быть нелегко (по сравнению с другими языками, с Python или Ruby, например).
> например, то, что программисту поднять свой уровень владения Perl-ом до ОО-программирования может быть нелегко
Это потому что возможностей perl хватает, чтобы долго без этого обходиться.
Чужие библиотеки с ОО-интерфейсом подключить - нет проблем.
Свои написать, чтоб другим было легче - думаю, тоже нет проблем, хотя я не пробовал.
Вот "магические" переменные с нелокальным действием - это да, легко можно устроить засаду.
Но разве в книжках не учат, как этого избегать?
Это потому что возможностей perl хватает, чтобы долго без этого обходиться.
Чужие библиотеки с ОО-интерфейсом подключить - нет проблем.
Свои написать, чтоб другим было легче - думаю, тоже нет проблем, хотя я не пробовал.
Вот "магические" переменные с нелокальным действием - это да, легко можно устроить засаду.
Но разве в книжках не учат, как этого избегать?
Согласен со всем, что ты написал.
Но беда в том, что когда возможностей перла без ОО перестаёт хватать (когда проект разрастается и чего-то модифицировать и добавлять в него чем дальше, тем тяжелее перейти на ОО весьма и весьма сложно. Ну или квалификация программистов не та
Но беда в том, что когда возможностей перла без ОО перестаёт хватать (когда проект разрастается и чего-то модифицировать и добавлять в него чем дальше, тем тяжелее перейти на ОО весьма и весьма сложно. Ну или квалификация программистов не та
> Ну или квалификация программистов не та
А хуле они делали, пока проект разрастался?
> когда возможностей перла без ОО перестаёт хватать
Не уверен, что это обязательно наступит, ведь perl полноценно поддерживает
программирование в функциональном стиле, в отличии от многих из упомянутых тут других языков.
А хуле они делали, пока проект разрастался?
> когда возможностей перла без ОО перестаёт хватать
Не уверен, что это обязательно наступит, ведь perl полноценно поддерживает
программирование в функциональном стиле, в отличии от многих из упомянутых тут других языков.
Перл не поддерживает и трети всех API, доступных из Java. Думаю, что такая же ситуация и с .NET.
А язык? При чем тут язык? Индустриальными обычно становятся далеко не самые "правильные" или "мощные" языки.
А язык? При чем тут язык? Индустриальными обычно становятся далеко не самые "правильные" или "мощные" языки.
> Перл не поддерживает и трети всех API, доступных из Java. Думаю, что такая же ситуация и с .NET.
И наоборот.
И наоборот.
> Перл не поддерживает и трети всех API, доступных из Java. Думаю, что такая же ситуация и с .NET.Например?
И наоборот.
Про CPAN слышал?
> Про CPAN слышал?
Модули с друг другом увязаны? или это просто толпа никак с друг другом несвязанных модулей?
Модули с друг другом увязаны? или это просто толпа никак с друг другом несвязанных модулей?
Есть разные.
Про ортогональность слышал?
Про ортогональность слышал?
> Про ортогональность слышал?
слышал. У них получилось?
Если есть ортогональность, то есть и замыкания, когда модуль X_and_Y должен работать подругому (или проще, лучше и т.д. чем модули X+Y.
Как они поступают с замыканиями?
слышал. У них получилось?
Если есть ортогональность, то есть и замыкания, когда модуль X_and_Y должен работать подругому (или проще, лучше и т.д. чем модули X+Y.
Как они поступают с замыканиями?
Грубо говоря - нужен модуль - вот он.
Значит ли это, что получилось?
Значит ли это, что получилось?
> Значит ли это, что получилось?
не факт
Важнее знать, что происходит, когда мы пишем большую систему и используем, например, 40 модулей из такой библиотеки.
Важно знать: насколько эти 40 модулей интегрируются между собой, насколько они предоставляют общие интерфейсы для работы с ними, насколько они взаимозаменяемы и т.д.
не факт
Важнее знать, что происходит, когда мы пишем большую систему и используем, например, 40 модулей из такой библиотеки.
Важно знать: насколько эти 40 модулей интегрируются между собой, насколько они предоставляют общие интерфейсы для работы с ними, насколько они взаимозаменяемы и т.д.
Ну 40 модулей скорее всего окажутся совсем разного назначения.
Какие тут общие интерфейсы и т.д.?
Какие тут общие интерфейсы и т.д.?
$_++ for (@a);
Если весь скрипт выдержан в этом стиле, то не так уж плохо.
А если while(a[ i]) a[i++]++; - тоже неплохо?
Допустим я пишу программу, которая должна работать на windows-е, *nix-е, предоставлять, как десктопный, так и web UI, хранить данные, как в Oracle, так и в MySql, так и в Access-е и т.д., программа должна формировать документы в OpenOffice, Word, Excel, html, rtf, pdf, tex, поддерживать графические форматы: png, jpeg, gif, bmp и т.д.
Далее возникают вопросы:
1. Предоставляют ли одиннаковый интерфейс модули, которые работают с разными базами: Oracle, Access, MySql, SqlLite, odbc-базы, ole-базы?
2. Предоставляют ли одиннаковый интерфейс модули, которые работают с разными графическими форматами?
3. Можно ли, напрямую, соединить модуль, который получает данные из базы, и модуль, которые выводит данные на экран, в html или в документ? Или требуется большой объем ручного кода?
4. Насколько одиннаковую концепцию обеспечивают модули, которые делают web-UI и desktop-UI?
5. Я использую готовый модуль для создания web-UI, но часть пользователей жалуются, что у них коряво выводится. Смогу ли я законфигурировать модуль так, чтобы под этих пользователей вывод происходил чуть другим образом.
6. Каждый из модулей требует конфигурирование. Можно ли единообразным способом законфигурировать все используемые модули? Какой объем ручного кода требуется?
7. Можно ли единообразным способом локализовать все модули? В частности, локализовать все сообщения об ошибках?
Далее возникают вопросы:
1. Предоставляют ли одиннаковый интерфейс модули, которые работают с разными базами: Oracle, Access, MySql, SqlLite, odbc-базы, ole-базы?
2. Предоставляют ли одиннаковый интерфейс модули, которые работают с разными графическими форматами?
3. Можно ли, напрямую, соединить модуль, который получает данные из базы, и модуль, которые выводит данные на экран, в html или в документ? Или требуется большой объем ручного кода?
4. Насколько одиннаковую концепцию обеспечивают модули, которые делают web-UI и desktop-UI?
5. Я использую готовый модуль для создания web-UI, но часть пользователей жалуются, что у них коряво выводится. Смогу ли я законфигурировать модуль так, чтобы под этих пользователей вывод происходил чуть другим образом.
6. Каждый из модулей требует конфигурирование. Можно ли единообразным способом законфигурировать все используемые модули? Какой объем ручного кода требуется?
7. Можно ли единообразным способом локализовать все модули? В частности, локализовать все сообщения об ошибках?
> А если while(a[ i]) a[i++]++; - тоже неплохо?
Нормально.
Нормально.
Допустим я пишу программу, которая должна работать на windows-е, *nix-е, предоставлять, как десктопный, так и web UI, хранить данные, как в Oracle, так и в MySql, так и в Access-е и т.д., программа должна формировать документы в OpenOffice, Word, Excel, html, rtf, pdf, tex, поддерживать графические форматы: png, jpeg, gif, bmp и т.д.Так не бывает, к сожалению
Если всё же захочешь делать, будь готов к проблемам.
На 1,2,7 ответ скорее "да", про остальное не знаю.
Объём ручного кода для связи модулей различных авторов зависит
от выразительности языка и мастерства программиста, с первым у перла неплохо.
> Объём ручного кода для связи модулей различных авторов зависит от выразительности языка и мастерства программиста
Так хочется, чтобы связь разных модулей производилась мышкой, "наладчиком" и у клиента, на основе его слов.
.net-фреймоворк, как раз раз сейчас в этом направлении развивается.
Так хочется, чтобы связь разных модулей производилась мышкой, "наладчиком" и у клиента, на основе его слов.
.net-фреймоворк, как раз раз сейчас в этом направлении развивается.
> Так хочется, чтобы связь разных модулей производилась мышкой, "наладчиком" и у клиента, на основе его слов.
Повторю, что это возможно в случае специализированных задач.
А на CPAN - в основном универсальные библиотеки.
Для некоторых специализированных задач такая "наладка" возможна -
пишутся скрипты прямо у клиента, мышка не нужна - и так всё просто.
Повторю, что это возможно в случае специализированных задач.
А на CPAN - в основном универсальные библиотеки.
Для некоторых специализированных задач такая "наладка" возможна -
пишутся скрипты прямо у клиента, мышка не нужна - и так всё просто.
> Так не бывает, к сожалению
если требование к .nix-выкинуть, то это требования реальных проектов.
т.е. обычно требуется примерно следующее:
работа с другими базами.
доступ с nix-клиента,
доступ с КПК-клиента,
если требование к .nix-выкинуть, то это требования реальных проектов.
т.е. обычно требуется примерно следующее:
предоставлять, как десктопный, так и web UI (или другими словами: rich и lite UI) на windows-е,По возможности дожно обеспечиваться:
хранить данные, как в Oracle, так и в MsSql,
формировать документы в Word, Excel, html, rtf, pdf,
поддерживать графические форматы: png, jpeg, gif, bmp
online и offline-доступ (синхронизация с базой раз в сутки, например
связь клиента и сервера, как по толстому канала (выделенка так и по тонкому (gprs).
работа с другими базами.
доступ с nix-клиента,
доступ с КПК-клиента,
> Для некоторых специализированных задач такая "наладка" возможна -
Почему это невозможно для универсальных задач?
Вывод данных он, и в Африке, вывод.
Ввод данных он, и в Африке, ввод.
Хранение данных оно, и в Африке, хранение.
Редактирование данных...
Последовательность пересчетов...
Связь...
Оптимизация...
Какие задачи остались?
Почему это невозможно для универсальных задач?
Вывод данных он, и в Африке, вывод.
Ввод данных он, и в Африке, ввод.
Хранение данных оно, и в Африке, хранение.
Редактирование данных...
Последовательность пересчетов...
Связь...
Оптимизация...
Какие задачи остались?
Если есть требование
> кучу запросов придётся писать отдельно для Oracle и отдельно для MSSQL
Это скорее всего останется на уровне stored procedure.
Это скорее всего останется на уровне stored procedure.
Это специализированная задача aka бухгалтерия.
Кто ж спорит, что у .Net тут хорошие перспективы.
Примеры других задач: игры, ИИ, высокопроизводительные вычисления, символьные вычисления, встраиваемые системы.
Могут быть дополнительные требования к задачам, например отказоустойчивость, повышенная безопасность.
Perl скорее специализируется на интеграции компонентов различного происхождения,
где нет согласованных интерфейсов, синтаксис языка и стандартные библиотеки заточены
для уменьшения объёма ручного кодирования, необходимого для преобразования данных любой структуры.
Кто ж спорит, что у .Net тут хорошие перспективы.
Примеры других задач: игры, ИИ, высокопроизводительные вычисления, символьные вычисления, встраиваемые системы.
Могут быть дополнительные требования к задачам, например отказоустойчивость, повышенная безопасность.
Perl скорее специализируется на интеграции компонентов различного происхождения,
где нет согласованных интерфейсов, синтаксис языка и стандартные библиотеки заточены
для уменьшения объёма ручного кодирования, необходимого для преобразования данных любой структуры.
Базы данных: если у MySQL рекордная скорость на простых запросах, но нет многой функциональности других СУБД,
то приложение, которое использует одинаковые абстракции на MySQL и на Oracle, будет сосать хотя бы в одном из этих случаев.
Если использовать одинаковый подход при проектировании WIMP GUI и для веб-интерфейса,
то по крайней мере один из вариантов будет неудобным, кроме самых простых случаев.
то приложение, которое использует одинаковые абстракции на MySQL и на Oracle, будет сосать хотя бы в одном из этих случаев.
Если использовать одинаковый подход при проектировании WIMP GUI и для веб-интерфейса,
то по крайней мере один из вариантов будет неудобным, кроме самых простых случаев.
> Могут быть дополнительные требования к задачам, например отказоустойчивость, повышенная безопасность.
так это как раз ортогональные требования
кто только, что говорил, что модули должны быть ортогональными?
> Примеры других задач: игры, ИИ, высокопроизводительные вычисления, символьные вычисления, встраиваемые системы.
И чем эти задачи друг от друга отличаются?
Все они сводятся к тому - что есть простая последовательность преобразований, в которой надо схитрить или сделать частично, чтобы она "влазила" в текущие компы.
так это как раз ортогональные требования
кто только, что говорил, что модули должны быть ортогональными?
> Примеры других задач: игры, ИИ, высокопроизводительные вычисления, символьные вычисления, встраиваемые системы.
И чем эти задачи друг от друга отличаются?
Все они сводятся к тому - что есть простая последовательность преобразований, в которой надо схитрить или сделать частично, чтобы она "влазила" в текущие компы.
> есть простая последовательность
Всё относительно. Бывает и сложная логика...
Всё относительно. Бывает и сложная логика...
> И чем эти задачи друг от друга отличаются?
Ну, например, тем, что играм обычно нафиг не нужны реляционные базы данных, а высокопроизводительным вычислениям не нужны всякие ворды, эксели и прочие PDF-ы.
Ну, например, тем, что играм обычно нафиг не нужны реляционные базы данных, а высокопроизводительным вычислениям не нужны всякие ворды, эксели и прочие PDF-ы.
> Бывает и сложная логика...
например?
например?
> Примеры других задач: игры, ИИ, высокопроизводительные вычисления, символьные вычисления, встраиваемые системы.Можно здесь поподробнее? Заранее могу сказать:
И чем эти задачи друг от друга отличаются?
Все они сводятся к тому - что есть простая последовательность преобразований, в которой надо схитрить или сделать частично, чтобы она "влазила" в текущие компы.
- Что касается игр, то здесь нужна не просто "простая последовательность преобразований", а офигенно быстрая такая последовательность, и .NET здесь, ясное дело, подходит плохо.
- Что касается ИИ, то примеры есть. Например JESS (Java-версия экспертной системы CLIPS).
Про CPAN слышал?Ты библиотеки от API отличаешь?
> Ну, например, тем, что играм обычно нафиг не нужны реляционные базы данных, а высокопроизводительным вычислениям не нужны всякие ворды, эксели и прочие PDF-ы.
Это, по твоему, серьезное отличие?
РБД - это маленький частный случай хранения данных.
ворд, эксель, pdf - это маленький частный случай вывода данных.
хранить и выводить данные надо, как и в играх, так и в вычислениях.
Это, по твоему, серьезное отличие?
РБД - это маленький частный случай хранения данных.
ворд, эксель, pdf - это маленький частный случай вывода данных.
хранить и выводить данные надо, как и в играх, так и в вычислениях.
> и .NET здесь, ясное дело, подходит плохо.
Типа Flash быстрее?
все-таки смотря о каких играх идет речь.
Типа Flash быстрее?
все-таки смотря о каких играх идет речь.
Ну ок, все подзадачи, возникающие в программировании - это маленькие частные случаи давно известных задач. И что с того? Чего обсуждаем? Абстрактную метасистему, которую можно настроить мышкой "на коленке", сидя в офисе у заказчика, расспрашивая его про требуемую функциональность и попивая коньячок?
> Абстрактную метасистему, которую можно настроить мышкой "на коленке",
В идеале, хочется именно что-то такое.
В реале, хочется от языка/системы - хотя бы поддержки нескольких основных принципов (ортогональности, последовательности и т.д.)
В идеале, хочется именно что-то такое.
В реале, хочется от языка/системы - хотя бы поддержки нескольких основных принципов (ортогональности, последовательности и т.д.)
Понимаю. Лично я имел в виду HL/CS.
По крайней мере, у -а "игры" шли вместе с "высокопроизводительными вычислениями".
По крайней мере, у -а "игры" шли вместе с "высокопроизводительными вычислениями".
Понимаю. Лично я имел в виду HL/CS.показать тебе игру с графикой покруче чем в контре в которой все кроме 3д написано на java?
> Лично я имел в виду HL/CS.
Такие игры можно разбить на следующие части:
граф. движок,
физич. движок,
движок мира
и т.д.
Верхнюю часть каждого движка удобнее писать на чем-нибудь высокоуровневом.
Верхняя часть - это описание правил преобразований - что движение бочки - это гор. перемещение + поворот вокруг своей оси,
что контейнер при взрыве распадается на три доски,
что пуля попадая в корпус уменьшает здоровье на 10 пунктов
и т.д.
Постоянный же обсчет этих правил- лучше всего, вообще, делать в железе или спец. либой написанной на asm-е с поддержкой sse2.
Такие игры можно разбить на следующие части:
граф. движок,
физич. движок,
движок мира
и т.д.
Верхнюю часть каждого движка удобнее писать на чем-нибудь высокоуровневом.
Верхняя часть - это описание правил преобразований - что движение бочки - это гор. перемещение + поворот вокруг своей оси,
что контейнер при взрыве распадается на три доски,
что пуля попадая в корпус уменьшает здоровье на 10 пунктов
и т.д.
Постоянный же обсчет этих правил- лучше всего, вообще, делать в железе или спец. либой написанной на asm-е с поддержкой sse2.
> Ты библиотеки от API отличаешь?
Расскажи, что ты понимаешь под ними, и в чём разница.
Расскажи, что ты понимаешь под ними, и в чём разница.
Покажи. Заодно скажи, какие требования к компу.
Как человеку, посвятившему какое-то время играм, мне прям даже интересно стало: что это за игры, которые по динамизму не уступают HL/CS, а написаны (кроме 3D) на Java?
> В идеале, хочется именно что-то такое.
Я бы сказал, что Java по сравнению с Smalltalk и C++ - это уход в сторону специализации.
Perl по сравнению с C, shell и awk - развитие в сторону универсальности и метапрограммирования.
Про .Net сказать затрудняюсь.
Я бы сказал, что Java по сравнению с Smalltalk и C++ - это уход в сторону специализации.
Perl по сравнению с C, shell и awk - развитие в сторону универсальности и метапрограммирования.
Про .Net сказать затрудняюсь.
> так это как раз ортогональные требования
не очень
например, если некий фреймворк не удовлетворяет требованиям безопасности, то его скорее всего придётся выкинуть целиком
а если слабо связанные модули, то может быть, некоторые можно и оставить
не очень
например, если некий фреймворк не удовлетворяет требованиям безопасности, то его скорее всего придётся выкинуть целиком
а если слабо связанные модули, то может быть, некоторые можно и оставить
> Perl по сравнению с C, shell и awk
У perl-а, также как и у C++ - очень плохие корни - и это очень серьезный минус, т.к. получается, что база языка - "рыхлая".
У perl-а, также как и у C++ - очень плохие корни - и это очень серьезный минус, т.к. получается, что база языка - "рыхлая".
> например, если некий фреймворк не удовлетворяет требованиям безопасности, то его скорее всего придётся выкинуть целиком
так может он просто был сформирован не по ортогональным правилам?
так может он просто был сформирован не по ортогональным правилам?
Ку2 портированная на жаву.
Ей, правда, памяти много надо.
Ей, правда, памяти много надо.
Просто для безопасности вредны зависимости между модулями.
Память-то ладно, она сравнительно дешёвая.
Ей комп. нужен, по производительности на порядок больше моего.
На своём Duron 700MHz с древней видеокартой я прошёл Quake2 без всяких проблем.
Здесь же частота обновления 0.5-1 fps - куда это годится?
Ей комп. нужен, по производительности на порядок больше моего.
На своём Duron 700MHz с древней видеокартой я прошёл Quake2 без всяких проблем.
Здесь же частота обновления 0.5-1 fps - куда это годится?
> Просто для безопасности вредны зависимости между модулями
т.е. код дублируется?
т.е. код дублируется?
Если изначально библиотека не проектировалась с учётом требований безопасности,
то таки нужную функциональность придётся переписывать, то есть дублировать код.
то таки нужную функциональность придётся переписывать, то есть дублировать код.
> то таки нужную функциональность придётся переписывать, то есть дублировать код.
Не понимаю я - зачем это надо код переписывать, если требование ортогонально к самой задаче?
Не понимаю я - зачем это надо код переписывать, если требование ортогонально к самой задаче?
А ты про .NET не говори, это не язык. Никто не мешает пересадить Perl на .NET. Причем если очень постараться, то можно сделать нормальный доступ из него к .NET API.
Если по поводу API в целом. Сегодня все системы API очень, очень ужасные. Как там у Perl с этим я не знаю, но думаю, что не сильно лучше чем у других. Например, то что я видел в PHP так это вообще ужас. Как там можно прогать. Реально тема API очень сильно игнорировалась. Если велось множество исследований в обоасти ООП и ЯП, то про дизайн API прочти нет ничего толкового. Проблемы наверно в том, что в разных ЯП используются разные стили организации API, поэтому наверно какие-то общие исследования не имели смысл. С появлением .NET можно говорить о API немного абстрагируясь от конкретного языка. Так MS сегодня работает на новыми API на ближайшие годы и очень серьезно подходит к этой проблеме. Просто сегодня уже очевидно, что на комфортность программирования вилияет качество API в большей степени, чем выбор ЯП, особенно когда вы работаете с очень сложным и функциональным фреймфорком.
Лично мне очень нравится все то, что складывается в .NET. C одной стороны доступны неплохие API к очень богатой функциональности. Взять например, взять хотя бы AST.NET. Можно накупить готовых компонент, что позволит с минимум кода сделать очень функциональное веб приложение. Что-то аналогично получить в PHP просто невозможно сегодня. Не спасут положение и все прелести языка в PHP. С другой стороны в .NET доступно большое количество языков. Пиши каждую часть проекта на том языке, который наиболее удобен. Как пример, VB.NET очень неплохо годится для написания бизнес логики, код смотрится очень симпатично, все ок с читабельностью. Если нужно много работать на низком уровне, много доступа к native компонентам, то хорошо подойдет MC++2005.
Если по поводу API в целом. Сегодня все системы API очень, очень ужасные. Как там у Perl с этим я не знаю, но думаю, что не сильно лучше чем у других. Например, то что я видел в PHP так это вообще ужас. Как там можно прогать. Реально тема API очень сильно игнорировалась. Если велось множество исследований в обоасти ООП и ЯП, то про дизайн API прочти нет ничего толкового. Проблемы наверно в том, что в разных ЯП используются разные стили организации API, поэтому наверно какие-то общие исследования не имели смысл. С появлением .NET можно говорить о API немного абстрагируясь от конкретного языка. Так MS сегодня работает на новыми API на ближайшие годы и очень серьезно подходит к этой проблеме. Просто сегодня уже очевидно, что на комфортность программирования вилияет качество API в большей степени, чем выбор ЯП, особенно когда вы работаете с очень сложным и функциональным фреймфорком.
Лично мне очень нравится все то, что складывается в .NET. C одной стороны доступны неплохие API к очень богатой функциональности. Взять например, взять хотя бы AST.NET. Можно накупить готовых компонент, что позволит с минимум кода сделать очень функциональное веб приложение. Что-то аналогично получить в PHP просто невозможно сегодня. Не спасут положение и все прелести языка в PHP. С другой стороны в .NET доступно большое количество языков. Пиши каждую часть проекта на том языке, который наиболее удобен. Как пример, VB.NET очень неплохо годится для написания бизнес логики, код смотрится очень симпатично, все ок с читабельностью. Если нужно много работать на низком уровне, много доступа к native компонентам, то хорошо подойдет MC++2005.
> Ты библиотеки от API отличаешь?API = application programming interface = интерфейс
Расскажи, что ты понимаешь под ними, и в чём разница.
библиотека = суть реализация какой-то функциональности
Верее, все системы API, известные _тебе_.
Либо что ты подразумеваешь под API?
---
...Я рабоатю антинаучным аферистом...
Либо что ты подразумеваешь под API?
---
...Я рабоатю антинаучным аферистом...
А какая между ними разница для client programmer?
Ну я согласен, что у меня не самый широкий кругозор
комент гнилой
афтар мозго!б
афтар мозго!б
У perl-а, также как и у C++ - очень плохие корни - и это очень серьезный минус, т.к. получается, что база языка - "рыхлая".Говноаргумент. В стиле "NNTP - очень старый протокол".
У библиотеки всегда есть некий интерфейс. Для приложений. То есть API.
Я не вижу особой разницы. Разые что такой. Библиотека юзается внутри проги. API предоставляется проге как части чего-то большего (системы). Есть здесь разница?
Здесь не в возрасте дело.
У Схемы корни уходят столь же, если не более, глубоко,
однако это куда более вылизанный язык, чем Перл.
---
...Я работаю антинаучным аферистом...
У Схемы корни уходят столь же, если не более, глубоко,
однако это куда более вылизанный язык, чем Перл.
---
...Я работаю антинаучным аферистом...
Схема - это имхо несколько специализированный Лисп, развитие которого остановлено в нужной точки, и лишнее отброшено.
А Перл - развивающийся в сторону универсальности язык, где про многое пока не понятно, надо ли это отбрасывать.
А Перл - развивающийся в сторону универсальности язык, где про многое пока не понятно, надо ли это отбрасывать.
> В стиле "NNTP - очень старый протокол".
Проблема не в старости, а в том, что языки (перл и c++) сначала разрабатывались, исходя из одних принципов, задач и т.д., а потом совсем из других.
Причем, даже если что-то в языке противоречит или мешает новой концепции - оно все равно остается.
ps
Взять тот же C - он, например, разрабатывался, исходя из того, что памяти у компилятора очень мало - и многие фишки растут именно из этого требования, хотя оно уже давно неактуально.
Проблема не в старости, а в том, что языки (перл и c++) сначала разрабатывались, исходя из одних принципов, задач и т.д., а потом совсем из других.
Причем, даже если что-то в языке противоречит или мешает новой концепции - оно все равно остается.
ps
Взять тот же C - он, например, разрабатывался, исходя из того, что памяти у компилятора очень мало - и многие фишки растут именно из этого требования, хотя оно уже давно неактуально.
Схема --- это универсальный язык, который сделан достаточно
небольшим, чтобы его можно было хорошо понять.
Всё, что выходит за рамки основ языка, вынесено в SRFI.
Последние, если их вдруг не оказалось, можно определять внешним
способом, как библиотеки, и использовать в своё удовольствие.
Схема, кстати, это "one T LISP."
---
...Я работаю антинаучным аферистом...
небольшим, чтобы его можно было хорошо понять.
Всё, что выходит за рамки основ языка, вынесено в SRFI.
Последние, если их вдруг не оказалось, можно определять внешним
способом, как библиотеки, и использовать в своё удовольствие.
Схема, кстати, это "one T LISP."
---
...Я работаю антинаучным аферистом...
А какая между ними разница для client programmer?Большая. Разницу между JDBC и Oracle OCI понимаешь?
У библиотеки всегда есть некий интерфейс. Для приложений. То есть API.И... что? Этот интерфейс поддерживается всеми остальными библиотеками?
Отбрасывание лишнего, дабы осталось только true, я бы назвал одним из видов специализации.
Не совсем понятно, какие такие остальные библиотеки должны поддерживать, например API для доступа к базам данных.
Если выбрасывание мусора называть специализацией, то ладно.
---
...Я работаю дзен-специалистом...
---
...Я работаю дзен-специалистом...
Я заглянул в http://www.schemers.org/Documents/FAQ/ .
Там довольно легко разглядеть, на чём специализируется Схема.
Там довольно легко разглядеть, на чём специализируется Схема.
А это такая область, куда замусоренным языкам очень уж сложно втиснуться.
Это также можно считать показателем большей универсальности,
то есть меньшей специализации.
---
...Я работаю дзен-специалистом...
Это также можно считать показателем большей универсальности,
то есть меньшей специализации.
---
...Я работаю дзен-специалистом...
> Разницу между JDBC и Oracle OCI понимаешь?
Нет. Могу лишь гадать, что JDBC позволяет абстрагироваться от конкретной реализации базы данных - Oracle, SQL Server, Access...
Ну и что? Насколько я понял, речь шла, с одной стороны, об интерфейсе как о наборе имён функций, с описанием того, что они делают и, с другой стороны, о конкретной реализации этих функций. Я предположил, что пользователю API плевать на реализацию, и API и интерфейс (в твоём смысле) - для него одно и то же.
Нет. Могу лишь гадать, что JDBC позволяет абстрагироваться от конкретной реализации базы данных - Oracle, SQL Server, Access...
Ну и что? Насколько я понял, речь шла, с одной стороны, об интерфейсе как о наборе имён функций, с описанием того, что они делают и, с другой стороны, о конкретной реализации этих функций. Я предположил, что пользователю API плевать на реализацию, и API и интерфейс (в твоём смысле) - для него одно и то же.
Не совсем понятно, какие такие остальные библиотеки должны поддерживать, например API для доступа к базам данных.Поэтому ты и любишь перл
Вот появится когда-нибудь PDBC или PNDI, Perl Collections и PTA, динамическая загрузка классов и AOP, станет перл платформой, а не языком для парсинга лог-файлов - тогда будут на нем писать, и будут перлисты получать больше C-шников Всё перечисленное возможно, если я правильно понял сокращения.
По поводу платформы - читай выше про ямы и лопаты.
По поводу платформы - читай выше про ямы и лопаты.
> станет перл платформой
Кстати, есть еще одно модное маркетинговое слово - решение. Возьми на вооружение.
> и будут перлисты получать больше C-шников
То есть C уже стал платформой?
Кстати, есть еще одно модное маркетинговое слово - решение. Возьми на вооружение.
> и будут перлисты получать больше C-шников
То есть C уже стал платформой?
Решение - это немножко другое. Это уже ближе к дотнету. И мне не платят за флеймы на перловые темы а мнение свое основываю на некоем количестве переработанных legacy-систем. На людей, расхваливающих перл, с тех пор смотрю с подозрением. Язык ИМХО ужасен, как с точки зрения средств абстракции, так и с точки читабельности.
Про С я ссылаюсь на твой собственный пример.
а мнение свое основываю на некоем количестве переработанных legacy-систем. На людей, расхваливающих перл, с тех пор смотрю с подозрением. Язык ИМХО ужасен, как с точки зрения средств абстракции, так и с точки читабельности. Про С я ссылаюсь на твой собственный пример.
Нет, дело не в возможности! Возможности и в Visual Basic есть.
По поводу ям и лопат тебе вроде правильно ответили.
По поводу ям и лопат тебе вроде правильно ответили.
Ответили не совсем правильно. Упустили из виду то, что экскаватор дают погонять бесплатно
(платить нужно только за модель с душем, кондиционером и ракетным ускорителем).
Но некоторые похоже по своей воле даже суп есть пытаются той же лопатой.
И дело не в возможностях, действительно.
Каждый имеет возможность подметать улицу зубной щёткой, но вне армии этого обычно не делают.
(платить нужно только за модель с душем, кондиционером и ракетным ускорителем).
Но некоторые похоже по своей воле даже суп есть пытаются той же лопатой.
И дело не в возможностях, действительно.
Каждый имеет возможность подметать улицу зубной щёткой, но вне армии этого обычно не делают.
> зачем это надо код переписывать, если требование ортогонально к самой задаче?
Microsoft и некоторые другие думают так же.
Поэтому поток обнаруженных уязвимостей не стихает.
Microsoft и некоторые другие думают так же.
Поэтому поток обнаруженных уязвимостей не стихает.
> очень плохие корни
так может показаться тем, кто понимает только бухгалтерию
так может показаться тем, кто понимает только бухгалтерию
> Microsoft и некоторые другие думают так же.
> Поэтому поток обнаруженных уязвимостей не стихает
Я говорил о другом.
Думай.
ps
Подсказка:
если у меня была программа:
И появилась новое требование: обеспечить безопасность,
то надо ли эту программу переписывать следующим образом:
> Поэтому поток обнаруженных уязвимостей не стихает
Я говорил о другом.
Думай.
ps
Подсказка:
если у меня была программа:
СпроситьЛогинИПароль;
If (ПодлинностьПароляУстановлена(логин, пароль
{
ПроизвестиРасчеты;
ВывестиРезультатыПользователю;
}
else
НеПуститьПользователя;
И появилась новое требование: обеспечить безопасность,
то надо ли эту программу переписывать следующим образом:
СпроситьЛогинИПарольБезопаснымОбразом;
If (!ПодлинностьПароляУстановленаБезопаснымОбразом(логин, пароль
{
ПроизвестиРасчетыБезопаснымОбразом;
ВывестиРезультатыПользователюБезопаснымОбразом;
}
else
НеПуститьПользователяБезопаснымОбразом;
Эти пять строчек переписывать, может быть, и не надо.
А вот те тысячи, что составляют тела функций, скорее всего придётся.
А вот те тысячи, что составляют тела функций, скорее всего придётся.
> Язык ИМХО ужасен, как с точки зрения средств абстракции, так и с точки читабельности.
Повторю еще раз для тех кто невнимательно читает: perl позволяет писать очень плохо, и то, что многие именно так и поступают не означает, что на perl нельзя писать хорошо.
На perl можно писать дюжиной стилей, и не вдаваясь в сравнение их между собой, я просто скажу, что самое ужасное начинается, когда их начинают месить. Когда передирают примеры из разных книжек и чужих програм, то рождаются перловые франкенштейны.
Что же до зарплаты, то это московская (?) или веб (?) специфика. Я например несколько раз видел объявления о найме perl программистов в конторы занимающиеся антиспамом, в т.ч. и в буржуйские, так там была вполне достойная зарплата, такая же как у программистов на других языках.
Повторю еще раз для тех кто невнимательно читает: perl позволяет писать очень плохо, и то, что многие именно так и поступают не означает, что на perl нельзя писать хорошо.
На perl можно писать дюжиной стилей, и не вдаваясь в сравнение их между собой, я просто скажу, что самое ужасное начинается, когда их начинают месить. Когда передирают примеры из разных книжек и чужих програм, то рождаются перловые франкенштейны.
Что же до зарплаты, то это московская (?) или веб (?) специфика. Я например несколько раз видел объявления о найме perl программистов в конторы занимающиеся антиспамом, в т.ч. и в буржуйские, так там была вполне достойная зарплата, такая же как у программистов на других языках.
Первые два твоих предложения можно преобразовать без потери
истинности: s/perl/C/g, s/perl/C++/g, s/perl/C#/g.
---
...Я работаю антинаучным аферистом...
истинности: s/perl/C/g, s/perl/C++/g, s/perl/C#/g.
---
...Я работаю антинаучным аферистом...
... не означает, что на perl нельзя писать хорошоА я такого и не говорил, это претензия к другим товарищам. Я говорил об объективных ограничениях перла - это прежде всего касается ООП. Правда, не знаю что там в Перл 6.
ООП - сейчас скорее проблема, чем решение.
См. соседний тред о множественном наследовании.
См. соседний тред о множественном наследовании.
Э-э, чуве, если ты утверждаешь, что язык ужасен потому, что он не ООП, то это клиника.
> Первые два твоих предложения можно преобразовать без потери
> истинности: s/perl/C/g
На С писать разными стилями потруднее будет.
Настолько труднее, что никому и в голову не приходит без внешних генераторов и хитрых препроцессоров.
> истинности: s/perl/C/g
На С писать разными стилями потруднее будет.
Настолько труднее, что никому и в голову не приходит без внешних генераторов и хитрых препроцессоров.
Первые два твоих предложения можно преобразовать без потериБез потери, но в случае perl это намного более ярко выражено.
истинности: s/perl/C/g, s/perl/C++/g, s/perl/C#/g.
Почитал про ООП в перл.
Своеобразно, но не слишком. В принципе, то же самое.
Своеобразно, но не слишком. В принципе, то же самое.
Что же до зарплаты, то это московская (?) или веб (?) специфика. Я например несколько раз видел объявления о найме perl программистов в конторы занимающиеся антиспамом, в т.ч. и в буржуйские, так там была вполне достойная зарплата, такая же как у программистов на других языках.Ну, в Москве, C/C++ программистам платят все-таки больше, чем перл. Разброс разный - в одних 100$$, в других 400$$, но обратного я пока не встречал. Хотя, ИМХО, настоящий атец перла на C писать-то должен уметь. XSы то как писать ?
Нет. Опять неправильно Я утверждаю, что язык ужасен, и добавление ООП его не спасет, потому что он не был для этого предназначен изначально.
Если кому-то действительно интересно, почему я говорю об исключительной полезности ООП как средства абстракции и "масштабрирования" логики, то по этому поводу очень любопытный график приводил Фаулер, к сожалению, в электронном виде у меня его нет. Для интересующихся могу попробовать раздобыть.
Я утверждаю, что язык ужасен, и добавление ООП его не спасет, потому что он не был для этого предназначен изначально.Если кому-то действительно интересно, почему я говорю об исключительной полезности ООП как средства абстракции и "масштабрирования" логики, то по этому поводу очень любопытный график приводил Фаулер, к сожалению, в электронном виде у меня его нет. Для интересующихся могу попробовать раздобыть.
Я ж и говорю, что похоже такова московская специфика.
"Real Programmer can write FORTRAN in any language."
Из того, что в Си из функции можно вернуть только одно слово,
никак не следует, что там нельзя писать в функциональном стиле.
Выглядит, конечно, очень уж чуднО, но всё же.
А ещё у меня есть подозрение, что GNU cpp старается всеми силами
подпрыгнуть повыше, став таким образом этим "хитрым
препроцессором." Можно ли cpp считать таким уж внешним?
---
...Я работаю антинаучным аферистом...
Из того, что в Си из функции можно вернуть только одно слово,
никак не следует, что там нельзя писать в функциональном стиле.
Выглядит, конечно, очень уж чуднО, но всё же.
А ещё у меня есть подозрение, что GNU cpp старается всеми силами
подпрыгнуть повыше, став таким образом этим "хитрым
препроцессором." Можно ли cpp считать таким уж внешним?
---
...Я работаю антинаучным аферистом...
> Выглядит, конечно, очень уж чуднО, но всё же.
Во всех примерах, что я видел, нужно явно выписывать лишние действия или вводить лишние сущности.
То есть вручную выполнять часть работы транслятора.
Во всех примерах, что я видел, нужно явно выписывать лишние действия или вводить лишние сущности.
То есть вручную выполнять часть работы транслятора.
Объекты ООП как средство абстракции --- это бред.
Простыми АТД можно обходиться с большим успехом.
---
...Я работаю антинаучным аферистом...
Простыми АТД можно обходиться с большим успехом.
---
...Я работаю антинаучным аферистом...
Возможно, это были не самые удачные примеры.
Си слишком низкоуровневый, поэтому ручной работы не избежать.
Разве что есть готовые библиотеки.
---
...Я работаю антинаучным аферистом...
Си слишком низкоуровневый, поэтому ручной работы не избежать.
Разве что есть готовые библиотеки.
---
...Я работаю антинаучным аферистом...
> Си слишком низкоуровневый, поэтому ручной работы не избежать.
Лисп тоже низкоуровневый, но для него
> есть готовые библиотеки
чего для Си сделать не получится.
Лисп тоже низкоуровневый, но для него
> есть готовые библиотеки
чего для Си сделать не получится.
Ключевое слово --- "слишком."
На Лиспе, если этих библиотек нет, последние создаются руками за
пятнадцать минут. Не так давно проделывал подобную работу,
устраняя отсутствие человеческого "map". Для Си объёмы кода,
выполняющего то же, значительно выше. Вот и думай, что более
низкоуровневое.
---
...Я работаю антинаучным аферистом...
На Лиспе, если этих библиотек нет, последние создаются руками за
пятнадцать минут. Не так давно проделывал подобную работу,
устраняя отсутствие человеческого "map". Для Си объёмы кода,
выполняющего то же, значительно выше. Вот и думай, что более
низкоуровневое.
---
...Я работаю антинаучным аферистом...
> Для Си объёмы кода,
> выполняющего то же, значительно выше.
Я думаю, вообще невозможно.
Есть контрпримеры?
> выполняющего то же, значительно выше.
Я думаю, вообще невозможно.
Есть контрпримеры?
Ах, ну да.
Можно написать интерпретатор.
Любой язык можно "расширить" таким образом.
Вот такой вопрос: можно ли (и если да, по каким признакам)
отделить "интерпретаторы других языков" от "библиотек, расширяющих существующий язык"?
Можно написать интерпретатор.
Любой язык можно "расширить" таким образом.
Вот такой вопрос: можно ли (и если да, по каким признакам)
отделить "интерпретаторы других языков" от "библиотек, расширяющих существующий язык"?
* Overview:: What is GLIB?
* Doubly linked lists:: Doubly linked lists
* Signly linked lists:: Singly linked lists
* List allocators:: List Allocators
* Hash tables:: Hash tables
---
...Я работаю антинаучным аферистом...
* Signly linked lists:: Singly linked lists
~~~~
Кстати.
---
...Я работаю...
Это библиотека, или интерпретатор, или неизвестно?
Объекты ООП как средство абстракции --- это бред.Кто ж спорит (со вторым утверждением)? Обходись.
Простыми АТД можно обходиться с большим успехом.
Вообще-то библиотека.
---
...Я работаю антинаучным аферистом...
---
...Я работаю антинаучным аферистом...
И с бОльшим успехом.
---
...Я работаю антинаучным аферистом...
---
...Я работаю антинаучным аферистом...
А вот если писать:
и при запуске оно напечатает
#include <lisp.h>
{ "(", "defun", "p", "(", "a", ")", "(", "+", "2", "a", ")", ")",
"(", "print", "(", "p", "3", ")", ")" };
, это на каком языке будет?
5
Я никогда не сомневался в том, что "Real Programmer can write
FORTRAN in any language."
---
...Я работаю антинаучным аферистом...
FORTRAN in any language."
---
...Я работаю антинаучным аферистом...
То есть, ты считаешь, что на C?
Считаешь, на Лиспе?
---
...Я работаю антинаучным аферистом...
---
...Я работаю антинаучным аферистом...
Думаю, тут не будет ответа, одновременно осмысленного и однозначного.
И с бОльшим успехом.Если ты намекаешь на свои неудачные попытки использования объектов, то остается только посочувствовать.
Я вижу, как из совершенно простых задач, вырастают большие
трудности, когда кто-то пытается решать их средствами ООП.
Сам я ни разу не видел задачу, которую имело бы смысл решать
средствами ООП.
Точно так же, как никто не показал мне таковой.
---
...Я работаю антинаучным аферистом...
трудности, когда кто-то пытается решать их средствами ООП.
Сам я ни разу не видел задачу, которую имело бы смысл решать
средствами ООП.
Точно так же, как никто не показал мне таковой.
---
...Я работаю антинаучным аферистом...
Память-то ладно, она сравнительно дешёвая.Странно это. У меня атлон64 3000+ и гф2мх200, в 1024х768 60фпс. Причём фпс при уменьшении разрешения растут линейно, т.е. затык в карточке.
Ей комп. нужен, по производительности на порядок больше моего.
На своём Duron 700MHz с древней видеокартой я прошёл Quake2 без всяких проблем.
Здесь же частота обновления 0.5-1 fps - куда это годится?
Что-то у тебя по ходу совсем говнокомп или говнодрова или древняя ЖаваРантайм.
> Что-то у тебя по ходу совсем говнокомп или говнодрова или древняя ЖаваРантайм.
Ну спасибо. Опустил мой заслуженный комп.-ветеран ниже плинтуса...
У меня, повторяю, Duron 700, и никакая видюха. Тем не менее, Quake 2 отлично работал. Java у меня версии 1.6 (Java 6).
Ну спасибо. Опустил мой заслуженный комп.-ветеран ниже плинтуса...
У меня, повторяю, Duron 700, и никакая видюха. Тем не менее, Quake 2 отлично работал. Java у меня версии 1.6 (Java 6).
Странно это. У меня атлон64 3000+ и гф2мх200, в 1024х768 60фпс. Причём фпс при уменьшении разрешения растут линейно, т.е. затык в карточке.Ну сосет ява по быстродействию, сосет.
Что-то у тебя по ходу совсем говнокомп или говнодрова или древняя ЖаваРантайм.
На моем совсем древнем компе в свое время Quake 2 без каких-либо ускорителей выдавал 15-25 fps в разрешении 320x200. На Pentium 166MMX + 64 MB RAM. Сомневаюсь, что у реализации на Java в такой конфигурации удастся хотя бы дождаться, пока она загрузится.
Не слышал что Q2 на Java переносят, это ж много гемора. Зато помню, что так демонстрировали фичу MC++/CLR. CLR тянула Q2 в софтварном режиме очень даже ничего (потеря производительности была порядка 15%)
А на ООП вообще гнать глупо. Не придумали еще ничего лучше. И не сделаешь нормальный фреймворк без ООП, чтобы прогер был в достаточной степени производителен и с другой стороны не испытывал больших ограничений в возможностях. И нет никаких проблем с мн наследованием в ООП, поверь.
А на ООП вообще гнать глупо. Не придумали еще ничего лучше. И не сделаешь нормальный фреймворк без ООП, чтобы прогер был в достаточной степени производителен и с другой стороны не испытывал больших ограничений в возможностях. И нет никаких проблем с мн наследованием в ООП, поверь.
Про ООП смотри в соседней ветке.
Лучше есть и давно придумано.
А ООП --- говно.
---
"Я знаю правду! Все прежние правды --- прочь!"
Лучше есть и давно придумано.
А ООП --- говно.
---
"Я знаю правду! Все прежние правды --- прочь!"
Оставить комментарий
ava3443