Комментарии 161
ИМХО, одно другому не мешает. Теоретически нет никаких ограничений на совместное использование статической и динамической типизации в одном языке, да и практически тоже (взять хотя-бы dynamic из C#).
Но вот ядро операционной системы, драйвер или прошивку для железки на чисто динамическом языке не напишешь:) А для обычных приложений вполне можно было бы использовать совмещенный подход, почему бы и нет?
Но вот ядро операционной системы, драйвер или прошивку для железки на чисто динамическом языке не напишешь:) А для обычных приложений вполне можно было бы использовать совмещенный подход, почему бы и нет?
С++ тоже развивается.
Если раньше приходилось писать так:
То сейчас можно уже не указывать тип:
А перебор коллекций вообще упрощен до смешного:
или:
Про Smart pointer's, Lambda's, Tuple's и пр. тоже не стоит забывать.
Если раньше приходилось писать так:
vector<int>::const_iterator i = vec.begin();
while (i != vec.cend()) {
/..
i++;
}
То сейчас можно уже не указывать тип:
auto i = vec.begin();
while (i != vec.cend()) {
/..
i++;
}
А перебор коллекций вообще упрощен до смешного:
for(int &i : vec) i *= i;
или:
array<int, 3> arr = {1, 2, 3};
for (auto i : arr) i *= i;
Про Smart pointer's, Lambda's, Tuple's и пр. тоже не стоит забывать.
когда в C# ввели dynamic — его тоже часто путали с var (на сколько я понял auto его аналог) — это разные вещи ;).
В приведенных вами примерах нет и намека на динамическую типизацию. Не путаете ли вы ее с автоматическим выводом типов?
Или вот более реальный пример:
По-моему очень даже динамично, не находите?
#include <iostream>
#include <array>
template<class T, class... Tail>
auto make_array(T thead, Tail... tail) -> std::array<T, 1 + sizeof...(Tail)>
{
std::array<T, 1 + sizeof...(Tail)> array = {thead, tail ...};
return array;
};
int main() {
auto array = make_array(1, 2, 3);
for (auto i : array)
std::cout << i*i << std::endl;
return 0;
}
По-моему очень даже динамично, не находите?
не находим. auto это не динамическая типизация. тип все равно определяется статически во время компиляции — просто компилятор сам его может вывести из контекста.
не спорю, это очень круто, и я обеими руками за — но, строго говоря, это не динамическая типизация.
не спорю, это очень круто, и я обеими руками за — но, строго говоря, это не динамическая типизация.
Все верно на этапе компиляции явно определяется тип инициализирующего значения.
И С++ по прежнему остается языком со статической типизацией, потому что auto это тоже тип.
А насчет динамичности я не успел развернуть мысль, это было больше стёбное выражение, говорящее о том, что новом стандарте и так упростил многое до безумия, куда еще проще, а главное зачем?
И С++ по прежнему остается языком со статической типизацией, потому что auto это тоже тип.
А насчет динамичности я не успел развернуть мысль, это было больше стёбное выражение, говорящее о том, что новом стандарте и так упростил многое до безумия, куда еще проще, а главное зачем?
Будем ли мы все программировать на динамически типизированных языках к 2010 году?
Нет, не будем.
Ваш К.О.
НЛО прилетело и опубликовало эту надпись здесь
Так и Java же ж
НЛО прилетело и опубликовало эту надпись здесь
Надо произносить Пи-Эйч-Пи.
НЛО прилетело и опубликовало эту надпись здесь
Если Java – это Ява, то Jazz…
… Рыба моей мечты?)
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
Естественно это была шутка. В английском вообще нет правил чтения. Почти.
>>Поражаюсь как ОЛОЛО имеет позитивную карму на хабре :D
Это вы конкретно про меня или про мой комментарий? :)
>>Поражаюсь как ОЛОЛО имеет позитивную карму на хабре :D
Это вы конкретно про меня или про мой комментарий? :)
НЛО прилетело и опубликовало эту надпись здесь
Каждой задаче — свои способы решения.
А вообще, мне кажется, что такие «гиганты» как C++, Java, C# еще долго будут строго-типизированными и долго будут в строю, потому что это своего рода «классика», но потихоньку будут уступать позиции тому же Python или Ruby. Тенденция программирования явно намечена на упрощение технических моментов и на сосредоточении разработчика на конкретной задаче, так что возможно когда-нибудь мы будем лишь вспоминать строгую типизацию.
А вообще, мне кажется, что такие «гиганты» как C++, Java, C# еще долго будут строго-типизированными и долго будут в строю, потому что это своего рода «классика», но потихоньку будут уступать позиции тому же Python или Ruby. Тенденция программирования явно намечена на упрощение технических моментов и на сосредоточении разработчика на конкретной задаче, так что возможно когда-нибудь мы будем лишь вспоминать строгую типизацию.
Меня всегда сильно напрягает то, что я не знаю какой код на самом деле выполняется. Для языка C и даже для C++ я примерно представляю в какие команды скомпилится мой алгоритм и могу оценить затраты памяти и время выполнения кода. Для perl — нет, для javascript — тем более нет.
Например, можно сказать что perl имеет два компилятора: отдельный для regexp — этот код обрабатывается «виртуальной машиной» написанной на C и другой для всего остального. Фактически это означает, что оптимизация кода должна проводиться по ДВУМ компиляторам.
Я не представляю как можно писать код сложных алгоритмов (классических?) на таких языках как javascript. Но это касается только алгоритмов со сложной математической подоплекой. Для таких задач как разработка движка сайта perl несомненно более удобен и быстр (с т.з. разработки) чем С++. Для обработки текстовых данных, парсинга, текстовых шаблонов и т.п. — тоже.
Например, можно сказать что perl имеет два компилятора: отдельный для regexp — этот код обрабатывается «виртуальной машиной» написанной на C и другой для всего остального. Фактически это означает, что оптимизация кода должна проводиться по ДВУМ компиляторам.
Я не представляю как можно писать код сложных алгоритмов (классических?) на таких языках как javascript. Но это касается только алгоритмов со сложной математической подоплекой. Для таких задач как разработка движка сайта perl несомненно более удобен и быстр (с т.з. разработки) чем С++. Для обработки текстовых данных, парсинга, текстовых шаблонов и т.п. — тоже.
Ну есть адепты, которые считают, что все, в т.ч. и сайты, должны писаться на с++.
И что ява — тормозное говно, потому что там нет прямого управления памятью и они не могут представить, в какие команды скомпилится их алгоритм.
И что ява — тормозное говно, потому что там нет прямого управления памятью и они не могут представить, в какие команды скомпилится их алгоритм.
Даже сайты-визитки?
Ага.
Но я, если что, за разумный выбор молотка. Диплом, клиент-серверное приложение управления роботом писал на С++, сайты и приложения пишу на PHP (ранее ASP, Perl), а софт давным-давно на Delphi и даже VB.
Но я, если что, за разумный выбор молотка. Диплом, клиент-серверное приложение управления роботом писал на С++, сайты и приложения пишу на PHP (ранее ASP, Perl), а софт давным-давно на Delphi и даже VB.
>>разумный выбор
>>софт на Delphi и даже VB.
Поперхнулся кофе. Знатно вы на ноль поделили.
>>софт на Delphi и даже VB.
Поперхнулся кофе. Знатно вы на ноль поделили.
А почему нет? В своё время Delphi предлагал широкий выбор компонент, должен признать это, хоть и не люблю Delphi/Pascal. А VisualBasic — на то время — лучший язык для работы с COM/OLE.
Просветите в чем принципиальное преимущество по работе с COM/OLE у VB по сравнению с тем же Delphi, например. Плюсы не беру, там действительно чуток посложнее.
Возможно я плохо знаю Delphi, но разве там были разрешены вызовы методов для объектов, тип которых неизвестен? В VB мог использоваться механизм IDispatch, причём для этого не требовалось ничего лишнего, внешне — обычный вызов метода.
Одно из преимуществ, которое для меня было принципиальным: Visual Basic намного терпимей к косячным COM–объектам.
Там, где остальные умирали, он продолжал работать.
Там, где остальные умирали, он продолжал работать.
Визитки — в первую очередь! :)
Скорость! Скорость! Скорость! Динамические языки заранее проигрывают по данному параметру. Пока скорость является важным параметром (например, в триггере событий на Большом Адронном Коллайдере, трейдинге в реальном времени), то строго-типизированные, компилируемые в машинный код, без сборщика мусора (С/С++) языки тут на первом месте.
Очень хочется вас перефразировать.
Скорость разработки! Скорость разработки! Скорость разработки!
Пока скорость разработки является важным параметром (например для написания сайтов, реализации ненагруженных gui), то динамические языки без «простых» способов выстрелить себе в ногу (ruby, python, php) тут на первом месте.
Ну в том плане что под разные задачи разные решения, про БАК то я с вами согласен.
Скорость разработки! Скорость разработки! Скорость разработки!
Пока скорость разработки является важным параметром (например для написания сайтов, реализации ненагруженных gui), то динамические языки без «простых» способов выстрелить себе в ногу (ruby, python, php) тут на первом месте.
Ну в том плане что под разные задачи разные решения, про БАК то я с вами согласен.
плюс много. Время работы программиста дороже железа. Скорость кода волнует всё меньше людей (купите более новое железо и всё), время на разработку и сопровождение кода определяет всё.
Это кто такое сказал? Если вы кодите говно энтерпрайз CRM на 30 человек — да. Как только появляется вопрос о highload, то вопрос начинает звучать проще: либо мы закупаем ещё 5 серверов по $20k каждый, либо вы решаете эту грёбанную проблему.
100к щто намного меньше чем надо будет платить программистам за написание и сопровождение быстрого кода.
100к — это один программист на год. Даже на полгода (расходы фирмы на программиста вдвое больше его зарплаты)
Т.е. для гугла, фейсбука и твитера — да. Им нужно быстро бегущий код — всем остальным — быстро и качественно написанный код.
100к — это один программист на год. Даже на полгода (расходы фирмы на программиста вдвое больше его зарплаты)
Т.е. для гугла, фейсбука и твитера — да. Им нужно быстро бегущий код — всем остальным — быстро и качественно написанный код.
Ну вот мы не гугль и не фейсбук, однако, за потребление процессора я с программистами не то, чтобы воюю, но вполне конкретно не хочу видеть больших цифр. Потому что это деньги, причём, в отличие от затрат на программирование, постоянные. 200 серверов, двухкратная экономия по нагрузке — и вполне можно на эти же деньги нанять ещё парочку программистов.
Ну вы же сразу про 200 серверов не сказали ;) весь вопрос еще в том, сколько программистов (и ит специалистов по сопровождению текущих серверов) у вас уже есть.
Но вообще общая суть в том, что если есть проблемы, в первую очередь она, скорее всего, решается покупкой нового оборудования, нежели еще одним новым сотрудником (как раз из-за стоимости), ну а если железо «почему то» уже не помогает — можно задуматься о программистах (новых просто или на замену старым). Как говорится — it depends ;)
Но вообще общая суть в том, что если есть проблемы, в первую очередь она, скорее всего, решается покупкой нового оборудования, нежели еще одним новым сотрудником (как раз из-за стоимости), ну а если железо «почему то» уже не помогает — можно задуматься о программистах (новых просто или на замену старым). Как говорится — it depends ;)
>>100к — это один программист на год
В какой стране? У нас 100К это 3-4 программиста в год
В какой стране? У нас 100К это 3-4 программиста в год
Америка, Европа, Израиль
Тут как бы в основном exUSSR-аудитория. Железо тут стоит немного дороже чем в этих странах, а программисты — в разы дешевле. Но дело даже не в этом. Далеко не всегда систему можно ускорить/масштабировать добавлением железа. И чтобы построить такую систему, которая будет легко масштабироваться, нужен труд большого числа высококвалифицированных программистов.
Понятно, что есть исключения. Но если посмотрите на то, как развивается индустрия софта, Вы увидите, что быстрые языки/системы/подходы заменяются на «быстро написуемые». Не зря так в гору пошла Ява, еще в 90е, когда она была и реально медленная и плохо продуманная. Всё потому что на ней легко писать
Готов подписаться под каждым словом. Вначале — надо быстрее сделать продукт! Давайте! Побольше абстракций. Больше готовых либ, даже если из всего ф-ционала только 20% используется. Вперед!
Через N месяцев — почем ж так медленно все. Почему столько памяти жрет? Что делать? Давайте переписывать части архитектуры на более производительных языках и тезнологиях!
Через N месяцев — почем ж так медленно все. Почему столько памяти жрет? Что делать? Давайте переписывать части архитектуры на более производительных языках и тезнологиях!
Вполне ожидаемый сценарий — сначала нужно выйти на рынок раньше (не сильно позже) других, чтобы захватить хорошую долю, с минимальными стартовыми издержками, чтобы не жалко было потерять в случае неуспешной попытки. А уже получая стабильный доход, можно заняться и минимизацией постоянных издержек, если рынок не требует новых фич.
Да ну. А что если от разницы в 10 мс на обработку изображения зависит купят ваш промышленный робот (стоимостью в 400000 евро) или нет? А это только один робот, их покупают сразу сотнями. Можете представить потери когда сделку заключают с конкурентом потому что их машина быстрее. Вы все еще считаете что время программиста дороже?
Вы часто продаете роботов стоимостью в 400'000 евро и сразу сотнями?
Я работал в компании которая это делает: www.accretech.jp/english/
А может дешевле добавить роботу «мозгов», чем переписывать код со, скажем, интерпретируемого языка на компилируемый?
Проблема в том, что есть некий предел скорости, на котором может функционировать не распределенная система, зависящий от текущего уровня технологии. Вы не можете купить процессор лучше чем «Mega Super Ultra», просто потому, что их не существует в природе. При этом, некоторые технологии требуют именно «не распределенных» вычислений просто потому, что распределенных аналогов не существует. На сегодняшний день не существует алгоритмов, способных «распределить» систему, которой необходим сквозной не кешируемый доступ к памяти, когда каждой составляющей системы необходим постоянный доступ к значительным по объему данным, которые постоянно меняются, и которые невозможно адекватно синхронизировать между собой. К примеру, мы хотим получать некую статистику методом Монте-Карло: сам метод подразумевает генерацию последовательности случайных чисел. За не именеем генератора действительно случайных чисел, мы пользуемся генератором «псевдослучайных» чисел, который удовлетворяет заданным нами характеристикам «случайности». Однако, такие генераторы невозможно адекватно распераллелить, т.е. на распераллеленной системе мы получаем уже не один ГСЧ, а несколько независимых. При этом «случайность» каждого из них уменьшается вследствии того, что недостатки «псевдослучайности» более ярко выраженны, если генерируется N псевдослучайных последовательностей вместо одной. От этого факта невозможно просто «убежать», повысив мощность кластера, необходимо повышать мощность каждого процессора, что упирается в границу существующих технологий.
Согласитесь, что таких, в принципе нераспределяемых задач меньшинство. А для многих задач только «специально» (откровенный говнокод никто не отменял) можно сделать решение, тормознутость которого будет заметна невооруженным взглядом.
А мы в топике говорим об общих тенденциях вроде как.
А мы в топике говорим об общих тенденциях вроде как.
Ну, за меньшинство я бы не ручался, да и даже меньше на несколько процентов и в разы — это разные вещи.
Но даже если не спорить об этом факте, нераспараллеливаемый алгоритм будет узким местом, которое может существенно снизить эффектвность распараллеливания остальных алгоритмов. Плюс если вспомнить закон Амдала, получим, что на определённом этапе увеличение числа вычислительных элементов почти ничего не даст.
Но даже если не спорить об этом факте, нераспараллеливаемый алгоритм будет узким местом, которое может существенно снизить эффектвность распараллеливания остальных алгоритмов. Плюс если вспомнить закон Амдала, получим, что на определённом этапе увеличение числа вычислительных элементов почти ничего не даст.
О чем спор? Там где важна скорость и надежность нужна строгая типизация. Там где важнее скорость разработки, гибкость, где разработка поставлена на конвееер, там нужна динамическая типизация. Как всегда любые решения должны выбираться исходя из задач, а не по принципу «это мне больше нравится, остальное отстой»
Еще более странно, что в споре противопоставляются «строгая типизация» и «динамическая типизация». Почему? Они не противоречат друг другу. Можно обсуждать "статическая vs. динамическая типизация" и "строгая vs. мягкая типизация". Есть целая куча самых разных комбинаций.
Какой спор? Я и не спорил, просто предыдущее заявление мне показалось слегка категоричным.
Причем здесь строгая/нестрогая типизация и способ выстрелить себе в ногу?
В питоне, например, стрелял себе в ногу с юникодными/неюникодными стрчками. (В неюникодную строчку сохраняются юникодные символы, строчка создается, но после этого скрипт в неожиданных местах начинает падать, например при попытке вывода на консоль).
Да и четкой зависимости между динамической типизацией и направленностью на быструю разработку я не вижу, посмотрите например на Delphi — направленность на быструю разработку и строгая типизация.
Не мешайте в кучу сразу столько понятий.
В питоне, например, стрелял себе в ногу с юникодными/неюникодными стрчками. (В неюникодную строчку сохраняются юникодные символы, строчка создается, но после этого скрипт в неожиданных местах начинает падать, например при попытке вывода на консоль).
Да и четкой зависимости между динамической типизацией и направленностью на быструю разработку я не вижу, посмотрите например на Delphi — направленность на быструю разработку и строгая типизация.
Не мешайте в кучу сразу столько понятий.
В языках со слабой типизацией меня удивляет — если мы знаем, что это переменная всегда int, зачем мы скрываем это от компилятора? :)
Это часто удобно, преобразовывать типы неявно — например, в шаблонизаторах это удобно при сравнениях (привет, php), или в электронных таблицах в формулах (привет, VB).
Смысл в языках со слабой типизацией есть, другое дело что при написании программ общего назначения слабая типизация мешает все-таки)
Смысл в языках со слабой типизацией есть, другое дело что при написании программ общего назначения слабая типизация мешает все-таки)
Это вы про динамическую скорее, чем про слабую. А так общий ответ: «транслятор умный — сам поймёт».
проигрывают, но какие-то критические части никто не мешает переписать на тот же C, в питоне так вообще это легко делается
На самом деле всё от компилятора зависит. Из того же Javascript отлично строится и компилируется строго типизированное приложение, просто это делается «за кулисами». И работает оно пусть и медленнее аналогов на С++, но это проценты, максимум разы, но никак не порядки и тем более не разные О.
Вот если вы попытаетесь вызвать eval — тогда конечно случиться ой.
Вот если вы попытаетесь вызвать eval — тогда конечно случиться ой.
Нет существует вопросов, связанных со сборкой.Как динамическая типизация решает вопросы со сборкой? Или имеется в виду, что популярные языки с динамической типизацией чисто случайно оказываются интерпретируемыми?
А вообще понравилась идея автоматического вывода типов при инициализации переменной. Ведь на практике смена типа переменной (локальной) встречается не так часто, обычно если присвоили ей 0, то она будет целой до конца жизни, присвоили «foo» — будет строковой. И type hinting для параметров функций/методов — можем указать тип параметры и получим ошибку выполнения, если передан не этот тип или не его наследник, а можем не указывать и разбирать внутри.
В общем мне кажется, что как таковая динамическая типизация используется по большинстве случаев в одном сценарии — задаем тип при первом присваивании, а больше его не меняем. Но неиспользуемая возможность сменить тип во время выполнения стоит довольно дорого по ресурсам.
я сомневаюсь, что верно перевел этот кусок
там было написано — There are no build time issues at all.
там было написано — There are no build time issues at all.
но вроде бы оно.
видимо да, имеется в виду, что они, как правило, интерпретируемые :)
видимо да, имеется в виду, что они, как правило, интерпретируемые :)
лучше проблемы с билдом чем с рантайм багами — их (ошибки компилятора) как то легче находить
При «100% coverage» ничуть не сложнее.
Ну и что — у меня в Delphi тоже нет с этим проблем, зато куча профита от строгой типизации. Динамическая, кстати, тоже есть.
НЛО прилетело и опубликовало эту надпись здесь
Ничто не рассказывает об объекте, как его тип.
Я люблю IntelliSense и статическая типизация никогда не тормозила процесс разработки, как тормозит процесс разработки неизвестность со стороны компилятора, который не скажет что заработает, а что нет ещё до запуска приложения. В C# такое количество синтаксического сахара, что я просто не знаю как можно ещё быстрее разрабатывать. Так что посыл автора мимо кассы… :)
Я люблю IntelliSense и статическая типизация никогда не тормозила процесс разработки, как тормозит процесс разработки неизвестность со стороны компилятора, который не скажет что заработает, а что нет ещё до запуска приложения. В C# такое количество синтаксического сахара, что я просто не знаю как можно ещё быстрее разрабатывать. Так что посыл автора мимо кассы… :)
В C# нет срезов массивов. Это наверное единственное, что меня сильно печалит в плане сахара…
Во избежании недопонимания, я все равно в общем и целом полностью согласен с автором. Особенно при использовании ReSharper в студии — вообще кайф писать код.
НЛО прилетело и опубликовало эту надпись здесь
В каком плане срезов массивов?Наверное вот в таком.
>>> a = range(32)
>>> a
[0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 2
2, 23, 24, 25, 26, 27, 28, 29, 30, 31]
>>> a[5:25:3]
[5, 8, 11, 14, 17, 20, 23]</code>
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
Как быть без типов если я хочу перегрузить метод?
if typeof(arg) == StringType:
pass
elif typeof(arg) == IntType:
pass
…
pass
elif typeof(arg) == IntType:
pass
…
Ну как бы да, только во многих языках есть еще Duck Typing, и тогда просто проверять типы не оч хорошо. Лучше проверять поведение объекта, т.к. это дает большую гибкость и не ведет к привязке логики к конкретным классам, т.е. что-то типа:
if arg.respond_to?(:do_something)
# logic
elsif arg.respond_to?(:do_something_else)
# another logic
end
Что значит без типов? Типы то есть, просто динамические.
Пример на руби:
Пример на руби:
case my_var
when Integer
# my_var is an integer
when String
# my_var is a string
when Array
# my_var is an array
when some_other_object
# my_var equals to some_other_object
else
raise ArgumnentError, "fuck it"
end
По моему личному мнению — Ruby самый удобный язык из всех существующих! Никогда не возникло не одной проблемы с типизацией, только бы на нем и программировал, если бы была такая возможность!
хорошо, что вы поделились своим мнением и своим опытом. было бы здорово, чтобы вы рассказали, какие языки вы вообще знаете и какой у вас опыт, в какой области вы работаете и с насколько сложными задачами сталкивались.
Постоянно сталкиваюсь с несоответствиями типов в Ruby. Видимо количество проблем с типизацией у меня двойное — за себя и за вас. :-)
Функциональщик врывается в этот тред!
А если серьезно, то вот в haskell без строгой статической типизиции никуда. Это одна из важнейших «фич» языка. В C\C++ тоже — помогает продвинутой оптимизации компилятором.
И если уж говорить о TDD, то обьем тестов и количество их запусков, если уж на то пошло, резко сокращается при использовании статических типов, а это тоже уменьшает пресловутое время разработки, которым «питонщики» тыкают в нос «плюсовикам».
А вообще я за то чтобы решать задачи инструментами, подходящими для этих задач. Хотя вот я сейчас осваиваю питон и честно скажу, я скучаю по строгой типизации. Просто никак не могу избавиться от мысли: «а что если программист Вася передаст вместо списка просто обьект один». Да, я знаю, что это должна разруливать документация, и вообще я параноик. Но давайте будем честными, не все ее читают так внимательно :)
А если серьезно, то вот в haskell без строгой статической типизиции никуда. Это одна из важнейших «фич» языка. В C\C++ тоже — помогает продвинутой оптимизации компилятором.
И если уж говорить о TDD, то обьем тестов и количество их запусков, если уж на то пошло, резко сокращается при использовании статических типов, а это тоже уменьшает пресловутое время разработки, которым «питонщики» тыкают в нос «плюсовикам».
А вообще я за то чтобы решать задачи инструментами, подходящими для этих задач. Хотя вот я сейчас осваиваю питон и честно скажу, я скучаю по строгой типизации. Просто никак не могу избавиться от мысли: «а что если программист Вася передаст вместо списка просто обьект один». Да, я знаю, что это должна разруливать документация, и вообще я параноик. Но давайте будем честными, не все ее читают так внимательно :)
НЛО прилетело и опубликовало эту надпись здесь
+миллион
говнокод на яве и с++, сишарпе ничуть не реже, чем на PHP.
просто PHP имеет такую славу из-за низкого порога вхождения и ЗАМЕТНОГО количества говнокодеров на нем.
к примеру, у меня знакомый ковыряет банковские и другие софты на яве. чуть ли не все — полный ппц, простите мой французский, ибо пишутся людьми, которых нанимают за копеечку, по принципу «лишь бы работало».
да и вообще, Винда это пипец. я ни разу не видел виснущих серверов на фре. зато банкоматов с BSOD с установленной XP — полно, как и всяких других гаджетов.
а правильные руки прекрасно позволяют на голых сях писать без всякого ООП, кстати
так что если уж типизация — только си, только фря, только хардкор.
говнокод на яве и с++, сишарпе ничуть не реже, чем на PHP.
просто PHP имеет такую славу из-за низкого порога вхождения и ЗАМЕТНОГО количества говнокодеров на нем.
к примеру, у меня знакомый ковыряет банковские и другие софты на яве. чуть ли не все — полный ппц, простите мой французский, ибо пишутся людьми, которых нанимают за копеечку, по принципу «лишь бы работало».
да и вообще, Винда это пипец. я ни разу не видел виснущих серверов на фре. зато банкоматов с BSOD с установленной XP — полно, как и всяких других гаджетов.
а правильные руки прекрасно позволяют на голых сях писать без всякого ООП, кстати
так что если уж типизация — только си, только фря, только хардкор.
Есть одна неприятная ситуация, когда вместо списка передают строку, а она успешно обрабатывается как список символов.
Бывает очень увлекательно ловить такую багу.
Бывает очень увлекательно ловить такую багу.
Кстати, тут вообще спорно. Вот в haskell и D и C++ строка — это и есть неизменяемый список символов. Это еще одна вещь, которую я не понимаю в питоне. Вернее, понимаю, там же нет immutable и тогда бы все строки меняли, но по мне лучше было бы добавить это мощное средство (заодно константы бы можно было делать), чем плодить сущности. Опять же, тогда кортеж можно было бы как неизменяемый список определить.
Подход питона более практичен. Очевидно же, что представление строки в виде списка символов неоптималено ни по расходу памяти ни по скорости типичных алгоритмов. Питоновская строка только «похожа» на список, то есть она реализует почти те же интерфейсы, что и список. Отличия только в том, что елементами строки могут быть только символы, и строки неизменяемы. Но это только интерфейсы, внутренняя реализация абсолютно другая.
Один из интерфейсов строки — iterable. Именно это может привести к такой трудно обнаруживаемой ошибке.
def do_something(names):
for name in names:
do(name)
Предполагается, что вызывать будут в виде: do_something(['name1', 'name2'])
Если по ошибке вызвать: do_something('name'), то вызов прекрасно отработает, только
do() будет вызвано с 'n', 'a' и так далее.
Везде можно найти способ прострелить себе ногу.
Один из интерфейсов строки — iterable. Именно это может привести к такой трудно обнаруживаемой ошибке.
def do_something(names):
for name in names:
do(name)
Предполагается, что вызывать будут в виде: do_something(['name1', 'name2'])
Если по ошибке вызвать: do_something('name'), то вызов прекрасно отработает, только
do() будет вызвано с 'n', 'a' и так далее.
Везде можно найти способ прострелить себе ногу.
Можно занудой немного побыть? В питоне типизация строгая, это не js или php) Вы, наверное, по статической скучаете.
Меня в таких случаях чаще смущает даже не отсутствие типизации параметров, а отсутствие аналогов struct. В js это на редкость неудобно — передаешь пачку параметров объектом, и нет никакой толковой проверки — указаны ли все необходимые параметры. И если этот объект потом отдаётся дальше какому-то коллбеку, который попытается им воспользоваться невесть когда — отлаживать такое — сплошное издевательство. А если руками всё это проверять — куча маеты, учитывая, что колбек и, соответственно, набор нужных ему параметров может быть разным и тоже скармливаться в функцию параметром… Вот где начинаешь скучать по плюсовым шаблонам, в которых подобное решается элементарно. И тесты на такое писать несподручно — нужно кучу всего сделать чтобы коллбек вызвался.
Чем больше я зависел от юнит-тестов, тем меньше я зависел от надежности на основе типизации в Java или C++ (мои языки).
Еще бы. Да не охота вот их писать на те мелочи, от которых помогает типизация.
Между явой и питоном я выберу питон, но не потому что он динамически типизированный.
Привет, Промт, давно не виделись!
Ах думаю, ничего себе. ТДД, парное программирование и кто-то прям серьзно-присерьзно к этому относится, а не как к идеалу которому нужно стремиться.
Оказалось перевод, дядюшка Боб. Таких как он на планете еще человек 10 =)
Оказалось перевод, дядюшка Боб. Таких как он на планете еще человек 10 =)
Да, я тоже сначала удивился — ух, у человека все-все покрыто тестами…
И между-прочим хорошо, что эти 10 человек есть, как и то, что их всего 10.
В итоге все остальные пытаясь «стремиться к идеалу» всё-же покрывают тестами хоть что-то и хоть иногда советуются с коллегами перед принятием глупых решений. В итоге получается сильно лучше, а в крайности скатываться не надо.
В итоге все остальные пытаясь «стремиться к идеалу» всё-же покрывают тестами хоть что-то и хоть иногда советуются с коллегами перед принятием глупых решений. В итоге получается сильно лучше, а в крайности скатываться не надо.
На эту тему есть известная статья Брюса Эккеля, написанная как раз в то же самое время:
Bruce Eckel. «Strong Typing vs. Strong Testing» (archive), 02.05.2003.
Русский перевод из сборника Джоэла Спольски «Лучшие примеры разработки ПО»:
Брюс Эккель. «Сильная типизация против сильного тестирования» // «Лучшие примеры разработки ПО», 2007
Bruce Eckel. «Strong Typing vs. Strong Testing» (archive), 02.05.2003.
Русский перевод из сборника Джоэла Спольски «Лучшие примеры разработки ПО»:
Брюс Эккель. «Сильная типизация против сильного тестирования» // «Лучшие примеры разработки ПО», 2007
Считаю, что одно другому не мешает, а наоборот — дополняет.
Решил я тут на днях написать хорошой алгоритм решения задачи размена монет (там в комментах до сих пор лежит мой позорный тормозной код). Изначально написал на Racket (диалект Lisp) и был приятно удивлён скоростью работы кода — все варианты размена для 1000000 денег считаются за ~11 сек (666793341266850001 вариантов). При этом в целях отладки кеширование я реализовал в виде «декоратора», а код функции расчёта получился очень простым (исходник). Потом я написал менее гибкую, оптимизированную версию — чтобы добиться максимальной производительности (исходник): на сей раз вышло ~1.3 сек.
И для полного счастья я написал версию на Go. Результат ~0.7 сек.
На C не стал заморачиваться, т.к. нужно ещё искать реализацию Big Integer (unsigned long long'а не хватает), а версия на D совсем не порадовала быстродействием (компиляторы сырые).
Как видите, выигрыш у статически типизированного компилируемого языка оказался не так уж и велик. А всё потому, что в Racket используется JIT и оптимизирована хвостовая рекурсия. Притом, на написание кода на Racket (который знаю средненько) я потратил заметно меньше времени, чем на более привычном мне D и недавно изученном Go.
Думаю, выбор не должен быть в стиле «или статическая, или динамическая типизация». Языки первого типа обычно дают хорошую скорость работы кода и раннее выявление ошибок, а второго типа — более быстрое и лёгкое написание кода. Так что для embedded я выберу C, а для ПК — Racket для начальной разработки / Go при потребности ускорить.
Решил я тут на днях написать хорошой алгоритм решения задачи размена монет (там в комментах до сих пор лежит мой позорный тормозной код). Изначально написал на Racket (диалект Lisp) и был приятно удивлён скоростью работы кода — все варианты размена для 1000000 денег считаются за ~11 сек (666793341266850001 вариантов). При этом в целях отладки кеширование я реализовал в виде «декоратора», а код функции расчёта получился очень простым (исходник). Потом я написал менее гибкую, оптимизированную версию — чтобы добиться максимальной производительности (исходник): на сей раз вышло ~1.3 сек.
И для полного счастья я написал версию на Go. Результат ~0.7 сек.
На C не стал заморачиваться, т.к. нужно ещё искать реализацию Big Integer (unsigned long long'а не хватает), а версия на D совсем не порадовала быстродействием (компиляторы сырые).
Как видите, выигрыш у статически типизированного компилируемого языка оказался не так уж и велик. А всё потому, что в Racket используется JIT и оптимизирована хвостовая рекурсия. Притом, на написание кода на Racket (который знаю средненько) я потратил заметно меньше времени, чем на более привычном мне D и недавно изученном Go.
Думаю, выбор не должен быть в стиле «или статическая, или динамическая типизация». Языки первого типа обычно дают хорошую скорость работы кода и раннее выявление ошибок, а второго типа — более быстрое и лёгкое написание кода. Так что для embedded я выберу C, а для ПК — Racket для начальной разработки / Go при потребности ускорить.
Вам полноценный Big Integer не нужен, достаточно пары unsigned long long-ов. Это вроде вообще легко сделать, особенно учитывая, что деление-то не особо вам нужно, и что гдето в MS версии stl есть реализация unsigned long long (64 бит) для 32 битной машины. Просто скопипастить код надо :)
Можно исходники для D личкой? Хочу отдебажить, где проседание про производительности.
НЛО прилетело и опубликовало эту надпись здесь
Типизация?
Не, не слышал.
Только ассемблер, только хардкор!
Не, не слышал.
Только ассемблер, только хардкор!
Будущее за выводом типов имхо, и ошибки ловит и явно типы писать не нужно в большинстве случаев. В то же время тип известен на этапе компиляции — плюс к производительности.
Брошу свои десять копеек, из опыта.
1. Статическая типизация.
— CUDA это C/C++ и жесткая типизация, во-первых потому, что разделяемой памяти мало (16 или 48 КБ), начинаешь как в старые времена думать, что массив 16-битных величин лучше чем 32-битный. В старых версиях (до 1.3) double обрабатывается сильно дольше, чем float.
— Приходилось писать плагины для photoshop и Ogre3d — здесь только С… Хотя я бы рассмотрел вариант питона :-)
— Обработка видео в реальном времени — детектирование/распознавание объектов. Нужно обработать HD кадр за 10 мс, пока на PC, а потом скорее всего на ARMe — здесь только C/C++ (причем без всяких там STL и прочих смарт поинтеров)
Java. Для той же задачи, для которой писали плагины для Ogre, нужна была небольшая база из четырех табличек. Пытались на QT(дабы соблюсти идейную чистоту C++) — на Java оказалось сильно проще.
2. Динамическая типизация. Про web писать не буду — К.О. уже все сказал…
— Бизнес логику в учетных и ERP системах пишем на 1С, начинали с 7.1, сейчас 8.2. ИМХО, это лучшая платформа для erp, на практике сравнивали с SAP/R3, Oracle E-Business Suite, Sun Account, Site Line, Axapta…
— Прототипирование математических алгоритмов (тех самых, которые потом переписываются на C/CUDA) пишем в Matlab, и также, имхо, это лучшая система для разработки прототипов математических алгоритмов.
— Простенькие утилитки пишу на perl/python для разных задач разные библиотечки, так wxPython очень нравится для очень быстрого создания GUI, а с ImageMagick удобнее через perl(а может просто привычнее), с другой стороны, некоторые функции работы c изображениями мне нравятся в PIL…
Так что, как говорится, у каждой церкви свой Будда, а для каждого класса задач свой язык.
1. Статическая типизация.
— CUDA это C/C++ и жесткая типизация, во-первых потому, что разделяемой памяти мало (16 или 48 КБ), начинаешь как в старые времена думать, что массив 16-битных величин лучше чем 32-битный. В старых версиях (до 1.3) double обрабатывается сильно дольше, чем float.
— Приходилось писать плагины для photoshop и Ogre3d — здесь только С… Хотя я бы рассмотрел вариант питона :-)
— Обработка видео в реальном времени — детектирование/распознавание объектов. Нужно обработать HD кадр за 10 мс, пока на PC, а потом скорее всего на ARMe — здесь только C/C++ (причем без всяких там STL и прочих смарт поинтеров)
Java. Для той же задачи, для которой писали плагины для Ogre, нужна была небольшая база из четырех табличек. Пытались на QT(дабы соблюсти идейную чистоту C++) — на Java оказалось сильно проще.
2. Динамическая типизация. Про web писать не буду — К.О. уже все сказал…
— Бизнес логику в учетных и ERP системах пишем на 1С, начинали с 7.1, сейчас 8.2. ИМХО, это лучшая платформа для erp, на практике сравнивали с SAP/R3, Oracle E-Business Suite, Sun Account, Site Line, Axapta…
— Прототипирование математических алгоритмов (тех самых, которые потом переписываются на C/CUDA) пишем в Matlab, и также, имхо, это лучшая система для разработки прототипов математических алгоритмов.
— Простенькие утилитки пишу на perl/python для разных задач разные библиотечки, так wxPython очень нравится для очень быстрого создания GUI, а с ImageMagick удобнее через perl(а может просто привычнее), с другой стороны, некоторые функции работы c изображениями мне нравятся в PIL…
Так что, как говорится, у каждой церкви свой Будда, а для каждого класса задач свой язык.
> Я насмехался над smalltalk'ерами, кто ныл о потери гибкости.
И ныл о потере надёжности в ответ. Да, холивары они такие.
И ныл о потере надёжности в ответ. Да, холивары они такие.
см также
habrahabr.ru/blogs/arbeit/88443/
habrahabr.ru/blogs/arbeit/88443/
C 2003 года много воды утекло, да и спорить с одним из классиков сложно :) Но так как уже год 2012 и статически типизированные языки все еще имеют место быть, то, как видно смена не пришла. БОльшая часть людей не настолько фанаты TDD, как Роберт Мартин, и покрытие кода 100% (или близко к тому) есть наверное у единиц. Поэтому строгая типизация все еще спасает (как раз таких как я, которые настолько ленивы что не могут позволить себе работать быстрее из-за того что покрытие проекта тестами ни 100%). Да и есть такой язык уже — Scala, который дает мощь статически типизированного языка, но выглядит, как динамически типизированный.
Одумайтесь люди.
Мой опыт показывает, что когда проект более-менее большой (1кк+ строк кода) и монолитный (новый функционал добавляется не плагинами) время разработки крайне мало зависит от ЯП, а по этому нет смысла для таких проектов использовать динамические ЯПы.
Автор банально путает кислое с длинным, говоря, что юнит-тесты заменяют проверку типизации. Отсутствие ошибок типизации гарантирует отсутствие определенных ошибок и корректность программы по некоторым критериям, особенно в безопасных языках (C++ к ним не относится). Юнит-тесты позволяют говорить всего-навсего о некоторой уверенности в отсутствии явных ошибок и никогда ничего не доказывают, если не покрывает множество возможных значений полностью, что нереально. По сему языки с динамической типизацией просто не подходят для программ, для которых надежность является основным или хотя бы важным критерием. Это, конечно, не означает, что они плохи и не могут быть с успехом использованы для решения определенных задач.
Старьё. Потом пришёл автоматический рефакторинг, и преимущества статической типизации опять вылезли во весь рост.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Придут ли на смену статически типизированным языкам языки с динамической типизацией?