Comments / Profile of eptr / Habr

@eptr

User

ProfileArticlesPostsNewsComments530

Кадровый голод в IT не то, чем кажется

eptr Jun 23 2024 at 16:59

Раз не важно, значит вывод из вашего коммента только что вы помножили на ноль.

Вы не объяснили, как из того, что что-то там не важно, следует, что вывод помножен на 0.

Вы сказали, что кто-то там чего-то гарантирует относительно ВО.

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

И требование наличия ВО повышает вероятность, что понимание у человека будет относительно вменяемое.

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

Что лишает смысла все 2к подводки к нему.

Это — не подводка, это — аргументация.
Потому что авторитетов не существует, и поэтому необходимо аргументировать.

Кадровый голод в IT не то, чем кажется

eptr Jun 23 2024 at 10:17

РАЕН гарантирует, что не только ВО, но и научные степени ничего не меняют в принципе.

Здесь не так важно, кто там чего гарантирует.

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

В этом смысл, а не в чьих-то там гарантиях.

Кадровый голод в IT не то, чем кажется

eptr Jun 22 2024 at 23:12

Вот у меня 22+ опыта в IT сфере, могу писать на 17 языках, и много чего ещё...

Что-то меня здесь насторожило.

Опыта - как у 10 сеньоров.

Смотрю - у вас статьи есть, решил почитать.
С таким-то опытом человек, 17 языков, опыта на 10 сеньоров...

В статье "Сильный ИИ. Элира1" вам в комментариях объясняют простые вещи, а вы понять не можете. Пикселей — всего 360 000, а символов — 1.5 миллиона, и вы рассказываете, что в этих условиях ChatGPT распознаёт все символы оптически, потому что формат —векторный, а не потому что там текст прямым текстом записан, хоть и слегка сжат компрессором, и поэтому там распознавать нечего, надо только разжать декомпрессором текст назад из сжатого вида.

Установите под Linux утилиту Midnight Commander, возьмите свой pdf-файл и посмотрите его, можно прямо запустить mcview VOINA_I_MIR_1_2.pdf.

Или вы хотите сказать, что в утилиту mcview тоже OCR-распознавалка встроена?

Утверждаете, что в 20 МБайтный pdf влезет 1 миллиард символов.
Возьмите 1 ГБайт текста (1 миллиард символов) и сожмите любым архиватором.
Получится ли у вас 20 МБайт (сжатие в 50 раз)?

Я достал чистый текст из вашего файла VOINA_I_MIR_1_2.pdf утилитой pdf2txt (получилось, где-то, 2.7 МБайта) и сжал с максимальным сжатием утилитами rar и xz. Утилита rar сжала в 4.7 раза, до 575 КБайт, xz — в 5.2 раза, до 520 КБайт.

Вот на этой странице есть текстовые файлы для проверки архиваторов, один файл на 100 МБайт, другой — как раз, на 1 ГБайт. Также там есть описание результатов тестирования на этих файлах различных компрессоров.

Я скачал файлы оттуда и также сжал их rar'ом и xz'ом на максимальной компрессии.

100 МБайтный файл rar сжал в 3.4 раза, xz — в 4 раза.
1 ГБайтный файл rar сжал в 3.9 раза, xz — в 4.7 раза, до 212 МБайт.
Не до 20 МБайт, а только до 212 МБайт!
На максимальной компрессии.

В 50 раз не повторяющийся текст вы не сожмёте.
Самый лучший в мире компрессор тот 1 ГБайтный файл чуть менее, чем в 7 раз сжимает.

А, по-вашему, получается, что можно текст в pdf-файле хранить в векторном виде — лучше самого лучшего компрессора сжимает, 1 ГБайт — в 20 МБайт. Чудеса, да и только.

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

Не зря меня насторожило "могу писать на 17 языках".
Не уверен, что такой уровень понимания, который вы продемонстрировали в той статье и потом в комментариях к ней, даже до джуна дотягивает.

А люди, смотрю, вам здесь на слово верят.

Выходит, требование иметь хотя бы незаконченное ВО не лишено смысла.
Хоть какая-то гарантия от таких случаев.

Ненавижу, _____, C++ массивы

eptr Jun 20 2024 at 16:46

А в чём ещё ошибка?

В том, что это — недотип.

Все нормальные агрегатные типы, вроде struct и union, но кроме массива, позволяют инициализацию переменной значением другой переменной того же типа, откуда сразу следует возможность передачи по значению в функцию и возврата из неё также по значению, потому что передача и возврат по значению — суть инициализация.

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

Массив же нельзя инициализировать другим массивом того же типа, и нельзя одному массиву присвоить значение массива другого типа.

При этом существует "особо специальный массив", которым массив проинициализировать всё-таки можно, — строковый литерал.

Проинициализировать можно, а присвоить уже нельзя.

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

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

Приводится же функция неявно к указателю на такую функцию?
Приводится же лямбда без захвата неявно к указателю на функцию?

Факт того, что неявное приведение в выражении допускается сколько угодно раз, а также, что разыменование даёт lvalue, позволяет писать:

#include <cstdlib>
#include <iostream>

void fun() {std::cout << "Yes!" << std::endl;}

int main() {
	auto const f{fun};

	(**********f)();
	(**********[]{std::cout << "No!" << std::endl;})();

	return EXIT_SUCCESS;
}

В 7-ой строке функция неявно приводится к указателю на неё и этим значением инициализируется указатель f.

В 9-ой строке указатель на функцию разыменовывается сначала один раз, получается функция.

Затем получившаяся функция неявно приводится к указателю на функцию и разыменовывается ещё раз.

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

В 10-ой строке, для лямбды, после её неявного приведения к указателю на функцию, процесс аналогичен.

Набор случаев, когда функция/лямбда приводится к указателю на функцию, сбалансирован.

Например, для лямбд:

#include <cstdlib>
#include <iostream>

typedef decltype([](int const x){std::cout << x << std::endl;}) l_t;

void fun0(l_t const l) {
	l(5);
}

void fun1(void (*const f)(int)) {
	f(7);
}

int main() {
	l_t const l1;
	l_t const l2{l1};
	l_t l3;

	l3 = l2;

	l1(1);
	l2(2);
	l3(3);

	fun0(l1);
	fun1(l1);

	return EXIT_SUCCESS;
}

В 16-ой строке лямбда инициализируется значением другой лямбды.
В 19-ой строке одна лямбда присваивается другой.

В 25-ой строке лямбда передаётся в функцию fun0 по значению.
В 26-ой строке лямбда неявно приводится к указателю на функцию и потом передаётся в функцию fun1.

Нет вот этого "недотипства", как у массива, и неявное приведение не мешает, а когда надо — работает.

Хотя, конечно, для лямбд без захвата эти действия смысла особого не имеют, но недотипом в смысле массивов лямбды не назвать.

При этом, если массив "обернуть" в struct или union, то это обёрнутое начинает прекрасно использоваться для инициализации переменной того же типа, а посему и прекрасно передаваться и возвращаться из функции по значению, а также прекрасно присваиваться одно другому.

Но сделанного не воротишь, массив — недотип.
Хоть он и недотип, но — никакой он не указатель.

Ненавижу, _____, C++ массивы

eptr Jun 20 2024 at 15:06

Я думал оно позволяет свапать индекс и имя переменной из-за ассоциативности.

Да, в "обычном" виде пришлось бы использовать скобки, чтобы "преодолеть" приоритеты и заставить операции выполняться в нужном порядке: (&a)[1].

А вот так не понял. Как оно превращается в адрес конца?

Требуется понимание адресной арифметики и типов.

Преобразуем к независимому виду: *(&a + 1).
Приоритет & выше бинарного +.

Итак, раз берём адрес, то &a — указатель, но на элемент — какого типа?
Мы берём адрес массива, значит на массив.
На массив из 3-х элементов типа int.

Далее идёт адресная арифметика, поэтому жизненно необходимо знать sizeof элемента, к указателю на который применяется адресная арифметика, ибо указатель будет "шагать" именно на этот размер, и этот размер есть sizeof целого массива a, массива из 3-х элементов типа int.

К указателю прибавляется 1, значит указатель "шагнёт" на 1 такой массив.
И получится адрес сразу за концом массива.

После этого данный адрес разыменовывается.
Поскольку указатель — на массив, то, в результате разыменования получится массив (того же типа, что и массив a, то есть, из 3-х элементов типа int).

При попытке проинициализировать массивом переменную типа указатель на int с именем end, этот массив неявно приводится к указателю на свой первый элемент, который как раз тоже имеет тип int, поэтому никаких дополнительных приведений не требуется, точно так же, как этого не потребовалось при "инициализации массивом a" указателя itr.

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

Для единообразия можно написать так:

	for (int const *itr = 0[&a], *const end = 1[&a]; itr != end; ++itr) {

Или, в более привычном виде, так:

	for (int const *itr = (&a)[0], *const end = (&a)[1]; itr != end; ++itr) {

Типы выражений a, (&a)[0] и (&a)[1] — одинаковы.
Это всё — массивы из 3-х элементов типа int.
И каждый из них может быть неявно приведён к указателю на свой первый элемент.

Теперь, думаю, всё должно быть полностью понятно.

Ненавижу, _____, C++ массивы

eptr Jun 20 2024 at 14:11

Огонь! Сохранил себе, спасибо!

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

Это больше для собственного развития и только для своего личного кода.

Ненавижу, _____, C++ массивы

eptr Jun 20 2024 at 11:32

Есть стандартный оператор взятия адреса &. Вот его и нужно было использовать для получения адреса массива (т.е. первого элемента массива).

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

Ненавижу, _____, C++ массивы

eptr Jun 20 2024 at 11:27

То что имя массива это адрес первого элемента - конечно же ошибка дизайна С/С++.

Имя массива не является адресом его первого элемента.
Ошибка дизайна C касательно массивов — в другом.

Ненавижу, _____, C++ массивы

eptr Jun 20 2024 at 11:22

Часто с литералами так ((n >> i)%16)["0123456789ABCDEF"] или похожие.

А что мешает записать так: "0123456789ABCDEF"[(n >> i) % 16]?
Как раз на лишнюю пару круглых скобок короче.

Ненавижу, _____, C++ массивы

eptr Jun 20 2024 at 11:18

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

#include <cstdlib>
#include <iostream>

int main() {
	int const a[]{1, 2, 3};

	for (auto const *itr{a}, *const end{1[&a]}; itr != end; ++itr) {
		std::cout << *itr << std::endl;
	}

	return EXIT_SUCCESS;
}

Вариант для C:

#include <stdlib.h>
#include <stdio.h>

int main(void) {
	int const a[] = {1, 2, 3};

	for (int const *itr = a, *const end = 1[&a]; itr != end; ++itr) {
		printf("%i\n", *itr);
	}

	return EXIT_SUCCESS;
}

Как бауманец научился делать миллионы на маркетплейсах и теперь работает с 7 до 21 без выходных

eptr Jun 12 2024 at 19:30

Беседа с вами не ведёт ни к чему.

Неверно.

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

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

Как бауманец научился делать миллионы на маркетплейсах и теперь работает с 7 до 21 без выходных

eptr Jun 12 2024 at 18:11

А вы не думали, что некоторые вещи в статье специально так написаны, чтобы вы комментировали, цеплялись к словам и даже бесились, тем самым продвигая эту самую статью
...
Значит, цель статьи достигнута.
...
Но пассивно, случайно для меня, трафик за 2 дня на сайт вырос на 300%.

Вы, видимо, предпочитаете выиграть бой, но проиграть войну.
Как сказал ещё Греф: "люди не хотят быть манипулируемыми".
И - да, доверие теряется один раз.

Здесь вы практически прямым текстом признались, что использовали людей для своих целей.

-1

Как бауманец научился делать миллионы на маркетплейсах и теперь работает с 7 до 21 без выходных

eptr Jun 12 2024 at 18:05

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

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

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

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

Есть, кстати, такое выражение "слив засчитан".

Как бауманец научился делать миллионы на маркетплейсах и теперь работает с 7 до 21 без выходных

eptr Jun 12 2024 at 17:51

Кто "мы" ждём, и какое интервью, и почему оно должно быть?
Сами придумали и на основании придуманного пытаетесь примитивно манипулировать?

Как бауманец научился делать миллионы на маркетплейсах и теперь работает с 7 до 21 без выходных

eptr Jun 12 2024 at 10:20