Какой язык выучить "для себя"

GOGI> Шли бы вы мужики с такими разговорами в соответствующий форум.
GOGI> А то читаешь и чувствуешь себя умственно отсталым.

Так ты вопросы задавай по своей теме

Murkt> Зря смеётесь. Такое бывает действительно очень часто.

Пардон, для писания Generic Algorithms надо всё-таки иметь нехилую подготовку. В случайные такие штучки я не верю. И такой подход в программировании не люблю. Такой стиль порождает не просто трудноулавливаемые ошибки, а очень трудноулавливаемые ошибки.

GOGI> Шли бы вы мужики с такими разговорами в соответствующий форум.
GOGI> А то читаешь и чувствуешь себя умственно отсталым.

Мы ведем среди тебя разъяснительную беседу. А ты должен расти над собой ©

Murkt> Очень смешно, поржал.
Так вот в книжке, как раз, не рекомендуют использования isinstance — а вдруг заработает.

Mishka> Такой стиль порождает не просто трудноулавливаемые ошибки, а очень трудноулавливаемые ошибки.

Ну, не знаю... Вот Хаскелл - очень жёсткий язык. Весь из себя такой статический Тем не менее - типы часто не указываются, проверки на типы не делаются. И это не мешает ему ажно академичным с позиций строгости быть Другое дело, что он ошибки типизации может ещё при компиляции отловить, насколько я понимаю.

А так - есть "Питон со статической типизацией" - Boo зовётся: BOO - Home

GOGI>> Шли бы вы мужики с такими разговорами в соответствующий форум.
GOGI>> А то читаешь и чувствуешь себя умственно отсталым.
mabusse> Мы ведем среди тебя разъяснительную беседу. А ты должен расти над собой ©
Мы ведём разъяснительную беседу среди себя, а ты учись на чужих ошибках.
А так — ты сразу можешь начинать учить и другой язык. Тогда сразу поймёшь половину — почему одни языки сакс, а другие — кул.

А так Рома тебе уже ответил.

Murkt>> Такой подход больше используется в других языках. В Питоне, как правило, исключения ловят только там, где они действительно возникают (соединение с базой, например). Ну а если сами передаёте какую-нибудь фигню всредину, так будьте добр побеспокоиться словить исключение сами. Зачем я буду оборачивать в try..except каждый кусок кода в который нерадивый программист может передать какую-нибудь фигню? Так код раздуется раза в полтора, читабельность будет хуже. Ну и какой вообще толк от того, что я вместо TypeError отдам наверх какой-нибудь код возврата? Его всё равно надо будет как-то обрабатывать. Так уж лучше обычные ошибки - они везде одинаковы и общеприняты.
mabusse> Все верно. Но давайте договоримся (пока Mishk-и нет) оставить обработку исключений в стороне, ибо в пресловутом совете о них ничего не было сказано. Поднимаемся на уровень вверх, в вызывающую процедуру, написанную нерадивым программистом. Этот болван должен проверять типы данных, которые он передает ниже? В противном случае он получит эксепшн и потому он болван. А если бы он сначала проверил, что за хрень он передает, и вызывал бы вашу функцию только с соответствующим типом параметров, ошибок бы никогда не возникало, и он был бы уже не болван а гуру и ведущий программист Не так ли?

Вот старый — почти динозавр. Был когда-то такой язык — PL/I. И было его венское описание, которое, как говаривал умный народ (всякие Вирты, Дейкстры и прочии), что это самое нечитаемое (в смысле по невозможности прочесть) описание языка на 5,000 страниц. И была цель у него — любое написаное добро должно иметь смысл. В том числе и такое (за синтаксис полностью не отвечаю — я на нём уже не писал 24 года):

1. ...
2. DECLARE
3.   x str(5), i float;
4. BEGIN
5.   x := "1";
6.   i := x + 5;
7.   return i;
8. END

И таки возвращал 6 — вызывалась процедура внутреннего чисел, всё складывалось и вычиталось. Вот только когда писали x := "one" (или вводилось) — то переставало работать. Народ тихо охреневал.
Не было там ничего про try-except.

GOGI>>> Шли бы вы мужики с такими разговорами в соответствующий форум.
Mishka> GOGI>> А то читаешь и чувствуешь себя умственно отсталым.
mabusse>> Мы ведем среди тебя разъяснительную беседу. А ты должен расти над собой ©
Mishka> Мы ведём разъяснительную беседу среди себя, а ты учись на чужих ошибках.
Mishka> А так — ты сразу можешь начинать учить и другой язык. Тогда сразу поймёшь половину — почему одни языки сакс, а другие — кул.
Mishka> А так Рома тебе уже ответил.

Я дико извиняюсь, но это ты кому ответил?

Murkt>> Зря смеётесь. Такое бывает действительно очень часто.
Mishka> Пардон, для писания Generic Algorithms надо всё-таки иметь нехилую подготовку. В случайные такие штучки я не верю. И такой подход в программировании не люблю. Такой стиль порождает не просто трудноулавливаемые ошибки, а очень трудноулавливаемые ошибки.
А тут не Generic Algorithms. Дженерики подразумевают большую разнотипность обрабатываемых данных. А в Питоне я могу подсунуть коду какой-нибудь класс, в котором всё так же, как и в обычном, но немножечко не так. Но алгоритму ведь об этом знать не нужно! Для него всё прозрачно. Например, список, оптимизированный для хранения длинных последовательностей одинаковых чисел. Не забывайте про duck typing.

Murkt>> Очень смешно, поржал.
Mishka> Так вот в книжке, как раз, не рекомендуют использования isinstance — а вдруг заработает.
Ещё раз повторю - правильно делают. Проверять типы на "а вдруг" - это для других языков программирования.

mabusse> Я дико извиняюсь, но это ты кому ответил?
Это я дополнил твой ответ GOGI.

Murkt> А тут не Generic Algorithms. Дженерики подразумевают большую разнотипность обрабатываемых данных. А в Питоне я могу подсунуть коду какой-нибудь класс, в котором всё так же, как и в обычном, но немножечко не так. Но алгоритму ведь об этом знать не нужно! Для него всё прозрачно. Например, список, оптимизированный для хранения длинных последовательностей одинаковых чисел. Не забывайте про duck typing.

Вот то, что ты написал и есть GP — в чистом виде. И проблемы с питоновским описанным подходом состоят в том, что даже не проверяешь, что у тебя нужный интерфейс реализован. Ошибки такого рода могут сидеть годами незамеченными, а потом рухнуть в самый неподходящий момент.

Mishka>> Так вот в книжке, как раз, не рекомендуют использования isinstance — а вдруг заработает.
Murkt> Ещё раз повторю - правильно делают. Проверять типы на "а вдруг" - это для других языков программирования.

Ещё раз пофффторю — неправильно делают. Писать алгоритм на "вдруг заработает" это, ИМХО, одна из самых больших глупостей. И, если питон этому учит или подталкивает к такому решению, то выкидывать его надо на свалку сразу.

Murkt>> А тут не Generic Algorithms. Дженерики подразумевают большую разнотипность обрабатываемых данных. А в Питоне я могу подсунуть коду какой-нибудь класс, в котором всё так же, как и в обычном, но немножечко не так. Но алгоритму ведь об этом знать не нужно! Для него всё прозрачно. Например, список, оптимизированный для хранения длинных последовательностей одинаковых чисел. Не забывайте про duck typing.
Mishka> Вот то, что ты написал и есть GP — в чистом виде. И проблемы с питоновским описанным подходом состоят в том, что даже не проверяешь, что у тебя нужный интерфейс реализован. Ошибки такого рода могут сидеть годами незамеченными, а потом рухнуть в самый неподходящий момент.
Интерфейс не проверяю, да (duck typing). Может быть в каких-то нишах это и не имеет права на жизнь (промышленность), но в массе других применений работает всё замечательно. И экономит очень много времени и денег. Между прочим, так работают все языки с duck typing, и никто не ругается - вон их сколько, этих языков.

Murkt> Интерфейс не проверяю, да (duck typing). Может быть в каких-то нишах это и не имеет права на жизнь (промышленность), но в массе других применений работает всё замечательно. И экономит очень много времени и денег. Между прочим, так работают все языки с duck typing, и никто не ругается - вон их сколько, этих языков.

Ничто не ново под луной. Duck Typing когда-то назывался отложенной динамической проверкой. Очень популярно в любых интерпретаторах, т.к. для полной статистической проверки надо компилировать всю программку. А дальше будет как в Пёрле (Рома описывал). Только чуть лучше ловит. Насчёт экономии времени и денег — тут не согласен. Но пёрл по этой причине (точнее, и по этой причине тоже) умирает.

А отложенную динамическую проверку когда-то даже в железе пытались делать. В том числе и в Эльбрусе. Мой начальник долго воевал с эльбрусовцами на эту тему. После трёх лет войны, они ввели команды обычные, а не с проверкой тэгов динамически.

Mishka> Ничто не ново под луной. Duck Typing когда-то назывался отложенной динамической проверкой. Очень популярно в любых интерпретаторах, т.к. для полной статистической проверки надо компилировать всю программку. А дальше будет как в Пёрле (Рома описывал). Только чуть лучше ловит. Насчёт экономии времени и денег — тут не согласен. Но пёрл по этой причине (точнее, и по этой причине тоже) умирает.
Дык Перл и не рассчитан на большие и серьезные проекты - он хорош в каждодневном использовании для маленьких программ. Для серьезных вещей нужно более серьезные инструменты, а не быстрая трансляция...

Murkt> Интерфейс не проверяю, да (duck typing). Может быть в каких-то нишах это и не имеет права на жизнь (промышленность), но в массе других применений работает всё замечательно. И экономит очень много времени и денег. Между прочим, так работают все языки с duck typing, и никто не ругается - вон их сколько, этих языков.
Ну если для разовой халтурки... Языков - да, дофига. И в академических целях - сколько угодно. Да и для open source - ты, выложил, у тебя работает, но гарантии ты не даешь - на страх и риск того, кто скачал.

Murkt> Это - факт. Не для разовой халтурки - Балансер привёл примеры настольных программ, на Питоне работают некоторые сервера, на Питоне работают крупнейшие сайты (ютуб, в гугле много). Вполне возможно, что управление ядерной электростанцией на Питоне лучше не писать.
Это - сайт. Информационный... Ну ляжет он, ну отпишуться тебе пользователи, полезешь и поправишь. А если сайт банковский и в алгоритмах подсчета денег? Настольные - опять таки для кого? Для серьезных вещей и тестирование серьезное делают, а не "как бы нам быстрее написать..."

yacc> Дык Перл и не рассчитан на большие и серьезные проекты - он хорош в каждодневном использовании для маленьких программ. Для серьезных вещей нужно более серьезные инструменты, а не быстрая трансляция...

В бытность аспиратом матмеха, мы всей лабой получили пропуск (через того же Витю Годунова) на какой-то там Comdex, который проходил в Питере. Пошли туда. И там встретили симпатичных девушек, бойко что-то обсуждавших про программирование. Подкатились к ним гордые (как же, блин, мы компиляторщики и осевики — статические языки — Алгол 68, Ада, Модула 2, С и С++ для разминки, Lisp — студенческий проект, Паскаль — да Антоша его написал за месяц) и спросили: "На чём пишите, девчата?" "На DBase III" — был ответ. "А-а-а!", — сказали мы, "Базки данных! Знаем, знаем. Сами разрабатываем СУБД!" "Да нет, мы к БД даже и не обращаемся, мы пишем расчётные задачки." Вот тут мы слегка и припухли. А оказывается их там формы привлекли для организации интерактивного взаимодействия. А ты говоришь, что Пёрл не был предназанчен...

Murkt>> Это - факт. Не для разовой халтурки - Балансер привёл примеры настольных программ, на Питоне работают некоторые сервера, на Питоне работают крупнейшие сайты (ютуб, в гугле много). Вполне возможно, что управление ядерной электростанцией на Питоне лучше не писать.
yacc> Это - сайт. Информационный... Ну ляжет он, ну отпишуться тебе пользователи, полезешь и поправишь. А если сайт банковский и в алгоритмах подсчета денег?
М-да.
Murkt> Может быть в каких-то нишах duck typing и не имеет права на жизнь (промышленность)
Читали? А этот сайт, между прочим, стоит очень много денег. И область таких сайтов - очень большая. И денежная. Или веб - "это не тру, мы его не рассматриваем, кому он нужен"?

yacc> Настольные - опять таки для кого? Для серьезных вещей и тестирование серьезное делают, а не "как бы нам быстрее написать..."
Как одно конфликтует с другим? Стремление сократить сроки и стоимость разработки очень часто означает именно раннее и серьёзное тестирование. Юнит-тесты, регрессионное тестирование. Чем меньше ошибок, тем быстрее работа

Murkt> М-да.

Ну было очень много сделано на CGI и, что, это служит доказательством того, что это было хорошо?

Murkt> Читали? А этот сайт, между прочим, стоит очень много денег. И область таких сайтов - очень большая. И денежная. Или веб - "это не тру, мы его не рассматриваем, кому он нужен"?

Вопрос не в том, чего нельзя сделать. Вопрос в том — а нужно ли? И как это окупится сейчас и потом. Делают массу решений, Которые сейчас дешевле. Это оправдано в какой-то мере и в какой-то момент — когда выживаешь. Но не очень далее этого.

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

Murkt> Как одно конфликтует с другим? Стремление сократить сроки и стоимость разработки очень часто означает именно раннее и серьёзное тестирование. Юнит-тесты, регрессионное тестирование.

Оно всегда конфликтует. Полное тестирование всё равно невозможно. Да и как ты протестируешь тот же метод, если он типы не проверяет? Ты реализуешь все типы какие возможно?

GOGI>>> Шли бы вы мужики с такими разговорами в соответствующий форум.
Mishka> GOGI>> А то читаешь и чувствуешь себя умственно отсталым.
mabusse>> Мы ведем среди тебя разъяснительную беседу. А ты должен расти над собой ©
Mishka> Мы ведём разъяснительную беседу среди себя, а ты учись на чужих ошибках.
Mishka> А так — ты сразу можешь начинать учить и другой язык. Тогда сразу поймёшь половину — почему одни языки сакс, а другие — кул.
Mishka> А так Рома тебе уже ответил.

При всем уважении к Гоги, вопрос он поставил некорректный, вот и получил некорректные ответы. Не язык надо изучать, а программирование. В такой редакции, в какой Гоги задал вопрос, это напоминает что-то вроде "я хочу научиться лечить зубы, какие материалы для пломб посоветуете?"

ЗЫ Гоги мне весьма симпатичен, очень не хотелось бы, чтобы данный постинг звучал для него высокомерным брюзжанием. Просто это действительно весьма широкая область деятельности и собственно язык значит для начинающего пренебрежимо мало.

Mishka> А оказывается их там формы привлекли для организации интерактивного взаимодействия. А ты говоришь, что Пёрл не был предназанчен...
Да я сам на нем биллинг в свое время писал... Ну и там всякие IRC или Багзиллы есть... Но... все-таки большие вещи на нем писать не то. Вдумайся в его название ( хотя понятное дело, что "за время пути собачка успела подрасти" ). Для маленьких прог доллары и собачки можно потерпеть ( это окупится лаконичностью регулярных выражений и не запариванием насчет памяти ) - зато быстрее сделаешь и трассировкой ( без IDE ) отладишь. А на более серьезном - таки всяких интерфейсов по спецификациям хочцца и нормального отладчика ... Сайт - это набор скриптов для форм + общая часть + (возможно) демоны или переодические процессы через крон. И SQL там интенсивно используется.

Murkt>> М-да.
Mishka> Ну было очень много сделано на CGI и, что, это служит доказательством того, что это было хорошо?
Я не привожу youtube или google в доказательство того, что питон - это хорошо. Я привожу их в доказательство того, что duck typing работает, причём работает без всяких проблем. И не падает, что удивительно. Десятки миллионов пользователей годами не могут эти сайты уронить. Несмотря на отсутствие статических проверок типов.

Murkt>> Читали? А этот сайт, между прочим, стоит очень много денег. И область таких сайтов - очень большая. И денежная. Или веб - "это не тру, мы его не рассматриваем, кому он нужен"?
Mishka> Вопрос не в том, чего нельзя сделать. Вопрос в том — а нужно ли? И как это окупится сейчас и потом. Делают массу решений, Которые сейчас дешевле. Это оправдано в какой-то мере и в какой-то момент — когда выживаешь. Но не очень далее этого.
Слова красивые. Разверни более подробно, чем же грозит применение языков с "утиной" типизацией? В тех областях, где они сейчас применяются. И через сколько лет, ориентировочно, исчезнет оправданность?

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

Murkt>> Как одно конфликтует с другим? Стремление сократить сроки и стоимость разработки очень часто означает именно раннее и серьёзное тестирование. Юнит-тесты, регрессионное тестирование.
Mishka> Оно всегда конфликтует. Полное тестирование всё равно невозможно.
А что, со статической проверкой типов возможно полное тестирование? Разве что в случае программ уровня hello world.

Mishka> Да и как ты протестируешь тот же метод, если он типы не проверяет? Ты реализуешь все типы какие возможно?
Я протестирую его на тех типах и данных, которые я буду использовать. Если он работает и на других типах - так в чём проблема? Когда мне понадобится, я протестирую, или другой человек протестирует этот метод на работу с другим типом данных. Если работает - я его повторно буду использовать. Или ты думаешь, что в динамически типизируемых программах в коде появляются переменные с неизвестно каким типом и значением, и которые могут из-за этого уронить мою программу? Ну, разве что рядом НЛО пролетать будет.