LINUX.ORG.RU

нужно, но не всем

Valeg ★★★
()

очень даже нужно

TDrive ★★★★★
()
Ответ на: комментарий от Virtuos86

А ещё Python 2.7! И какие там версии питона ещё, а то мало как-то.

lexazloy
()
Ответ на: комментарий от sT331h0rs3

Чукча не писатель... P.S. Для Ъ - это краткая выдержка для тех, кому лень переходить на другой сайт с лор-а? Или?

Sorcus
() автор топика
Ответ на: комментарий от Virtuos86

Ненужно, есть Python 3.6.

Python не очень хорошо продуман. Многие важные вещи в нем отсутствуют, либо сделаны плохо(таким образом, что ими неудобно пользоваться).

Я недавно уже приводил один пример вот здесь. Другой пример — это отсутствие даже базовой поддержки паттерн-матчинга.

В Ruby паттерном может быть любой объект, который имплементирует метод ===. Такой объект можно использовать в case, либо другим способом — например, в Enumerable#grep.

В Python для этого придется городить вереницу ифов.

Anatolik ★★
()

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

pacify ★★★★★
()
Ответ на: комментарий от pacify

Согласен. Если бы разработчики Python развивали вторую ветку, вместо создания нового языка, сообщество не было бы так фрагментировано.

Anatolik ★★
()
Ответ на: комментарий от Anatolik

Case в Питоне вообще нет, поэтому и зачатков сопоставления с образцом нет, а grep это типичная перловка, которой в Питоне точно никогда не будет. И чем grep лучше select? А так-то все «ненужно» — не более чем набросы, не стоит воспринимать их всерьез :).

Virtuos86 ★★★★★
()
Ответ на: комментарий от TDrive

Не позорюсь. Использование языка без проверки типов при компиляции - отличный способ продырявить себе ноги, отстрелить яйца и заработать рак мозга. Теперь твоя очередь не позориться.

hateyoufeel ★★★★★
()
Ответ на: комментарий от hateyoufeel

Использование языка без проверки типов при компиляции - отличный способ продырявить себе ноги, отстрелить яйца и заработать рак мозга.

Только если твое IQ меньше чем у улитки.

TDrive ★★★★★
()
Ответ на: комментарий от TDrive

Только если твое IQ меньше чем у улитки.

Отлично, то есть у 95% программистов на Ruby IQ меньше чем у улитки. Там и запишем. Что ещё скажешь?

hateyoufeel ★★★★★
()
Ответ на: комментарий от hateyoufeel

Еще скажу что ты не понял о чем я написал, что в принципе дает объяснение твоего хейта динамической типизации.

TDrive ★★★★★
()
Ответ на: комментарий от TDrive

объяснение твоего хейта динамической типизации.

Почему все фанаты ущербных технологий любую критику объясняют вот этим? Больше аргументов нет?

hateyoufeel ★★★★★
()
Ответ на: комментарий от kachan

А кто запрещает проверять типы в нужных местах?

Этим должен заниматься компилятор, например. Во время компиляции.

Ведь редко где это нужно.

Проверка корректности кода редко где нужна. Ок.

hateyoufeel ★★★★★
()
Ответ на: комментарий от kachan

Проверка корректности кода и проверка типов немножко разные вещи.

В каком месте? В случае со статически типизированными языками с достаточно мощной системой типов (хотя бы уровня C++ с концептами и прочими плюшками) с помощью этих самых типов программист описывает некие инварианты относительно кода, которые потом проверяются компилятором. Более мощные системы типов позволяют точнее описывать свойства программ. Чем это отличается от проверки корректности?

hateyoufeel ★★★★★
()
Последнее исправление: hateyoufeel (всего исправлений: 1)
Ответ на: комментарий от hateyoufeel

Тем что проверка корректности кода - общее понятие, а проверка типов более узкое, которое входит в первое. Обобщить, а потом предъявлять «высосаные из пальца» аргументы можно до безконечности. Без конкретики, звучит не более чем вброс.

kachan ★★
()
Последнее исправление: kachan (всего исправлений: 1)
Ответ на: комментарий от kachan

предъявлять «высосаные из пальца» аргументы можно до безконечности

Ну так перестань сосать свой «палец» и напиши что-нибудь осмысленное уже.

hateyoufeel ★★★★★
()
Последнее исправление: hateyoufeel (всего исправлений: 1)
Ответ на: комментарий от hateyoufeel

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

kachan ★★
()
Последнее исправление: kachan (всего исправлений: 1)
Ответ на: комментарий от kachan

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

Какой именно мой аргумент?

у тебя походу и сборщик мусора - вселенское зло.

А ещё я детей ем.

hateyoufeel ★★★★★
()
Последнее исправление: hateyoufeel (всего исправлений: 1)
Ответ на: комментарий от hateyoufeel

Почему все фанаты ущербных технологий любую критику объясняют вот этим? Больше аргументов нет?

То что ты пишешь это не критика.)

TDrive ★★★★★
()
Ответ на: комментарий от TDrive

Отсутствие проверки типов на этапе компиляции приводит к большему числу ошибок и увеличивает время разработки в итоге из-за затрат на поиск ошибок и написание лишних тестов.

^--- если это не критика, то я не знаю что чувак с IQ улитки примет за критику.

hateyoufeel ★★★★★
()
Ответ на: комментарий от hateyoufeel

Отсутствие проверки типов на этапе компиляции приводит к большему числу ошибок и увеличивает время разработки в итоге из-за затрат на поиск ошибок и написание лишних тестов.

Почему у нас в мире (в реальном мире, а не твоих фантазиях) такое большое количество популярных языков с динамической типизацией если на них дольше писать код?

TDrive ★★★★★
()
Ответ на: комментарий от hateyoufeel

то есть ты сейчас на полном серьёзе собираешься доказывать что писать код на C, C++, Java быстрее чем на php, python, ruby, js... ?

TDrive ★★★★★
()
Ответ на: комментарий от TDrive

то есть ты сейчас на полном серьёзе собираешься доказывать что писать код на C, C++, Java быстрее чем на php, python, ruby, js... ?

Я сейчас хочу сказать, что долгоживущие достаточно изолированные системы почему-то никто на php, python, ruby или js не программирует, и что, скорее всего, одной из причин (забудем на секунду про абсолютно ублюдочную производительность указанных тобой языков) является проблема с выявлением дефектов в коде, вызванная динамической типизацией. Т.е. эти языки распространены только в вебе, где для накатывания обновления достаточно ткнуть пару кнопок.

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

hateyoufeel ★★★★★
()
Последнее исправление: hateyoufeel (всего исправлений: 1)
Ответ на: комментарий от hateyoufeel

Я сейчас хочу сказать, что долгоживущие достаточно изолированные системы почему-то никто на php, python, ruby или js не программирует

дай определение «долгоживущий достаточно изолированной системы»

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

ты 5 минут назад был полностью уверен в этом а сейчас уже «скорее всего» ?) подождем еще минут 10?)

Т.е. эти языки распространены только в вебе, где для накатывания обновления достаточно ткнуть пару кнопок.

обновления тут вообще каким боком?)

TDrive ★★★★★
()
Ответ на: комментарий от TDrive

дай определение «долгоживущий достаточно изолированной системы»

Покажи мне, например, спутник, на котором крутится javascript.

ты 5 минут назад был полностью уверен в этом а сейчас уже «скорее всего» ?) подождем еще минут 10?)

Лично ты с IQ улитки можешь ждать сколько угодно.

обновления тут вообще каким боком?)

Хотя скорее у тебя IQ баклажана. Это один из факторов, влияющих на затраты в рисковых ситуациях, вызванных твоим бажным кодом. Если твой говносайтик на PHP упадёт из-за ошибки в коде, ты его можешь поднять за 5 минут обратно. Если георазведочное оборудование в тайге с медведями внезапно заглючит, твою жопу скорее всего порвут на британский флаг, потому что дебажить на месте прошивку и пытаться её обновить никто не будет. А если глючить начнёт прошивка в контроллере тормозной системы автомобиля, тебя, возможно, ещё и посадят.

hateyoufeel ★★★★★
()
Последнее исправление: hateyoufeel (всего исправлений: 1)
Ответ на: комментарий от hateyoufeel

Во всем что ты написал большую роль играет скорость и ограниченность ресурсов, а не статическая типизация.

TDrive ★★★★★
()
Ответ на: комментарий от hateyoufeel

И уж тем более не скорость разработки.

TDrive ★★★★★
()
Ответ на: комментарий от TDrive

Во всем что ты написал большую роль играет скорость и ограниченность ресурсов, а не статическая типизация.

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

У тебя, как я понимаю, весомых аргументов нет вообще? Черепная коробка баклажанной икрой заполнена?

hateyoufeel ★★★★★
()
Ответ на: комментарий от hateyoufeel

Вычислительных ресурсов - скорее нет, железо сейчас в большинстве случаев дешёвое.

На спутниках жесткие ограничения по потреблению энергии и охлаждению. И если есть возможность продлить работу спутника на несколько лет ценой пары месяцев е**ли программистов то этим глупо не воспользоваться.

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

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

У тебя, как я понимаю, весомых аргументов нет вообще? Черепная коробка баклажанной икрой заполнена?

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

TDrive ★★★★★
()
Ответ на: комментарий от TDrive

На спутниках жесткие ограничения по потреблению энергии и охлаждению.

И что? Как это относится к коду, который там будет выполняться?

Человеческие ресурсы тут вообще роли не играют,

Оплата работы человеков - это одна из самых жирных статей расходов в случае R&D.

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

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

А за «нанять пару программистов» я тебя лично буду бить копией The mythical man-month.

Статическая типизация не панацея

У тебя руби последние мозги выел? Никто не утверждает, что статическая типизация - панацея. Статическая типизация позволяет снизить расходы на разработку (не на написание кода!) и снизить вероятность рисков при правильном применении. Точка.

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

Упоротые фанаты динамических типов и других недотехнологий (привет Iron_bug!) почему-то постоянно повторяют эту мантру. На практике же оказывается, что косячат все, абсолютно все.

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

Меня задевает, что какой-нибудь нуб может увидеть твои бредни, заработать рак мозга и стать рубистом. Этого следует избегать.

hateyoufeel ★★★★★
()
Последнее исправление: hateyoufeel (всего исправлений: 1)
Ответ на: комментарий от hateyoufeel

языка без проверки типов при компиляции

Руби скриптовой язык. Хотя не знаю, компилится ли jruby. Сам руби не юзаю, не увидел, в чём его полезность. И да, динамическая типизация рулит при прототипировании. Ну, а статика в реализации окончательного решения.

Hertz ★★★★★
()
Ответ на: комментарий от hateyoufeel

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

kachan ★★
()
Ответ на: комментарий от Hertz

Руби скриптовой язык. Хотя не знаю, компилится ли jruby.

Это детали реализации. В любом случае, даже mruby не выполняет скрипт построчно, а компилирует его в некое внутреннее представление.

динамическая типизация рулит при прототипировании.

Citation needed.

hateyoufeel ★★★★★
()
Ответ на: комментарий от kachan

Так где в этих всех системах можно юзать руби, или кто его туда пихает?

Что значит «можно юзать руби»?

Просто интересно, я могу стрельнуть себе в ногу там где нужна статическая типизация, но при этом язык для этого и не предназначен.

Разве есть языки, предназначенные для стрельбы в ногу?

ты распинаешся об спутниках или близкой работе с железом.

Спутники - это был пример области с высокой стоимостью рисков. Можешь взять любую другую. Про близкую работу с железом я вообще не говорил ни слова. Ты это видимо вытащил оттуда же, откуда мою мнимую нелюбовь к GC.

hateyoufeel ★★★★★
()
Последнее исправление: hateyoufeel (всего исправлений: 1)
Ответ на: комментарий от hateyoufeel

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

kachan ★★
()
Последнее исправление: kachan (всего исправлений: 1)
Ответ на: комментарий от kachan

Язык никогда для этого не был предназначен

Никогда не был предназначен для чего?

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

Если под выстрелом в ногу имеется ввиду непреднамеренное внесение ошибки в код, то есть дохрена способов.

hateyoufeel ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.