- 01
- 02
- 03
- 04
- 05
- 06
- 07
- 08
- 09
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
- 26
- 27
- 28
- 29
- 30
- 31
- 32
- 33
- 34
- 35
- 36
- 37
- 38
- 39
- 40
- 41
- 42
- 43
- 44
- 45
- 46
- 47
- 48
- 49
- 50
var buf = Buffer.allocUnsafe(kexInitSize);
var p = 17;
buf[0] = MESSAGE.KEXINIT;
if (myCookie !== false)
myCookie.copy(buf, 1);
writeUInt32BE(buf, kexBuf.length, p);
p += 4;
kexBuf.copy(buf, p);
p += kexBuf.length;
writeUInt32BE(buf, hostKeyBuf.length, p);
p += 4;
hostKeyBuf.copy(buf, p);
p += hostKeyBuf.length;
writeUInt32BE(buf, algos.cipherBuf.length, p);
p += 4;
algos.cipherBuf.copy(buf, p);
p += algos.cipherBuf.length;
writeUInt32BE(buf, algos.cipherBuf.length, p);
p += 4;
algos.cipherBuf.copy(buf, p);
p += algos.cipherBuf.length;
writeUInt32BE(buf, algos.hmacBuf.length, p);
p += 4;
algos.hmacBuf.copy(buf, p);
p += algos.hmacBuf.length;
writeUInt32BE(buf, algos.hmacBuf.length, p);
p += 4;
algos.hmacBuf.copy(buf, p);
p += algos.hmacBuf.length;
writeUInt32BE(buf, algos.compressBuf.length, p);
p += 4;
algos.compressBuf.copy(buf, p);
p += algos.compressBuf.length;
writeUInt32BE(buf, algos.compressBuf.length, p);
p += 4;
algos.compressBuf.copy(buf, p);
p += algos.compressBuf.length;
// Skip language lists, first_kex_packet_follows, and reserved bytes
buf.fill(0, buf.length - 13);
Follow us!
Исходный тред:
https://govnokod.ru/26463#comment531865
То ли дело инкрементить индекс в удобном сишном массиве/указателе с автовыводом размера типа:
*((p += 4) - 4) = ...;
> Unsafe
так падажжи мы же специальный язык написали чтобы мимо памяти не промазать
>>> This method differs from the Buffer.alloc() method because it creates a not-pre-filled buffer, and it may contain information from older buffers. That is why it is called unsafe.
Без этого наверняка файл в тридцать семь мегабайт будет не три минуты загружаться, а три минуты и сто миллисекунд, что неприемлемо.
Если бы автор реализовал хелперы pushInt(buf, x), pushFloat(buf, x), pushString(buf, x), было бы даже лучше, чем в сишке, т.к. в сишке было бы pushInt(buf, x), pushFloat(buf, x), pushString(buf, x, dlina_stroki).
А указатель p куда девать?
Даже в сраной жабе нормальные апи есть.
Гость подсказывает: https://govnokod.ru/26472#comment531961
https://github.com/mscdex/ssh2-streams/blob/master/lib/sftp.js#L2305
Это походу ему никто никогда не писал ради прикола в глобал-скоупе
undefined=42;
Ну видно как людям сильно не хватает сишного struct
И это в не очень свежей версии "Node.pituz".
Ну и вообще, переопределить unpituzed может только хацкер, который специально ломает код. Так же можно во все прототипы вставить function(){} или сделать for(char*p=NULL; p<LONG_MAX; p++) *p = 0; в сишке. От этого нет адекватной защиты, кроме отдубашивания хацкера стандартом C++ по башке.
Это был сарказм.
Зачем на ровном месте создавать проблемы?
Какой смысл в
Зачем undefined? Зачем?
void(0) короче и надёжнее.
* работает in
* сравнивается по ==
Я же не знаю. Вдруг это какая-то хитрая питумизация, чтобы не инициализировать их раньше времени.
Вот спрашиваю зачем именно undefined?
> сравнивается по ==
А undefined разве нет?
> А undefined разве нет?
Сравнивается. Я имел в виду, что null == undefined, и больше ничему не равны.
Огромная переголова. Адекватнее будет просто написать обёртку над libssh.
Да оно, скорее всего, даже быстрее работать будет... Ну и без проёба кусков файла.
>А дебажить это всё как?
Элементарно!
Из utils.js.
А не могут высрать простейшую обёртку со счётчиком для buf.
Не хочу, хочу жрать говнопетушиться с индексами
writeUInt32BE(buf, cols, 23);
p += 4;
А не писать код как белый господин:
Не читал код, поэтому не знаю, там добавляется в конец, или просто так поверх буфера (во втором случае самописный код с изменением полуглобального счётчика будет более гибким).
Меня печалит, что из-за подобного ГКвские анскиллябры, которые "JS" толком не видели, ругают "JS", как будто бы на "сишке" этот текст выглядел бы как-то иначе.
Могу поставить 64 вареции распулужения информации, что критических багов там дохуя и больше.
Единственное, что меня печалит - что она 0.5с входит. Не знаю, это криптопожатия хостов так долго работают, или жс питух тормозит. Но я просто наравне с SQL пулами держу наготове соединение и теку, когда мне надо несколько питушень запускать. Зато мой сервер может запускать разную питушню на хостах, где она доступна.
Надеяться на то, что один разраб (который там де-факто в одиночку проЭкт развивает) ни разу не ошибся в этих сотнях магических числах и не наделал кучи ошибок разной степени опасности — в высшей степени наивно.
И хорошо, если эта хуйня просто чанк из файла вырежет (как уже, заметь, бывало). А ведь она твои ключи парсит и по сетке что-то с ними связанное гоняет.
Мне вот страшно доверять своё бабло одному-единственному петуху, который даже именованные константы не осилил.
Это кто тут JS не видел?
Ну коли там всё говнище лютое, чего б и не поругать?
«У нас архивчики не больше 128к» «У нас чанки херятся»
«Мы воруем исходники с сишки, а у нас по-прежнему всё дико тупит»
Больше говнища в мире скриптушни - не потому, что скриптушня - говно, а потому, что не-скриптушня просто не позволяет написать код человеку, не являющемуся пердоликом профессионального уровня.
И порицать нужно не-скриптушню, где простой человек не может написать программу, не может автоматизировать свою работу и не может иметь куч пользователей. Не-скриптушня превращает общество в закрытую секту программистов, хотя языки программирования в XXI веке должны быть доступны для всех, а не быть набором хипстерксих слов и концепций как C++.
node.js-элиты, которая пишет сложнейший код ключевых модулей.
>быть набором хипстерксих слов и концепций как C++
Кмк, хипстерский набор слов и концепций — это Haskell и Node.js.
А С++ при всех его недостатках уже больше 30 лет как серьёзный промышленный язык.
По правилам хипстерства хипстерам следует быть не как все и, в частности, придумывать слова, которые другие люди не понимают.
В кулхацкеле и ноде гиковский набор слов и концепций.
>где простой человек не может написать программу
А вот node.js для гиков.
Но там давно уже нет никакого набора концепций.
Просто их свалка.
* те, кто пишут компиляторы, ВМ и прочий царский код, где нужно мышление поехавшего на байтушне
* те, кто занимается архитектурой и проектированием систем
* те, кто занимается дизайном от общей сути до пользовательского интерфейса
Как показывает практика, простой человек не может размышлять как поехавший байтушок, не может продумать архитектуру и не может сделать что-то, чем удобно пользоваться (часто для него важнее сам факт автоматизации, а не взаимодействие программы и человека). Всё остальное он сделать может.
Обычному человеку вполне себе можно доверить не только лоховскую скриптушню, но и C++, только для этого надо сделать C++ адекватнее (сейчас сложность C++ - это не сложность концепций или сложность программирования как такового, а сложность налипшего на язык говна). Обычный человек вполне себе понимает, как работает компьютер, что там происходит в памяти, что такое класс, метод и процедура. И только большее количество людей будет это понимать.
Обычному человеку легче написать для себя программу, чем программисту. Ему точнее известно, что она должна делать, он лучше разбирается в предметной области. Если предметная область сложная, программист в неё будет въезжать долго и дорого за это возьмёт. А программирование - это всего лишь язык. Научиться говорить с компьютером даже легче, чем с людьми.
Вся питушня, которая изучается "программистами" - либо коньцепции, которые просто впитали в себя здравый смысл (если писать медленную программу, она будет долго выполняться; если разделить задачу на подзадачи, будет две простых задачи, за которые легче взяться), который есть не только в программировании, либо абстрактная математика, которую программисты сами не используют (например, лямбда-исчисление), либо алгоритмы, которые программисты сами не знают и реализуют по книжкам, как будет их реализовывать простой человек.
Нет. Это твой сдвиг восприятия как программиста.
Для обычного человека компьютер — это такая же коробка, как и холодильник. Она работает, она выполняет задачи пользователя, внутри неё какие-то байты, электроны и фреон. Всё.
И никаких предпосылок к увеличению людей, понимающих, как работают компьютеры, нет. Точно так же, как не увеличивается количество людей, знающих, как работает телевизор.
Скорее всего, в бухгалтерии наврали, что телевизоры у них у на каждый стол поставили.
Готов поспорить, что и премии не каждый получал за мастерское владение холодильником. Ну разве что некоторые: http://joyreactor.cc/post/3186277
В офисы и прочие помещения ставят не телевизоры, а компьютеры. Компьютер на рабочем месте теперь не диковинка, но обычное положение вещей. За знание телевизора больше зарплаты не получишь, а вот за знание компьютера - вполне. Больше знаешь о компьютере - меньше времени тратишь на пердолинг и возню с ленивым админом - работаешь лучше, имеешь больше предпосылок для повышения зарплаты, спаривания с более здоровыми особями и больше возможностей (финансовых и биологических) для выведения здорового потомства. Знание компьютеров даёт преимущество в эволюционном плане.
Может быть, не все, но технари точно начинают понимать, как и что в компьютере крутится, когда им приходится что-то автоматизировать, а программист слишком туп, чтобы написать программу для их предметной области.
Ты путаешь «знания о том, как работает компьютер» со «знаниями о том, как работать с программами». Какому-нибудь бухгалтеру никто не будет повышать зарплату за то, что он знает о байтиках, тактах, тредах, оперативной памяти, винде на флешке и NAS с SMB1. А вот за углублённые знания «Экселя», «1С:Предприятие» и прочих профессиональных пакетов — вполне.
Например, выломал человек байеровский фильтр ради фотографий с повышенными разрешением и чувствительностью и хочет сам сгенерировать картинку из RAW, т.к. не уверен, что демозаик алгоритм не перестанет смешивать субпиксели, поскольку этого без цветных стекляшек делать не нужно.
Зачем? Зачем? Если человек это делает для себя — он спокойно подождёт пару минут (не настолько же там всё плохо с батушнёй). Если он пишет программу для других — он автоматически становится программистом и должен страдать.
Питушня же, даже если зелёная. Человек может сделать что-то уровня письма в редакцию о том, как правильно поливать фикусы (ака современные лайфхаки), поделиться с любителями любительской питушнёй.
Его программа не обязана работать со всеми вариантами RAW файлов (даже LR так не умеет, если камера крайне нова), не обязана иметь удобный интерфейс, но она должна без пердолинга обрабатывать фотографии, для этого спецпрограммисты не нужны.
Расскажи мне, пожалуйста, как без боли, регистрации и смс мне сделать веб-страницу, которая выводит таблицу с картинками. Приветствуются все хипстерские решения.
* Можно сгенерировать страницу скриптом на python и т.п., положить в директорию со статикой и раздавать любой питушнёй, которая умеет раздавать файлы по HTTP.
* Можно взять хостинг с PHP и быстро нахреначить запрос в mysql и вывести в цикле.
* Можно написать очень простое приложение под Node, хотя PHP-питушня будет быстрее, т.к. в ней всё встроено, а под Node надо качать пакеты вроде mysql; если приложение будет сложнее странички - какой-нибудь express/impress, либо самому матчить request.url и писать заголовки.
Хоть я и забыл PHP, я бы выбрал второй вариант как наименее пердольный.
А если эта та задача со словарём с ворециями, то лучше всего написать простой скрипт на питоне, которым генерить страницу и заливать её как статику. Так даже можно использовать самый лоховской хостинг без БД и MySQL.
А хипстушнёй я не занимаюсь. Мне ближе ванильный ECMAScript5 без модного говна, чтобы добиваться цели, а не смаковать популярную питушню.
Я посмотрел на последний ангуляр и ужаснулся. В этих дебрях можно ногу сломать. Сейчас ковыряю vue.js
Основной вопрос, как сделать адаптивную таблицу, которая автоматически меняла бы количество рядов и колонок в зависимости от ширины экрана (но это, конечно, совсем не js-вопрос, на самом деле)
Ну то есть, если у неё есть какие-то строки/колонки, которые можно не показывать без вреда для пользователя, может быть, их стоит не показывать совсем?
Или же это не таблица, а набор блоков, которые можно перенести как слова на другую строку?
У таблицы можно сделать полосы прокрутки (CSS overflow) или сменить размер текста (CSS font-size). Можно просто накинуть прямоугольных блоков (HTML div, CSS float left, м.б. flexbox), которые будут переноситься на следующую "строку" и из-за равных размеров собираться в "таблицу". Можно вручную прописать разные стили (CSS media queries). Если ширина меньше такой-то, скрыть стилями такие-то столбцы; если высота - такие-то строки. Если ещё меньше в таких-то пределах, то скрыть ещё те и те.
Можно слушать изменение размеров страницы (JS window resize event), считывать реальные размеры (JS что-то про rounding box) и решать, что скрывать, что удалять, что рисовать.
Вон тут напитушили какую-то питушню: https://github.com/svinkle/responsive-table - если становится узко, таблицу перепердоливают в список и т.п.
,
а на ноутбуке, к примеру
или
?
Но вообще всё равно, оба варианта норм.
1. отрисовать таблицу как есть
2. измерить ширину колонок
3. зафиксировать её и пустить питушню по кругу
https://jsfiddle.net/b0rmtxLd/2/
Если взять максимальный размер, будет вариант 1: https://jsfiddle.net/b0rmtxLd/3/
Если убрать левость tr, tdшки пойдут в поток, будет вариант 2: https://jsfiddle.net/b0rmtxLd/4/
* аналогично - с высотой.
b0rmtxLd рекм0нду3т!
Если длина/ширина ячейки известна, можно сверстать на divах.
На эту тему есть статья https://css-tricks.com/snippets/css/a-guide-to-flexbox/
Только писали сайт скриптухи, он у меня загрузился медленнее, чем Notepad++ с 20 открытыми файлами с говнокодом.
[citation needed]
Программирование — это такая же профессиональная область деятельности, как вождение, ремонт/обслуживание техники, строительство или даже перевод (естественных языков).
Да, практически любой человек может, например, заменить у себя дома лампочку. Однако сколько могут поменять проводку и не сжечь дом впоследствии? Я вот не могу.
С программированием — всё абсолютно так же. Написать скрипт, который будет генерить какую-нибудь сводку в табличке, скачивать что-нибудь из интернета или генерировать вореции может практически любой опытный пользователь ПК™.
А доверять непрофессионалу реализацию сложного криптографического протокола или просто чего-то, от чего будут зависеть деньги — абсолютно то же самое, что и требовать от программиста починить лифт.
Профессиональный молоток будет в несколько раз дороже и крепче, но функционировать будет так же, как и любительский. Профессиональный лом вовсе не отличишь от любительского. А профессиональный автомобиль таксиста - от любительского. Профессиональные фотокамеры даже проще, чем любительские (из них выпиливают вспышку, кучу ненужных режимов и добавляют интуитивно понятные аппаратные кнопки вместо запутанных программных меню).
Но инструменты профессионального программиста - какое-то сложное говно с кучей придуманных аббревиатур. Программисту надо долго учиться работать с банальным текстовым редактором (vim, msvs), учиться выводить в поток в C++.
Несколько столетий/тысячелетий назад тоже делали бронзовые стамески. Но это было не потому, что они предназначались для профессионалов, которыми могли быть единицы, а потому, что технологий изготовления банальной стали у людей тогда не было. Так и с ИТ-питушнёй: пока мы имеем сырое говно, которое ещё не успело обкататься хотя бы веков за пять. И мешает его использовать не анскильность людей, а говённость инструментов. В программировании намного меньше задач, для которых действительно нужны программисты.
В первую очередь инструменты программиста сложны из-за того, что программист работает с крайне сложным устройством — компьютером.
Можешь открыть какой-нибудь лётный мануал от самолёта — там вообще чуть ли не половина слов написана капсом, а понятны только предлоги.
> И мешает его использовать не анскильность людей, а говённость инструментов.
[источник?]
Наше сырое говно на транзисторах мы уже обкатали до физически возможно максимума, дальше можно только крохи вырывать. А квантовая питушня — мало того, что требует крайне специфических знаний, так ещё и с большой долей вероятности нереализуема.
Ну нет там уж такой большой сложности. Все идеи - простые и понятные, реализация не всегда оставляет их такими, но всё же.
То ли дело медики или физики. У них в предметной области принципиально сложная питушня, которые они не придумывали и не хотели бы придумывать. Они распутывают говнокод мироздания.
ИТ-специалисты же сами создали своё говно, сами его усложняют и сами с ним борются. Асинхронность в JS как пример. Что мешало так долго бороться с лапшой? Почему так долго не вводили async/await и пердолились? Что мешало сделать нормальный C++ заново, а не фиксить баги и размышлять об оптимизации C++ в терминах C++ в идеологии C++, хотя известно было, что они - говно?
Асинхронность в JS и язык C++ - какая-то принципиальная сложность программирования? Нет, это просто необкатанное говно.
> Наше сырое говно на транзисторах мы уже обкатали до физически возможно максимума
Это мелочи. Остаётся ещё ряд задач, которые надо решить, чтобы инструменты программиста перестали быть таким говном
* Тормознутая скорость света и большое энерговыделение вентилей
* Ортогональная система команд у процессора
* Отсутствие UB
* Продвинутая оптимизация и нетормозной декларативный SQL
* Понятный C++
* Уменьшение бойлерплейта, семантически понятный код
* Понимание компьютером намерений пользователя и адекватное выполнение автоматически выведенного и скорректированного ТЗ
Ну да, ну да. Чтобы понять работу современного компьютера в деталях (а не на уровне «это АЛУ, он считает, а это ЗУПВ, там данные хранятся») нужно иметь как минимум пару вышек.
> Все идеи - простые и понятные, реализация не всегда оставляет их такими, но всё же.
Идея самолёта — простая и понятная, но это не значит, что самолёт — простое устройство (хотя он проще компьютера, кстати).
> язык C++ - какая-то принципиальная сложность программирования?
Да. Это попытка выразить высокоуровневые концепции в низкоуровневых терминах. Получить максимальный пирфоманс можно только так.
> Остаётся ещё ряд задач, которые надо решить, чтобы инструменты программиста перестали быть таким говном
Пожалуй, соглашусь, что сложность каждого из пункта последующего списка примерно одинакова. [/color]
Понимать на таком уровне не нужно. Программа либо сразу работает как надо, либо гуглится и рассматривается каждый случай отдельно.
Знание квантовых состояний атомов в полупроводниках программисту не нужно, так же как микроархитектура процессора. Программист работает на уровне абстракции повыше, где в двух-трёх сигмах случаев проблемы другие. То кто-то сел на флешку и долго читает, то пользователь поставил битый диск или какую-то питушню двадцатилетней давности, то UAC добавили. До того, как дело упрётся во внутренности ПК, программист уже может уйти на пенсию. Просто так рассматривать хвосты за тремя сигмами - питушня, которая не окупится.
>> язык C++ - какая-то принципиальная сложность программирования?
> Да. Это попытка выразить высокоуровневые концепции в низкоуровневых терминах. Получить максимальный пирфоманс можно только так.
Ну вот Вы говорите, что это "попытка". Чуть менее, чем полностью эта сложность - несовершенства такой попытки, никак не связанная с принципиальной сложностью.
Вот кто помешал разрешить описывать операторы с правым this внутри класса? Это можно сделать банальным препроцессором, который их выносит за класс, а внутри добавляет строчку дружеского доверия оператору.
Кто помещал переиспользовать и инлайнить коньструкторы (вроде же это уже добавили в новую версию)?
Кто помешал сделать режим без UB, но с подгоном кода и его ворнингов под конкретную архитектуру, где у меня, например, работает как надо интовый перекат, т.к. моя архитектура использует комплементарного питушка? Это бы и байтухам первым пригодилось.
Много высокоуровневых терминов могут хорошо описывать низкоуровневую питушню, и это можно эффективно использовать.
И тем не менее, как я и сказал, программирование такое сложное потому, что оно построено на базе крайне сложного устройства. Да, постоянно придумываются абсракции, которые отдаляют программиста от компьютера. Но у абстракций в реальном мире есть неприятное свойство: они постоянно текут. Нетекущие абстракции бывают только в чистой математике (и то не факт).
Собственно, поэтому для любого программиста крайне важно умение работать с протёкшими абстракциями.
> Чуть менее, чем полностью эта сложность - несовершенства такой попытки, никак не связанная с принципиальной сложностью.
Нет. Принципиальная сложность в том, что любая попытка выразить абстракции низкого уровня в терминах абстракций высокого уровня неизбежно будет (1) тормозить, (2) протекать и/или (3) выглядеть как переусложнённое говно (можно выбрать один или больше пунктов из списка, меньше нельзя). Происходит это из-за того, что при переходе на ступеньку «вверх» нам надо каким-то образом обработать потерянную при этом информацию. Разберём по пунктам:
1) Тормозящие абстракции: мы потеряли информацию о железе и не можем эффективно его использовать. Сюда входит любое скрипто- и вмоговно.
2) Протекающие абстракции: мы не потеряли информацию с нижнего уровня, а потащили её наверх. Реальный пример — «C». Вроде бы язык высокого уровня, но приходится пердолиться с памятью, ручными тредами и прочим железоговном.
3) Переусложнённое говно: мы не потеряли информацию, вместо этого полностью выразив её в абстракциях верхнего уровня. В результате у нас в одном слое лежат абстракции и верхнего уровня, и нижнего. Идеальный пример — кресты с их «std::hardware_destructive_interference_ size».
> операторы
> коньструкторы
> UB
Всё это — мелочи, которые никак не влияют на общую картину. Исправим их — получим вылезшего из другой лунки крота. Потому что абстракции низкого уровня всегда будут ждать удобного момента, чтобы укусить нас за жопу.
Это эффективная сложность, но не принципиальная. Если по литературе задали выучить пару строф из /dev/urandom, можно выучить ту кобенацию, которую выдаст генераторушня, а можно навернуть свой генератор, никто не заметит разницы!
Так и с компьютерами: можно изучать принципы и связи, а можно - конкретное устройство с чипами определённых производителей и набором установленных программ и шрифтов. Второе будет намного сложнее, хотя объективную реальность будет описывать более бедно.
> у абстракций в реальном мире есть неприятное свойство: они постоянно текут
И их успешно затыкают. Мой printf или console.log отлично работает, я чуть менее, чем никогда заглядывал внутрь.
Их затыкают настолько хорошо, что при их протечке программистом уже не обойдёшься, нужен будет эксперт по криптушне или внутреннему устройству процессоров отдельной серии.
И компиляторы выдают ошибки и ворнинги.
> Тормозящие абстракции
JIT, директивы и параметры компилятора.
В C++ есть "ссылки", которые позволяют не переписывать код, работающий со значением, и при этом добавить царски быстрое копирование аргументов в стек.
> Переусложнённое говно
Да. Но это уже проблемы реализации. С опытом у создателей языков вырабатывается статистика, вырабатывается опыт, популярный код начинает выглядеть проще и не тормозить.
Проблема в том, что этих самых принципов и связей в современном ПК вагон и маленькая тележка, и досконально их знают только хардкорные бородатые программеры с 20+ годами опыта. Остальным (включая меня, да) остаётся только жаловаться на несовершенство мира.
> И их успешно затыкают.
По большей части это «затыкание» сводится к банальному закидыванию дыры лишники гигагерцами и гигабайтами. Решение эффективное… Было до недавних пор, пока Мур работал. А теперь мы упёрлись в физику, дальше экспоненциально расти некуда (вернее, можно и нужно расти в мультиядерность, но там, во-первых, надо многопоточность, которую макаки не осилят, а во-вторых, к пределу энергопотребления мы тоже подползаем потихоньку).
> JIT, директивы и параметры компилятора.
Прах, тлен, эвристики и недетерминированная питушня. Ни жид, ни компилятор не знают, что от них хочет программист (он и сам это в большинстве случаев не знает).
> Но это уже проблемы реализации.
Это проблемы несоответствия гипотетической машины, под которую создаётся язык, и реальных компьютеров.
Но не все сразу нужны.
Если имеется сложная глючащая программа, часто достаточно с помощью чтения кода и отладчика выяснить её особенности в отдельном месте и пофиксить.
А можно у себя в голове смоделировать поведение программы, мысленно найти проблему и переписать код.
Так и в ИТ в целом. Достаточно базовых принципов и изучения конкретно нужных особенностей, хотя можно стать бородатым опытоносцем.
> По большей части это «затыкание» сводится к банальному закидыванию дыры лишники гигагерцами и гигабайтами.
Однако, с этим можно бороться.
Можно обучить компилятор упрощению стыков абстракций (самый простой пример - инлайн и анролл, когда тормозящие абстракции функций и циклов превращаются в царский код), можно вставить скукоживатель области оперделения (например, ворнинги на лишние касты наподобие ворнингов на касты из длиннуха в короткуха). Помню, дяденька Борманд рассказывал про программирование видеопитуха, где была абстракция цикла, но не было циклов с заранее неизвестным числом итераций. Аналогично - урезанная рекурсия в макросне C/C++.
> Ни жид, ни компилятор не знают, что от них хочет программист (он и сам это в большинстве случаев не знает).
> Это проблемы несоответствия гипотетической машины, под которую создаётся язык, и реальных компьютеров.
А вот это - принципиальная проблема процесса программирования.
Код надо перевести из желания клиента об автоматизации, выраженном в (недо)ТЗ, криво понятым программухом и изложенным на языке программирования, который настолько убог, что сочетает сложность (ради точного выражения царского кода) с описанием алгоритма под какую-то другую машину (ради попытки натянуть один царский код на несколько машин). Питушня, нафиг так жить.
В любой области достаточно базовых принципов и изучения конкретных особенностей. Другое дело, что специалистом так стать не получится, только PHP-программистом, пишущим гостевухи за еду.
> Однако, с этим можно бороться.
Как я и сказал, это всё тлен и частные случаи. Вот этому товарищу, кстати, тоже частные случаи постоянно мешали: https://gamedev.ru/flame/forum/?id=169618.
Нет, разумеется, это не значит, что я против развития оптимизаций, совсем наоборот. Просто фундаментальные проблемы эти затычки исправить в принципе не могут. Для этого надо как минимум изобретать другие, совершенно новые парадигмы программирования, включая языки (с нуля) и архитектуру компьютеров (с нуля). Убрать UB из крестов, добавить в жабаскрипт типизацию, реализовать агрессивный инлайн — это всё попытки починить «Титаник» синей изолентой.
Но с другой стороны: а так ли плохо современное программирование, чтобы выкидывать его на помойку и изобретать что-то новое?
Я вот думаю, что нет, не стоит это таких усилий. Над созданием современной IT-экосистемы целое человечество работало эдак лет сто. Сложность крестов — явно не то, из-за чего нужно повторять этот путь заново.
Настолько ли нужно им быть? Век специалиста недолог: знания специалиста устаревают быстрее.
Если можно на свою заплату покупать сёмгу, надо ли становиться пердоликом-специалистом?
> попытки починить «Титаник» синей изолентой
А мне кажется, это полезный опыт. Так можно выяснить направления движения, а не просто знать, что вон в тех точках нет ничего интересного.
Тем более, что полная замена
> не стоит таких усилий
Но вообще надо кобенировать революционный подход с эволюционным. Новое говно может дать большой буст, а может влить тонны говна. Старое говно может вяло улучшаться или вяло загибаться.
Новаторы пойдут строить реальные проекты на принципиальном новом говне (не стоило ругать менеджеров в соседнем треде. они дают индустрии полезные данные) и выносить их этого опыт. Консерваторы будут спокойно добавлять полезные фичи и улучшать старое говно.
С тем же успехом можно вообще не быть айтишником, а пойти в «Макдак» на кассу.
Специалисту, обладающему обширными знаниями, попросту открыто больше перспектив.
Можно быть пхп-макакой и всю жизнь писать гостевухи за три куска сёмги в день — но тогда надо быть морально готовым к тому, что ничего лучше уже не будет.
А можно быть крутым специалистом, пройти собеседование в «Гугле» и уехать в силиконовую долину, с соответствующим повышением уровня жизни.
И да, разумеется, я не утверждаю, что специальные знания автоматически дают +$100500 к зарплате. Они попросту увеличивают шансы получить +$100500 к зарплате. Стоит ли это затрат времени и сил на становление специалистом — тут уж каждому решать самостоятельно.
> Но вообще надо кобенировать революционный подход с эволюционным
Подтверждаю.
Пока пхпшник ходит в кино, ты работаешь над знаниями.
Когда пхп выкинули и пхпшник сидит в кафе учит ноду, ты сидишь с ним в кафе и хлещешь водку, т.к. тебе не наверстать выкинутый x86 и перестроиться на арм за короткое время.
Я всё понял! На самом деле ДОБРОЕ ИМЯ ДОБРАЯ СЛАВА В ЧЕСТИ 1024-- — матёрый бородатый низкоуровневый спец, с закрытыми глазами определяющий ISA процессора на ощупь. А за анскильных пхп-макак он агитирует специально, чтобы в его области было поменьше конкурентов и побольше зарплаты.
Любому тотальному выкидыванию технологии на мороз обязательно будут предшествовать долгие годы обсуждений, подготовительных этапов и переходных процессов. Идеальный пример — «IPv4», который «выкидывают» уже лет двадцать, или «x86», который в пользу «x64» выкидывают чуть поменьше, лет десять-пятнадцать.
Если «специалист» много лет подряд полностью игнорировал все новости из области своей специализации и в результате оказался у разбитого корыта (при этом умудрившись проебать даже время, в которое устаревшая технология была нужна как легаси, а-ля Кобол) — ну, значит, это какой-то очень странный специалист.
И да, я очень сильно сомневаюсь, что пхп-макака, в жизни кроме пхп ничего не видевшая, выучит «Ноду» быстрее, чем специалист по x86 ассемблеру выучит другой ассемблер, в архитектуре которого вообще нет каких-то совершенно революционных идей.
Наконец, область IT вообще крайне новая, бурная и быстро развивающаяся. Если хочется просто получить работу и ближайшие лет пятьдесят сидеть на жопе ровно, получая стабильный доход — в айти идти точно не следует.
Она её выучит быстрее в необходимом для получения той же зарплаты объёме, чем специалист по x86 ассемблеру выучит другой ассемблер в необходимом для получения той же зарплаты объёме.
Как я уже написал, в «ARM» нет каких-то идей, которые будут совершенно новыми для x86-спеца. Разумеется, если «x86-спец» — это действительно специалист, углублённо знающий архитектуру компьютеров, а не просто замаскированная пхп-макака, заучившая список команд.
С другой стороны, при переходе на «Ноду» пхп-макаку ждёт целый дивный новый мир концепций, которых в пхп либо нет вообще, либо о которых пхп-макака не догадывается.
Асинхронность, события, потоки, REST, пакетный менеджер и так далее, и тому подобное. Даже то, что надо за собой чистить занятые ресурсы, ведь память в пхп не шарится, и на каждый запрос заново запускается.
В некотором смысле выходит, пхп-макака - это узкий специалист в прикладном скриптовании, для которого даже нода будет новой; а "x86-спец" на самом деле генералист, который хорошо знает только основные идеи и готов использовать другие инструменты. И генералист в долгосрочной перспективе с большей вероятностью остаётся в деле.
А вот для «x86-спеца» жизненно важно обладать мощными фундаментальными знаниями о работе процессора, потому что иначе просто не получится писать эффективный код (а нужен «x86-спец», который не может написать эффективный код? Легче тогда уж пару джаваскриптеров нанять).
Собственно, если пхп-макака возьмётся за самообразование, освоит основы программирования (императушня, структурошня, ООПушня, функциотушня, питушина Питуринга, общие питуринципы работы ПК, математика, etc.), то она внезапно превратится в самого обычного PHP-программиста, который способен достаточно легко перейти на любую другую скриптушню.
+а кому нужен «x86-спец», который не может написать эффективный код?
Но не уверен, что он реализует свои алгоритмы лучше, чем номерной j с ГК, который знает актуальную питушню в ПК и GCC.
Знания Торвальдса и Руссиновича постоянно устаревают. Не удивлюсь, если они тратят пару часов в день на самообразование.
Специалисты, за которыми стоят в очереди - как айфоны. Их можно распродать, а можно получить очередь из 200 перекупщиков. Люди могут копить на них и залезать в кредиты, а могут взять что-то подешевле, даже если показатель "цена к качеству" будет ниже.
Сегодня стоят очереди, а завтра возьмут того, кто за меньшие деньги выдаст результат получше и не будут просить накинуть соточку за сертификаты.
> Выбирай, как грица
Два стула
- дружище, а ты часто сам пробовал переключаться на новый язык/технологию/фреймворк?
Типа ты писал на жабе серверные приложения, а потом рынок поменялся и ты начал писать на котлине под андроид, например?
- чувак, ты бы слышал стоны моих сотрудников году в 2015, которые искали 100500 причин не переходить на свифт (например, он, видите ли, недостаточно динамический). Это при том, что да, платформа, парадигма и фреймворки остались по сути теми же, а сколько при этом попоболи.
Или вот переход с UIKit на SwiftUI, особенно, если до этого тебе "реактивное" погромирование было до пизды. Да, через неделю ты сможешь копипастить туториалы, через месяц юзать как серебряную пулю, но сколько времени пройдёт, прежде чем ты осилишь технологию по максимуму, чтобы выйти на свой уровень продуктивности до начала её использования?
Можно только представить, сколько Sun, MS, Apple потратили средств на раскрутку своих языков и платформ для разработчиков. Не было бы агрессивного маркетинга, была бы Джава с шарпом и котлином где-то в области обитания языка D.
У Мэттта прямо на сайте написано, что он worked as a technical writer, нерелевантно.
А что бы в этом случае использовали для питушни, где C++ слишком сложен, а python слишком тормозит?
Паскаль и дельфин, кстати, умерли вместе с компанией Борманд. Оказалось некому их продвигать и макаки не стали на них больше пересаживаться.
Недавно упоминавшийся тут Дилан умер вместе с донекстстеповским ябблом. Джобс не стал его продвигать и макаки не стали на него больше пересаживаться.
Не всегда новый инструмент лучше старого. Именно поэтому няшная и кресты, несмотря на все свои UBы и местами старческие маразмы, живее всех живых.
- я так понимаю, под Nokia ты подразумеваешь рынок телефонов на j2me? Ябблу сложнее отправиться вслед за ним в обозримой перспективе, будем честны.
А так-то я несколько лет назад попробовал свитчнуться, поблевал, вернулся.
Плюс я говорил про сейчас: тебя никто (теоретически) не заставляет писать на свифте. Можно сидеть на обжективе до победного конца.
> Например, Нидлесс выучил свой J равно не ради работы, и думаю он любой другой язык так же выучит.
- выучит это для гыгыканья и ололоканья на говнокоде или же для того, чтобы писать на языке, занимая минимум сеньорскую должность?
Но в итоге они продались майкам, а виндофоны не смогли пробиться на рынок и сдохли.
WinPhone мс лично закопала своими бангалорскими жавлами, никогда блядям не прощу.
Пойду в таком случае писать задний конец на Рэкете или Стриже.
А недооплачиваемых бормандов?
Прирост эффективности профессионала (а вместе с ним - прирост зарплаты за единицу знаний) падает экспоненциально с поглощаемыми знаниями.
Насчёт асимптотики падения я бы не был так уверен.
В любом случае, вместе с поглощаемыми знаниями растёт количество подходящих мест работы, что позволяет
1) Получать бо́льшую зарплату за счёт устройства на более выгодную работу;
2) В целом быть более уверенным в своём будущем.
Да, конечно, получить все знания мира и стать королём шаманов и невозможно, и бессмысленно. Но вот чрезмерно ограничивать свой кругозор и свою область специализации не менее вредно, чем тратить всё свободное время на получение лишних знаний.
Во всём нужен баланс.
> пхп
Но в пхп нет тредов, какой шаринг )))
Вижу, у них целый раздел, который посвящён обсуждению многопоточности.
Какой позор (((
Блядь, за три дня битья головой об стену нормальный человек бы сто раз успел сообразить, что он делает какую-то хуйню, но, видно, для пхп-макак это не предел.
И ладно бы это был нуб, который только вчера книжку «ПХП за 2 часа» прочитал — так ведь нет, он, сука, на работу устраивается, испытательный срок проходит! Тьфу.
Концовка эпична, конечно:
Ну это норм. У меня сишный rand() работал в сотню раз медленнее, чем без потоков...
Какая многопоточность )))
Тормозящее сложное говно:
То же, но выглядит как цикл, без явной байтушни и ненужных кастов и царских умножений указателей, которые надо отдельно оптимизировать:
И вообще, банальное описание типа всё усложняет:
Тогда как можно было бы обойтись без всех этих значков, которые надо читать по спирали:
Запись одна и та же, компилируется в то же, но для её прочтения не нужно быть профессиональным читателем сигнатур функций в "сишке".
У хипстерков так не принято, вон даже "кодексы поведения" всякие начали выдумывать...
Вишенка.
Кто-то объяснит зачем? А то я туго понимаю в столь поздний час.
>Support Electron 5/6 for ed25519
https://github.com/mscdex/ssh2-streams/issues/144
Гениально просто.
Например: https://github.com/mscdex/pg2/blob/master/lib/Client.js
>>> A PostgreSQL driver for node.js that focuses on performance
Вместо того чтобы перегнать сишные либы в asm.js люди городят такой пиздец невообразимый.
https://github.com/digitalbazaar/forge/blob/628b17fb5bc0bf22074b632432ffa535805a1b2b/lib/aes.js#L11
Если не сказать больше.
Но после этих безумных p += 4 няшная с её типами, cstdint.h, c её массивами и указателями, с memcpy и realloc кажется мне лютой годнотой.
https://ideone.com/8lj4Ku
* Какая-то пидорская конструкция вместо явных sizeof, .size() или .length
*Работает только для массивов с известной длиной, выдаёт говно для int*
В итоге получается, что какая-то царушня
особо и не нужна, когда в C++ есть читаемая версия:
где точно известно, какой тип будет у элемента и на что ссылаться. Говна вида эквивалентности int [10][20][30][40] и int *[20][30][40] и типа int *[30][40] как элемента этого массива просто не будет. Либо массив как элемент, либо явный итератор.
> int arr[10][20][30][40]
Говно.
> std::array<std::array<std::array<std::ar ray<int, 40>, 30>, 20>, 10>
Говно.
Ни в «C», ни в «C++» искаропки нормальных многомалостныхмерных массивов нет, есть только тормозящее и вылетающее за кеш нечто.
+ Ни в «C», ни в «C++» искаропки нормальных динамических многомалостныхмерных массивов нет, есть только тормозящее и вылетающее за кеш нечто.
Статические есть: «GCC» успешно оптимизирует пачку арраев до одного сложения с укококозателем.
Соответственно, размер элемента массива, включающего arr - 5 интов.
> } else if(forge.util.isArray(key) &&
да сука
и тут без кастомного isArray не обошлось
* инкапсулированная имплементация зависит от конькретного типа
* интерпейс принимает разные типы и
* конвертирует в поддерживаемые
* вызывает нужные имплементации
* бросает исключения
То есть то же самое, что делает хорошая программа с пользовательским интерфейсом
* инкапсулированная имплементация зависит от конькретного типа
* интерпейс принимает разные форматы ввода и
* парсит значения
* вызывает нужные имплементации
* бросает исключения
То есть в скриптушне можно скалировать MVC или business logic+interface с уровня приложения на уровень библиотеки и течь иметь хороший код.
какое функциональное программирование )))
Теперь точно функциональное.
Всё, что "логично" следует читать как "когда в системе 1 элемент, это логично; когда в системе N элементов, есть N! нелогичных кобенаций".
Надо думать, где вставить явное копирование, чтобы твои данные не споганили.
Надо думать, где вставить ссылки, чтобы твои данные могли изменить без рассинхронизации.
Один раз забыл - сел на флешку.
Надо думать, где вставить const и как изменить всех пользователей по цепочке, чтобы код скомпилировался, и возможно ли это.
Нудо думать, где вставить копирование, а где - ссылки, и вообще возможно ли это, если ты убрал const.
Один раз забыл - сел на флешку.
А питушня растёт факториально кобенаторно, и думать приходится в несколько раз больше на каждом следующем шаге.
в принципе, они не поленились и self пробрасывать во всех методах «объекта»
Потому что какие-то типы данных нельзя эффективно скопировать. Инт можно, а список — нельзя.
> Почему класс и список не копируются, а булен копируется? (на самом деле в питоне все ссылка, но семантика именно такая)
Нет, семантика не такая. Просто в Питоне есть мутабельные ссылки (листы, дикты), а есть немутабельные (инты, строки). Поэтому передача инта от передачи листа не отличается ничем.
> Хочу язык где всё всегда копируеца по значению
Питушня. Выстрел в ногу с испорченным массивом более заметен для непрофессионала, чем выстрел в то же место ноги, но с тормозами из-за копирования.
*За исключением совсем малость количества исключений вроде джвух i32 на x64 процессоре.
Да. Поскольку математику изучают только в рашке, анскильные скриптухи про оценку сложности не слышали, просто пишут код и текут. Очень сложно будет объяснять анскильному питуху, что f(some_int) и f(some_1gb_array) — это совершенно разные (в языке с повальным копированием) вещи.
Тут очень показателен подход «JavaScript», в котором, вместо объяснений скриптухам про Шлёмиэля и O(N^2), просто взяли и оптимизировали «for (x in arr) { str += x; }» до O(NlogN).
Кратко: да, язык должен упрощать разработку, в том числе и эффективного кода. Чем меньше нужно знать, чтобы писать эффективный код — тем язык лучше.
Но причина конкретно этого багра, кстати, вовсе не в ссылках, а в том, что дефолтные параметры инициализируются один раз, на этапе «выполнения» объявления функции.
И опять же, я где-то выше писал, что лучше уж скриптух поломает голову попишет на SO про «неправильную» работу ссылок. Потому что в противном случае мы получим программы, которые у скриптуха работают, а у нас безбожно тормозят из-за O(N^2) (ещё больше, чем сейчас).
> Питушня. Выстрел в ногу с испорченным массивом более заметен для непрофессионала, чем выстрел в то же место ноги, но с тормозами из-за копирования.
Выстрел в ногу, которого можно было бы избежать - просчёт языка, поскольку
> язык должен упрощать разработку
Да, я согласен с тем, что
> разработку, в том числе и эффективного кода. Чем меньше нужно знать, чтобы писать эффективный код — тем язык лучше.
Но как по мне, лучше иметь медленный и корректный код, чем быстрый и некорректный. Тормозящей питушнёй даже можно пользоваться, а некорректную питушню можно только выкинуть.
Если массив распитушился и не вызвал исключение, а также удаление пользовательской директории, то это никто не заметит. Добавят пару костыльков, чтобы исправить перезаписанные значения - и снова запустят.
Даже программисты часто ловят исключения ради стабильной работы программы и игнорируют коды возврата, что уж говорить о простых людях, для которых важен эффект, а не призрачные красота, корректность и поддерживаемость кода.
Даже у программистов в почёте подход "сначала реализуй логику, потом оптимизируй". В первую очередь думают о поддерживаемом коде, а потом переписывают его по-царски с битхаками, если он вызывает зуд кулера.
Так и в языках для людей должен быть подход от простого и надёжного кода с копированием и GC до явно помеченных царских unsafe блоков с UB и ассемблерных вставок.
Я прочитал это как "чем если на ногу повесили гирю, и она от гири не болит как от пули". Может быть, изначальный комментарий был другой, я отвечал на придуманный мной тезис "лучше испортить массив, чем тормозить программу с неиспорченным массивом".
Гуест8 топит за копирование всего и вся по-умолчанию и отказ от неявных ссылок; я указал, что для языков, ориентированных на массового потребителя, это не самый здравый подход.
Но являются ли ссылки в действительности источником проблем?
Ведь программист не только может испортить массив, переданный по ссылке: с тем же успехом он может не поменять тот массив, который надо — и таким образом выдать пользователю некорректные данные (реальный пример: https://govnokod.ru/26443#comment528066).
А вот какой вид ошибок более распространён и вероятен — гораздо более сложный вопрос, требующий исследования. Эмпирикой тут не обойдёшься.
Выведет 2.
Мне кажется, императивное программирование и пошаговый интерпретатор в голове - профдеформация программушков.
Да и C++-боги же вроде приходят к функциональной чистоте, т.к. обилие изменяемого состояния заставляют подвиснуть даже их могучие мозги.
Однако, усложнённая что математика, что императушна - уже нет.
При этом усложнённая математика гораздо сложнее усложнённой императушни. Это наглядно демонстрирует, например, сравнение количества программистов на «JavaScript» и количества программистов на «Haskell».
Мир подсел на императушню
* Функциушня хуже ложится на выбранные идеи питушины Питуринга и питутиктуры фон Питуймана.
* Простых людей больше учили и учат пирфомансной императушне.
* Программистов учили и учат с упором на императушню, охват знаний функциушни часто слишком мал.
Почитайте посты поехавших скриптухов. Они с удовольствием используют ФВП для массивов, начинают садиться на монады и тащат функциушню в свой скриптомирок.
Функциушков пока маловато, в большой степени ещё и потому, что функциушня много раз пропускала день ног.
P.S. А, ну ещё нейросети и мозгушня. Функционально бегут сигналы.
P.P.S. Тогда *HDL ещё. Функциушня как питуредство метапрограммирования.
https://ideone.com/gtrlOK
Просто *& не работало, «gcc» ругался: «assignment to expression with array type».
P.S. Я смотрел ассемблерный выхлоп. *(takefive_ptr)&krestuhi = *(takefive_ptr)&petuhi; именно копирует массив.
https://ideone.com/5SC190
А такой код можно легко сгенерировать скриптом для любых max_block.
а вообще безусловно
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/TypedArray/from
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/TypedArray/of
ну ладно
Опять мы приходим к тому о чём я уже говорилк удобству инициализаторов структур и массивов в сишке.
Данные надо не только инициализировать, но и использовать.
x = "linux";
Сложная сишка, два вида строк.
А не бумер ли ты часом?!
это для обратной связи с повершеллом
https://imgur.com/j4zzglK
Почти как мы с дяденькой ПИ предлагали.
Золотые, бессмертные строки Царя как нельзя лучше подходят к моменту.
>>> I understand the file gets corrupted because it's a ZIP consisting of thousands of very small files, so the zip structure can be damaged easily...
Какое дожатие )))
Помнится, у Царя была какая-то проблема, когда размер файла делился на размер страницы без остатка.
Ко-ко-кой пирфоманс )))
Если бы n++ написали на ноде, он бы и мегабайта текста не вывез.
А node-zlib честно написали: мы говно, ничего не умеем, архивчики в 128Кб, не больше.
Note that node-zlib is only intended for small (< 128 KB) data that you already have buffered. It is not meant for input/output streams.
блядь
блядь
блядь
mysql_escape_string doesn't work, try mysql_real_escape_string
>Possibly, but it's not really a priority at the moment
В переводе: «возможно, но я анскильный лох и вообще мне похуй».
золото.
я даже специально на всякий проверил - да, это три нуль-байта, за которыми идет [email protected].
А 21 зачем?
"\u0000\u0000\u0000\[email protected]"
Но зачем им e-mailы на 4 миллиарда символов? Зачем?
https://github.com/mscdex/pg2/blob/56049c528063548ed797a45dda6ca01fe0d409c2/lib/Protocol.js#L64