PI>>какой мой ultimate source of info on the web для лиспа?
L>google
не, это не ответ
это как будто ты спросишь, "где посмотреть по дотнету", а я отвечу "ну, в инете есть сайты, юзай гугл"
на самом деле я тебе отвечу "msdn.com"
если по немерле — "nemerle.org, конференция, рсдн"
нету портала для лисперов?
ну ладно, дайте ссылку на наиболее уважаемый quick insight по лиспу/схеме (не знаю пока че именно нужно, пока просто посмотреть)
Здравствуйте, PhantomIvan, Вы писали:
PI>нету портала для лисперов?
наверно есть, надо лисперов подождать
PI>ну ладно, дайте ссылку на наиболее уважаемый quick insight по лиспу/схеме (не знаю пока че именно нужно, пока просто посмотреть)
Далеко не quick и скорее даже и не "по лиспу/схеме" а скорее обучение Программированию вообще (но за-одно и схему изучишь ):
"Structure and Interpretation of Computer Programs"
Здравствуйте, lomeo, Вы писали:
VD>>1. Статически тпизированный язык с возможностью явной динамики. Это не ново так как дотнет, Ява даже VB 4-6 уже давно дают подобные возможности. Собственно тут у Непреле много соседей: (речь идет только о мэнйстриме, так что не задавайте вопросы "а почему нет языка Х?". Эрлэнг и Скалу я приплел откровенно говоря не корректно, но все же это языки о которых в послденее время говорят, а значит они интересены в нашем анализе) С, С++, Паскаль, Дельфи, Ява, C#, O'Caml, VB, Хаскель, Скала. Причем С, С++, Хаскель и O'Caml не предоставляют управляемых динамических возможностей, а стало быт менее мощьны.
L>Что такое управляемые динамические возможности, из-за которых Хаскель и Окамл пролетают?
Я так понимаю имелось в виду Late binding macro.
L>Насчёт терминов ФВП и первоклассные значения — это просто разные термины. Функции как первоклассные значения — это ФВП, которые можно создавать на лету, ну и хранить в данных, как и значения прочих типов. L>Вопрос — почему Скала не столь мощна в этом вопросе как Немерле?
Да, я тоже не вижу.
Единственное, что у Скалы вывод типов послабее
(в том числе и для локальных функций: например, Скала не умеет даже выводить тип возвращаемого значения для рекурсивных функций):
Scala:
object ackermann {
def main(args: Array[String]) = {
/*
def ack(m, n) = // Нельзя
def ack(m: Int, n: Int) = // для рекурс функций нельзя даже опустить возвращ тип,
// хотя для других можно
*/
def ack(m: Int, n: Int): Int =
if (m == 0) n + 1;
else if (n == 0) ack(m-1, 1);
else ack(m-1, ack(m, n-1));
Console println("Ack(3,10): " + ack(3,10));
}
}
VD>>7. ООП. Тут с одной стороны конкурентов много, но с другой качественная реализация ООП есть далеко не везде. Например, Питон я точно не могу назвать качествнной реалзацией. Руби чуть лушче, но все же тоже не дотягивет. Но в любом случае из этого списка резко исчизают Хаскель и Эрлэнг.
L>ООП слишком сложный вопрос. ОО — всего лишь слово. Разных ОО моделей — вагон и маленькая тележка.
1) Smalltalk (цитаты из сообщения на которое дал ссылку)
Алан Кей сформулировал три базовых принципа объектного подхода:
1. Объект — базовая единица системы.
2. Объекты обладают состоянием.
3. Единственным способом взаимодействия между объектами является посылка сообщения. Объекты сами определяют как обрабатывать сообщения.
2) Simula
1) ИНКАПСУЛЯЦИЯ
2) ПОЛИМОРФИЗМ
3) НАСЛЕДОВАНИЕ
L>Лисп позволяет написать нужный тебе ОО, а вот Немерле разрешит мне написать ОО на прототипах?
Думаю, что проблематично, если ты имеешь ввиду — "скопируй объект и измени/добавь методы по вкусу".
Но это динамический стиль. И в этом стиле гораздо сложнее соблюдать инкапсуляцию и проверять инварианты, что на мой взгляд очень важно.
В статических языках в большинстве случаев хватает наследования и миксинов/traits.
Последних в Nemerle пока нет, но, надеюсь, появятся.
L> Зачем же его выкидывать? Или вот CLOS гораздо мощнее дотнетовского ОО
Мультиметоды?
А то что там можно на лету менять реализацию методов или добавлять их по мне так не является достоинством.
Но это уже видимо в раздел "статика vs динамика".
С другой стороны в CLOS, как и в Python, нет инкапсуляции.
L>(а я думаю, что ОО Немерле — это и есть ОО дотнета, я прав?).
В общем да.
VD>>10. Возможности расширения. Тут конкуренты только O'Caml и Lisp. Причем оба языка резко проигрывают Немерле так как не позволяют получать метаинформацию о типах. Это делает их значительно менее мощьными. С другой стороны нельзя не отметить, что возможности по модификации АСТ у Лиспа и даже у O'Caml-а несколько выше. Хотя реально это мало что дает, так как возможности по модификации АСТ у Немерле тоже нехилые. Кстати, это пожалуй единственный пункт где из списка на прочь выбывает скала. По поводу скриптов можно сказать, что с одной стороны те их них что поддерживают метапрограммирование тоже вохоят в эту категорию, но с другой их метапрограммирование не позволяет серьезно менять синтаксис. Хотя тут я могу ошибаться. Так что можно оставить их вписывание сюда на усмотрение читателя.
L>А TemplateHaskell — это не сюда?
Да.
И Camlp4 для OСaml (возможно Влад его и имел в виду когда говорил про метавозможности в OСaml, но явно не сказал).
И MetaOCaml тоже сюда.
L>Нет-нет, не факт, а твоё мнение. Например, у меня Немерле по этому же списку отсеился в нескольких пунктах. L>А если бы я ещё и свои добавил!
Давай.
Здравствуйте, PhantomIvan, Вы писали:
PI>>>какой мой ultimate source of info on the web для лиспа?
L>>google
PI>не, это не ответ
но ведь ты даже не попробовал, а уже рассуждаешь об этих языках, что в них есть, а чего нет.
PI>это как будто ты спросишь, "где посмотреть по дотнету", а я отвечу "ну, в инете есть сайты, юзай гугл" PI>на самом деле я тебе отвечу "msdn.com"
на самом деле, когда я тебя об этом спрошу — я уже буду знать об мсдн, потому что, ценя твоё время, сначала обращусь к гуглу.
PI>нету портала для лисперов? PI>ну ладно, дайте ссылку на наиболее уважаемый quick insight по лиспу/схеме (не знаю пока че именно нужно, пока просто посмотреть)
с коммон лиспом дружу меньше, но знаю о http://www.cliki.net/ http://common-lisp.net/
опять таки на фриноде есть канал.
хорошие книжки читать надо
Для лиспа
On lisp, practical common lisp (gentle intro тоже хвалили, но я его только листал)
Для схемы
sicp, htdp
это то, что из головы, а представляешь, я сейчас в гугл полезу!
Здравствуйте, FR, Вы писали:
FR>Далеко не quick и скорее даже и не "по лиспу/схеме" а скорее обучение Программированию вообще (но за-одно и схему изучишь ): FR>"Structure and Interpretation of Computer Programs"
Здравствуйте, PhantomIvan, Вы писали:
PI>я тут думал, почему таких программ нет, и понял! PI>то, что мы обсуждаем здесь — типичный олдскул PI>рисование UML диаграмм вручную на бумаге ли, на планшете, маркером на мониторе — это олдскул
Ничего подобного. PI>не нужно его переносить один-в-один на цифровую технологию
PI>вместо этого наш редатор должен оперировать такими простейшими операциями, как: PI>- кинуть на лист класс PI>- кинуть на лист интерфейс PI>- прокинуть связь между классами (причем, связь должна "красиво" ложиться на лист, по возможности, сохраняя граф плоским)
Гм. Вот как раз такому софту сто лет в обед. Тема обсуждения как раз в том, что никто не хочет пользоваться Rational Rose! Кинуть класс, кинуть интерфейс...
Это хорошо подходит для случаев, когда нужно задокументировать хорошо известную штуку.
Цитата:
Я почти профессионально владею фотошопом, также приходилось пользоватся и векторными редакторами, они весьма удобны для своих задач, но для проектирования, для "думания с карандашом в руке" абсолютно непригодны, я за то время как что нибудь нарисую в какой-нибудь диа или визио успею забыть о чем думал а с карандашом за то же время уже набросаю пару эскизов
Я под ней полностью подпишусь! У меня стол зарастает бумажками за неделю — результаты думания на бумаге. Это и deployment diagram, и workflow, и class diagram, и блок схемы и все что угодно. Просто потому, что за 30 секунд я могу нарисовать гораздо больше квадратиков, чем классов в розе.
1.2.0 alpha rev. 655
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Андрей Хропов, Вы писали:
L>>Что такое управляемые динамические возможности, из-за которых Хаскель и Окамл пролетают?
АХ>Я так понимаю имелось в виду Late binding macro.
Прикольно, т.е. можно написать late {...} и писать динамически типизированный код?
АХ>Единственное, что у Скалы вывод типов послабее АХ>(в том числе и для локальных функций: например, Скала не умеет даже выводить тип возвращаемого значения для рекурсивных функций):
Да, про рекурсивные функции знаю. Надеюсь, не умеет пока.
VD>>>7. ООП. Тут с одной стороны конкурентов много, но с другой качественная реализация ООП есть далеко не везде. Например, Питон я точно не могу назвать качествнной реалзацией. Руби чуть лушче, но все же тоже не дотягивет. Но в любом случае из этого списка резко исчизают Хаскель и Эрлэнг.
L>>ООП слишком сложный вопрос. ОО — всего лишь слово. Разных ОО моделей — вагон и маленькая тележка.
АХ>Да, это зависит от того что понимать под ОО.
АХ>В принципе основные мысли были написаны тут: Re: Что такое ООП
Угу, в курсе, что под ОО обычно понимают совсем не то, что создатель термина. Однако, имелось в виду несколько другое. Пусть ООП — это инкапсуляция, наследование, полиморфизм. Однако даже в таком случае реализаций очень много. Вот модификаторы доступа — public, private, protected и каждый язык добавляет какие ему надо. Можем ли мы задавать свои? Например, поля, которые видны только из классов из пакета ааа с именем AAASome* Это что касается инкапсуляции. Подобные примеры можно придумать и для наследования и полиморфизма. (Вспомним хотя бы вечные споры о множественном наследовании).
L>>Лисп позволяет написать нужный тебе ОО, а вот Немерле разрешит мне написать ОО на прототипах?
АХ>Думаю, что проблематично, если ты имеешь ввиду — "скопируй объект и измени/добавь методы по вкусу". АХ>Но это динамический стиль. И в этом стиле гораздо сложнее соблюдать инкапсуляцию и проверять инварианты, что на мой взгляд очень важно.
Это уже неважно. Не будем забывать о блаб программистах и будем оперировать понятиями не достоинство/недостаток (которое может быть сильно субъетивным), а фича. Важно, что эта черта у дотнета, а следовательно у Немерле отсутствует, я прав?
АХ>В статических языках в большинстве случаев хватает наследования и миксинов/traits. АХ>Последних в Nemerle пока нет, но, надеюсь, появятся.
Я об этом и говорю, составить список, в котором Немерле будет пролетать проблем нет.
L>> Зачем же его выкидывать? Или вот CLOS гораздо мощнее дотнетовского ОО АХ>Мультиметоды?
Угу, например. Или аспекты (method combination).
АХ>А то что там можно на лету менять реализацию методов или добавлять их по мне так не является достоинством.
Опять таки это всего лишь мнение. Ты пробовал писать на селфе или чём то подобном?
АХ>С другой стороны в CLOS, как и в Python, нет инкапсуляции.
Ставим минус — нет такой фичи. (Обходной путь, как всегда есть — это импортировать через пэкедж нужное).
L>>Нет-нет, не факт, а твоё мнение. Например, у меня Немерле по этому же списку отсеился в нескольких пунктах. L>>А если бы я ещё и свои добавил! АХ>Давай.
А зачем? Это будет всего лишь моё мнение. Толку от этого списка ноль. Если хочешь своё мнение я могу сказать и так.
PI>>я тут думал, почему таких программ нет, и понял! PI>>то, что мы обсуждаем здесь — типичный олдскул PI>>рисование UML диаграмм вручную на бумаге ли, на планшете, маркером на мониторе — это олдскул S>Ничего подобного.
точно тебе говорю
PI>>не нужно его переносить один-в-один на цифровую технологию
PI>>вместо этого наш редатор должен оперировать такими простейшими операциями, как: PI>>- кинуть на лист класс PI>>- кинуть на лист интерфейс PI>>- прокинуть связь между классами (причем, связь должна "красиво" ложиться на лист, по возможности, сохраняя граф плоским) S>Гм. Вот как раз такому софту сто лет в обед. Тема обсуждения как раз в том, что никто не хочет пользоваться Rational Rose! Кинуть класс, кинуть интерфейс... S>Это хорошо подходит для случаев, когда нужно задокументировать хорошо известную штуку. S>Цитата: S>
Я почти профессионально владею фотошопом, также приходилось пользоватся и векторными редакторами, они весьма удобны для своих задач, но для проектирования, для "думания с карандашом в руке" абсолютно непригодны, я за то время как что нибудь нарисую в какой-нибудь диа или визио успею забыть о чем думал а с карандашом за то же время уже набросаю пару эскизов
S>Я под ней полностью подпишусь! У меня стол зарастает бумажками за неделю — результаты думания на бумаге. Это и deployment diagram, и workflow, и class diagram, и блок схемы и все что угодно. Просто потому, что за 30 секунд я могу нарисовать гораздо больше квадратиков, чем классов в розе.
а для меня вот, максимум что печатать приходилось — это клас-диаграмму после реверс-энжиниринг, и ниче рисовать не надо
а то, что ты больше квадратиков рисуешь — это напоминает мне давний спор калькуляторщиков и счетоводов (кто на на счетах считает)
вторые даже обгоняли калькуляторщиков — пока калькуляторы были медленные и неудобные
вот представь себе, я повесик шорткаты (или макросы) на такие команды:
(не знаю, есть ли они уже сейчас в редакторах)
F1 — добавить класс
F2 — добавить абстрактный класс
F3 — добавить интерфейс (и прицепить к последнему классу)
F4 — добавить поле к текущему классу
F5 — прокинуть связь между последними двумя классами
... и пр.
если что, можно мышкой перекидывать связи
ну всё, а теперь представь, я как в шутере буду — левой рукой по клаве педалить, а правой мышу дергать
и ты мне говоришь, что ты меня обгонишь по скорости создания диаграмм?
мне трудно это представить (хотя я себе представляю промышленного робота, разваливающегося от таких перегрузок)
так что всё дело в привычке — я не заставляю тебя менять их
... к сожалению, мне кажется "ньюскул" сменит "олдскул" только при смене поколений
(меня вот сама мыша уже ой как достала, как будто это универсальное средство ввода, можно подумать...)
Здравствуйте, Sinclair, Вы писали:
PI>>вместо этого наш редатор должен оперировать такими простейшими операциями, как: PI>>- кинуть на лист класс PI>>- кинуть на лист интерфейс PI>>- прокинуть связь между классами (причем, связь должна "красиво" ложиться на лист, по возможности, сохраняя граф плоским) S>Гм. Вот как раз такому софту сто лет в обед. Тема обсуждения как раз в том, что никто не хочет пользоваться Rational Rose! Кинуть класс, кинуть интерфейс...
К сожалению ссылки у меня не осталось, но видел в инете видео (наверное годов начала 80-х), где мужик демонстрировал системку, в которой скретчишь пером, а у на экране в итоге появляются красивые правильные фигуры. Нарисовал крестик на линии — она удалилась. Правда он ее позиционировал как скретчер для CAD.
Здравствуйте, Андрей Хропов, Вы писали:
L>>Что такое управляемые динамические возможности, из-за которых Хаскель и Окамл пролетают? АХ>Я так понимаю имелось в виду Late binding macro.
Я думаю все еще прозаичние... ИМХО Влад имел в виду возможность привести ссылку на базовый класс к производному с проверкой во время работы программы.
АХ>В статических языках в большинстве случаев хватает наследования и миксинов/traits. АХ>Последних в Nemerle пока нет, но, надеюсь, появятся.
Напиши макрос. Делов то...
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
WH>Я думаю все еще прозаичние... ИМХО Влад имел в виду возможность привести ссылку на базовый класс к производному с проверкой во время работы программы.
Думаю что нет, поскольку он упомянул, что в C++ этого нет. Ну и я бы это прям такими "динамическими возможностями не назвал"
АХ>>В статических языках в большинстве случаев хватает наследования и миксинов/traits. АХ>>Последних в Nemerle пока нет, но, надеюсь, появятся. WH>Напиши макрос. Делов то...
Не все так просто. Тут нужно чтобы это грамотно продумано было и вписывалось в дизайн языка. Важна правильная концепция а не технические детали. Да и я не специалист по внутренностям компилятора Немерле пока.
Здравствуйте, Андрей Хропов, Вы писали:
АХ>Думаю что нет, поскольку он упомянул, что в C++ этого нет. Ну и я бы это прям такими "динамическими возможностями не назвал"
Скорей всего он просто забыл про dynamic_cast.
В любом случае макрос late это специфика немерле.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, lomeo, Вы писали:
L>>>Что такое управляемые динамические возможности, из-за которых Хаскель и Окамл пролетают?
АХ>>Я так понимаю имелось в виду Late binding macro.
L>Прикольно, т.е. можно написать late {...} и писать динамически типизированный код?
Да, хотя я признаюсь пока с этим не игрался. Возможно там подводные камни есть.
А также в блоках динамического кода можно вставлять nolate чтобы пользоваться обычными проверками.
Да, для тех кто не знает в Немерле возможны и ленивые вычисления.
L>>>ООП слишком сложный вопрос. ОО — всего лишь слово. Разных ОО моделей — вагон и маленькая тележка.
АХ>>Да, это зависит от того что понимать под ОО.
АХ>>В принципе основные мысли были написаны тут: Re: Что такое ООП
.
L>Угу, в курсе, что под ОО обычно понимают совсем не то, что создатель термина. Однако, имелось в виду несколько другое. Пусть ООП — это инкапсуляция, наследование, полиморфизм. Однако даже в таком случае реализаций очень много. Вот модификаторы доступа — public, private, protected и каждый язык добавляет какие ему надо. Можем ли мы задавать свои? Например, поля, которые видны только из классов из пакета ааа с именем AAASome* Это что касается инкапсуляции. Подобные примеры можно придумать и для наследования и полиморфизма.
Это сводится к философскому спору хорошо ли когда все позволено.
L>>>Лисп позволяет написать нужный тебе ОО, а вот Немерле разрешит мне написать ОО на прототипах?
АХ>>Думаю, что проблематично, если ты имеешь ввиду — "скопируй объект и измени/добавь методы по вкусу". АХ>>Но это динамический стиль. И в этом стиле гораздо сложнее соблюдать инкапсуляцию и проверять инварианты, что на мой взгляд очень важно.
L>Это уже неважно. Не будем забывать о блаб программистах и будем оперировать понятиями не достоинство/недостаток (которое может быть сильно субъетивным), а фича. Важно, что эта черта у дотнета, а следовательно у Немерле отсутствует, я прав?
У Немерле есть такая мощная штука как макросы, поэтому утверждать что это невозможно не возмусь .
Другое дело, что в целом это не совсем вписывается в его (Nemerle) идеологию.
С третьей стороны на CLR возможна реализация таких динамических языков как JScript.NET и Питон, а значит все же при желании подобные вещи возможно делать. А все что возможно в рамках .NET CLR возможно на Немерле. Так что...
АХ>>В статических языках в большинстве случаев хватает наследования и миксинов/traits. АХ>>Последних в Nemerle пока нет, но, надеюсь, появятся.
L>Я об этом и говорю, составить список, в котором Немерле будет пролетать проблем нет.
Ну попробуй, но опять же как и в Лиспе в Немерле можно ОЧЕНЬ многое сделать с помощью макросов.
Насчет недостатков:
Мне как performance freakу хотелось бы конечно опциональных низкоуровневых возможностей для битовыжимания и ручного управления памятью .
Ну и понятие владения объектом как в C++, чтобы можно было сделать настоящую константность, а то возможны вот такие вещи
А зависимость от .NET меня не особо пугает хотя бы потому, что в Mono есть утилита mkbundle.
L>>> Зачем же его выкидывать? Или вот CLOS гораздо мощнее дотнетовского ОО АХ>>Мультиметоды?
L>Угу, например. Или аспекты (method combination).
В смысле AOP (aspect-oriented programming)?
А пример можно как это делается на CLOS?
АХ>>А то что там можно на лету менять реализацию методов или добавлять их по мне так не является достоинством.
L>Опять таки это всего лишь мнение. Ты пробовал писать на селфе или чём то подобном?
нет. Да, вроде как JavaScript а него похож в смысле прототипирования, я слышал.
L>>>Нет-нет, не факт, а твоё мнение. Например, у меня Немерле по этому же списку отсеился в нескольких пунктах. L>>>А если бы я ещё и свои добавил! АХ>>Давай.
L>А зачем? Это будет всего лишь моё мнение. Толку от этого списка ноль.
Не 0. Мы тут собственно обсуждаем различные идеи в дизайне языков. Если есть хорошие идеи которые Влад не упомнянул, а ты можешь о них сказать, заодно аргументировав почему они на твой взгляд важны, то всем будет интересно.
L> Если хочешь своё мнение я могу сказать и так.
давай
PI>>>лучше бы сделали, как в университете, где мой кореш учиться (Германия) — они там учат 2 языка: PI>>>Хаскель и Java
DG>>В MIT не учат языкам, в MIT учат подходам к решению задач. PI>а ты разве учился в МИТ?
Плавали -- знаем.
DG>> LISP в том общем курсе, с которого начался этот топик -- всего лишь DG>>средство для реализации этих задач. PI>я думаю причина присутствия лиспа в том курсе аналогична причине включения виртуальной машины в труде Кнута
+1
DG>>Непонятно вот только, то ли задачи изменились, то ли средства устарели. PI>минутная блажь, поменяют обратно, надеюсь PI>а "задачи" за долгие десятилетия существенно не менялись, могу тебя уверить
Кстати о Хаскеле в немецких ВУЗах, тут тоже политика, есть несколько местных монстров которые достаточно сильно влияют на вузовские курсы. Впрочем,это уж точно оффтоп.
Здравствуйте, Курилка, Вы писали:
К>Здравствуйте, Dr.Gigabit, Вы писали:
К>>>Ну расскажи, что же там продаётся DG>>Продаются там САПовские сервисы, и куча консалтеров, присосавшихся к кормушке К>А я тебе о чём.
К>>>Типовые решения, написаные большей частью на этом самом ABAP/4 + рантайм для этого всего. К>>>Ты думаешь, что суть абапа ("коболовская" идеология — куча разных слов и т.п., почти никакой типизации, пляска от БД) не имеет отношения к тому, что на нём было написано и продавалось? DG>>Я думаю там первично то, что написано, а не на чем. К>Опять же это только подтверждает мою мысль
Консенсус Ключевое слово здесь там. Я погалаю мы здесь обсуждаем программирование в "правильном" понимании, а не применительно к САП и прочим 1С. Да, это солидная область, да там рулит именно что а не как. Но область не единственная.
К>>>"Местный" пример 1С показывает, что, возможно, это далеко не так. DG>>1С нескольно некорректно сравнивать с SAP. К>Не знаю, учитывая масштаб, думаю вполне можно. Хотя 1С это лишь первое что пришло в голову, думаю таких примеров порядком.
Неа, не найдешь таких примеров, как не ищи
[skiped]
К>А по поводу явы — ты очень заблуждаешься. Возьми хотябы R/3 и посмотри сколько там явы и сколько абапа. Ява большей частью в вебных делах крутится (EP в основном). Основные же решения — это как раз ERP, а там от обратной совместимости САП фиг откажется. Поэтому, допустим, и получили в том же ABAP/4, как пишет SAP Professional Journal, jungle of possibilities (хотя я бы это несколько другими словами назвал ) К>Да и вообще core SAP — это рантайм, писаный на сях, на котором крутится туева хуча абапного кода, ну и ещё небольшая доля явовского application сервера.
Мысль интересная, сколько в САПе процентов с++, явы, абапа и прочего Г Думаю, такой статистикой даже они сами не владеют. Так что тут спорить бессмысленно.
Здравствуйте, PhantomIvan, Вы писали: S>>Я под ней полностью подпишусь! У меня стол зарастает бумажками за неделю — результаты думания на бумаге. Это и deployment diagram, и workflow, и class diagram, и блок схемы и все что угодно. Просто потому, что за 30 секунд я могу нарисовать гораздо больше квадратиков, чем классов в розе. PI>а для меня вот, максимум что печатать приходилось — это клас-диаграмму после реверс-энжиниринг, и ниче рисовать не надо
Ну вот я и говорю — reverse engineering уже есть. А думать как на бумажке роза не позволяет. PI>вот представь себе, я повесик шорткаты (или макросы) на такие команды:
Дело не в шорткатах. Ладно, спор бессмысленный. Просто поверь на слово: то, что ты сейчас изобрел, существует больше десяти лет и нифига не помогает. Доказано занусси. У меня (и еще нескольких участников) есть гипотеза о том, что проблему мог бы решить софт для распознавания черновиков. Желательно в реальном времени и интерактивно.
Во-первых, это гипотеза.
Во-вторых, ее проверка затрудняется тем, что нужен не просто абы какой софт, а софт качественный. Если ему придется сильно много подсказывать, то никто не будет им пользоваться, и ровно по той же причине: неудобно. Идея в том, чтобы распознавалка ничего мне не навязывала, но при этом извлекала максимум смысла из того, что я делаю.
PI>и ты мне говоришь, что ты меня обгонишь по скорости создания диаграмм?
Естественно обгоню. Потому, что я буду рисовать только то, что необходимо, а тебе придется делать все формальности.
1.2.0 alpha rev. 655
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, lomeo, Вы писали:
L>Угу, в курсе, что под ОО обычно понимают совсем не то, что создатель термина. Однако, имелось в виду несколько другое. Пусть ООП — это инкапсуляция, наследование, полиморфизм. Однако даже в таком случае реализаций очень много. Вот модификаторы доступа — public, private, protected и каждый язык добавляет какие ему надо. Можем ли мы задавать свои? Например, поля, которые видны только из классов из пакета ааа с именем AAASome* Это что касается инкапсуляции. Подобные примеры можно придумать и для наследования и полиморфизма. (Вспомним хотя бы вечные споры о множественном наследовании).
Не надо, ради байта, ничего придумывать. Private/protected/public/internal и т.д. это не совсем инкапсуляция. Это возможность предоставлять различные контракты различным потребителям. Классификация потребителей зависит от того, какие предикаты можно вычислить на паре типов. В С++ это ровно три предиката: тождественный TRUE, коммутативный Equals, и транзитивный InheritsFrom.
Если преподавать это, то потом не возникнет дурацких вопросов типа "а protected — это инкапсуляция или нет?".
1.2.0 alpha rev. 655
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, EvilChild, Вы писали:
EC>Тебя опять подводит знание русского — с чего ты взял, что передо мной стоит подобный выбор? Потому, что я считаю, что плохой код сопровождать труднее?
Вопрос из серии "ты уже бросил пить коньяк по утрам?". На такой можно ответить только одно — с чего ты взял, что меня вообще когда-то подводило знание русского языка? У тебя очередное обострение болезни под названием "высасывание из пальца". Ты сказал:
Т.е. тебе нет разницы какой код сопровождать: просто плохой или изощрённо плохой?
На что тебе прозрачно намекнули, что в отличии от тебя, допускающего такой выбор, я перед подобным выбором не стою. Я просто не буду сопровождать плохой код и уж темболее очень плохой код. По сему вопрос не корректный. В прочем, кооректных вопросов от тебя я не слышал не разу.
В общем, завязывай с демагогий.
VD>>Заблуждаетесь вы в одном. В том что плохое получается от макросов (вмест них можно вписать что угодно по вкусу). Полхой код получается от небрежности, глупости, надменности и большого опыта. Хороший же искючительно от желания сделать код хорошим. Так что получив плохой код, сделай его хоршим. Вот и все.
EC>Опять какие-то домыслы — я здесь ниразу не озвучил своё отношение к макросам.
Конечно, домыслы. Ты здесь вообще не разу ни одной разумной мысли до коднца не высказывал. Просто задаешь откровенно глупые, алогичные вопросы. На подобные вопросы можно отвечать только, то что они не корректны. Но даже из пдобной ахинеи можно понять к чему человек пытается клонить. Демагогия ведь давно стала наукой. Ее приемы изучены и сразу видно куда клонит демагог.
Вот зачем, к примеру, задавать вопрос:
Т.е. тебе нет разницы какой код сопровождать: просто плохой или изощрённо плохой?
?
С большой долей уверенности можно сказать, что вопрос этот нацелен на оправдание плохого кода. Используется банальнийший демагогический прием — ограничение выбора. Ведь любому ребенку ясно, что превосходная степень "очень плохой" хуже чем просто "плохо", но не все способны распознать подвох (в списке ведь нет еще "хорошего" и "очень хорошего" кода) и понять, что вопрос по сути подстава. Темболее сложно это понять товарищам скловнным к барикадным войнам (когда вместо того чтобы отстаивать свою позицию по данному вопросу люди тупо отстаивают позицию группы к которой примкнули ранее) подобные "мелочи" практически незаметны.
EC> Видимо Nemerle благотворно влияет на способность фантазировать и читать между строк, что ты постоянно мне приписываешь мысли, которые я не высказывал.
Ояевидный бред, но забавно, что подобные примеры так так нравятся барикадщикам.
VD>>Это заставляет писать код без IDE. Да и не еао197 об этом говорить. Он вообще пишет код без приличной IDE и на языках где до рантайма о типах вообще ничего сказать нельзя. Они все у него в подсознании.
EC>>>Ты как блаб программист — ты не можешь себе их представить и думаешь, что их нет.
VD>>Чья бы кобыла мычала.
EC>Опять те же симптомы — я ничего не имею против Nemerle, более того я искренне желаю ему успеха, мне просто хотелось бы более уравновешенного диалога о нём, а не постоянного упоминания его к месту и не к месту, что только раздражает, как безвкусная реклама пива по телику.
Симптомы? Нет, батенька, это не симтомы. Это чистая клиника. Потрудись прочесть цитаты и ответить на вопрос "как связаны твои медецинские потуги с процитированным выше?".
Ты влез защищать черт знает, что и на первое замечание откровенно перешел на обсуждение личности оппонента. Причем умудрился разглядеть какие-то упоминания Немерла.
Так вот мой тебе совет. Если раздражает реклама, выключи ее. Перевожу для тех бестолковых, что пытаются трактовать слова дословно. Не нравится разговоры о Немерле или еще каких-то там технологиях которые? Кажется, что о чем-то говорят слишком часто и не к месту? Не открывай форумы и сайты где это происходит. У тебя есть выбор. В конце концов, создай свой сайт. Но не надо затыкать рот окружающим. Бери пример с других. Тот же Руби обсуждается и никто не запрещает этого делать. Наоборот это интересно.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, lomeo, Вы писали:
L>Что такое управляемые динамические возможности, из-за которых Хаскель и Окамл пролетают?
Ищи в Википедии описание КОП.
L>Насчёт терминов ФВП и первоклассные значения — это просто разные термины. Функции как первоклассные значения — это ФВП, которые можно создавать на лету, ну и хранить в данных, как и значения прочих типов.
ФВП есть и в С++. Я довольно подробно объяснял почему ошибочно исползовать этот термин там где должен использоваться тенмир ФПО (функции — первокласные объекты).
L>Вопрос — почему Скала не столь мощна в этом вопросе как Немерле?
Я этого не говорил. Скала имеет практически такую же поддержку ФПО.
L>ООП слишком сложный вопрос. ОО — всего лишь слово. Разных ОО моделей — вагон и маленькая тележка. Лисп позволяет написать нужный тебе ОО,
ООП в Лиспе это еще то извращение. Можно конечно его называть эдаким альтернативным взглядом, но практика показала, что такой взгляд не принимается большинстовом.
L> а вот Немерле разрешит мне написать ОО на прототипах?
Прототипы это не ООП. Обычно подобные языки называют "объектными". Собственно одно то, что подобный подход приводит к существенному замедлению кода лично для меня ставит на нем крест. К тому же у него опять же наблюдаются проблемы с зашитой.
В общем, лично мое мнение, что прототипный подход — это зло. По крайней мере для высокопроизводительного сложного софта разрабатываемого более чем одним человеком.
L>Насчёт наличия. Вот скажем в Хаскеле есть O'Haskell (ещё много чего на самом деле). Зачем же его выкидывать? Или вот CLOS гораздо мощнее дотнетовского ОО
Это далего не так. Лично для меня очень важными факторами являются простота, понятность и удобство. Они в CLOS отсуствуют на проч. А дотнетный ООП как раз самая что ни на есть классика проверенная временем и кучей народа. Единственное что есть в CLOS — это мультиметоды (причем весьма странные). Ну, так они элементарно реализуются где угодно. Было бы желание. Лично мне пока что достаточно паттерн-матчинга (для организации множественной диспетчерезации).
L> (а я думаю, что ОО Немерле — это и есть ОО дотнета, я прав?). Однако мы же Немерле не выкидываем. Очень субъективный этот пункт номер семь.
Было бы глупо викидывать продукт поддерживающий наиболее популярную реализацию ООП. Мне кажется всем любителям экзотики надо понимать, что если экзотику не приняли на протяжении 30 и более лет, то проблема именно в ней, а не в окружающих. Это как в том анегдтоте когда на замечание, что какой-то идиот едет по встречной полосе товарищь отвечать, что их здесь тысячи...
L>А TemplateHaskell — это не сюда?
TemplateHaskell именно сюда. И если ты потрудишся прочесть статью о метапрограммировании в Немерле, то узнаешь, что он был одним из рассматриваемых языков опыт которго был учтен в Немерле. Там же описаны недостатки TemplateHaskell. От себя скажу только одно. Этот продукт в отличии от Немерле вообще вряд ли увидит мэйнстрим. Он так и останется в рамках эксперемента. Меж тем реальный Хаскель его возможностями не обладает. Да и опять же это одна из многих возможностей.
VD>>11. Встроенная поддержка параллелизма. Тут в списке остается только Эрлэнг. Но Немерле, ОКамл и Лисп позволяют добавить подобнрые фрэймворки в виде библиотеки. Так что пункт не столь очевиден.
L>ParallelHaskell? L>Но пункт да, невнятен.
Мне кажется пора остановиться. А то следующим притянутым за уши извращением станет ImperativeHaskell.
Есть огромная разница между Немерлом и любыми эксперементальными языками. Немерле будет зарелизен в ближайшее время и на нем можно без какого либо дискомфорта писаль практически любые приложения. Хаскель же так и останется игрушкой цель которой продемонстрировать возможности и подходы. А его эксперементальные ответвления вообще даже бессмысленно обсуждать. Это чисто научные работы. Они стольк долеки от жизни, что о них и говорить не стоит.
VD>>Теперь остается пробежать список и понять, что в итоге Немерле остался в одиночистве. Все конкуренты отсеялись на тех или иных этапах.
L> Ну, никто и не сомневался.
Не только сомневался, но и даже занимаются самовнушением чтобы не видеть очевидного.
VD>>Конечно можно сказать, что кому-то некоторые пункты могут оказаться не важными, но факт отсается фактом.
L>Нет-нет, не факт, а твоё мнение.
Если повторять себе это перед сном, то в это можно даже поверить. По как-что из фактов я от тебя ничего не услышал. Только притягивание за ущи разной эксперементальной лабуды и попытки тыкнуть в незначительные мелочи в моих словах (придраться к словам).
L>Например, у меня Немерле по этому же списку отсеился в нескольких пунктах. А если бы я ещё и свои добавил!
По каким? Давай обсудим.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Dr.Gigabit, Вы писали:
DG>Здравствуйте, Курилка, Вы писали:
К>>А по поводу явы — ты очень заблуждаешься. Возьми хотябы R/3 и посмотри сколько там явы и сколько абапа. Ява большей частью в вебных делах крутится (EP в основном). Основные же решения — это как раз ERP, а там от обратной совместимости САП фиг откажется. Поэтому, допустим, и получили в том же ABAP/4, как пишет SAP Professional Journal, jungle of possibilities (хотя я бы это несколько другими словами назвал ) К>>Да и вообще core SAP — это рантайм, писаный на сях, на котором крутится туева хуча абапного кода, ну и ещё небольшая доля явовского application сервера. DG>Мысль интересная, сколько в САПе процентов с++, явы, абапа и прочего Г Думаю, такой статистикой даже они сами не владеют. Так что тут спорить бессмысленно.
Да ты возьми хотя бы основные вещи саповские и посмотри. Думаю в R/3 (которая щаз вроде ECC зовётся) нет вообще явовского кода, а она занимает большую часть саповского бизнеса. На яве в основном "внешние" примочки, типа Enterprise Portal, вся логистика и прочие модули ERP на абапе.
Хотя спорить и правда надоело
1.2.0 alpha rev. 655
