Программирование, т. 8

Бтв в этой фразе из чата прям жирный намек на то что челик говнокод хуярит

пофиксить все ошибки типов (которые иногда бывают очень нетривиальными)

я ещё не видел ни раза ни от одного адепта слабой/динамической типизации привера (в виде ебаного кода, а не абстрактных концептов "нет типов = всё быстрее") где показано будет что без типов сделать быстрее чем с ними. где вы находите проблемы с типами которые надо фиксить так долго что х2 замедляется разработка?

я понимаю когда такое говорят о С++

и то, даже там со временем почти перестаёшь наталкиваться на проблемы с темплейтами которые можно по полчаса решать

но в ебаном джаваскрипте, серьёзно?

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

Бтв что замедляет въезжание в проект с тс? То что иде подсказывает тебе все доступные методы и поля? Или что когда ты юзаешь компонент в jsx, тебе не надо лезть в его имплементацию, а достаточно из автокомплита увидеть какие пропсы какого типа ему нужны?

более того, многие из них вообще тебе не важны

только не какой-то рак между строками/числами который решается одним вызовом функции str2num()/num2str() или аналогичное

я ещё не видел ни раза ни от одного адепта слабой/динамической типизации привера (в виде ебаного кода, а не абстрактных концептов "нет типов = всё быстрее") где показано будет что без типов сделать быстрее чем с ними.

видел

функция сache() которая зависимо от разного кол-ва аругментов и их типов делает три разных действия

а можно пример ошибки которая тебе сейчас не важна?

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

какие к хуям ошибки? эксепшны? или что

резолвить ошибки это про что?

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

 

кароче приведи пример

Ну вот допустим ты обьявил newRequest и присвоил ему обьект. Теперь тебе надо описать все поля обьекта, а если в них есть вложенные обьекты, то и их тоже. И если этого не сделать, то тайпскрипт скажет "Ошибка!". Идешь в отдельный файл, описываешь IGetWorkflowTasksRequest, а через пять минут понимаешь, что тебе newRequest вообще не нужен и можно по другому сделать. Any конечно есть, но у нас почему-то было принято типизировать почти все.

const newRequest: IGetWorkflowTasksRequest = {
    ...request,
    ...changedRequest,
    ...{
        paging: {
            page: 0,
            blocksize: 10
        }
    }
}

у вас проблема не с тайпскриптом, а с тем что нету навыка работы с типами

 

 

это что то на уровне "зачем мне ваши объекты если я могу процедурно и через goto всё что угодно написать в 5 раз быстрее"

я даже соглашусь что на старте это быстрее

но через 3-6 месяцев интенсивной разработки уже получаешь 100% выигрыш по скорости

 

Ну да, мне говорили "это поначалу много писать, а потом на поддержке мы выйграем, все же типизировано, понятно". Но я чет за 3 месяца выйгрыша так и не ошутил. Зато когда заходил в файл с формой и видел 40+ импортов мне хотелось паунс в окно сделать

 

а можно пример ошибки которая тебе сейчас не важна?

 

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

 

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

по мне списывать незнание работы типов на то что типы это плохо - чистой воды долбоебизм. отказ от х10 более сильного статического анализа кода потому что ты собрался 5 раз переписывать решение и не хочешь чтоб твоё текущее решение было рабочим не звучит убедительным аргументом

Ты пишешь any, а когда понимаешь, что решение финальное, обьявляешь тип, если тебе так удобнее

Ну и можно (внимание) отключить проверку типов при пересборке вебпаком, и проверять их только когда надо - у нас вот прекоммит хук на это стоит

Теперь тебе надо описать все поля обьекта, а если в них есть вложенные обьекты, то и их тоже.

а через пять минут понимаешь, что тебе newRequest вообще не нужен и можно по другому сделать.

как этот процесс происходит, ты такой думаешь "хм, надо бы ебануть реквест, мне он наверное щас понадобится" а потом выясняется что не понадобился?

и кстати чет не совсем понимаю прикола в анонимных объектах под интерфейсы, это норма в ТС так делать?

 

какие к хуям ошибки? эксепшны? или что

резолвить ошибки это про что?

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

 

кароче приведи пример

а через пять минут понимаешь, что тебе newRequest вообще не нужен и можно по другому сделать.

 

может проблема всё таки в этом? 

я хз, вообщем мне лень и у меня нет достаточной компетенции (всего 3 месяца работы), чтобы доказать что тайпскрипт замедляет работу. Это мое субьективное суждение. Я вообщем-то и писал как советует kijupsik, отключал проверку, забивал на все типы, пилил фичу, а потом перед коммитом еще пару часов описывал 100500 интерфейсов, чтобы тайпскрипт отвалил. Где тут преимущества я хз.

3 МЕСЯЦА РАБОТЫ ГОВНОДОЛБАЕБОМ ФРОНТЕНДЕРОМ И ПЫТАЕТСЯ ПИЗДЕТЬ ЧТОТО СЕНЙЬОРАМ КОТОРЫЕ СИДЯТ ТУТ

типичные жс-макаки, надеюсь вы подохните

я хз, вообщем мне лень и у меня нет достаточной компетенции (всего 3 месяца работы), чтобы доказать что тайпскрипт замедляет работу. Это мое субьективное суждение. Я вообщем-то и писал как советует kijupsik, отключал проверку, забивал на все типы, пилил фичу, а потом перед коммитом еще пару часов описывал 100500 интерфейсов, чтобы тайпскрипт отвалил. Где тут преимущества я хз.

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

 

а можно пример ошибки которая тебе сейчас не важна?

 

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

 

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

Я никак не могу запомнить кто из них там кто, ебал их нахуй, но там очевидные проблемы при конвертации одного списка в список базовых классов, а потом наоборот, тк операции не эквивалентны

 

какие к хуям ошибки? эксепшны? или что

резолвить ошибки это про что?

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

 

кароче приведи пример

Ну вот допустим ты обьявил newRequest и присвоил ему обьект. Теперь тебе надо описать все поля обьекта, а если в них есть вложенные обьекты, то и их тоже. И если этого не сделать, то тайпскрипт скажет "Ошибка!". Идешь в отдельный файл, описываешь IGetWorkflowTasksRequest, а через пять минут понимаешь, что тебе newRequest вообще не нужен и можно по другому сделать. Any конечно есть, но у нас почему-то было принято типизировать почти все.

 

const newRequest: IGetWorkflowTasksRequest = {
    ...request,
    ...changedRequest,
    ...{
        paging: {
            page: 0,
            blocksize: 10
        }
    }
}

у вас проблема не с тайпскриптом, а с тем что нету навыка работы с типами

 

 

это что то на уровне "зачем мне ваши объекты если я могу процедурно и через goto всё что угодно написать в 5 раз быстрее"

я даже соглашусь что на старте это быстрее

но через 3-6 месяцев интенсивной разработки уже получаешь 100% выигрыш по скорости

 

Ну да, мне говорили "это поначалу много писать, а потом на поддержке мы выйграем, все же типизировано, понятно". Но я чет за 3 месяца выйгрыша так и не ошутил. Зато когда заходил в файл с формой и видел 40+ импортов мне хотелось паунс в окно сделать

 

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

ведь ВНЕЗАПНО типы есть всегда, просто в жсе ты их не объявляешь, и надеешься, что все смогут прочесть твою лапшу и понять, что там, либо всё лежит в документации, которая описывает всё то же самое, только ничего не гарантирует 

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

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

GoToDefinition вполне заменяется глобальным поиском по проекту, хоть это и чуть дольше. Улучшенный автокомплит тайпскрипта штука конечно прикольная, только вот достигается она за счет программиста, который все интерфейсы опишет, что мне нафиг не сдалось. А тайпскрипт из коробки дает только автокомплит стандартных типов. Показывает мне что у массивов есть length и push, спс бро помог так помог 

 

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

 

 

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

 

джун и опыт

опыт и джун

 

 

ну и отдельный вголсяндр с • Умение адекватно оценивать трудоемкость и сроки, соблюдать эти сроки;

А разве это не изи

спрашиваешь прогера сколько времени уйдет на фул проект и умножаешь на 2 то что он скажет чтоб получить дату бета версии продукта.

С меня на работе экстимейты уже год наверное как не спрашивают, хех. Перки работы в продуктовой компании как говорится.

ну ещё бы, сидишь на подсосе у буржуев и в плейстешон играешь, что с тебя спрашивать?

В пятницу RDR2, ух работы подвалит