ОБЩИЙ БУГУРТ ТРЕД V35.0 / GENERAL BUTTHURT THREAD V35.0 /butthurt/
Аноним
# OP
26/04/21 Пнд 10:47:15
№1
@
"ИНТЕГРАЦИЯ АПИ ОТ HUEBANK.COM"
@
"ДОБАВЛЕНИЕ НОВОГО МИКРОСЕРВИСА ДЛЯ ОБРАБОТКИ ПЛАТЕЖЕЙ"
@
"ЗАМЕНА gRPC НА ОЧЕРЕДЬ СООБЩЕНИЙ ДЛЯ АСИНХРОННОЙ ОБРАБОТКИ"
@
"ИЗУЧИТЬ ВОЗМОЖНОСТЬ ПЕРЕХОДА НА ДРУГУЮ БАЗУ ДАННЫХ ДЛЯ УСКОРЕНИЯ ОБРАБОТКИ ДАННЫХ"
ЗАДАНИЯ НА ФРОНТЕНДЕ
@
"ДОБАВЬТЕ К КНОПКАМ ТЕНЬ"
@
" ДОБАВИТЬ ТАБЛИЧКУ С ДАННЫМИ, КОТОРЫЕ В ГОТОВОМ ВИДЕ ПРИЛЕТАЮТ С БЭКЕНДА"
@
"ПОМЕНЯТЬ ШРИФТ"
Прошлый >>1997490 (OP)
@
ЛЫЧКА МИДЛ-СЕНИОР
@
ПОЛУЧАЕШЬ 60К
@
НА САМОМ ДЕЛЕ ДАЖЕ 58К
ПОЛУЧАЕШЬ 150К - 200К.
@
У ТЕБЯ МНОГО ДЕНЕГ , ЕСТЬ ЗАПАСЫ ЗА 2-3 ГОДА ВЕЛСЛОВАНИЯ.
@
УВОЛЬНЯЕШЬСЯ ЧТО БЫ ОТДОХНУТЬ 1 ГОД И ПОЧУВСТВОВАТЬ СЕБЯ ЧЕЛОВЕКОМ, ИНОГДА ФРИЛАНСИШЬ НА 20К В МЕСЯЦ.
@
ВСЕ УДИВЛЯЮТСЯ КАК ТЫ ЖИВЕШЬ БЕЗ ДЕНЕГ ВЕДЬ БЕЗ РАБОТЫ НЕ ВЫЖИТЬ
@
ОХ УЖ ЭТОТ ГЕН РАБСТВА.
>Erlang
Вы ебанутые? Зачем он нужен, если есть Elixir?
@
СКОЛЬКО?!
@
ДА ТЫ КТО ТАКОЙ, ЧТОБЫ СТОЛЬКО ХОТЕТЬ?!
@
СКОЛЬКО ТЫ НА ПРОШЛОЙ РАБОТЕ ПОЛУЧАЛ?! М? НУ МАКСИМУМ ЖЕ 40К!
@
МАКСИМУМ, ЧТО МЫ МОЖЕМ ПРЕДЛОЖИТЬ, ЭТО 50К! МАК-СИ-МУМ
@
И ТО ТЫ СТОЛЬКО НЕ СТОИШЬ, У НАС ЕСТЬ КАНДИДАТ ЛУЧШЕ
@
Я ВОТ ТОЖЕ ХОЧУ ПОЛУЧАТЬ 300КК
В ДЕНЬ И ЧТО!? М? СЪЕБАЛ!
Трустори, только цифры другие. Зачем им знать мою прошлую зарплату? Почему они считают, что +10к на деле было бы не +10к, но херочка то цифру другую представляла это норм и я пойду к ним?
Бля, дружок, ну ты же понимаешь, что зарплата программистам это по сути вопрос рентабельности. Конечно же, чем меньше ты платишь программистам, тем больше шансов что твоя контора выживет. Если это галера, то это прямо сколько капитан галеры заработает на разнице. Если сразу написать вилку, то никто даже не откроет твою вакансию и не придёт поторговаться.
Ебанутые хрюши ебашат за KPI по холодным.
Единственный норм кейс: узнать сколько ты получаешь и какие премии, что бы это спрогнозировать на их ЗП и сделать норм оффер.
Но большинству похуй даже: у тебя норм резюме, опыт 3-5 лет, ожидаемая зп 300к, сеньер, который поймал всех покемонов в своем стаке.
И тебе каждый день пишут,
Привет, у нас тут интересный энтерпрайз на паскале, не хочешь вкатится за 20к/месяц?
Вилки пишут только те, кто уверены, что у них они хорошие.
Иначе будут морозится, обещать соц. пакет и комфортные условия и все такое.
Плюс в галерах и мелких шарашках, где тимлид/владелец бизнеса/HR это один человек, зп у Васи который ему нравится и Пети который хуй с горы могут отличается очень сильно, при нулевой разнице с точки зрения скиллов/опыта/пользы и прочего.
Если у тебя жирное резюме и ты умеешь себя продавать, то в хорошем стартапе/галере ты можешь хорошо умножить свою зп.
Если нет, то пиздуй в тырпрайз, там тебя оценят, выдадут грейд и соответствующее ему бабло
РАЗРОБИТЧАНЕ
Ору что ненормальный, хоть и сам хохол
Нет, первый это "готовы ли вы выполнить небольшое тестовое?".
Вообще в вакансии была указана вилка, я назвал цифру чуть ниже максимальной планки, а хрюша пыталась продавить меня ниже нижней планки, а когда я спрашивал, как это так получается, она говорила, что это не для меня написано, а для опытных мужиков.
>Бля, дружок, ну ты же понимаешь, что зарплата программистам это по сути вопрос рентабельности.
Нет, не только. Зарплата это ещё вопрос статуса внутри иерархии, то есть обозначение, насколько сотрудник ценных, привязка именно к себе и т.п.
Производительность программистов может отличаться на порядок, ещё куча моментов по качеству кода, насколько вписываешься в коллектив, с тобой другие лучше или хуже начинают работать.
Это у водителя-дальнобойщика или продавца в пятёрочке более-менее предсказуемая производительность труда и легко контролируемая. Но не на таких сложных специальностях, как программирование.
Поэтому подход индивидуальный.
>ко мне относились
Судя по тому, как ты пишешь сюда, возможно адекватно относились.
>>2009256
>Есть какой-то другой опыт, который в резюме силу имеет?
Есть, если ты до того, как пошёл работать программистом, много занимался программированием, там в университетских лабах и т.п., что-то для себя делал, то это большая разница с тем, если у тебя такого бэкграунда не было.
Но, это не совсем коммерческий опыт, зона риска, и поэтому просьба выполнить тестовое оправдано.
>На тот момент год был.
Классический джун-опыт. Ещё хороший вопрос, чем ты до этого занимался. Но аппломб у тебя такой, как будто ты уже такой матёрый программер-волк, перед которым должны дрожать и умолять тебя пойти к себе, потому что у тебя есть аж целый год опыта работы.
Ходит по собесам, самый ебанутый вопрос от хрюши был,
ВАСЯН, ТЫ ВОТ ДЖВАДЦАТЬ ЛЕТ НАЗАД ИЗ ПОЛИТЕХА В ГОСУДАРСТВЕННЫЙ ПЕРЕКАТИЛСЯ НА ВТОРОМ КУРСЕ, С ЧЕМ ЭТ СВЯЗАННО.
Вот не похуй ли что там было у чела с опытом работы в миллион лет?
> Но аппломб у тебя такой
Хрюша, ты?
> Есть, если ты до того, как пошёл работать программистом, много занимался программированием, там в университетских лабах и т.п., что-то для себя делал, то это большая разница с тем, если у тебя такого бэкграунда не было.
Это у каждого первого выпускника скиллбрейнса есть. Ценность нулевая.
>>2009308
Все-таки не везде.
ФРОНТЕНДЕР В 2000 - КРАСИТ КНОПКУ, РАМКИ И РАССТАВЛЯЕТ КАРТИНКИ
@
ФРОНТЕДНЕР В 2021: ПИШЕТ БЕК, РИСУЕТ И КРУТИТ ДЕРЕВЬЯ, РЕШАЕТ АЛГОРИТМИЧЕСКИЕ ЗАДАЧКИ, ОПТИМИЗИРУЕТ КОД, ПИШЕТ 10 УРОВНЕЙ АБСТРАКЦИЙ НА ts, ПРИМЕНЯЕТ ПАТТЕРНЫ
@
ФРОНТ В 2030: НАСТОЛЬГИРАЕТ КАК ХОРОШО КОГДА СУЩЕСТВОВАЛИ БЕКЕНДЕРЫ И ОНИ ПОМОГАЛИ ИМ ДЕЛАТЬ ЧАТСЬ ЗАДАЧ НА СТОРОНЕ БЕКЕНДА.
@
ВЕЗДЕ НУЖНЫ ЗНАНИЯ ФРОНТА
@
НЕ ЗНАЕШЬ КАК ВКАТИТЬСЯ В БЭКЕНД
@
ВКАТЫВАЕШЬСЯ ВО ФРОНТЭНД
анти анти
@
ВКАТИЛСЯ В БЕКЕНД
@
УВИДЕЛ ЧТО ФРОНТ ИМЕЕТ 190 РОСТ И ХОРОШУЮ ПРИЧЕСКУ К НЕМУ ЛИПНУТ ТЯНОЧКИ.
@
УНИЖАЕШЬ ФРОНТОВ ОТПРАВЛЯЯ ИМ НЕУДОБНЫЕ API, ДОКАЗЫВАШЕЬ ЧТО ТЫ НАСТОЯЩИЙ ПРОГРАММИСТ
@
ФРОНТЫ УВОЛЬНЯЮТСЯ, А НОВЫЕ ЛИВАЮТ В ТЕЧЕНИИ 2 МЕСЯЦЕВ.
@
ТЕБЯ ЗАСТАВЛЯЮТ ПОДУЧИТЬ ФРОНТ ЧТО БЫ СПАСТИ ПРОЕКТ
ДЕЛАЕШЬ ФРОНТЫ НА TYPESCRIPT В ТЕЧЕНИИ 3 ЛЕТ, ДО СИХ ПОР НЕ ПОНИМАЕШЬ ВСЕХ ТОНКОСТЕЙ И "МАГИИ" ФОРМОШЛЕПСТВА, КУЧА ТОНКОСТЕЙ И ВСЕ ШАТКОЕ КАК СОЛОМИНКА
@
РЕШИЛ ПОТЫКАТЬ БЕКЕНД, БЫСТРО РАЗОБРАЛСЯ ВСЕ ЛОГИЧНО
@
ЧЕРЕЗ 3 МЕСЯЦА СТАЛ СЕНЬЕР БЕКЕНД РАЗРАБОТЧИКОМ И ОЩУЩАЕШЬ КАЙФ ОТ ТОГО КАК ЖЕ ЛЕГКО СТАЛО ПРОГРАММИРОВАТЬ
@
ЧИТАЕШЬ ТРИ СТРАНИЦЫ ОБЕСЦЕНИВАНИЯ ЧУЖОГО ТРУДА
@
ВЕЗДЕ "ВКАТИЛСЯ ЗА ТРИ СЕКУНДЫ"
@
"ЭТА РАБОТА ДЛЯ ДАУНОВ"
@
"СКОРО ВАС ЗАМЕНЯТ"
@
А ВОТ У МЕНЯ
@
А ВОТ Я ВАЖНЫЙ И НУЖНЫЙ
- В макоси работает;
- В рековери работает;
- В загрузчике (который по зажатиу Option) не работает.
- В сетевом восстановлении тоже.
Я уже изгуглил весь интернет и тамошние issues, никто ничего не знает, никому не нужно видимо. Было предположение, что виноват размер пакета USB, но они не подтверждаются. Кроме того, дело явно не в HID-дескрипторе, потому что в бут-режиме мышка его вообще не должна использовать, а если отдает репорт - то должна нормально работать. Я взял рисовальный планшет диванон лол, подключил его - и он отлично работает в загрузчике как мышка, хотя там и используется хитрожопый дескриптор.
Короче, мне надо как-то посмотреть, как ебучий загрузчик мака видит мой USB-девайс и хули ему нравится клавиатура, но не нравится мышка. INB4 покупать аппаратный анализатор протокола (хотя придется, видимо).
@
ЛИПНУТ ТЯНОЧКИ С ХОРОШИМ ФРОНТЭНДОМ
@
ПОМЫЛСЯ
https://www.npmjs.com/package/is-even
держи вдогонку
https://github.com/jonschlinkert/split-string/blob/master/index.js
Кто пустил говнокодера в жс?
>Several years ago I switched careers from sales, marketing and consulting to learn how to program, with the goal of making the world a better place through code. Whether that means giving people access to information, the tools and technology to level the playing field with big corporations, or empowering people in impoverished regions to participate in the world economy.
Он сам вкатился.
НАЧИНАЕШЬ ЗАГОНЯТЬСЯ ЧТО ДЕНЬГИ КОНЧАЮТСЯ, УЖЕ ЧЕРЕЗ ПОЛГОДА
@
СУДОРОЖНО ИЩЕШЬ РАБОТУ
@
КОНТОРЫ ПРЕДАЛАГАЮТ ТЕБЕ ОТСТОЙНЕЙШИЕ ПОЗИЦИИ
@
ПО ИХ МНЕНИЮ, ТЕБЯ ПРОСТО ВЫГНАЛИ С РАБОТЫ В РАЗГАР КОРОНЫ
@
КАТЯ, СМОТРИ, ЭТОТ ДОДИК ПОЛГОДА ОФИЦИАЛЬНО НЕ УСТРОЕН
@
НЕСИ ВАКАНСИЮ СТРОНГ ДЖУНА
И, нет, пункт про "фриланс" не помог. Даже с описанием, чего делал. Пришлось устроиться сначала в стремноватое место, а уже из него, через полгода, выпрыгнуть в хорошее.
Не повторяйте моих ошибок, аноны.
@
ВПЕРВЫЕ
@
СУДОРОЖНО ИЩЕЩЬ, ГДЕ ВКЛЮЧИТЬ
@
КАКОЙ МОНИТОР ВКЛЮЧИТСЯ, НА ПЕРВОМ НЕРЕЛЕЙТЕД ХУЕТА И ТО, ЧТО ЛУЧШЕ БЫ НЕ ВИДЕТЬ ЗАКАЗЧИКУ МЕСТО РАБОТЫ, НАПРИМЕР
@
ВДРУГ МНЕ НАПИШУТ ЧТО-ТО И ОПОВЕЩЕНИЕ ВЫЛЕЗЕТ?
@
ТАК, ВТОРОЙ МОНИТОР, А МОЖНО ЛИ БРАУЗЕРЫ МЕНЯТЬ?
@
БЛЯЯЯ, АНИМЕ В ЗАКЛАДКАХ
@
СТИМ В ЗАКРЕПЛЕННЫХ, ПИЗДОС
@
ТАК, ПАПКУ С ПРОНОМ Я ЗАРАНЕЕ УБРАЛ, ДА?
@
ETC
В том и ирония, что нее кончились. Их ещё на год-полтора бы хватило.
Просто привыкаешь к тому что запасы каждый месяц растут, а тут наоборот, начинают уменьшаться. Непривычно.
Начинаешь мучить себя мыслями, мол "а вдруг Пыня окончательно поедет кукухой и нужны будут запасы побольше и срочная релокация", "а вдруг вся эта короновирусная канитель сломает рынок на годы вперёд и надо сейчас собрать запас".
Нормальный человек таких бед с башкой, наверное, не имеет, но если привык копить и смотреть в будущее - можешь и на измену подсесть.
https://github.com/i-voted-for-trump/is-odd/blob/master/index.js
Если внимательно посмотреть на код - по сути там сплошные защиты от дурака непонятно зачем и требование СТРОГОГО соответствия типов. Пакет действительно какой-то дэбильный.
> I created this in 2014, the year I learned how to program.
Не все поняли шутку, видимо.
Двачую, нехуй качать порнуху через торрент. И кроме того...
СТИМ В ЗАКРЕПЕ
@
ПОХУЙ, В НЕРАБОЧЕЕ ВРЕМЯ
@
АНИМЕ В ЗАКЛАДКАХ
@
ЗАКАЗЧИК НЕ ПРОТИВ
@
ОПОВЕЩЕНИЯ
@
ПОХУЙ, ТОЛЬКО НА ТЕЛЕФОНЕ
@
ПАПКА С ПРОНОМ
@
ЗАКОПАНА ПО СТАРОЙ ПРИВЫЧКЕ
@
ТОРРЕНТ ОТКЛЮЧЕН, ПОТОМУ ЧТО ЗАКАЗЧИК ПОДКЛЮЧАЕТСЯ С ВПН
@
@
ВСЕ-ТАКИ ВЫЛЕЗЛО ЧТО-О НЕПОТРЕБНОЕ
@
ПОКРАСНЕЛ, СТРЕМИТЕЛЬНО СНЁС, ИЗВИНИЛСЯ
@
ПРОДОЛЖИЛ
@
ЧЕРЕЗ СЕКУНДУ ВСЕ ВСЁ ЗАБЫЛИ
@
АНТИБУГУРТ
>ЧЕРЕЗ СЕКУНДУ ВСЕ ВСЁ ЗАБЫЛИ
@
САМ ВСПОМИНАЕШЬ ЭТОТ МОМЕНТ ВСЮ ЖИЗНЬ
@
УВОЛЬНЯЕШЬСЯ С РАБОТЫ
@
СПИВАЕШЬСЯ
@
УМИРАЯ ЗА ГАРАЖАМИ ДУМАЕШЬ КАК БЫ СЛОЖИЛАСЬ ТВОЯ ЖИЗНЬ ЕСЛИ БЫ ТЫ ТОГДА ВЫКЛЮЧИЛ УВЕДОМЛЕНИЯ
Поясните за космический эффект
Поясните свифтобогу в чем суть, x % 2 !== 0 реально не будет нормально работать и нужно какой-то гиморой тащить чтобы проверок типов нахуячить, или джсерам просто лень ремайндеры учить и они гуглят либы по названиям нужных функций? Там ведь реально охуилиард инсталлов, небось петушки с такой популярность потом на конфах нонстоп выступают и рассказывают сакксесс стори как побороли позавчера трудный хэллоуворд на интервью, а крутым дрочилам типа этого анона >>2009819 даже на его вопрос никто нигде не ответит.
с похуй фэйсом на демо шарю экран где на фоне симулятора был открыт какой то срач в зекаче.
шучу конечно, до сих пор стыдно, зря я тогда поленился просунуть руку и второй моник подключить.
А так обычно заранее готовлюсь и весь нерелейтед закрываю/сворачиваю, на маке еще боевые пикчи если схоронять потом в доке последняя видна, тоже можно подорваться.
>"фриланс" не помог
Есть куча других отмазок.
Может ты реально слабый специалист?
В ГЭПЧИКЕ 7 месяц, хрюши зовут на собесы.
Всем говорю что были личные дела.
Иногда хожу и получаю офферы
>ТЕБЯ ПРОСТО ВЫГНАЛИ С РАБОТЫ В РАЗГАР КОРОНЫ
Работал в хорошим компаниях в течении 6 лет. а тут ты вдруг уволился с последней и плохой?
>КАТЯ, СМОТРИ, ЭТОТ ДОДИК ПОЛГОДА ОФИЦИАЛЬНО НЕ УСТРОЕН
Скорей так:
КАТЯ, ОН МОЖЕТ УСТРОИТСЯ К НАМ В ТЕЧЕНИИ 2 ДНЕЙ, МЫ СМОЖЕМ УЖЕ НАКОНЕЦ ЗАКРЫТЬ ВАКАНСИЮ ГДЕ ИЩЕМ МИДЛА 5 МЕСЯЦЕВ.
ТЫ НЕ ГЕПЕР, ТЫ ЧУЖОК-ДЖУН КАКОЙ-ТО
За дрочилу спасибо, но, видимо, да, никто не ответит. Я за последний год столько всякой хуйни повидал, и по большей части уникальных проблем, с которыми раньше никто не сталкивался. Два раза даже сталкивался с тем, что баг оказался не багом, а дефектом кремния в конкретном процессоре))) Весело пиздец.
>ЗАДАНИЯ НА ФРОНТЕНДЕ
Сейчас фронт всё больше на разработку приложений похож. Я на одном из проектов вообще с браузерным 3Д движком работал. Да, работал с тенями кстати, но в совершенно другом ключе
>Бля, как щас помню на работе лид подошел, а я окна переключал и оконный менеджер подвис, на секунд 5 остался сайт с проститутками на весь экран. Сделали вид, что никто ничего не заметил.
На собесе переключился на другой тэг в тайловом менеджере, а там у меня на весь экран растянув рогатку лежала краля недодроченная
Тогда у каждой шараги был сайт. Сейчас же страничка в инсте или вк приносит куда больше профита и отдельные сайты стали не нужны. Плюс в 2000 году даже хтмл-погромистов было настолько мало, что работы хватало. Никаких блять курсов для хипстеров не было, институты выпускали кодеров на дельфи, ну в лучшем случае на С++. А сайты бизнесу были нужны. Ну или бизнес думал, что нужны, не важно.
Я бы мог назвать контору, в которой сейчас тружусь, но делать это на дваче, рандомному кловану, который непременно затребует доказательства вплоть до слепка ануса - такое себе.
Просто скажу, что инструменты, которые она делает, ты с большой вероятностью каждый день юзаешь, если кодер.
"и получаю офферы"
"Хачапури торговал, куртками торговал, Соней торговал и имел уважение"
Получать офферы не проблема. Проблема получать лучшие офферы. Понятно что в условный Сбер тебя и из канавы возьмут. Хотя, насчёт именно тебя, не уверен.
'use strict';
var isOdd = require('is-odd');
module.exports = function isEven(i) {
return !isOdd(i);
};
is-odd
'use strict';
const isNumber = require('is-number');
module.exports = function isOdd(value) {
const n = Math.abs(value);
if (!isNumber(n)) {
throw new TypeError('expected a number');
}
if (!Number.isInteger(n)) {
throw new Error('expected an integer');
}
if (!Number.isSafeInteger(n)) {
throw new Error('value exceeds maximum safe integer');
}
return (n % 2) === 1;
};
is-number
'use strict';
module.exports = function(num) {
if (typeof num === 'number') {
return num - num === 0;
}
if (typeof num === 'string' && num.trim() !== '') {
return Number.isFinite ? Number.isFinite(+num) : isFinite(+num);
}
return false;
};
Лучшие офферы получают лучшие программисты, ты не лучший программист который отрывают с руками, признай это.
И это самая главная причина отказов.
Меня берут практически в любую компанию, вот буквально вчера был на собесе и получил еще 1 оффер, хрюша даже не спросила почему я не работал 7 месяцев.
ты сама как помидор сильно бы расстроился что кандидат позволил себе отдых?
Думаю нет, а программистов берут на работу не хрюши, а помидоры, которые проводят у тебя собесы.
@
ОБОЖАЮ ИГРЫ, ВКАТЫВАЮСЬ!
@
БУДУ ДАРИТЬ ЛЮДЯМ РАДОСТЬ!
@
ВКАТИЛСЯ
@
ДЕЛАЕШЬ ПИКРИЛ
@
ФУЛЛСТЕЧИШЬ КАК УБЛЮДОК
@
ЗАДАЧ ЧИСТО ПО ФРОНТУ ПОЧТИ НЕТ
Сейм?
>при этом еще не платят нихуя
Потому что вы макаки. Хуле вы тут выебывайтесь тем, что бэкенд пишите. Там все задачи уровня скопипастить с доки и со стак оверфлоу, на той залупе, что вы пишите в промышленном программировании. Так же как и у фронтендеров.
Вы вообще скорее всего на пхп странички отправляете, вот вам и не платят нихера, дебилы чсвшные блять.
Понимаю что тред ироничный. Но знающие аноны знают что бэкэндеры никому не нужны в 2021.
@
ТЫ СЪЕБАЛ ЧЕРЕЗ МИНУТУ
@
ЧУВСТВУЕШЬ, ЧТО КИНУЛ МУЖИКОВ
@
ТАМ В ЧАС НОЧИ МЕНЕДЖЕРКА ПИШЕТ ПО ТАСКУ ОДНОМУ КОЛЛЕГЕ
@
ПОТОМУ ЧТО ОН ЕЁ ДЕЛАЕТ В ЧАС НОЧИ И ОТВЕЧАЕТ
Не хочу перерабатывать, как они...
В моём городе вакансий на бек больше, чем на фронт - одна джава, сисярп, пхп, пайтон. На фронт есть, но только для миддлов. На джунов-фронтов вообще вакансий ноль, тупо нет ничего. Вот и все пруфы. Я сам хотел во фронта вкатиться, в итоге переквалифицировался в джависта.
>Небось isEqual будешь из npm тоже ставить, шизик?
Ты сначала спецификацию на свой маня isEqual предоставь, а потом попробуй убедить меня в том, что твоя спецификация правильна.
Как твой isEqual должен вести себя с рекурсивными ссылочными типами? Как должна обрабаываться логика тайпкаста внутри твоего isEqual (valueOf, Symbol.toPrimitive), в какой приоритетности? Как твой isEqal должен реагировать на прокси? А на prototyped-proxy?
>Сишка: ctype.h, wctype.h. Ебаный вагон всяких чекеров, например islower() и iswlower().
...которые работают только на единичные символы, а не на строки
>Питон: str.*, например str.lower()
...который является переводом строки в нижний регистр, а не проверкой регистра, и в жсе точно так же присутствует в виде String#toLowerCase
Оправдания, обосрун.
А какая разница, если речь идет о том, что проверки строк на регистр ни в одной стандартной библиотеке ни одного языка нет? Если тебе нужно писать цикл и проверять каждый символ по отдельности, то это нихуя не встроенная проверка строк, еще бы по байтам там дрочился. Тогда уже легче просто регулярку написать с \p{Lowercase}, вот тебе и "встроенная" проверка.
> ...которые работают только на единичные символы, а не на строки
Потому что в си нет строкового типа, еблан. Есть соглашение про нуль-терминированные строки, и есть "кубики" для работы с отдельными символами, из которых ты можешь собрать все что тебе нужно с помощью макросов, инлайнов и чего угодно.
> ...который является переводом строки в нижний регистр
Опечатка. str.islower() в питоне, разумеется. В любом случае, он есть, как есть и isalpha, isnumber и прочие, действующие на целую строку
Побежал оправдываться, джун.
>Небось isEqual будешь из npm тоже ставить, шизик?
В жсе нет и не может быть однозначной проверки на равенство, потому что там 1) ебанутая система объектов и их свойств. 2) нет отдельной структуры для хешмап. В любом ОО-языке ты по очевидным причинам должен сам писать реализацию isEqual для своих кастомных классов/объектов, но там обычно есть отдельный тип для хешмап, у которых эта реализация написана. В жсе такого нет, и любой объект по сути кастомный и язык в жизни не сможет угадать, что ты в него понасовал и как его сравнивать с другими.
> ...но зачем-то ты его приводишь в пример в разговоре о сравнении строк, еблан.
Затем, чтобы показать тебе альтернативный подход, еблан.
> Молодец, один язык нашел, ищи второй, а то пока как-то слабо получается.
> РРРЯЯЯ ТВОЙ ПРУФ НЕ ПРУФ.
Напоминаю: твоим утверждением было, что "проверки строк на регистр ни в одной стандартной библиотеке ни одного языка нет". Я тебе нашел ровно один язык, как ты и просил, и опроверг твое утверждение. Слив засчитан, еблан. Остальные языки ты побежишь сейчас искать сам, если оно тебе надо. Моя задача была лишь наглядно подсветить твою некомпетентность, что я с успехом и проделал.
>Напоминаю: твоим утверждением было, что "проверки строк на регистр ни в одной стандартной библиотеке ни одного языка нет"
Моим изначальным утверждением было то, что этот функционал нахуй не нужен в стандартной библиотеке, и то, что языки правильно делают, что не включают его. Оно остается как осталось. Про "ни один" так и быть, разрешу тебе "опровергнуть" эту гиперболу, раз ты как стандартный дебил-буковоед влез в разговор посередине, ухватившись за одну фразу, без малейшей идеи, о чем идет речь и почему.
Начались виляния жопой. Обосрался - имей силы признать, раз ты нихуя не знаешь кроме своего JS.
Что до твоего изначального утверждения, то оно уже само по себе хуита, потому что достаточно погуглить и увидеть, что проверка на lowercase, как на другие вещи, типа isdigit - достаточно распространенный кейс, чтобы его игнорировать. Настолько, что его частенько прицепляют к библиотеке, как расширение. Как в шарпе, например.
Обоснование тут очень простое. Например ты хочешь провалидировать строку и узнать, что там только числовые значения. Для этого ты берешь isdigit и применяешь его к строке. Если есть метод на строковый объект, то вся валидация закончится на вызове одной функции. Если нет - придется итерироваться. легко увидеть, что наличие стандартной функции строки укорачивает твой код и позволяет не писать кучу хлама в свой собственный utils. Кроме того, нельзя забывать, что готовые функции удобно использовать для передачи по в другие, скажем, в map(), без необходимости городить лямбды.
Итак, я наглядно показал нужность строковой функции isdigit. islower может понадобиться именно для этих же телей, не говоря уже о том, что с точки зрения единообразия нет смысла выбирать, какие чекеры включать в стандартную библиотеку, а какие - нет.
Тебе бумажное полотенце дать, чтобы ты обтерся, или сначала мыться под струю пойдешь?
На самом деле не понятно, зачем нужна проверка на регистр в стандартной библиотеке. Не помню, чтобы когда-то таким пользовался.
Если вдруг надо, то в JS ты можешь сделать
if (string == string.toLowerCase())
что и будет аналогом isLowerCase()
В общем конкретно это полная мелочь и ерунда. JS проблемная платформа, из-за стандартной библиотеки в том числе, но всё-таки там главные проблемы из-за стандартной системы типов, вот где жопа. Но там сложно что-то менять из-за требований к обратной совместимости.
>Например ты хочешь провалидировать строку и узнать, что там только числовые значения. Для этого ты берешь isdigit и применяешь его к строке.
isdigit это очень разумная вещь. islower вряд ли, то есть мне сложно представить случай, когда надо только проверить, а приводить не надо, и только на нижний регистр, без проверки других допустимых символов. На практике тебе проверять, чтобы там не было не нужных спецсимволов, был только стандартный латинский алфавит без умляутов и кириллицы, и т.п.
Конкретно в питоне это получилось естественным путем, так как там нет разницы между строкой и одним символом. Так что их islower просто работает на любом количестве символов, но чаще используется на одном. С другой стороны, если ты делаешь стандартную либу со строками, то было бы странно включить туда строковый isdigit, и не включить islower хотя бы с точки зрения единообразного интерфейса.
>я наглядно показал нужность строковой функции isdigit
Спорное утверждение, но гораздо более интересен тот факт, что ты по какой-то причине решил показывать не полезность той конкретной функции, о которой мы говорим, а абсолютно другой, не относящейся к ней, и используемой для других целей. Не уточнишь, почему тебе понадобилась дешевая и ложная аналогия в качестве аргумента, и почему ты не начал с(и не закончил на) демонстрации полезности и нужности конкретной функции проверки регистра, которую мы и обсуждали?
> Спорное утверждение
Нет
> почему
По твоему пустому качану. Я черным по серому ясно написал: для единообразия. Мне строковый islower без нужды, хотя ему можно найти применение в специфичесикх случаях. Основной поинт я уже подробно раписал: когда ты проектируешь библиотеку, ты не должен выбирать среди класса функций, что включать туда, а что - нет.
>Основной поинт я уже подробно раписал: когда ты проектируешь библиотеку, ты не должен выбирать среди класса функций, что включать туда, а что - нет.
Какого еще "класса" функций, где ты эти классы нашел и как отделил от "ненужных"? Вот есть класс символов - кириллица. Давай по твоей логике включим в стандартную библиотеку метод isCyrillic, и еще метод isCyrillicRussian, и еще десяток штук. Мне они конечно не нужны, но нельзя выбирать среди класса функций, что включать, а что нет, так что включаем.
Скажи честно, ты долбоеб или просто троллишь тупостью? Есть устоявшийся набор чекеров для одиночных символов. Во всех языках он плюс-минус одинаковый. Если ты делаешь библиотеку строковых чекеров такого же плана, то просто переноси все один к одному, и не решай за разработчика, что ему нужно, а что - нет.
>Есть устоявшийся набор чекеров для одиночных символов. Во всех языках он плюс-минус одинаковый
Так а где этот набор и в каких языках, показывай? Пока мы выяснили, что даже проверку на регистр ты сумел найти только в питоне и сях нахуй, что уж там говорить про остальное.
Пока что мы выяснили, что ты активно пытаешься вилять жопой и съехать с темы, в которой обосрался. Ты просил тебе найти ОДИН язык - я тебе нашел. Обтекай.
Берем сишечку, смотрим список is* функций в ctype.h. Открываем другие языки. Видим примерно то же самое. Вот это и будет устоявшимся набором.
Тебя кто из магазиностроительного выпустил, животное?
Надо смотреть на внутреннюю реализацию. В кишках может быть всё не так очевидно. Например, у тебя вообще может не быть таблицы со свойствами регистра, а может быть только таблица для перекодировки вниз-вверх.
В общем мне кажется, что тут слишком редкий случай, слишком малый профит и слишком простая альтернатива, чтобы грузить этим требования к стандартной библиотеке. Причём из-за этой функции могут быть какие-то подводные камни, как вести себя на каком-нибудь вьетнамском алфавите и т.п., где может быть неопределённым регистр, а возвращать какой-то результат надо.
Лучше не делать лишнего и ненужного, из-за чего потом могут быть проблемы.
>Ты просил тебе найти ОДИН язык - я тебе нашел. Обтекай.
См. >>2015483
>Берем сишечку, смотрим список is* функций в ctype.h. Открываем другие языки. Видим примерно то же самое
1) Какие языки?
2) Что "то же самое"?
3) Почему "примерно"? Неужели они не следовали твоему совету и о ужас, не включили что-то из твоего универсального несуществующего списка чар чекеров?
> См.
Ну я и говорю. Ты обосрался - пытаешься вилять жопой.
Ты, видимо, совсем уебан. Я выдал тебе направление исследований. Иди изучай.
> Почему "примерно"
Оставлю тебе этот вопрос в виде домашнего задания.
Видишь ли, ты уже спалился, что кроме жаваскрипта ничего не знаешь, даже банальный питон на базовом уровне. Я не вижу смысла дискутировать с безграмотной магазиностроительной макакой.
Пока только ты тут за разработчиков жса и на жсе решаешь что им нужно а что нет.
Мне вот лично тоже изловер не пригодился наверное ни разу за всю жизнь, если и нужны какие-то проверки такого рода, то это обычно регулярка с еще 10ю условиями.
2 года фриланса, 2 года опыта фулстеком, 3 года беком на скале
>>2015630
Согласен, на самом деле многие библиотеки или например ФП утилити (в JS'е в том числе, можно глянуть исходники ramda.js) написаны очень императивно под капотом, чтобы выжать производительность на нижнем уровне. Зато на верхнем няшный код.
С другой стороны - приведенный пример с toLower не совсем в этой категории, это уже нанооптимизации, которые ну никак не повлияют в проекте, будь у тебя хоть каждый requestAnimationFrame вызов toLower.
Война и мир вся целиком это всего несколько мегабайт текста. Ни о чём вообще, какие-то миллисекунды вертеть регистром. Страницу рендерить намного сложнее и дороже.
Сейчас нет проблемы в плане производительности по обработке текста. Производительность актуальна совсем в других местах.
И твой код с посимвольным перебором проиграет, потому как ты всю логику вынесешь в юзер сайд, в то время когда в изначальном варианте используются нативные оптимизированные функции.
Даже чтобы пройтись по строке посимвольно циклом, с учетом того, что строки юникодные, ты уже проиграешь в производительности, пока будешь расчехлять строку, которую движок будет преобразоываать под капотом в объект, создавать отдельные субстроки, кушать память, потом вызывать gc миллионы раз.
Функция вроде toLowerCase() работает довольно быстро. Посмотрел, текст Войны и мира, вместе с оглавлением, предисловием, десятками страниц комментариев, в сумме 3597849 юникод-символов, toLowerCase() делает за 35-40 миллисекунд, на nodejs, на старом ноуте.
О чём тут говорить вообще? И как часто нужно переводить данные такого размера в нижний регистр?
Ты дурак? Для тебя ничего сложнее сишечки не существует, даже плюсов не существует?
Ты понимаешь, как устроены объекты и массивы в сложных языках программирования, вот чтобы не Си с примитивными типами?
Вот что такое массив [1, 2, 3] в JS? Ты его побайтово с массивом [1, 2, 3] будешь сравнивать?
Иди отсюдова в свой каменный век.
В норме сравнение имеет смысл только для тех объектов, которые можно скопировать и сериализовать. Например в JSON.
В JS внутри используется принцип, что объекты приводятся к строке и потом уже строки сравниваются. Поэтому
[1, 3] == '1,3'
Было бы просто сравнивать JSON представление объекта, но разрабы JS тут подставили жопу вместо лица - у тебя объекты {'a' : 'a', 'b' : 'b'}, {'b' : 'b', 'a' : 'a'} будут разное представление иметь, потому что разный порядок определения элементов, и изменить его каким-нибудь ключём sortKeys для JSON.stringify() нельзя.
Поэтому для сравнения базовых простых объектов тебе надо пилить своё собственное кастом-сравнение.
Ты дурак, который наверное даже с указателями в сях ещё не разобрался.
Поэтому не понимаешь, что в языках высокого уровня работают с объектами, то есть адресами. А данные реально хранятся в хеш-мапах, причём тоже не напрямую, а там адреса.
Два разных адреса могут указывать на два разных объекта, которые фактически одинаковые.
И вот хрен ты так просто что-то сравнишь.
[[1,2], [3,4]] == [[1,2],[3,4]] по-твоему?
Это ты побайтово сравнивать собираешься?
Ты это даже в сишечке так просто не сравнишь, когда у тебя два массива указателей на int, например.
Ламер-недоучка ты, услышал умные слова, а смысл того, что за ними стоит, не понимаешь. Вот кто ты.
Но это проблема строкового представления. И проблема JS как платформы.
Потому что для меня, разработчика, кто с этими объектами работает, это одинаковые объекты. И мне нужен инструмент, чтобы я быстро и максимально нативно мог такие объекты сравнивать. А их нет, и вот это жопа, потому что задача как раз очень бытовая, в отличии от надуманного isLoserCase()
// Мимосишник
Возможно, когда жопаскрипт только появился, это имело смысл. Веб тогда был нестандартизованным, и было сложно писать сайты так, чтобы они работали везде настолько, нксколько это возможно, на фоне этого стратегия "если что-то сломалось - проглотить и продолжать работать" выглядит более жизнеспособной, чем падать на первой ошибке. Но сейчас времена другие, и от убогой слабой типизации можно было бы отказаться, как и от попыток рендерить невалидный html.
Теперь уже отказ от слабой типизации - ниибаца проблема из-за того, вы выросли JS-макаки, которые считают это нормой, как некоторые уебашки выше по треду. Когда веб зарождался, надо было сразу делать нормально. Нерабочие сайты быстро бы фиксились или теряли посетителей.
КУЧА МУДАКОВ
@
КОТОРЫЕ НЕ ПИШУТ НА ЖС
@
С ВИДОМ НАХОХЛИВШЕГОСЯ ПОНАСЕНКОВА
@
РАССУЖДАЮТ О ПРОБЛЕМАХ ЖС
@
КАК ИМ КАЖЕТСЯ БЛЕЩУТ УМОМ ЗА КИЛОМЕТР
@
ПРИВОДЯТ В ПРИМЕР ЛЕГАСИ ПРИВЕДЕНИЕ ТИПОВ
@
И ПАКЕТЫ ОТ ИНДУСОВ ОДНОСТРОЧНИКИ С МАЛВАРЬЮ
@
ЯКОБЫ ВСЕ ЖСЕРЫ ВСЕМ ЭТИМ ПОЛЬЗУЮТСЯ
@
ЧТО-ТО НЕСВЯЗНОЕ ВЯКАЮТ ПРО ПРОТОТИПЫ
@
НА ЭТОМ ПОЗНАНИЯ ЗАКАНЧИВАЮТСЯ
@
ТЫ МУЛЬТИЯЗЫЧНЫЙ ПРОГРАММИСТ
@
МОЖЕШЬ КЕКНУТЬ С МЕМА ПРО ЖС
@
НО КОГДА НУЖНО СДЕЛАТЬ ПРИЛОЖЕНИЕ ТЕБЕ ПОХУЙ
@
ПИШЕШЬ ХОТЬ НА ПЕТУХЕ, ЛИШЬ БЫ БЫСТРЕЕ ПОЛУЧИТЬ РЕЗУЛЬТАТ
@
КОМУ-ТО ВСЕРЬЁЗ НЕ ПОХУЙ ЧТО В БРАУЗЕРЕ ЖС
@
ПРЕДЛАГАЮТ СИ, ФОРТРАН, ХАСКЕЛЬ И БРЕЙНФАК НА ЗАМЕНУ
@
ТИХО КРЕСТИШЬСЯ
@
ДУМАЕШЬ КАК ЖЕ ХОРОШО ЧТО ИХ НЕ ПУСТИЛИ К РАЗРАБОТКЕ БРАУЗЕРОВ
Синтаксис непривычный, да, но питон придумали 30 с лишним лет назад, когда Си синтаксис ещё не был доминирующим.
Основы у питона другие. Спорный момент только в отступах вместо скобок, но и в современных ИТ подобный подход используют, например в считающемся очень прогрессивным формате yaml.
Мне в целом синтаксис нравится, не мешает писать одновременно на питоне и JS.
При этом несопоставимо то, насколько хорошо и удобно сделаны базовые типы в питоне, и как с этим хреново в JS. И сколько всего удобно делать в питоне, и неудобно в JS.
Две серьёзные вещи, которые в базе у JS может больше возможностей дают:
1) принцип отступов в питоне. В чём-то интересно, но из-за этого иногда случаются баги, и, главное, это хоронит возможность активно играть с callback проектированием, для которого идеально заточен JS.
2) спорное решение в питоне, что не надо никак декларировать переменные, и что все переменные внутри функции имеют область видимости всю функцию, аналог var в JS. Нет переменных с областью видимости блока. Это зашито в архитектуру языка, __dict__, и изменить невозможно, не ломая язык, в то время как современные традиции программирования требуют переменных уровня блока.
> активно играть с callback
За нонейм-каллбеки длиннее трех строчек и без названия нужно убивать.
> идеально заточен JS
Да, но не от хорошей жизни, это единственный способ делать там что-то условно параллельно.
> спорное решение в питоне, что не надо никак декларировать переменные
Это не спорное решение, это полный пиздец, которому нет оправданий.
> Нет переменных с областью видимости блока
nonlocal - это не то, что ты хочешь?
В питоне вагон сомнительных решений, это правда. Есть даже дизайнерский тупак вида: x = ([], []); x[0] += [1]
Все языки по-своему говно. Что-то больше, что-то меньше. Хотя есть и абсолютное говно: BASIC и 1C.
>nonlocal - это не то, что ты хочешь?
Совсем не то. nonlocal для случая, когда ты определяешь функцию внутри функции и во внутренней функции хочешь использовать переменные внешней функции.
В JS ты в таких случаях просто не декларируешь переменную.
Я бы хотел, чтобы было как в JS, когда ты внутри тела цикла делаешь
let myVar = 1;
и это никак наружу цикла не попадает.
Это делает код намного более стройным и понятным.
ДА ТЫ ПРОСТО НА СЛОЖНОМ ПРОЕКТЕ НЕ РАБОТАЛ, ТАМ ТОЛЬКО СТАТИКА!!!
@
НУ И ЧТО, ЧТО ПОЛИНТЕРНЕТА НА ПХП, ПИТОНЕ, ЖСЕ, РУБИ, ЭТО НИЩИТОВО И НЕДОСТАТОЧНО СЛОЖНО!!!
А ЧТО ЕСЛИ МОЙ КОД ВДРУГ НАЧНЕТ БЕЗ МОЕГО ВЕДОМА СТРОКИ С ЧИСЛАМИ СКЛАДЫВАТЬ??
@
В СМЫСЛЕ ПРОСТО НЕ СКЛАДЫВАЙ СТРОКИ С ЧИСЛАМИ, ТАК НЕЛЬЗЯ, СРАЗУ ВИДНО В СЛОЖНОМ ПРОЕКТЕ НЕ РАБОТАЛ, А ВОТ ПРИДЕТ ДЖУН И НАСКЛАДЫВАЕТ СТРОК С ЧИСЛАМИ, ВСЕ СЛОМАИТ!!!!
Из языков того же класса, жс не самый плохой. Как минимум у него самый быстрый JIT. И он хорошо умеет в сэндбоксинг, такое же умеет ещё разве что луа, и в какой-то мере лиспы. Выбора-то на самом деле и нет, даже вот если сейчас взять и заменить язык. Но жс на сервере я считаю заслуженно не взлетел.
>>2016285
Анимацию уже давно на css делают. Алсо, эти ваши андроиды активно пиздят идеи из реакта.
Усложнится реверс-инженеринг всякого говна. Этим будут заниматься только три с половиной хакера в IDA. А так ты можешь почитать что делает код на сайте. Сложно будет дебажить твой нормальный язык. Ну разве что скорость чуть-чуть побольше станет. Вместо полминуты на разогрев JIT сразу быстро будет. Но какой ценой.
>Но жс на сервере я считаю заслуженно не взлетел.
Ну кстати одно время взлетал очень сильно, потому как на нём реально удобно было писать асинхронные приложения с callback подходом. То есть развитые коллбэки, библиотека под это, нативный JSON, реально делали его удобным.
Потом правда другие платформы догнали, парадигма проектирования ушла к async/await, уже профит не такой большой, а грязи в языке и на платформе в целом много.
Но реально ведь довольно много проектов, где нода работает, хотя бы частично.
Инструмент белых людей - это динамическая типизация, изобретенная как раз после того, как обезъяны развились до методик тестирования и поняли, что им не нужно приносить жертву конпелятору в виде не дающего ничего мусорного кода в обреченной на провал попытке поставить знак равно между "программа сходится по типам" и "программа выполняет поставленную задачу", а можно просто сразу писать и проверять то, что реально важно и определяет каждый аспект программы без исключения - бизнес-логику.
Статикошизики они статикошизики. Потому что считают, что вручную разбирать JSON это типа очень круто.
При этом твердят шизу насчёт того, что мол зато строка вместо числа в функцию не попадёт. Не понимая, что реально это не большая проблема, контролируется легко и в динамических языках с typing костылями.
При этом куда больше проблем от типизации статические языки не решают.
Потому что ты можешь проконтролировать, что у тебя unsigned int приходит, то не можешь проконтролировать, что у тебя значения обязятельно от 1 до 9999, а уже 0 и 10000 это беда, или что строка пришла в нижнем регистре, или что из пары аргументов только один должен быть не пустым, и т.п. А это как раз реальная жизнь. Проблема типизации, которую статическая типизация решить никак не может.
Но шизики всё равно продолжают шизить и придумывать костыли для динамики, вроде переменных var в Java или auto в C++.
>Инструмент белых людей - это динамическая типизация,
Что интересно, в энтерпрайз языки тоже запихивают инструменты для динамической типизации, точнее для автоматической, так как динамическую на компилируемом языке сложно реализовать. Это var в Java и auto в C++.
Отсутствие динамической типизации это часто проблема компилируемых языков, которую пытаются подать как преимущество. Но при этом придумывают костыли, как эту типизацию реализовать.
Иногда, конечно, нужна статическая типизация. Для надёжности и читаемости. Ну и для скорости.
Это вывод типов, макака. Переменная всё ещё будет иметь статический тип, определенный по выражению справа. Используется в частности чтобы не писать название типа, когда и так однозначно понятно, что там будет лежать.
Пиздец, откуда столько вкатунов повылезало? Сортиры не мыты, а они на жс пишут.
ITT
Как думаете, этот дебил знает что жс таки компилируется в браузере или нет?
Так вот и с обьектно-ориентированным программированием дела обстоят абсолютно ТАК ЖЕ. Люди боятся того, чего не в состоянии понять.
>>2016464
У тебя не только с языками программирования проблема, у тебя и с пониманием русского языка проблема
>>2016442
>Что интересно, в энтерпрайз языки тоже запихивают инструменты для динамической типизации, точнее для автоматической, так как динамическую на компилируемом языке сложно реализовать. Это var в Java и auto в C++.
Что такое "автоматическая типизация", гидроцефал? Покажи расшифровку этого термина в CS-литературе.
Не существует никакой автоматической типизации. Есть автоматический вывод типов, который ты, по своему долбоебизму, решил смешать с динамической типизацией, хотя это абсолютно ортогональные понятия. А теперь начал изворачиваться и съезжать на РРРЯЯЯ ТЫ НИТАК ПОНЯЛ.
--> >>2016488
Ты сначала обоснуй, что такое статическая типизация, что она для разработчика, и какую пользу приносит, и какие проблемы, потом и будет разговор.
Пока очевидно, что ты просто нихрена не умеешь. Занимался бы разработкой на разных платформах, имел бы реальное мнение о плюсах того и другого.
Ты не охуела, макака скриптовая? Я что-то не припомню, чтобы записывался в преподаватели спец-школы для детей с JS головного мозга особенностями развития.
Во-первых, мы разные аноны. Обоссывал тебя по поводу статической типизации один, а я сейчас тыкаю носом в твое полное незнание матчасти.
Во-вторых, поскольку ты не знаешь, что такое типизация вообще, твое мнение не просто не важно, его вообще не существует, пока ты не ознакомишься с базовыми понятиями CS.
В-третьих, от меня ты получишь сейчас только две вещи: 1) хуй за щеку и 2) ссылку на хабр: https://habr.com/ru/post/161205/
Образовывайся, животное, и исчезни с глаз моих.
У нас, господ-разработчиков, принято относиться к языку просто как к инструменту. Ты делаем продукт, который для чего-то нужен. Используем разные инструменты, может удобные, может нет. Может иногда поплёвываемся от работы с кривой недоделкой, но что делать... У всего плюсы и минусы.
А вы просто школьники-студни, которым хочется самоутвердиться, потому что они научились компилятор запускать и умеете писать на своей сишечки конструкции вида
int m[10][10];
int x;
......
x = 2[1[m]];
и в восторге от того, что понимаете, как это работает.
Начните уже что-нибудь полезное делать, а не хуйнёй страдать.
Как раз таки профессионал еще и умеет понимать, какой инструмент в целом хуевый и какой в целом не хуевый для тех или иных задач. И видит, что жс в целом сейчас вообще не имеет никаких плюсов ни для каких задач, кроме того что ему можно обучить и дегенерата поэтому ты и тут, и того что в силу исторических причин ему нет альтернативы на фронте.
А вот хуесосина с гикбрейнс как раз чему научилась то и хвалит, а на другое ума не хватает. Что и видно кстати по твоим высерам, которые пытаются преподнести простейшую работу с памятью как какое-то достижение.
>>2015647 - кун
Нахуя?
>И видит, что жс в целом сейчас вообще не имеет никаких плюсов ни для каких задач
>и того что в силу исторических причин ему нет альтернативы на фронте
Действительно, всего-то нахуй вся морда интернета на жсе написана и альтернативы ему не предвидится даже близко, а так задач нет никаких, соглы. Штанишки стирай, "профессионал".
Тащемта весь срач и начался с утверждений про то что жс это кусок говна и всем было бы лучше, если бы этому куску говна появилась альтернатива. А потом прибежал жс-петух и начал защищать ОСОБЕННОСТИ этого скриптоподелия и крыть хуями остальные языки, за что ему тебе хуем по губам и водим всем тредом.
Ни одной реальной претензии к жсу за весь тред не было, только шиза вроде сравнения массива со строкой через ==, хотя реальных претензий можно много найти без проблем. Да и речь в основном шла не про жс, а про статикошизиков как таковых, и им по губам поводили знатно, так что не знаю, с кем ты там в своей голове жс обсуждал.
Видишь ли, я ничего не выдумываю. Я выдаю факты, для понимания которых у тебя банально нет опыта. Давай сюда свое резюме, клоун. Потом посмотрим, есть у тебя право варежку разевать со своим охуенным мнением, или нет. А то по твоим изречениям - ты типичный петух-фронтендер из магазиностроительного.
> Это твое дилетантское мнение
Мальчик, ты своим поведением сейчас демонстрируешь типичное проявление эффекта Даннинга-Крюгера. Ты необразован, поэтому считаешь, что в слабой динамической типизации нет ничего плохого. Если бы ты написал хоть один средних размеров проект, то очень быстро бы понял, что не так с жавасриптом.
Обтекай.
Единственное, что я увидел в постах это -
> СТАТИЧЕСКАЯ НИНУЖНО!!!
Тем, что не нужно много времени тратить на рутину, вроде того, чтобы описывать сложные составные типы.
На простых типах, вроде чисел-строк, динамическая типизация не нужна. Она не вредна, но статические типы компилятор или интерпретатор может оптимизировать, а динамические уже сложно. В этом главная сила статической типизации и главная проблема динамической. Но не всегда актуально.
Но вот на сложных составных объектах, когда у тебя возможно полиморфное поведение, у тебя начинаются проблемы. Когда ты описываешь структуры данных, эти структуры данных хранишь в коллекциях, причём когда в коллекции могут храниться разные структуры.
Вот здесь в языках со статической типизацией начинается конкретная еботня, а с динамической всё хорошо.
Классическая история, тебе приходят сериализованные в JSON или другой формат данные, ты их парсишь и возвращаешь в виде объекта. Тривиально в динамических языках, и какая-то муть в статических.
Но заебало со школотой сраться.
>Это не спорное решение, это полный пиздец, которому нет оправданий.
Кстати питон даёт такую возможность, просто ей никто не пользуется.
Ты можешь в функции определить список __slots__ используемых переменных. И тогда переменные не в __dict__ будут храниться, а в __slots__, и ты не сможешь использовать не задекларированные переменные. Кроме того, __slots__ вроде как быстрее.
Но на практике этим никто не пользуется, всё-таки не элегантно.
Если ты не можешь нормально жсон распарсить в статике то это не проблема статики. Наоборот это во многих языках проще, так как почти везде есть либы конвертящие жсон по описанию в класс или выдающие ошибку, и дальше ты работаешь с ним как с обычным объектом.
Сука, ОРУ в голосину. Я знал, знал, блядь, что ты либо джун обоссанный, либо макака из магазиностроительного))) Если твоя работа заключается исключительно в перекладывании джейсонов - тогда да, динамика удобнее.
После того, как ты распарсил и провалидировал данные, ты должен их гонять внутри софта в четко описанных структурах, а не "ну чот пришло, вроде похоже на то, что нужно". Все преобразования данных должны строго ограничиваться этими структурами, а не твоими чувственными ощущениями.
>После того, как ты распарсил и провалидировал данные
Уже пошёл торг
>ты должен их гонять внутри софта в четко описанных структурах,
Тоже нет. Потому что у тебя одна функция может использоваться в разных местах. При этом ей требуется структура с каким-то набором полей, а на другие начхать. А источники данных могут быть разными, в одной свой набор, в другой свой.
Главное, чтобы структура "соответствовала протокол", то есть имела нужный набор регламентированных полей. При этом могут быть лишние поля любого типа. А другой функции нужна структура с другими полями.
При этом одна структура может последовательно гоняться через несколько функций, она может храниться в какой-то общей коллекции, она может перебрасываться через очередь специальную, и т.п.
Вы просто застряли в своих рамках, которые вам навязали платформы, где всё завязано на технические ограничения, потому что некоторые вещи сложно реализовать в компилируемых языках. При том, что там даже пытаются такие парадигмы реализовывать, поддерживать подобный полиморфизм, но это сложно и болезненно.
А в динамических языках легко и непринуждённо.
Большой реальной проблемы с багами нет. Если ты криво пишешь код на таком уровне, что там просто левые структуры тебе придут, то других косяков будет на порядок больше, против которых уже статическая типизация не поможет. Так ты только примитивные ошибки отловишь (и да, они бывают).
Самая главная проблема динамической типизации - это провал по производительности. Потому что статически типизированные переменные сразу можно в нативный код сгенерить, а динамические переменные это тяжеловесные объекты, которые надо разбирать в рантайме. Поэтому динамические языки сливают напрочь в производительности, хотя JIT может иногда спасать как-то довольно прилично. Но байтоёбством всё-таки лучше на питонах не заниматься.
https://youtu.be/kIoZDUd5DKw
Я вот думаю, есть ли здесь перекатившиеся между js и питоном? Что скажете про то и про другое?
>Жсер меняет один аргумент и сразу запускает все 1000 тестов, чтобы понять что сломается; а при нормальном рефакторинге у него вообще отваливается жопа
>Здоровый человек меняет любой кусок кода, и иде сразу выдает все места где сломается и на что обратить внимание
Одно и то же.
Покажи мне такую ИДЕ, которая тебе покажет, что в бизнес-логике что-то сломалось и которая позволит тебе не гонять тесты для этой бизнес логики при рефакторинге или иди нахуй. Классика статикошизла, который пытается поставит знак равно между "типы сходятся" и "программа работает", но все время серет себе в штаны.
Очередной еблан-максималист, у которого типы или решают вообще все баги или не нужны.
И самое смешное что он отвечает на пост, где писали что типы позволяют быстрее и удобнее рефакторить, а не что отлавливать баги.
Весь тред превратился то ли в театр одного еблана, то ли в театр одного жиробаса. Зато надо признать, он реально почти добился бугурта в бугурт-треде.
Я помню появление ноды. Сейчас активности и хайпа куда меньше. Тем более, что ее нишу отъедает голанг, который, при всей своей уебищности, лучше жс во всём, и такой же простой, чтобы макаки могли его осилить.
Нода будет держаться ещё долго, но в конечном итоге превратится во что-то типа лиспа для веба, где полтора фанатка уже десятилетиями рассказывают, что оно вот-вот взлетит и все пойдут дворы мести.
>у которого типы или решают вообще все баги или не нужны.
Именно так, потому что если у тебя уже есть инструмент, предотвращающий баги в бизнес-логике(тесты), то тебе не нужно еще дополнительно проверять, что ты нигде не складываешь число со строкой - это подразумевается автоматически.
>типы позволяют быстрее и удобнее рефакторить
Помогают они не рефакторить, а скорее давать подсказки IDE, что и где можно однозначно поменять. С этим я абсолютно согласен, и если бы типошизики отстаивали свои типы с позиции "ну и что, что я пишу в два раза больше кода, который ничего функционально не делает, зато у меня IDE может аргумент в функции по щелчку пальцев заменить", то у меня вопросов к ним не было бы никаких, кроме как пальцем у виска покрутить.
Видал я эти "в два раза меньше кода", везде лишние проверки на налл вместо человеческих nullable-типов/мейби, везде допотопные исключения вместо айзеров и нужно лезть каждый раз смотреть что там функция может выбросить, контроля эффектов никакого, какие-то везде тесты даже на простейшие функции чтобы не дай боже не сломать случайно из-за динамопарашности языка (в то время как такого рода тесты пишутся автоматически типами). И самое главное все равно где-нибудь макака пропустит тестик на null и все упадет в проде, или тест не пройдет но вообще не в том месте где надо и ходи распутывай по коллстеку где именно передалось не то.
Хули ты мне задвигаешь, я сам фулстеком на аспнете+реакте отработал 2 года. Навидался.
>позволяет писать МЕНЬШЕ кода в крупных проектах, и одновременно с этим проще отлаживать и проще рефакторить
Не позволяет и не проще. Судя по твоим примерам выше, ты оперируешь с классической ложной позиции статикошизла, которая заключается примерно в "если типов нет, то надо писать тесты, проверяющие нулл, строку, число, аллаха, а с типами бы это конпелятор проверил". Это абсолютная дикая глупость и непонимание принципов тестирования. Любые тесты(включая юнит-тесты для самой низкоуровневой логики) пишутся только с позиции бизнес-логики, а не с позиции "что будет, если инопланетянин мне передаст строку вместо числа".
Программа и ее работоспособность так же определяются только с позиции бизнес-логики, а не позиции манясхождения по манятипам. Если ты можешь тестами данную работоспособность продемонстрировать, то это означает, что ты уже продемонстрировал, что программа выполняет поставленную задачу, больше никаких конпеляторных проверок на нулл-строку-число тебе писать не нужно. А тесты бизнес-логики ты должен писать одинаково в любом языке, хоть обтипизируйся.
Дополню анона.
Самая проблема не в том, что строка пришла вместо числа, а что строка пришла в невалидном виде, либо есть какое-то несоответствие на более высоком уровне, данных больше или меньше, чем надо, id несуществующих объектов и т.п.
То есть ошибки на более высоком уровне, которые типизация отловить в принципе не может.
И тестировать надо в первую очередь на это.
>Самая проблема не в том, что строка пришла вместо числа
"Прийти" что-то может только из IO, например из юзер инпута. И любой юзер инпут ты так и так должен сам приводить к нужному тебе формату/типу и валидировать, хоть есть у тебя типы, хоть нет, так что тут разницы нет. А если под "неожиданно пришла строка вместо числа" подразумевается внутренняя работы программы, то это проблема того, кто эту строку отправил и не проверил, что его код работает. И типы тут не помогут, потому что таких же ситуаций "а что если программист напишет неработающий код" можно навыдумывать миллион, и никакими типами они не решаются, только методологией тестирования кода.
История "строка вместо инта и наоборот" довольно обычная. Вот есть некоторое хранилище данных, в нём объекты хранятся с id типа int. Но трафик сообщений упаковывается в JSON, где ключ это строка. Или идёт в виде XML с параметрами-строками.
Плюс в JS коллекциях тоже часто удобнее пользоваться именно строковами ключами, потому как там иначе это как массив интерпретируется, да, подгорает от JS и здесь.
Из-за этого часть функций может работать с целочисленными параметрами, а часть со строковыми. И вот здесь как раз статическая типизация была бы удобной, поскольку сразу показывает, каким должен быть параметр.
На самом деле проблема небольшая, потому что этот вид багов отлавливается очень быстро, хотя всё равно напрягает.
Не путай статическую-динамическую типизацию и слабую-сильную (нестрогую-строгую).
Например в Си статическая типизация, но не строгая. А в питоне динамическая, но строгая. В плюсах статическая строгая, JS динамическая нестрогая.
Нестрогая типизация скорее зло, потому что по коду часто непонятно, что там чего делает. Но никто не запрещает в JS, например, явно приводить типы, чтобы было понятно, что происходит, вместо неявного приведения, которое сделала бы сама JS-машина.
>Из-за этого часть функций может работать с целочисленными параметрами, а часть со строковыми.
Такого быть не должно, если у тебя айдишники хранятся в виде числа, а приходят откуда-то в виде строки, то они сразу же по приходу должны парситься в число и передаваться в программу уже в таком виде. А если половина функций принимает строки, половина числа и нужно их туда-сюда переводить без причины, просто чтобы дальше по флоу передать, то это лютый говнокод и его нужно немедленно фиксить.
@
НЕ МОЖЕТ СЕРВИТЬ HTTP ПО UNIX-СОКЕТУ
@
СДЕЛАЕМ REACT, ЧТОБЫ ПРОГАТЬ РЕАКТИВНО
@
ПИЛЯТ 100500 БИБЛИОТЕК ДЛЯ УПРАВЛЕНИЯ СОСТОЯНИЕМ, ХУКИ ХУЮКИ И МИЛЛИОН ДРУГИХ КОСТЫЛЕЙ, ЧТОБЫ СНИЗИТЬ ОВЕРХЕД ОТ РЕАКТИВНОГО ПРОГРАММИРОВАНИЯ
@
ИЗЪЁБЫВАЮТСЯ, ЧТОБЫ СДЕЛАТЬ ЧУТЬ МЕНЬШЕ НЕНУЖНЫХ ПЕРЕРИСОВОК
@
СЛОЖНОСТЬ ВСЕХ ЭТИХ КОСТЫЛЕЙ ПРЕВЫШАЕТ СЛОЖНОСТЬ ИМПЕРАТИВНОГО ПРОГРАММИРОВАНИЯ
@
ВСЁ РАВНО НЕ ПРИЗНАЮТ, ЧТО ОБОСРАЛИСЬ
Манька, автоматическое тестирование НЕ гарантирует, что все будет работать правильно. Поэтому умные люди обмазываются линтерами и перекладывают на компилятор то, что можно автоматизировать. Не случайно в питоне появились аннотации типов: это и для проверок линтерами (mypy), и документация.
Тебе, видимо, в магазиностроительном объяснили за тесты, но не объяснили, как пользоваться, и теперь ты думаешь, что это золотая пуля.
@
РАБОТАТЬ ПРОГРАММИСТОМ НЕ НРАВИТСЯ
>Манька, автоматическое тестирование НЕ гарантирует, что все будет работать правильно
Что автоматическое тестирование гарантирует, так это то, что человек, который написал тест на кусок бизнес логики, сделал все возможное, чтобы продемонстрировать и убедиться, что этот кусок логики работает. Больше от него никто ничего требовать не может.
>Жаваскрипт на беке
ну почему же, я еще котлин ковыряю, ничего сложного нет кста, корутины немного дают просраться, а так норм, краулить одно удовольствие. нода великолепна для какого-нибудь bff и прочих микросервисов
>жаваскрипт на фронте
справедливости ради- я перекатился на тс и на жсе не пишу уже довольно давно
>Господа
в голос с этой попытки привлечь внимание и поддержку со стороны
>... Ну кстати я на ТС перекатился давно и на жс не пишу
Говноязыки плодят говнософт, только и всего. И что это за мода такая, спрашивать стек? У нормальных программистов, как и у меня, нет "стека", они выбирают наиболее подходящий язык под задачу. В последних проектах я активно пользовался сями, плюсами питоном и жс. 15 лет коммерческой разработки, из которых 10 - распределенных систем и высокой нагрузки.
- Скажи, динамический питушок, ты согласен, что складывать километры с килограммами не имеет смысла?
- РЯЯЯЯ, но мОИ юНиТ ТеСТЫ!!!!1111
>вообще-то весь смысл в том, что нельзя
Зачем тебе пытаться складывать килограммы с километрами? Попробуй думать над тем, что ты делаешь, прежде чем печатать код. Тогда вдруг обнаружится, что подобные проблемы бывают только при глупых опечатках (да, они тоже случаются), а реальные ошибки сложнее и просто так не отлавливаются.
Тащемта, как раз таки последние десятки лет компуктер саенс тем и занят, что пытается минимизировать риски выстрелов в ногу. Все новые хоть сколько-то популярные продакшн языки выходят со статикой кроме эликсира который дсл для эрланга, и очередных лиспов, в старые динамик языки завозят инструменты/синтаксис для статического анализа, контроль эффектов проникает уже в мейнстрим, развивается тема завтипов, и так далее.
И тут приходит динамикопетух и кричит "ррряя нинужна все баги не отловишь значит вообще не нужно ловить".
:^)
Если тебе хочется разбить голову о стену только потому, что это возможно, то видимо тебя стоит держать в комнате с мягкими стенами.
У нормальных людей потребности в мягких стенах обычно не возникает. Хотя голову да, разбить можно. Иногда и с нормальными людьми случается.
ЗАДАНИЯ НА БЭКЕ
@
CRUD №2151 ДЛЯ СУЩНОСТИ "ГОВНО"
@
ДОБАВИТЬ ДЕКОРАТОР ДЛЯ ВАЛИДАЦИИ ПОЛЯ
Поправил
Компьютер саенс занят в том числе тем, чтобы делать механизмы полиморфизма, в том числе для типов. Чтобы можно было складывать разные типы в одни виды контейнеров.
В плане "выстрела в ногу" проблемы с динамической типизацией нет. Вот реально нет. Если же код пишет обезьяна, которая вместо километров подставит килограммы, то там других багов, не отлавливаемых, будет на порядок больше.
Главная проблема динамической типизации это производительность. Потому что процессор работает с конкретными типами, нельзя переменную неопределённого типа транслировать в машинную инструкцию.
Вот это да, проблема. Поэтому пишущим на таких языках приходится оправдываться, что сейчас производительность в большинстве случаев не нужна на самом деле глупо оправдываться, потому что на самом деле не нужна. А всё остальное высосано из пальца.
@
ОПТИМИЗИРУЕШЬ ВРЕМЯ СБОРКУ БАНДЛА, ЧТОБЫ СОКРАТИТЬ ХОТЯ БЫ НА НЕСКОЛЬКО СЕКУНД, ДЕНЬ ЕБЁШЬСЯ С ВЕБПАКОМ
@
АУТИЧНО НАСТРАИВАЕШЬ ЧАНКИ И ОПТИМИЗИРУЕШЬ ИХ РАЗМЕР
@
БОРЕШЬСЯ ЗА МИЛЛИСЕКУНДЫ В FIRST PAINT И TTI НА ВЁДРАХ ЗА 4К И 2G
@
ПАРИШЬСЯ О ПРАВИЛЬНОМ КЕШИРОВАНИИ СТАТИКИ/CDN. МОЖЕТ СТОИТ ВСТРОИТЬ CSS, ЧТОБЫ УВЕЛИЧИТЬ СКОРОСТЬ ЗАГРУЗКИ НА 0.1 СЕКУНДУ?
@
ЗАЁБЫВАЕШЬСЯ С ДОСТУПНОСТЬЮ, ЧТОБЫ ДАЖЕ СЛЕПОЙ ДАУН ХАРКАЧЕР МОГ ПОЛЬЗОВАТЬСЯ ИНТЕРФЕЙСОМ
@
ПРОДУМЫВАЕШЬ АРХИТЕКТУРУ И ВЫБИРАЕШЬ ИЗ 9000 СТЕКОВ, ЧТОБЫ МИНИМИЗИРОВАТЬ ВРЕМЯ ДЖУНОВ НА ЗАПИЛИВАНИЕ 32623733487 ФОРМОЧЕК
@
И НЕ ЗАБУДЬ, ЧТО ЧЕРЕЗ ПОЛГОДА КОМУ-ТО ВНЕЗАПНО ВЗБЕРЁД В ГОЛОВУ ИНТЕРНАЦИОНАЛИЗАЦИЯ
@
ОПТИМИЗИРУЕШЬ ГРАФИКИ И ДИАГРАММЫ, ЧТОБЫ НЕ ЛАГАЛИ НА ТЕХ ЖЕ НИЩЕВЁДРАХ
@
ПИЛИШЬ СИНХРОНИЗАЦИЮ ВСЕГО ГОВНА МЕЖДУ ВКЛАДКАМИ
@
ОБРАБАТЫВАЕШЬ МИЛЛИОН ЭДЖ КЕЙСОВ, КАК КРИВОРУКИХ ЮЗЕРОВ, ТАК И БИТЫХ ДАННЫХ С БЕКА
@
ПРИДЕЛЫВАЕШЬ СВИСТЕЛКИ И ПЕРДЕЛКИ, ВЕДЬ НУЖНЫ НЕСКУЧНЫЕ АНИМАЦИИ, ПОКА ЮЗЕР ЖДЁТ ОТВЕТА ЛАГАЮЩЕГО БЕКЕНДА. И НЕ ЗАБУДЬ ПРО СИЛКИ СМУЗ 60 ФПС НА НИЩЕВЁДРАХ!
@
ПРОВЕРЯЕШЬ ВСЁ В 100 БРАУЗЕРАХ, ОСОБЕННО В ЭТОМ ЁБАНОМ ЯБЛОДАУНСКОМ САФАРИ
@
ВВОДИШЬ 10 РАЗНЫХ ВИДОВ ТЕСТИРОВАНИЯ, ОТ ЮНИТ ДО ИНТЕГРАЦИОННЫХ И ТЕСТИРОВАНИЯ СКРИНШОТАМИ
@
НАСТРАИВАЕШЬСЯ ПРАВИЛЬНО ДЛЯ НИХ CI, ВЕДЬ ДЛЯ ДЕВОПСОМАКАК ЭТО СЛОЖНА
@
ПОСЛЕ ЗАМЕРОВ ОКАЗЫВАЕТСЯ, ЧТО ЮЗЕР ПОСЛЕ ОБНОВЛЕНИЯ ЗАГРУЖАЕТ ЦЕЛЫХ 50КБ НОВОЙ НЕЗАКЕШИРОВАННОЙ СТАТИКИ, А ДЖАВАСКРИПТ ЗАНИМАЕТ 30МБ В ХИПЕ
@
ПЛОХО, НУЖНО ОПТИМИЗИРОВАТЬ!
@
@
@
ТЕМ ВРЕМЕНЕМ БЕКЕНДЕР-КРУДОМАКАКА
@
"ДА ЧТО ВЫ ТАМ ДЕЛАЕТЕ, ОДНО ФОРМОШЛЁПСТВО!"
@
САМ ПИЛИТ КРУДЫ И ЮНИТ ТЕСТИКИ ИЛИ ПЕРЕКЛАДЫВАЕТ ЖСОНЫ НА ИНТЕГРАЦИЯХ УЖЕ 5-Й ГОД
@
ВСЁ ЧТО СЛОЖНЕЕ НОВОГО ЭНДПОИНТА ДЛЯ КРУДА - ДЕЛАЮТ АРХИТЕКТОР/ЛИД/СИНЬОРЫ
@
НЕ ЗНАЕТ, КАК ПОДНЯТЬ HTTP СЕРВЕР БЕЗ СПРИНГ-БУТА
@
"НУ И ЧТО ЧТО СЕРВЕР ПАДАЕТ С АУТ ОФ МЕМОРИ? НУЖНО ПРОСТО ЕЩЁ 32ГБ КУПИТЬ!"
@
"ТЫ НЕ ПОНИМАЕШЬ, 30 СЕКУНД НА ЗАПРОС ЭТО НОРМ, У НАС БИГДАТА, БД НА ЦЕЛЫЙ ГИГАБАЙТ!"
@
"АХААХ А ПОЧЕМУ ВКЛАДКА 500МБ ЗАНИМАЕТ?? ЧТО ЗНАЧИТ БЕЗОПАСНОСТЬ? КАКИЕ БРАУЗЕРНЫЕ АПИ?? КАКАЯ ВКЛАДКА ПРОИЗВОДИТЕЛЬНОСТЬ? КАКОЙ ЕЩЁ ХИП? ВОТ У МЕНЯ В ТЕРМИНАЛЕ НАПИСАНО!"
Берёшь максимально угоревшего по качеству фронтендера. Противопоставляешь его макаке-крудошлёпу с уровнем откровенно ниже среднего. Получается бугурт про превосходство фронтенда.
Можно взять среднего фронта и скиллового бэка. Получится бугурт про превосходство бэкенда.
И не надо мне тут пиздеть про то что средний фронтендер в большинстве задач запаривается хотя бы по половине из этих пунктов.
Если бы что-то из этого было бы сильно проще и оплачивалось хорошо, люди бы толпами валили с фронта на бэк, или наоборот.
@
Senior software engeener ебётся два месяца над оформенным на себя тикетом, чтобы писать не на ноде, а на плюсах. Чтобы на одного клиента в онлайне тратилось не 64Мб, а 1Мб.
@
Успешно, теперь когда в онлайне сидит 1000 пользователей одновременно, память всё равно почти не тратится. Оформляет презентацию, какой он крутой, какую пользу приносит компании. Сэкономил 64 гигабайта памяти сервера. Не зря получает 300k+. Себестоимость работ 10k$.
@
Приходит упругий джун-стажёр. Спрашивает, а стоит ли овчинка выделки. Ведь 64гигабайта на сервере стоят 20 долларов в месяц. А трафик стоит 2 доллара за террабайт. Зато у конкурентов всё это уже полгода как работает, всё обновляется в срок.
@
Кабанчик напряжённо думает.
@
>Но очевидно что типы+юниттесты покрывают еще больше багов чем по отдельности
Не очевидно и это не так Функциональные тесты делают любые тайпчеки внутри протестированного функционала полностью ненужными и вторичными. Писать тайпчек, когда у тебя есть тест - это примерно как убедиться, что чайник полностью работает и кипятит воду, а потом начать этот чайник разбирать, чтобы проверить, не перекушены ли у него провода внутри.
>Если у тебя какая-то логика не покрыта тестами, то о ее работоспособности в каждый конкретный момент ты не знаешь
>ЕСЛИ НЕ ЛОВИТ 100% ОШИБОК ТО ЗНАЧИТ НЕ НУЖНО ВООБЩЕ
Ну началось
> см >>2017569
И что там смотреть? Маняфантазии про х2 кода? На практике типчики только ускоряют разработку в проектах крупнее туду листов.
Тестить надо интерфейс лолка. А не н-макс-н-мин и с шагом +1/-1 проверять будет ли ноль в результате.
Бизнес-логика это то что клацаешь руками, а не в закромках у тебя кастует анальный карнавал и вместо проверки данных в точке входа, ты бегаешь и проверяешь их каждый раз в функции, бугага.
Зачем ты перевираешь мои слова? Я сказал, что единственный реальный способ в каждый конкретный момент времени знать, что кусок логики работает - это иметь зеленый тест на этот кусок логики. Схождение по типам ничего о его работоспособности не говорит.
>На практике типчики только ускоряют разработку в проектах крупнее туду листов.
Разработку ускоряет правильная методология. Тестирование - это методология, типы - это подсказки для IDE, не дающие ничего функционально. Второе в присутствие первого принципиально не нужно. Либо ты обсуждаешь этот принцип без глупых порывов в анекдотическое необоснованное "да без типов только туду листы писать", либо аргументов у тебя нет.
>нельзя переменную неопределённого типа транслировать в машинную инструкцию.
Спокойно просто меняешь ссылку, и слаживаешь(суешь в массив) А+Б просто потом надо понимать что работаешь не с байтами а с данными и привести их в 1 вид.
>>2019232
Чо неясно тебе в слове точка входа?
Пришли данные перевел в и обработал или послал нахуй.
А как дебилы некоторые забивать в базу SQL всякую парашу типа
"><h1>Админ хуесос///
И потом эту парашу в каждом выводе фильтровать через магическую копрозалупу format_text_f($hueta);
А потом где-то проебавшись обтекают как дауны.
Ну подумаешь некрасивые в базе данных данные и че? С базой надо работать только в виде гуя.
>>2019232
>курлом
Полно хуеты на динамопараше что ваяют приложения а потом не проверяют ведь кто же их говноприложение разберет или трафик отсниферит с джейсонами стетхемами. И течет говно с жопы у даунов.
>Вилки пишут только те, кто уверены, что у них они хорошие.
>Иначе будут морозится, обещать соц. пакет и комфортные условия и все такое.
О прям в Германии. Почему у вас в Берлине сеньор получает меньше чем в Киеве? Кряя зато у нас бесплатная медицина для бомжей за твой 40% налогов.
Я видел нормальное покрытие тестами в весьма большой компании, где я работал.
Тут нюанс в том, что некоторые вещи просто покрывать тестами, а некоторые очень сложно. Делать тесты для многопоточного-асинхронного кода, завязанного на сети, на состояние БД, кешей, очередей и т.п. сложно.
Одно дело проверить, как приложение реагирует на какой-то набор входных данных, и совсем другое, когда начинаются всякие race condition, нетривиальные состояния в БД, тупящие сервисы, отваливающиеся соединения и т.п.
>Аргумент про упрощения изменений ты конечно при этом пропустил
Аргумент высосан из пальца. Не понятно, почему изменять 20 строчек проще, чем 4, например. Или когда тебе придётся одну структуру разделять на две, наследовать одну от другой, только ради того, чтобы добавить одно поле. И потом думать, как всё это хранить в одной коллекции.
С точки зрения тестирования тебе в первую очередь надо контролировать, чтобы не пришли невалидные данные. Данные не того типа это самый простой случай и отлавливается сразу.
> в базу SQL
О птичках.
Твои аргументы примерно такие, принцип NoSQL говно по-определению, реляционная алгебра позволяет представить любые данные в виде классических нормализованных SQL таблиц.
Хочешь хранить новый тип данных? Создавай таблицу или несколько. Нужно добавить поле? Делай alter table или внешнюю таблицу привязанную по foreign key. И правь все SQL запросы.
Вроде бы и так, но... В итоге все СУБД поддерживают "документные" типы данных, вроде JSONb в postgres, уходя от традиционного SQL. Ибо очень удобно и полезно.
Довольно близкая история с динамической и статической типизацией.
>Спокойно просто меняешь ссылку, и слаживаешь(суешь в массив) А+Б просто потом надо понимать что работаешь не с байтами а с данными и привести их в 1 вид.
К сожалению, ты вообще не понимаешь, что пишешь, просто поток слов мало осмысленный, если в них разбираться.
То есть ты видимо совсем не представляешь, как всё это на уровне инструкций процессора (aka ассемблера) выглядит.
А аноны тратят время, чтобы с тобой какие-то срачи вести.
Берешь таблицу ид - название поля - описание и
создаешь справочник, на клиенте просто нормализуешь 11-"ебобо" 22-"обобе" и т.д.
>>2019362
>процессора (aka ассемблера) выглядит.
>
я знаю как они в самой программе, ссылка на тип и данные.
можешь поменять нахуй ссылку с инт на чар и будет похуй. (но будет не корректнос с точки зрения самых данных)
А передавать можешь чо хочешь мне допизды проц схавает твои флоат + флоат
Посрал на убогого клована
Попутно делаешь кучи методов для преобразования её в строку, сериализацию, отображение на SQL/JSON, думаешь над тем, как хранить среди прочих данных и т.п.
В результате получаешь неподъёмного монстра.
При этом необходимость обрабатывать истории, когда в БД данные с этим id заблочены или их вообще нет, остаётся.
>>>Подсказки от иде не ускоряют разработку и вообще не нужны
Ты опускаешь малюсенькую деталь - это не просто подсказки от доброй ИДЕ с нихуя, а написанный лично тобой шмат типов, которым ты обмазал реализующий рабочую логику код.
>Схождение с типами отсекает значительный пласт ошибок, возникающих при внесении изменений в крупный проект.
Набор бессмысленных баззвордов без квалификации("значительный пласт ошибок" - насколько значительный, каких ошибок, почему?, "внесении изменений в крупный проект" - каких изменений, насколько крупный, почему только крупный, маленьким значит типы не нужны?), и попытка съехать с темы. Напоминаю: речь идет о писании работающего кода. Моя позиция заключается в том, что единственный способ консистентно писать работающий код - это следовать методологии тестирования. И такая методология делает любые compile-time проверки типов ненужным и бессмысленными, потому что если ты уже проверил самое важное в программе - бизнес-логику, то тебе не нужен сверху компилятор, проверяющий сложение чисел со строкой.
@
ФРОНТЕНДЕР ПРИ ЭТОМ ПОЛУЧАЕТ БОЛЬШЕ БЭКЕНДЕРА
@
В СВОБОДНОЕ ВРЕМЯ ДЕЛАЕТ ШАБАШКИ И ОДНОСТРАНИЧНИКИ ЗА 50к
>Типы которые написал ты сам
Да, ранее написал, теперь пользуюсь. Проблемы?
>Длинная портянка про ловлю багов исключительно тестами
Да, да, 100% ковераги, и тесты всегда падают ровно в том месте где баг случился а не через 5 слоев коллстека, ага. Очень интересно.
"Можно плохо следовать принципу и тогда этот принцип не будет работать" не является аргументом в обсуждении нужды принципа как такового, особенно учитывая, что ты сравниваешь некий выдуманный тобой плохой тест с некими выдуманными тобой хорошими типами и последние все равно не ловят баги в бизнес логики, потому что у них принципиально такой возможности нет.
Сколько ни наблюдаю подобные срачи, ещё не видел, чтобы кто-то кого-то убедил. Одни и те же аргументы и контраргументы повторяются по нескольку раз, но другими формулировками. Срачи протекает одинаково, и не важно, про статику/динамику они, про производительность вычислений/скорость разработки или про респонс коды. Пустая трата времени.
>На джунов-фронтов вообще вакансий ноль
Дело в том, что нынешние мидлы, это по сути и есть джуны. Причем я не могу сказать, что тебе принципиально много нужно знать, проблема в том, что многие люди проходят курсы, при этом вообще в рот ебав весь этот наш/ваш кодинг, и потом с такими людьми непонятно что делать, когда они буквально не знают, как плагин в идеешке установить, потому что на курсах не показали. А если тебе интересно всё это вот "технарское", то однохуйственно вкатишься, разберешься, подучишь. И другая проблема тут состоит в том, что сам стек сегодня даже на фронте слишком разросся. Но опять же, можно и просто на верстальшика сначала вкатиться, да, 300к сек не будет, но уже неплохо для начала, по сути джуном и будешь.
@
ПЕРЕСАДИЛ МАМУ НА ПРАВОСЛАВНЫЙ ИНТЕРНЕТ
@
СМОТРИТ ЦЕЛЫЙ ДЕНЬ ТИКТОК
@
БОЖЕ КАК СТРАШНО ЖИТЬ - ВЕЗДЕ ЧИПИРОВАНИЕ, ВАКЦИНАЦИЯ, 5Ж
@
СЫНОЧЕК, ОФОРМИ МНЕ ЗАГРАНПАСПОРТ
@
ОПЛАЧИВАЕШЬ ПОШЛИНУ ЗА ЗАГРАН НОВОГО ОБРАЗЦА
@
ЧТОООО!? ОТМЕНЯЙ, НЕ ПОЙДУ, ТАМ ЧИПИРУЮТ!
@
СЫНОЧЕК, ПОСЛУШАЙ КОКОЙ УЖАС, 5Ж
@
КАКОЙ-ТО ХРЕН РАССКАЗЫВАЕТ, ЧТО ДЛИНА ВОЛНЫ 5Ж СОВПАДАЕТ С ДЛИНОЙ КЛЕТКИ, ВЫЗЫВАЕТ ОБМОРОКИ, ВЫКИДЫШИ, МУТАЦИИ
@
НО НАША ВОЛШЕБНАЯ НАКЛЕЕЧКА НЕЙТРОНИК ВСЕГО ЗА 1150 РУБ. ЗАЩИТИТ ВАС ОТ ИЗЛУЧЕНИЙ!
@
МАМ, ЭТО АНТИНАУЧНЫЙ БРЕД
@
ДА ТЫ ПОСЛУШАЙ, ПОСЛУШАЙ ЧТО УМНЫЙ ЧЕЛОВЕК ГОВОРИТ!!! ЭТО УЖЕ НЕ В ПЕРВЫЙ РАЗ ЭТО СЛЫШУ!!!
Большинство людей в ступор впадают, когда обычный C видят, мозг отказывается воспринимать информацию такого плана, ибо СЛИШКОМ СЛОЖНО для них (хотя на самом деле достаточно просто ПОДУМАТЬ, но люди ленивы и думать не хотят). Но статическая типизация от этого хуже не становится, она отсеивает ТУПИЦ.
Так вот и с указателями дела обстоят абсолютно ТАК ЖЕ. Люди боятся того, чего не в состоянии понять.
Если бы все всегда следовали всем принципам и без ошибок, то приложения выходили бы сразу без багов, были бы оптимизированы по дефолту и понятия легаси не существовало. А значит и юнит тесты бы тоже были не нужны. К сожалению в реальности есть еще человеческий фактор и требования бизнеса.
А еще есть например постоянно прибывающие на проект новички, которым с подсказками от иде и четкими описаниями типов и сигнатур в разы проще вкатиться в проект.
Но впрочем >>2019790 прав, ебанутый какой-то срач
> ламер
В зекач бошорг протёк, что ли?
>Попутно делаешь кучи методов для преобразования её в строку, сериализацию, отображение на SQL/JSON
Достаточно же одного метода, вроде getString(). И с нею уже работаешь, когда надо. Не помню, стоит ли делать метод для неявного кастования к строке, но в плюсах такое технически возможно. Саму АдреснуюСтроку просто принимаешь где надо и всё, ничего другое туда не засунется. А ты на каком языке пишешь, кстати?
>думаешь над тем, как хранить среди прочих данных и т.п.
Всего два варианта - строка или АдреснаяСтрока
>В результате получаешь неподъёмного монстра.
Класс с одним конструктором и одним методом. Ну и ещё может быть пустой конструктор без аргументов.
>При этом необходимость обрабатывать истории, когда в БД данные с этим id заблочены или их вообще нет, остаётся.
С БД я почти не работал, не мог бы ты привести пример или описать это подробнее?
>фронт оплачивается выше бекенда
Согласно careerhabr, JS-макаки всасывают даже крестоёбам
>фронт писать сложней чем бек.
>тесты на фронте делать во много раз сложней чем тесты на беке
>код поддерживать на фронте сложней в 1000 раз
Потому что макаки высрали такого говна, что даже сами запутались
Почти так. Почти вся сложность фронта происходит от необходимости поддерживать шизоидные стандарты, старые браузеры и прочую залупу, которая существует исключительно по историческим причинам. Ну и оптимизации, да.
Сложность бека происходит из сложности самих задач - помимо собственно оптимизаций, это продумывание архитектуры БД, синхронизации реплик, интеграции и их постоянная поддержка, микросервисная ебля с ее откатами распределенных транзакций и прочей залупой, процессинг платежей итп.
Ну и если бек накосячит, то юзеры могут проебать деньги или данные, а фронт максимум формочку не покажет или не сохранит.
>Сложность бека происходит из сложности самих задач
Ну какие там сложные задачи? там такой же набор готовых фреймворков и библиотек, крудошлепство, использование готовых библиотек и алгоритмов, вам даже ORM Дали что бы не писать голые запросы вручную + защитили вас от всяческих SQL инъекций.
Тестирование через откат транзакций, не нужно миллиард моков
> Ну и оптимизации, да.
мдя, в 99% случаях это делает девопс с его ордером на новую 32гб оперативку.
>микросервисная ебля с ее откатами распределенных транзакций и прочей залупой,
Это проще чем залупа с событиями и асинхронностью фронтов, где 1 неправильное действие или лишня рамка может привести к лагу рендеринга.
>Ну и если бек накосячит, то юзеры могут проебать деньги или данные.
Бекендер этим не занимается.
@ Работать в компании с секретными данными
@ не иметь тестировщиков, и гору безопасников которые провряют на уязвимости
Все так, сложность фронта не в математических знаниях, а в том что надо знать: "Нельзя брать камень, который лежит возле ведра, потому что ведро может обрушить дом, но если взять ведро и поставить на него птицу - то дом не упадет, но птица должна быть с зелеными перьями"
Считаю справедливо что фронтам платят сейчас по 300 - 400к за эту сложную работу.
Сложность как я сказал выше не в алгоритмах, а в пиздеце фронта.
Людям которые пишут на очень хороших бекенд языках, где все хорошо и красиво я предлагаю платить максим 90 000 рублей
Но именно по этому я получаю свои 280к просто клепая кнопки.
> какие там сложные задачи
Описаны в посте который ты процитировал.
> даже дали ORM которое идет нахуй при любых запросах сложнее вставки/выборки из одной-двух таблиц
> тестирование через откат транзакций
Говной повеяло за версту.
> Микросервисы проще фронта, на фронте может лагнуть рендер!!
А транзакция через 4 сервиса может не пройти, откатиться неправильно и у клиента проебутся деньги в банке или данные будут неконсистентны. Пострашнее лага рендера наверное.
> новую оперативку
Это только на начальных этапах развития проекта работает, когда продуктом пользуются сотни тысяч уже хуй там плавал.
> Бекендер этим не занимается
Ага, а процессинг оплаты кто пишет? Сохранение данных в базу? Тесты тестами, но 100% юзкейсов и потенциальных происшествий в асинхронной, микросервисной среде невозможно покрыть десятком тестеров. Где-нибудь что-нибудь обязательно наебнется, не откатится, не залогируется, не проверится на права.
>Описаны в посте который ты процитировал.
Ты описал влажыне фантазии вкатыша, на нашем рынке все задачи связаны с крудом.
Интересные сложные задачи есть только у байтоебов с окладом 60к.
>А транзакция через 4 сервиса может не пройти
А если я нажимаю на кнопку, она может на нажаться.
лол, если не приходит, то ты хуйню сделал и не умеешь пользоваться инструментов, этой проблеме 10 лет и ее давно решили.
>откатиться неправильно и у клиента проебутся деньги в банке
Не проебутся, потому что эту проблему уже решили очень давно.
ты блять не будешь писать все с НУЛЯ, ты используешься готовый инструмент и читаешь инструкцию на библиотеку, у вас все так как у формошлепов.
Раньше вы себя в грудь били: ооооо ебать, искусственный интеллект, это сложно!
А что в итоге? вам байтоебы высрали 10 готовых фреймворков с которыми теперь справится даже ребенок.
есть под все виды задач.
Чет лень высер твой читать и отвечать целиком. Для начала покажи-ка "готовую библиотеку" чтобы синхронизировать данные в разных сервисах. Чтобы если в процессе выполнения задачи, включающей в себя 5-10 запросов в разные сервисы, где-нибудь в конце что-то упало, изменения внесенные предыдущими запросами к другим сервисам также откатились а откат тоже может не пройти лол, и если между изменением и откатом были еще какие-то третьи изменения то осталась корректная версия.
Давно хочу что-то такое, а то постоянно приходится ебаться.
ОП, не перекатывай, пока эти долбоёбы не перестанут сраться.
Эти инструменты не решают задачу синхронизации данных. Вот как RabbitMQ может в этом помочь?
Это просто брокер сообщений, чтобы надёжно доставить сообщение из одного сервиса в другой или другие.
Синхронизация данных это такая типовая ETL задача, которая не имеет решения. Проблема тут в логике данных в первую очередь. Это примерно как конфликты слияния веток гита решать, почему до сих пор автоматически они не решаются? Вот тут та же история.
Под каждый случай своё решение делается, с учётом предметной области и особенностей источников данных.
