Новые языки программирования незаметно убивают нашу связь с реальностью / forpes.ru

Главная
Новые языки программирования незаметно убивают нашу связь с реальностью

Новые языки программирования незаметно убивают нашу связь с реальностью +88

28.02.2019 14:02

fillpackart 339 74000 Источник

Однажды настанет день, когда команды в программировании будут выглядеть вроде «эй, компьютер, сделай-ка мне вот эту хреновину».

Что там будет под капотом, ни одна живая душа уже не поймет. Команда «хреновина» интерпретируется в абзац с описанием, который интерпретируется в ключевые слова, который интерпретируется в набор векторных обозначений, который интерпретируется в какой-нибудь С, который скомпилируется в…

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

Программистами станут лощеные гуманитарии с «высокими вербальными способностями, коммуникативными навыками и умением быть няшей в команде». Слава богу до этого дня, как до Аляски на упряжке, но каждый раз изобретая очередной Kotlin, мы этот день приближаем.

Просто я задумался — а не стали ли наши ЯПы уже чем-то таким? Чуть более умным эквивалентом фразы «компьютер, сделай хреновину». Кучей формализованных протоколов для электричества, про которое мы уже забыть забыли. Штукой, которая все сильнее рвет нашу связь с механической реальностью.

Я часто слышу фразу: «Фил, отступись, хватит думать обо всякой чепухе». Но блин, будь проклят тот день, когда на Хабре напишут «хватит думать».

У меня на работе много небольших проектов, и мы используем разные стеки — .net, React.ts, c++, Java. В чем ты хоть немного прошарен, то на тебя и повесят. Я пришел как дотнетчик, но таски на доске есть на все приложения, доступ к репозиториям — тоже.

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

Вот я написал штуку, которая выбирает лучший впн сервер на шарпах, вот пошел делать то же самое на джаве. То же самое, точно таким же образом. Поначалу не придавал значения, но в какой-то момент не заметить закономерность было уже очень сложно.

Я просто делал одно и то же на разных языках программирования. Этот код был очень похожим, за исключением деталей, которые никак не влияют на решаемую задачу. Ведь бизнес не приходит ко мне со словами: «Эй Фил! Нам нужно использовать абстрактные классы, чтобы отобразить клиенту состояние впн соединения». Бизнес и пользователи хотят, чтобы девайс показал им картинку. Да и я на самом деле тоже просто хочу показать им эту картинку.

Но я не могу. Нельзя просто сказать машине: делай то, что мне нужно. Пока еще я тот самый промежуточный интерпретатор, который превращает фразу «сделай хреновину» в команды, пока еще мне приходится детально и пошагово разъяснять процессору, куда и как класть долбаные байты.

Но и я уже не работаю с байтами. Я работаю на очень абстрактном уровне со штуками, которые производят фабрику фабрик механизмов, которые управляют этими байтами. Там внизу есть железяка, и она устроена еще сложнее — я понятия не имею как, что там делается. Но оно делается, через сотню призм, о которых я тоже не имею никакого понятия. Половину того, что я хочу сказать машине, она «додумывает» сама, и я не знаю, как именно.

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

Дотнетный компиль превращает мой сишарп в промежуточный язык (IL), который едет на машину к клиенту, где в свою очередь другой дотнетный компиль (который just-in-time) на лету превращает мой IL в платформоспецифичный код, который в свою очередь скармливается процессору…

И где-то там все мои формальные описания, все различия между ЯПами стираются, и делают одно и то же. На пальцах:

Я знаю, что процессор знает команду O1. Получив ее, он пульнет электричеством во встроенный микродинамик, у того что-то где-то перемкнет и раздастся писк.

И вот я на сишарпе пишу:

using System;
Console.Beep(500,500);

Эта строка у меня превратится в О1

Я пишу на плюсах:

#include <windows.h>

Beep(500,500);

И она тоже превратится в О1.

Я что, должен думать, почему здесь System.Console, а там windows.h? Но мой мозг это запоминает, а таких специфичных деталей дофига, они совсем разные. Рано или поздно деталей становится так много, что мой выбор ЯПа становится не логическим, а просто потому что мне так больше нравится.

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

И это сработало. С кучей оговорок и проблем, но они просто автоматически превращали сишарп код в джава код, и пуляли либу клиентам. Все эти убеждения, что «каждый язык решает свою задачу», выбросили на помойку.

И вот сидя над дизайном очередного модуля, я подумал — а что бы сказал старина фон Нейман и его команда, когда услышали о моих проблемах? Те самые парни, которые конструировали свои принципы хранения данных и доказывали идиотам, что двоичная система для машин лучше, чем десятичная.

Они бы не офигели от нашего количества абстракций ради абстракций? Смогли бы принять, что в 2019 все чаще выбирают абстракции чисто эстетически и этим размывают связь с выполнением на машине.

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

Каждый раз, когда очередной стартапер думает «да че там случится с моей нодой, когда я все перевезу с x86 на ARM. Вся эта низкоуровневая фигня меня не касается», мы все дальше и дальше от реального контроля над задачами. Язык общения с машиной стал почти человеческим. Но похоже, это не работает так, как задумано.

Почти любой из распространенных сегодня ЯПов продается, как инструмент решения всех проблем. Но это не работает. Сначала появляется инструмент, который делает жизнь проще при решении какой-нибудь одной маленькой задачи, все начинают его хайпить, создают ему инфраструктуру, делают все, что бы он стал применим везде — и вот у нас очередной чересчур сложный и слишком абстрактный инструмент, который все делает плохо. Кто-то где-то уже пилит новый ему на замену. Чтобы запутать все еще больше.

Один мой друг-гуманитарий (эй, уберите револьверы, мы же все с вами притворяемся, что с гуманитариями можно дружить, я — не исключение) написал рассказ. Заявил мне, что я, как друг, должен его прочитать. Я долго отлынивал. Но он меня достал, и я прочитал. И это оказался один из тех случаев, когда гуманитарные знания улучшили мои навыки разработчика. Смотрите.

Сам рассказ — фантастика. В центре дизайна проблема словесного взаимодействия между людьми. Там весь мир заболел болезнью, когда тебе кажется, что ты говоришь нормально, но окружающие слышат какую-то бессвязную чепуху. Рассказ в итоге об этом — как с помощью языка передавать свое восприятие, и что делать, если языка у тебя нет. Я и раньше думал о том, что между языком программирования и естественными языками можно проводить параллели, но думал, конечно не всерьез. Прочитал и задумался покрепче.

Когда бизнес приносит мне задачу «Эй, Фил, сделай хреновину», что вообще происходит у меня в мозгу? Сколько ступенек интерпретации проходит, пока звуковая волна, отскакивая от моих ушей, превращается в сигналы и пробегает по нейронам мозга куда надо. Я об этом вообще не думаю, это происходит само.

И из-за этой неосознанности, из-за того, что я спокойно отдал мозгу автоматически интерпретировать «услышанное» в «понятое» — появилась куча багов, которые я не контролирую. Вот менеджер три часа объясняет мне бизнес задачу, а я ухожу от него с одной мыслью: «что за буллшит он нес!? Пусть напишет в джире, тогда и сделаю».

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

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

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

И когда кто-то напишет очередное «мое разочарование в софте» и будет жаловаться, какое все громоздкое, неправильное и неповоротливое — с этим уже ничего нельзя будет сделать. Стремясь упростить свою жизнь, мы теряем над ней контроль. А это очень плохо.

Но еще больше я боюсь другого. Высокоуровневые ЯПы настолько изменят мое мышление, что мысль «все плохо» просто физически не сможет зародиться в моей голове. Я точно уверен, что естественный язык, на котором я говорю, очень серьезно влияет на мое сознание. Если я русский, то десять поколений моих предков диктуют мне, как я должен думать с помощью языка, который я от них унаследовал. Языка, который устроен, например, так, что в любом предложении о случившейся проблеме — должен быть виноватый. Даже если я говорю «случилась херня» — виновата все равно херня. А, например, в испанском такого нет. Случилось и случилось (и даже сейчас по-русски подразумевается, что случилось «что-то»).

Я проговорил на русском четверть века каждый день — и теперь физически не верю в случайности. Или верю, что мужчины важнее женщин, потому что весь язык завязан на мужском роде. Мою статью перевели на английский, в комменты пришли американцы с просьбами заменить местоимения на гендерно-нейтральные — и я не знаю, что делать со своим возмущением. А у немцев, например, таких проблем нет. Их язык давно гендерно-гибкий. И там все ходят в одну баню, а страной руководит женщина.

Язык управляет мной не меньше, чем я им, и это не тот выбор, который бы делал я сам. Его за меня сделали другие люди. Но естественный язык — штука древняя и неповоротливая, я не могу взять, и надавать по щам его создателям если мне в нем что-то не нравится. И не могу его сменить, по крайней мере легко.

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

И чем абстрактнее становится язык, тем сильнее из твоего мышления вымывается его реальная природа — контролировать электричество в железе. Все эти картинки у тебя на мониторе, циферки, библиотеки, анимации — они не настоящие. Настоящее только электричество. Только железо. Я не готов потерять над ним контроль.

Комментарии (339)

amarao
28.02.2019 17:07
#19819532
+9
Вся компьютерная индустрия, начиная со второго поколения компьютеров — бесконечная попытка забыть тот ужас, который нас ждёт с initial orders и осцилографом. Попытка забыть этот ужас порождает новый ужас (обычно меньшего размера), и идёт ещё одна попытка забыть ужас.

Если серьёзно — задача всего компьютерного — абстрагирование и уменьшение сложности. Каждый раз, когда сложность уменьшается, мы можем сделать больше (чем раньше) всего лишь восстановив уровень сложности. А потом ещё раз его уменьшить.

… Проблема начинается в тот момент, когда нижележащий уровень перестаёт прятать сложность и оно взрывается как пружина. Обычно люди просто стараются увернуться (включить/выключить, попробовать ещё раз), а не выяснять что именно там случилось.
1. NetBUG
  28.02.2019 23:26
  #19821276
  +4
  Я хорошо помню, как году в 2009 смотрел на Rails.
  Когда смотришь на готовый проект (что пример, что просто хороший чужой код) и всё очевидно. Начинаешь делать что-то сам — и упираешься в дикие ограничения, при решении которых натыкаешься либо на готовые сниппеты (магия!), либо городишь дикий код.
  Потом начинаешь оборачивать дикий код в магию.
  
  Тогда я это объяснил себе это спецификой декларативных языков, но в целом это свойственно для любой сложной системы — а код сейчас действительно сложный.
  1. develop7
    01.03.2019 02:57
    #19821856
    Начинаешь делать что-то сам — и упираешься в дикие ограничения, при решении которых натыкаешься либо на готовые сниппеты (магия!), либо городишь дикий код.
    Там до сих пор так
  1. JustDont
    01.03.2019 14:50
    #19824410
    В декларативщине обычно более заметно из-за того, что мало в какой декларативщине можно прыгнуть на нижележащий уровень и доработать там напильником. Но да, это в любой сложной системе так.
  1. max_mustermann
    01.03.2019 15:20
    #19824622
    Да, это именно специфика декларативных языков. Магия «мы описываем проблемму и оно как-то само нам говорит результат» не бесплатна и за ней стоит огромная «подводная» часть.
    
    Замените рельсу на SQL — ничего не изменилось.
    
    khim
    01.03.2019 18:09
    #19825598
    Рекорд, который я не знаю, будет ли побит когда-либо установил Пролог.
    
    Потому что он заявляет «вам нужно просто описать информацию о предметной области в терминах предметной области, а Пролог-система даст ответ».
    
    Но при этом достаточно в первой же нетривиальной программе из любого учебника по Прологу поменять две строки местами (а это, как понятно, «информацию о предметной области» не меняет) — и привет: программа зациклится и упадёт, сожрав предварительно всю память.
    
    Блеск!
    
    litwr2
    02.03.2019 14:30
    #19828382
    Вроде бы должно быть каждому понятно, что из описания нетривиальной задачи её эффективное решение не следует. Или, например, что связки И/ИЛИ на практике не коммутативны.
    
    khim
    02.03.2019 14:58
    #19828464
    Пробел пропустил. Имеется в виду «не тривиальная» задача, а не «нетривиальная».
    
    Как правило первая не тривиальная задача в учебниках — это набор фактов из Библии (пролог ещё до эпохи толерантности появился, там на Библию ещё можно ссылаться). Набор фактов вида «Исаак родил Иакова» и правила вывода (два):
    1. Если A родитель B, то A — предок B.
    2. Если A родитель B, а B — предок C, то A — предок C.
    Так вот если эти правила поменять местами, то программа «рассыплется».
    
    Восхитительная «декларативность».
    
    vchslv13
    02.03.2019 17:18
    #19828810
    Подождите, но тут всё достаточно логично (как для человека, который никогда не видел пролог). В правиле №2 должно быть известно что такое «предок», т.к. это нужно для интерпретации части условия («а B — предок C»). Или пролог даёт какие-то гарантии того, что порядок задания правил не важен?
    
    khim
    02.03.2019 18:00
    #19828882
    Оба правила вместе описывают что такое предок.
    
    Но с точки зрения человека последовательность этих правил — неважна. Такое определение: «предок твоего папы — это твой предок… ну и твой папа — тоже твой предок» — человек поймёт.
    
    А с точки зрения Пролога — важна. «Предок твоего папы — это твой предок… ну и твой папа — тоже твой предок» — Пролог не поймёт. Зациклится. Где декларативность?
    
    litwr2
    02.03.2019 19:50
    #19829182
    Это пример практической некоммутативности связки ИЛИ. Например, выбор на дороге: 1) налево — потеряешь голову, 2) направо — получишь приз. От того какой путь выбрать первым зависит как пойдут дела. :) Так и и пролог. Проблема не в нем, а в природе логики.
    
    khim
    02.03.2019 21:02
    #19829382
    Это пример практической некоммутативности связки ИЛИ.
    Извините, но это бред. Эти два правила для любой пары объектов дают ровно один ответ на вопрос «является ли Исаак предком Иакова» — независимо от порядка.
    
    Например, выбор на дороге: 1) налево — потеряешь голову, 2) направо — получишь приз. От того какой путь выбрать первым зависит как пойдут дела. :)
    Это называется — императи?вное программи?рование
    
    Проблема не в нем, а в природе логики.
    Нет — проблема в том, что некоторые люди не умеют отличать декларативное программирование от императивного.
    
    Пролог просто является классической подменой понятий: вначале нам объясняется, что Prolog является декларативным языком программирования, а потом — объясняется как работает Prolog-машина и оказывается, что мы должны не писать декларативное описание этой задачи, а программировать вот эту вот, вполне императивную, машину…
    
    litwr2
    02.03.2019 21:33
    #19829466
    Если вы хотите сделать что-то с практическими результатами, вам придется разбираться с порядком применения правил — равноправия на практике обычно не получится. Перепишите мой пример в виде «налево — потеряешь голову» ИЛИ «направо — получишь приз» — какая тут императивность, 100% декларативность, но от того, за что вы возьметесь в первую очередь, зависит результат.
    
    0xd34df00d
    02.03.2019 21:37
    #19829478
    Какая разница для связки, что вы делаете в первую очередь?
    
    В этой нашей теории типов A V B кодируется как ?C: *. (A > C) > (B > C) > C. То есть, для любого действия, выполняемого и при походе налево, и при походе направо, разницы таки нет совсем.
    
    litwr2
    03.03.2019 09:21
    #19830216
    Если вам нужна теория для её самой, то разницы о очередности нет, а если вы что-то хотите от теoрии практического, то есть. Это и отражается в прологе, как в практическом инструменте. Если кто-то останется без головы, то приз получать уже будет никому. Декларативность предполагает обычно слишком много вариантов и зацикливание — это тоже вариант. От перемены местами дизъюнктов в вашем примере вы его и получаете. В 90-е кто-то предлагал вариант пролога с со случайным выбором — интересный подход, но, полагаю, что он сильно понижает производительность работы. Кому нужен ответ, полученный через 100 лет? Получается выбор: 1) изобретать замысловатые системы логики, конкурировать с Аристотелем; 2) пытаться сделать эффективные машины логического вывода — это пролог, SQL, скорее неудачный и несостоявшийся меркурий,…
    
    khim
    03.03.2019 14:32
    #19830806
    Ещё раз, для идиотов. Цитирую:
    
    Декларати?вное программи?рование — это парадигма программирования, в которой задаётся спецификация решения задачи, то есть описывается, что представляет собой проблема и ожидаемый результат.
    
    Противоположностью декларативного является императивное программирование, описывающее на том или ином уровне детализации, как решить задачу и представить результат.
    
    Так вот спецификация — не должна превращаться в тыкву при перестановке двух строк местами. Это уже не «описание проблемы», а бог-знает что.
    
    Можно сколько угодно рассказывать про сложности работы со спецификациями, но практически — вы либо умеете с ними работать, либо нет. Пролог — не умеет. Он умеет работать только со специцикациями заточенными под Пролог-машину и учитывающими то, что у неё «под капотом». Какая тут, нафиг, декларативность?
    
    AlexLeonov
    02.03.2019 00:56
    #19827042
    SQL вполне себе императивен, если вы освоили концепцию «вложенных циклов»
1. yarston
  01.03.2019 00:38
  #19821526
  +2
  Да ну, перешёл с джавы на си для своих проектов — наоборот, всё стало гораздо проще. Не нужно писать ненужный бойлерплейт в угоду ООПшным шаблонам проектирования, питать надежды, что всё это влезет в память, а не упадёт с OOM, профилировать перформанс — и так ясно, что всё предельно быстро будет и без задержек на GC, не нужно думать о том, откуда на клиентском устройстве JVM возьмётся, почти не нужен рефакторинг, т.к. без классов функции никак друг с другом не связаны.
  Отличный язык для быстрого прототипирования) Просто фигачишь функции и они просто работают)
  1. imanushin
    01.03.2019 11:14
    #19822996
    +4
    всё предельно быстро будет
    Аллокатор, я надеюсь, у вас тоже не требует синхронизации между потоками? И программа работает на x84/x64/arm/aarch64 без компиляции? И векторизация инструкций тоже будет использоваться, да? И порядок инструкций поменяется на лету, ради скорости, да?
    
    без задержек на GC
    Аллокатор не фрагментарнтирует память, да? И free у Вас работает в отдельном потоке, как на Java, да?
    
    не упадёт с OOM
    Модель памяти у Вас простая, сама память не течёт, грязную память вы не используете, да?
    
    Отличный язык для быстрого прототипирования)
    А для боевого применения?
    
    на клиентском устройстве
    А отладку сможете делать на нем, если у Вас на рабочей машине другая ОС/архитектура процессора?
    
    Если подытожить: Ваши аргументы крайне спорные. И далеко не так очевидно, что С быстрее, удобнее и т.д.
    
    yarston
    01.03.2019 12:19
    #19823482
    Аллокатор, я надеюсь, у вас тоже не требует синхронизации между потоками?
    Не требует.
    
    И программа работает на x84/x64/arm/aarch64 без компиляции?
    Какая разница, +1 архитектура — всего лишь строчку в мейфайл добавить и поставить компилятор, что куда проще и симпатичнее, чем например, jvm под iOS запихнуть в дистрибутив приложения.
    
    И векторизация инструкций тоже будет использоваться, да?
    Да, автовекторизация и прочие оптимизации весьма недурно производительность поднимают.
    
    И порядок инструкций поменяется на лету, ради скорости, да?
    Если порядок меняет результат вычисления, и при этом нет грубых нарушений правил языка, ничего не поменяется.
    
    Аллокатор не фрагментарнтирует память, да? И free у Вас работает в отдельном потоке, как на Java, да?
    На практике вклад malloc/free во время исполнения с лупой искать надо.
    
    Модель памяти у Вас простая, сама память не течёт, грязную память вы не используете, да?
    Да вроде не течёт, тем более сама)
    
    А для боевого применения?
    Проще 1 раз на 1 языке написать, чем писать на # под венду, java на андроид, swift на ios и js для веба. Для этого не так много языков годится.
    
    А отладку сможете делать на нем, если у Вас на рабочей машине другая ОС/архитектура процессора?
    Для отладки компилятор зашивает в бинарник всё необходимое, при чём здесь ОС и процессор. В С я могу включить в отладочных целях проверки обращения к памяти например, как в той же Java, в релизе могу выключить и получить прирост производительности, а в Java — нет, не доверяет она разработчику.
    
    playermet
    01.03.2019 12:25
    #19823526
    всего лишь строчку в мейфайл добавить и поставить компилятор
    Это так просто не работает.
    
    yarston
    01.03.2019 13:05
    #19823758
    В Android именно так и работает, даже доустанавливать ничего не нужно.
    gist.github.com/ph0b/69586260bc20c58136ef
    
    4410
    01.03.2019 13:07
    #19823762
    +1
    Проще 1 раз на 1 языке написать, чем писать на # под венду, java на андроид, swift на ios и js для веба. Для этого не так много языков годится.
    
    Покажите ваш проект на си, чтобы один раз, да сразу для iOS и для веба и для винды.
    
    yarston
    01.03.2019 13:28
    #19823876
    Пока рано что-то показывать, однако не вижу, что мне помешает OpenGL приложение собрать под разные платформы. Схема «пишу под десктоп — иногда поглядываю, что там на андроид» уже работает, хотя конечно под андроид отдельная обёртка и шейдеры отличаются и OpenGL ES вместо обычного OpenGL, и отдельный проект в Android Studio, но сишное ядро приложения одно.
    
    4410
    01.03.2019 13:34
    #19823922
    +1
    Между «теоретически возможно» и «устоявшаяся технология, экономящая время» огромная пропасть. И она, с огромной долей вероятности, для Си не будет преодолена.
    
    Схема «пишу под десктоп — иногда поглядываю, что там на андроид» уже работает, хотя конечно под андроид отдельная обёртка и шейдеры отличаются и OpenGL ES вместо обычного OpenGL, и отдельный проект в Android Studio, но сишное ядро приложения одно.
    
    Получается не один раз, а под каждую платформу придётся писать что-то, а переиспользуется только какая-то небольшая часть? Я вам подскажу, таким занимается куча людей из устоявшихся технологий, и пока даже просто между iOS и Android настолько большая разница, что всё чаще возникают вопросы имеют ли смысл все эти Xamarin и React Native, если приложение больше пары простых скринов.
    
    yarston
    01.03.2019 14:02
    #19824080
    Си как-то странно причислять к неустоявшимся технологиям, языку ~50 лет, инструментов и кейсов применения для него наработано огромное количество, множество платформ имеют официальную поддержку, есть стандарты, при соблюдении которых эта поддержка гарантирована.
    
    Получается не один раз, а под каждую платформу придётся писать что-то, а переиспользуется только какая-то небольшая часть?
    Переиспользуется как раз почти всё, написание чего требовало каких-то усилий. Обёртка под андриод — уровня хэлловорлда, причём даже не написанная, а тупо позаимствованная из NDKшных примеров.
    
    Я вам подскажу, таким занимается куча людей из устоявшихся технологий, и пока даже просто между iOS и Android настолько большая разница, что всё чаще возникают вопросы имеют ли смысл все эти Xamarin и React Native, если приложение больше пары простых скринов.
    Ну если есть деньги на N команд разработки, то почему бы и не писать под каждую платформу отдельно. У меня нет)
    
    4410
    01.03.2019 14:09
    #19824114
    Си как-то странно причислять к неустоявшимся технологиям, языку ~50 лет, инструментов и кейсов применения для него наработано огромное количество, множество платформ имеют официальную поддержку, есть стандарты, при соблюдении которых эта поддержка гарантирована.
    
    Вот только использование Си для написания приложений сразу под веб и все остальные платформы — не устоявшийся кейс. Можете показать какие-то инструменты для этого, сравнимые с React Native?
    
    Переиспользуется как раз почти всё, написание чего требовало каких-то усилий. Обёртка под андриод — уровня хэлловорлда, причём даже не написанная, а тупо позаимствованная из NDKшных примеров.
    
    Пока вы не можете показать код — это просто слова. Я допускаю возможность каких-то частных случаев, когда это реально возможно с минимальным добавлением платформоспецифичного кода. Но вы писали о приложениях на Си под все платформы сразу.
    
    Ну если есть деньги на N команд разработки, то почему бы и не писать под каждую платформу отдельно. У меня нет)
    
    Я вам ещё раз повторю написанное: компании, использующие инструменты с огромным комьюнити, покрывающие гораздо более простые кейсы (iOS+Android), сомневаются в целесообразности этого. Именно с денежной точки зрения.
    
    yarston
    01.03.2019 14:34
    #19824302
    Зачем вам именно мой код, есть известные игровые движки Unreal Engine / Unity с большим сообществом, и некоторые другие, позволяющие собирать игры на Windows/Mac/Linux/Web/Android/iOS.
    И есть простые примеры типа такого github.com/redblobgames/helloworld-sdl2-opengl-emscripten
    
    Себе я запилил удобный фреймворк, на котором приятно работать, вот например разметка + внешний вид + добавление кнопки:
    
    static LayoutsParams lbPersNew = {.width = 320, .height = 96, .gravity = CENTER_HORIZONTAL | TOP, .marginTop = 8, .marginTopPercent = .333}; static TextureParams tbPersNew = {.texLeft = 225, .texTop = 249, .texRight = 263, .texBottom = 287}; static NinePathParams nbPersNew = {.vertTop = 16, .vertBottom = 16, .horLeft = 16, .horRight = 16}; //... void initGui() { bPersNew = BUTTON(0, &onPersNewPressed, &lbPersNew, &tbPersNew, &nbPersNew, VISIBLE);
    
    //…
    
    Вы видите здесь что-то платформоспецифичное? Разметку и другие параметры я могу объявить в другом файле, если захочется разный вид приложения на разных платофрмах сделать, могу как есть оставить.
    
    4410
    01.03.2019 15:20
    #19824616
    +2
    Зачем вам именно мой код, есть известные игровые движки Unreal Engine / Unity с большим сообществом, и некоторые другие, позволяющие собирать игры на Windows/Mac/Linux/Web/Android/iOS.
    
    Во-первых, что под UE нужно писать на плюсах, под юнити на C# или UnityScript. Во-вторых, вы же в курсе что люди не только игры пишут, да?
    
    В реальном мире даже просто нарисовать дизайн, который бы просто был удобен на всех платформах, это уже большая проблема. Не говоря уже о том, что он должен подходить под гайдлайны платоформ и быть привычным пользователям платформы.
    
    .width = 320
    
    320 чего?
    
    yarston
    01.03.2019 18:11
    #19825610
    320 чего?
    
    Масштабируемых единиц, конечно же)
    
    вы же в курсе что люди не только игры пишут, да?
    У меня приложение, и есть все нужные для него виджеты, аналоги андроидных ImageView, TextView, ListView с линейным списком и сеткой, скроббары, прогрессбар, кнопки. Всё, к чему привык на андроид, в облегченном варианте и кроссплатформенно.
    
    Во-первых, что под UE нужно писать на плюсах, под юнити на C# или UnityScript.
    Я уже писал, что по моим ощущениям, С уменьшает сложность по сравнению с C++ или C#. На С++ код иногда без боли не взглянуть.
    
    4410
    01.03.2019 18:18
    #19825664
    Масштабируемых единиц, конечно же)
    
    Вы же в курсе, что в браузере их не существует?
    
    У меня приложение, и есть все нужные для него виджеты, аналоги андроидных ImageView, TextView, ListView с линейным списком и сеткой, скроббары, прогрессбар, кнопки. Всё, к чему привык на андроид, в облегченном варианте и кроссплатформенно.
    
    Как думаете, ваше приложение пройдёт ревью в App Store?
    
    yarston
    01.03.2019 18:22
    #19825678
    Как думаете, в AppStore есть игры с виджетами на 3д графике и непонятно какой логикой мастшабирования?
    
    Вы же в курсе, что в браузере их не существует?
    выбор коэффициента масштабирования — задача платоформозависимой обёртки, можно положить =1, если лучшего решения не найдётся.
    
    4410
    01.03.2019 18:53
    #19825822
    Всё ещё не понимаю что вы хотите сказать.
    
    Что на Си можно написать на движке игру и она будет работать на всех платформах? Нет, нельзя. Зато можно сделать на C# или C++.
    
    Что можно написать на Си кроссплатформенное приложение? Нет, нельзя. Как минимум, вам придётся создавать UI на OpenGL с нуля. Чем вы и занимаетесь.
    
    Что вы можете написать велосипед и добавлять в него платформы со временем? Ну удачи. Наберёте когда сделаете 3-4. Как раз с точки зрения финансов это просто выброшенные на ветер деньги. Только какие тут преимущества у Си?
    
    yarston
    01.03.2019 22:50
    #19826690
    Благодарю за комплимент, очень приятно слышать, что я делаю невозможное. У меня сложность не в UI, он уже есть и работает на 2х платформах как минимум (Android + Linux + Mac (?) Windows(?)), где (?) — не протестировано, но должно работать без изменений. Профит для меня как разработчика самый прямой — если раньше я просто шлёпал формочки, то сейчас в резюме могу дописать больше интересных вещей и продать своё время дороже, + 50%...100% — это более чем окупит потраченное время, если пересчитать на стандартную оплату труда. Это минимум. Цель — запустить крутой продукт и заработать о***лиарды)
    
    Только какие тут преимущества у Си?
    Вы видели эти божественные скобочки, которые я выше привёл? Я могу частично инициализировать структуру! Да это же как JSON! Я могу на си описывать UI с такой же лёгкостью, как JSON написать! В С++ такого нет, в джаве нет, в андроид блеклая эмуляция декларативного описания через XML, в iOS муки и матюки на StoryBoard или как там их инструмент разметки называется, несовместимый с git, в котлин чуть удобнее сделали, но всё равно не то.
    
    Кроме того, Си на мой взгляд меньше всего ограничивает свободу, и при этом при помощи нехитрых макросов ему можно придать выразительность, не уступающую модным фишкам из С++, в т.ч. тем что только готовятся для включения в стандарт. for с ренжами например. Мне нравится его гибкость.
    
    На Си можно писать в функциональном стиле, с функциями можно обращаться как с переменными, надеюсь вы не станете отказывать функциональному программированию в праве на существование? Си — это как Хаскель на минималках, достаточно функциональный для практического применения, но всё ещё с ручным контролем памяти.
    
    Си замечательно дружит со многими другими языками. Я могу просто закинуть сишные файлы в проект на С++/objective-C/D, вроде Swift тоже, могу подключить к проекту на Java через jni, могу сишную либу слинковать с любым другим компилируемым языком. У С++ тут уже начинаются проблемы.
    
    Далее, Си — простой для чтения и написания язык. Я могу показать код программисту на Java/C++/JS/C# и пр., и он гарантированно поймёт, что тут проиходит. Можно смотреть его в плейнтекст и не ломать голову, что это за auto.
    
    Си программы быстро компилируются и быстро запускаются, за 1 секунду я могу собрать (инкрементально) проект и запустить приложение, полная пересборка всего ~4c, а в Java я успею попить кофе, пока всё соберётся, в С++ и подавно.
    
    khim
    01.03.2019 23:31
    #19826810
    В С++ такого нет
    Чего нет? Designated initializers? Поддерживаются уже лет 10 clang'ом и GCC, включены в C++20. В MSVC, да, беда — ну так там их с в C нет, ибо C99 MSVC не поддерживает.
    
    0xd34df00d
    01.03.2019 23:45
    #19826850
    На Си можно писать в функциональном стиле, с функциями можно обращаться как с переменными, надеюсь вы не станете отказывать функциональному программированию в праве на существование?
    Можете map и foldr на С написать?
    
    Желательно, чтобы foldr по ленивой структуре данных вычислялся лениво.
    
    Си — это как Хаскель на минималках, достаточно функциональный для практического применения, но всё ещё с ручным контролем памяти.
    Прелесть хаскеля не в том, что там с функциями можно обращаться как с переменными (кстати, нельзя), а в мощной системе типов.
    
    Я вообще не понимаю этого восторга от функционального программирования как от банального STLC. В типах всё счастье-то, а не в том, что фукнции можно передавать в функции.
    
    yarston
    02.03.2019 00:19
    #19826956
    Map написал уже, синтксис другой немного, суть та же: берём список элементов одного типа, создаём из него список элементов другого типа по коду в скобках.
    
    Использование:
    
    0xd34df00d
    02.03.2019 04:56
    #19827376
    Что-то это не очень на С.
    
    Да, препроцессор является частью С, но мы обсуждаем таки сишную часть. Ну или мне так казалось.
    
    Ну если охота о препроцессоре думать — давайте всё равно рассуждать гомоиконно и делать map на препроцессоре, который принимает макру и список на препроцессоре и применяет макру к каждому элементу списка.
    
    Если что, в Boost.PP такое есть. Получается, препроцессор годнее сишечки!
    
    yarston
    02.03.2019 08:38
    #19827530
    А давайте сравним перформанс и читабельность кода? В бусте я Map в смысле преобразования списков не нашёл, так что через std::transform
    C:
    
    time ./cppapplication_4
    el = 1
    el = 11
    el = 21
    el = 31
    el = 41
    el = 51
    el = 61
    el = 71
    el = 81
    el = 91
    
    real 0m0,583s
    user 0m0,486s
    sys 0m0,097s
    
    с++:
    
    time ./cppapplication_3
    foo contains: 11 21 31 41 51 61 71 81 91 101
    
    real 0m3,828s
    user 0m3,734s
    sys 0m0,092s
    
    Разница по времени не в пользу С++, да и читаемость так себе.
    
    humbug
    02.03.2019 10:00
    #19827758
    А давайте сравним с Rust:
    
    vec.rs:
    
    fn main() { let vec = vec![0; 100000000]; vec.into_iter().enumerate() .map(|(idx, _el)| idx * 10) .map(|x| x + 1) .take(10) .for_each(|x| { println!("el = {}", x); }); }
    
    Компиляция:
    
    $ rustc vec.rs -O
    
    $ time ./vec el = 1 el = 11 el = 21 el = 31 el = 41 el = 51 el = 61 el = 71 el = 81 el = 91 real 0m0.003s user 0m0.003s sys 0m0.000s
    
    Поиграться с кодом на playground
    
    OMG пыщ-пыщ РАСТ БЫСТРЕЕ С в 200 раз и быстрее С++ в 1200 раз!!!111
    Сомнительный бенчмарк, сэр. Тем не менее, этот сомнительный бенчмарк показывает, на что способен оптимизатор Раста =)
    
    humbug
    02.03.2019 10:09
    #19827790
    На самом деле это было на ленивых вычислениях. Тем не менее, без ленивых вычислений:
    
    fn main() { let vec = vec![0; 100000000]; let vec: Vec<_> = vec.into_iter().enumerate() .map(|(idx, _el)| idx * 10) .map(|x| x + 1).collect(); vec.into_iter() .take(10) .for_each(|x| { println!("el = {}", x); }); }
    
    real 0m0.281s user 0m0.072s sys 0m0.208s
    
    А в C++ версии вы сделали инициализацию массива из 100000000 элементов с помощью push_back, не удивительно, что оно так тормозит. Вы-то себе пачкой выделили память.
    
    Читайте про амортизированную стоимость.
    
    yarston
    02.03.2019 20:52
    #19829364
    То с дебажным флагом компилятора было, с -03
    real 0m0,133s
    user 0m0,072s
    sys 0m0,061s
    И это я ещё OpenMP не подключил для автопараллелизации циклов)
    Раст прикольная конечно штука, но пока экзотика)
    
    humbug
    03.03.2019 10:15
    #19830292
    Вся смехота заключается в том, что мы одни бенчи запускаем на одном железе, а другие на другом. Вот таблица бенчей:
    
    ArrayListTest.c:
    
    real 0m0.497s user 0m0.292s sys 0m0.205s
    
    cpp:
    
    int op_increase(int i) { return ++i; } int main() { std::vector<int> foo; foo.reserve(100000000); for (int i=0; i<100000000; ++i) foo.push_back(i*10); std::transform (foo.begin(), foo.end(), foo.begin(), op_increase); for(size_t i = 0; i<10; ++i) { std::cout << foo[i] << std::endl; } }
    
    real 0m0.254s user 0m0.148s sys 0m0.108s
    
    rust (вариант выше):
    
    fn main() { let vec = vec![0; 100000000]; let vec: Vec<_> = vec.into_iter().enumerate() .map(|(idx, _el)| idx * 10) .map(|x| x + 1).collect(); vec.into_iter() .take(10) .for_each(|x| { println!("el = {}", x); }); }
    
    real 0m0.286s user 0m0.097s sys 0m0.189s
    
    rust (параллельные итераторы):
    
    use rayon::prelude::*; fn main() { let vec = vec![0; 100000000]; let vec: Vec<_> = vec.into_iter().enumerate() .map(|(idx, _el)| idx * 10) .map(|x| x + 1).collect(); vec.into_iter() .take(10) .for_each(|x| { println!("el = {}", x); }); }
    
    real 0m0.112s user 0m0.302s sys 0m0.314s
    
    Пока что лидирует Rust =)
    
    И это я ещё OpenMP не подключил для автопараллелизации циклов)
    Только код скиньте.
    
    0xd34df00d
    02.03.2019 18:54
    #19829004
    У меня нет ArrayList, поэтому не могу воспроизвести. С какими опциями вы собирали код?
    
    Кроме того, это немножко читерство: в плюсах вы не выделили всё место сразу, а в С — выделили.
    
    Ну и, кроме того, как-то мы резко сменили тему с написания сишного map на микробенчмарки.
    
    yarston
    02.03.2019 20:47
    #19829352
    github.com/yarston/ArrayListTest выложил сюда. собиралось c gcc -g в прошлом посте.
    Сделал вариант бенчмарка с пушем в список по 1 элементу.
    Вариант с пушем с -O3:
    
    make && time ./a.out
    real 0m0,394s
    user 0m0,321s
    sys 0m0,073s
    
    С единоразовым выделением памяти gcc -O3:
    
    make && time ./a.out
    real 0m0,133s
    user 0m0,072s
    sys 0m0,061s
    
    Проц i73630QM 2.2 ГГц
    
    Ну и, кроме того, как-то мы резко сменили тему с написания сишного map на микробенчмарки
    Ну он написан же, что там ещё обсуждать. Перформанс вроде как важен для сишников.
    void* add2ArrayList(ArrayList *list) работает несколько не так как в C++, он не добавляет элемент сам, а только увеличивает счётчик, если надо, реаллоцирует и возвращает указатель, по которому уже можно писать данные. Например, указатель на структуру.
    
    Кроме того, это немножко читерство: в плюсах вы не выделили всё место сразу, а в С — выделили.
    На самом деле я скопипастил плюсовый код с какого-то сайта. Ну вот пишут они так.
    
    0xd34df00d
    02.03.2019 21:49
    #19829500
    github.com/yarston/ArrayListTest выложил сюда.
    Спасибо. ХЗ, у меня сишка чего-то тормозит:
    0.53 с для вашего варианта (только я ещё -march=native добавил).
    0.36 с для плюсового варианта с reserve + push_back.
    0.31 с для плюсового варианта с resize + operator[], чтобы не проверять capacity на каждой вставке.
    
    Если честно, я думал, разница между двумя последними вариантами будет не такой большой — по идее, бранч предиктор должен очень быстро научиться, что проверка на capacity всегда проходит. Интересно.
    
    gcc 8.3.0, i7 3930k.
    
    PS. Поигрался ещё.
    
    Если убрать bar и писать сразу в тот же foo, то получаем 0.18 с.
    
    Кроме того, заметил, что у вас там Slow вместо Fast. Заменил в вашем коде на getFast — да, стало работать быстрее, та же 0.31 с, что и для плюсового кода.
    
    Теперь можно сравнить, насколько универсальны std::transform и этот ваш макрос соответственно.
    
    Ну он написан же, что там ещё обсуждать.
    Нет, там написан не он. Там написаны инструкции для кодогенератора (сишного препроцессора), как сделать сишный map для каждой конкретной функции (да и то в виде блока кода, а не произвольного указателя на функцию).
    
    Так мы с вами дойдём и до того, что в Go дженерики есть, потому что их можно кодогенерировать.
    
    yarston
    02.03.2019 22:05
    #19829544
    у меня сишка чего-то тормозит:
    странно, у меня
    gcc --version
    gcc (SUSE Linux) 8.2.1 20190204 [gcc-8-branch revision 268513]
    
    Правда у меня ещё патчи против спектр отключены. Там getSlow() по умолчанию стоит, его можно закомментить и собрать с единоразовым выделением памяти.
    Нет, там написан не он.
    Звучит как повод для дискусси, но лень спорить) Да и ладно, списки крутятся, работа мутится.
    
    Если убрать bar и писать сразу в тот же foo, то получаем 0.18 с.
    это уже другая задача.
    
    0xd34df00d
    02.03.2019 22:07
    #19829550
    У меня патчей против всех этих спектров тоже нет, зачем они мне на десктопе.
    
    Кстати, к слову о функциональщине — если вам будет охота, предлагаю написать две функции, map и foldr, и сделать по вашему списку, например, map с увеличением на единичку (как сейчас), а потом свертку с суммированием, и посмотреть, сколько времени это займёт. Потом можно будет сравнить с Ъ функциональщиной.
    
    yarston
    02.03.2019 22:12
    #19829566
    Нет наверно, спать охота, и тут запрос на webassembly порт поступил. Почему у вас такие цифры времени исполнения — для меня загадка, на вашем процессоре быстрее должно же быть по идее.
    
    0xd34df00d
    02.03.2019 22:17
    #19829576
    Оно в память всё упирается, думаю (а запускать vtune лень). Надо суммарно почти гигабайт через шину прогнать, что даёт оценку снизу на время выполнения где-то в 100-150 мс на моей машине. Повод обновиться на DDR4, на самом деле.
    
    Но, в любом случае, важны не абсолютные цифры, а сравнение с плюсовой версией (которое я таки дал).
    
    yarston
    02.03.2019 22:24
    #19829586
    Замена
    CONVERT_VEC_TYPE(unsigned, in, list, unsigned, out, list2) *out = *in + 1;
    на
    FOR(unsigned, el, list) (*el++)++;
    :
    make && time ./a.out
    gcc -O3 list.c main.c
    el = 1
    el = 10
    el = 21
    el = 30
    el = 41
    el = 50
    el = 61
    el = 70
    el = 81
    el = 90
    
    real 0m0,090s
    user 0m0,070s
    sys 0m0,020s
    
    0xd34df00d
    02.03.2019 22:26
    #19829592
    Что-то, судя по выводу, это неэквивалентная замена.
    
    yarston
    02.03.2019 22:31
    #19829600
    Да, спать пора) Инкремент указателя внутри макроса же делается.
    
    FOR(unsigned, el, list) (*el)++;
    
    gcc -O3 list.c main.c
    el = 1
    el = 11
    el = 21
    el = 31
    el = 41
    el = 51
    el = 61
    el = 71
    el = 81
    el = 91
    
    real 0m0,089s
    user 0m0,060s
    sys 0m0,028s
    
    0xd34df00d
    02.03.2019 22:39
    #19829624
    Тут, кстати, отлично видно, зачем на самом деле нужен map. Все эти функциональные map, filter и foldr нужны не для того, чтобы циклы на них переписывать, а для того, чтобы ограничить доступные вам действия. Хаскелевский мап не передаёт функции ничего, кроме текущего элемента — значит, у него нет никакого состояния, и преобразование действительно зависит только от текущего элемента (в отличие от foldr, например, для которого это не так, но через который можно выразить map). Плюсовый трансформ не передаёт указатель на элемент или итератор, а только сам элемент. Все эти функции хороши тем, что они связывают вам руки.
    
    yarston
    02.03.2019 22:33
    #19829604
    Ну у меня DDR3, ноут 13года что ли.
    
    0xd34df00d
    02.03.2019 22:40
    #19829626
    Страннота. Я эту машину тоже в 13-м году собирал.
    
    yarston
    02.03.2019 00:58
    #19827052
    Ехал this через this, сунул this в this auto, this this this this this this this this)
    
    OldPrg
    02.03.2019 02:37
    #19827262
    Ты в золотой середине. Можно дрова писать и приложения для людей. Мы спрыгнули в начале 90-х с С и подобных языков в погоне за баблом. Тогда нужны были бухгалтерско-банковские десктопно-локально-сетевые проги. Брали Clipper, написанный на С, и за месяц рисовали то, что на С создавали бы год. Поэтому, если С есть наработка и не происходит отставания по времени исполнения проектов от конкурирующих языков, то жаба — это ничто по сравнению с С, тем более, что на кофеварке крест ларри поставил, но никак не может сдать в утиль. Вторая сторона луны — это где найти команду сишников, которая гребет не меньше жабокодеров. Т.е., сравниваем, сколько бабла дает С по сравнению с другими.
    
    androidovshchik
    01.03.2019 18:11
    #19825612
    Кстати, например, Flutter (скорее всего и другие аналоги) пошел по этому пути. Он есть ничто иное, как 2d движок по типу игрового, но отрисовывает только виджеты и тп) Гениально!) Сишные бинарики просто идут в комплекте с приложением
    
    yarston
    01.03.2019 18:25
    #19825686
    Да, вот гугл тоже в этом направлении думает.
    
    zagayevskiy
    01.03.2019 16:48
    #19825172
    +1
    Вы видите здесь что-то платформоспецифичное?
    
    Да. 9-patch это андроидовская тема.
    В чём у вас измеряются все магические константы — непонятно.
    
    yarston
    01.03.2019 18:11
    #19825622
    У меня кроссплатформенная реализация. 320 dp.
    
    zagayevskiy
    01.03.2019 16:38
    #19825106
    На iOS без плясок с бубном уже не взлетит.
    
    yarston
    01.03.2019 18:13
    #19825642
    Потому что Metal? Переписать вызовы OpenGL на Metal должно быть несложно, суть-то одна, названия методов только отличаются.
    
    0xd34df00d
    01.03.2019 17:34
    #19825410
    +1
    Да, автовекторизация и прочие оптимизации весьма недурно производительность поднимают.
    И компиляторы уже такие умные стали, что автоматически векторизуют всё, что можно векторизовать?
    
    Может, оно вам и AoS в SoA само конвертирует?
    
    На практике вклад malloc/free во время исполнения с лупой искать надо.
    Везёт вам там. У меня бывают проекты, где приходится писать свои аллокаторы, с аренами и вот этим всем.
    
    yarston
    01.03.2019 23:01
    #19826720
    И компиляторы уже такие умные стали, что автоматически векторизуют всё, что можно векторизовать?
    
    Ну у меня например, софтварный растеризатор треугольников на Си без интрисинков с опцией -O3 ~180мс на отрисовку сцены 8к полигонов в 4к (3840*2160) в 1поток на ноутбучном CPU, а с интрисинками (SSE4.2), оптимизацией размещения данных в структуре и выравниванием в памяти ~160мс. Пожалуй под неон забью на ручную векторизацию.
    
    Может, оно вам и AoS в SoA само конвертирует?
    А зачем? Я сразу пишу как надо.
    
    У меня бывают проекты, где приходится писать свои аллокаторы, с аренами и вот этим всем.
    В линуксовой libc аллокатор с аренами как раз. Если что, можно её статически линковать, не уверен правда, позволяет ли лицензия.
    
    0xd34df00d
    01.03.2019 23:49
    #19826866
    +1
    Ну у меня например, софтварный растеризатор треугольников на Си без интрисинков с опцией -O3 ~180мс на отрисовку сцены 8к полигонов в 4к (3840*2160) в 1поток на ноутбучном CPU, а с интрисинками (SSE4.2), оптимизацией размещения данных в структуре и выравниванием в памяти ~160мс.
    А у меня есть код, у которого производительность отличается на порядок. И при этом я далеко не спец в SIMD, так, мимо проходил.
    
    А про разницу всяких dlib'ов или eigen'ов с ручными операциями с матрицами против MKL я и говорить не хочу.
    
    А зачем? Я сразу пишу как надо.
    Ну а чего б и нет? В терминах AoS таки чуть удобнее размышлять.
    
    В линуксовой libc аллокатор с аренами как раз. Если что, можно её статически линковать, не уверен правда, позволяет ли лицензия.
    У меня как у программиста чуть больше информации о времени жизни объектов. Например, я знаю, что по условиям задачи я могу выделять память из арены, не освобождая её до окончания обработки запроса вообще никогда, и одним махом всё уничтожить в самом конце. Компиляторы пока не такие умные, к сожалению.
    
    yarston
    02.03.2019 00:35
    #19827000
    Кто лучше решение может предложить? Java? .NET? У них ещё меньше информации.
    
    0xd34df00d
    02.03.2019 04:58
    #19827378
    Решения чего? По памяти?
    
    Языки с элементами субструктурных систем типов могут, например. Но да, не джава и не .NET.
    
    Правда, и в этом случае будут проблемы — оптимизации во многом зависят от ожидаемых объёмов, времен жизни и тому подобного, которые непонятно как передать компилятору, кроме как через PGO.
    
    PsyHaSTe
    02.03.2019 20:33
    #19829312
    Растовые лайтфайфы не подойдут?
    
    0xd34df00d
    02.03.2019 21:50
    #19829502
    Нет, потому что проблему из последнего абзаца они не решают.
    
    PsyHaSTe
    02.03.2019 23:40
    #19829786
    Ну вот мы знаем размеры объектов, времена жизни. Что еще надо? Просто проблему не понимаю.
    
    0xd34df00d
    03.03.2019 00:16
    #19829878
    Надо ещё знать, что их можно выделять из одного блока памяти, который потом можно прибить целиком.
    
    PsyHaSTe
    03.03.2019 02:03
    #19829984
    Ну сделать это локально не очень трудно.
    
    А глобально да, в голову ничего не приходит.
    
    balsoft
    02.03.2019 14:56
    #19828458
    С быстрее
    Очевидно. Удобнее — уже очень сомнительно.
  1. 0xd34df00d
    01.03.2019 17:35
    #19825416
    +2
    профилировать перформанс — и так ясно, что всё предельно быстро будет
    А люди, дураки, зачем-то всё равно тяжёлый вычислительный код под профайлерами гоняют. А можно-то просто писать на сях, оказывается!
    
    Отличный язык для быстрого прототипирования)
    И код реюзабельный, и в языке все средства для этой реюзабельности есть, ага.
    
    И да, это сарказм. И нет, это не про торжество ООП.
    
    yarston
    01.03.2019 23:04
    #19826736
    Реюзать функцию без ссылок на this проще, чем с. Нет ООП — нет this. Чистые функции как они есть.
    
    0xd34df00d
    01.03.2019 23:50
    #19826868
    Мне ООП не нравится по другим причинам.
    
    this — это всего лишь ещё одна ссылка, ничем не отличающаяся от любой другой.
1. Zenitchik
  01.03.2019 15:34
  #19824744
  Обычно люди просто стараются увернуться (включить/выключить, попробовать ещё раз), а не выяснять что именно там случилось.
  
  Так ещё Чарльз Беббидж говорил, что выгоднее (по времени) пересчитать заново всю ошибочную страницу, чем искать в ней ошибочные значения.
1. sergeperovsky
  03.03.2019 03:09
  #19830008
  Всякая абстракция имеет дыры. Целые «числа» имеют максимально возможные значения. Вещественные переменные на самом деле имеют ограниченный набор дискретных значений.
  Вычитание из большого числа маленького может не приводить к изменению значения. И т.д.
  Но стек абстракций уже слишком велик, чтобы кто-то мог его весь знать в подробностях.
  Мы не чиним двигатель через выхлопную трубу. Мы едем на СТО и просим специалиста залезть пд капот.

Serge3leo
28.02.2019 17:14
#19819588
+2
Не готовы потерять контроль? Как было сказано: «Принеси ведро электронов!»

Juralis
28.02.2019 17:21
#19819630
+1
> Все эти картинки у тебя на мониторе, циферки, библиотеки, анимации — они не настоящие. Настоящее только электричество.
Так и мысли в голове не настоящие. Это несвязной бормотание внутри головы — это только тень от того, что происходит за пределами сознания. В каком-то смысле, сознание и есть то, что мы можем сказать. Чтобы сделать тривиальное действие, например, выделить немного слюны — мы должны очень напрячься, воображая лимон.
И этот же подход мы перенесли на программирование. Чтобы отправлять тривиальные сигналы, мы создали какие-то абстракции, которые нашему сознанию более близки, которые проще вообразить. Мы, условно говоря, мыслим «лимонами», а наше тело и компьютер управляется условным электричеством. И наши ЯПы — тем для нас лучше, чем они ближе к «лимонам». А что они там под капотом делают — дело уже давно десятое. И в принципе, оно хорошо. Если завтра у нас компьютеры будут основаны на других принципах, то нам достаточно будет переписать наши интерпретаторы лимонов в это новое и оно будет как-то там работать. Это тоже контроль. Но другого типа.
1. AN3333
  01.03.2019 12:19
  #19823484
  Электричество тоже не настоящее. Оно течет в ненастоящих кристаллических решетках, которые сделаны из ненастоящих атомов, которые сделаны из ненастоящих электронов и ядер, которые сделаны из ненастоящих кварков, которые…
  1. androidovshchik
    01.03.2019 18:16
    #19825658
    По-моему, все от мало до велика виртуально)
1. OldPrg
  02.03.2019 02:04
  #19827208
  Читаем теорию электромагнитного поля (3-я, завершающая часть электротехники). Это, самое, электричество — оно даже не течет. Это поле. Технология эл.проводов — это древность, но бизнес, как нефть, перегаром которой нас вынуждают дышать.

kireevmp
28.02.2019 17:33
#19819728
+3
А если серьёзно, то проблема построения абстракций над абстракциями (и так до бесконечности) очень-очень серьёзная. Хорошо, если хоть четверть веб-разработчиков знают и понимают, что под капотом у V8, сишарперы — у IL. И как только мы встречаемся с проблемой уровня ниже нашего предела понимания этих абстракций, мы бессильны.
Ещё Азимов в своей книжке "Основание" описал, а Артур Кларк сказал, что любая достаточно развитая технология неотличима от магии. А разве мы можем понять магию? Нет. Не можем. Значит рано или поздно, при появлении таких технологий, мы будем жить в мире компьютерной магии, и ни один человек не будет ей управлять.

А теперь представьте, если магия перестанет работать. Что будет? Полная разруха...
1. braineater
  28.02.2019 17:48
  #19819812
  +2
  Если магия перестанет работать то прилетят Рептилоиды и все починят.
  P.S. Машу табличкой «сарказм». Ссылка на рассказ Гарри Гаррисона.
  1. kireevmp
    28.02.2019 17:52
    #19819840
    +1
    Как жаль, с одной стороны, что нет инопланетян, и никакое НЛО не починит… Но с другой стороны, хорошо, что никто не может нас шантажировать в плане контроля и починки этой "магии".
    
    braineater
    28.02.2019 18:00
    #19819882
    Вы не совсем уловили что я хотел сказать. Я к тому веду что кто-то этим управлять в любом случае должен. Если не инопланетяне то сами люди, те кто эту технологию разработал или их наследники. Чтобы некая технология работала но при этом никто не знал как — нужны весьма специфичные условия. Это в глобальном смысле, само собой.
    
    User2Qwer
    28.02.2019 23:29
    #19821286
    +1
    Вы знаете, вот это вот Всё мне частенько напоминает о книге Герберта Уэллса — Машина времени (посмотрев кино версию этого не ощутить). Хоть я и читал её лет 20 назад. Но иногда сталкиваюсь с тем во что оно может «интерпретироваться» и нахожу параллели. Как бы мне не хотелось чтобы мы не создали случайно эти самые специфичные условия. Гуманитарии там тоже по своему интерпретированы=)) они живут под землей и чинят механизм какой-та, а по ночам выходят и хавают илиту, живущих на поверхности, безвольных
    
    Dr_Faksov
    01.03.2019 04:09
    #19821926
    Вы знаете, мне иногда кажется, что в современном мире достаточно уничтожить 15-20 тысяч человек, чтобы цивилизация встала в своём развитии. Пугает…
    
    braineater
    01.03.2019 04:45
    #19821960
    +2
    Даже если предположить что предположение верно, вы правда не считаете специфичными условиями внезапное уничтожение 15-20 тысяч конкретных людей?
    
    Ark_V
    01.03.2019 12:14
    #19823444
    Да все эти конкретные люди географически в одном месте сосредоточены, к тому ж сейчас отдельные, даже очень образованные и знающие, люди не смогут восстановить технологию если ее утерять, технология на команды и оборудование завязана, уничтожь большую часть команды и оборудования и технологию не восстановить.
    Сколько мест в мире где скажем жесткие диски делают или еще чего там более продвинутого? А если их 1-2 таких мест на весь мир останется, глобализация экономики это же диктует, а потом какой локальный кабздец на это место свалится типа эпидемии или военного конфликта. Т.ч. специфичность условий тут скорее в локализации технологий, а не сами условия, о чем мне думается предыдущий оратор и говорил.
    
    khim
    01.03.2019 20:50
    #19826294
    Сколько мест в мире где скажем жесткие диски делают или еще чего там более продвинутого?
    Жёсткие диски ладно. А вот сканеры для литографии — это штучная работа и всего три фирмы: ASML и Canon и Nikon их делают (вернее практически ASML только делает, Canon/Nikon всё грозятся победить EUV, но пока поставок нет).
    
    User2Qwer
    01.03.2019 20:51
    #19826304
    Вы знаете, мне иногда кажется, что в современном мире достаточно уничтожить 15-20 тысяч человек, чтобы цивилизация встала в своём развитии. Пугает…
    
    американцы вон уже список в санкциях начали заполнять=)) осталось ещё сотню таких составить, и заживём
    
    ariksu
    01.03.2019 10:37
    #19822794
    Вы заблуждаетесь. Локальные технологии могут держаться на маленькой группке людей, глобальные — нет.
    Предположим некоторые рептилоиды с помощью наноботов взяли и уничтожили весь интел и амд. Ну и производственные их мощности заодно и складские запасы, так уж, чтобы наверняка. Что произойдёт?
    Ну экономику поколбасит, да. Цены полезут вверх на железо как на дрожжах, стартапов поуменьшится.
    Но
    1) останутся сотни мелких производителей
    2) Новые процессоры х86 выпустят в течение двух, максимум пяти лет
    3) технологии на фабах откатятся ну скажем на десять лет назад
    4) станут востребованны более быстрые стеки ПО
    
    В целом эффект на прогресс это окажет не очень сильный.
    
    trir
    01.03.2019 10:51
    #19822888
    Так надо не компании уничто жать, а специалистов. Если уничтожить всех разработчкиов и все чертежи, человечество не сможет востановить архетектуру. Максимум через несколько десятелетий сможет создать совместимый аналог
    
    dimm_ddr
    01.03.2019 11:18
    #19823012
    Чтобы уничтожить всех причастных разработчиков нужно уничтожить весьма немаленькое количество людей. Причем конкретных и в совершенно разных географически местах. чтобы при этом еще и все чертежи уничтожить так, чтобы вообще нельзя было восстановить — это нужно уничтожить пол интернета и какое-то количество бумажных распечаток — последнее вообще не представляется возможным. Это что должно произойти чтобы такое в принципе могло случится? Ну и в мире где есть кто-то, для кого такое действие возможно — у нас будут проблемы посерьезнее потери группы инженеров.
    
    trir
    01.03.2019 11:42
    #19823186
    При чём тут интернет? Это ведь комерческая информация — разве эти чертежи есть в открытом доступе? Разве только старые версии
    
    dimm_ddr
    01.03.2019 14:06
    #19824104
    Ну значит нужно уничтожить не интернет, а кроме разработчиков еще и тех, у кого есть доступ к серверам. Ну либо сервера. В любом случае случайно такое событие не произойдет до тепловой смерти вселенной, а если кто-то организует такое специально, то нам вряд ли что-то поможет.
    
    ariksu
    01.03.2019 12:14
    #19823448
    Посмотрите пожалуйста на Dolphin или на RPCS3. Это проекты разрабатываемые горсткой энтузиастов в свободное время без исходных документов. Знания размазаны по культуре и восстанавливаются по поведению образцов, от этого никуда не деться.
    
    Alex_v99
    01.03.2019 12:56
    #19823684
    В этом случае достаточно будет знать, что «такое точно возможно сделать». А значит тысячи энтузиастов ломанутся заполнять внезапно освободившуюся нишу. Человечество заново пробежит вековую историю IT за десятилетие, и кто знает, куда «взлетит» по инерции…
    
    trir
    01.03.2019 13:01
    #19823720
    ключевой момент — за десятилетие
    возмут люди книжки и начнут изучать с азов, через пару лет появится группа специалистов которая будет востанавливать технологию…
    
    Alex_v99
    01.03.2019 13:10
    #19823788
    Ну да десятилетие — вместо столетия. Разумеется это будет откат назад, но недолгий и не фатальный. Кроме того многие вещи просто не станут изобретать заново, грубо говоря вместо LPT изобретут сразу USB.
    
    Ark_V
    01.03.2019 12:24
    #19823524
    1 и 2 сомнительно.
    СССРовсский x86 собственной разработки был или все же в основе интел лежал?
    И сколько мелких производителей имеют культуру разработки и как изделий так и технологий, они уже всем готовым скорее пользуются чем собственное разрабатывают.
    
    khim
    01.03.2019 20:53
    #19826316
    СССРовсский x86 собственной разработки был или все же в основе интел лежал?
    Он был копией — но это было политическое решение. Так же, как и пресловутый Ту-4.
    
    Zenitchik
    01.03.2019 21:31
    #19826434
    Так же, как и пресловутый Ту-4.
    
    Это Вы зря. Эта машина — самый настоящий реверс-инжиниринг.
    
    khim
    01.03.2019 22:12
    #19826592
    Ровно как в случае с К1810ВМ86. Поступил заказ на создание копии — и копию сделали.
    
    Из чего не следует, что ничего своего создать не могут. В конце-концов и Ан-225 и E2K существуют и точно не являются копиями западных аналогов.
    
    OldPrg
    02.03.2019 02:15
    #19827226
    Да, все компы мы копировали. Так быстрее врага догонять с меньшими затратами. На заводе Кварц слой за слоем снимали с западных микросхем и потом делали свои побольше, и с 6 ручками, чтобы переносить (юмор такой был тогда).
  1. avvor
    28.02.2019 21:50
    #19820934
    +2
    Прилетят ретролойды, достанут спектрумы, ассемблеры и т.п. и все починят)
    
    lonesimba
    01.03.2019 00:47
    #19821544
    Джон Тайтор? IBM 5100?
1. dss_kalika
  28.02.2019 19:29
  #19820380
  +1
  Будут люди, которые её будут понимать. Только их будет не так уж много…
  Кто то же эту «магию» должен поддерживать на всех уровнях )
  
  Просто это будет совсем другой уровень. Сейчас уже есть неплохой разрыв между теми кто пишет ядро технологии и тех, кто ими пользуется ) Со временем он просто будет расти или количество слоёв будет увеличиваться.
  1. kireevmp
    28.02.2019 20:29
    #19820628
    Да, разрыв будет увеличиваться. И да, будут люди, поддерживающие всё это. Но рано или поздно это кончится. Либо это будет как в "Матрице", когда машины вытеснили людей и заставляют их жить по своим правилам, либо это будет, как тот случай с криптовалютной биржей и холодным кошельком, владелец которого умер.
    Это всё к чему. Если (ну вдруг) происходит форс-мажор и людей-"богов" (продолжая образ магии = технологии), которые держали всё на своих двоих, не станет, то мы приедем в тупик цивилизации. Как только мы забудем, если отвлечься от темы технологий, рецепт Кока-Колы, которую знают единицы, то мы никогда не сможем её воспроизвести, лишь пользоваться уже настроенным оборудованием, пока его не придется заменить и забыть программу производства. Так и здесь, не стань пары ключевых людей в Intel, и архитектура процессора для нас — тайна. Тайна, правду о которой мы никогда не узнаем.
    
    reki
    28.02.2019 21:23
    #19820824
    То, что для многих «магия», для кого-то просто рутина. Если бы бизнес Intel был так завязан на знания пары людей, то она не протянула бы столько времени. Чтобы защититься от Bus factor люди давно уже применяют разные штуки типа управления знаниями.
    
    dimm_ddr
    28.02.2019 22:55
    #19821174
    Но рано или поздно это кончится.
    Совсем не факт. Помимо людей, которые сейчас эту магию умеют есть масса учебных курсов. Из-за роста количества людей которым эту магию нужно чинить — людей владеющих магией тоже становится больше (количественно, не в процентах). Как они могут все внезапно куда-то деться, да еще и всю литературу по теме прихватить — непонятно совершенно. Разве что апокалипсис случится, но там проблемы побольше будут чем непонимание что там под капотом у V8.
    
    inkelyad
    28.02.2019 23:41
    #19821358
    +1
    Апокалипсиса не надо. Оно встречается постоянно.
    
    Делается некая система, в нее вкладываются квалификация, знания и умения людей — чтобы делала все это за них. Потом люди уходят, оказавшись ненужными или потеряв интерес.
    
    И через несколько лет имеем черный ящик, про который не только никто не знает, как он работает, но и никто не знает, что именно от ящика ожидается. Т.е. когда на постукивание в левом верхнем углу ящик выплевывает комок зеленых соплей — никто не может сказать, «это так и задумано и сделано для того-то и того-то крайнего случая», или «ящик сломался».
    
    Ну хорошо, про «так и задумано» иногда сказать можно — на этот счет тест есть. А вот для чего оно так — это задокументировать забыли. Тут вот чуть выше про управление знаниями вспомнили. Но речь как раз про то и идет, что на самом деле этого самого управления практически никогда нет.
    
    dimm_ddr
    01.03.2019 11:23
    #19823050
    Апокалипсиса не надо. Оно встречается постоянно
    И что — постоянно случаются катастрофы? Вроде бы нет, человечество как жило так и живет. Я к тому, что либо то, что вы описываете — апокалипсис и его скорее всего не случится, либо это достаточно незначительные события не играющие большой роли. Зависит от того, какой смысл вы вкладываете в слово «это».
    Ну забросили в какой-то компании самодельную систему, ну и что? Да, компания что-то теряет из-за невозможности модификации и вынуждена будет потратить сколько-то денег на либо переделывание, либо покупку готового. Но это штатная ситуация, ничего страшного не произошло. Да, какие-то более глобальные решения забрасываются и есть люди которые остаются с магией. Но и это не происходит в один день и без появления альтернатив зачастую. Популярное решение не умрет если пропадет единственный его разработчик, потому что он не будет единственным. Ну а в таком случае те, кто остался на умершей системе в общем-то сами виноваты, могли бы и озаботится миграцией на что-то живое.
    
    User2Qwer
    01.03.2019 21:24
    #19826412
    И через несколько лет имеем черный ящик, про который не только никто не знает, как он работает, но и никто не знает, что именно от ящика ожидается. Т.е. когда на постукивание в левом верхнем углу ящик выплевывает комок зеленых соплей — никто не может сказать, «это так и задумано и сделано для того-то и того-то крайнего случая», или «ящик сломался».
    
    Это вы сейчас прям точно в саму природу человека и попали. Сколько тайн хранит не изученный потенциал человеческого мозга. Сколько интересных исследований я вчера почитал по раздвоению личности, после просмотра фильма «стекло». А не потеряли ли мы инструкцию к самим себе. И не это ли хотели нам сказать все предыдущие пророки. Но в силу скудности ума, мы так и не научились читать и слушать. И каждый народ интерпретировал или перевёл это на свой лад.
    
    Barbaresk
    02.03.2019 11:25
    #19828028
    Так если ТЗ было создать ящик, который при постукивании выдавал кучку зеленых соплей, может и не нужно его сопровождать? Работает и не трогает, что-то сбилось — перезагрузи. Всегда есть системы, которые просто работают и всех это усраивает, ничего менять не надо, допиливать тоже. Да, если нужно будет поменять цвет соплей на синий, наверно, начнутся проблемы и проще будем написать заново. Но ведь скорее всего не понадобится.
    
    inkelyad
    02.03.2019 19:19
    #19829114
    Сопровождать нужно. Потому что 'работает и не трогай' не очень-то работает, так как внешние условия меняются. И если они поменялись после того, как мы забыли почему ящик что-то делает — то мы не можем даже сказать, нужно ли его выкидывать, или еще можно использовать. И что еще сломается, если мы его все же выкинем. Это как в известном примере с ракетой. Алгоритм перетащили на новую модель, забыв проверить его применимость, в нем произошло переполнение — ой, ракеты больше нет.
    
    Dr_Faksov
    01.03.2019 04:40
    #19821954
    Не соглашусь с вами. Проблема есть уже сейчас. Есть такая вещь как утеря технологического наследия. Если коротко — сейчас НЕВОЗМОЖНО воспроизвести многие вещи произведённые 20-40 лет назад.
    Вы скажете — а зачем это надо? Ну, к примеру, возобновление производства оружейного плутония. Там всё задокументированно и понятно, для химика, получившего образование в 40-х годах прошлого века. У современного специалиста, фраза " довести концентрацию вещества до 7" вызовет немой вопрос в глазах. Потому что кардинально поменялись методы анализа веществ.
    Или совсем простой пример, лет 10 назад надо было слегка модернизировать крупный нефтеперерабатывающий завод в США. Есть некая документация, живы люди, которые её разрабатывали, и методы перегонки вроде не поменялись, вот только реальная схема завода СОВСЕМ не соответствует чертежам. И зачем так было сделано — никто не помнит. Причём видно, что сначала делали по чертежам, а потом переделывали. Результат — небольшая модернизация вылилась в полную перестройку, «с нуля».
    Так что это дело не будущего, а настоящего. Мы уже не понимаем что, и почему именно так, делали наши родители.
    И управление знаниями не панацея. Бумажная документация — считайте что её нет. Как показывает опыт, она не полная и перепутана. Да и выкидывают её с большим удовольствием. Особенно при банкротстве\ поглощении. Найти что либо в бумажных архивах можно при большой доле везения. Как с нефтеперегонным заводом. Понятно что была документация на все переделки. Вполне вероятно что она даже сохранилась. Вот только ГДЕ?
    
    ariksu
    01.03.2019 10:41
    #19822830
    Вы путаете локальную технологию и глобальную. Вот тот же нефтезавод — он один. Был бы их хотя бы десяток по миру — с документацией было бы гораздо легче и лучше.
    
    dimm_ddr
    01.03.2019 11:26
    #19823068
    Я все еще не понимаю зачем воспроизводить именно прикладные технологии 20-40 летней давности. Они умерли потому что есть что-то более современное, что пришло им на замену. Если где-то решили не модернизироваться и дотянули до момента когда модернизация невозможна, но необходима — ну сами виноваты. В чем трагедия то? Человечество не пострадало, даже на уровне отдельного государства такие случаи редко заметны.
    
    Так что это дело не будущего, а настоящего. Мы уже не понимаем что, и почему именно так, делали наши родители.
    Так а нам и не надо. Частный случай провала планирования не в счет — это провал планирования модернизации, а не необходимость восстановления никому больше не нужных тех процессов.
    
    Dr_Faksov
    03.03.2019 07:07
    #19830114
    Зайдем с другого края. Американская лунная программа состоялась (или нет) благодоря УНИКАЛЬНОМУ ракетному двигателю ( уникальный по соотношению тяга\собственный вес, там 100 тонн тяги на ОДНУ КАМЕРУ вроде было). Такого двигателя ни у кого не было и сейчас нет ни у кого в мире, включая сами США. Несколько лет назад США пытались снова сделать похожий двигатель, но упёрлись, как и все остальные в пульсации пламени и нестабильность факела.
    И возникает вопрос — если двигатель С ТАКИМИ ПАРАМЕТРАМИ был (сам двигатель в музее стоит) то почему его не использовали потом и не могут воссоздать сейчас?
    
    sshikov
    03.03.2019 15:20
    #19830934
    Ну, его с переменным успехом пытаются. Думаю вы читали, раз интересуетесь, скажем вот это.
    
    User2Qwer
    01.03.2019 21:31
    #19826438
    Ну, к примеру, возобновление производства оружейного плутония.
    
    это вы сейчас так хитро тендер в хабр впихнули? или кто та там на верху забыл как плутоний обогащать=)) headhunter не
    
    Dr_Faksov
    03.03.2019 07:18
    #19830120
    Не забыли, все записано. Вопрос только — понять. Если вы определяли концентрацию чего-то титрованием при помощи реактива К-1228, то в документации у вас, для быстроты, записана концентрация по этому реактиву. И это нормально, потому что реактива на складе стоит бочка, а если кончится, то позвоним в фирму «Кемикал систерс» и они еще бочку привезут. Вот только склада уже лет 50 нет. А фирма обанкротилась и архивы бесследно исчезли. И как готовить реактив К-1228 никто не знает.
    
    Это образно говоря. Но вполне возможно наткнутся на измерения уникальными приборами, с записью результатов в единицах шкал этих приборов. Или реакции которые тогда шли, а сейчас не идут, потому что степень очистки вещества поменялась, а примеси работали как катализаторы.
    
    trir
    01.03.2019 07:30
    #19822096
    В одном городе, в 2000-ом, один человек сделал web-gis на MapGuide, а потом эмигрировал. Через 15 лет ко мне обратились люди которых просили это модернизировать, они не понимали как это устроенно. Сайт за это время, пережил несколько перездов и продолжал работать — при том, что никто не понимал как…
    
    User2Qwer
    01.03.2019 21:51
    #19826516
    та ладно вам, вон выше у кремлеботов химик ядерщик кажется в праотцам эмигрировал=) гугл на запрост о смерти ядерщика подсказывает Владимир Дмитриевич Фёдоров (5 сентября 1930 — 3 июня 2017). У китайских соседей тоже кажется беда. В Пекине 16 января в возрасте 93 лет скончался известный физик-ядерщик, изобретатель китайской водородной бомбы Юй Минь. Как известно, водородная бомба в Китае была создана в 1966 году. При этом Юй Минь смог решить ряд ключевых проблем при ее разработке, за что в дальнейшем его прозвали отцом китайского аналога этого вида оружия массового поражения. К тому же, ученый считается единственным авторитетным китайским специалистом-ядерщиком, который никогда не учился за границей.
    
    anprs
    01.03.2019 08:40
    #19822246
    Рецепт булата и дамасской стали был в своё время утерян. И что?
1. cubit
  28.02.2019 19:48
  #19820452
  Не согласен с пониманием магии(видимо это уже занудство, но все же). Почему не можем понять магию? Есть вещи, которые когда-то были просто волшебством — фантастикой в чьих-то воображениях и мечтах, например, смартфон, сто лет назад это было бы воспринято чистым волшебством(у некоторых людей, не думаю что у всех), телевизор тоже самое. Да я знаю суть на самом деле не в этом и я вообще свернул куда-то в другие дебри. Тем не менее для строгости ради высказался. Магия относительна. Относительна времени и культуры.
  1. kireevmp
    28.02.2019 20:21
    #19820584
    Здесь понимание магии как таковой не в том, что она для кого-то — фантастика, а для кого-то — реальность, а в том, что никто её не может объяснить толком. Вот лично я, разбираясь в достаточно простой (на первый взгляд) технологии — техниках рендеринга 3д игр, увяз в тоннах деталей, потонул как раз в той самой "магии" не потому, что это эпоха такая, или я плохой, а потому лишь, что тысячи последовательно возникавших идей создали многоуровневую сложность, пониманием (имею ввиду виду простоту и лёгкость осознания, Simple is better than complex — Python Zen) которой часто жертвуют ради других целей: эффективности, красочности и так далее.
    Всё это приводит к тому, что если раньше, будучи энтузиастом, можно было легко покорять геймдев с минимальными знаниями, то сейчас есть шанс вообще не постигнуть этот дар богов.
    
    dimm_ddr
    28.02.2019 22:57
    #19821186
    Вы просто пытаетесь охватить больше чем нужно. Все эти слои абстракции как раз и создавались чтобы не было необходимости понимать все от самого верха до самого низа.
    
    MacIn
    01.03.2019 00:52
    #19821564
    … разделение труда — основа прогресса.
    
    dimm_ddr
    01.03.2019 11:27
    #19823076
    Ну собственно именно об этом я и говорю, да. Вроде бы принципу тысячи лет, буквально, но все равно находятся люди которые его не понимают.
    
    User2Qwer
    01.03.2019 22:19
    #19826618
    Здесь понимание магии как таковой не в том, что она для кого-то — фантастика, а для кого-то — реальность, а в том, что никто её не может объяснить толком. Вот лично я, разбираясь в достаточно простой (на первый взгляд) технологии — техниках рендеринга 3д игр, увяз в тоннах деталей, потонул как раз в той самой «магии» не потому, что это эпоха такая, или я плохой, а потому лишь, что тысячи последовательно возникавших идей создали многоуровневую сложность, пониманием (имею ввиду виду простоту и лёгкость осознания, Simple is better than complex — Python Zen) которой часто жертвуют ради других целей: эффективности, красочности и так далее.
    Всё это приводит к тому, что если раньше, будучи энтузиастом, можно было легко покорять геймдев с минимальными знаниями, то сейчас есть шанс вообще не постигнуть этот дар богов.
    С магией точно так же. Просто многое утрачено. инквизиций, церкви. Сколько литературы созжено. Люди боятся того что не понимают.
    Техпроцесс основан на самопознаний, на силе разума и чем та там еще. Типа человек может контроливать на атомном уровне силой мысли.
1. justboris
  01.03.2019 11:51
  #19823260
  если хоть четверть веб-разработчиков знают и понимают, что под капотом у V8
  Если много знать о внутренностях V8, то и код получится заточенный под Google Chrome, а пользователи Firefox расстроятся. Поэтому лучше опираться на стандарт языка, а не на конкретную реализацию.

IgorKh
28.02.2019 17:39
#19819756
Прямо сейчас вы можете позвонить мебельщику, сказать:«сделай мне тумбочку» и получить завтра «что-то», этот результат определенно будет тумбочкой.
Но можете немного вникнуть в детали, и сказать:«мне нужна тумбочка размерами x-y-z», что уже лучше.
Можете еще глубже погрузиться в детали, описать цвет, текстуру, материалы, фурнитуру, способ установки, разбивку внутреннего пространства и даже способы скрепления отдельных частей дуг с другом.

Что я вообще хотел сказать, вы прямо сейчас можете сказать «сделай тумбочку», решает ли это проблему и нужны ли еще люди разбирающиеся в деталях?
1. amarao
  28.02.2019 18:18
  #19819980
  Вам невероятно повезло, что вы знаете слово «тумбочка» и мебельщик тоже знает слово «тумбочка» и вы друг друга понимаете.
  
  А тут вы идёте к мебельщику и начинается: нам нужно чтобы та штука, которая делает штуки, когда выполняет делание штуки делала другое делание делания штуки, которая штуку делает, а потом у неё есть функция контейнирования и она реаллоцируема.
  1. gleb_kudr
    01.03.2019 02:08
    #19821788
    +1
    Во во. В слове "тумбочка" на самом деле скрыт десяток лет воспитания и взросления человека, причем в определенном обществе. Ибо ваша тумбочка и тумбочка соседа таки может очень сильно отличаться :)
    В данном случае само слово это всего лишь указатель на место объекта в памяти. А сам объект это дикая абстракция над абстракцией. И все еще неизвестно, где же в нашей голове предел сложности и финальные элементы декомпозиции "тумбочки".
    
    Skerrigan
    01.03.2019 06:03
    #19822022
    Рискну вынести мысль-продолжение. Тумбочка говорите?
    Ок: тумбочка->спальня/гостиная/кабинет->комната->помещение->дом/завод/соц.объект->сооружение
    И таки да, при задаче «нам надо спроектировать сооружение» — вероятность учета уместности тумбочки будет под вопросом.
    Однако когда стоит задача "комната" — уже можно дать условные 90%, что все будет совместимо с любой условной тумбочкой.
    
    Чем больше слоев абстракций, тем больше неопределенность в структуре нижних слоев.
    Однако человечество справляется. По крайней мере на текущий момент.
    
    UPD: Вспоминаю Sims — там как раз можно «пилить модулями-комнатами» (с тумбочками разумеется).
    
    UPD №2: Смотрю на свою платформу для тестирования — у неё, как и любого сложного продукта есть много слоев абстракций.
    На верхнем я просто пишу (утрирую конечно):
    — система, вкл.
    — система, авторизация
    — система, проверить компонент Z
    — система, проверить компонент F
    — система, проверить компонент H
    — система, выкл
    Но под капотом,… разнокалиберные сервисы, динамическая балансировка нагрузки, автоматическое выявление неполадок (ага, тулл для тестирования сам себя тоже проверяет), их устранение (узкий спектр, но тем не менее), гибкое конфигурирование (частично на лету, самостоятельное). Система за собой даже тестовую среду может подчистить (убирать за собой, для возможности протестировать «продакшн»).
    Т.е. в недрах крутится просто адская сущность, в которой без бутылки порой и не разберешься — блок-схемы в компе (или на бумаге) обязательны для возможности удержать в голове общую структуру.
    Но это весьма надежная молотилка.
    
    И все это управляет еще одним набором пластов абстракций, заключенных в webDriver.
1. trir
  01.03.2019 07:34
  #19822106
  Люди говорят — «сделай карту» и не могут объяснить, что они хотят…

flancer
28.02.2019 17:47
#19819806
+3
выбрал PHP — слил жизнь в унитаз. Выбрал Go — стал тупицей.
Выбрал .net — не спишь по ночам, пытаясь восстановить связь с реальностью.

Шутка. Интересная публикация (y)
1. ledocool
  01.03.2019 07:03
  #19822070
  А я php не выбирал. Он выбрал меня :(
  1. Cerberuser
    01.03.2019 09:18
    #19822338
    Он захотел Вас убить?
    
    AntonSor
    01.03.2019 12:36
    #19823580
    нет, поглотить и растворить в себе во славу Расмуса Лердорфа

DrunkBear
28.02.2019 18:00
#19819880
Кому нужен много контроля и низкий уровень — пишут на С.
Кому нужен максимальный контроль — на asm.
Единственная полу-успешная попытка явно перестать отвечать за код умерла с архитектурой Intanium :)
А абстракции… То, что делают команды людей слишком сложно, чтоб обходиться без них — попробуйте себе представить, что происходит в каком-нибудь современном лайнере целиком или хотя бы в процессоре — в деталях и без абстракций?
1. amarao
  28.02.2019 18:19
  #19819992
  +1
  А в каком месте у вас в Си есть контроль? Есть жалкая иллюзия, что может быть, то, что вы написали — не undefined behaviour. Потому что если это UB — то компилятор пишет за вас. Что-то.
  1. Whuthering
    28.02.2019 18:43
    #19820142
    Это с включенной оптимизацией.
    Можете выключить оптимизации, и тогда UB будет основываться исключительно на особенностях архитектуры, под которую мы компилируемся. Точно так же, как при разработке на языке ассемблера или в машинных кодах.
    
    amarao
    28.02.2019 20:37
    #19820654
    +2
    Это не отменяет иллюзии, точнее того, как больно она рассыпается.
    
    keydon2
    28.02.2019 21:31
    #19820862
    +5
    Только машинные команды тоже жонглируются внутри процессора.
    Выполнение 8086 команд это тоже абстракция с целью совместимости.
    Даже на си и асме мы не знаем что же там внутри творится. Исключая разве некоторых непосредственных работников амд и интела
    
    DrunkBear
    01.03.2019 09:49
    #19822508
    … да и они знают только часть общей картины.
    
    DarkTiger
    01.03.2019 22:59
    #19826712
    FPGA -> процессор со своим набором команд, никаких сторонних ISA. Никаких кэшей. Никакого спекулятивного исполнения или суперскаляра. VLIW — это все, что мы можем позволить для ускорения. Ладно, еще во входном буфере храним считанные данные, ибо принципы временной и пространственной локальности все же ускоряют работу, не нарушая детерминированность. Хотя нет, он неизменно (низменно) выродится в кэш при попытках ускориться, поскольку дальше разрастется и пойдут стратегии вытеснения данных из него — на фиг такие искушения, давим в зародыше.
    А теперь начинаем ме-е-едленно подниматься наверх. Свой ассемблер. Свой компилятор, который переставляет команды для оптимизации загрузки функциональных устройство стрррого по заданному алгоритму. Линукс порт. Busybox. Едва-едва дышащие (на тысячедолларовой FPGA) vi и mc. Текстовый браузер. И запоздалое понимание: на кой черт я безвозвратно потратил десять лет жизни — чтобы убедиться в том, что я точно понимаю, что под капотом?
    
    JerleShannara
    01.03.2019 05:37
    #19822008
    А потом пришли микрокоды и команда add вполне себе могла перестать быть передачей двух операндов на сумматор… Если же посмотреть на что-то из AVX2 инструкций, то тут уже становится совершенно непонятным, как оно работает на уровне RTL, и тем более ниже, на уровне транзисторов.
    
    ariksu
    01.03.2019 10:46
    #19822854
    А зачем это «как»? Есть спецификация, вы при желании сами можете построить по ней чип на HDL. Да, возможно вам понадобится десяток человеко-лет на особенно сложные, и работать они будут небыстро, но ведь будут.
    
    humbug
    01.03.2019 21:12
    #19826374
    +1
    Откуда вы такие беретесь? В Стандарте нет ни слова про debug/release, UB есть UB.
  1. DrunkBear
    28.02.2019 19:16
    #19820322
    +1
    Это смотря с какой точки зрения смотреть: с точки зрения asm — да, иллюзия контроля, а с точки зрения аналитика больших данных, который пишет код на Scala, который выполняется на Spark, который получает виртуальные контейнеры от YARN (при этом каждый процесс на своей JVM), взаимодействует с Hadoop и работает с виртуальной памятью и не менее виртуальными ядрами через вызовы к ОС — у вас дикая уймища контроля!
    PS только сейчас подумал, что Глушковская ОГАС сейчас занимает 1 серверную стойку и стоит в каждом приличном банке, как минимум — 1.
  1. Groramar
    28.02.2019 22:29
    #19821070
    +3
    Delphi в помощь, там UB нет.
1. atrosinenko
  01.03.2019 12:33
  #19823566
  Кому нужен много контроля и низкий уровень — пишут на С.
  Кому нужен максимальный контроль — на asm.
  <сарказм>… а кому нужно ещё больше контроля, пишут на Scala.</сарказм> Я, конечно, понимаю, что это просто DSL, но забавно всё-таки, что функциональный язык оказался в чём-то ближе к железу, чем asm (да, я знаю, что можно "писать процессоры" хоть на Python).
1. arcman
  01.03.2019 12:58
  #19823696
  Какой может быть контроль, если ты думаешь что вот у тебя адрес в памяти, а по факту эта страница на диске сейчас хранится?
  Или думаешь что команды выполняются в таком порядке, а на самом деле процессор выполнил их в другом.
  Или думаешь что загрузил данные в конкретный регистр, а их там целый пул.
  Уже давно asm это просто внешний интерфейс.
1. YetAnotherSlava
  01.03.2019 16:01
  #19824902
  Кому нужно много контроля — пишут на Ada и прочих Модулах.

SirEdvin
28.02.2019 18:03
#19819896
И чем абстрактнее становится язык, тем сильнее из твоего мышления вымывается его реальное назначение — контролировать электричество в железе. Все эти картинки у тебя на мониторе, циферки, библиотеки, анимации — они не настоящие. Настоящее только электричество. Только железо. Я не готов потерять над ним контроль.
Можно подумать у вас когда-то был этот контроль. Мне кажется, случай со specte должен был отлично показать, что вы не контролируете железо.
1. DrunkBear
  28.02.2019 18:05
  #19819910
  +2
  Был. В 50х, когда писали программы машинными словами ( производительность — 3-4 машслова в день) и в любой момент могли по индикаторам посмотреть состояние регистров.
  1. amarao
    28.02.2019 18:21
    #19820000
    Ну, не до такой степени же. Талантливый инженер мог за день написать целую программу, которая была способна что-то посчитать.
    
    … До индикаторов был осцилограф, который точечками биты показывал.
    www.youtube.com/watch?v=nc2q4OOK6K8
  1. SirEdvin
    28.02.2019 18:22
    #19820002
    В 50х еще даже мои родители не родились. Я боюсь, что автор поста, скорее всего, тоже.
    
    ezus
    28.02.2019 18:53
    #19820206
    +1
    От чего же?
    Я тоже из того времени и начинал писать на Урал-1, где все переменные должны были быть от -1 до 1, а в системе команд не было циклов и переходов с возвратом(вызов подпрограмм). Пришлось пройти весь путь от машинных команд через Алгамс, Кобол, PL/1, C, C++, Java к C#, WPF со множественными ответвлениями в разные стороны.
    И ЯП не главное. Кроме языков есть методологии и технологии: модульность, структурное программирование, HIPO, Варнье, Джексон, ООП и др.
    Пройденный путь помогает понять — почему и куда движется программирование.
    
    perfect_genius
    01.03.2019 12:15
    #19823456
    О, и куда же придём, как думаете?
    
    0xd34df00d
    01.03.2019 17:53
    #19825516
    Не во всех языках применимо структурное программирование и ООП. А в каких-то языках с модульностью всё очень плохо, и поэтому в классы начинают запихивать всё для реализации модульности, скажем. Френды там всякие, вот это всё.
    
    sshikov
    28.02.2019 19:27
    #19820364
    Я начинал в 1975. Алгол-60. Примерно в середине 80-х состояние регистров ЕС-1061 — вполне мог, и посмотреть, и останов поставить, в общем — отладка с пульта в полный рост, хотя писал уже по большей части на REXX, который был весьма высокого уровня язык даже по сегодняшним меркам.
    
    3-4 слова в день — конечно перебор.
    
    DrunkBear
    01.03.2019 10:20
    #19822702
    50. Алгол — только в мечтах.
    Есть БЭСМ -1, у которого всего ничего памяти, поэтому — программирование в машинных словах:
    
    Вот он, полный контроль
    Система команд: трёх-адресная. Количество разрядов для кода команды — 39. Код операции — 6 разрядов; коды адресов — 3 указателя по 11 разрядов каждый, что позволяло адресовать 2048 ячеек памяти для операндов и результата. Регистры общего назначения отсутствуют.В систему команд машины входят 9 арифметических операций, 8 операций передач кодов, 6 логических операций, 9 операций управления. Машина имеет общее поле памяти для команд и чисел (Архитектура фон Неймана) — 2047 39-разрядных ячеек (ячейка с номером 0 всегда возвращает машинный нуль). Специальный бит в поле кода команд позволял отключить нормализацию с плавающей точкой и выполнять адресную арифметику. При написании программ для БЭСМ-1 широко применялась техника само-модифицирующегося кода, когда напрямую модифицировалась адресные части команд для доступа к массивам.
  1. xitt
    28.02.2019 21:54
    #19820946
    +1
    В конце 80х пришлось программировать точно так же, поднимать стек с ноля. Производительность была намного больше 3-4 слов в день. Вы каких-то страшилок начитались. Пишешь на ассемблере, вручную транслируешь в адресное пространство, вручную набираешь с бумажки в консоль (да, кнопочками). В день можно 300-500 комманд написать. Не каждый день конечно, а один день, потому что хватает написать только ввод-вывод с перфы например, а потом уже набор идет быстрее, а там и монитор, и магнитная лента, и интерпретатор, и ассемблер.
  1. Alek_roebuck
    28.02.2019 23:24
    #19821268
    В принципе, с этими временами можно и сейчас столкнуться. Например, на военной кафедре в 2000-х годах я, так сказать, программировал на машинах, гораздо менее абстрактных, чем те, на которых программировала моя бабушка в 1970. У неё уже были Алгол, Фортран и какой-то советский аналог ПЛ/1, ввод осуществлялся удобными перфокартами, вывод тоже печатался на бумаге. Мы же двадцать пять лет спустя вводили данные тумблерами по 1-2 команды, вывод шёл лампочками-индикаторами. Настоятельно рекомендовалось, помимо машинных команд, разбираться и в микрооперациях.
    
    APLe
    01.03.2019 04:16
    #19821930
    Ой. А расскажите, что за машина, пожалуйста! Если не секрет.
    
    Alek_roebuck
    01.03.2019 05:23
    #19822004
    ЦВК 5э26
    
    APLe
    02.03.2019 19:21
    #19829120
    Ого, то есть оно ещё десять лет назад в строю было?
  1. Mladolaborant
    01.03.2019 02:34
    #19821828
    Совершенно спокойно в своё время на лабах писались программы на сях, которые не менее спокойно руками транслировались в ассемблер, а из него — в те самые машкоды.
    Которые да, руками забивались в машинку с 486 процессором и затем успешно исполнялись.
    И полный цикл разработки-внедрения какого-нибудь метода Сименса занимал две сдвоенные пары.
    А вот дебаг, это да, страшно было.
    
    arcman
    01.03.2019 13:12
    #19823796
    Вот только в 486 машкоды уже не соответсвовали тому что внутри процессора происходит, внутри работа уже шла в микро операциях.
    
    khim
    01.03.2019 21:34
    #19826456
    +1
    Не надо только пугать народ, а? ?opsы — это Pentium Pro. Даже Pentium напрямую все инструкции исполнял…

old_bear
28.02.2019 18:14
#19819960
-1
«Вавилон 17» вспомнился мне.

выбрал PHP — слил жизнь в унитаз. Выбрал Go — стал тупицей

Доктор, а если я выбрал HDL, я ещё не совсем безнадёжен?
1. JerleShannara
  01.03.2019 05:40
  #19822012
  Пока вы не включили в свой проект софт-ядро какого-нить ARM/MIPS — нет, ещё не безнадежны =)

shaukote
28.02.2019 18:15
#19819968
+3
На мой взгляд, автор сгущает краски.

1. Потеря контроля из-за делегирования и абстрагирования — основа человеческой цивилизации. Думаете, проектировщик корпуса нового спортивного автомобиля понимает, как работает его двигатель? Или всю глубину математического аппарата под моделированием аэродинамических характеристик? Думаете, врач знает, как работает МРТ, на основе которого он ставит диагнозы, определяющие чью-то жизнь? Мы все миримся с этим, потому что другого способа реализовывать сложные вещи и процессы у нас нет.

2. Увеличение толщины слоя абстракций в ЯП, как мне кажется, сильно преувеличено. Да поправят меня люди, чей опыт побольше моего и исчисляется десятилетиями, но по моим ощущениям за последние пару-тройку десятков лет толщина этого самого слоя не так чтобы особо выросла. Языки стали более зрелыми, да, инструменты стали более мощными. Но концептуально изменилось немного. Изучая устройство V8 я часто обнаруживал, что многие его ключевые фичи изобретены в 60-x – 80-x авторами какого-нибудь Lisp или Self. Выше упомянули Spectre — так и спекулятивному выполнению уже лет 30 как.

Но финальная идея, что язык значительно определяет сознание верная. Выход на мой взгляд простой — стараться изучать концепции, а не языки, смотреть шире. Тогда ставка на «неправильный» язык не будет критична.
1. SirEdvin
  28.02.2019 18:28
  #19820040
  Увеличение толщины слоя абстракций в ЯП, как мне кажется, сильно преувеличено. Да поправят меня люди, чей опыт побольше моего и исчисляется десятилетиями, но по моим ощущениям за последние пару-тройку десятков лет толщина этого самого слоя не так чтобы особо выросла. Языки стали более зрелыми, да, инструменты стали более мощными. Но концептуально изменилось немного. Изучая устройство V8 я часто обнаруживал, что многие его ключевые фичи изобретены в 60-x – 80-x авторами какого-нибудь Lisp или Self. Выше упомянули Spectre — так и спекулятивному выполнению уже лет 30 как.
  
  Самая большая победа, кмк, это реальная независимость от железа. Истории из 80-х полны рассказов о том, что как программы работали только на определенных видах процов, дисков, памяти и так далее. На данный момент банальное веб-приложение на python запускается почти везде.
  1. shaukote
    28.02.2019 18:40
    #19820134
    +2
    Самая большая победа, кмк, это реальная независимость от железа. Истории из 80-х полны рассказов о том, что как программы работали только на определенных видах процов, дисков, памяти и так далее. На данный момент банальное веб-приложение на python запускается почти везде.
    Полностью согласен. Но не думаю, что это вопрос того, что тупо наклепали абстракций. Просто инструменты стали совершеннее.
    
    Даже древнебородатый (не в обиду) C++ сегодня достаточно неплохо переносится между платформами. Понятно, что с перекомпиляцией; понятно, что нужно учитывать ряд ограничений (иначе и никак). Но тем не менее вы вполне можете писать кросс-платформенный код на С++ — имея при этом те самые «zero-cost abstractions».
    
    Whuthering
    28.02.2019 19:13
    #19820308
    +1
    Учитывая, что отцом C++ был C, который изначально проектировался как раз ради приемлемой переносимости между архитектурами, то не вижу ничего удивительного :)
    
    shaukote
    28.02.2019 19:27
    #19820368
    +1
    Ага. Я просто это к тому, что для достижения независимости от железа не так чтобы особо сильно были нужны всякие Python и JS.
    
    indestructable
    28.02.2019 20:54
    #19820726
    +2
    Так с++ собирается под разные платформы, а пайтон и джаваскрипт запускаются на разных платформах.
    
    lonesimba
    01.03.2019 00:53
    #19821570
    +1
    так пайтон и жаваскрипт — интерпретируемые, а интерпретаторы на том же c\c++ и написаны, не?
    
    arcman
    01.03.2019 13:17
    #19823816
    вот только платформ на которых можно запустить python/js в разы меньше.
    вот такая вот «кросс-платформенность»…
    
    khim
    01.03.2019 21:40
    #19826478
    А это как раз принципиальная разница в подходах. C/C++ не скрывают от вас железо. Она запрещают вам использовать некоторые конструкции (те, которые непереносимы). То есть поддержка переносимости программ возлагается на программиста.
    
    А вот C#/Java (в меньшей степени Python/JS) — как раз ради этого и созданы: вам не нужно думать на каком CPU ваша программа запускается — если она работает у вас на десктопе, то и на телефоне запустится… разумеется такой подход ограничивается количество доступных платформ гораздо сильнее: вы не можете (как в C/C++) сказать «если ваша платформа это умеет — то и отлично, а если нет — то ошибка компиляции» и потом обложить это место #ifdef'ами. Вам нужно выбрать некоторое множество фич и обеспечить их работу на всех платформах…
  1. sentyaev
    01.03.2019 02:57
    #19821854
    -1
    Самая большая победа, кмк, это реальная независимость от железа.
    
    С одной стороны это выглядит как победа, это да, т.к. решать проблемы на стороне софта дешевле, соответственно прогресс идет быстрее.
    С другой стороны в тот момент когда мы начали абстрагироваться от железа мы начали костылить, и теперь не можем остановится.
    
    У нас есть операционные системы которые абстрагируют нас от железа, они предоставляют некий слой API для работы с ним как с некими абстрактными сущностями.
    Соответственно программы не зависят от железа.
    
    Но этого стало не хватать, поэтому создали штуки типа JVM, .NET, Python которые абстрагируют нас от операционной системы. Теперь мы можем писать программы и не зависеть от операционной системы, но это больше для серверсайда.
    Для фронта верхом абстракции в наше время является браузер, который является по сути операционной системой сам по себе, там и UI однотипно рисуется, и набор API есть, и виртуальная машина, а с появлением WebAssembly действительно надобность в ОС отпадет.
    
    Я это все к тому, что вместо стандартизации, мы продолжаем решать проблему не на той стороне, добавляя ненужные абстракции.
    Но, возможно, это нормально, и причина такому развитию событий — молодость нашей профессии и, со временем такие стандарты появятся, и бесполезные абстракции типа виртуальных машин будут удалены и все ОС будут иметь одинаковый API. Но это видимо будет очень не скоро.
    
    SirEdvin
    01.03.2019 11:42
    #19823184
    Я это все к тому, что вместо стандартизации, мы продолжаем решать проблему не на той стороне, добавляя ненужные абстракции.
    Мне кажется, что никогда такого не будет, потому что слишком много разных кейсов и для них нужны слишком разные стандарты. Даже тот же "стандартизированный" sql не очень то стандартизирован. Да что там, даже tcp/ip стек в каждом месте имеет свои приколы.

MacIn
28.02.2019 18:29
#19820052
-2
Высокие абстракции нужны в том числе для поддерживаемости, читаемости другими людьми, для более компактного описания задачи.

И чем абстрактнее становится язык, тем сильнее из твоего мышления вымывается его реальное назначение — контролировать электричество в железе.

Не-а. Реальное назначение — это решение задачи. Например, «показать пользователю иконку состояния ВПН соединения». Это — задача, а не манипуляция отдельными пикселями на экране. И если ты можешь решить эту задачу проще, то и чудно.
1. JerleShannara
  01.03.2019 05:45
  #19822016
  А в результате такого уровня абстракций мы имеем требования вида «два ядра два ~~ведра~~гига игровая видеокарта» для какой-то смотрелки картинок, функционал которой особо с 90ых годов никуда не сдвинулся. И всёравно все эти абстракции порой нормально не работают(пинок в сторону Java — ну почему мне требуется держать кучу версий JVM, почему софт не может работать в одной последней).

shaukote
28.02.2019 18:40
#19820130
(deleted)

Guitariz
28.02.2019 18:45
#19820156
+2
В реальности контроллировать электричество в железе никому не нужно — это не основная задача при написании кода.
Современный человек не задумывается, откуда у него на столе хлеб, в кране — вода, а на экране — сериальчики.
Безусловно, такой человек вряд ли самостоятельно сможет изготовить хлеб «с нуля».
Должен ли он знать, как это делается — наверно, да. Должен ли он сам это делать — наверно, нет.
Я точно ощущаю, что возможность решать задачи высокого порядка, не задумываясь о задачах порядков низких — это прекрасно и это в действительности ведет к прогрессу.
1. geher
  28.02.2019 22:19
  #19821038
  В реальности контроллировать электричество в железе никому не нужно
  На самом деле это очень даже нужно.
  Другой вопрос, что это нужно точно не программисту.
  А нужно оно тому, кто это железо создает и порождает первые уровни абстракции — элементы логики для электрических схем (транзисторы, конденсаторы...), элементы более высокого уровня (ячейки памяти, триггеры...), элементы еще более высокого уровня (блок памяти, АЛУ...) и так до процессора.
  Дальше программисты первого уровня абстракции уровня процессора (машинные команды) прячут под абстракции уровня компилятора (язык программирования), над которыми наворачивается стандартная библиотека, над которой наворачиваются фреймворки и так далее до абстракции уровня пользовательского интерфейса — кнопки, поля ввода.
  
  Короче говоря, чтобы программисту было чем заняться, а у пользователя была кнопка в интерфейсе, которую он сможет нажать, нужны люди, которым приходится контролировать электричество в железе.
  1. Guitariz
    01.03.2019 10:11
    #19822614
    Понятно, что процессор сам себя не разработает.
    Я за то, что пользователи этого железа (а бытовые разработчики железо именно используют,
    а не разрабатывают) не контроллируют электричество в железе. Оно на уровне абстрактных вещей формулирует другие, более высокоабстрактные вещи. И так далее. Все это в конечном итоге для того, чтобы кто-то смог действиями на экране заказать пиццу или посмотреть кино.
    И это прекрасно — я вместо того, чтобы тратить время на приготовление пиццы, займусь теми вещами, которые умею делать. А пиццу пусть приготовят те, кому это выгоднее делать.
1. trir
  01.03.2019 07:49
  #19822126
  Я знал людей, котрые сами пекли хлеб дома, довольно вкусный… там было шесть взрослых сестёр
1. Groramar
  01.03.2019 13:41
  #19823960
  и это в действительности ведет к прогрессу
  Проблема только в том, что это прогресс для программиста, не для пользователя. Для пользователя, как уже здесь писали, с 90-2000х мало что принципиально поменялось. Да, кое-что стало слегка красивее. Но те же операционки с приблизительно XP для пользователя почти не поменялись. Браузеры тоже. Да, они стали обрабатывать огромные страницы по несколько мегабайт, но чем гмейл из двухтысячных хуже современного? дизайн слегка поменялся, он стал весить раз в 10 больше. по возможностям на фронтэнде всё примерно то же.
  1. Guitariz
    01.03.2019 13:49
    #19824000
    Мобильные устройства, например, из устройства для звонков отобрали перевенство у персональных компьютеров. У меня в смарт часах больше оперативки, чем в первом компе.
    А персональные компьютеры обзавелись, например, поддержкой HDR и Hairworks. Процессор позволяет моделировать сложнейшие модели на ноутбуках в килограмм весом. Хорошую звуковую карту для проигрывания HI FI музыки можно уже не покупать — это все давно встроено в наушники.
    Само собой, если не запускать ничего сложнее почтового клиента, блокнота, консоли и третьих героев, можно все это не заметить.
    Но утверждать, что ничего не изменилось…
    
    Groramar
    01.03.2019 16:05
    #19824922
    По железу изменения есть, ок. Но обсуждаем же софт? По софту изменения минимальные. Скайп, например, стал только хуже 'благодаря' новомодному Электрону в том числе.
    Мобильником примерно таким, как я пользуюсь сейчас (Samsung J1 16), я пользовался уже 10+ лет назад (Motorola A925).
    
    Guitariz
    01.03.2019 16:43
    #19825140
    уведомление на браслет, музыку в беспроводные наушники и магнитолу, сверхскоростной интернет с возможностью просмотра fullHD видео на 6 дюймовом смартфоне — ну да, почти тоже самое.
    по софту — вымирание любительской фототехники как класса (мобильник с ии фильтрами на борту), полноценные мобильные клиенты для соцсетей (покажите мне приложение с возможностями мобильного вКонтакте 10 лет назад), невероятно интуитивное и удобное яндекс такси, голосовое распознавание команд в мобильнике с набором текста — тоже было 10 лет назад?
    
    andrey_ssh
    02.03.2019 15:35
    #19828548
    Десять лет назад голосовое распознавание команд в мобильниках было. А вот сейчас его уже нет. Перекочевало в облака (точнее на чужие компьютеры).
    
    geher
    02.03.2019 16:09
    #19828618
    Было такое. Причем в самом обычном кнопочнике, ни разу не смарте. Причем работало даже без обучения на пользователя (хотя с обучением лучше было).

oldd
28.02.2019 19:03
#19820276
+1
Всё развивается по-спирали… Во времена молодости был такой Clarion, которые позволял писать программы, щелкая мышкой по менюшкам, и программы работали. Но проблема была в том, что сделать могли только те вещи, до которых додумался разработчик языка, и даже небольшие «хочувоттак» приводили к углубленному копанию, подключению внешних библиотек и прочее.
Так что думаю, не придёт уровень «сделай вот такую хрень», потому как обязательно потребуется «сделай почти такую же хрень, но с перламутровыми пуговицами». И если разработчик абстракции не предусмотрел такой возможности, то целиком вся абстракция оказывается непригодной и придётся спускаться на уровень ниже.
1. Dr_Faksov
  01.03.2019 04:57
  #19821978
  О да! Clarion тот еще подарок был. И мышкой там щёлкалось ровно до тех пор, пока не полез руками в код. Основная его беда была в невозможности построить проект по написанному коду. Раз что-то в коде исправил, и всё, про щелканье по менюшкам можно забыть.
  Рад встретить человека, который общался с этим языком.

dss_kalika
28.02.2019 19:26
#19820362
«Язык определяет сознание». (и к этому, до кучи, ещё фильм «Прибытие»).

По поводу «через какое то время» — всё станет очень просто:
1. Сначала абстракция достигнет возможности не особо подготовленных пользователей писать «программы» — последовательности действий. Программа! Возьми рубли, преврати их в доллары и просуммируй за 100 лет по каждому клиенту. Или — подсоединись к Вконтакте и слей туда все мои фото по АПИ.
Программа ещё будет иметь достаточно много ограничений, но она будет уметь описывать в каких допустимых формах пользователь может ей сказать что хочет.
2. Пользователь сможет говорить своим языком в какой последовательности что и как надо сделать. Программа! Возьми вон тот столбец со значком Р и посчитай оборот за последний век.
3. Пользователь будет указывать что ему надо — программа сама построит алгоритм выполнения. Программа! Посчитай обороты для моего отчёта!

т.е. в итоге мы должны прийти (и придём) к тому, что бы машина понимала человека. Простого, неподготовленного человека. Именно к этому и ведёт увеличение уровня абстракций ЯП на мой взгляд и это неплохо.

другое дело, во что превратиться общество после такого перехода, как поддерживать такой «компилятор», что станет с легаси и АйТи итп-итп… но это совсем другая история.

Пока программист это часть компилятора по превращению желания заказчика в машинный код. Такие же как аналитик, компьютер, фреймворк, компилятор и все остальные уровни интерпретации данных поступивших от первого члена цепочки до последнего огонька на экране, показывающего то, что ему надо. И профдеформация у нас соответствующая части компилятора )

Не стоит бояться. Мы на стороне добра ) Системное мышление (чем бы оно нибыло развито) — это, на мой взгляд, уже само по себе очень хорошо.

… но наши дети точно будут уже совсем другими.
1. AnutaU
  28.02.2019 20:23
  #19820594
  +1
  «Язык определяет сознание». (и к этому, до кучи, ещё фильм «Прибытие»).
  Если изучать языкознание не по фильмам, то внезапно всё оказывается совсем не так.
  Вот тут лингвист кратко, но достаточно понятно разъясняет этот вопрос
  1. ninacarrot
    28.02.2019 21:02
    #19820744
    +1
    Мягкая версия гипотезы Сепира-Уорфа, тем не менее, находит немало экспериментальных подтверждений.
    
    AnutaU
    28.02.2019 21:20
    #19820808
    По моей ссылке Максим Кронгауз про это тоже рассказывает, если что.
1. Dr_Faksov
  01.03.2019 05:01
  #19821982
  +1
  Я надеюсь дожить до того дня когда в Фотошопе-лайт будет всего одна кнопка «Сделать хорошо!» Всё к тому идёт…
1. Druu
  01.03.2019 07:46
  #19822120
  Простого, неподготовленного человека.
  Как показывает практика, простой, неподготовленный человек не умеет делать то, что вы описали в п. 1-3.
1. perfect_genius
  01.03.2019 16:26
  #19825042
  Вот как примерно может выглядеть визуальное программирование. Человек повторяет ситуацию, чтобы компьютер увидел повтор и предложил автоматизировать это.
  
  Inobelar
  01.03.2019 22:31
  #19826648
  Есть ещё один (тьюринг-полный) способ визуального программирования :D

chapter_one
28.02.2019 19:30
#19820384
Даже если я говорю «случилась херня» — виновата все равно херня. А, например, в испанском такого нет. Случилось и случилось (и даже сейчас по-русски подразумевается, что случилось «что-то»).

А можно вот с этого момента немного подробнее? Очень интересно. Совершенно не знаком с испанским.
1. shaukote
  28.02.2019 21:19
  #19820798
  +3
  Меня в этом абзаце скорее наоборот, заинтересовал русский. :)
  Лично у меня (носителя русского языка с рождения), фраза «случилась херня» не вызывает ощущения что «херня виновата»; может, я как-то неправильно её понимаю?..
  1. alaskanebraska
    01.03.2019 00:41
    #19821536
    Имеется в виду, что она как бы случилась сама по себе, без участия (и, соответственно, ответственности) говорящего.
    
    shaukote
    01.03.2019 08:11
    #19822172
    Ну это понятно, да. Но «без ответственности говорящего» != «херня виновата».
    Я изначальную фразу (без уточнений, что именно случилось и кто виноват) воспринимаю скорее как форс-мажор, обстоятельства непреодолимой силы.
1. Murtagy
  01.03.2019 20:39
  #19826246
  Я вспоминаю 2 формы, не уверен какую имел в виду автор.
  Вариант «lo paso» — оно произошло. И, например, «las llaves se calleron» — ключи уронились, типо сами.

nmrulin
28.02.2019 19:32
#19820398
Типичное промышленное программирование. Сначала перешли от Паскаля где всё расписано словами к Си, где всё расписано закорючками. Потом стали пришлёпывать к нему кучу надстроек, чтобы было «более понятно».

Что же касаются потерю связи с реальностью, то на уровне обывателей всё гораздо хуже, чем у программистов. Если в 90-е годы дети понимали в компьютерах лучше, чем многие учителя информатики, сейчас, они умеют нажимать две кнопки на планшете, не знают ни что такое файл, ни директория, ни оперативная память.
1. ZurgInq
  28.02.2019 20:27
  #19820618
  +2
  Если в 90-е годы дети понимали в компьютерах лучше, чем многие учителя информатики, сейчас, они умеют нажимать две кнопки на планшете, не знают ни что такое файл, ни директория, ни оперативная память.
  
  И этого достаточно. Компьютерами в 90е было просто невозможно нормально пользоваться, не зная этих вещей.
  1. Cerberuser
    01.03.2019 07:18
    #19822082
    А сейчас как будто возможно? Именно "нормально пользоваться", а не "тупо следовать прописанным шаблонам и материться на тормоза".
    
    Guitariz
    01.03.2019 10:13
    #19822632
    за 6 лет разбирал комп 2 раза, один раз термопасту поменял (перепал тюбик, грех было не воспользоваться), и год назад воткнул видеокарту пободрее, чтобы нормально в Doom загамать. Что я делаю не так?
    
    Cerberuser
    01.03.2019 10:41
    #19822820
    Ну почему же «не так»? Вы просто работаете с ним как опытный пользователь, которому не нужно ничего делать с железом, чтобы всё работало, а достаточно грамотно оперировать софтом.
    
    Guitariz
    01.03.2019 10:46
    #19822848
    Опытность видимо — это пользоваться лицензионным ПО и автообновлениями Windows.
    
    Druu
    02.03.2019 09:12
    #19827644
    Но ведь это и правда так. Всяким околокрасногоазием болеют в старшей школе и универе. Потом люди вырастают (не все, конечно) ака "приобретают опыт" ну и… лицензионное ПО, автообновления windows :)
    
    Guitariz
    02.03.2019 12:22
    #19828148
    Мейби. Но я надеюсь, это пережиток небогатого прошлого

Hardcoin
28.02.2019 19:33
#19820400
+2
Реальна волновая функция. До этого "электричества", которое хочет контролировать автор, ещё пара слоев абстракций. И между электричеством и процессорной командой — ещё парочка.

Реальность не познаваема в принципе, люди строят модели реальности и работают с ними. У моделей есть ограничение по сложности (есть максимум, который можно понять).

Хочешь всегда работать на уровне машинных инструкций? Вотсап не сделаешь, потому что сложность будет неподъемная. Каждый слой абстракции нужен для упрощения. Работаешь с интерфейсом, а что под капотом — не смотришь, кроме самых важных случаев.
1. ninacarrot
  28.02.2019 21:09
  #19820768
  Нет ничего невозможного в создании мессенджера на уровне машинных команд. В конце концов, на ассемблере полно доступных библиотек и сетевых, и криптографических. Будет ли разработка приятной, результат надежным, а программа удобной — совсем другой вопрос.
  1. Dr_Faksov
    01.03.2019 05:03
    #19821984
    «Сделай программу которой сможет пользоватся даже дурак — и только дурак захочет ей пользоватся»
    Один из законов Мэрфи.
1. wert_lex
  28.02.2019 22:30
  #19821074
  И это еще большой вопрос, реальна ли волновая функция, или попозже найдутся другие или каким-то способом уточнённые модели.
  В общем-то если глянуть достаточно глубоко в любую часть окружающего мира, то слово "реально" вообще как-то начинает немного ускользать.
1. Nimtar
  01.03.2019 00:12
  #19821438
  Реальна волновая функция.
  
  А мне показалось, что она на таком высоком уровне абстракции, что Реактам на Электроне и не приснится.
1. 0xd34df00d
  01.03.2019 18:44
  #19825772
  +1
  Реальна волновая функция.
  На самом деле только квадрат модуля, да и там с реальностью вопросы.

wormball
28.02.2019 21:20
#19820800
-1
> И чем абстрактнее становится язык, тем сильнее из твоего мышления вымывается его реальная природа — контролировать электричество в железе.

Так вот ты какой, смысл жизни!

Заголовок спойлера

AntonSor
28.02.2019 21:38
#19820894
А с какой точностью вы хотите это контролировать? Вернее, до какой степени? Вам разве важно состояние каждого из транзисторов процессора? Вам важно, чтобы задача выполнялась. Контролируйте её и довольно.
1. shaukote
  28.02.2019 22:38
  #19821102
  +2
  До степени контроля над универсальными константами, вестимо. :)
  1. Inobelar
    01.03.2019 22:27
    #19826638
    Не смог удержаться, чтобы не дополнить этим

wormball
28.02.2019 21:38
#19820896
Я проговорил на русском четверть века каждый день — и теперь физически не верю в случайности. Или верю, что мужчины важнее женщин, потому что весь язык завязан на мужском роде. Мою статью перевели на английский, в комменты пришли американцы с просьбами заменить местоимения на гендерно-нейтральные — и я не знаю, что делать со своим возмущением. А у немцев, например, таких проблем нет. Их язык давно гендерно-гибкий. И там все ходят в одну баню, а страной руководит женщина.

В турецком и персидском языке местоимения «он» и «она» не различаются, и где там это ваше гендерное равенство?
1. Nimtar
  01.03.2019 00:01
  #19821408
  Автор явно что-то напутал с языками в этом абзаце. Следствие рефакторинга, наверное.

FForth
28.02.2019 21:50
#19820932
> Они бы не офигели от нашего количества абстракций ради абстракций?

Вот ссылкa на одну из книг по работe с языком программирования при формировании решения задачи 1984 года: Л.Броуди «Cпособ мышления — Форт язык и философия для решения задач» archive.org/details/Broudie2

P.S. Но, боюсь тогда придётся признать, что мы со своим мышлением не «универсальные винтики» в глазах менеджеров при создании ПО.

third112
28.02.2019 22:31
#19821078
+2
То, что Вы описали, началось задолго до ЭВМ: становление методологии науки суть которой моделирование. В модели надо использовать не все свойства прототипа, а только важные, без которых не обойтись. Процесс выделения таких свойств и есть абстрагирование, иначе не выдержит никакая модель — за деревьями не будет видно леса, и это будет действительная потеря контроля.

Настоящее только электричество

Есть, нпр., пневматические вычислительные машины. Так что электричество совсем не обязательно.

В свете сказанного можно заключить, что беда не в высоком, а в слишком низком уровне абстракций. Практики, владеющие многими абстрактными технологиями, предназначенными для конкретных задач, не видят леса, т.е. обобщающих абстракций, на которых базируется методология научного подхода. Столкновение с методологией науки у людей неискушенных вызывает ложное чувство потери контроля.
1. Dr_Faksov
  01.03.2019 05:14
  #19821996
  Лингвисты давно установили что чем сложнее человеческое общество, тем абстрактней его язык. У эскимосов есть несколько десятков слов, описывающих разновидности снега. Но вот слова «снег» у них в языке нет. Сказать -«выпал снег» эскимос не может. Может сказать «выпал тяжёлый мокрый снег» или нечто наподобии. Но и только.
  У австралийских бушменов в языке нет слова «дерево». Нет, названия для каждого вида деревьев в языке есть. Но сказать — «на холме 3 дерева» они не могут, только «на холме 3 акации» к примеру.
  Так что уровни абстрагирования в живом языке от языков програмирования не сильно отличаются.

Amomum
28.02.2019 23:22
#19821262
+1
Меня вот больше удивляет, что каждый год появляются новые языки программирования и люди каждый раз заново пишут для них стандартную библиотеку. Все то же самое, что было уже миллион раз написано.
В лучшем случае — пишут обертки для уже существующих библиотек.

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

А тем временем даже для С++ существует 3 основные реализации стандартной библиотеки (которые, разумеется, слегка отличаются друг от друга), а сколько их вообще существует я подумать боюсь.

И в результате мой супер-пупер-абстрактный платформонезависимый код начинает обрастать условной компиляцией чтобы учитывать все эти особенности. Какое уж там «сделай табуретку».
1. nikbond
  01.03.2019 01:47
  #19821750
  +1
  Новый язык программирования обычно подразумевает некие относительно новые абстракции и подходы к программированию, поэтому взять стандартную библиотеку от другого языка будет несколько некошерно.
  1. Amomum
    01.03.2019 01:52
    #19821762
    +1
    Теоретически — да. Практически, повторов довольно много — почти вся математика, работа со строками, разбор аргументов командной строки… И GUI раз за разом изобретают заново, да все никак не изобретут так, чтоб кроссплатформенно вышел (Electron'ы, молчать!).
    
    balsoft
    02.03.2019 15:45
    #19828574
    Вроде бы изобрели Qt, который работает везде, где вообще есть экран.
    
    Amomum
    02.03.2019 16:00
    #19828594
    Да, только окна выглядят по-разному, шрифты выглядят по-разному и т.д. Есть, короче говоря, нюансики.
    
    balsoft
    02.03.2019 16:06
    #19828610
    Это же хорошо — у каждой платформы должен быть свой Look-n-feel, и все фреймворки должны его слушаться. Хотите везде одинаковых квадратно-серых виджетов — получите tk.
    
    Amomum
    02.03.2019 16:09
    #19828622
    Я полагаю, что это зависит от конкретного приложения. Кому хорошо, а кому и не очень.
    
    Amomum
    02.03.2019 16:36
    #19828730
    Но вообще, я говорил немного не об этом, а о том, что в каждом новом языке заново переизобретают стандартную библиотеку GUI в частности.
    Биндинги к Qt встречаются примерно так же часто, как и обертки над сишными вызовами — т.е. часто, но все равно требуют большого количества оберточного бойлерплейта.
    
    PsyHaSTe
    02.03.2019 23:42
    #19829794
    Ну вот например в языках без ООПэ как гуй сделать правильно это большой вопрос. Никаких «все уже украдено до нас» нет.

Amiosan
28.02.2019 23:30
#19821298
-1
Глобализация невозможна без всеобщей перезагрузки.

suhr
28.02.2019 23:30
#19821300
+1
Где-то я потерял одну очень хорошую статью про три культуры в программировании. Людям из первой интересно программирование с более математической стороны, им важно чтобы код был красив (в математическом смысле) и корректен. Вторым интересен сам процесс вычисления и эффективность использования ресурсов. Ну а третьи просто хотят решать практические задачи.

Так теряем мы контроль над реальностью? С точки зрения первой культуры, нет: наши возможности выражать инварианты в коде и доказывать конкретные свойства только растут. С точки зрения третей культуры тоже нет: наши способности решать проблемы не уменьшаются.

У людей же из второй культуры, начиная с 70-х, дела, похоже, идут всё хуже и хуже. Посочувствуем же им.

1Tiger1
28.02.2019 23:49
#19821382
+2
Ну не знаю, я не контролирую электричество в железе (кремнии?), я контролирую изменение информации. Ведь программирование как раз про это, превращение одной информации в другую, ее хранение и контроль. Это нулевой уровень абстракции. А бегают там электроны по железу или фотоны по кристаллам меня не волнует пока проблема/задача не опускается на уровень железа (или я не опускаю ее туда). Потому что «железо» это просто еще один аспект, а не «основа всего». Это в стороне а не внизу. Завтра вы перенесете софт на другой сервер, это же не значит что его нужно полностью переписывать?

ЯП это инструмент. Само собой он влияет на носителя. Как и любой инструмент. Если в руках молоток то все вокруг кажется гвоздями. Но мышление первично, пусть и меняется под действием привычек, задач, используемого инструмента. Я вот про это «Это не гаечный ключ у тебя в гараже — это кусок твоего сознания. », это перебор. Если это действительно так, то это серьезная профессиональная деформация. Причем с привязкой к области и языку. Встречал не раз что-то подобное, обычно это была зависимость от инструментов уровня фреймворка, люди мыслили не задачей, информацией, другими критериями вроде надежности, масштабируемости, сложности, гибкости, а следует ли код духу фреймворка и мануалам/рекомендациям или нет, вот когда это было уже в ущерб задаче и другим важным параметрам — то это мешало. Фреймворк первичный у них был, а не всего лишь инструмент. С языком тоже часто встречал, но не настолько, все же любой ЯП достаточно гибок а мануалов как «истинно правильно» на нем делать не так уж и много.

Абстракции это нормально, даже хорошо. Абстракция это как модель, отражает только нужные нам качества чего-то. Их ограниченное количество и все нужные, и это дает настоящий контроль. Если вы управляете автомобилем то вы управляете с помощью руля и педалей. Где-то там работает двигатель по своему циклу карно, что-то подсчитывает и контролирует бортовой компьютер, и где-то датчик в бензобаке ждет своего часа. Вы смотрите на панель и крутите руль, а не контролируете каждое колесо отдельным рычагом, наблюдая работу двигателя через прозрачный кожух в прозрачных цилиндрах и периодически на ходу опускаете щуп в бензобак.
Вам все это не нужно, да это даст больший контроль (на самом деле нет), но это не нужный в данный момент контроль, он только мешает, забирает время, отвлекает, размывает фокус, и котролируя каждое колесо вы меньше внимания сможете потратить на дорогу. Контроль потребуется когда вы услышите странный стук а потом машина заглохнет. Вот тогда вы откроете капот. Или потащите автомобиль в автосервис.
Да мы пользователи. Пользователи процессора, файловой системы, пользователи библиотек и third-party закрытых инструментов, пользователи API внешних сервисов. Мы пользователи черных ящиков. Эти ящики вокруг нас. При разработке мы фокусируемся на том что нам нужно сделать, при этом «пользуясь» кучей инструментов о которых мы знаем крайне мало, только то что нам нужно. И если мы будем заглядывать постоянно к каждой машине под капот, просто чтобы сохранить имитацию (да именно имитацию) контроля — мы не сможем заниматься основной задачей. Мы заглядываем под капот, вскрываем ящик только тогда когда понимаем что проблема именно в этом ящике. Или не вскрываем а меняем. И это нормально. Потому что мы знаем что вот этот черный ящик с надписью «процессор» выполняет то-то и то-то, мы знаем что он делает, нам не нужно знать как, и тогда черный ящик можно спокойно заменить на другой с тем же набором свойств. Сервис на другой. Библиотеку обновить. Это отлично, это дает гибкость и стабильность. И все благодаря абстракциям.

Даже мир для нас черный ящик а мы для него, и общаемся мы с ним ( и с другими людьми) с помощью ограниченного количества входов-выходов (чувств и действий) и абстракций (язык, мимика, телодвижения). И в самом черном ящике нашего восприятия еще куча промежуточных слоев и наслоений из нашей памяти, чувств, отношений, образов, все что формирует мировоззрение и текущее настроение, и эти слои тоже меняют информацию, сильно меняют. Но эти слои в сумме и образуют наше создание и мышление. Без них мы бы просто и беспристрастно, как видеокамера, фиксировали бы входящую информацию. Только фиксировали. Отвлекся, вернемся к баранам.

То что компьютер все больше становится черным ящиком и для нас, программистов, это нормально, это специализация. Это непривычно, нам немного стыдно признавать что мы уже ничерта не понимаем в деталях в работе процессора и вряд ли сможем починить материнскую плату если что-то пойдет не так, не говоря уже о том что не спаяем компьютер в гараже из набора простейших деталек и чипов из ближайшего магазина радиотехники. Но это нормально, суммарно контроль не утерян, он просто стал глубже и разделился на десятки специализаций, ни у одного человека уже не хватит знаний чтобы быть экспертом во всем что связано с компьютерами. Обьем «эксперта» во всей области давно уже перевалил за 10 тысяч часов и исчисляется миллионами часов, и скорость роста знаний превышает скорость освоения, а сложность растет. Один человек просто не способен разобратся во всей области. Он не будет успевать поддерживать актуальный уровень. И даже опуститься вниз до процессора по отдельной области. Даже поддерживать 100% информированность по всем связанным с узкой областью инструментов не получиться, даже популярных, не то что опускаться вниз.
Будте хороши на одном, своем уровне, и своей области, пусть другие занимаются остальными, каждый своей.

Кстати вот эта практика, которую вы описали, с мультиязычностью меня немного удивила, имхо, плохо это. На простых задачах и проектах в принципе нормально, но на сложных начинают тащить привычки и принципы одного языка в другой, и такой плохоподдержвиваемый ад со временем получается…
Если язык не важен — почему их так много? Разве что действительно одну и ту же библиотеку на разных языках, для пользователей того же API. Ну это редкость и достаточно законченная задача, там если что и «выбросить все и написать заново» не страшно.

А полноценно контролировали и софт и железо только в 50-е, когда еще и разделения толком не было и софт писался под конретный экземпляр компьютера. Вот там контроль. Вот там постоянно открытый капот. Вот там заточка кода под железо а железа под код. Вот там знание компьютера до каждого резистора и понимание каждого байта и каждого сигнала. Вот только это совсем не эффективно и не надежно, и замена «винчестера» (не говоря уже о «процессоре») могла превратить весь софт в ненужный хлам.

Извиняюсь за многобукв, во всем виноваты абстракции, человеческий язык слишком несовершенен, и из-за этого приходиться использовать дополнительные слои в виде тех же примеров и аналогий, чтобы передать изначальную мысль с минимумом искажений внутренними фильтрами наших черепушек. Вот бы где нам действительно «языки низкого уровня» пригодились бы. Когда там уже мыслеречь допилят и общение образами?
1. NeocortexLab
  01.03.2019 22:30
  #19826644
  -2
  ниасилил… простите… можно кратенькую выжимку? КГ-АМ?

OlegGelezcov
01.03.2019 02:28
#19821816
Абстракции упрощают жизнь условно, для одних людей, которые были воспитаны в условиях этих абстракций действительно становится все легче, чтобы реализовать определенный функционал — им нужно меньше телодвижений. Другое дело, что эти абстракции строят и больше стен в плане свободы выражения, а соответственно далеко не все задачи будут решать находясь только в парадигме высокоуровневого программирования… а там будет все также сложно и даже еще сложней.

Таким образом со временем и это мы уже наблюдаем сейчас, все программисты делятся на две категории (условно)
— программисты-клиенты живущие в условиях простых бизнес-задач не выходящих за возможности абстрактных фреймворков
— программисты-производители или творцы, которые срать хотели на все правила и сами строят новые правила, или абстракции, или абстракции для абстракций.

Первая категория — низкооплачиваемые кодерки, которые лепят формы в душном офисе всю жизнь, их ЗП чуть выше средней по стране, но вполне с ней сравнима, их основная задача — вовремя учить тонны новых абстракций и обслуживать базовые потребности бизнеса с помощью них

Вторая категория — высокооплачиваемые спецы, которые идут впереди планеты всей, их зарплаты в зависимости от страны в диапазоне 100-300К, они придумывают разные языки, фреймворки, платформы и не дают заскучать первой категории.
1. 1Tiger1
  01.03.2019 09:46
  #19822492
  как понимаю вы из второй категории?
  1. OlegGelezcov
    01.03.2019 12:53
    #19823666
    Нет, думаю что ближе к первой, точно не рокстар и звезд с неба не хватаю, вынужден 50% времени учить новое, чтобы остаться в теме и не двигаю прогресс никак, скорей прогресс двигает мной
    
    1Tiger1
    02.03.2019 10:44
    #19827884
    у вас странное понимание области разработки. очень странное. сколько работаете в этой области?
1. JustDont
  01.03.2019 22:43
  #19826674
  Вот только вы денежный вопрос слегка перепутали. Бывает.
  Первой категории платят деньги. Они бизнес-задачи решают, а бизнес им за это деньги платит. Конечно, клепателям формочек платят слегка меньше, но вот изобретателям формочек (для последующего клепания) — уже нормально так.
  Вторая категория, творцы и маги — иногда не получают примерно вообще ничего. В лучшем случае — пока кто-нибудь из первой категории не прочувствует мощи очередной магии, и не начнёт заносить. А в худшем — творцы и маги просто работают в первой категории, а магию творят — во внерабочее время. И подавляющее большинство этой магии (как впрочем и любых других вещей) — не взлетает вообще никак.

Pilat
01.03.2019 03:04
#19821864
+1
Был фантастический рассказ — старый программист что-то клепает, а искусственный интеллект всё не может понять и повторяет — «ты мне объясни что ты хочешь, я сам сделаю быстрее и лучше, так как ты давно никто не делает» и т.д. Конец рассказа — вирус запущен, ИИ понял что ему конец, но сделать уже ничего не может.

Насчёт творцов. В Perl два виде массивов — просто упорядоченные списка, и хэши. И всё. Тривиальный Borland С++, как помню, начинался с десятка разных массивов-коллекций-списков разной степени навороченности и километровой наследуемости. Программисты-творцы решили что Perl слишком простой. Ну и получили то что получили — вместо простого понятного языка сделали кучку «магии», с которой теперь приходится справляться. Желание творить привело к появлению тварей.

IvanGanev
01.03.2019 03:41
#19821900
Задача программирования не в том что бы контролировать электричество, а в том что бы решать проблемы реального мира. «Реальность» это не то что происходить внутри компа, а то что происходит снаружи. Абстракция которая упрощает решение проблем — приближает программиста к реальности, а не отдаляет его от них.

Более того, идея что реально только электричество — это именно что отдаление от реальности, подмена реальности… абстракцией.

Страх же «отупеть» довольно странен. Все кто использует русский язык, но не является филологами — дураки которые не могут использовать русский язык?

andrey_aksamentov
01.03.2019 06:20
#19822038
Технологическая сингулярность. Никто не будет понимать как это работает. Скорость устаревания знаний превысит человеческие возможности.

shasoft
01.03.2019 06:47
#19822050
Задача не «контролировать электричество в железе», а получить от этого железа требуемый результат.
К примеру есть задача: расчет чего-то (зарплаты к примеру). Можно это писать на ASM, можно на Си, можно на 1С. А можно ещё 1С допилить и писать на этом дополнении. При этом если на каком то слое абстракции уперлись в границу, то можно модернизировать только этот слой (или ниже). И специалист понадобится именно по этому слою абстракции. Человеку, который пишет компилятор Си=>ASM не нужно знать как работает 1С. У него есть задача для его слоя, он её решает. В результате разработчик 1С получает доп. плюшки. При этом специалистов по ASM будет меньше, чем по 1С, потому что на 1С больше пишут программ. На мой взгляд плюс абстракции как раз в том, что специалисту одного слоя не обязательно знать ка работают другие слои. Точнее не обязательно детально знать, хотя некоторые знания не помешают ему писать более продуктивный код.

ledocool
01.03.2019 06:48
#19822052
Вообще-то уже сейчас программирование по большей часте задача гуманитарная. Или вы думаете много матана надо знать, чтобы клепать сайтики?

411
01.03.2019 08:31
#19822214
Ну вообще-то это не потеря контроля, а использование наработок, опыта и знаний нескольких поколений программистов для упрощения создания ПО. Вот какая мне разница, что там происходит в железе или какой машинный код исполняется, когда я написал цикл? Мне важно, что описанные мною действия будут правильно воспроизведены и я доверяю разработчикам .Net/MRI/gcc/и тд в этом. Ведь они тоже стараются использовать наработки, знания и опыт, чтобы получить лучший вариант кода и продукта.

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

Если же выбранный инструмент не позволяет эффективно решать задачу — стоит выбрать другой. Если не подходит «эй компьютер, сделай мне эту хреновину», то это делается чем-то другим. Важно, что низкоуровневые инструменты никуда не исчезнут и в большинстве случаев сделать что-то по своему будет возможно. Но наиболее вероятно, что кумулятивный опыт разработчиков будет намного больше, чем опыт одного программиста, которому нужен контроль, и необходимые вещи уже будут сделаны корректно и оптимально.

prostofilya
01.03.2019 08:37
#19822240
Это вопрос доверия, доверять или не доверять — сугубо ваше личное дело. На 100% доверять своему инструменту нельзя никогда, даже если это простая палка и вы сейчас в 20 веке до н.э. Она вполне может сломаться. Так нас взращивает природа, а иначе мы бы потеряли своё главное преимущество — приспосабливаемость, а затем вымерли.

vsantonov
01.03.2019 09:11
#19822314
Понятно желание передавать мысли в чистом виде и не делать поправки на среду передачи данных, но так устроен язык, из множества вариантов в определенной группе людей родился самый эффективный метод коммуникации, который удовлетворял требованиям. Если у Испанцев не было никогда требования обвинить кого-то в случившемся и они позволяли вещам «просто случаться», то и такой абстракци не было заложено в язык. Представьте что было бы если не изобрели булеву алгебру и не было бы всех эти XOR, AND и т.д. Все равно нашли бы способ, как сказать машине что от нее нужно, придумав ту абстракцию, которая бы решила задачу. Ничего плохого в абстракциях не вижу, мы в своей голове достаточно высоко сидим с позиции абстракций, никак не контролируя сердцебиение и другие низкоуровневые процессы, что высвобождает нам кучу времени для размышлений, написания программ и т.д. По сути абстракции экономят самый ценный и невосполнимый ресурс- время.

engine9
01.03.2019 09:19
#19822340
Я не программист, но скромно постою в уголке вот с таким мнением. Мне кажется, что проблема отчасти обусловленна стремлением бизнесменов извлечь выгоду «сейчас» ценой проблем «потом». Ветеринары пичкают коров килограммами антибиотиков, получая устойчивые штаммы. Производители товаров заворачивают продукцию в десять слоев упаковки, от чего на суше растут горы пластикового «шлака» который природным утилизаторам совсем не знаком, программеры в спешке пишут костыли, и так далее.

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

peacemakerv
01.03.2019 09:22
#19822352
А мне все же нравится стиль программирования типа: «Джарвис, вот тебе чертежи в каталоге data/data/docs, изготовь в железе, покрась в оранжевый, прошей выхлоп на EURO3».
И пофигу (лично мне) какие там в процессе его работы типы переменных.

Miron
01.03.2019 09:45
#19822486
«Языки которые мы потеряли». Крис Касперски.
www.evilfingers.com/publications/research_RU/oldnewlang.pdf

batman12345
01.03.2019 10:18
#19822686
+1
Фил, поздравляю с очередной ступенью просветления! Серьёзно.
И да, ложки не существует.
Концептуальный изъян твоего мнения, изложенного в этой статье, в том, что ты думаешь что понимаешь хоть что-то. Это заблуждение.
Ты не знаешь ничего ни о природе электричества, ни о том, благодаря чему вообще возможно существование этой природы. Электричество — это просто ещё один уровень абстракции вбитый в тебя в школе.
Русский язык сам по себе нейтрален. Окрашиваешь его так или эдак именно ты. Проблема в тебе, а не в языке. Ты просто не готов воспринимать и строить сложные конструкции. Даже свой идентификатор ты сократил до трёх букв.

Kilorad
01.03.2019 10:19
#19822688
+1
Давно занимаюсь системами Reinforcement learning. И вот у меня возникла задача написать RL на языке ActionScript 2.0. Это который Флеш, да ещё и старой версии.
Как же я ругался. Никаких тебе векторных вычислений. Никаких Dataframe-ов. Всё писать через кучу вложенных циклов, которые на AC 2.0 работают не сильно быстро. В общем, я написал кучу своих функций для векторных вычислений, функцию для KNN-регрессии, функции вышли довольно глубокой вложенности, но в принципе задача была решена.
Это я к чему. Мне нравится, когда мы можем дёшево поднять уровень абстракции. Мне нравится, когда кусок программы можно не писать, а просто подключить в виде «чёрного ящика» — если этот ящик неплохо работает из коробки, и при этом пригоден для тонкой настройки.

Или ещё. Я как-то работал с нейросетями на Matlab. Там есть две нейросетевых библиотеки — старая и новая. В старой можно заглянуть в любой вес любого нейрона, его можно подправить вручную. В новой… Заглянуть можно сильно не во всё, и точно нельзя всё поправить вручную.
В первом случае передо мной был сложный чёрный ящик, в который можно влезть до уровня отдельных переменных — сложно, но можно. А во втором был просто сложный опечатанный чёрный ящик =)

Так что абстракции можно реализовать с сильно разной прозрачностью. И в таком случае они необязательно становятся проблемой

predessor
01.03.2019 10:24
#19822722
Вот поэтому-то, самый лучший язык тот, на котором ты уже пишешь много лет.

OldPrg
01.03.2019 10:28
#19822746
+1
Статья очень, очень умная, аж зарегился чтоб комент написать.
Сам автор статьи в силу возраста еще не врубился в то, что уже нарыл.
1. Учили в вузе прогить в 82. 8разрядный аля копия какого то американца60х, создали у нас в 70х, тумба-комп (небольшой размер считался), клава (!), световой карандаш (кнч с проводом) для исправления на экране символов, блок из 8 тумблеров для карандаша, монитор символьный. Очепятался, выставляешь тумлерами 8раз код нужного символа, подносишь карандаш к символу на экране, жмешь типа ентер и обана, готово! Потом фортран на ЕС (шкафы) и дальше pl/1, басик. Кто был особо заточен, то самозацепил во вред пьянкам кобол, ассемблер. Бесконечные зависания отечественных ЭВМ (ну компом их тогда не называли), наладчики быстро меняли перегоревшие платы, зайдя за шкафы и открыв из зады, потом они у себя выпаивали сгоревшие элементы и впаивали новые на платах, заливали программатором микропроги в пзу. 88 г — польская Мазовия (экспишка с ЖД 10М и двумя флопами на 5 по 720К) открывает графический басик и остальные чудеса американского софтпрома с примером в виде принца. Мы по старинке начинаем в фортрана 77 под старые золтопесочнонесущие задачи и тут же уход в космический дибейс < — это важный момент. То, что ваяли за месяц на пл1, дибей — за 10 мин. с нуля. Даст ист фантастиш!!! Заказы на бюсгалтерские и прочие базоданные задачи как ливень из денег. Боги, а не прогеры в то время железных феликсов на столах приятных женщин.
2. Я знал одного суперчела электронщика-системного прогера, который читал как я здесь пишу, 16ичный машкод, а ассемблер, как русский лит+матерный+остальной, взял мсдос, продебажил и написал за месяц ос на Корвет в 92 году, дрова писал под любое устройство, если хоть какая инфа есть по эл.базе (ну из чего железо сварено). За ним вояки с далик самолет присылали. Мозги как дом советов, но системщик. На все остальные ЯП, кроме С, смотрел как на игрушки для взрослых. Неинтересно. Он генетик.
Что к 92 поняли: бизнес прогера — это не знания всей хрени из ЯП, а скорость, в которой дедлайн — НЕ последний остаток кислорода. А тогда нас было по пальцам пересчитать. А теперь конкуренция мама не горюй. Да, С и вижн (ассемблер уже тогда был только для системщиков) — приближали нас к железу, но заказчик требовал «вчера». Поэтому от дибейса прыгнули в фохпро, затем ко всему, что быстрее с заказчика бабло стряхивает без ущерба имиджу и привязывает его к кошельку прогера навсегда в качестве дойной коровки, так как мало кто из современной школоты возьмется проги тех лет доработать. Доятся и поныне. Выбор ЯП с дааааальним прицелом, как история показала.
3. Если (1), то много конкуренции, но больше возможностей забить на нищету.
, в противном — (2) будешь генетиком железа — то большие деньги, то их часто нет. Объединение (1) и (2) — утопия или как быть никому не нужным, прожить жизнь среди хрени и не остаться здоровым телом и психикой.

OldPrg
01.03.2019 10:45
#19822844
Поэтому выбирая ЯПы думать надо думать о следующем: быстро делаем деньги, привязываем заказчика на очень долго, есть перспектива развития ЯП.

Да, и вот еще что: вы что поколение Z думаете, будете всегда этой хренью заниматься до крышки? Это же самосожжение, а не икаровский полет! Это же удел мойщиков золота на эльдорадо. Двадцать лет и все. Дальше только аналитик, продажник, рукпроектами или просто хозяин с головной болью за свое детище в заднем месте. Это я о чем: ЯП — не самое в вашей профессии, а только вынужденные ступени к тому, чтобы с 45 лет жить безбедно в приятном месте нашей или выбранной страны, и делать только то, что не требует дедлайна — бича и палкой по пяткам всех прогеров, жить не ходя под себя до гораздо большего возраста, чем в мечтаниях правительства на поднятие пенсионного «не доживут».
1. 0xd34df00d
  01.03.2019 18:56
  #19825838
  Дальше только аналитик, продажник, рукпроектами или просто хозяин с головной болью за свое детище в заднем месте.
  А зачем, если можно просто продолжать писать код и наслаждаться процессом?
  1. OldPrg
    01.03.2019 20:12
    #19826150
    Очень правильный вопрос для пишущего прогера, а не админа и озе братии, так как кодировка — это нередко захватывающая тема. Спрыгивают по нескольким причинам: 1) надоедает однообразие синего воротничка; 2) устают от переходов с ЯП1 на ЯП2; 3) здоровье; 4) желание значительно больше заработать и больше времени отдавать семье; 5) постоянные дедлайны и ответственность; 6) озе.
    У меня было 4), потом резко 3). Статистика показывает, что дальше 45 очень мало, кто кодирует. Все уходят за еще большими деньгами или уже хватит и хочется заняться чем то другим, но не кодировкой, особенно по корявым постановкам, типа вот этой картинки
    toster.ru/q/6866, которую я увидел в 88.
    Нередко админами и сапортами продолжают. Но мое перлы — это исключительно по ЯП -первичное свойство натурального прогера.
    
    0xd34df00d
    02.03.2019 04:59
    #19827382
    1 — непонятное что-то.
    2 — можно не переходить. Я знаю людей, которые уже 20 лет пишут на C++98/03, им норм. Хотя я бы так не хотел, переходить весело!
    3 — универсальный ограничитель.
    4 — ну это смотря какие приоритеты.
    5 — зависит от места работы.
    
    То есть, нет, конечно, жизнь длинная, и я вот до того с ЯП на ЯП допрыгался, что последние мои изучения языков используют не компьютер, а ручку и бумажку, но то такое. От роли продажников, аналитиков и прочих рукпроектов — спаси и сохрани.
    
    OldPrg
    02.03.2019 23:44
    #19829806
    1 — это 2,3 и более лет в одном крупном проекте свои грядки шлифуешь.
    2 — весело в теории. Ставиться задача и сроки, а на новом ЯП всё идет как всегда и это не нравится шефу, заказчику и коллегам.
    3 — надо задуматься, а почему так мягко говоря мало кодировщиков за 40.
    4 — да, да, да. Когда занялся финансами порядок к з/п прибавился, а пахать и особенно думать требовалось на порядок меньше.
    5 — читаем книжку «Дедлайн» Де Марко.
    Жизнь оооооочень короткая. Продажником редко становятся вообще, кто бы то ни был, а уж тем более прогер. А вот рукпроектофиса в приличной корпорации получает не 100К, и не 200К, а 300К. Когда входишь в деньги, которых хватает на многое и еще остаются, то розовые очки — я пуре прогер и мне об колено все эти морочки с управлением — сваливаются, топчутся и остаются «там», где синий цвет за стеклом подержанного соляриса.
    
    0xd34df00d
    03.03.2019 00:22
    #19829882
    1 и 2 у вас в итоге вместе хорошо сочетаются.
    
    Когда входишь в деньги, которых хватает на многое и еще остаются, то розовые очки — я пуре прогер и мне об колено все эти морочки с управлением — сваливаются, топчутся и остаются «там», где синий цвет за стеклом подержанного соляриса.
    У меня вместо этого отвалились очки, показывавшие, что в деньгах есть хоть какое-то разумное количество счастья.
    
    JustDont
    03.03.2019 12:19
    #19830560
    3 — надо задуматься, а почему так мягко говоря мало кодировщиков за 40.
    
    Пока отрасль растёт (а она растёт всю дорогу с середины 20 века и останавливаться не собирается) — у вас всегда программистов «в годах» будет мало. И далеко не только потому, что они куда-то там на агромадные деньги уходят. А просто потому, что молодёжи в отрасли каждое поколение будет всё больше и больше.
    
    OldPrg
    03.03.2019 13:30
    #19830692
    все факторы приведенные выше будут играть положительную роль в омолаживании отрасли, особенно при повышении уровня ЯП.
    
    JustDont
    03.03.2019 13:48
    #19830730
    Конечно. Вопрос только в том, какие из них существенные, а какие — на уровне «я художник, я так вижу». Так-то и вы лично в энтропию вклад вносите, но на фоне астрономических объектов вашим вкладом можно просто решительно пренебречь.

OldPrg
01.03.2019 11:07
#19822966
И еще: вам по своему повезло, что столько ЯПешек расплодилось и околояпешной хрени. Пройдет три десятка лет и кто будет поддерживать весь зоопарк софта на пхп, жабе, эрке и прочих буквах? Думаете, что вас много и все также будет с конкуренцией? Нет. Многие срулят с этого каната над пропастью дедлайнов, глюков и нового умасбродства разработчиков ЯП. Поэтому, выбирая ЯП надо заморачиваться не осознанием гмомодификации своих мозгов линейным, объектным и прочими «яйцами только в профиль», а тем, как через 30 лет доить истеричных от отсутствия старых профи заказчиков сегодняшнего софта. Типа, как хобби, тряхнуть стариной с пайтОном, когда все прогеры будут просто говорить ИИ: «хочу хрень для заказчика Пупкина, ТЗ завтра пришлет, а не пришлет, напомни ему, но осторожно».
1. Miron
  01.03.2019 21:35
  #19826460
  Вы с пайтОном погорячились маленько :)
  Тут перлового наследия в корпоративном сегменте вагон и маленькая тележка. Просто пока ещё эти издержки не вылезли на осязаемый уровень, так чтобы до высокого руководства корпораций это наконец таки дошло, что переходить на новые рельсы надо было уже очень давно. Надо писать автоматические переводчики для языков программирования. LLVM тут прям вовремя выстреливает. Диалектов уже очень много и средний уровень разработчика будет только падать, из-за возрастания количества накопленных знаний в IT-среде.
  1. OldPrg
    02.03.2019 01:09
    #19827088
    На счет гада это я к эдак году 2035 отнес вас нынешних «горячих финских парней», из колыбели конца 90-х. Реально, еще где то мэинфреймы тащат воз, перфокарты в подлодках США (они то не подвержены магнитному дестрою), виндовоз 3.1 на мсдосе 6 не меняют. А чё, работает, нахрен бабло тратить. В Калининграде стоит морской корабль космического наведения ракет «Космонавт Пацаев». Был на консервации. Там Минс32 в полной сохранности со всей периферией 70лохматого года. Хоть щас заводи на точки.
    Но где взять спецов? Все уже забили, кости ломит, хвост отваливается. Тяжкий труд у прогера. Немчуры еще с 80х от компов отлынивают. Только азия (степбайстеп) заполоняет пространство. Иначе бы вы были на вес золото при таком темпе заполнения мира дискретным железом.
    Блин, какие то п мне минусов наставили. я же не пришел тут кого то критиковать или в маинпрогеры лезть. сдалась мне эта печаль.
    Автору огромный респект. Действительно, прогерство и ЯП наносят свой визит мышлению, делая не только из нас под стать авторам ЯП, но и влияя на менталитет. Раньше от нас шарахались (свитер, небритость и логические речевые структуры), а теперь тянуться. Слова «версия», «апгрейт», «баг» и прочий птичий сленг, который мы не выделяли, стал уже в бизнес среде чем то мажорнистым. Народ потянулся к ботаникам.
    
    mkovalevskyi
    02.03.2019 01:27
    #19827134
    Больше как бы напрягает тот печальный факт, что низкоуровневая разработка все еще имеет место быть. И получается дикая пропасть, между теми кто таки проэктирует теже процессоры, и теми кто их потом использует. И она растет.
    Прямой путь к жрецам от технологий, с тайными знаниями, обрядами, вот этим вот всем )
    Или к переходу всего низкоуровневого на ИИ, с полной не возможностью фикса давно сделанных багов, бо никого живого, кто сможет глянуть что не так — просто не будет…
    
    OldPrg
    02.03.2019 16:48
    #19828748
    Ваш вопрос очень правильный. Он приходит со временем.
    Надоедает прикладуха. Кто то воще забивает на писанину, берется за орк, сертифицируется и живет сисадминкой в штатах. И таких я знал.
    Но мысль углубляться к корням — она правильная. Хуже не будет, если только в азарте на завалить основную работу. Сразу ведь не перепрыгнешь в системщики.
    У меня был выбор когда проходили ТАУ, паяли, че то прогить пытались на ассемблере. Препод был г«но в том институте. В другом другой уже опоздал, я засел за фортран всерьез и мне уже платили. Мне понравилось много и сразу. Есть сварщики 6 разряда, а есть операторы сварочных станков с ЧПУ. И те и другие — нужны, а что им прет, то сами на ромашке своей души делают выбор.
    В любом случае, если душа запела дрова попилить к управлению освещением в квартире или какого робота родить, надо обязательно попытаться.
  1. Pilat
    02.03.2019 13:19
    #19828264
    Тут перлового наследия в корпоративном сегменте вагон и маленькая тележка.
    
    До руководства достреливает, что «новые рельсы» это Oracle, который внезапно стал нежелательным явлением. Или какая-то модная технология, которая точно так же внезапно будет объявлена устаревшей.
    
    OldPrg
    02.03.2019 16:57
    #19828768
    орк пока очень сильно рулит корпоративным сегментов в мире. ларри бдит и сразу скупает проявившихся серьезно конкурентов и убивает в своих застенках.
    вы еще увидите зе енд жабы.
    возможно монополия реляшки и сиквеловские запросы уже морально давят как старье. вероятно как в истории ксероксных шрифтов придерживают что то архиважное, выживают из старого как из нефти автомобилестроение. в айти будут до последнего один и тот же код 100 млн раз продавать. отличный бизнес.
  1. OldPrg
    03.03.2019 13:38
    #19830714
    на счет переводчиков было дело уже в 80-х при переходе на персоналки. оказалось проще и гораздо лучше задача выглядит в новой итерации кода на современном языке. никто не любит чужой код на чужом языке, а уже перевести его на ЯП2 младше на 20 годин ЯП1, заставить работать и восхитится божественностью ума того автора — ну редчайший случай. Вывод: проще пойти в булонский лес и трюфель найти.

BlancLoup
01.03.2019 11:21
#19823036
Автор, а за какими уровнями абстракции ты при употреблении пищи? Думаю пора бить тревогу, что мы не знаем в принципе откуда берутся те или иные продукты. А то приходишь такой в столовую, говоришь: «мне котлету», опа, и котлета почти магически появляется у тебя в тарелке. Это неправильно. Надо идти и выращивать дикого кабанчика…
1. OldPrg
  02.03.2019 01:25
  #19827130
  Правильная мысль. Жоем не знамо что в булочке из гмошной пшеницы (а пшеница ли это?).
  — Еда есть? — Каша.… Пластиковая (1986 г, х/ф Кин-дза-да).
  Но работать в постоянке асматиком & шарпером & слоном с либками — прощай жизнь. А изредка — ну это не айспрофи. Специализация была изначально — или системщик-канифольщик, или прикладник-шахматист. макдональдс — 12 челов как лента конвейера ради быстробутера. К коротким спринтам клиенты тянуться. Клиенты — это ради кого или их бабла пишутся проги. Приличной герле рафаэли без, хотя бы, сонаты не нужны. ЯП должен косвенно давать заказы наперед и короткий ЖЦ.

eefadeev
01.03.2019 11:28
#19823084
Самое время вспомнить сакраментальное: «Любую архитектурную проблему можно решить путём добавления ещё одного уровня абстракции. Любую, кроме проблемы слишком большого количества уровней абстракции...»
1. dimm_ddr
  01.03.2019 14:11
  #19824132
  Выглядит как демагогия. Потому что не описано а что же за проблема со слишком большим количеством абстракций. Если сложно работать или просто запомнить, то можно закрыть несколько абстракций новой но одной. И работать уже с ней. Само по себе количество в вакууме — не является проблемой.
  1. eefadeev
    01.03.2019 15:20
    #19824620
    Проблема всегда одна и та же: сложность. И убрать её из системы принципиально невозможно. Её можно только перераспределить (попутно увеличив).
    
    dimm_ddr
    01.03.2019 16:27
    #19825046
    Конечно, общая сложность системы никуда не денется. Но я не знаю ни одной реальной задачи когда нужно сложную систему охватить целиком за один раз. Всегда можно разбить на более мелкие задачи на разных уровнях абстракций и сделать по отдельности. Если у вас есть проблема с количеством абстракций, то объединение нескольких в одну (то есть фактически добавление новой абстракции) как раз таки и решит эту проблему. Я допускаю что это может быть не всегда так, но в общем случае ваше изначальное утверждение неверно.
    Демагогией же это выглядит как раз таки из-за обобщения которое рассыпается если задуматься. Я не пытался сказать что вы это специально, скорее пытался показать недостаток вашего утверждения.
    
    eefadeev
    01.03.2019 16:33
    #19825080
    Вы слишком серьёзны :)
    К тому же это не моя фраза (именно поэтому она взята в кавычки), а вполне расхожий афоризм. Который, как любой афоризм, является «шуткой, в которой есть доля шутки».
    
    dimm_ddr
    01.03.2019 21:38
    #19826470
    Так я лично против вас ничего и не имею, мне не нравится сама фраза. В первую очередь потому что на мой взгляд она только выглядит красиво, но, как обычно в таких случаях и бывает, неверна.
    
    0xd34df00d
    01.03.2019 18:59
    #19825852
    Но я не знаю ни одной реальной задачи когда нужно сложную систему охватить целиком за один раз.
    Любая достаточно долго живущая околотырпрайз-система. Особенно если там архитектурные астронавты постарались. Да, круто, мило, оопэшно, фабрики абстрактных прокси над синглтонами парсеров командной строки, но, блин, глобальный стейт (а он всегда будет, если язык не мешает его делать, как всегда будут баги), функция в одном месте зависит от состояния класса в другом месте, и вся эта изящная башня рассыпается о пугающее дальнодействие.
    
    dimm_ddr
    01.03.2019 21:37
    #19826464
    В любом случае это можно лечить добавлением абстракций и разбитием этого монолита. Это не самый выгодный подход (как минимум не всегда), но это точно рабочий подход. А суть моего комментария была именно в существовании такого варианта, ни в коем случае не в его оптимальности.
    
    Miron
    01.03.2019 21:46
    #19826502
    Я допускаю что это может быть не всегда так, но в общем случае ваше изначальное утверждение неверно.
    Вы будете правы только в одном единственном случае — когда вычислительная мощность и память — бесконечны. В остальных вариантах вы проиграете в производительности и памяти, так как их конечное число.

playermet
01.03.2019 12:10
#19823412
Абстракции — это отлично. Они могут превращать степенную трудоемкость множества задач в линейную. Вместо того чтобы писать X1, X2, X3… для каждого из Y1, Y2, Y3… (и не дай Бог есть еще и слой Z) можно единожды написать каждый, соединив их через интерфейсы более высоких абстракций. Причем каждым компонентом может заниматься профильный специалист, и делать это намного лучше чем мастер на все руки, работающий со всеми уровнями абстракций сразу. Разделение труда не зря было придумано.

А «сделай-ка мне вот эту хреновину» никогда не наступит. Потому что без внятного ТЗ — результат ХЗ, и без телепатии никакой ИИ этого не исправит. А подбробная спецификация того что человек хочет от компьютера это как бы и есть код.
1. dimm_ddr
  01.03.2019 14:13
  #19824140
  Оно и с телепатией не получится. Потому что если человек не может сформулировать чего он хочет, то оно и в голове у него в виде каши находится.
  1. playermet
    02.03.2019 19:27
    #19829140
    Имелась в виду телепатия более глубокого уровня, читающая из мозга всю нужную инфу.

mikelavr
01.03.2019 12:28
#19823552
Я прокомментирую вчерашним кейсом из реальной жизни embedded программиста.

Есть аппаратный протокол подключения внешней аппаратуры к процессору — SPI. Он простой как три копейки, и в процессорах реализован аппаратно.
Есть моя функция, которая общается с SPI через библиотеку от изготовителя. Есть примеры использования этой библиотеки. Смотрю в пример, пишу аналогично — и получаю странности в процессе. Чаще всего работает хорошо, но иногда — внешняя аппаратура (в моем случае — LCD) начинает вытворять чудеса, явно получая неправильные команды.
Нормальный программист первым делом ищет ошибки у себя в коде. Не нашлись. Написал тестовую программную реализацию SPI на уровне размахивания физическими ножками — работает (уже хорошо — LCD исправен и плата корректная), но так оставлять в релизе нельзя (как минимум надо скорость на порядок больше). Начинаем спускаться по уровням абстракции, благо библиотека с исходниками. Раз функция, два, три, четыре, дальше обращение в порты процессора. Вроде все выглядит логично (правда количество #ifdef на все случаи жизни зашкаливает). Подключаю осциллограф (потребовалось 4 канала), и вижу, что я передаю один байт, а на выходе почему то передается 11 (!) бит clock, то есть некратное байту количество бит, да еще прерывание о завершении операции выдается заранее, чего быть не должно.
К этому моменту появляется ощущение, что виноват следующий уровень абстракции — аппаратная реализация SPI внутри процессора. Смотрим hardware errata, и о чудо!

nRF52832 Rev 2 Errata v1.1
3.9 [58] SPIM: An additional byte is clocked out when RXD.MAXCNT = 1
This anomaly applies to IC Rev. Rev 2, build codes QFAA-E00, CIAA-E00, QFAB-E00. It was inherited from the previous IC revision Rev 1.
Symptoms: SPIM clocks out additional byte.
Conditions: RXD.MAXCNT = 1; TXD.MAXCNT <= 1.
Consequences: Additional byte is redundant.

Workaround не описан, но ключевое слово SPIM подсказывает, что проблема в передаче по DMA. Выключаем DMA (благо он для этого изделия не обязателен), SPI начинает работать корректно.

То есть для понимания и исправления проблемы мне потребовалось спуститься от уровня функции на Си до аппаратуры процессора.

Kotarofuma
01.03.2019 12:49
#19823644
+1
Лично я не вижу в абстрагировании ничего плохого и сейчас объясню почему.

Программист, как сказано в статье, на данный момент является интерпретатором (прослойкой, если хотите) между бизнесом и машиной. В бОльшем количестве ситуаций, работа сводится к решению определенной бизнес проблемы. Да, большую часть проблем (если не все пожалуй) можно решить низкоуровневыми языками. Но если вам нужно перевезти тонну песка из пункта А в пункт Б, сомнительно что вы будете использовать телегу с конём (условно), а не самосвал.
Тоже самое и тут: зачем писать 1000 строчек кода, если определенный язык, может решить эту задачу за 10 строк?

Пожалуй единственный вопрос тут возникает в используемых ресурсах, а точнее в их ограничении. Если мы ограниченны ресурсом, то тогда лучше спускаться на более низкие уровни абстракции и писать максимально оптимизированный код. Но опять же, в общем случае это касается гигантских проектов, для которых крайне важна маштабируемость.

Как итог: не вижу на самом деле ничего критичного в новых языках. Просто их действительно нужно изучать с пониманием работы на более низких уровнях.
1. mkovalevskyi
  02.03.2019 01:36
  #19827150
  на данный момент является интерпретатором (прослойкой, если хотите) между бизнесом и машиной
  
  Только ооочень не каждый это может делать. У большенства подход четок и понятен — мне так сказали, я так задевелопил, а думать что я творю — мне этого не сказали, и это блин печально.
  
  Из недавнего на эту тему — сказали добавить столбик в репорте — добавили. А то, что теперь в репорте два одинаковых столбца — ну наверное так было надо. Ну как так-то?..

SvyatoslavS
01.03.2019 13:24
#19823856
Мне кажется, Вы взяли факты, опыт и сделали прямо противоположный логике вывод: проблема не в абстракциях, а в слишком большом количестве различающихся реализаций! Язык (и обычный и программный) в идеале должен быть один, но максимально абстрагированный от реализации, потому, в что в жизни нам важен результат, а не подкапотные механизмы :)

munx
01.03.2019 14:20
#19824184
Именно в разделении труда состоит сила человечества (привет, Адам Смит)!
Мы все существуем в рынке, и рассуждать нужно рыночными терминами.
Главный стимул появления новых ЯПов это увеличение скорости разработки. Стоимость ПО складывается главным образом из недешёвого рабочего времени разработчика.
Меньше времени потратили на разработку, значит получили конкурентное преимущество.

Великолепная лекция Боба Мартина на тему эволюции разработки ПО (от Тьюринга до Java и Agile):
Miron
01.03.2019 21:53
#19826530
Я думаю, что вы слишком смело обобщаете:

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

khanid
01.03.2019 15:22
#19824658
Я не вижу ничего плохого в абстракция и уходах на уровни выше. Задача программиста, всё же, логику реализовать, а не перекладывание по регистрам как самоцель.
Проблема в другом.
Первое.Не существует культуры решения проблем, если эти проблемы возникают уровнями ниже. Если есть проблема безопасности или просто баги, то это просто может приводить к обружению всего, что человек надстроил выше. И если с багами в части функциональности и работоспособности ещё как-то мирятся, то с багами в безопасности забивают до тех пор, пока где-то не прорвёт.
Второе. Оверхэд. Дикий оверхэд. Когда привыкли просто палить из пушки по воробьям, причём из многоствольной пушки, потому что автор пушки решил, что вместо трёх пушек для разных областей лучше сделать одну. И не удобную, а просто со спаянными тремя стволами вместе. Вдруг когда-то кому-то понадобится использовать сразу две. В итоге имеем громоздкое нечто. Хороший пример — современный веб. Местами крутой, но совершенно прожорливый на ровном месте.

maydjin
01.03.2019 15:22
#19824660
Прочитал как Филл — отпустись.

tikhenko
01.03.2019 15:48
#19824834
-1
Программистами станут лощеные гуманитарии

Уже так. Телефон — потому что розовенький, ноутбук — потому что белый, язык программирования — потому что без скобок. Разве инженер так делает?
Сишечка будет всегда, Паскаль тоже. А мэйнстрим будет сходить с ума и дальше.
1. FForth
  02.03.2019 20:19
  #19829276
  Про язык без скобок — порадовало, да и белый дизайн буков вполне неплохо выглядит, особенно клавиатуры.

tnsaturday
01.03.2019 16:41
#19825120
+1
Новые языки программирования незаметно убивают нашу связь с реальностью

Ну так программируйте на перфокартах, пока не связь с реальностью не оборвалась. А еще лучше как на Альтаире рубильниками переключать.

iamsilent
01.03.2019 19:05
#19825868
+2
Надо сказать, ваш друг написал отличный рассказ, так ему и передайте

Desiderio
01.03.2019 19:53
#19826070
до этого дня, как до Аляски на упряжке

Но кто-то считает, что это произойдёт быстрее (Slack из 50 строк кода, поисковик из 75 строк, фейсбук из 150 строк — как Вам такое?).
1. tnsaturday
  01.03.2019 20:15
  #19826158
  Slack из 50 строк кода, поисковик из 75 строк, фейсбук из 150 строк — как Вам такое?
  
  Можно посмотреть?
  1. schrodenkatzen
    01.03.2019 20:52
    #19826314
    Да нефиг) Какое-нибудь автоматизированное развертывание вордпресса и подобных проектов

edvorg
01.03.2019 21:32
#19826444
Если бы человечество следовало вашей логике о ненужности высокоуровневых языковых конструкций, мы бы сейчас все еще на стенах в пещерах рисовали а не на хабре сидели.

leossnet
01.03.2019 21:38
#19826472
Проблема в не языках программирования и уровнях абстракций. Главная проблема каждого человека заключается в способности осознавать свои собственные желания и умении четко формулировать их окружающим людям.

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

В конечном же итоге на просьбу управляющего ПИСЬМЕННО сформулировать в произвольном виде критерии оценки качества мытья пола, чтобы технички самостоятельно контролировать качество своей работы, был получен ответ, что ему проще самому мыть пол, чем сформулировать требования к качеству мытья этого пола.

Возвращаясь же к программированию могу лишь сказать, что для меня чрезмерное усложнение выполняемой работы либо желание использовать разные новомодные штуки означает всего лишь низкий уровень квалификации исполнителя, чаще всего сопровождаемый избыточным самомнением.
1. mkovalevskyi
  01.03.2019 23:05
  #19826744
  Главная проблема каждого человека заключается в способности осознавать свои собственные желания и умении четко формулировать их окружающим людям.
  
  Скорее в не способности )
  Но, именно эту проблему, теоретически, решают всяческие психологи, коучи, корректоры и прочие красивые слова. А вот как они ее решают — это уже другая печальная история…

Praksitel
02.03.2019 01:19
#19827116
Лет 20 назад я понял, что любой компьютер занят только одним — обработкой данных. Любой ЯП — средство для обработки данных. Не нужно вообще думать о языках, нужно думать о данных.
1. OldPrg
  02.03.2019 01:53
  #19827182
  30 лет назад я понял, что ЯП, СУБД и прочая хрень — это отличный источник растущего дохода, если с помощью них быстро можно выразить мысль заказчика. А это: короткий код/процесс кодирования, шустрая БД и (!!!) умение быстро разобраться в ТЗ «качелей» заказчика и грамотно раскидать работу между коллегами. ЯП выбирался один для всех за исключение системных вещей и на длительный срок.
  Все оказалось элементарно просто.
  И сейчас так. Ничего не меняется. Раньше кларионщики, сегодня, к примеру, пхпшники.
  Уже в конце 80х с приходом персиков работали так, как сейчас называют эджайл — на коленях у заказчика. До нас, со второй половины 70х — то, что назвали потом скрамом. 1 во 1. Меня учили этой организации разработки: еженедельные и экспресс-собрания, плакаты-доклады (!), гантирование и др.нормальная для большого проекта обсуждаловка-распределялка-итогосчиталка.

diafour
02.03.2019 01:38
#19827160
Фам Нювен несколько лет провел, обучаясь программировать и исследовать.
Программирование восходило к началу времен. Как та навозная куча за замком
отца. Когда ее промыло ручьем на десять метров вглубь, обнаружились
искореженные корпуса машин — летающих машин, как говорили крестьяне, еще от
тех великих дней колонизации Канберры. Но та навозная куча была чистой и
свежей по сравнению с тем, что лежало в локальной сети "Репризы". Были
программы, написанные пять тысяч лет назад, когда человечество еще не
покинуло Землю. И самое чудесное (самое ужасное, как говорила Сура) было то,
что, в отличие от бесполезных обломков прошлого Канберры, эти программы все
еще работали! И через миллион миллионов запутанных нитей наследования многие
из старейших программ все еще выполнялись во внутренностях системы Кенг Хо.
Например, методы слежения за временем у торговцев. Поправки вносились
неимоверно сложно — но на самом дне лежала крошечная программа, которая
гоняла счетчик. Секунду за секундой отсчитывала система Кенг Хо с того
момента, как нога человека ступила на Луну Старой Земли. Но если
приглядеться еще пристальнее… начальный момент был миллионов на сотню
секунд позже; момент "ноль" одной из первых компьютерных операционных систем
Человечества.
Значит, под всеми интерфейсами верхнего уровня лежат уровни поддержки,
слой на слое. Какая-то часть этих программ была создана для совершенно иных
ситуаций. То и дело несоответствие рождало фатальные инциденты. Вопреки всей
романтике космических полетов, чаще всего катастрофы вызывались древними
забытыми программами, которым удавалось взять реванш.

Вернор Виндж. «Глубина в небе»

OldPrg
02.03.2019 02:22
#19827234
Интересная тема со второй половины скамейки пошла в депрессивном направлении. Много дряни НЕпрогерской глазоушами жуют, потом здесь хороу устраивают — апокалипсисы, нло и розетка без вилки (самое ужасное).
ЯП — это язык программирования (для тех кто снизу читает коменты).

hopicowuda
02.03.2019 04:53
#19827372
+1
Подскажете ли, какой шрифт и IDE используются в вставках этого поста?
1. fillpackart Автор
  02.03.2019 04:55
  #19827374
  Тут мы имеем дело с VSCode, цветовые схемы из расширения daylerees.rainglow, шрифт — firaCode.
  1. hopicowuda
    02.03.2019 22:36
    #19829612
    +1
    Спасибо за ответ, не уж то шрифт и цветовая схема понравились :)

YemSalat
02.03.2019 06:18
#19827422
Может вам просто квалификацию поменять, стать каким-нибудь kernel программистом, или например, в геймдев податься. Там все куда ближе к железу.
Нечего удивляться, что когда решаешь бизнес задачи нa платфгормах для решения бизнес задач — то уклон будет в бизнес логику, а не в то что под капотом.

Jenyay
02.03.2019 11:26
#19828036
Меня в этом плане особенно пугает Web и настольные приложения, построенные поверх него (aka Electron). Количество слове абстракции зашкаливает. Например, Typescript -> JavaScript -> HTML -> браузер -> нативный код.
1. JustDont
  02.03.2019 13:29
  #19828286
  Лихо вы нарисовали JS над HTML.
  Это на самом деле совсем не так.
  
  Тайпскрипт улетает еще до рантайма.
  
  Остаётся всё то же, что и во всех других браузерах, только упакованное одним локальным куском. Ничего особо страшного.

disputant
02.03.2019 14:11
#19828358
Есть у меня один знакомый, который все время доказывает, что все, кроме ассемблера — полный отстой, и что весь софт должен писаться только на ассемблере… Сам он работает в несколько другой области, сисадминит помаленьку…
Как-то попалась маленькая задачка на ruSO -надо было биты поковырять. Попросил его написать на ассемблере. Результат был забавный — во-первых, он написал раза с шестого, все время что-то не так шло. Во-вторых его код оказался раза в полтора медленнее, чем тот же алгоритм, скомпилированный с С. В-третьих, решение на ruSO на C обставило оба эти решения раза в 3-4.

Так ли уж это плохо — отдавать взаимодействие с железом — железу? Которое справится с этим лучше? Почему обязательно уход от непосредственной работы с железом должен вести к "какое все громоздкое, неправильное и неповоротливое"?
1. OldPrg
  03.03.2019 00:05
  #19829864
  Некоторые мнят из себя асматиков, но настоящие, хотя бы «3 сорт — то же не брак», редкость.
  Они кучкуются в странах, где производство с применением микропроцессоров развито и по дефолту в США. У нас в ВПК, производственных корпорациях, инфобезики. Редкая специализация, требующая значительных знаний в области электроники.

litwr2
02.03.2019 14:41
#19828408
Неновые языки тоже иногда задают очень непростую связь с peaльнocтью. Например, на языке APL согласно википедии всего в одну строчку можно напиcать игpу Жизнь Kонвeя — life<{^1 ??.?3 4=+/,?1 0 1?.??1 0 1?.???} — нечто.
Язык TeX, будучи универсальным, порождает весьма интересные кoды даже для самых простых задач, например, расчета чисел Фибоначчи.

zim32
02.03.2019 17:04
#19828780
Будущее уже тут
https://internetua.com/iskusstvennyi-intellekt-uskorit-razrabotku-prilojenii-v-1000-raz
1. OldPrg
  03.03.2019 00:10
  #19829874
  И здесь ;)
  www.vedomosti.ru/finance/news/2019/02/26/795134-gref