Джентельменский набор ЯП

Откуда уверенность, что эта функция не выходе даст список? Откуда уверенность, что y оканчивается на nil?

А откуда такая уверенность в хаскеле?

А ты посмотри на тип функции. Она принимает список, оттуда и уверенность.

> ненадо руби выкидывать, отличный язык, на чем же еще скрипты писать
На Tcl.

По теме: befunge забыли. Где ещё встретишь двумерное (или больше) пространство памяти и векторный InstructionPointer?

>> ненадо руби выкидывать, отличный язык, на чем же еще скрипты писать >На Tcl.

s/Tcl/perl/

>> ненадо руби выкидывать, отличный язык, на чем же еще скрипты писать >На Tcl.

> s/Tcl/perl/

s/Tcl/Python/

s/perl/Python/

s/Ruby/Python/

s/tailgunner/anonymous/

;)

s/.*/lisp/g

s/anonymous/troll/

> s/tailgunner/anonymous/

Эх, да разве я могу возместить потерю анонимных братьев :/

И не говори, гнобить стало совершенно некого... :(

>Scheme -> Haskell

Тот, кто начинает программировать со схемы, никогда не станет приличным программистом (с) К. О.

У меня самого был такой путь:

Sinclair Basic => Pascal => C++ => Haskell

>Есть мнение, что статически типизированные ЯП не нужны, когда любой уважающий себя девелопер имеет практику покрывать юнит-тестами весь свой код.

есть также мнение, что быдлокодеры, покрывающие все юнит-тестами, нужны разве что в качестве топлива

> быдлокодеры, покрывающие все юнит-тестами, нужны разве что в качестве топлива

Афигеть. Раскрой тему, а?

>Афигеть. Раскрой тему, а?

Ну jtoof выше уже частично раскрыл.

Вместо того, чтобы тратить свое время на написание и поддержку юнит-тестов, нужно максимально навесить все проверки на плечи компилятора. В крайнем случае -- использовать контракты в рантайме. А если же язык таков, что компилятор просто не способен облегчить задачу программиста в этом плане, то увы -- приходится использовать юнит-тесты. Но юнит-тесты -- это костыль, вынужденная мера, которая обусловлена либо недостатками языка, либо недостатком джуниор-кодера, неспособного использовать возможности языка для предохранения от ошибок.

Это мне напоминает то, как джависты и шарписты пеняют плюсистам, что в цпп нет конструкции try...finally. Хотя на самом деле finally в подобных языках -- это костыль, существующий из-за невозможности реализации идиомы RAII.

Естественно, это никоим образом не отменяет тестирования со стороны SQA. Юнит-тесты -- это исключительно инструмент разработчика, а не инженера по контролю качества.

> Вместо того, чтобы тратить свое время на написание и поддержку юнит-тестов, нужно максимально навесить все проверки на плечи компилятора. В крайнем случае -- использовать контракты в рантайме.

Я таки не понял, чем плохо 100% покрытие тестами. Тем более, что нормальные unit-тесты ловят ошибки логики, что компиляторы пока не умеют (ну или не всегда умеют).

> Это мне напоминает то, как джависты и шарписты пеняют плюсистам, что в цпп нет конструкции try...finally. Хотя на самом деле finally в подобных языках -- это костыль

А я бы хотел finally.

>Ну jtoof выше уже частично раскрыл

ну почему, почему все всегда норовят покорёжить мой прекрасный симметричный ник? вроде ж не такой уж он и сложный. непонятно. непонятно

>> Ну jtoof выше уже частично раскрыл

> ну почему, почему все всегда норовят покорёжить мой прекрасный симметричный ник?

Хм, чо-то я не вижу симметрии в "jtoof".

:D

>Хм, чо-то я не вижу симметрии в "jtoof"

и я не вижу. а вот в jtootf - вижу

непорядок

>ну почему, почему все всегда норовят покорёжить мой прекрасный симметричный ник?

виноват, каюсь:)

>Я таки не понял, чем плохо 100% покрытие тестами.

тем, что на их написание и поддержку уходит слишком много времени, которое можно потратить непосредственно на разработку

>А я бы хотел finally.

зачем?

> Sinclair Basic => Pascal => C++ => Haskell

Отстой.

Z80 assembler -> x86 assembler -> c-- -> c -> c++ -> common lisp

>>Я таки не понял, чем плохо 100% покрытие тестами.

> тем, что на их написание и поддержку уходит слишком много времени, которое можно потратить непосредственно на разработку

Быдлокодеришко? За тебя кто-то программу продумывает и даёт листок со спецификациями, по которому код клепать надо?

> Но юнит-тесты -- это костыль, вынужденная мера, которая обусловлена либо недостатками языка, либо недостатком джуниор-кодера, неспособного использовать возможности языка для предохранения от ошибок.

Человек, имевший Спектрум, но не программировавший на ассемблере, право на собственное мнение не имеет.

>Z80 assembler -> x86 assembler -> c-- -> c -> c++ -> common lisp

МК-61 -> Basic -> Focal -> Asm 8080 -> Асм PDP -> Forth -> Си, Паскаль -> Асм x86 -> FORTRAN -> Perl -> PHP -> Java ... :)

>Человек, имевший Спектрум, но не программировавший на ассемблере, право на собственное мнение не имеет.

Имеет. Но не в области программирования :)

> МК-61 -> Basic -> Focal -> Asm 8080 -> Асм PDP -> Forth -> Си, Паскаль -> Асм x86 -> FORTRAN -> Perl -> PHP -> Java ... :)

MK-61?! Да ты ещё круче меня! :)

>MK-61?! Да ты ещё круче меня! :)

Заметь, там Basic без указания версий. Там всё ещё круче. Я первые свои программы на Бейсике писал на листке бумажки и исполнял в голове ;) На реальном железе первый раз Бейсик (GW Basic) увидел на областной олимпиаде по программированию в 1989-м. Ну а свой первый Бейсик был уже на Радио-86РК :) Спекки был уже много позже, где-то в 1992-м :)

> Заметь, там Basic без указания версий. Там всё ещё круче. Я первые свои программы на Бейсике писал на листке бумажки и исполнял в голове ;)

Так у меня то же самое! Дома был Спектрум, в школе Корветы, диалекты различались, я в тетрадке программы (игрушки) на корветовском бейсике писал.

На реальном железе первый раз Бейсик (GW Basic) увидел на областной олимпиаде по программированию в 1989-м. Ну а свой первый Бейсик был уже на Радио-86РК :) Спекки был уже много позже, где-то в 1992-м :)

Чёрт, не говори только, что ты Радио сам себе спаял! Я от зависти умру.

>Чёрт, не говори только, что ты Радио сам себе спаял!

Именно так! :D При чём полгода на него со стипендии откладывал, Тушинского рынка я тогда не знал и покупал комплектующие по гос. ценам в магазинах. 17.50р. за КР580ВМ80А, 20.00р. за ВГ72, два раза по 50.00 руб за два по 16кБ оперативки (565РУ6)... Итого на 140 рублей набежало. Месячная зарплата иного инженера :D Потом целое лето отлаживал, опыта сборки цифровой техники не было, а программно конструкция 86РК сложная была...

Потом были самопаянные Орион-128, серия разнокалиберных Спектрумов, и в конце - АТМ-Турбо (Sprectrum-128 + CP/M в одном флаконе). И только в 1994-м удалось скопить на персональную 486DLC-40 :) (до этого - с товарищем делили его Поиск/286-12/286-20/386SX-40/486DLC-40, с последней мамку с процом я у него и взял после очередного апгрейда...)

...

Прикольно, что самый первый РК86 до сих пор в деревне в Калининградской области, откуда я родом, валяется. Только без радиомодема для ТВ, его я забирал потом в Москву, да так где-то и посеял... Поеду туда снова, надо будет отфоткать для истории :)

Для зверского ностальгирования :)

В 2004-м отсканил для истории :)
http://airbase.ru/computers/pmk/progs/PMK.djvu

А это - уже другое маньячество.
Вручную дизассемблированный моим товарищем 16кБ BIOS МК-85 :)
http://balancer.ru/computers/mk/mk-85/files/MK-85_BIOS_GAW.djvu

Я придумал, как на нём до памяти и ассемблера добраться и вытащил первые дампы, а он догадался, что эти дампы - не специализированный ассемблер, как я думал, а обычный PDP и дизассемблировал его :)

Уважуха! Я сопляком ходил в библиотеку, смотрел журнал "Радио" и мечтал о том времени, когда смогу спаять "Радио" или "Орион". Потом было много Спектрумов, начался апгрейд паяльником. Последний агрегат (GRM-2+) был прокачан по моде: турбо на Z80 и ВГ, мегабайтная симмка с двумя режимами листания страничек (Profi и Pentagon-1024), ПЗУ с двумя прошивками (стандарная 82-го года для совместимости и Глюк) и двумя TR-DOS'ами (стардартная 5.03 и глюковская), саундрайв, контроллер мыши по своей схеме (микросхемы нужные после развала СССР исчезли).

>Я сопляком ходил в библиотеку, смотрел журнал "Радио" и мечтал о том времени, когда смогу спаять "Радио" или "Орион".

У меня болезнь началась с выходом приложения к ЮТ с модульным компом ЮТ-88, который начинался как продвинутый калькулятор и потом рос до типичного 8080-компа :)

Я номер с первым выпуском до дыр залистывал, поняв, что _это_ я собрать осилю. (А о готовых компах тогда на одну зарплату матери - сельской учительницы и не мечтал).

И только когда в Москву выбрался, понял, что осилю собрать сразу готовый Радио-86РК :)

>Profi

Ы! Помню войны сторонников ATM Turbo vs Profi... Это было едва ли не круче, чем Си vs Pascal несколькими кодами спустя, или как Intel vs AMD, 3Dfx vs nVidia... Сегодняшние Python vs Ruby или nVidia vs ATI - в подмётки тем страстям не годятся :)

>>Я таки не понял, чем плохо 100% покрытие тестами.

>тем, что на их написание и поддержку уходит слишком много времени, которое можно потратить непосредственно на разработку

Оно может окупиться за счет сокращения отладки, и сокращения времени на внесение изменений.

>>А я бы хотел finally.

>зачем?

Потому что бывает так, что по окончанию try-блока нужно просто выполнить код (_не_ освобождения ресурсов). Скажем, просто напечатать на "Завершение успешно"/"Завершение неуспешно".

>Оно может окупиться за счет сокращения отладки

Но баланс именно посередине. Если чрезмерно заниматься тестрованием, продукт заданной надёжности получается дольше, чем с умеренным тестированием.

...

А _серьёзное_ тестирование способно отнять времени в десятки раз большее, чем написание программного комплекса.

Я в ~2000-м году в «Барсе» админил, которые был российским подразделением Honeywell Solutions (кто с авиацией хоть как-то знаком, должен их знать), так вот, практически всё подразделение, человек 20, занималось только тестированием. День за днём, месяц за месяцем :) Написание UML тестов, тестирование тестов, прогонка и так - непрерывно :)

Но там надёжность продукта такая требовалась. Не очень приятно, когда у тебя при заходе на посадку откажет софт, отвечающий, скажем, за предупреждение критических режимов ;)

>s/perl/Python/

Питон конечно замечательный язык, но в области скриптов для кофигурирования системы и обработки текста он отсосёт причмокивая у перла. не конкурент вообще/

>но в области скриптов для кофигурирования системы и обработки текста он отсосёт причмокивая у перла

Только за счёт "~" синтаксиса. Не так уж и много.

И факт есть факт - в системах Perl медленно, но верно вытесняется Python'ом.

> Питон конечно замечательный язык, но в области скриптов для кофигурирования системы и обработки текста он отсосёт причмокивая у перла. не конкурент вообще/

Перл мертв. Большинство его задач (и нужно) выполнять shell или Python.

Z80 basic -> Z80 asm -> QBasic -> C -> C++ -> Java -> Python -> Common Lisp -> Haskell

>> Оно может окупиться за счет сокращения отладки

> Но баланс именно посередине

У сферической задачи в вакууме - точно :)

> Если чрезмерно заниматься тестрованием, продукт заданной надёжности получается дольше, чем с умеренным тестированием.

Всё и всегда - вопрос баланса, не так ли? :D

> А _серьёзное_ тестирование способно отнять времени в десятки раз большее, чем написание программного комплекса.

Конечно. И расходы будут соответствующие. Поэтому (вернемся к теме флейма) рулят статически типизированные языки с выразительными системами типов.

>Поэтому (вернемся к теме флейма) рулят статически типизированные языки с выразительными системами типов.

У сферической задачи в вакууме - нет :)

На практике зависит от требуемого соотношения надёжность/скорость разработки. Это ещё не учитывая массы тонкостей, типа инфраструктуры, раскрученности и т.п. :)

> Человек, имевший Спектрум в 5 лет, но не программировавший на ассемблере, право на собственное мнение не имеет.

Починено.

> Всё и всегда - вопрос баланса

Скажи еще - балансера. )))

>существующий из-за невозможности реализации идиомы RAII

Вот за что я еще очень "люблю" ООП, так это за всякие "широко известные в узких кругах" словечки, типа RAII или IoC.

>рулят статически типизированные языки с выразительными системами типов.

Рулят-то они рулят... Но где ж их взять-то? Только ML подобные... да вроде еще scala. И в таких языках обязательно должен быть паттерн матчинг.

> Рулят-то они рулят... Но где ж их взять-то? Только ML подобные... да вроде еще scala. И в таких языках обязательно должен быть паттерн матчинг.

Qi. Около-lisp, выведение типов (опциональное!), паттерн матчинг.

>>рулят статически типизированные языки с выразительными системами типов.

>Рулят-то они рулят... Но где ж их взять-то? Только ML подобные... да вроде еще scala.

Тебе мало *ML? O_o И для полноты картины следовало упомянуть любимую игрушку околоакадемических кругов - Хаскел.

> И в таких языках обязательно должен быть паттерн матчинг.

Да, и нет прощения Брайту за отсуствие оного в D.

> Хотя на самом деле finally в подобных языках -- это костыль, существующий из-за невозможности реализации идиомы RAII.

В питоне и RAII делается нормально, и finally есть...

> питоне и RAII делается нормально

Это как? O_o

> Вот за что я еще очень "люблю" ООП, так это за всякие "широко известные в узких кругах" словечки, типа RAII или IoC.

RAII напрямую с ООП не связано. Как уже сказано выше, есть море ОО-языков без поддержки RAII.

>> питоне и RAII делается нормально

> Это как? O_o

Да вы попробуйте, ничего сложного :) В питоне каждая переменная - как boost::shared_ptr в C++. Надеюсь, как связан shared_ptr с RAII, вы знаете?