-
Balancer: Все сообщения за 3 Декабря 2002 года
| Пн | Вт | Ср | Чт | Пт | Сб | Вс |
|---|---|---|---|---|---|---|
| 1 | ||||||
| 2 | 3 | 4 | 5 | 6 | 7 | 8 |
| 9 | 10 | 11 | 12 | 13 | 14 | 15 |
| 16 | 17 | 18 | 19 | 20 | 21 | 22 |
| 23 | 24 | 25 | 26 | 27 | 28 | 29 |
| 30 | 31 |
Прочёл "Выбраковку". Понравилось. С первых страниц внутренне матерился, ожидая какой-то НКВД-восхваляющей мути, но потом отношение к книге сильно переменилось. Не шедевр, но книга отличная. Хотя и настоящую историю "птички" раскусил сразу после рассказа Пэ от Птицыне...
В общем, очень понравилось, но боюсь, книга на один раз. Перечитывать пока желания нет. Но есть желание читать другие вещи автора
В общем, очень понравилось, но боюсь, книга на один раз. Перечитывать пока желания нет. Но есть желание читать другие вещи автора
… чтобы понять рекурсию, нужно сперва понять рекурсию …
инфо
инструменты
TEvg>Гораздо лучшим вариантом я считаю создание одинакового компилера под все платформы
C++/POSIX. На соответствующих платформах прекрасно переносится.
Если нужна графика - то тоже давно всякие Tcl есть.
TEvg>(Free Pascal ets) и разработку сразу предусматривающую несколько платформ. Если грамотно написать прогу на Pascal или C понадобится лишь чуток ее адаптировать на другую платформу. И получится полноценное приложение, а не ублюдочное.
Если система разработки по-настоящему грамотная, то адаптировать не понадобится, только перекомпилировать. Но на самом деле проблема ещё и в другом. Мало кто добровольно расстанется с исходным кодом. Поэтому компиляция из исходников для коммерческих продуктов неприменима. А вот Java или C# будут выполняться из бинарника на любой системе, имеющей соответствующую виртуальную машину.
TEvg>Что касаеся веба - тут рулит PHP.
Ну, как я уже сказал, для быстрого написания интерфейсных страниц Для всего более-менее серьёзного Perl выглядит предпочтительнее. Умеет всё, что и PHP и сверх того гораздо больше
TEvg>А на хрена MG жаба? Они что Ил-2 собрались под BeOS и Irix портировать?
Нет, на Java писать без ошибок, они говорят, проще
C++/POSIX. На соответствующих платформах прекрасно переносится.
Если нужна графика - то тоже давно всякие Tcl есть.
TEvg>(Free Pascal ets) и разработку сразу предусматривающую несколько платформ. Если грамотно написать прогу на Pascal или C понадобится лишь чуток ее адаптировать на другую платформу. И получится полноценное приложение, а не ублюдочное.
Если система разработки по-настоящему грамотная, то адаптировать не понадобится, только перекомпилировать. Но на самом деле проблема ещё и в другом. Мало кто добровольно расстанется с исходным кодом. Поэтому компиляция из исходников для коммерческих продуктов неприменима. А вот Java или C# будут выполняться из бинарника на любой системе, имеющей соответствующую виртуальную машину.
TEvg>Что касаеся веба - тут рулит PHP.
Ну, как я уже сказал, для быстрого написания интерфейсных страниц
Для всего более-менее серьёзного Perl выглядит предпочтительнее. Умеет всё, что и PHP и сверх того гораздо больше TEvg>А на хрена MG жаба? Они что Ил-2 собрались под BeOS и Irix портировать?
Нет, на Java писать без ошибок, они говорят, проще
… чтобы понять рекурсию, нужно сперва понять рекурсию …
avmich>Крон, Перл же тоже можно в компилированном виде держать - а модули Апача ещё и предзагруженным его делают, так что со скоростью тоже не всё плохо?
Всё равно более чем на порядок (но менее, чем на два) медленнее, чем у "классических" компиляторов. В 90% случаев этого достаточно, но часто - бывает мало
avmich>Что касается избыточной информации - это уже ближе у идеям, скажем, XML
XML - это хороший переносимый контейнер. Но работать с ним вручную, в текстовом редакторе - увольте!
У языков програмирования в первую же очередь должно стоять именно удобство ручной работы с исходным текстом. Даже на всяких Visual Basic и Delphi
avmich>Дальше, под Яву библиотек - сомневаюсь, что меньше, чем для Перла
Речь я веду в первую очередь о том, что в стандартную поставку включено Впрочем, я не слышал и о наличии репозиториев, подобных CPAN, для Java
avmich>Тут, уж пожалуйста, не недооцените самый, по некоторым оценкам, распространённый язык программирования. Есть они у него...
До недавнего времени самым распространённым был Visual Basic. Однако библиотек под него - крайне мало. Даже с учётом OCX-компонентов и т.п., хотя это и не совсем то. Так что распространённость языка ничего не говорит о наличии под него библиотек
avmich>Насыщенный синтаксис - думаю, даже после того, как изучишь Перл... По крайней мере, видел программы на C с пятью плюсами подрядд и всё такое - ну не хочется их читать. Проще надо писать .
А Perl в плане неоднозначностей более жесток, чем Си В смысле - неоднозначностей компилятором допускается меньше. плотный синтаксис и неоднозначность прямо не связаны.
avmich>Теперь насчёт ООП. А как же тезис о "разделении и властвовании" как методе борьбы с программовской сложностью? Тут, по-моему, пока концепцию лучше ООП не изобретут, рывка не будет.
Ну, на новый уровень выходит, например, функциональное программирование. Кажется, оно очень сблизилось с агентным программированием. Впрочем, то же ООП приходит к агентам.
avmich>Напоминаю, языки программирования пишутся под, и исходя из, людей, а вовсе не компьютеров. Поэтому и не пишут все на ассемблере.
Именно!
avmich>А утечку памяти, конечно, можно организовать... классический пример -
avmich>здесь, пока вечный цикл выполняется, память, занятая массивом, не освобождается. Вот и утечка.
Кстати, я так и не разобрался, почему нет ни одной жалобы на утечки памяти в Perl Ну не верю я, что там так всё хорошо
Всё равно более чем на порядок (но менее, чем на два) медленнее, чем у "классических" компиляторов. В 90% случаев этого достаточно, но часто - бывает мало
avmich>Что касается избыточной информации - это уже ближе у идеям, скажем, XML
XML - это хороший переносимый контейнер. Но работать с ним вручную, в текстовом редакторе - увольте!
У языков програмирования в первую же очередь должно стоять именно удобство ручной работы с исходным текстом. Даже на всяких Visual Basic и Delphi
avmich>Дальше, под Яву библиотек - сомневаюсь, что меньше, чем для Перла
Речь я веду в первую очередь о том, что в стандартную поставку включено
Впрочем, я не слышал и о наличии репозиториев, подобных CPAN, для Java avmich>Тут, уж пожалуйста, не недооцените самый, по некоторым оценкам, распространённый язык программирования. Есть они у него...
До недавнего времени самым распространённым был Visual Basic. Однако библиотек под него - крайне мало. Даже с учётом OCX-компонентов и т.п., хотя это и не совсем то. Так что распространённость языка ничего не говорит о наличии под него библиотек
avmich>Насыщенный синтаксис - думаю, даже после того, как изучишь Перл... По крайней мере, видел программы на C с пятью плюсами подрядд и всё такое - ну не хочется их читать. Проще надо писать
.А Perl в плане неоднозначностей более жесток, чем Си
В смысле - неоднозначностей компилятором допускается меньше. плотный синтаксис и неоднозначность прямо не связаны.avmich>Теперь насчёт ООП. А как же тезис о "разделении и властвовании" как методе борьбы с программовской сложностью? Тут, по-моему, пока концепцию лучше ООП не изобретут, рывка не будет.
Ну, на новый уровень выходит, например, функциональное программирование. Кажется, оно очень сблизилось с агентным программированием. Впрочем, то же ООП приходит к агентам.
avmich>Напоминаю, языки программирования пишутся под, и исходя из, людей, а вовсе не компьютеров. Поэтому и не пишут все на ассемблере.
Именно!
avmich>А утечку памяти, конечно, можно организовать... классический пример -
avmich>здесь, пока вечный цикл выполняется, память, занятая массивом, не освобождается. Вот и утечка.
Кстати, я так и не разобрался, почему нет ни одной жалобы на утечки памяти в Perl
Ну не верю я, что там так всё хорошо
… чтобы понять рекурсию, нужно сперва понять рекурсию …
Пока по теме это хорошо укладывается в форум "Человек и общество". Вот когда там будет немерянный трафик - тогда можно и поделить будет
… чтобы понять рекурсию, нужно сперва понять рекурсию …
200 от 300 fps не отличишь, но вот 20 минут на обсчёт ролика или 30 минут - тут уже разница заметна.
… чтобы понять рекурсию, нужно сперва понять рекурсию …
TEvg>Что за намеки? 
Что значит всяких? Как можно басик рядом с Дельфией ставить?
И там и там сперва лепятся кнопочки, потом код для их связки. Поэтому я их и отделяю принципиально от других языков, где для разработки достаточно FAR+Colorer и консольный компилятор.
MS Visual C++ - позиционируется где-то посередине, но всё равно его удобнее использовать как классику, с консоли и Makefile
Что значит всяких? Как можно басик рядом с Дельфией ставить? И там и там сперва лепятся кнопочки, потом код для их связки. Поэтому я их и отделяю принципиально от других языков, где для разработки достаточно FAR+Colorer
и консольный компилятор.MS Visual C++ - позиционируется где-то посередине, но всё равно его удобнее использовать как классику, с консоли и Makefile
… чтобы понять рекурсию, нужно сперва понять рекурсию …
TEvg>Загонять простые переменные в объекты нет никакой надобности
Вот переменные как раз просто обязаны кому-то принадлежать. Поскольку абстрактные переменные - это чрезвычайно пакостная штука. Не стоит, конечно, опускаться до уровня функциональных языков, полностью их отменяя, но и от глобализации их надо отказываться. Переменные должны инкапсулироваться в объекты.
Хотя в случае с Java, думаю, вышел перебор
Вот переменные как раз просто обязаны кому-то принадлежать. Поскольку абстрактные переменные - это чрезвычайно пакостная штука. Не стоит, конечно, опускаться до уровня функциональных языков, полностью их отменяя, но и от глобализации их надо отказываться. Переменные должны инкапсулироваться в объекты.
Хотя в случае с Java, думаю, вышел перебор
… чтобы понять рекурсию, нужно сперва понять рекурсию …
Lerm>По-моему, недостатком также является отсутствие возможности перегружать операции...
Э, нет... Операторы однозначно должны быть перегружаемыми. Запись вида c3=add_complex(c1,c2) не улучшает воспринимаемости программ, а, значит, усложняет восприятие и увеличивает потенциально вероятность ошибки. Хотя тут тоже меру надо знать.
К слову, очень и очень академический Haskell имеет механизм перезагрузки операторов куда более продвинутый, чем в Си++, например.
Э, нет... Операторы однозначно должны быть перегружаемыми. Запись вида c3=add_complex(c1,c2) не улучшает воспринимаемости программ, а, значит, усложняет восприятие и увеличивает потенциально вероятность ошибки. Хотя тут тоже меру надо знать.
К слову, очень и очень академический Haskell имеет механизм перезагрузки операторов куда более продвинутый, чем в Си++, например.
… чтобы понять рекурсию, нужно сперва понять рекурсию …
Fakas>А вот из-за таких "связывателей кнопок" у народа неправильное представление о Дельфи.
Просто Дельфи создавался именно как связыватель кнопок. Что он со временем развивается - это ему в плюс. Но впечатление об этом - осталось
Никогда не забуду, как во времена Дельфи-1, ко мне пришёл товарищ и сказал - "я тут калькулятор на Дельфи написал, только он не работает. Не посмотришь, в чём дело?". Я пришёл и офигел. Он нарисовал красивейший инженерный калькулятор, с графическими цветными многофункциональными кнопками, имитацией ЖКИ-индикатора и т.д. и т.п. и... ни строчки кода Он думал - оно всё так заработает, само cобой
Кстати, не считайте, что я к лепительству кнопок негативно отношусь, бо сам делал это ещё в далёком 1995 на VB3 под Win3.11. Интерфейс - это нередко 90% времени проектирования прикладной программы.
Но стоит, всё же, ИМХО, разделять реализации языков, где во главу угла ставятся кнопочки от языков, где первым идёт Makefile
Просто Дельфи создавался именно как связыватель кнопок. Что он со временем развивается - это ему в плюс. Но впечатление об этом - осталось
Никогда не забуду, как во времена Дельфи-1, ко мне пришёл товарищ и сказал - "я тут калькулятор на Дельфи написал, только он не работает. Не посмотришь, в чём дело?". Я пришёл и офигел. Он нарисовал красивейший инженерный калькулятор, с графическими цветными многофункциональными кнопками, имитацией ЖКИ-индикатора и т.д. и т.п. и... ни строчки кода
Он думал - оно всё так заработает, само cобой Кстати, не считайте, что я к лепительству кнопок негативно отношусь, бо сам делал это ещё в далёком 1995 на VB3 под Win3.11. Интерфейс - это нередко 90% времени проектирования прикладной программы.
Но стоит, всё же, ИМХО, разделять реализации языков, где во главу угла ставятся кнопочки от языков, где первым идёт Makefile
… чтобы понять рекурсию, нужно сперва понять рекурсию …
Натка, не лезь, а то подерёмся
Что толку, что он был искренним? Бомж в метро тоже может быть искренним Ну не люблю я Гантенбайна. Мне органически противны его взгляды, его поведение, его игра. Точка. При чём того, когда я писал вышеприведённую страницу, я к Гантенбайну относился куда терпимее
Кстати, наверное я уже чего-то забыл, но какая, в баню, искренность у Гантенбайна??
Что толку, что он был искренним? Бомж в метро тоже может быть искренним
Ну не люблю я Гантенбайна. Мне органически противны его взгляды, его поведение, его игра. Точка. При чём того, когда я писал вышеприведённую страницу, я к Гантенбайну относился куда терпимее Кстати, наверное я уже чего-то забыл, но какая, в баню, искренность у Гантенбайна??
… чтобы понять рекурсию, нужно сперва понять рекурсию …
3D Max уже рендерит в кластере? Не знал А так - собрали просто дуалку на 2x P4-2.4ГГц.
А так - собрали просто дуалку на 2x P4-2.4ГГц.
… чтобы понять рекурсию, нужно сперва понять рекурсию …
Fakas>Рома, ну не может тул. основанный еще на досовском BP быть "связывателем кнопочек" . В отличие от VB Дельфя код держала и держит в тесктовых pas файлах.
Гы. Между прочим, VB тоже основан на досовском QB, и держит код в текстовых .bas файлах
Fakas>Никто тебе не запрещает вообще не использовать ни IDE, ни VCL — пиши себе с ноля аппликуху на чистом API и радуйся. И это было изначально так. И никак иначе.
Что удивительно, и на VB можно также
Fakas>И make есть, и компайлер текстовой строки есть и файлы описания форм в текстовом виде.
Но, ведь, не пользуются этим обычно?
Fakas>А все Филя Кан — VB killer, DB application development... Сказали бы сразу — MS killer
.
И каково соотношение программеров в мире между VB и Delphi? Конечно, дела у Борланда (вроде, он снова Борланд, а не Инпрайз, или меня глючит?) поправилсь, был на грани смерти, теперь просто держит нишу, но до прямой конкуренции с MS на базе средств разработки ему сейчас, ИМХО, далеко. Да, были золотые деньки, по сей день BC3.1 тепло вспоминаю, а многие к TP7 нежные чувтва питают, но как давно это было...
. В отличие от VB Дельфя код держала и держит в тесктовых pas файлах.Гы. Между прочим, VB тоже основан на досовском QB, и держит код в текстовых .bas файлах
Fakas>Никто тебе не запрещает вообще не использовать ни IDE, ни VCL — пиши себе с ноля аппликуху на чистом API и радуйся. И это было изначально так. И никак иначе.
Что удивительно, и на VB можно также
Fakas>И make есть, и компайлер текстовой строки есть и файлы описания форм в текстовом виде
.Но, ведь, не пользуются этим обычно?
Fakas>А все Филя Кан — VB killer, DB application development... Сказали бы сразу — MS killer
.И каково соотношение программеров в мире между VB и Delphi?
Конечно, дела у Борланда (вроде, он снова Борланд, а не Инпрайз, или меня глючит?) поправилсь, был на грани смерти, теперь просто держит нишу, но до прямой конкуренции с MS на базе средств разработки ему сейчас, ИМХО, далеко. Да, были золотые деньки, по сей день BC3.1 тепло вспоминаю, а многие к TP7 нежные чувтва питают, но как давно это было...
… чтобы понять рекурсию, нужно сперва понять рекурсию …
Nilli>Странное движение души! К брезгливости и ненависти, но не к терпимости и любви!
Я же не сказал, что у меня ко всем так К кому-то, наоборот, стал относиться с бОльшим понимаием, чем раньше. Скажем, так, среди литературных героев таких, как раз большинство
Nilli>Мы не можем судить наверняка, глядя издалека. Но вполне можно допустить, что в такой игре он или кто-то другой на его месте мог бы быть искренним.
Тут меня хоть режь, но для меня "искренняя игра" - это то же, что "горячий снег" или "ледянящий кипяток".
Я же не сказал, что у меня ко всем так
К кому-то, наоборот, стал относиться с бОльшим понимаием, чем раньше. Скажем, так, среди литературных героев таких, как раз большинство Nilli>Мы не можем судить наверняка, глядя издалека. Но вполне можно допустить, что в такой игре он или кто-то другой на его месте мог бы быть искренним.
Тут меня хоть режь, но для меня "искренняя игра" - это то же, что "горячий снег" или "ледянящий кипяток".
… чтобы понять рекурсию, нужно сперва понять рекурсию …
Когда однажды в совершенно вышеописанной обстановке мне за шиворот кинули снежок (кто, увы, неизвестно, т.к. кидали многие, а народ танцевал тесно), я просто снял рубкашку, вышел на балкон и лёг спиной в снег (благо, мороз был под -20° ). Больше мне снежков за шиворот не кидали
Т.е. что ж, это мне теперь, в случае чего, в жидкий азот нырять? Оно, конечно, понятно, я химик, должен снести, но, с другой стороны, практики давно не было
). Больше мне снежков за шиворот не кидали Т.е. что ж, это мне теперь, в случае чего, в жидкий азот нырять? Оно, конечно, понятно, я химик, должен снести, но, с другой стороны, практики давно не было
… чтобы понять рекурсию, нужно сперва понять рекурсию …
Но, бывает и так...
… чтобы понять рекурсию, нужно сперва понять рекурсию …
avmich>Крон, думаю, просто привык к Перлу.
Я привык (т.е. писать в любой обстановке, на любом системе и т.п.) к Perl, PHP, Forth, C/C++, разные асмы Доводилось писать (в смысле - вещи посложнее "Hello world") на Java, FORTRAN, Visual Basic, QBasic. Изучал концепции и писал всякие бенчмарки на Haskell, Ocaml, C#... Это только, скажем, за последний год. Сколько десятков языков прошло через меня за последние лет 10 - я просто не смогу всё вспомнить В общем, каша концепций и подходов изрядная, так что есть что с чем сравнивать. Надо отметить, что к Perl'у я привыкал долго и болезненно. Очень многое не нравилось, многое не умел. Да и сейчас я не гуру Perl'а
avmich>Писать программы "write only" на нём быстрее
Мне кажется, ты в этой роли его с PHP путаешь
avmich>только сложность таких программ более ограничена.
Проект в миллион строк - да, не напишешь. Но вот, например, Авиабаза сейчас имеет, как минимум, более 30 тыс. строк на Perl'е. И я не вижу никаких проблем к наращиванию их ещё на порядок, а то и на два - модульность последних моделей офигенная, у меня нередко какой-нибудь отдельный модуль, под целое направление, занят всего одной функцией, в расчёте на дальнейшее расширение. Кстати, написано всё очень и очень коряво, поскольку начиналось всё писаться когда я Perl едва знал, а полной "с нуля" переписи не было и не будет. Просто планомерная замена одних, корявых модулей, на новые и изящные
avmich>Моё мнение, что JSP как минимум понятнее Перла. Согласен, каждый язык понятен своему создателю, но здесь вопрос статистический - Java понятна большему количеству людей, в этом я не сомневаюсь.
Я не отношусь к ним Я не люблю языки, несущие много избыточной информации в виде лишних токенов. И высокая вложенность объектов Java меня обычно угнетает
avmich>Если мне надо подправить чужую программу, мне важно, чтобы она была понятна - включая язык. Так что это скромное мнение Крона, что Перл и PHP проще.
PHP - в этом плане уродец. Он служит именно для написания быстрых одноразовых программ. Хотя многие на PHP лепят целые сайты, но это извращение. Язык, в котором нельзя даже включить обязательное описание переменных не может претендовать на роль языка крупных проектов. Но Perl - другое дело.
1. Под Perl существует море стандартных библиотек. Надо мне сделать base64 encode? - пожалуйста. Надо скачать страницу, прикинувшись MSIE - вот. Сделать SQL-запрос? Чего проще! А если стандартных библиотек мало, скажем, хочется работать с графикой на уровне GIMP'а - есть тысячи этих модулей на CPAN'е.
2. Чрезвычайно насыщенный синтаксис. Для меня Perl тут близок к идеалу. Стоит только разобраться и запомнить тонкости применения регекспов или обработки переменных по умолчанию, как ненужной писанины оказывается на порядок меньше, чем в классических ЯВУ, и читаемость программ подскакивает на порядок - и кода программы перед глазами оказывается больше, и лишних токенов меньше.
3. Просто общая мощь языка.
В общем, конструкции языка столько лаконичны и насыщены, что нередко программу-то создавать не обязательно, можно из командной строки через perl всё сделать
Недостаток же Perl'а серьёзный один - крайне низка скорость, даже относительно той же Java ранних модификаций...
Я привык (т.е. писать в любой обстановке, на любом системе и т.п.) к Perl, PHP, Forth, C/C++, разные асмы
Доводилось писать (в смысле - вещи посложнее "Hello world") на Java, FORTRAN, Visual Basic, QBasic. Изучал концепции и писал всякие бенчмарки на Haskell, Ocaml, C#... Это только, скажем, за последний год. Сколько десятков языков прошло через меня за последние лет 10 - я просто не смогу всё вспомнить В общем, каша концепций и подходов изрядная, так что есть что с чем сравнивать. Надо отметить, что к Perl'у я привыкал долго и болезненно. Очень многое не нравилось, многое не умел. Да и сейчас я не гуру Perl'а avmich>Писать программы "write only" на нём быстрее
Мне кажется, ты в этой роли его с PHP путаешь
avmich>только сложность таких программ более ограничена.
Проект в миллион строк - да, не напишешь. Но вот, например, Авиабаза сейчас имеет, как минимум, более 30 тыс. строк на Perl'е. И я не вижу никаких проблем к наращиванию их ещё на порядок, а то и на два - модульность последних моделей офигенная, у меня нередко какой-нибудь отдельный модуль, под целое направление, занят всего одной функцией, в расчёте на дальнейшее расширение. Кстати, написано всё очень и очень коряво, поскольку начиналось всё писаться когда я Perl едва знал, а полной "с нуля" переписи не было и не будет. Просто планомерная замена одних, корявых модулей, на новые и изящные
avmich>Моё мнение, что JSP как минимум понятнее Перла. Согласен, каждый язык понятен своему создателю, но здесь вопрос статистический - Java понятна большему количеству людей, в этом я не сомневаюсь.
Я не отношусь к ним
Я не люблю языки, несущие много избыточной информации в виде лишних токенов. И высокая вложенность объектов Java меня обычно угнетает avmich>Если мне надо подправить чужую программу, мне важно, чтобы она была понятна - включая язык. Так что это скромное мнение Крона, что Перл и PHP проще.
PHP - в этом плане уродец. Он служит именно для написания быстрых одноразовых программ. Хотя многие на PHP лепят целые сайты, но это извращение. Язык, в котором нельзя даже включить обязательное описание переменных не может претендовать на роль языка крупных проектов. Но Perl - другое дело.
1. Под Perl существует море стандартных библиотек. Надо мне сделать base64 encode? - пожалуйста. Надо скачать страницу, прикинувшись MSIE - вот. Сделать SQL-запрос? Чего проще! А если стандартных библиотек мало, скажем, хочется работать с графикой на уровне GIMP'а - есть тысячи этих модулей на CPAN'е.
2. Чрезвычайно насыщенный синтаксис. Для меня Perl тут близок к идеалу. Стоит только разобраться и запомнить тонкости применения регекспов или обработки переменных по умолчанию, как ненужной писанины оказывается на порядок меньше, чем в классических ЯВУ, и читаемость программ подскакивает на порядок - и кода программы перед глазами оказывается больше, и лишних токенов меньше.
3. Просто общая мощь языка.
В общем, конструкции языка столько лаконичны и насыщены, что нередко программу-то создавать не обязательно, можно из командной строки через perl всё сделать
Недостаток же Perl'а серьёзный один - крайне низка скорость, даже относительно той же Java ранних модификаций...
… чтобы понять рекурсию, нужно сперва понять рекурсию …
Всё чаще и чаще от теоретиков звучат слова, что сегодня ООП - это скорее фетиш, поднятый на флаг коммерсантами, чем реально необходимый в таких масштабах инструмент. В общем, очередная поп-мода
… чтобы понять рекурсию, нужно сперва понять рекурсию …
hcube>Да... это фигня... с тем же успехом можно назвать Драконом любого отморозка.
Значит - плохо читал "Атомный Сон". Или плохо постигал восточную мудрость. 
Значит - плохо читал "Атомный Сон".
Или плохо постигал восточную мудрость.
… чтобы понять рекурсию, нужно сперва понять рекурсию …
По поводу прецендентов:
… чтобы понять рекурсию, нужно сперва понять рекурсию …
Copyright © Balancer 1997..2024
Связь с владельцами и администрацией сайта: anonisimov@gmail.com, rwasp1957@yandex.ru и admin@balancer.ru.
Связь с владельцами и администрацией сайта: anonisimov@gmail.com, rwasp1957@yandex.ru и admin@balancer.ru.
