Здравствуйте, Курилка, Вы писали:
К>И интересно было бы увидеть эрланговскую модель на статически типизированном языке. Причём не только посылку сообщений (что есть в скале), но и хотябы часть инфраструктуры (как минимум взаимодействие в рамках больше чем одной ВМ)
Мне тоже. Но это объем работы. Уверен, что все можно реализовать довльно шустро. Единственная проблема — это отем состояния у псевдо-потоков. Можно использовать зеленые потоки, но боюсь они будут медленнее чем у Эрлэнга. Смый простой вариант это организовать кооперативную многозадачность. Для многих задач бльшего и не надо. Этот варинт по скорости порвет все что угодно, но конечно программировать с расчетом на то что управление долго держать нелья не так просто.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, Gajdalager, Вы писали:
G>>Не то.. Это работа с SQL через макросы.. Я имел в виду "вместо синтаксиса SQL использовать Nemerle". Хотя согласен, пример дурацкий
VD>А зачем сравнивать декларативый язык запросов с универсальным языком скриптов? VD>Давай такогда так. Вместо регексов ты будешь использовать Баш. Бред? Ну, вот такой же бред замена SQL-я универсальным языком. VD>Хотя рельно языки вроде Немерла без проблем могут обеспечить инфраструктуру запросов не хуже чем в SQL. Смотри, например, LINQ от МС.
К слову сказать, есть такая типа сверх-современная идея, как конструирование запросов к БД из list comprehensions (слова для гугления — kleisli, язык программирования links, в какой-то степени и LINQ "про это").
Лично мне она нравится
Таким образом, "вместо синтаксиса SQL использовать <подставьте-ваш-язык-если-он-достаточно-функционален>" — не такая уж идиотская идея
VD>А зачем сравнивать декларативый язык запросов с универсальным языком скриптов? VD>Давай такогда так. Вместо регексов ты будешь использовать Баш. Бред? Ну, вот такой же бред замена SQL-я универсальным языком. VD>Хотя рельно языки вроде Немерла без проблем могут обеспечить инфраструктуру запросов не хуже чем в SQL. Смотри, например, LINQ от МС.
о, я понял что надо делать
надо говорить про "почти правильную объектную модель", приводя примеры из с++
про функции как первоклассные значения на примере хаскеля
про макросы, приводя в пример лисп (или клоны)
про удобства статической типизации на примере джава (чтоб дотнет даже не вспоминать)
про среду разработки тоже надо джаву приводить в пример (ну, эклипс скажем)
че там ещё... а, паттерн-матчинг, это надо окамль в пример ставить
а если кто вдруг спросит, а чё все примеры на этих разных языках, надо отвечать
"а я на их смеси пишу, вот..."
ANS>То есть "regexp match(line)" находит только первое совпадение с патерном и не срабатует для всех последующих?
ээээээээ...
я за последние полгода написал только 3 строчки регэкспов (символов по 100)
а потом их переписал на строковые операции, потому что они тормозили, а мне нужно было много парсить...
поэтому
S>>Поэтому предложенная реализация благополучно сдохнет на 10 гигах без переносов. В отличие, смею полагать, от grep.
VD>На 10 гигах сдохнит скорее всего что угодно. Но какой смысл в этом если текстовые файлы не превышают 3-х меторов.
регекспы, особенно с look-behind/look-forward условиями, сдохнут и на мегабайтной строке
АХ>>Я считаю что вообще все надо читать на компьютере (не обязательно ПК конечно). АХ>>А уж смысла читать программы без компьютера вообще ну ни вижу никакого. АХ>>Только если из интереса окунуться в атмосферу 50-х — 60-х годов XX века.
VD>Ну, это явный перегиб. Лично мне читать статьи и книги проще с бумаги. VD>Даже не смотря на то, что ссылки на ней не работают.
E>>Все, дальше тебе можно ничего не объяснять. Будучи профессиональным продавцов IT-пиара ты не можешь просто понять, что я не пиарю Ruby.
VD>Слив засчитан.
ты видишь, ты так постепенно придёшь к пониманию того, что падонковщина — необходимый инструмент ведения дискуссии
а там и до мата недалеко
растём-с
К>>>Если по сути — интересно, вроде как всего в 2 раза медленней Эрланга. PI>>естественно, на дотнете должно заработать гораздо быстрее
VD>Это зависит от качества реализации.
я имел в виду тождественные реализации
(а вообще, когда я говорю о параллельности, я имею в виду параллельность на основе нормальных потоков оси)
VD>>>Скромный вопрос, а кого ты цитирушь?
PI>>ну, тебя вообще-то
VD>Уверен, что точно?
немного утрировал, а что?
несвязный проект — это не проект, а набор разнородных проектов
а если "однородных проектов" — то это bad design (индусский код), где всё можно объединить на основе библиотек/макробиблиотек
Здравствуйте, PhantomIvan, Вы писали:
ANS>>То есть "regexp match(line)" находит только первое совпадение с патерном и не срабатует для всех последующих?
PI>ээээээээ... PI>я за последние полгода написал только 3 строчки регэкспов (символов по 100) PI>а потом их переписал на строковые операции, потому что они тормозили, а мне нужно было много парсить... PI>поэтому
А ты их компилировал (RegexpOptions.Compiled)?
Еще лучше на самом деле вообще иметь compile-time регекспы на макросах (в D и Немерле это возможно).
PI>>я за последние полгода написал только 3 строчки регэкспов (символов по 100) PI>>а потом их переписал на строковые операции, потому что они тормозили, а мне нужно было много парсить...
АХ>А ты их компилировал (RegexpOptions.Compiled)?
разумеется
если они не скомпилены, то выполняются на регексп-интерпретаторе, не так ли?
но там намучено что-то, например, регексп, относительно быстро выполняющийся в проверочной проге (Expresso), в реальном коде затормаживается больше, чем в 10 раз (причём не на всех подставляемых файлах)
ты можешь в это поверить? ведь Expresso выполняет регекспы вызывая, тот же дотнетный код
короче, даже не заторможенные они давали слишком большие тормоза (3 сек, look-behind условия, чтоб было яснее)
плюс были исключения из правил в контенте, я плюнул — и на стрингах переписал, перемалывает данные аж винт дымится
АХ>Еще лучше на самом деле вообще иметь compile-time регекспы на макросах (в D и Немерле это возможно).
ага, синт. сахар для стринговых операций — может быть, не регекспы, а их подмножество
есть идеи реализации?
Здравствуйте, VladD2, Вы писали:
VD>Рад что появились какие-то еще средства.
Да, собственно, они существуют уже довольно-таки давно.
VD>Раньше кроме Цигвина я ничего найти не мог. Но один хрен их прийдется искать, ставить, изучать...
Это все можно сказать и про любые другие инструменты. А если есть опыт работы с unix-системами, то изучать дополнительно ничего и не надо — они аналогичны одноменным никсовым утилитам.
VD>>Раньше кроме Цигвина я ничего найти не мог. Но один хрен их прийдется искать, ставить, изучать...
С>Это все можно сказать и про любые другие инструменты. А если есть опыт работы с unix-системами, то изучать дополнительно ничего и не надо — они аналогичны одноменным никсовым утилитам.
не люблю юниксовые инструменты, портированные на винду
они, как правило, глючат
Здравствуйте, WolfHound, Вы писали:
WH>Точно также можно наехать на любую конструцию языка высокого уровня... for конечно удобен но для того чтобы его понять нужно прочитать книжку по С... толи дело куча jmp, jnz... все просто и понятно...
Сравнение некорректное. Если в некоторую контору приходит программист, и говорит, что он знает язык "Х", то это уже автоматически предполагает, что он знает конструкции этого языка (если не соврал). В случае же со своими языковыми "велосипедами" потребуется его сначала научить кататься на этих "велосипедах".
Здравствуйте, PhantomIvan, Вы писали:
PI>не люблю юниксовые инструменты, портированные на винду PI>они, как правило, глючат
Не люблю Unix, не работаю на нем.
Не люблю Unix-овые утилиты под Windows, они глючат, не пользуюсь ими.
Не люблю динамические языки, не понимаю динамику, не программирую на них.
Не люблю немейстримовые функциональные языки (Haskel-ы там, OCaml-ы всякие), сложные слишком, не знаю их, не пользуюсь ими.
Не люблю вообще немейнстримовое, не знаю что там есть, пользуюсь только мейнстримом.
Зато точно знаю, что Nemerle круче всех!
Не скучно вам с такой непоколибимой уверенностью?
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, PhantomIvan, Вы писали:
PI>о, я понял что надо делать PI>надо говорить про "почти правильную объектную модель", приводя примеры из с++ PI>про функции как первоклассные значения на примере хаскеля PI>про макросы, приводя в пример лисп (или клоны) PI>про удобства статической типизации на примере джава (чтоб дотнет даже не вспоминать) PI>про среду разработки тоже надо джаву приводить в пример (ну, эклипс скажем) PI>че там ещё... а, паттерн-матчинг, это надо окамль в пример ставить
PI>а если кто вдруг спросит, а чё все примеры на этих разных языках, надо отвечать PI>"а я на их смеси пишу, вот..."
и, что еще смешнее, "... и деньги за это получаю".
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, Курилка, Вы писали:
К>>Плюс Скала — имеративный язык, со всеми вытекающими (хотя чётко аргументировать тут сейчас не могу).
VD>Эрлэнг тоже не чистый ФЯ. Что из этого вытекает?
Я про чистый и не говорил. Просто теже только immutable переменные позволяют хотябы иначе делать сборку мусора.
Но в такой постановке обсуждать желания нет, сорри
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, Курилка, Вы писали:
К>>Нет там потоков. К>>В том весь и смысл, что параллельность получается не на потоках ОС, т.е. нет постоянных переключений контекста, что позволяет ускорить работу приложения (при наличии нескольких процессов).
VD>Ты бы разобрался в том что обсуждаешь, а потом бы разговоры вел. Чушь ведь несешь.
Ты бы читал сначала, прежде чем отвечать, Влад, это уже просто из раза в раз повторяется.
VD>Ни одна современная ОС не даст прложению доступа к преключению контекстов физических процессоров. Так что что Эрлэнг, что Скала несколько процессоров будут использовать через потоки ОС. В Эрланге сделано распараллеливание на уровне псевдо перключений контекстов. Реально все происходит в рамках одного потока. И за счет того, что контекст получается маленьким и не происходит переключения в нулевое кольцо защиты процессора, скорость переключения получаетсявысокой. До недавнего времени Эрланг вообще не мог распараллеливат задачи на разных процессорах в рамках одного физического процесса. Недавно такая возможность была добавлена, но оверхэда ОС они обойти не смогут. Так что ручное распараллеливание на более низком уровне окажется за всегда более быстрым.
И? Я говорил что-то противоположное этом? Я же гововорил, что нет постоянного переключения между тредами (что было бы в реализации процессов чисто на потоках). И именно засчёт этого и получается выигрыш.
И твои слова как раз являются описанием того, что я имел в виду. Чуть более подробным.
Просто фантом сказал, что будет много круче из-за разницы между потоками явы и .нет. Я же сказал, что это тут совсем не существенно (возможно многопроцессорность сделает это более значимым, но это другая тема).
Здравствуйте, PhantomIvan, Вы писали:
К>>>>Если по сути — интересно, вроде как всего в 2 раза медленней Эрланга. PI>>>естественно, на дотнете должно заработать гораздо быстрее
VD>>Это зависит от качества реализации.
PI>я имел в виду тождественные реализации PI>(а вообще, когда я говорю о параллельности, я имею в виду параллельность на основе нормальных потоков оси)
Вот в этом и вопрос, что это не обязательно, я тебе возразил, на что Влад, возразил мне, и подробней объяснил, в чём, возможно, не всегда правильна твоя т.зр.
