- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
public static int activeThreadsCount(List<Thread> threadList)
{
int i = 0;
for (Thread thread : threadList)
{
i += thread.isAlive() ? 1 : 0;
}
return i;
}
Нашли или выдавили из себя код, который нельзя назвать нормальным, на который без улыбки не взглянешь? Не торопитесь его удалять или рефакторить, — запостите его на говнокод.ру, посмеёмся вместе!
+71
public static int activeThreadsCount(List<Thread> threadList)
{
int i = 0;
for (Thread thread : threadList)
{
i += thread.isAlive() ? 1 : 0;
}
return i;
}
Кстати, а зачем вообще кому-то нужно считать стопнутые треды?
Javablyadee sosnulee
Впрочем, во многих других языках под JVM этой проблемы нет
--------
Самое смешно тут знаете что?
Что понять степень пиздеца можно только попробовав языки с лямбдами.
А без этого так и будешь вот так писать и совершенно не понимать что же тут плохого.
Всё же, что в рассматриваемом ГК такого плохого?
Вот если у нас есть какая-то коллекция, хранящая беспорядочные знания (базы данных/большие данные/экспериментальный набор чисел), из которой мы хотим выжать суть и не знаем, как и как долго мы (или вообще кто-то другой) будем это делать, то логично определить над ней map/reduce/filter и пользоваться лямбдами, не вырисовывая тонны for'ов на каждый случай.
В рассматриваемом примере мы имеем дело скорее с единичными случаями использования. Пробежались по тредам - посчитали живые, пробежались по тредам - что-то запустили, пробежались ещё раз и выпилили лишнее, и всё. Три раза на весь класс, причём всё, что могло стать лямбдой (x => x.isAlive() ? 1 : 0), находится в нашем коде.
В итоге не тянем в код лишние абстракции; (наверное) не заставляем компилятор разворачивать лямбды, чтобы код не тормозил; не плодим лишних методов, которыми будут пользоваться один раз ради того, чтобы переписать три строки в две.
>>не заставляем компилятор разворачивать лямбды, чтобы код не тормозил
давайте не заниматься предоптимизацией) Писать код нужно красиво и малобуквенно, и пока не доказано что лямбда тут боттлнек -- трогать её не нужно
А вот тут надо задуматься: сколько же времени мы тратим на понимание, обдумывание, планирование задачи, и сколько собственно на набор кода.
Подумать и не тащить лямбды везде где ни попадя. Или громоздкость анонимных классов кому-то мешает набирать по 1000 строк в день?
Да по мне так и наоборот хорошо - были б они короче, задачу обязательно решили бы лямбдой.
---
ps: лучше всего писать на машинных кодах. Любое действие там требует определенного обдумывания, и никто не будет лепить ненужное.
Вон в C# есть LINQ, и AssParallel, можно выбирать живые потоки многопоточно!
> лучше всего писать на машинных кодах. Любое действие там требует определенного обдумывания
Хм. Мне и в ЯВУ, и в русском языке для написания какого-либо текста требуется определённое обдумывание. ЧЯДНТ?
У вас в компании фильтрацией коллекций занимается отдельный программист?
Или может быть Вам никогда не приходилось заниматься фильтрацией коллекций?
Или Вы фильтровали коллекции будучи джуниором, а после Вас повысили и теперь Вам больше не нужно фильтровать коллекции?
>>ЧЯДНТ?
Все так. Я лишь довел до абсурда Ваш прекрасный аргумент о том что синтаксическая соль ввиде отсутствия лямбд это "наоборот хорошо" :)
Замечательный демагогический приём.
>Или может быть Вам никогда не приходилось заниматься фильтрацией коллекций?
Я же сказал типичные. Какие задачи типичны? Сколько процентов от всей работы по написанию кода составляет фильтрация?
Это прекрасный прием, так как фраза "Хорошо что язык FOO не умеет BAR: это заставляет думать" не заслуживает другого ответа)
>>Сколько процентов от всей работы по написанию кода составляют такие задачи?
Я не считал.
А сколько процентов от работы занимает написание switch? Думаю процентов 10. Давайте выкинем switch из языка.
... подумал Гвидо. И выкинул.
Какой нахер паттерн матчинг, в питоне системы типов-то нормальной нет для этих целей
Наверно Василий это видел, а тут к слову пришлось - вот и написал неявным зелёным.
Давайте! Вы поможете мне?
>А сколько процентов от работы занимает написание switch?
Я стараюсь его не использовать в своем коде вообще.
В том виде, в котором он есть сейчас это уродский и бесполезный оператор. К тому же NPE-опасный.
----
>> К тому же NPE-опасный.
што?
К этому сахарку у меня тоже имеются претензии. Но вы слишком быстро скачете с одной темы на другую.
Давайте сначала разберемся со свищом и выпилим его из жабы.
>што?
Вы точно пользовались этим оператором?
Да в общем уже не скачу. Если Вы не пользуетесь чем-то постоянно, то это не нужно. Я уже понял:)
>>Вы точно пользовались этим оператором?
Вы точно используете слова по их прямому назначению?
Нарушена причинно-следственная связь.
Если я чем-то не пользуюсь, то может я перестал, по той причине что удобно воспользоваться им невозможно.
А если чем-то нельзя нормально воспользоваться - оно в принципе не нужно.
http://ideone.com/uxY7XB
Нужно пример приводить, или так поймете?
Тот факт что java не форсит Вас обойти все значения енума в свиче никоим образом не означает что он "NPE-небезопасный". И вообще: визитор Вам в помощь.
>Нужно пример приводить, или так поймете?
Boolean. Но тут опасен не сам if, а авто(ан)боксинг.
А вот от него-то как раз много проблем и непоняток.
Причем тут if, absolut?!
Из двустволки в жопу.
Для кого-то они составляют дохуя %. Остальные по серверным без окон сидят.
В каком-то то ли встроенном, то ли стандартном де-факто xml парсере форыч для подузлов и не поддерживается, самое интересное, что жаваблядки это еще и защищают.
Единственная его реальная проблема - большое количество программистов низшего класса, которые пишут отвратительный код и из-за которых Java и считают медленной и жрущей память.
На самом деле в джаве много печалек, и исправляют их крайне медленно (это и Блох признает), но просто на момент появления джавы никто и подумать не мог что это будут печальки.
Примеры:
* Даты (исправлено в 8)
* Отсутствие средств для построения контрактов (исправлено в JSR 305, не уверен что он вошел в восьмерку)
* readObject / writeObject
* Override аннотация (а должно быть ключевым словом)
* Классы, поля и методы по-умолчанию не final
* Нет пропертей (как в C#)
----
С некоторой натяжкой можно пожалеть что нет невиртуальных методов и еще кое-о-чем)
-------
Вот теперь просто интересно как Вы будете троллить
С этим действительно было плохо. Тем не менее, это не ошибка дизайна языка, а ошибка дизайна api.
> Отсутствие средств для построения контрактов
Можно конкретнее? Вам недостаточно assert'ов и нужны пост проверки и инварианты?
> Override аннотация (а должно быть ключевым словом)
Не должно. Когда Java создавалась, то была идея не делать override вообще, ибо все методы все равно виртуальные. Его добавили уже потом в виде аннотации, что позволяет не указывать её.
>readObject / writeObject
Не очень понимаю о чем вы
> Классы, поля и методы по-умолчанию не final
Это сложно назвать минусом, все зависит от специфики языка. В случае Java, ИМХО, но все сделали правильно, ибо final - просто договоренность, не более.
>Нет пропертей
А вот это точно. Не понимаю, почему до сих пор не сделали их. Они прекрасно реализуются на уровне компиляции, без нарушения совместимости.
От себя добавлю: null. Вот чего уж точно не должно было быть в Java
>Можно конкретнее? Вам недостаточно assert'ов и нужны пост проверки и инварианты?
Не достаточно так как asserts не проверяются статически. Посмотрите на этот JSR, там много прекрасного. В частности:
* Nullable/NotNull: это решает проблему nullов и избавляет от NPE: Тоесть Вы всегда знаете может вернуть метод нул, или не может. И если может, то проверяете результат на нул (иначе любой статический анализатор Вас отловит). Больше не нужно проверять на null все подряд или ловить NPE. Скажу еще что такие же аннотации были сто лет как у гугла и у JetBrains, хорошо что нынче это стандарт.
* ThreadSafe (и unsafe, соответственно). И в effective Java и в concurrency in java сказано что лучше всего явно писать является-ли метод потокобезопасным или нет. Наконец можно делать это явно!
* Closes (или как-то так): значит что метод получая дескриптор его закрывает: статический анализ покажет Вам если Вы забыли закрыть дескриптор: это круто.
* ShouldCallParent: когда Вы оверрайдите папин метод не всегда понятно нужно ли делать super. Так вот теперь можно аннотацией явно это сказать и анализ и IDE вам подскажут если нарушите контракт
* И много-много-много всего
>>Его добавили уже потом в виде аннотации, что позволяет не указывать её.
Его добавили ввиде аннотации чтоб сохранить обратную совместимость. Совершенно уродски получилось: final -- ключевое слово, а override -- нет. Понятное дело что Override надо _всегда_ писать, иначе родитель молча поменяет имя метода, а вы этого и не узнаете.
продолжение следует
ИМХО, конечно, но кроме assert'ов и require в Java больше ничего из КП не нужно. Просто потому, что все остальное лучше писать в unit-тестах.
>Nullable/NotNull
>ThreadSafe
В Java 8 появились type annotations, в том числе и вышеупомянутые.
>Closes
Чем это лучше try with resources?
И опять же, имхо, но освобождение ресурса "где-то там" не хорошая практика.
> Его добавили ввиде аннотации чтоб сохранить обратную совместимость
>Добавили, чтобы сохранить обратную совместимость
Вовсе нет, его добавили, потому, что было море воплей из-за того, что люди забывают есть ли такой метод у предка или нет, в результате чего возникает неожиданное поведение
Найти ошибку статически лучше, чем найти её динамически. Во всяком случае в толстом энтерпрайзе.
>>Чем это лучше try with resources?
Вы видимо не поняли. Есть метод doAll(InputStream stream): вопрос: этот метод закроет стрим сам или нужно его вручную закрывать? Ответ таится в аннотации.
>>И опять же, имхо, но освобождение ресурса "где-то там" не хорошая практика.
Вообще -- да. Лучше закрывать там же, где и открыл.
>>Вовсе нет,
Блин) Конечно его добавили именно из-за воплей но сделали его не ключевым словом а аннотацией именно ввиду обратной говносовместимости (как это часто бывает в IT). Будь он в джаве изначально -- был бы ключевым словом.
Лучше. Но КП не гарантирует вам этого, просто потому, что не все случаи можно проверить статически. Именно поэтому assert и require - достаточно.
>вопрос: этот метод закроет стрим сам или нужно его вручную закрывать?
Здесь не аннотации нужны, а договоренность, что нельзя освобождать чужие ресурсы. А кто не понимает, тому ломать пальцы.
>Будь он в джаве изначально -- был бы ключевым словом.
Здесь согласен. Но увы и ах - тяжелое бремя обратной совместимости
Начался мой любимый аргумент: "%FOO не решает всех проблем, потому %FOO не нужен".
Можно сказать что статическая типизация так же не проверяет все случаи, потому она тоже не нужна (собссно питонисты так именно и говорят).
Конечно же assert и require - *не* достаточно потому что увидеть ошибку в момент её написания в IDE куда лучше чем поймать ее тестом.
>> А кто не понимает, тому ломать пальцы.
Представим себе такой метод:
и варианты его использования с ручным закрытием
И вариант, за который Вы предлагаете ломать пальцы:
Какой лучше?)
В 90% случаев ресурсы и правда лучше закрывать там же, где их открыли. В остальных 10% (как в приведенном примере) это не так. Для разграничения случаев и были введены аннотации.
Все верно, в данном случае именно так. Зачем эти полумеры, которые лишь усложнят язык? У нас есть assert'ы, есть unit- тесты - используйте.
> статическая типизация так же не проверяет все случаи, потому она тоже не нужна
Утрируете. Статическая типизация проверяет значительно больше случаев, чем может проверить КТ. Кроме того, у неё есть еще и приятный бонус - она значительно упрощает процесс написания кода и заставляет продумывать дизайн. Чтобы убедиться, достаточно посмотреть в сторон javascript.
>питонисты говорят
Эту братию вообще слушать не стоит, они слишком помешаны на своем божественном языке.
>Какой лучше?)
Вот этот:
try(InputStream stream = new FileInputStream("....)){
User user = eadUserFromStream(stream);
}
>отсюда еще IOException полетел
А во втором случае он, конечно же, не полетит
>В остальных 10%
лучше использовать try-with-resources
with для чего?
Это волшебные методы которые вызываются при сериализации/десериализации. Куда лучше было бы сделать их методами интерфейса или помечать аннотациями. Плохо завязываться на волшебное имя. Почитайте Effective Java, там Блох как раз приводит их в пример как ошибку своей молодости.
>>ибо final - просто договоренность, не более.
Извините что я опять с Блохом: "проектируйте наследование явно или явно запрещайте его". Тоесть в Идеале нужно или явно написать в доке "мой класс можно расширять, вот эти методы можете переписать". Или надо явно запретить переписывание методов (тоесть вручную все сделать final). Иначе какой-нибудь лунь переопределит метод, нарушит принцип подстановки Лискоу и создаст мостра с неясным поведением. Потому лучше всегда писать final. Но можно сойти с ума. Так что было бы лучше если бы:
* Все методы и классы по-умолчанию были-бы final (хочешь чтоб от тебя наследовались? Явно пометь метод как overrridable)
* Все поля были бы final (надеюсь не нужно объяснять почему final поля, устанавливаемые в конструкторе, уменьшают количество состояний и делают класс более понятным, предсказуемым и надежным чем не final поля с мутаторами?)
>> null. Вот чего уж точно не должно было быть в Java
Ну сам по себе null не виноват: на что-то же должен поинтер указывать? Но проблема в том что надо делать ОЧЕНЬ четкое разделение между Nullable и не Nullable переменными.
Тоесть чтоб нельзя было написать так: i = 1 + myVarThatMayBeNull, чтоб такое не скомпилировалось, чтоб компилятор заставил тебя явно проверить что там не nul..
Вот приснопамятный JSR 305 это конечно еще не так круто, но уже шаг в правильную сторону.
Ах вот о чем вы. Как по мне, их нужно было сделать не интерфейса, но встроить в Object вместе с toString.
>Effective Java
Читал. С тех пор не рекомендую её к прочтению никому. Разве что в ознакомительных целях.
> Потому лучше всегда писать final.
Не согласен. Его стоит писать либо в случае переменных, либо в случае, когда переопределение метода нанесет явный ущерб поведению. Последний случай вообще лучше делать не через final, а через объявление метода приватным
>Ну сам по себе null не виноват: на что-то же должен поинтер указывать?
На null, конечно. Вот только в Java их нет, здесь только ссылки. А потому, от него одни проблемы
> Но проблема в том что надо делать ОЧЕНЬ четкое разделение между
Нет. Достаточно сделать optional, либо ввести условие - наличие 0-значения для типа.
Почему? Отличная книга.
>>когда переопределение метода нанесет явный ущерб поведению.
Любое переопределение всегда может нанести ущерб т.к. нет гарантий что наследник понимает контракт так как Вы его явно нигде не описали так как не планирвоали что метод будут оверрадить)
>>а через объявление метода приватным
Особенно это хорошо когда кто-то дергает его снаружи.
>>На null, конечно. Вот только в Java их нет, здесь только ссылки. А потому, от него одни проблемы
Во-первых в джаве они называются именно что указатели. Как они называются в других языках -- не важно. Во-вторых что вместо нула-то сделать?
>>Достаточно сделать optional, либо ввести условие - наличие 0-значения для типа.
Не очень понял, объясните пожалйста
Потому, что последнее издание устарело на 7 лет. Потому, что многие примеры там либо тривиальны, либо настолько специфичны, что встретиться с ними в реальной жизни очень сложно. Кроме того, могу ошибаться, но по моему именно в этой книге Блох предлагал реализовывать синглтон через перечисления, что вообще ужасно.
>Любое переопределение всегда может нанести ущерб
Просто нужно проектировать объектную модель с учетом того, что ей будет пользоваться кто-то кроме самого разработчика.
> Особенно это хорошо когда кто-то дергает его снаружи.
Если кто-то дергает приватный метод снаружи, то я даже жалеть его не буду, ибо сам дурак.
Если же метод должен быть неприватным и разработчик не смог сделать его безопасным, то пусть ставит final, здесь да, никак иначе.
>Во-первых в джаве они называются именно что указатели
Знаю, досадное недоразумение. А еще некоторые Java-программисты называют анон-функции замыканиями, но это не значит что нужно так делать. Если следовать правильной терминологии, то, с учетом семантики, это именно ссылки.
> объясните
>optional
Можно "оборачивать" все ссылочные типы в некий контейнер (монаду), который в зависимости от того есть есть ли в нем что-то (объект), либо нет (null) принимает значения Some и None соответственно. Не обязательно делать именно контейнер, можно просто сделать у Object'а метод, например, isNull.
Кстати, в Java 8 Option добавили. Жаль, но null все же остается.
> 0-значения для типа
Как 0 для чисел, так и некое дефолтное значение для классов. Вариант с optional мне нравится больше.
А в чем разница?
Замыкание (Closure) - возможность внутри анонимной функции обращаться к контексту, в котором она была создана.
Лямбда - красивый способ записи анонимных функций
Ээ да ну? Да и по сути они - ссылки, тк допускают только присваивание.
В Java с этим действительно путаница. Все связано с тем, что
NullPointerException, но при этом
Reference types
Поэтому называют и так и так.
Указатели много где есть
> Кто еще позволяет отрубить себе ногу?
Питон например. Только более пафосно, без указателей.
>Питон например.
Ладно, таки попрошу пример.
Что-то не так?
> Ладно, таки попрошу пример.
Да пожалуйста. Где-то здесь на странице было про суммирование булевых типов. Что там получилось? Число? Лол.
А примеров с многострадательных GIL'ом можно вообще тысячи напридумывать
>Где-то здесь на странице было про суммирование булевых типов.
И это все? Ну в сисярпе элементы энума конвертируются в инт. Как по мне - неправильно, ломается строгая типизация.
>А примеров с многострадательных GIL'ом можно вообще тысячи напридумывать
Можно, но почему-то все перечисленное тобой упоминают те, кто питоном не пользуется.
>Сколько этих низкоуровневых языков
Много на самом деле. Но популярны 3-4.
> и с каких пор они стали нормальными?
С тех пор как появились. Судя по твоим сообщениям ты школьник и потому ничего удивительного, что ты не понимаешь чем в первую очередь отличаются друг от друга языки. А именно - задачами, на которые они ориентированы.
> все перечисленное тобой упоминают те, кто питоном не пользуется.
Это должно тебя натолкнуть на мысль, что все эти проблемы действительно весомые и те люди, которые это понимают неспроста не пользуются питоном.
Бугурт незаметен.
А другие слова, описывающие эмоции ты не знаешь?
Мне просто доставляет общаться на такие темы. Приятно смотреть как в глазах оппонента таит уверенность в себе.
Какие, кроме c?
>С тех пор как появились.
Когда-то байтоёбство было модным, а сейчас один Царь одиноко хуячит на сях обход памяти.
>Это должно тебя натолкнуть на мысль, что все эти проблемы действительно весомые и те люди, которые это понимают неспроста не пользуются питоном.
Слушай, мнение прохожих, что отбойный молоток воняет маслом или еще чем-то, рабочего не ебут, а ебут его какие-то другие проблемы, о которых прохожие могут и не догадываться. И что отбойным молотком гвоздь не забить, нормальных людей тоже не волнует. На все свой инструмент. Ты же пытаешься мне объяснить, что отбойный молоток - это как обычный, только хуёвый. Нет.
Перечислял же уже где-то здесь, на странице, поищи.
>Когда-то байтоёбство было модным
Глупый ты еще. Твоей же фразой тебе отвечу:
> На все свой инструмент
>И что отбойным молотком гвоздь не забить
Ну так а что же этот "отбойный молоток" пытается выглядеть микроскопом?
Ты как и любой питонист слишком уверен в том, что он идеален и прекрасен, в то время как в нем есть явные косяки. Причем все они это не проблемы того, что питон ориентирован на что-то другое.
Иногда мне кажется, что питонисты готовы хуй сосать, лишь бы с ними согласились и сказали что питон классный
Как я понял из высеров местных господ, С++ низкоуровневый, если на нем писать как на C, а так в нем есть все ,кроме нормального ГЦ.
>Глупый ты еще. Твоей же фразой тебе отвечу:
> На все свой инструмент
Уважаемый Седомудый Царь,приведи мне области, где еще нужно байтоебство, а также процент вакансий на них в отношении ко всем.
>Ну так а что же этот "отбойный молоток" пытается выглядеть микроскопом?
Ты о чем? Где это питон лезет в хайлоад?
>Ты как и любой питонист слишком уверен в том, что он идеален и прекрасен, в то время как в нем есть явные косяки.
Ты не то что не читал мои остальные посты, ты даже этот тред не осилил. Я нигде не говорил, что он идеален, просто список моих и твоих претензий совпадает на 0,хуй%, а поскольку ты питон не юзал, то твое мнение важно где-то настолько, насколько мнение прохожего по поводу удобства чужих интсрументов.
>Иногда мне кажется, что питонисты готовы хуй сосать, лишь бы с ними согласились и сказали что питон классный
Давно в глаза долбимся? От красноглазия помогает?
Вообще-то ты прав, но я тут причем?
Настройка IDE, не (в жаве один хрен без нее никуда)?
У вас паранойя, я и не троллил.
Наличие проблем не говорит о том, что Java плохо спроектирована. Траблы естественно есть, но в целом язык очень хороший, интуитивно понятный.
2
True + False + True == 2 ? Seriously? Let's keep C programmers happy?
Haskell approach to this is much clearer. It's pretty clear that Bool is a monoid in two different ways: Any with unit equal to False and sum equal to logical OR and All with unit equal to True and sum equal to logical AND.
https://docs.python.org/3.1/library/stdtypes.html#boolean-values
Boolean values are the two constant objects False and True. They are used to represent truth values (although other values can also be considered false or true). In numeric contexts (for example when used as the argument to an arithmetic operator), they behave like the integers 0 and 1, respectively.
-----
Haskell is safier in this case:)
But in Python you ain't able to convert string into int implicitly and that makes Python much better than many other scripting languages
Haskell is probably safier in any case you can imaging.
http://raz0r.name/vulnerabilities/simple-machines-forum/
А то! (АТО!)
Каким-то хуем это конвертируется в int. Где граница слабой и сильной типизации?
В одной статье, не помню уже чьей, это деление вообще критиковалось, потому что у многих аргументация выходит в стиле «слабая типизация — это та, которая мне не нравится».
scala:
threads count _.isAlive
Слово lambda тяжеловато, но питон любит ясность
Кроме того, в Java теперь есть лямбды, так что уже поздно выёживаться.
>Слово lambda тяжеловато, но питон любит ясность
Вы еще в названии методов пишите слово method, наверное?
>>Вы еще в названии методов пишите слово method, наверное?
В питоне мы пишем def
В джаве и C# -- возвращаемый тип
А на языках где надо писать "function" мы, к с частью, пишем крайне редко
>Ну у Вас больше опыта в разглядывании чужих членов
Это называется метафора
>В питоне мы пишем def
Читай внимательнее
Видимо разглядывание чужих членов плохо влияет на способность вести конструктивную беседу:) Что же я не так прочитал?
>разглядывание чужих членов плохо влияет на способность вести конструктивную беседу
Вот и не разглядывай
sum(bool(x.isAlive()) for x in threadList) - написавший это, ты что курил? это код для мастер класса, так что начинающие точно так не пишут
Есть легкий способ вызвать у меня бугурт, но я Вам его не скажу.
Уже был пример из scala, вон там, сверху. Ни скобок, ни извращений с типами.
> Есть легкий способ вызвать у меня бугурт, но я Вам его не скажу.
Да мне и не интересно. Просто забавно, когда в качестве лучше подхода приводят явно страдающий от проблем пример.
> Я привел подход на первом подвернувшемся языке
Это все замечательно. Вот только у этого языка своих проблем достаточно, тем хуже выглядит эти бросания камней в сторону чужих проблем
Я кидал камень не в джаву со стороны пайтона, а в отсутствие лямбд и средств работы с ними в старых версиях языках.
Тоесть на пайтоне (при всех его минусах) можно сделать это в одну строчку. На джаве шестой -- никак.
Ключевое высказывание
>На джаве шестой -- никак.
Что, в прочем, никак не сказывается на читабелности. Безусловно, можно подобрать более удачный пример, но конкретно здесь преимущества сомнительные.
Конечно же сказывается: конструкция sum(1 for t in threads if t.alive) более чем читаема, особенно в сравнении с конструкцией из девяти строчек в этом посту
Хорошо. Сделаем вид, что я не понимаю что здесь написано. У меня сразу возникнут вопросы:
1 - Почему sum - функция, а не метод?
2 - Для чего 1 перед for?
3 - Почему есть if, а не else? Что произойдет, если !t.alive ?
Конечно пример простой, потому немного утрировано, но все же
А вот код из поста значительно понятнее: он чисто императивный и не содержит неоднородностей (if-без-else).
Рискну предположить что человек не знающий синтаксиса Скалы тоже может в ней многое непонять
А с Java у вас такие вопросы не возникнут, просто потому, что все просто. Да многословно, но все же просто
>многое непонять
Как и в любом другом языке. Но мы то про конкретный пример
>threads count _.isAlive
Я даже не знаю, что здесь может быть непонятно
Ну, либо так: threads.count(_.isAlive)
Например, видимость переменных во вложенных классах.
Трудности могут быть разве что со static, но и там все просто. В общем, не знаю о чем вы.
В том, что в питоне все выглядело гораздо логичнее и получалось с первого раза.
Вот тут все варианты описаны:
https://docs.oracle.com/javase/tutorial/java/javaOO/nested.html
Простой вложенный класс содержит ссылку на родителя, и жить без нее не может. Отсюда и небольшое извращение с new. Вложенный static class такой ссылки не содержит, поэтому ведет себя вполне интуитивно.
Смотрите-ка, илитка? Или псевдоэлитие сраное?
Толсто, даже смысл потерял
Нет, конечно. У тебя что-то с когнитивными способностями. Влияние питона, видимо, не первый раз такое замечаю у вашей братии.
Не путай "плохой" и "ориентированный на говнокодеров".
Вот С++, например, плохой. Тем не менее на говнокодеров он не ориентирован.
А вот питон - рай для оных. Кроме того он популярен, что явно плюс к ЧСВ, а школьники это любят
ПОтому ,что простой и на нем преподдают. А вот ориентированные на говнокодеров -это js и php. Влияние <Кстати, чего? Ты ведь так и не представился.>, видимо, не первый раз такое замечаю у вашей братии.
Метод чего?
Твои попытки оправдать эту поделку просто жалки.
Более того - вот захочу я функцию, которая считает произведение всей коллекции. Я ее тоже должен сделать методом этой иерархии?
anyCollection.reduce( (x, y) => x + y)
У вас же есть reduce? Или он тоже отдельной функцией реализован?
Опечатался, бывает
anyCollection.reduce( (x, y) => x * y)
У кого у "нас"?
Или вы просто хотите про код поговорит?
> Или вы просто хотите про код поговорит?
Да. Так что плохого в свободных функциях?
Объясните, почему она при этом должна лежать отдельно?
> Объясните, почему она при этом должна лежать отдельно?
Т.е. в коллекциях теперь стало можно хранить только элементы, которые можно складывать? Иначе ведь код коллекции в какой-нибудь жабе не скомпиляется. Она ведь не умеет в ленивую инстанциацию шаблонов.
Судя по более поздним коментам guest'а sum вообще не нужен. Ибо у коллекции будет fold (аля reduce), который позволит запилить sum прямо там, где он понадобится.
Нет конечно. Не забывайте, что в питоне есть дактайпинг и такой проблемы вообще не должно быть
> Иначе ведь код коллекции в какой-нибудь жабе не скомпиляется
Все зависит от подхода. Никто не мешает передавать передавать компаратор? Так почему бы не передавать сумматор?
Если хочется красивости, то его можно сделать неявным, как например, в Scala:
List(1,2,3,4,5).sum
И все работает.
Кроме того, лучше уж вообще не делать функцю sum, а суммирование списка делать через свертку, как предложено выше
Уже поднималось рубиёбами, почему .join есть у строк, а не у списков. Отвечаю: "".join() принимает не список, а последовательность, enumerable в терминах жабы / IEnumerable в c#. Куда ты там методы пришьешь?
>join
К чем это вообще?
>Уже поднималось рубиёбами
Мне безразлично что тебе там говорили рубиёбы, они ничуть не адекватнее тебя.
>последовательность
То есть списки у вас не последовательность? Лол. Вот еще один косяк архитектуры. Еще чуть чуть и в логотипе питона можно будет писать defective by design
>Куда ты там методы пришьешь?
Шедевр. Без комментариев
Чем ужасно? Эмоции есть, обоснований нет. Мы программы пишем или занавески вешаем?
Давай, сделай нам sin() с ООП.
При чем здесь вообще sin? Мы сейчас говорим про тривиальную функцию, которая работает с конкретным типом. С чего рази она должна быть отдельно от этого типа?
Каким типом, с каких пор последователность - это тип?
Для жаваёбов. У остальных есть модули и функции.
Не позорься. Хотя бы матчасть выучи перед тем как на такие темы разговаривать. У тебя что ни сообщение, то глупость.
Бггг
Где в питоне иерархия классов?Или ты про наследование?
Кто-нибудь, запишите это в фонд золотых цитат Говнокода
Ладно, чудо, приелось, пойду кофе пить. Удачи тебе, желаю вырасти и поумнеть.
> Куда ты там методы пришьешь?
В python же вроде были классы. И наследоваться же вроде можно было. Почему нельзя было сделать класс IEnumerable, реализовать там join и унаследовать от него коллекции? Или же последовательности - это какой-то костыль-исключение, которое позволяет по массиву и питонокортежу бегать через какой-нибудь for, а ни унаследоваться, ни создать свою последовательность не позволяет?
Последовательность - почти один в один enumerable, отличается методом .__iter__()
> так сделал
В жс можно самому унаследоваться от массива:
Да и у вас в питоне с утиной типизацией и наследованием всё это можно было устроить.
Я правильно понимаю, что проблемы тут скорее идеологические, питон как язык всё может, и join мог бы быть в каждой коллекции?
Не. Это полная хуйня. В жс как раз итераторов не хватает. Верней хватает, но только в фф.
>IEnumerable
Суть этой штуки, можно примерно описать как ленивый список. В шарпе пока не начнёшь доставать оттуда элементы он и пальцем не пошевелит — не пойдёт за ними в базу и прочее.
Ленивый список, как вы понимаете может быть бесконечным и вычисляемым на лету. Массив так не умеет.
>IEnumerable doesn’t support lazy loading.
Да IQueryable — декларируется как ленивый, но interface IQueryable : IEnumerable.
То есть каждый IQueryable всё-равно является инстансом IEnumerable.
Следовательно ничто мешает написать нам свой ленивый IEnumerable.
IEnumerable doesn’t support lazy loading? Так?
А IQuerable, который является и IEnumerable, support lazy loading, так?
Значит существуют IEnumerable с поддержкой lazy loading.
Получили противоречие. Та статья писана некомпетентным человеком.
Q.E.D
> Значит существуют IEnumerable с поддержкой lazy loading
IQuerable
>IQuerable
Любой IQuerable является IEnumerable. Квантор всеобщности проходили? Утверждение что объект IEnumerable не может в ленивую подгрузку — ложно.
Раскрою страшную тайну IQuerable, он вообще ничего не поддерживает. Абсолютно. Никаких ленивых подгрузок.
И не надо мне тыкать какими-то левыми мнениями людей в интернете. Не вижу цитаты из спецификации, выдержек из документации. Я тоже могу найти много чего, например, того кто считает что все шарперы — идиоты, и сослаться на его авторитетное мнение.
Хотелось бы увидеть ответ на простой вопрос: "чем же таким важным IQuerable расширяет IEnumerable, что тот начинает поддерживать lazy loading?"
IQuerable
http://referencesource.microsoft.com/#System.Core/System/Linq/IQueryable.cs,965b3e30b9ed851f
надеюсь пояснения не потребуются.
1. Какой функционал в IQueryable обеспечивает ленивость:?
2. Что такое IQuerable?Поциент даже не заметил как я начал подглумливаться над его безграмотностью.
Ок. Но каким образом IQueryable заставляет это делать?
Давай.
Большинство тулзин на нем всё же однопоточны.
Тем более что yield from и asyncio позволяют делать достаточно красивый однопоточный код с корутинами, получается вытесняющая многозадачность. В конце концов первый апач вон так работал, и никто не жужжал.
Пайтон это СКРИПТОВЫЙ язык, не нужно ждать от него того, что есть в нескриптовых
Где константы?
private на уровне соглашений. __ почти private
Констант нет, да, это минус.
Обоссаться просто. Работает он у вас тоже на уровне соглашений?
>Все, что ты перечислил
> "недостатки"
Так ты на остальные камменты посмотри. Давай, прям по каждому пункту отвечай. С GIL начинай.
Да не обманывай ты. Это значит лишь "пацаны, считайте, что вы его не видите".
> начиная с отступов по 4 пробела, а не по 1 - первый, по 7 - второй.
Даже не могу представить как в трезвом виде можно было придумать такое извращение
На кой черт вообще из языка скобки убрали? Типа, меньше кода? Ммм да, круто, меньше.
>Да не обманывай ты. Это значит лишь "пацаны, считайте, что вы его не видите".
Ты про один _
>Даже не могу представить как в трезвом виде можно было придумать такое извращение
Какое? Что такое работает? Я хз. Обратная совместимость с каким-то гавном, питон старше жавы, кстати.
>На кой черт вообще из языка скобки убрали?
А что они давали, кроме возможности рассинхрона между отступами и скобками?
Не ну private можно сделать заныкав переменную в замыкании.
Я не совсем уверен как там поведёт себя скоупинг, в общем идея такая:
2) ВОТ_ТУТ
Я уже раз восемь объяснял тутошней публике и попробую объяснить еще раз:
Константы, приваты и прочее это КОНТРАКТ. В некоторых языках контракт проверяет компилятор (java например), в некоторых -- специальный lint тул (в пайтоне, например).
Важно что контракт есть, и что никто не завяжется на приватный метод. Да, это можно обойти: взять и завязаться. Но тогда ты сам виноват. В джаве тоже можно рефлексией вызвать приватный метод. Но тогда ты тоже сам виноват.
Можно спорить о том хорошо или плохо что в пайтоне контракт не проверяется интерпретатором, но говорить что его там нет -- это чушь.
И кстати пайтон няша еще и потому, что там есть довольно внятный PEP-8 на кодстайл в отличии от пыха, JS итд.
Где барьеры?
Где вообще хоть какие-то внятные примитивы параллельного программирования?
Где нормальная работа с тайм-зонами?
Где нормальное, всепроникающее ООП, а не издевательство ввиде коллекций функций (sum(blblabla))?
А как мне в качестве коллбека передать print? Ах да, это же не функция, давайте обернем её и только тогда передадим. Что? Использовать третий питон? А как же все мои библиотеки? Весь мой код? Забить?
>Где нормальная работа с тайм-зонами?
Не понял, что имеется в виду.
>Где нормальное, всепроникающее ООП
Эээ, что не так?
Задам встречный вопрос- а зачем передавать print? Не путаете ли вы часом ФП c "циклом в одну строчку"?
Кстати, загляните в __future__. И да, двойка устарела и не развивается.
Ты их пробовал вообще? Ну так попробуй. Без сторонних библиотек без слез смотреть нельзя.
>Эээ, что не так?
Я уже сказал что не так. Какого черта в питоне для тривиальных действий нужно вызывать внешнюю функцию, а не метод объекта?
Для кого ООП придумали?
>Задам встречный вопрос- а зачем передавать print?
Чтобы сделать, например так:
anyArray.foreach(print)
>Не путаете ли вы часом ФП c "циклом в одну строчку"?
Лол, как этот вопрос у тебя вообще возник из того утверждения? Не путаешь ли ты? Хотя откуда тебе знать, в питоне от фп разве что функции как first-class-citizens.
>двойка устарела и не развивается.
Сколько у вас там % 3 пользую? 10? 20?
Может, приведешь пример, что ты хочешь? Я пока не догоняю?
К чему ты приплел sum? Ты не путаешь, случайно, ООП и ФП?
>Чтобы сделать, например так:
>anyArray.foreach(print)
И зачем? У тебя руби головного могза.
>Лол, как этот вопрос у тебя вообще возник из того утверждения?
Ну потому что результат выражения отбрасывается и ФП используется чисто для побочных эффектов, что противоречит его идее.
>Сколько у вас там % 3 пользую? 10? 20?
Где как. В вебе, насколько я знаю, большинство либ уже на тройке, но это неважно. Развивается только тройка, будешь сидеть на двойке - будешь наступать на грабли семилетней давности.
Хотя бы самое тривиальное. Как там учесть переход на зимнее время и отсутствие перехода на летнее? Как учесть то, что сейчас снова поменяли?
>Ты не путаешь, случайно, ООП и ФП?
При чем здесь ФП? Или ты думаешь, что ФП - это просто использовать функции вместо методов? Лол.
>И зачем? У тебя руби головного могза.
А как мне коллекцию распечатать? Вот сделал я фильтр по, допустим, логу, как мне вывести его на экран?
>Ну потому что результат выражения отбрасывается и ФП используется чисто для побочных эффектов, что противоречит его идее.
При чем здесь ФП вообще? К чему ты его приплел? Или ты считаешь, что обычный foreach это уже ФП?
>Где как
>насколько я знаю
Насколько я знаю и вижу на 3 сидят только те, у кого нет поддерживаемого кода, нет требований к зависимостям и проект стартовал вчера.
>Развивается только тройка
А что толку? На ней как полтора школьника писало так и пишет
Гениальный алгоритмы просто:
1. Сделать функции как fcs. Все.
2. Ввести синтаксис лямбд (стремный в вашем случае, кстати. Как вообще можно было додуматься писать слово lambda ? Вы еще на минимализм претендуете. Ужас)
3 ????
4. PROFIT!!1
Потому, что я - не питон? :)
Я знаю, есть стайка мудаков, которые на нем пишут всякую хуйню в /pr/. Больше я о них них ничего не знаю.
А какую бы ты хотел поддержку ФП? Где, по-твоему, она нормальна?
Теряешь контекст все время. Мы про питон говорим здесь, забыл?
> Больше я о них них ничего не знаю
Вот в том то все и дело. Не стоит употреблять термины, если не знаешь их значения. Выглядишь жалко.
> А какую бы ты хотел поддержку ФП? Где, по-твоему, она нормальна?
За исключением чистых фп языков (не pure, а где фп - единственная парадигма ) - scala
>Зачем ты его упоминаешь
Я не гвидо, почему мне нельзя упоминать ФП?
>Вот в том то все и дело. Не стоит употреблять термины, если не знаешь их значения. Выглядишь жалко.
Мне поебать как я выгляжу в глазах тех, кем я не хочу стать.
>За исключением чистых фп языков (не pure, а где фп - единственная парадигма ) - scala
Пока твои претензии "питон не скала ->питон == гавно". Ну так и пиши на них, хуль приебался-то?
Как будто что-то плохое (по поводу знать)
>нахуй никому не нужны.
Только посмотрите, он продолжает изрекать шедевры.
Такого самообливания говном я еще никогда не встречал
Ты такой милый
>pr
Перверач закрылся уже давным давно
>Lock
Серьезно? Лок? Все? На этом интересы питон-программистов заканчиваются?
Для low level там сишка есть, а что на чистом питоне не стоит писать критический к скорости код, как и на любом динамическом языке - это ни для кого не секрет.
Я вот нихуя не врублюсь в суть твоих претензий. Ты пытаешься объяснить, что чистый питон по скорости сосет у жавы/сей? Это совсем не секрет. Питон не для этого сделан был, как и все динамические языки.
Насчёт многопоточности в пейсоне. Ну лочки, очереди и семафоры есть.
А низкоуровневые многопоточные примитивы всякие CASы и fencы, атомики, хитрые пулы с work-stealing, вероятно нам ответят что это всё байтоёбство.
И ведь так оно и есть — на пейсоне производительных серверов никто всё-равно не пишет.
Думал как-то попробовать питон для скриптинга, вместо perl'а. Лучше бы не пробовал. Как там вызывается чертов ping? Слабонервным лучше не видет.
В этом смысле руби делает питон делает как стоячего просто.
Опять двойку хуесосим? Давайте, может мудачье с нее переходить начнет.
>Думал как-то попробовать питон для скриптинга, вместо perl'а. Лучше бы не пробовал. Как там вызывается чертов ping? Слабонервным лучше не видет.
Возможно. А так - subprocess.Popen()
>В этом смысле руби делает питон делает как стоячего просто.
Как замена перлу? Возможно. Оттуда сознательно выпилили TMTOWTDI нахуй.
Лол, на двойке как раз таки нормальные и сидят, потому, что у них там проекты реальные, которые, знаешь ли поддерживать нужно.
> subprocess.Popen()
Я же сказал, слабонервным не смотреть. Это же жесть, господа. И он еще позиционируется как нормальный язык для скриптов? Невыразимо просто.
>TMTOWTDI
Да ладно если бы несколько, в питоне и одного нормального нет. subprocess.Popen...
>проекты реальные, которые, знаешь ли поддерживать нужно.
Что за проекты реальные? Говнообертка к сишной либе?
>И он еще позиционируется как нормальный язык для скриптов?
Кем?
Смотрю твоя область знаний сильно узкая. Хоть один известный и хорошо работающий проект на 3 назови.
>Кем?
Всеми. На каждому углу кричат, какой питон классный, как на нем удобно писать все: и скрипты и энтерпрайз и сайты и вообще всё всё. Вот только на деле он бесполезен более чем полностью.
django? Подавляющее большинство web фреймверков?
>Всеми. На каждому углу кричат
Ясно. Я тоже на каждом углу наслушался, а потом оказалось, что питон - вендовраждебное прыщеговно. Прислушивайся внимательнее, или точнее, не слушай прыщеблядков.
>на нем удобно писать все: и скрипты
можно
>и сайты
Одна из основных областей применения, чо.
Проблема в питоне, с моей точки зрения, в том, что у него есть куча областей применения, и эти области принципиально разные, с разными требованиями. Кто-то пишет на нем что-то нормальное , используя все фишки питона. Кто-то хуячит обертку на питоне для сишной либы и пишет потом си на питоне, потом этой оберткой реально нельзя пользоваться без знания сей, точнее можно, но до первого сегфолта, плюс документация наверняка будет для сишного апи.
Так пример проекта можно услышать?
* Отсутствие явной декларации переменной
* Отсутствие единого стандарта на документирование методов (зоопарк развели, епидоки, ресты, хуесты)
* Застрял в переходе с 2 на 3 уже 8 лет. Это СИПЕЦ!!!
Ну это так, сходу
Это мудачье, лепящее обертки к сишколибам, чтобы писать си на питоне, на нем застряло. Какая разница, на чем писать си - на двойке или тройке? Возможностей питона кроме базового ООП там не используется. Но должен сказать, что невозможность хоть как-то использовать код на двойке и тройке в одной проге или добавить поддержку плагинов и на двойке, и на тройке все сильно тормозит. С другой стороны, если поискать, можно найти и проги с неполной поддержкой юникода, TC, например.
* Огромная кодовая база: сотни программ используют относительный импорт, ловят исключения без скобок, принтят без них, считают строки неюникодными итд. Выкинуть старое говно не так-то просто, хо-хо!
* На говнохостингах говноадмины поставили говнодистрибутивы со вторым пайтоном. Еще хорошо если там 2.7. А если 2.4? Смех смехом, но даже на моём амазончике Python версии 2.6.9!! Не все люди достаточно рукасты чтобы подключить другой репозиторий или собрать из сырцов.
* В тройке не так-то много киллинг фич. Ну вот йелд фром с asyncio -- это фича, да. Но 99% кодомакак про нее не знает. А если и узнает --то не осилит. А если и осилит, то оно им нафиг не надо. Так что смысла переходить нету.
Натыкаюсь на обертки к библиотекам, которые дай бог чтобы на 2.7 портанули, не говоря уже про 3.
Пруф: https://pypi.python.org/packages/2.7/l/lxml/lxml-3.4.1-cp27-none-win32.whl
кстати, надо попробовать portage на jython или как его там :)
У меня от игор глаза и так красные.