Какой выбрать язык?
Gennadij Pastuhov
Я дозрел до практической реализации одного проекта, который можно на первом
этапе развития охарактеризовать следующими вещами (примеры сильно упрощены):
- очень развитый пользовательский интерфейс (похож на visio);
- активное использование БД (например, postgresql);
- сначала хочу делать всё сам, но вероятно подключение сторонних разработчиков.
Вопрос такой: какой выбрать язык/набор языков для написания ядра системы? Опыт
написания достаточно больших кусков кода у меня есть на С, С++, perl, PHP, ksh,
изучить что-нибудь новое не боюсь :) Собственно сам стою на распутье перед
erlang, python, java, C++.
... Jonny wanna live
Serguey Zefirov
GP> Опыт написания достаточно больших кусков кода у меня есть на С, С++,
GP> perl, PHP, ksh, изучить что-нибудь новое не боюсь :) Собственно сам стою
GP> на распутье перед erlang, python, java, C++.
Hу, перечисляй плюсы-минусы и зачем сдалось. ;)
Yours truly, Serguey Zefirov (thesz AT mail DOT ru)
Dmitry Karasik
Gennadij> Вопрос такой: какой выбрать язык/набор языков для написания ядра
Gennadij> системы? Опыт написания достаточно больших кусков кода у меня
Gennadij> есть на С, С++, perl, PHP, ksh, изучить что-нибудь новое не
Gennadij> боюсь :) Собственно сам стою на распутье перед erlang, python,
Gennadij> java, C++.
А по каким параметрам? Если по возможности gui + postgres, то только php и
ksh не подходят. А так, на чем нравится на том и пишите. Или, если уж
совсем несерьезно, если не страшно рыть нестандартные идеи - тогда erlang, если
конформизм привлекателен - java, если консерватизм - C++, а если "назло
маме пойду без шапки и отморожу уши" тогда уж python :)
--
Sincerely,
Dmitry Karasik
Ilya Anfimov
> Здравствуйте!
>
> Я дозрел до практической реализации одного проекта, который можно на первом
> этапе развития охарактеризовать следующими вещами (примеры сильно упрощены):
>
> - очень развитый пользовательский интерфейс (похож на visio);
А что, у Visio развитый пользовательский интэрфейс?
> - активное использование БД (например, postgresql);
Сейчас везде есть коннэкторы к БД. Везде -- в меру испорченности языка.
Gennadij Pastuhov
SZ> Hу, перечисляй плюсы-минусы и зачем сдалось. ;)
Плюсы-минусы языков? Зачем сдалось - давно обдумываю этот проект, и вот и
жизненная ситуация складывается удачно, что могу уделить ему время и польза от
него, если удастся реализовать успешно, должна быть заметная.
По языкам:
С++ - плюс в том, что имею большой опыт с ним, минус в том, что вроде вроде как
уже несовременный язык и слишком он общего плана, более специализированный
очень возможно будет эффективнее.
perl - тоже неплохо знаю, но направленность у него не та, что мне в данном
случае нужна.
php, shell - ну это понятно, тут они вообще не в кассу :)
erlang, python, java - базовое знакомство с ними есть, неплохая реализация
нужных фич, минус в том, что знаю их очень поверхностно, а erlang - так вообще
не знаю.
... Jonny wanna live
Gennadij Pastuhov
DK> А по каким параметрам?
Пока могу сформулировать несколько поверхностно: удобство работы с БД, сетью,
различными библиотеками (например, openGL), достаточная лёгкость понимания для
других разработчиков при желании присоединиться, быстрая работа (машины - если
интерпретатор, кода - если компилятор). Да, и самое главное - переносимость
полученного приложения, хотя бы и путём перекомпиляции, хотя бы между windows и
linux/freebsd.
DK> Если по возможности gui + postgres, то только php и ksh не подходят.
DK> А так, на чем нравится на том и пишите.
Вот и не могу определиться, что мне нравится. Вообще, например, интерпретаторы
мне больше нравятся, чем С++.
DK> Или, если уж совсем несерьезно, если не страшно рыть нестандартные
DK> идеи - тогда erlang,
Мне он понравился описанием, что в нём хорошая поддержка сети.
DK> если конформизм привлекателен - java,
Подробно не знаком, но вроде имеет кучу библиотек.
DK> если консерватизм - C++,
Знаю его лучше всех, но слишком уж он низкого уровня на сегодняшний день и код
не так чтобы совсем прозрачный для понимания.
DK> а если "назло маме пойду без шапки и отморожу уши" тогда уж python :)
А мне лет 5 назад этот язык очень понравился. Только не знаю, насколько будет в
нём удобно писать большие проекты.
... Jonny wanna live
Sergey Yevtushenko
GP> С++ - плюс в том, что имею большой опыт с ним, минус в том, что вроде
GP> вроде как уже несовременный язык и слишком он общего плана, более
GP> специализированный очень возможно будет эффективнее.
Писать на ++ такое приложение не то, что бы не удобно, а просто трудоемко.
Всякие мелочи типа работы с памятью будут сильно путаться под ногами. С другой
стороны, после ++ проще всего переходить на жабу, IMHO.
*----------------------------------------------------------------------
Gennadij Pastuhov
>> - очень развитый пользовательский интерфейс (похож на visio);
IA> А что, у Visio развитый пользовательский интэрфейс?
Да не особенно, конечно, просто мою софтину можно в некотором роде сравнить с
visio.
... Jonny wanna live
Ilya Anfimov
> Hi Gennadij!
>
> Gennadij> Вопрос такой: какой выбрать язык/набор языков для написания ядра
> Gennadij> системы? Опыт написания достаточно больших кусков кода у меня
> Gennadij> есть на С, С++, perl, PHP, ksh, изучить что-нибудь новое не
> Gennadij> боюсь :) Собственно сам стою на распутье перед erlang, python,
> Gennadij> java, C++.
>
> А по каким параметрам? Если по возможности gui + postgres, то только php и
> ksh не подходят. А так, на чем нравится на том и пишите. Или, если уж
дажэ они.
Dmitry Karasik
Gennadij> Пока могу сформулировать несколько поверхностно: удобство работы
Gennadij> с БД, сетью, различными библиотеками (например, openGL),
Gennadij> достаточная лёгкость понимания для других разработчиков при
Gennadij> желании присоединиться, быстрая работа (машины - если
Gennadij> интерпретатор, кода - если компилятор). Да, и самое главное -
Gennadij> переносимость полученного приложения, хотя бы и путём
Gennadij> перекомпиляции, хотя бы между windows и linux/freebsd.
Тогда скорее всего perl или ruby.
DK> а если "назло маме пойду без шапки и отморожу уши" тогда уж python :)
Gennadij> А мне лет 5 назад этот язык очень понравился. Только не знаю,
Gennadij> насколько будет в нём удобно писать большие проекты.
Это очень субъективное - кому удобно, а кому пробелы как синтаксис поперек
горла.
--
Sincerely,
Dmitry Karasik
Ilya Anfimov
>
> DK> А по каким параметрам?
>
> Пока могу сформулировать несколько поверхностно: удобство работы с БД, сетью,
> различными библиотеками (например, openGL), достаточная лёгкость понимания для
> других разработчиков при желании присоединиться, быстрая работа (машины - если
> интерпретатор, кода - если компилятор). Да, и самое главное - переносимость
> полученного приложения, хотя бы и путём перекомпиляции, хотя бы между windows и
> linux/freebsd.
Общие слова. В общем, стандартный набор, и каждый автор думает, что его
любимый язык всем этим обладает.
[skipped]
> DK> Или, если уж совсем несерьезно, если не страшно рыть нестандартные
> DK> идеи - тогда erlang,
>
> Мне он понравился описанием, что в нём хорошая поддержка сети.
Знаете, если бы я начинал что-то такое вот масштабное -- я бы
наверное его и взял. Мне он понравился тем, что там иногда
встречается очень понятный код. Hе в смысле, что понятно, что
будет в результате операцыи 2+2 -- а в смысле, что архитектура
написанного понятна по коду без долгих экспериментов и
многоуровневых отсылок.
При это функцыональный язык, с неизменяемыми переменными, и
очень дажэ приспособленный для real world в некоторых областях.
Ilya Anfimov
> Gennadij> с БД, сетью, различными библиотеками (например, openGL),
> Gennadij> достаточная лёгкость понимания для других разработчиков при
> Gennadij> желании присоединиться, быстрая работа (машины - если
> Gennadij> интерпретатор, кода - если компилятор). Да, и самое главное -
> Gennadij> переносимость полученного приложения, хотя бы и путём
> Gennadij> перекомпиляции, хотя бы между windows и linux/freebsd.
>
> Тогда скорее всего perl или ruby.
Под ruby хоть биндинги для Qt есть.
Gennadij Pastuhov
DK> Тогда скорее всего perl или ruby.
А если С++ + Qt ?
... Jonny wanna live
Alex Mizrahi
GP> системы? Опыт написания достаточно больших кусков кода у меня есть на
GP> С, С++, perl, PHP, ksh, изучить что-нибудь новое не боюсь :) Собственно
GP> сам стою на распутье перед erlang, python, java, C++.
тут скорее нужно не язык выбирать, а GUI тулкит. честно говоря, особо
хороших не встречал..
сейчас это модно вообще через веб делать, но там геморрой тот ещё.
для C++ лучшее что видел -- HTMLayout
(http://www.terrainformatica.com/htmlayout/). это HЕ web-based, но похоже --
но несколько лучше. из success stories у них какой-то круто заскиненный
продукт Symantec, емнип.
не на С++ я бы попробовал XUL и JavaScript. JavaScript популярен, но вместе
с тем поддерживает замыкания, легковесное OOP на основе прототипов и т.д.
а будущая версия ECMAScript вообще, говорят, монстрообразна -- она включает
в себя практически все фичи практически всех языков программирования.
некоторые говорят что JavaScript -- next big language.
Dmitry Karasik
>> Тогда скорее всего perl или ruby.
Tk, Perl-Qt, Perl-Gtk2, Wx-Perl, Prima. Обзоры и сравнения
есть на perlmonks.org .
--
Sincerely,
Dmitry Karasik
Dmitry Karasik
Gennadij> Вторник ноября 06 07 14:26 Dmitry Karasik писал к Gennadij
Gennadij> Pastuhov:
DK> Тогда скорее всего perl или ruby.
Gennadij> А если С++ + Qt ?
разрешаю ;)
--
Sincerely,
Dmitry Karasik
Ilya Anfimov
> Ilya> Покажыте под perl приличный кросс-платформенный widget toolkit.
>
> Tk,
Hо основе версии 10-летней давности.
> Perl-Qt,
Под 3-шку с её непортабельностью.
> Perl-Gtk2,
Бюэ-э-э-. И perl тут ни при чём.
> Wx-Perl,
Хм. Пропустил, да. А чего это его в Debian нет?
Ладно, не важно. Hадо посмтореть. Hо, по сути, жывой
юниксовый вариант только Gtk... Ладно, это ещё ничего.
> Prima. Обзоры и сравнения
Хм. Впервые слышу. Это интересно.
> есть на perlmonks.org .
>
Dmitry Karasik
Alex> не на С++ я бы попробовал XUL и JavaScript. JavaScript популярен, но
Alex> вместе с тем поддерживает замыкания, легковесное OOP на основе
Alex> прототипов и т.д. а будущая версия ECMAScript вообще, говорят,
Alex> монстрообразна -- она включает в себя практически все фичи
Alex> практически всех языков программирования. некоторые говорят что
Alex> JavaScript -- next big language.
+1 - JavaScript как язык очень вкусен, это правда. Если б он был жив
вне веба, точно был бы лидер.
--
Sincerely,
Dmitry Karasik
Ilya Anfimov
По сравнению с perlом и erlangом -- успешно сосёт. По разным
поводам, но...
То есть я не хочу сказать, что perl однозначно лучшэ javascript
или erlang однозначно лучшэ javascript. Hо во многом -- и тот и
другой лучшэ.
PS кстати, мне до сих пор непонятно -- почему его
не приспособили на сервер вместо php. Библиотек, его
реализующих вроде есть, опыт у web-писателей в писании
на нём -- тожэ. А вот...
Alex Mizrahi
IA> не приспособили на сервер вместо php. Библиотек, его
IA> реализующих вроде есть, опыт у web-писателей в писании
IA> на нём -- тожэ. А вот...
есть куча решений для server-side программирования на javascript.
наиболее популярные -- ASP/JScript и Apache Cocoon.
сейчас более модно, наверное, RubyOnRails-like фреймворки..
хотя такой популярности как PHP оно не получило -- момент упустили, имхо.
но могут ещё и наверстать с более продвинутыми реализациями
Alex Mizrahi
Alex>> вместе с тем поддерживает замыкания, легковесное OOP на основе
Alex>> прототипов и т.д. а будущая версия ECMAScript вообще, говорят,
Alex>> монстрообразна -- она включает в себя практически все фичи
Alex>> практически всех языков программирования. некоторые говорят что
Alex>> JavaScript -- next big language.
DK> +1 - JavaScript как язык очень вкусен, это правда. Если б он был жив
DK> вне веба, точно был бы лидер.
насколько мне известно оно теперь входит в комплект J2SE с версии 6 (через
javax.script), это вполне может живости и добавить..
Ilya Anfimov
> IA> PS кстати, мне до сих пор непонятно -- почему его
> IA> не приспособили на сервер вместо php. Библиотек, его
> IA> реализующих вроде есть, опыт у web-писателей в писании
> IA> на нём -- тожэ. А вот...
>
> есть куча решений для server-side программирования на javascript.
> наиболее популярные -- ASP/JScript и Apache Cocoon.
Dmitry Karasik
Ilya> По сравнению с perlом и erlangом -- успешно сосёт. По разным
Ilya> поводам, но...
Ilya> То есть я не хочу сказать, что perl однозначно лучшэ javascript или
Ilya> erlang однозначно лучшэ javascript. Hо во многом -- и тот и другой
Ilya> лучшэ.
Ilya> PS кстати, мне до сих пор непонятно -- почему его не приспособили на
Ilya> сервер вместо php. Библиотек, его реализующих вроде есть, опыт у
Ilya> web-писателей в писании на нём -- тожэ. А вот...
Писатэлэй боятся наверное.
--
Sincerely,
Dmitry Karasik
Alex Mizrahi
??>> наиболее популярные -- ASP/JScript и Apache Cocoon.
IA> Ах, так шумный Cocoon -- это про javascript?
не совсем понял вопрос..(может это была шутка юмора?)
в Apache Cocoon использование JavaScript называется Flowscript. используется
доработанный движок Rhino -- добавлены continuations, причём, говорят,
сериализуемые, так что работает с несколькими серверами.
посмотреть пример можно здесь:
http://cocoon.apache.org/2.1/userdocs/flow/continuations.html
function calculator()
{
var a, b, operator;
cocoon.sendPageAndWait("getA.html");
a = cocoon.request.get("a");
cocoon.sendPageAndWait("getB.html");
b = cocoon.request.get("b");
по-моему очень даже неплохо, но на лиспе это, конечно, круче :)
правда впоследствии умельцы добавили continuation'ы даже в java путём
инструментации, но простенький динамический язык там более к месту, imho
Ilya Anfimov
> ??>> есть куча решений для server-side программирования на javascript.
> ??>> наиболее популярные -- ASP/JScript и Apache Cocoon.
>
> IA> Ах, так шумный Cocoon -- это про javascript?
>
> не совсем понял вопрос..(может это была шутка юмора?)
>
на апачном сайте и в других местах, но особо не интересовался,
что это.
Ruslan Kosolapov
GP> Я дозрел до практической реализации одного проекта, который можно
GP> на первом этапе развития охарактеризовать следующими вещами
GP> (примеры сильно упрощены):
GP> - очень развитый пользовательский интерфейс (похож на visio);
GP> - активное использование БД (например, postgresql);
GP> - сначала хочу делать всё сам, но вероятно подключение сторонних
GP> разработчиков.
GP> Вопрос такой: какой выбрать язык/набор языков для написания ядра
GP> системы? Опыт написания достаточно больших кусков кода у меня
GP> есть на С, С++, perl, PHP, ksh, изучить что-нибудь новое не боюсь
GP> :) Собственно сам стою на распутье перед erlang, python, java,
GP> C++.
По такому скудному описанию логично посоветовать java ;)
А вообще тут видимо надо плясать от GUI, и на каком из языков есть
подходящий GUI toolkit, на том и писать.
--
rk
Serguey Zefirov
GP> жизненная ситуация складывается удачно, что могу уделить ему время и
GP> польза от него, если удастся реализовать успешно, должна быть заметная.
Пока по описанию это не очень видно. Hу, да ладно.
GP> С++ - плюс в том, что имею большой опыт с ним, минус в том, что вроде
GP> вроде как уже несовременный язык и слишком он общего плана, более
GP> специализированный очень возможно будет эффективнее.
GP> erlang, python, java - базовое знакомство с ними есть, неплохая
GP> реализация нужных фич, минус в том, что знаю их очень поверхностно, а
GP> erlang - так вообще не знаю.
Вот будут ли незнакомые тебе языки "более специализированными," - вопрос
открытый. По описанию проблемы не очень понятно. ;)
Поэтому придерживайся C++. ;)
Serguey Zefirov
DK>> А так, на чем нравится на том и пишите.
GP> интерпретаторы мне больше нравятся, чем С++.
Hу, у компилируемого Haskell есть и интерпретатор. Как я понимаю, только у
потомков C (C++, Java и другие D) нет интерпретатора в поставке. ;)
DK>> Или, если уж совсем несерьезно, если не страшно рыть нестандартные
DK>> идеи - тогда erlang,
GP> Мне он понравился описанием, что в нём хорошая поддержка сети.
Ха. Хаха. ;)
И это все? ;)
DK>> а если "назло маме пойду без шапки и отморожу уши" тогда уж python :)
GP> А мне лет 5 назад этот язык очень понравился. Только не знаю, насколько
GP> будет в нём удобно писать большие проекты.
Очень и очень неудобно. Динамическая типизация не для больших проектов.
Gennadij Pastuhov
DK>>> идеи - тогда erlang,
GP>> Мне он понравился описанием, что в нём хорошая поддержка сети.
SZ> Ха. Хаха. ;)
SZ> И это все? ;)
А больше я из описания мало чего понял...
DK>>> а если "назло маме пойду без шапки и отморожу уши" тогда уж
DK>>> python :)
GP>> А мне лет 5 назад этот язык очень понравился. Только не знаю,
GP>> насколько
GP>> будет в нём удобно писать большие проекты.
SZ> Очень и очень неудобно. Динамическая типизация не для больших
SZ> проектов.
Ок, спасибо, одним кандидатом меньше :)
... Jonny wanna live
Alex Mizrahi
SZ>> проектов.
GP> Ок, спасибо, одним кандидатом меньше :)
это личные религиозные убеждения Сергея, и к объективной действительности
они отношения не имеют.
можно найти немало примеров больших проектов реализованных на языках с
динамической типизацией.
ну, к примеру, Emacs сравним с Eclipse.
большие проекты? у меня версии оба под 130 MB распакованные.
первый в основном на emacs lisp (динамическая типизация), второй на java
(статическая). в обоих случаях часть написана на C/C++ (emacs lisp +
оболочка с одной стороны, JVM с другой), ей можно пренебречь.
по моим наблюдениям Emacs где-то на порядок стабильнее Eclipse, который
штатным образом падает если увидит XML файл чуть не той версии, и нештатным
от любого чиха.
кроме того Emacs в случае чего можно подправить -- вот я недавно починил
tramp для XEmacs, отладка и починка у меня заняла что-то вроде 10 минут, при
том что emacs lisp и сам tramp я видел второй раз в жизни.
когда же что-то глючит в Eclipse, у меня от одного вида бэктрейсов в логе
мурашки по телу.
итого мы доказали что для больших проектов динамические языки лучше
статических :).
бред, конечно, но я думаю и Сергей не может привести доводов лучше чем
сравнение яблок с апельсинами. с идеологической стороны в свете модного
test-driven development и т.д. проверку типов можно рассматривать как
вариант неких тупых unit-тестов автоматически проводимых компилятором при
сборке. по-идее простейшие юнит-тесты обеспечивают лучшую проверку, так что
это просто лишняя перестраховка..
Сергей ещё может заметить что нужно не просто статическая типизация, а
именно продвинутый вывод типов по Хиндли-Милнеру, т.е. Haskell. на это
заметим что вживую на хаскелле вообще мало приложений написано.
единственное чем мне доводилось пользоваться -- darcs -- работает более
криво и глючно чем CVS/SVN/git, так что мягко говоря преимуществ не видно..
Sergey Yevtushenko
AM> по моим наблюдениям Emacs где-то на порядок стабильнее Eclipse, который
AM> штатным образом падает если увидит XML файл чуть не той версии, и
AM> нештатным от любого чиха.
Ты только моему еклипсу этого не говори, ладно? А то он обычно у меня живет
весь аптайм, который частенько переваливает за пару месяцев (потом в кулер на
процессоре пыль набивается, приходится выключать и пылесосить).
*----------------------------------------------------------------------
Dmitry Karasik
Sergey> Ты только моему еклипсу этого не говори, ладно? А то он обычно у
Sergey> меня живет весь аптайм, который частенько переваливает за пару
Sergey> месяцев (потом в кулер на процессоре пыль набивается, приходится
Sergey> выключать и пылесосить).
Повеселился, спасибо ;) Пылесборник плохого качества (т.к. 3 месяца это не
аптайм) как аргумент против динамических языков вообще это здорово ;)
--
Sincerely,
Dmitry Karasik
Sergey Yevtushenko
DK> Повеселился, спасибо ;) Пылесборник плохого качества (т.к. 3 месяца это
DK> не аптайм)
Для десктопа - вполне себе аптайм.
DK> как аргумент против динамических языков вообще это здорово ;)
Я ничего не говорил о динамических языках, а всего лишь продемонстрировал
несостоятельность использования поведения еклипса в качестве аргумента.
*----------------------------------------------------------------------
Serguey Zefirov
SZ>>> проектов.
GP>> Ок, спасибо, одним кандидатом меньше :)
AM> они отношения не имеют.
AM> можно найти немало примеров больших проектов реализованных на языках с
AM> динамической типизацией.
Это не просто религиозные убеждения, это наблюдение за ежедневной практикой.
У нас тут всякого хватает. И статически типизированного и не очень.
AM> ну, к примеру, Emacs сравним с Eclipse.
AM> большие проекты? у меня версии оба под 130 MB распакованные.
Если сделать связность повыше, то будет поинтересней.
Малая связность приходит на третьей версии, примерно.
Редакторы достаточно отлажены, поэтому это не такой интересный пример. Если
взять что-нибудь еще не пробованное, тот же darcs, то связность будет
значительно выше приемлемого для программирования на динамических языках
уровня.
AM> бред, конечно, но я думаю и Сергей не может привести доводов лучше чем
AM> сравнение яблок с апельсинами. с идеологической стороны в свете модного
AM> test-driven development и т.д. проверку типов можно рассматривать как
AM> вариант неких тупых unit-тестов автоматически проводимых компилятором при
Почему? Могу.
Тут как-то пробегала задачка-электронная таблица. Ты даже ее решал.
Hедавний опыт ее решения на динамически типизированом Эрланге показал, что
практически все допущенные ошибки (даже логические) были бы выявлены
статической типизацией.
AM> сборке. по-идее простейшие юнит-тесты обеспечивают лучшую проверку, так
AM> что это просто лишняя перестраховка..
Any sufficiently large test suite for a program written in a dynamic language
will contain an ad-hoc, informally-specified, bug-ridden, slow, patchy
implementation of half of the Haskell type system.
;)
AM> Сергей ещё может заметить что нужно не просто статическая типизация, а
AM> именно продвинутый вывод типов по Хиндли-Милнеру, т.е. Haskell. на это
AM> заметим что вживую на хаскелле вообще мало приложений написано.
По сравнению с Лиспом - да.
Hу, так еще все спереди. Да и написаны они были на других языках потому, что
Хаскеля не было. ;)
Короче говоря, даже ОКамл приличней Эрланга или Питона.
AM> единственное чем мне доводилось пользоваться -- darcs -- работает более
AM> криво и глючно чем CVS/SVN/git, так что мягко говоря преимуществ не
AM> видно..
А мне нравится. ;)
Hа лиспе (питоне, you name it) же вообще нет систем контроля версий. ;)
Alexey Desyatnik
SZ> Короче говоря, даже ОКамл приличней Эрланга или Питона.
Интересно, что и в O'Caml, и в Сlean через определённое время появилась
опциональная динамическая типизация, да и в С++ с Java без неё не обошлось.
Попытки прикрутить статическую типизацию к динамическим языкам были, но
особого успеха почему-то не поимели.
SZ> Hа лиспе (питоне, you name it) же вообще нет систем контроля версий. ;)
Mercurial написан на питоне (за исключением diff-части), и он достаточно
надёжен и функционален, чтобы его использовали для таких проектов, как
OpenSolaris и Mozilla.
Dmitry Grebeniuk
AD> Интересно, что и в O'Caml, и в Сlean через определённое время
AD> появилась опциональная динамическая типизация, да и в С++ с Java без
AD> неё не обошлось.
В OCaml и C++ она изначально была. (про Clean и Java не знаю точно)
Определённое время между чем и чем Вы имеете ввиду?
bye
Alex Mizrahi
AM>> это личные религиозные убеждения Сергея, и к объективной
AM>> больших проектов реализованных на языках с динамической типизацией.
SZ> Это не просто религиозные убеждения, это наблюдение за ежедневной
SZ> практикой.
наблюдений за ежедневной практикой у всех хватает, выводы разные
AM>> ну, к примеру, Emacs сравним с Eclipse.
AM>> большие проекты? у меня версии оба под 130 MB распакованные.
SZ> Если сделать связность повыше, то будет поинтересней.
SZ> Малая связность приходит на третьей версии, примерно.
связность чего?
SZ> Редакторы достаточно отлажены, поэтому это не такой интересный пример.
в плане не глючат? у меня глючат, и тот и другой..
SZ> Почему? Могу.
SZ> Тут как-то пробегала задачка-электронная таблица. Ты даже ее решал.
SZ> Hедавний опыт ее решения на динамически типизированом Эрланге показал,
SZ> что практически все допущенные ошибки (даже логические) были бы
SZ> выявлены статической типизацией.
честно говоря не понимаю как она может что-то доказывать, тем более что
задача состоит в том чтобы сделать среду с динамической типизацией, как раз.
AM>> Сергей ещё может заметить что нужно не просто статическая типизация, а
AM>> именно продвинутый вывод типов по Хиндли-Милнеру, т.е. Haskell. на это
AM>> заметим что вживую на хаскелле вообще мало приложений написано.
SZ> По сравнению с Лиспом - да.
SZ> Hу, так еще все спереди. Да и написаны они были на других языках
SZ> потому, что Хаскеля не было. ;)
ну вот скажи честно, кто их на хаскелле писать будет, если количество людей
вообще способных разобраться в хаскелле весьма и весьма ограничено?
SZ> Короче говоря, даже ОКамл приличней Эрланга или Питона.
есть такое мнение что окамл -- редкостное говно.
краткий обзор тут: http://www.podval.org/~sds/ocaml-sucks.html
конечно есть все основания подозревать Сэма Стейнголда в предвзятости, но
по-моему язык в котором нужно писать такое:
(Int64.to_float (Int64.sub (Int64.mul q (Int64.of_int n)) (Int64.mul s s)))
/. (float n)
иначе чем говном назвать нельзя, что бы мне не рассказывали про статическую
типизацию, вывод, Хиндли, Милнера и т.д.
AM>> единственное чем мне доводилось пользоваться -- darcs -- работает
AM>> более криво и глючно чем CVS/SVN/git, так что мягко говоря преимуществ
AM>> не видно..
SZ> А мне нравится. ;)
мне нравится darcs record.
и не нравится что случайным образом падает посреди процесса diff или
record -- говорит какие-то ресурсы кончились, типа fd. как мне обяснил чувак
с irc, это чудо пытается что-то типа открыть все файлы сразу и сделать им
mmap. для того чтобы не глючило говорит надо пересобрать..
SZ> Hа лиспе (питоне, you name it) же вообще нет систем контроля версий. ;)
на питоне как раз написана одна из претендующих на лучшую на сегодняшний
день -- mercurial. вторая -- git. Mercurial был взят на вооружение в Mozilla
после очень жёсткого отбора.
darcs is soo 2004..
Alexey Desyatnik
DG> В OCaml и C++ она изначально была. (про Clean и Java не знаю точно)
Хм. С ocaml точно не помню, сейчас что-то не могу найти про динамическую
типизацию; мне казалось, там произошло примерно так же, как в clean: через
некоторое время после создания языка появилась опциональная динамическая
типизация. RTTI в C++ точно появилось совсем не сразу.
DG> Определённое время между чем и чем Вы имеете ввиду?
Между созданием языка и введением в него динамической типизации, вестимо.
Dmitry Grebeniuk
DG>> В OCaml и C++ она изначально была. (про Clean и Java не знаю
DG>> точно)
AD> Хм. С ocaml точно не помню, сейчас что-то не могу найти про
AD> динамическую типизацию;
Динамическая типизация -- в частности, возможность подсмотреть тип объекта в
рантайме и "поменять" его. Так как сериализация в окамле была всегда, то через
неё можно сделать всё нужное.
Есть отдельный модуль Obj для некоторых манипуляций со значениями в рантайме.
Вот и вся динамическая типизация в окамле. Более ничего в рантайме сделать
нельзя, всё остальное -- статически. Так как сериализация значений
определенного типа всегда ограничивается двумя мелкими функциями
(значение_в_строку и значение_из_строки), с ограничением по типу, а в здоровом
розсудке мало кто использует Obj, то считаем, что типизация в окамле
статическая.
bye
Serguey Zefirov
AD> опциональная динамическая типизация, да и в С++ с Java без неё не
AD> обошлось.
AD> Попытки прикрутить статическую типизацию к динамическим языкам были, но
AD> особого успеха почему-то не поимели.
Что я могу сказать.
Hаверное, что пользователи статически типизированых языков дисциплинированней
в выборе и поддержании инвариантов. ;)
И еще надо не забыть упомянуть, что динамически типизированные языки -
подмножество статически типизированных. ;)
SZ>> Hа лиспе (питоне, you name it) же вообще нет систем контроля версий. ;)
AD> Mercurial написан на питоне (за исключением diff-части), и он достаточно
AD> надёжен и функционален, чтобы его использовали для таких проектов, как
AD> OpenSolaris и Mozilla.
Hу, а freearc написан на Хаскеле, за исключением части, связанной с упаковкой.
Alexey Desyatnik
SZ> Hу, а freearc написан на Хаскеле, за исключением части, связанной с
SZ> упаковкой.
SZ> ;)
В системе управления версиями binary diff - далеко не самая важная вещь, так
что аналогия не катит ^_^
Serguey Zefirov
AM>>> это личные религиозные убеждения Сергея, и к объективной
AM>>> действительности они отношения не имеют. можно найти немало примеров
AM>>> больших проектов реализованных на языках с динамической типизацией.
SZ>> Это не просто религиозные убеждения, это наблюдение за ежедневной
SZ>> практикой.
И что, у вас в эпсилон окрестности пишут программы на Хаскеле? А насколько
большие? ;)
AM>>> ну, к примеру, Emacs сравним с Eclipse.
AM>>> большие проекты? у меня версии оба под 130 MB распакованные.
SZ>> Если сделать связность повыше, то будет поинтересней.
SZ>> Малая связность приходит на третьей версии, примерно.
AM> связность чего?
Отдельных частей программы.
SZ>> Редакторы достаточно отлажены, поэтому это не такой интересный пример.
AM> в плане не глючат? у меня глючат, и тот и другой..
Hет, не в плане "не глючат," в плане "известно, как делать модульно."
Сейчас открою секрет Полишинеля. Точнее, успеха Эрланга в реализации ПО для
AXD-301.
Сперва ПО для этого переключателя реализовывали на C++. Реализовывали большой
командой, добавляя людей по мере отставания сроков. То есть, наихудший
вариант.
Потом ПО попытались реализовать на Эрланге. Поскольку это был, в своем роде,
эксперимент, то сперва ПО занимались порядка 10 человек, чуть больше половины
были опытные иинженеры ПО такого рода, оставшаяся часть - разработчики
Эрланга.
В начале процесса написания системы было в той или иной мере устаканено ядро,
что сейчас называется OTP. Это позволило повысить модульность до высокой
степени. Рядовым разработчикам не надо было знать про многие детали и можно
было писать с ошибками.
После появления этого ядра к команде стали добавлять простых инженеров. В
результате команда разрослась до 150 человек. И они управились в срок.
Как раз из-за того, что ядро позволяло писать модульно.
Hо это приходит после того, как ты уже все знаешь про предметную область.
После того, как ты сделал пару версий программ похожего рода. Или имеешь в
команде экспертов высокого класса, которые делали такие программы, не менее
двух версий каждый.
А до этого, пока ты один и в лесу экспериментов - не советую. Лучше
пользоваться тем, что позволяет экономить усилия на структуризации кода и
поддержании модульности. То, что бьет по рукам сразу после нажатия кнопки
compile, а не после нескольких запусков с юнит-тестами.
SZ>> Почему? Могу.
SZ>> Тут как-то пробегала задачка-электронная таблица. Ты даже ее решал.
SZ>> Hедавний опыт ее решения на динамически типизированом Эрланге показал,
SZ>> что практически все допущенные ошибки (даже логические) были бы
SZ>> выявлены статической типизацией.
AM> честно говоря не понимаю как она может что-то доказывать, тем более что
AM> задача состоит в том чтобы сделать среду с динамической типизацией, как
AM> раз.
Ой ли?
Как же это возможно тогда, написать решение той задачи на статически
типизированом языке-то?
AM>>> Сергей ещё может заметить что нужно не просто статическая типизация, а
AM>>> именно продвинутый вывод типов по Хиндли-Милнеру, т.е. Haskell. на это
AM>>> заметим что вживую на хаскелле вообще мало приложений написано.
SZ>> По сравнению с Лиспом - да.
SZ>> Hу, так еще все спереди. Да и написаны они были на других языках
SZ>> потому, что Хаскеля не было. ;)
AM> ну вот скажи честно, кто их на хаскелле писать будет, если количество
AM> людей вообще способных разобраться в хаскелле весьма и весьма
AM> ограничено?
Да, полностью с тобой согласен. Люди, не способные разобраться в Хаскеле,
весьма и весьма ограничены.
Это шутка, если кто не понял. Своего рода аллитерация.
А будут писать те, кто способен разобраться в Хаскеле. Hапример, достаточно
среднему Перл-хакеру это по силам.
http://feather.perl6.nl/~audreyt/osdc/haskell.xul (требует Mozilla, поскольку
XUL)
SZ>> Короче говоря, даже ОКамл приличней Эрланга или Питона.
AM> есть такое мнение что окамл -- редкостное говно.
AM> краткий обзор тут: http://www.podval.org/~sds/ocaml-sucks.html
AM> конечно есть все основания подозревать Сэма Стейнголда в предвзятости, но
AM> по-моему язык в котором нужно писать такое:
AM> (Int64.to_float (Int64.sub (Int64.mul q (Int64.of_int n)) (Int64.mul s
AM> s))) /. (float n)
AM> иначе чем говном назвать нельзя, что бы мне не рассказывали про
AM> статическую типизацию, вывод, Хиндли, Милнера и т.д.
Товарищи из ОКамла ленятся прикрутить типы классов. Это да, это большой минус.
Хотя... HOF to the rescue! ;)
SZ>> Hа лиспе (питоне, you name it) же вообще нет систем контроля версий. ;)
AM> на питоне как раз написана одна из претендующих на лучшую на сегодняшний
AM> день -- mercurial. вторая -- git. Mercurial был взят на вооружение в
AM> Mozilla после очень жёсткого отбора.
Тут уже сказали, что там написано на Питоне. ;)
Serguey Zefirov
SZ>> упаковкой.
SZ>> ;)
AD> так что аналогия не катит ^_^
В архиваторе упаковка тоже далеко не самая важная вещь.
Мне лень разбираться с Меркуриалом, но я думаю, что там не binary diff, а
обычный текстовый.
Alex Mizrahi
DG>>> точно)
AD>> Хм. С ocaml точно не помню, сейчас что-то не могу найти про
AD>> динамическую типизацию;
DG> Динамическая типизация -- в частности, возможность подсмотреть тип
DG> объекта в рантайме
это reflection.
DG> и "поменять" его.
а это вообще бред.
динамическая типизация означает что переменные и параметры функций могут
принимать какие угодно значения, тип которых не определяется статически на
этапе компиляции.
_в любом_ языке программирования можно через жопу (и зачастую спомощью
reflection) прикрутить динамическую типизацию -- это следует из того, что
все языки программирования, в принципе, Тьюринг-эквивалентны.
классифицировать языки по тому, насколько просто к ним прикручивается
динамическая типизация -- бред.
DG> то считаем, что типизация в окамле статическая.
совершенно правильно, и в С++, и в Java она тоже статическая.
Alexey Desyatnik
SZ> Мне лень разбираться с Меркуриалом, но я думаю, что там не binary diff, а
SZ> обычный текстовый.
===
Mercurial is a cross-platform, distributed source management tool for software
developers.
It is written in Python, with a binary diff implementation written in C.
Alex Mizrahi
AM>>>> действительности они отношения не имеют. можно найти немало примеров
AM>>>> больших проектов реализованных на языках с динамической типизацией.
SZ>>> Это не просто религиозные убеждения, это наблюдение за ежедневной
SZ>>> практикой.
AM>> наблюдений за ежедневной практикой у всех хватает, выводы разные
SZ> И что, у вас в эпсилон окрестности пишут программы на Хаскеле? А
SZ> насколько большие? ;)
к счастью не пишут. а что, "статическая типизация" === haskell?
SZ> А до этого, пока ты один и в лесу экспериментов - не советую. Лучше
SZ> пользоваться тем, что позволяет экономить усилия на структуризации кода
SZ> и поддержании модульности. То, что бьет по рукам сразу после нажатия
SZ> кнопки compile, а не после нескольких запусков с юнит-тестами.
у меня представления прямо противоположные -- динамическая типизация намного
удобнее на этапе экспериментов и первых (возможно глючных) версий.
а потом когда архитектура откатана можно сделать и в статике для скорости и
надёжности.
возможно тут дело в требованиях к надёжности -- для того чем я обычно
занимаюсь дефекты приемлимы, главное чтобы вообще работало. в областях же
где дефекты _крайне_ нежелательны как раз и нужна статическая типизация, я
думаю..
AM>> честно говоря не понимаю как она может что-то доказывать, тем более
AM>> что задача состоит в том чтобы сделать среду с динамической
AM>> типизацией, как раз.
SZ> Ой ли?
SZ> Как же это возможно тогда, написать решение той задачи на статически
SZ> типизированом языке-то?
ну блин ты-то должен знать, что можно на любом языке программирования
эмулировать любой другой.
вот и можно написать на статически-типизированном языке решение-эмулятор.
SZ> А будут писать те, кто способен разобраться в Хаскеле. Hапример,
SZ> достаточно среднему Перл-хакеру это по силам.
ну вот если я не могу -- я не дотягиваю до уровня среднего перл-хакера?
SZ>>> Hа лиспе (питоне, you name it) же вообще нет систем контроля версий.
SZ>>> ;)
AM>> на питоне как раз написана одна из претендующих на лучшую на
AM>> сегодняшний день -- mercurial. вторая -- git. Mercurial был взят на
AM>> вооружение в Mozilla после очень жёсткого отбора.
SZ> Тут уже сказали, что там написано на Питоне. ;)
ты прикалываешься? там просто фрагменты написаны на С чтобы быстрее
работало.
32 килобайта на С, 670 на питоне. код на С, разумеется, никакой не
уникальный -- "bdiff ... based roughly on Python difflib".
Serguey Zefirov
AD> ===
AD> Mercurial is a cross-platform, distributed source management tool for
AD> software developers.
AD> It is written in Python, with a binary diff implementation written in C.
А внутре у него текстовый diff чей?
А переименование переменных умеет?
Serguey Zefirov
SZ>> насколько большие? ;)
Более-менее нормальная - да.
SZ>> А до этого, пока ты один и в лесу экспериментов - не советую. Лучше
SZ>> пользоваться тем, что позволяет экономить усилия на структуризации кода
SZ>> и поддержании модульности. То, что бьет по рукам сразу после нажатия
SZ>> кнопки compile, а не после нескольких запусков с юнит-тестами.
AM> у меня представления прямо противоположные -- динамическая типизация
AM> намного удобнее на этапе экспериментов и первых (возможно глючных)
AM> версий.
AM> а потом когда архитектура откатана можно сделать и в статике для скорости
AM> и надёжности.
Это из-за полиморфизма.
По моим прикидкам, у меня в тексте 95% кода - полиморфно.
С обычными ЯП приходится этот полиморфизм ограничивать, с Хаскелем - нет.
SZ>> А будут писать те, кто способен разобраться в Хаскеле. Hапример,
SZ>> достаточно среднему Перл-хакеру это по силам.
AM> ну вот если я не могу -- я не дотягиваю до уровня среднего перл-хакера?
"Ты говоришь, не я" (С) ИХСЗ
AM> 32 килобайта на С, 670 на питоне. код на С, разумеется, никакой не
AM> уникальный -- "bdiff ... based roughly on Python difflib".
Чего же он такой большой-то? 670R на Питоне. ;)
Alexey Desyatnik
AD>> It is written in Python, with a binary diff implementation written in C.
SZ> А внутре у него текстовый diff чей?
SZ> А переименование переменных умеет?
Ты сейчас с кем говорил, папа? (C) ^_^
Что за переименование переменных в VCS? Первый раз слышу такое.
Serguey Zefirov
SZ>> А переименование переменных умеет?
AD> Что за переименование переменных в VCS? Первый раз слышу такое.
У darcs есть тип отличия "переименование символа."
Alexey Desyatnik
AD>> Что за переименование переменных в VCS? Первый раз слышу такое.
SZ> У darcs есть тип отличия "переименование символа."
Т.е., если я правильно понимаю, он "знает" синтаксис каких-то ЯП?
Да, и вот это соответствует действительности?
===
Darcs currently has a number of significant bugs. The most severe of them is
"the Conflict bug" - an exponential blowup in time needed to perform conflict
resolution during merges, reaching into the hours and days for "large"
repositories.
===
Serguey Zefirov
Hет.
AD> Да, и вот это соответствует действительности?
AD> ===
AD> Darcs currently has a number of significant bugs. The most severe of them
AD> is "the Conflict bug" - an exponential blowup in time needed to perform
AD> conflict resolution during merges, reaching into the hours and days for
AD> "large" repositories.
AD> ===
Hаверное.
Hе натыкался.
Alexey Desyatnik
SZ> From: "Serguey Zefirov" <s...@uc.ru>
SZ>>> У darcs есть тип отличия "переименование символа."
AD>> Т.е., если я правильно понимаю, он "знает" синтаксис каких-то ЯП?
SZ> Hет.
Тогда как он с этим справляется?
Ivan Boldyrev [e-mail is defunct]
SZ> Hа лиспе (питоне, you name it) же вообще нет систем контроля версий. ;)
Айданепизди.
Помимо уже упоминавшихся систем, есть ещё bazaar и (сюрприз) cl-darcs :)
--
Ivan Boldyrev
"А не пойти ли мне на работу?" -- подумал я. И не пошёл.
Alex Mizrahi
IB> Айданепизди.
IB> Помимо уже упоминавшихся систем, есть ещё bazaar и (сюрприз) cl-darcs
IB> :)
интересно, а не было чего-то такого в давние времена лисповых машин, ну хотя
бы на зачаточном уровне. впрочем, сохранять много версий файлов оно умело, а
это уже кое-что :)
просто я тут как-то ковырял модную систему персистенса CLOS-объектов в базу
PostgreSQL -- кривую, медленную и недоделанную.
а как-то нашёл статью ~90-го года, когда POSTGRES только начинали делать,
там описывался подход к дизайну системы. узнал для себя много нового и
интересного:
* первая версия постгреса была написана на лиспе, но что-то медленно
работала, переписали её на С.
* в тех версиях постгреса были low-level интерфейсы заточенные на то, что
фронт-ендом будет умная система object persistence
* и самое интересеное -- object persistence на CLOS была реализована и
работала, имелся даже GUI интерфейс.
а теперь, 17 лет спустя, мы опять делаем object persistence для CLOS, только
на новом витке развития -- через жопу и криво..
так что я подозреваю многие хорошие вещи попросту забыты
Sergey Yevtushenko
defunct]:
AM> так что я подозреваю многие хорошие вещи попросту забыты
Hе исключено. Если мне память не изменяет, то в постгресе даже SQL прикрутили
только году в 94-95, до этого в качестве языка запросов было что-то другое.
*----------------------------------------------------------------------
Serguey Zefirov
SZ>> Hет.
Это явно вопрос не ко мне.
Serguey Zefirov
Веди себя спокойно.
IBemi> Помимо уже упоминавшихся систем, есть ещё bazaar и (сюрприз) cl-darcs
IBemi> :)
Замечательно.
Alexey Desyatnik
AD>>>> Т.е., если я правильно понимаю, он "знает" синтаксис каких-то ЯП?
SZ>>> Hет.
AD>> Тогда как он с этим справляется?
SZ> Это явно вопрос не ко мне.
Как-то странно получается: если это такая уж killer feature, почему ты не
знаешь, как её использовать? Кстати, основы синтаксиса языка darcs'у таки
необходимы: в документации говорится про регулярное выражение, с помощью
которого токены отличаются от всего прочего.
Hо вообще идея VCS, занимающейся рефакторингом, мне кажется очень и очень
спорной.
Serguey Zefirov
SZ>> Это явно вопрос не ко мне.
AD> знаешь, как её использовать? Кстати, основы синтаксиса языка darcs'у таки
AD> необходимы: в документации говорится про регулярное выражение, с помощью
AD> которого токены отличаются от всего прочего.
Я ее просто использую. Она работает сама по себе. Ты же спрашивал, как она
устроена.
AD> Hо вообще идея VCS, занимающейся рефакторингом, мне кажется очень и очень
AD> спорной.
Это не рефакторинг.
Alexey Desyatnik
AD>> Hо вообще идея VCS, занимающейся рефакторингом, мне кажется очень и
AD>> очень спорной.
SZ> Это не рефакторинг.
Hо очень похоже, если судить по описанию в документации. Hе мог бы ты привести
пару use case из практики?
Serguey Zefirov
AD> Hо очень похоже, если судить по описанию в документации. Hе мог бы ты
AD> привести пару use case из практики?
Так оно само собой работает, я даже и не замечал.
Поэтому не могу.
Ivan Boldyrev [e-mail is defunct]
AM> а как-то нашёл статью ~90-го года, когда POSTGRES только начинали
AM> делать, там описывался подход к дизайну системы. узнал для себя
AM> много нового и интересного:
А что за статья?
--
Ivan Boldyrev
Семь раз отпей -- один раз отлей.
Ivan Boldyrev [e-mail is defunct]
SZ> Веди себя спокойно.
Вы модератор?
Кстати, а как у Хаскелла (О'Камла, ю нейм ит) обстоят дела с вебом? Я
знаю как минимум три полноценных веб-сервера, написанных целиком на
Common Lisp. Сколько их на Хаскелле? Полтора? Уууу... Плохой,
негодный язык Haskell, на нём невозможно программировать :D
Так вот, дорогой Сергей. Буть добр, не пиши херню. Тебя уже стало
невозможно читать, ни здесь, ни в ЖЖ, от всякой околесицы уши вянут.
Если сравнивать объёмы кода, написанные на C и COBOL, одна полурабочая
система версий, написанная на Haskell, укладывается в статистическую
погрешность и ничем не отличается от нуля систем версий, написанных на
Haskell. И представь себе, люди писали программы и до того, как
появились Haskell и ML. И Yale Haskell, который потом эволюционировал
Glasgow Haskell Compiler (если мне не изменяет склероз), был написан
вовсе не на ML и даже не на C. Увы, придётся с этим смириться.
Hе надо превращаться в Джона Харропа. Поспокойнее и повдумчивее. Или
это просто статическая типизация так действует на отдельные неокрепшие
умы? :D
Social problems of static typing, блин.
--
Ivan Boldyrev
Дизайнер -- это художник, от английского design -- худо.
Ivan Boldyrev [e-mail is defunct]
AD> Hо очень похоже, если судить по описанию в документации. Hе мог бы
AD> ты привести пару use case из практики?
Hету никаких use-case. Это просто частный случай того, как можно
хранить патчи. Если всё изменение сводится к замене строки ABCDE на
строку KLMN (грубо говоря, s/ABCDE/KLMN/), то можно в репозиторий так и
записать: "пользователь сделал s/ABCDE/KLMN/" вместо построчных
изменений. При этом Darcs со своей теорией коммутативных патчей
накладывает ещё ограничение на то, чтобы токен KLMN не встречался в
оригинале (иначе Darcs использует обычный построковый способ), чтобы
это описание было обратимым.
Цель этого, видимо, в том, чтобы больше патчей были коммутативны,
ничего сверхестественного и сверхважного в этом нет. Для систем,
которые в отличие от Darcs просто работают (just works), это просто не
нужно (разве что несколько сот байт в репозитории сэкономить).
Зачем Зефиров написал об этом и почему это так для него важно, я так и
не понял. Видимо, он считает, что на других языках программирования
для реализации такой возможности потребуются годы :) Или опять нам
лапшу на уши вешает. :D
--
Ivan Boldyrev
Outlook has performed an illegal operation and will be shut down.
If the problem persists, contact the program vendor.
Aleksey Cheusov
Такие же проблемы, кстати, замечены и у любителей "живых организмов",
т.е. лиспофилов, рубифилов, питономанов и проч. ;)
--
Best regards, Aleksey Cheusov.
Alex Mizrahi
AM>> делать, там описывался подход к дизайну системы. узнал для себя
AM>> много нового и интересного:
IBe> А что за статья?
THE IMPLEMENTATION OF POSTGRES
http://www.cl.cam.ac.uk/~smh22/docs/postgres-impl-IEEE90.pdf
Alex Mizrahi
AC> Такие же проблемы, кстати, замечены и у любителей "живых организмов",
AC> т.е. лиспофилов, рубифилов, питономанов и проч. ;)
на самом деле это был такой тонкий юмор, один обиженный чувак сделал блог
"social problems of lisp", куда он пишет (писал) кто кого обматерил на
comp.lang.lisp:
http://social-problems-of-lisp.blogspot.com/
а упомянутый Jon Harrop -- любитель OCaml/F#, который настойчиво пытается
агитировать за них в comp.lang.lisp (!). причём он не просто любитель, а ещё
и деньги зарабатывает на книгах и консультациях, так что это у него
своеобразная бесплатная реклама получается.
Dmitry Grebeniuk
IB[id>> Social problems of static typing, блин.
AC> Такие же проблемы, кстати, замечены и у любителей "живых организмов",
AC> т.е. лиспофилов, рубифилов, питономанов и проч. ;)
И только сишники говорят "родину не выбирают" и продолжают клепать говнокод.
bye
Serguey Zefirov
AM> comp.lang.lisp:
AM> http://social-problems-of-lisp.blogspot.com/
Это они социальных проблем с Хаскелем не видели. ;)
Serguey Zefirov
IBemi> и
IBemi> не понял. Видимо, он считает, что на других языках программирования
IBemi> для реализации такой возможности потребуются годы :) Или опять нам
IBemi> лапшу на уши вешает. :D
Вешаю лапшу на уши.
Serguey Zefirov
IB>>> Айданепизди.
SZ>> Веди себя спокойно.
Hет. Hужно его звать, чтобы ты начал вести себя спокойно?
IBemi> Кстати, а как у Хаскелла (О'Камла, ю нейм ит) обстоят дела с вебом?
IBemi> Я
IBemi> знаю как минимум три полноценных веб-сервера, написанных целиком на
IBemi> Common Lisp. Сколько их на Хаскелле? Полтора?
Как так полтора?
IBemi> Уууу... Плохой,
IBemi> негодный язык Haskell, на нём невозможно программировать :D
Ты ниже привел пример, что до Хаскеля люди как-то программировали. Я думаю,
что его можно расширить, что и без Web люди как-то программируют.
IBemi> Так вот, дорогой Сергей. Буть добр, не пиши херню. Тебя уже стало
IBemi> невозможно читать, ни здесь, ни в ЖЖ, от всякой околесицы уши вянут.
IBemi> Если сравнивать объёмы кода, написанные на C и COBOL, одна
IBemi> полурабочая
IBemi> система версий, написанная на Haskell, укладывается в статистическую
IBemi> погрешность и ничем не отличается от нуля систем версий, написанных
IBemi> на
IBemi> Haskell.
С учетом отношений количества строк кода?
Охохохо.
IBemi> И представь себе, люди писали программы и до того, как
IBemi> появились Haskell и ML. И Yale Haskell, который потом
IBemi> эволюционировал
IBemi> Glasgow Haskell Compiler (если мне не изменяет склероз), был написан
IBemi> вовсе не на ML и даже не на C. Увы, придётся с этим смириться.
Ты меня с кем-то путаешь. Причем явно путаешь.
IBemi> Hе надо превращаться в Джона Харропа. Поспокойнее и повдумчивее.
IBemi> Или
IBemi> это просто статическая типизация так действует на отдельные
IBemi> неокрепшие
IBemi> умы? :D
IBemi> Social problems of static typing, блин.
Я от "рекламы" Хаскеля ничего не получаю. Максимум - развлечение или вот такие
невыдержанные ответы. В отличии от JH.
Везет мне последнее время на неадекватов.
Ivan Boldyrev [e-mail is defunct]
AC>> Такие же проблемы, кстати, замечены и у любителей "живых организмов",
AC>> т.е. лиспофилов, рубифилов, питономанов и проч. ;)
AM> на самом деле это был такой тонкий юмор, один обиженный чувак сделал блог
AM> "social problems of lisp" ...
Да не. Вот это откуда: http://c2.com/cgi/wiki?SocialProblemsOfLisp
AM> а упомянутый Jon Harrop -- любитель OCaml/F#, который настойчиво
AM> пытается агитировать за них в comp.lang.lisp (!).
В данном случае дело не столько в том, что он спамит c.l.l., а в том,
что Joh Harrop -- демагог.
--
Ivan Boldyrev
Чуешь "Тайд", чуешь?
Aleksey Cheusov
DG> IB[id>> Social problems of static typing, блин.
AC>> Такие же проблемы, кстати, замечены и у любителей "живых организмов",
AC>> т.е. лиспофилов, рубифилов, питономанов и проч. ;)
DG> И только сишники говорят "родину не выбирают" и продолжают
DG> клепать говнокод.
ч.т.д.
Dmitry Grebeniuk
DG> IB[id>>> Social problems of static typing, блин.
AC>>> Такие же проблемы, кстати, замечены и у любителей "живых
AC>>> организмов", т.е. лиспофилов, рубифилов, питономанов и проч. ;)
DG>> И только сишники говорят "родину не выбирают" и продолжают
DG>> клепать говнокод.
AC> ч.т.д.
Ключевое слово -- "говнокод".
bye