- 1
https://habr.com/post/417047/
Нашли или выдавили из себя код, который нельзя назвать нормальным, на который без улыбки не взглянешь? Не торопитесь его удалять или рефакторить, — запостите его на говнокод.ру, посмеёмся вместе!
−1
https://habr.com/post/417047/
Гвидо уходит напитон из питона
KaKou-To_xyu 13.07.2018 13:40 # 0
Если уж при Гвидо туда пропихнули хуиту (:=), то без него, думаю, преврятят Питонию в какой-нибудь Перл или Руби.
roskomgovno 13.07.2018 16:43 # −1
зы: руби охуенен, братан
не кроши на него батон
да и перл не так уж плох для своего времяни и области применення
vistefan 13.07.2018 17:29 # 0
Да и Perl не так уж плох для любого времени и любой области примнения.
// fixed
roskomgovno 13.07.2018 17:33 # 0
я писал комментарий, а он удалялился
ох, пхп
так вот: Perl был создан чтобы легко и просто парсить текстовые файлы и крутить их как нужно. И чтобы делать это в небольших скриптах. Он для этого идеален.
А когда на нем пишут сложную бизнес-логику с кучей классов и кучей файлов то он превращается в ад. И он не виноват: он НЕ для этого.
Practical extranction and report language.
vistefan 13.07.2018 17:50 # 0
Благодаря своему происхождению Perl был богатым языком даже тогда, когда служил «просто» языком преобразования данных, предназначенным для перемещения по файлам, просмотра больших объемов текста, создания и получения динамических данных и вывода легко форматируемых отчетов, основанных на этих данных. Но в какой-то момент начался расцвет Perl. Он стал также и языком для работы с файловой системой, управления процессами, администрирования баз данных, программирования в архитектуре клиент-сервер, создания безопасных программ, управления данными в Сети и даже для объектно-ориентированного и функционального программирования. Эти возможности не были просто механически присоединены к Perl — каждая новая синергически работает с остальными, поскольку с самого начала Perl проектировался как интегрирующий язык.
<...>
Хотя Perl особенно популярен среди системных программистов и разработчиков для Интернета, это связано лишь с тем, что они первыми его открыли; аудитория Perl значительно шире. Получивший при создании скромный статус языка обработки текста, Perl превратился в сложный язык программирования общего назначения с богатой средой разработки программ, укомплектованной отладчиками, профайлерами, формировщиками перекрестных ссылок, компиляторами, библиотеками, синтаксически ориентированными редакторами и всеми остальными атрибутами «настоящего» языка программирования — если они вам требуются. Но все они относятся к поддержке возможностей решения сложных задач, с чем справляются многие другие языки. Уникальность Perl в том, что он никогда не терял из виду возможность легко решать задачи простые.
roskomgovno 13.07.2018 22:29 # 0
В том-то и проблема.
ЯПу лучше бы сразу же проектироваться и использоваться так, как спроектировался. Дикорастущий сад приводит к хаосу.
Перл хороший, но
1) в нем дохуя операторов, некоторые лучше бы было реализовать функциями (https://perldoc.perl.org/perlop.html)
2) мне не нравится что все функции varargs по умолчанию. Это почти никогда не надо. Хак с хешем, превращающмимся в named parameters тоже не очень (от перла эта болезнь передалась в Ruby)
3) доллар не нужен. Это мусор семантический, чтобы не выглядеть чужаком в шелпрограмминге
4) blessed, new и стрелочка мало того что тоже мусор, так еще и мозговзрыв. Вы или не умейте ООП вообще (как си) или умейте его в нормальных терминах.
5) -s и use strict надо быть по умолчанию
6) один факт наличия "use English;" много говорит о языке
В целом же Perl крут, имеет кучу отличных модулей на CPAN, и маленькое, но сильное сообщество.
Если ты берешь программиста на Perl на работу то он почти никогда не мудак-скрипткидди (а, например, с питонистом такое может случиться)
tuberkulez 13.07.2018 22:33 # −102
guest8 13.07.2018 23:27 # −999
roskomgovno 14.07.2018 03:15 # 0
Если С++снику платят больше, чем PHPшнику то это не потому что С++ сложнее, а потому что сложнее задача, и ее может решить только более крутой программист, ну а язык это просто инструмент.
С остальным, в принципе, согласен.
vistefan 14.07.2018 14:35 # 0
Вот это сомнительно. А если вдруг наоборот пхп-шнику платят больше? Что это значит, что у него задача сложнее или он более крутой программист? Я думаю, это значит, что какой-то из бизнесов просто приносит больше денег или что-то в этом роде.
3oJIoTou_xyu 14.07.2018 14:47 # 0
guest8 13.07.2018 19:38 # −999
roskomgovno 13.07.2018 22:12 # 0
Видишь, педоматик какой-то использует
guest8 13.07.2018 22:29 # −999
roskomgovno 13.07.2018 23:09 # 0
используют люди, да
рубийное соощество, кстати, очень много сделало для
1) DSLей
2) веб-фреймворков
3) configuration as code
4) BDD
Зато PHP сообщество изобрело правку .php файлов на продакшене через тотал коммандер по ftp
Desktop 13.07.2018 23:26 # 0
- "ой, мы сделали непонятную херню, а давайте её присобачим всюду, куда дотянутся наши потные ручки"
roskomgovno 13.07.2018 23:29 # 0
Без словестного описания фич их невозможно ни тестировать, но синхронизировать свое понимание с бизнес-оунером (см "Specification by Example" Аджича)
guest8 13.07.2018 23:29 # −999
roskomgovno 13.07.2018 23:30 # 0
>>но сам язык, похоже, не нужен
толи дело пхп, да?
3.14159265 13.07.2018 21:31 # 0
guest8 13.07.2018 21:34 # −999
666_N33D135 14.07.2018 16:06 # 0
guest8 13.07.2018 19:38 # −999
666_N33D135 13.07.2018 19:45 # 0
666_N33D135 13.07.2018 19:50 # 0
guest8 13.07.2018 19:43 # −999
guest8 13.07.2018 19:44 # −999
3.14159265 13.07.2018 21:57 # +1
Хахаха. Они даже FAQ не удосужились поправить
https://docs.python.org/3.8/faq/design.html#why-can-t-i-use-an-assignment-in-an-expression
Why can’t I use an assignment in an expression?
Many people used to C or Perl complain that they want to use this C idiom:
The reason for not allowing assignment in Python expressions is a common, hard-to-find bug in those other languages, caused by this construct:
666_N33D135 14.07.2018 16:08 # 0
guest8 16.07.2018 21:22 # −999
guest8 16.07.2018 21:23 # −999
tuberkulez 13.07.2018 17:11 # −4
roskomgovno 13.07.2018 17:29 # −1
во всем остальном необходимость есть
roman-kashitsyn 13.07.2018 18:44 # −1
Ну не знаю, я уже джвадцать джва года жду, когда всё это недотипизированное скриптоговно уже сдохнет.
roskomgovno 13.07.2018 18:46 # −1
Хотя я, пожалуй, соглашусь что в 1993 году смысла в скриптовых языках было куда больше чем сейчас
Desktop 13.07.2018 18:57 # −1
roskomgovno 13.07.2018 18:58 # −1
Desktop 13.07.2018 19:08 # −1
roskomgovno 13.07.2018 19:10 # −1
Мне 90% того что пишется на скриптах действительно легче и приятнее написать на котлине, например. И у меня будет стат. типизация, комплишен, рефакторинг, файнд юзадж итд
А Роману, наверняка, на го
На скриптовых хорошо писать скрипты. В один экран. Из двух файлов. Или несложный сайтик.
Desktop 13.07.2018 19:17 # −1
Как писать скрипты на go, я представляю слабо, это же мунспик для 99% программистов (хотя учитывая местные нежные чувства к перлу, неудивительно, что ты его упомянул).
Котлин действительно лишён вышеуказанных недостатков. И в общем тебе прямо сегодня ничто не мешает писать 90% того, что пишется на скриптах, на котлине. Ты готов?
roskomgovno 13.07.2018 19:20 # −1
Как и руби
Как и перл
>> Ты готов?
Не всегда.
1) в некоторых окружениях может не быть JVM
2) у меня есть проекты на джанге и фласке. Джанга на котлине не реализуема.
Desktop 13.07.2018 19:24 # −1
- absolutely. Кроме макожобсов, сидящих на герыче, никто на этой шняге не будет писать в здравом уме.
> в некоторых окружениях может не быть JVM
- в некоторых окружениях может не быть python. Или будет python, но не будет python3. И в каких таких окружениях не будет JVM? На винде разве что, где нужно будет next -> next -> next -> finish.
> Джанга на котлине не реализуема
- джанга нет, но какой-то сервак должен быть реализуем, нет?
roskomgovno 13.07.2018 19:28 # 0
ну нет, RoR еще сущестует. Мне руби нра, но я признаю что без предварительной подготовки не прочитать код
>> в некоторых окружениях может не быть python
Тоже верно, но обычно он там есть в каком-то виде, если тебе надо на серваке скриптец то лянотно ставить JVM.
>> но какой-то сервак должен быть реализуем, нет?
Разумеется, они даже есть. Но в Django много магии, которая на ЯПах со стат. типизацией не реализуема. Зато она сохраняет кучу бойлерплейта.
Это трейдофф всегда. Но в целом писать что-то огрмное, сложное, над которым будет работать 20 человек, где будет 300 концепций, писать такое на скриптовом языке в 2018 году я бы не стал
Desktop 13.07.2018 19:36 # −1
- ну вот галера, которая лабает kabanchik.ua, prom.ua (и возможно их аналоги для российского рынка), содержит около сотни питонорабов, пока не потонула. Да, это не гугл, да, это не хайлоад, но who cares
guest8 13.07.2018 19:40 # −999
Desktop 13.07.2018 19:43 # −1
guest8 13.07.2018 23:30 # −999
roskomgovno 13.07.2018 22:08 # 0
не дай бог кому переименовать поле user в huuser в проекте где 100 разрабов на питоне
guest8 13.07.2018 22:25 # −999
roskomgovno 13.07.2018 22:32 # 0
guest8 13.07.2018 23:30 # −999
guest8 13.07.2018 23:32 # −999
guest8 13.07.2018 22:40 # −999
guest8 13.07.2018 22:44 # −999
Desktop 13.07.2018 23:34 # 0
Кстати, это ж вроде задача devops'а, накатить такую миграцию?
roskomgovno 13.07.2018 23:43 # −1
Ты до такой степени не понял о чем я, что мне даже стало страшно. Давай я попробую снова:
В языках со статической типизацией вроде Java, Kotlin или C# ты (при условии неиспользования рефлексии конечно) про каждый метод можешь сказать где он объявлен.
Для каждого метода, филда и пр. всегда можно легко дойти до его объявления.
Этим пользуются IDE чтобы поддерживать рефакторинги вроде "rename method".
Ты переименовал поле user в owner, и IDE сама нашла все его вхождения и переименовала, а другие user она не тронула.
В динамических языках сделать такое крайне сложно. В питоне чуть легче, в руби сложнее, в JS еще сложнее.
Потому ты легко можешь сломать код таким рефакторингом.
В компилируемых ЯПах ты узнал бы об этом на этапе компилации, но в питоне -- нет. Остается уповать на тесты.
Всё это не имеет проблемы кода
1) каждый разработчик понимает ВСЮ систему (про каждый "user" он может сказать тот это самый user или другой)
2) весь код покрыт тестами и такие проблемы сразу же всплывут
К сожалению, так бывает только в кино. В жизни приходится ковыряться в недокументированном дерьме на 800 строк без единого теста и пытаться что-то там понять (кстати, CTRL+click в Java перенесет тебя на декларацию/дефиницию, а в питоне далеко не всегда ибо IDE может и не знать).
Потому мне и кажется что большой проект с обычными (а не супергениальными) программистами на питоне поддерживать сложнее, чем аналогичный на Java.
guest8 13.07.2018 23:48 # −999
roskomgovno 14.07.2018 15:25 # 0
В DI, сериализаторах (в json например), в ORM. Но обычно она поддерживается IDE боль-мень.
пример: Spring (DI контейнер) позволяет в XML описывать бины (пишу по памяти, не видел 10 лет, синтаксис может быть и не такой, но смысль понятен)
Мы создали синглтон курочки и установили ее в одноименное свойство питушка.
По сути вызвался метод "setKurochka" у класса Pitushok (всё это мутабельно и вообще говно, но речь не о том сейчас). Ну вот тут мы использовали рефлексию, но Idea это поймет и будет статически проверять.
>>Но где ты видел проект на питоне где работает большое количество проггеров?
Так Desktop писал же про 100 разрабов:)
В идеальном мире конечно проект надо разбивать на маленькие, независимые сервисы и делать команды на 5-6 человек максимум (и скрам так учит) но не всегда так бывает
Desktop 13.07.2018 23:52 # 0
- ковыряться в недокументированном дерьме на 800 строк одинаково приятно что в Питоне, что в крестах, что в перле (ну ок, тут вдвойне приятнее).
Да, есть проблема, о которой ты говоришь. Но есть много вариантов её решения или уменьшения. Так что проблема опять-таки в техническом менеджменте.
Ну и конечно я более, чем уверен, что питонячья макака обходится большому папке дешевле жабового гамадрила. Шах и мат, идеалисты
roskomgovno 14.07.2018 15:17 # 0
Не совсем. Быстро что-то найти все таки проще когда у тебя работает find usage в Idea. Но с другой стороны чтобы реально ПОНЯТЬ как что-то работает тебе всё равно придется читать код: что на питоне, что на жаве.
Но прыг-прыг-фикс-хуяк на джаве сделать проще. Ну и хотя бы копеляция тебе даст хоть какую-то слабую уверенность что ты вообще не разнёс все к хуям.
>> питонячья макака обходится большому папке дешевле жабового гамадрила
Это не всегда так, если судить по hh (как ни странно!).
В жавке есть еще всякие ништяки. Например есть омуденные профилировщики, даже обычный YourKit и тот хорош (это примерно как ваши Apple Instruments/dtrace, но по проще).
В питонячьем сообществе многие вообще не знают что можно профилировать (там даже про дебагер не все знают!) и похожих инструментов, увы, нет.
Ну и так, по мелочи хуйня всякая типа многопоточности нормальной (которая конечно не так важна в мире микросервисов и облаков)
Desktop 14.07.2018 15:41 # 0
Есть реальный мир джунов, где народ не сильно в курсе, что можно делать dev, stage и prod, а не хуячить всё в одном окружении на боевом серваке; слово Swagger тут никому ни о чём не говорит. Тут тоже разницы, на чём писать, нет, всё равно получится треш
Ну а у тебя мир вечных мидлов, которые умные слова уже знают, а что с ними делать нет.
roskomgovno 14.07.2018 15:48 # 0
Казалось бы: Apple, Google и MS могут позволить себе самых лучших программистов, но студия xcode и android studio всё равно иногда глючат
guest8 14.07.2018 16:59 # −999
guest8 14.07.2018 17:00 # −999
guest8 14.07.2018 16:48 # −999
vistefan 14.07.2018 14:52 # 0
И узнать об этом далеко не сразу, и, возможно от недовольного заказчика.
roskomgovno 14.07.2018 15:12 # 0
Ну вроде как в современном вебе это считается хорошей практикой.
Попробуй спросить вебщика почему вместо XHTML теперь HTML5 в котором можно не закрывать таги, и он тебе объяснит что если ты случайно забыл закрыть таг в XHTML (при верном контент тайпе) браузер покажет ошибку, в HTML5 все равно отрендерит страницу, просто кусочек ее не покажет.
Бывает так, что верстун напутал с тагами и footer страницы не виден, и этого долго никто не замечает, а с XHTML сразу бы заметили.
Те же самые аругменты они используют когда я спрашиваю почему xml-based шаблонизаторов больше не делают.
Ну и когда речь про выбор языка со стат типизацией то, вероятно, они руководствуются тем же:
а зачем мне узнавать про ошибку в CI сервере, если можно узнать от нее от заказчика случайно через пол года?
guest8 14.07.2018 16:48 # −999
roskomgovno 14.07.2018 16:57 # 0
в начале нулевых было дофига шаблонизаторов на xml (и xslt конечно же).
Они имели отличную поддержку от IDE (потому что их легко парсить) и были защищены от перепутанных и незакрытых тагов.
Потом все сказали что это сложно и нипанятна, и стали использовать НЕ xmlные шаблонизаторы.
Стало можно писать вот так:
.
Разумеется никакие IDE нормально это не хендлят и проверить что все таги закрыты тоже статически никак нельзя.
И все страшно радуются: ах, как теперь стало удобно.
Держится более-ли-менее разве что JSPX: остальные слились
>>А xhtml руками писать не очень удобно.
а html5 удобно? В чем разница?
Алсо, в XSLT можно было наматчить шаблон на какую-то ноду: например если у тебя есть хотя бы один элемент в коллекции то шаблон вызовится, а если нет от не вызовится. Во всех совремменных надо явно писать if, и это оцтой.
guest8 14.07.2018 17:01 # −999
guest8 14.07.2018 17:02 # −999
roskomgovno 14.07.2018 17:08 # 0
как проверяешь то?
>>Ну html был изначально сделан под ручное написание жи.
xhtml это тоже html
>>xml - переусложненное говно и ненужно.
как и статическая типизация, как и IDE как и SOAP. Надо писать на JavaScript в Notepad++ и всё будет хорошо
bormand 14.07.2018 18:27 # 0
Пессимистично, как джавка делает с final. Будет ругаться на некоторые вполне валидные конструкции, но в целом сойдёт.
vistefan 14.07.2018 23:03 # 0
> Пессимистично…
Что такое «проверять пессимистично»?
guest8 14.07.2018 18:36 # −999
guest8 14.07.2018 18:39 # −999
guest8 14.07.2018 18:51 # −999
roskomgovno 14.07.2018 19:07 # 0
Уход от XML-based шаблонизаторов в хипстоту это, суть, уход от статической проверки шаблонов на велл-форменность (и даже, о ужас, на валидность если есть схема!).
Это ровно так же самая проблема что и с уходом от стат типизированных ЯПов.
Тобишь чтобы получить гарантию отсутствия незакрытых или перепутанных тегов, которую ты получал статически за 2 секунды в xml, тебе надо покрыть 100% кейсов тестами.
Поскольку статически доказать это покрытие невозможно, остается только запускать тесты с code coverage и надеяться что все куски твоего шаблона рано или поздно выполнятся.
Чуваки взяли, и выкинули на помойку огромный пласт работы, который делал компьютер, и стали делать его сами.
roskomgovno 14.07.2018 18:47 # 0
Для этого тебе надо запустить приложение, и тестами проверить все его состояния.
проблема точно такая же как и с отсутствием стат типизации:
в xml ты статически, Без запуска приложения поймаешь
"<b></b></b></b"
Точно так же как в Java ты поймаешь 2 +"petux".
А в сраных джановых, например, шобланизаторах ты этого не поймаеешь.
>>А html это не xhtml
и? В каком месте xml сложнее htmlя?
>>Ну дай нормальный юз кейс xml.
Мне кажется я уже тыщу раз приводил, ну ок.
Я делаю сервис с SOAP: я описываю интерфейс, делаю какие-то структуры, пишу джавадоки, жму волшебную кнопку и получаю .wsdl файл./
На другом конце земли сидит программист на C#: он тоже жмет кнопку и получает скелеты для клиента к моему сервису.
У него те же самые структуры и даже доки в них есть!
То-есть если у меня есть структура Rooster с полем age типа int и комментарием "how many birthdays this rooster celebrated" то чувак на ДРУГОМ языке получит тоже самое. С типом и комментом.
Теперь представим себе питушков с REST/JSON.
формальной спецификации у них нет: есть только человекочитаемые описания .json форматов. Синхронизировать ее с кодом надо вручную потому что ничто там типы не проверяет, и доки тоже.
Доходит до того что если на клиенте чел со статтипизированным япом то он ВРУЧНУЮ создает датаклассы чтобы в них удобно сериализовывать json.
Вот в первых юниксах не было .h файлов и надо было структуры вручную собирать по мануалам.
Но к середине 70х уже поняли что если я делаю API то неплохо бы дать его структуры.
А теперь вот опять откатились в каменный век.
guest8 14.07.2018 19:23 # −999
roskomgovno 14.07.2018 19:26 # 0
и то и то тюринг полный язык
vistefan 14.07.2018 22:47 # +1
Вы троллите, или упорно не хотите понять роскомговна, или не знакомы с порблемой останова.
Представьте себе шаблон: Такой код уже никак не провалидировать без проверки всех вариантов ветвления.
А теперь представьте, например, такой код, и попробуйте придумать алгоритм, которым его можно было бы проверить статически:
guest8 14.07.2018 23:02 # −999
roskomgovno 14.07.2018 23:11 # +1
Это вполне себе проблема, особенно в больших шаблонах с глубокой вложенностью.
>> Каждый день отстреливаешь
Не отстреливаю. Следует-ли из этого что проблему не надо решать?
Я так же не допускаю багов _каждый_ день, значит-ли это что я могу не писать тестов?
У меня достаточно редко (ну раз в месяц где-то) бывают конфликты мерджа, значит я могу отказаться от VCS?
>> и это сразу заметно по разъёбаной верстке.
Совершенно не всегда. Я видел примеры верстки которая едет на конкретных резолюшенах, или у которой незаметно отваливается футер или проблема взлетает только при определенном поведении пользователя (ибо много клиент сайда)
Кроме того в случае XML IDE может построить дерево статически и буквально подсказать тебе какие таги ты можешь где использовать.
Anyway, если какую-то проблему можно бесплатно решать с помощью компьютера, то зачем её решать вручную?
Просто потому что я могу её решить?
Ну так я и без подсветки синтаксиса могу писать, давайте от нее откажемся.
vistefan 14.07.2018 23:35 # +1
> Проблема статической валидации парности тегов - это охуеть пиздец важная проблема?
Во-первых, если вы считаете, что это не важная проблема, зачем вы утверждаете, что она разрешима, вместо того, чтобы утверждать, что она не важна? Итак, остановились на том, что в общем случае она не разрешима.
Во-вторых, разговор идёт не о важности незакрытых тегов, а о дисциплине веб-программирования в целом. Например, нам известно, что легко было бы сделать так, чтобы все теги гарантированно были закрыты. Средства для этого давно существуют и их назвал роскомговно. Но почему-то настойчиво и во всех пунктах сообщество выбирает в пользу решений, в которых статическая проверка невозможна ни в какой мере. Так же поступает и стандарт: разрешает разработчикам так поступать, попуская незакрытые теги и так далее. В чем профит — сказать трудно, видимо всем важно, чтобы валидировалось вообще что угодно, набранное на клавиатуре, и писать сайт могли даже шимпанзе, которых я очень люблю. Если речь идёт действительно о компьютеризации приматов, я — за.
guest8 13.07.2018 19:49 # −999
roman-kashitsyn 13.07.2018 19:22 # 0
Лолчто
Язык тупой до безобразия, в либе полно всякого добра, для всяких скриптов норм подходит (уж лучше это говно, чем Python).
Desktop 13.07.2018 19:33 # −1
Мне тоже в Питонии не нравится излишняя динамичность, runtime-errors driven development и может что ещё, но для скриптов/тулзей это ок.
А по поводу серваков я в соседнем треде скинул ссылки три на бэкенд-фреймворки на Swift'е. На убунту взлетит
guest8 13.07.2018 19:41 # −999
Desktop 08.09.2018 15:51 # 0
guest8 13.07.2018 19:46 # −999
roskomgovno 13.07.2018 22:07 # 0
ну и jvm под линуксы от оралка, кмк, более серьезна чем core.net
tuberkulez 13.07.2018 21:57 # −103
Так сложно при случае воспользоваться "intval" в "PHP" или "*1" (даже не "ParseInt") в "JavaScript"?...
roskomgovno 13.07.2018 22:06 # −1
guest8 13.07.2018 22:25 # −999
guest8 13.07.2018 20:15 # −999
roskomgovno 13.07.2018 22:06 # 0
Если у тебя больше одного года опыта то ты почти никогда не нуждаешься в SO
guest8 13.07.2018 22:28 # −999
Desktop 13.07.2018 23:20 # 0
Иногда официальные доки куцы и не покрывают всех нюансов, примеры не полностью документированы, а все туториалы дальше этих самых примеров носа не суют. Это случай фирмы Эппл (см., например, CallKit)
roskomgovno 13.07.2018 23:22 # 0
Фреймворк может быть непонятен даже тому, у кого 25 лет опыта писания на этом языке.
Речь же шла о том, что если возникнет тупой вопрос по go то на него сложнее найти ответ чем на PHP./
Desktop 13.07.2018 23:28 # 0
Ну, разве что именно ты его и написал! Файка Борманда
roskomgovno 13.07.2018 23:33 # 0
Если у меня проблема со Spring, но мне пофиг на Kotlin я или на Java.
Если у меня проблема с UIKit, но разве важно пишу на свифте или на objc?
Desktop 13.07.2018 23:44 # 0
- на SO это обычно две разных категории ответов (т.е. тегов), или же в ответах есть и про то, и про другое, в самых модных случаях авторы ответов указывают варианты для обоих языков. Потому что иногда реально есть разница, ведь это же разные языки, верно?
roskomgovno 13.07.2018 23:46 # 0
>>разные языки
работа с CallKit отличается для objc и swift?
Desktop 13.07.2018 23:57 # 0
- если вопрос про фреймворк, то да.
> работа с CallKit отличается для objc и swift?
- честно не ебу, в целом API, понятное дело, одинаковый, но осознавать те же enum'ы иногда мучительно больно.
А, если говорить про фреймворки не от Apple, то там вообще иногда отдельные версии под ObjC и под Swift, в Realm вроде так.
guest8 13.07.2018 23:40 # −999
bormand 14.07.2018 03:03 # 0
З.Ы. По тем же крестам иногда приходится смотреть т.к. тонкие моменты в стандарте сложно отыскать.
roskomgovno 14.07.2018 03:06 # +1
зы:попадалась либа вообще не документирвоанная. Никак. Максимум пара примеров. В последнее время таких все больше. Думаю, надо за такие либы пиздить.
Desktop 14.07.2018 16:33 # 0
roman-kashitsyn 14.07.2018 20:03 # 0
Больше одного опыта в чём? В 80% процентов случаев я нахожу ответ пока пытаюсь сформулировать хороший вопрос на SO.
У нас ещё есть аналог SO внутри компании, я им постоянно пользуюсь, когда нужно нетривиальные вещи о работе или дизайне внутренних сервисов узнать.
guest8 14.07.2018 20:10 # −999
guest8 14.07.2018 22:32 # −999
roskomgovno 14.07.2018 22:33 # 0
guest8 14.07.2018 22:56 # −999
roskomgovno 14.07.2018 23:00 # 0
defecate-plusplus 14.07.2018 22:57 # 0
https://en.wikipedia.org/wiki/GLEAM
там не принято шутить про говно и хуи, потому что у многих кишка тонка
guest8 15.07.2018 01:13 # −999
roskomgovno 14.07.2018 20:39 # 0
в программировании.
Вы все как-то умудрились не понять что я говорю.
Собесеник сообщил что писать на go сложнее чем писать на PHP потому что ответов на вопросы по языку на SO будет меньше.
На что я сказал что обычно хорошему программисту достаточно книжки и референса по языку чтобы с ним разобраться.
Если такой программист задает вопрос на SO, то обычно он связан алгоритмами или API фреймворков, ОС итд, но не самим языком.
То-есть вопросы "как проитерироваться по такой-то коллекции" сеньёры обычно не задают.
Борманд правда отметил что с С++ это не так, ну окей: наверное в с++ можно что-то не понять в стандарте и с 10 годами опыта
>> В 80%
Ну так это же rubber duck debugging. Хороший вопрос -- половина ответа.
>>аналог SO внутри компании,
Вам везет:) У нас есть какие-то статьи на конфлюенсе, какие-то видео со внутренних выступлений и канальчик в слаке, но самое распостраненное решение это "подойти к Васе и спросить как пользоваться его сревисом". И это дико расстраивает
guest8 14.07.2018 22:50 # −999
guest8 14.07.2018 22:53 # −999
roskomgovno 14.07.2018 22:58 # 0
Ленивые все стали. Нынче не то что давеча
Desktop 13.07.2018 23:29 # 0
- прочитал как guillotine
guest8 14.07.2018 20:11 # −999
roskomgovno 14.07.2018 20:39 # 0
guest8 13.07.2018 20:17 # −999
3.14159265 13.07.2018 21:36 # −1
https://embedy.cc/movies/c0lkbEhCOWlUTzhpSUI0TFQrVlV5YU5hYjIvb1FF eGxLZEc1ZEE2blp1RT0=
Правда я не совсем понял, о питоне ты или о рнр.
guest8 13.07.2018 21:49 # −999
roskomgovno 13.07.2018 22:45 # −1
guest8 13.07.2018 22:48 # −999
roskomgovno 13.07.2018 23:08 # 0
или я сделал тоже самое с php (там вроде можно явно указывать типы) и с помощью zend скопилировал его
ну, я все еще программист на интерпретируемых япах?
кстати, у Kotlin есть repl консоль. А уж про груви я и вовсе молчу: она как-бы скриптовая но компилируетс яна лету
vistefan 14.07.2018 01:49 # 0
В то же время Java, Scala, Kotlin-программы распространяются в скомпилированном виде, и все стремятся научить свои языки компилироваться в джава-байткод для переносимости и вообще, потому что на миллиардах устройств для этого уже всё готово.
Такая мысль меня посетила, вкинул для дискуссии. Рушится вроде как об JS. Тот нихуя не переносим, и считается компилируемым при этом.
roskomgovno 14.07.2018 02:47 # 0
В юниксах это вообще классический путь. Большинство юниксов сейчас имеет предкомпилированные пакеты для большинства программ, но есть же gentoo и arch, да и бздуны делают пекеджи не из всех портов, есть слаковые slackbuilds которые тоже тянут исходники.
MasterJoda 08.09.2018 15:56 # 0
Как эротично звучит...
tuberkulez 13.07.2018 22:55 # −102
roskomgovno 13.07.2018 22:56 # +2
Хуй, подтверди!
guest8 13.07.2018 23:13 # −999
roskomgovno 13.07.2018 23:14 # 0
tuberkulez 13.07.2018 23:17 # −102
roskomgovno 13.07.2018 23:17 # 0
guest8 13.07.2018 23:33 # −999
guest8 13.07.2018 23:10 # −999
guest6 15.04.2024 18:33 # 0
3.14159265 13.07.2018 21:42 # +2
И в 2к18 лет тащить сайд-эффектные фичи сишкоязыков. В целом конечно насрать, поскольку питон дальше калькулятора не использовал.
tuberkulez 13.07.2018 21:59 # −102
И то клеймо...
roskomgovno 13.07.2018 22:05 # −1
можно подробнее?
>>and preferably only one—obvious way to do it
compared to ruby and perl -- yep
guest8 13.07.2018 22:28 # −999
guest8 13.07.2018 22:27 # −999
3.14159265 14.07.2018 13:43 # +2
guest8 14.07.2018 18:37 # −999
666_N33D135 15.07.2018 09:09 # 0
666_N33D135 14.07.2018 18:22 # 0
guest8 14.07.2018 18:37 # −999
bormand 14.07.2018 18:42 # 0
guest8 14.07.2018 19:20 # −999
roman-kashitsyn 14.07.2018 19:56 # +1
Особенно удивительно слышать такое от Борманда…
roskomgovno 14.07.2018 21:33 # 0
horizontal ellipsis? Серьезно? Ты это вручную делаешь или у тебя автозамена?
bormand 14.07.2018 21:59 # 0
roskomgovno 14.07.2018 22:12 # 0
vistefan 15.07.2018 01:51 # 0
Я тоже всегда так делаю…
roskomgovno 15.07.2018 01:58 # 0
А вот за правильные тире и кавычки вы достойны всяческих респектов. Вы еще может и ёшки ставите?
vistefan 15.07.2018 02:06 # 0
…
...
Уже за это его можно ставить. Кроме того, фанатичность и одержимость подсказывают: если многоточие считается единым знаком препинания, значит должно обозначаться одним символом. Паранойя вторит: один символ ни при каких обстоятельствах не окажется разбит на несколько строк (хотя нынче и просто точки не переносятся). Ну и, наконец, использование таких символов показывает, что я очень крутой.
Ёшки — ты имеешь ввиду буквы «ё»? Ну, у меня уже рефлекс после клавиатурных тренажёров. Я если даже захочу, с трудом получится везде «е» ставить.
roskomgovno 15.07.2018 02:12 # 0
Но, повторюсь: он мог и спиздеть.
Забавно: символ "..." используется для обозначения varargs в Java и Lua.
Лень проверять, но уверен что … там не сработает
vistefan 15.07.2018 02:34 # 0
Я тебе и без проверки скажу: не сработает, и хорошо, что не сработает. Не хватало ещё такую дрянь жрать.
roskomgovno 15.07.2018 02:36 # 0
bormand 15.07.2018 08:01 # +1
666_N33D135 14.07.2018 18:45 # 0
roskomgovno 14.07.2018 20:51 # 0
юзай dc(1)
Pa3yMHbIu_xyu 14.07.2018 05:59 # +1