Речь о более общем контроле, на данном историческом этапе компьютер не может задизайнить (разработать, создать, довести до необходимого состояния, короче) программу по ТЗ самолично, без участия программиста.
Поэтому возможности «исполнителя» (компьютера) на первом этапе ограничены возможностями IDE, которую можно дополнить пользовательским кодом в виде плагинов. Как раз этот код подлежит исполнению в design-time.
Например, сгенерированный по WSDL-описанию java-класс будет слегка бесчеловечным, что определит дальнейшую работу с этим классом, а значит, повлияет на программу в целом.
Вот, пишут выше, что процессы не налажены — значит, сам разработчик подошёл к делу чисто формально, за зарплату и по должностным обязанностям (откуда такая незаинтересованность, ведь не в РосКосмосе работает).
Или вот вы пишете, что виноваты датчики — как будто в космосе принято доверять многомесячную миссию единственному датчику. Полетели на авось, допустим, но это значит, что софт даже не пытались затачивать под ситуацию «авось».
Руководители, конечно, своё получат, да и датчик обвинить проще всего. Но получается, что современное computer science просто не сильно готово к ответственности. И это не только в космосе, до сих пор не каждый крудошлёп знает, что нельзя доверять данным от пользователя, и нет факторов, которые бы удержали его от ошибки.
Считайте, что Лурк сначала заминусовали ниже днища, а потом он сбросил карму, но стал осторожнее, ведь надо следить за языком, а второй попытки никому не дано.
В целом, ваша догадка неверна, я никак не связан ни с одной религией, что помогает мне вполне рационально оценить содержимое этой статьи и комментариев. По сути точно понятно, а по форме «понятно», что эта статья оскорбляет самого космонавта (но это не предмет для 282), оскорбляет космонавта как представителя православия (282.1) и возлагает на космонавта коллективную ответственность за все недостатки всех православных (как антисемитизм), а затем сомневается в пригодности православных людей для деятельности в космосе (282.1). Опубликовано в публичном ресурсе лидером мнений (блогером lozga, карма овер 500), стиль — публицистика, научным исследованием не является, художественным произведением не является. Все основания чтобы проверить статью на предмет разжигания уже с привлечением власти.
Но вы продолжайте меня минусовать, может, так вам полегчает.
1. Действия, направленные на возбуждение ненависти либо вражды, а также на унижение достоинства человека либо группы лиц по признакам пола, расы, национальности, языка, происхождения, отношения к религии, а равно принадлежности к какой-либо социальной группе, совершенные публично или с использованием средств массовой информации либо информационно-телекоммуникационных сетей, в том числе сети «Интернет», наказываются штрафом в размере от трехсот тысяч до пятисот тысяч рублей или в размере заработной платы или иного дохода осужденного за период от двух до трех лет, либо принудительными работами на срок от одного года до четырех лет с лишением права занимать определенные должности или заниматься определенной деятельностью на срок до трех лет, либо лишением свободы на срок от двух до пяти лет.
2. Те же деяния, совершенные:
а) с применением насилия или с угрозой его применения;
б) лицом с использованием своего служебного положения;
в) организованной группой, — наказываются штрафом в размере от трехсот тысяч до шестисот тысяч рублей или в размере заработной платы или иного дохода осужденного за период от двух до трех лет, либо принудительными работами на срок от двух до пяти лет с лишением права занимать определенные должности или заниматься определенной деятельностью на срок до трех лет, либо лишением свободы на срок от трех до шести лет.
Прекращайте разжигать ненависть и унижать достоинство, ув. lozga, к Этим Русским https://www.instagram.com/p/BLwcT3Zl2yg/
Нужно быть очень умным и сильным программистом, чтобы хорошо знать javascript.
javascript это язык для браузеров, которые у миллиардов людей.
Миллиарды людей могут принести деньги бизнесу.
Очень умные и сильные программисты получают много денег за свой скилл.
Всё равно бизнесу хорошо, поэтому система живёт дальше.
Вы приводите пример, в котором файлы не используются, а потом спрашиваете, что изменится когда файлы исчезнут. Ответ: в данном примере ничего не изменится.
Кажется, это вы суть не улавливаете, не первый раз уже. Почитайте про файлы, потом про ООП (например), потом про API работы с файлами в том же юниксе. Потом поговорим, а то воинствующее профанство, поощряемое плюсами уже давно надоело.
Тут ещё можно порассуждать, к чему более удобно применять понятие версионности, к объектам или к их сериализованным проекциям. Мета-информация, полиморфизм, иммутабельность, связка понятий, которая давно присутствует в программах и присуща объектам далеко не полностью возможна даже в современных ФС.
Короче, всё что я хочу сказать, появление в ИТ понятия «файл» тащит за собой целый куст последствий, которые как бы есть, и все привыкли, и все знают, а то, что известно, как правило, никто не хочет понимать. И так известно, чего там копаться, воду лить. И так сойдёт.
Это ещё мало, всего один комментарий. Я думаю, аккуратный разбор популярных определений слова «файл» займёт не одну статью.
> мы опять же возвращаемся к концепции «файлов»
В случае с сокетом, скорее, поток. Да почти всегда это будет поток данных. Я не зря упомянул связистов, кстати. Ну, разве что мы повезём грузовик жёстких дисков, да и то, все они могут хранить непосредственно дамп памяти, вместе со снэпшотами софта и прочего.
В любом случае, если мы хотим подвести некое обобщённое понятие под всё это, то понятие объекта подходит лучше хотя бы в силу большего количества охватываемой реальности и оторванности от исторического понятия «файл».
*nix-экосистеме в случае сдвига парадигмы придётся тяжелее всего, наверное.
Можно объяснить это так: файл, как концепция, был введён для того, чтобы хранить, идентифицировать и передавать куски данных в энергонезависимой памяти. Почему назвали «файл» есть много легенд, мне кажется, наиболее верно объясняет ситуацию легенда про картотеку перфокарт, которые были сгруппированы по папкам, то, что сейчас офисные работники называют «файл для бумаг».
Так вот, если разобраться, что такое файл, окажется, что изначально это прямая копия куска (блока) энергозависимой памяти. Если представить, зачем это было нужно, можно понять, что блоки содержали осмысленную информацию, в общем случае, эта информация представляла собой данные, понятные программам. Непосредственные данные, которые обрабатывал процессор в памяти, грузил в регистры и так далее. В общем-то, если посмотреть на файл подкачки, можно понять, чем были файлы изначально.
Сначала это были байты, потом группы байт — числа, потом цепочки чисел, и наконец группы чисел и не чисел, объединенные смыслом. Если посмотреть с современной точки зрения — это и были объекты, структуры, массивы, ссылки, в общем случае, программные объекты, с которыми работает пользовательский код.
Недавно была статья про первый форматы MS Office, так там писали, что по сути файлы .doc это дампы сишных структур, копия информации из рантайма.
Так вот теперь представим, что память в 21-м веке наконец-то стала вся быстрая и энергонезависимая. Сама концепция файлов просто теряет смысл. Объекты в памяти остаются объектами в памяти. Не исчезают, пока пользователь их не удалит или сборщик мусора не вычистит. То есть, функция хранения реализована без файлов.
Функция идентификации так же может быть реализована без понятия файлов, ведь в первую очередь, мы идентифицируем объекты, для них даже есть понятие identity, по содержимому или по идентификатору, или по адресу. А то, что все привыкли называть «файловой системой» на деле является способом адресации в древовидной структуре. Не самой совершенной, кстати. XPath тоже такую функцию выполняет, например. А ведь есть и совсем иные альтернативы, типа системы тэгов.
Остаётся третья функция: передача. Конечно, логично передавать объекты в сериализованном виде (проблемы у этого способа были с самого начала), или в виде дампа памяти, как делали MS. Но сейчас есть много путей передачи содержимого не в виде файлов. Фактически, любая передача данных, как могут рассказать связисты, не основывается на общепринятом понятии файла, тут возможно подходит слово «сообщение», так как помимо пользовательских данных, то есть того, что все называют файлом, есть метаинформация о данных, информация о канале данных, специфичное потоковое разбиение данных.
В целом, вот основные доводы в пользу отказа от понятия файла вместе с отказом от концепции носителей данных, которая и привела к появлению понятия файла.
Кстати, сеть IPFS, с которой мне довелось поработать <https://habrahabr.ru/post/310554/>, тоже изначально никак не связана с понятием файла, оно было введено позже, и, на мой взгляд, в результате получился аналог object-relational impedance mismatch, но уже для объектов/блоков и «файлов». Но люди привыкли к файлам, это надо признать
Поэтому возможности «исполнителя» (компьютера) на первом этапе ограничены возможностями IDE, которую можно дополнить пользовательским кодом в виде плагинов. Как раз этот код подлежит исполнению в design-time.
Например, сгенерированный по WSDL-описанию java-класс будет слегка бесчеловечным, что определит дальнейшую работу с этим классом, а значит, повлияет на программу в целом.
Или вот вы пишете, что виноваты датчики — как будто в космосе принято доверять многомесячную миссию единственному датчику. Полетели на авось, допустим, но это значит, что софт даже не пытались затачивать под ситуацию «авось».
Руководители, конечно, своё получат, да и датчик обвинить проще всего. Но получается, что современное computer science просто не сильно готово к ответственности. И это не только в космосе, до сих пор не каждый крудошлёп знает, что нельзя доверять данным от пользователя, и нет факторов, которые бы удержали его от ошибки.
Грустно всё это.
Возможно, ему будет немного стыдно.
Но вы продолжайте меня минусовать, может, так вам полегчает.
А вы умело перешли на личности, почти как автор в статье.
2. Те же деяния, совершенные:
а) с применением насилия или с угрозой его применения;
б) лицом с использованием своего служебного положения;
в) организованной группой, — наказываются штрафом в размере от трехсот тысяч до шестисот тысяч рублей или в размере заработной платы или иного дохода осужденного за период от двух до трех лет, либо принудительными работами на срок от двух до пяти лет с лишением права занимать определенные должности или заниматься определенной деятельностью на срок до трех лет, либо лишением свободы на срок от трех до шести лет.
Прекращайте разжигать ненависть и унижать достоинство, ув. lozga, к Этим Русским https://www.instagram.com/p/BLwcT3Zl2yg/
javascript это язык для браузеров, которые у миллиардов людей.
Миллиарды людей могут принести деньги бизнесу.
Очень умные и сильные программисты получают много денег за свой скилл.
Всё равно бизнесу хорошо, поэтому система живёт дальше.
Кажется, это вы суть не улавливаете, не первый раз уже. Почитайте про файлы, потом про ООП (например), потом про API работы с файлами в том же юниксе. Потом поговорим, а то воинствующее профанство, поощряемое плюсами уже давно надоело.
Короче, всё что я хочу сказать, появление в ИТ понятия «файл» тащит за собой целый куст последствий, которые как бы есть, и все привыкли, и все знают, а то, что известно, как правило, никто не хочет понимать. И так известно, чего там копаться, воду лить. И так сойдёт.
Это ещё мало, всего один комментарий. Я думаю, аккуратный разбор популярных определений слова «файл» займёт не одну статью.
> мы опять же возвращаемся к концепции «файлов»
В случае с сокетом, скорее, поток. Да почти всегда это будет поток данных. Я не зря упомянул связистов, кстати. Ну, разве что мы повезём грузовик жёстких дисков, да и то, все они могут хранить непосредственно дамп памяти, вместе со снэпшотами софта и прочего.
В любом случае, если мы хотим подвести некое обобщённое понятие под всё это, то понятие объекта подходит лучше хотя бы в силу большего количества охватываемой реальности и оторванности от исторического понятия «файл».
*nix-экосистеме в случае сдвига парадигмы придётся тяжелее всего, наверное.
> Какое это имеет отношение к современным реалиям?
Байты из RAM до сих пор надо где-то хранить, пока электрики разруливают проблемы.
> Если постоянно хранимый контейнер с нужными данными и каким-то адресом для доступа/поиска — то это и есть файл.
Это и есть объект, а как организована коллекция объектов — дело десятое. Может, связный список, может, хэш-массив «мои документы».
Так вот, если разобраться, что такое файл, окажется, что изначально это прямая копия куска (блока) энергозависимой памяти. Если представить, зачем это было нужно, можно понять, что блоки содержали осмысленную информацию, в общем случае, эта информация представляла собой данные, понятные программам. Непосредственные данные, которые обрабатывал процессор в памяти, грузил в регистры и так далее. В общем-то, если посмотреть на файл подкачки, можно понять, чем были файлы изначально.
Сначала это были байты, потом группы байт — числа, потом цепочки чисел, и наконец группы чисел и не чисел, объединенные смыслом. Если посмотреть с современной точки зрения — это и были объекты, структуры, массивы, ссылки, в общем случае, программные объекты, с которыми работает пользовательский код.
Недавно была статья про первый форматы MS Office, так там писали, что по сути файлы .doc это дампы сишных структур, копия информации из рантайма.
Так вот теперь представим, что память в 21-м веке наконец-то стала вся быстрая и энергонезависимая. Сама концепция файлов просто теряет смысл. Объекты в памяти остаются объектами в памяти. Не исчезают, пока пользователь их не удалит или сборщик мусора не вычистит. То есть, функция хранения реализована без файлов.
Функция идентификации так же может быть реализована без понятия файлов, ведь в первую очередь, мы идентифицируем объекты, для них даже есть понятие identity, по содержимому или по идентификатору, или по адресу. А то, что все привыкли называть «файловой системой» на деле является способом адресации в древовидной структуре. Не самой совершенной, кстати. XPath тоже такую функцию выполняет, например. А ведь есть и совсем иные альтернативы, типа системы тэгов.
Остаётся третья функция: передача. Конечно, логично передавать объекты в сериализованном виде (проблемы у этого способа были с самого начала), или в виде дампа памяти, как делали MS. Но сейчас есть много путей передачи содержимого не в виде файлов. Фактически, любая передача данных, как могут рассказать связисты, не основывается на общепринятом понятии файла, тут возможно подходит слово «сообщение», так как помимо пользовательских данных, то есть того, что все называют файлом, есть метаинформация о данных, информация о канале данных, специфичное потоковое разбиение данных.
В целом, вот основные доводы в пользу отказа от понятия файла вместе с отказом от концепции носителей данных, которая и привела к появлению понятия файла.
Кстати, сеть IPFS, с которой мне довелось поработать <https://habrahabr.ru/post/310554/>, тоже изначально никак не связана с понятием файла, оно было введено позже, и, на мой взгляд, в результате получился аналог object-relational impedance mismatch, но уже для объектов/блоков и «файлов». Но люди привыкли к файлам, это надо признать