Когда у тебя есть хоть какой-то капитал, то и приумножить его проще, чем если ты начинаешь с полного нуля.
Верно, но капитал этот, тем не менее, тоже когда-то появился у своего держателя.
Допустим кому-то дали денег родители, а откуда они взяли эти деньги? Предположим, что им дали их родители, а тем? В итоге, все-таки, в самом начале кто-то именно с полного нуля и начинал, при этом сумел не растратить заработанное и передал потомкам.
ездить надо не только по крупным федеральным трассам и в городах где дорожная сеть полностью оцифрована
Каждому свое, как говорится. Несмотря на то, что существуют экскаваторы, лопаты все еде продаются и используются.
Тут ситуация схожая - если работы для экскаватора, сиречь автономного грузовика, нет, то тогда копают лопатой (едет живой водитель на обычном транспорте).
В Википедии есть, на мой взгляд, довольно логичная гипотеза, объясняющая "серединность" среды:
Существует предположение, что у предков восточных славян вся неделя состояла из пяти дней, и среда была её серединой. И лишь позднее у евреев через греков они заимствовали субботу, а с распространением христианства в их языке появилось и воскресенье.
В статье верно подчеркивается, что техническая сторона дела важна.
Однако я полагаю, что все же бОльшую роль в популярности видеохостингов и онлайн кинотеатров имеет библиотека контента - качественного и востребованного у пользователей. Если супер технологичный сервис не может заинтересовать покупателей тем, что предлагает - вряд ли техническое совершенство ему поможет всех победить.
Вывод, к которому это меня привело, таков: 1) всем нужно полностью ориентироваться на единую ОС, отринуть всякие конкуренции и прочие уводы внимания, времени и усилий в ненужное русло
Вроде бы я и не настаивал, что числа должны быть абстрактно-универсальными.
Я как раз за то, чтобы не забывать, глядя на небоскребы, что в основе все-таки конкретные сталь и бетон, а не некий универсальный "строительный материал" знания о котором строителям этих небоскребов не важны.
От языка требуется возможность определять свои domain-specific абстракции
Вроде бы никто и не мешает определять. Просто не на уровне самого языка, а пользуясь им. На то это и язык.
а не спотыкаться постоянно о встроенные машино-специфичные типы.
Не могу припомнить языки явно страдающие от поддержки встроенных типов. Но может такие и есть, просто я не в курсе.
Если работаешь с цветами, то практичнее определить тип Color с нужным набором операций, оставив нюансы низкоуровневого представления за кадром.
На мой взгляд "работа с цветом", "работа с документами", "работа с авиабилетами" это не задача языка. Это задачи конкретных библиотек/фреймворков.
Например, есть задача "описать вкус кофе".
На русском языке можно миллионом разных способов описать вкус кофе, который вы выпили на завтрак.
Сам язык при этом не имеет средств для истинной передачи вкуса, чтобы читатель ощутил ровно то же, что и вы.
Однако это не мешает пользоваться языком для описания вкуса, причем так, что читатель поймет что же писатель хотел до него донести.
Так же и на языках программирования высокого уровня можно описать нужные алгоритмы и при этом не требуется, чтобы язык поддерживал именно этот конкретный алгоритм или именно под него был разработан.
Все это может и должно жить в библиотеке.
Предметные домены, предметные же типы данных и связанные со всем этим абстрации должны жить в библиотеках, соглашусь.
Возможно, кстати, что вы видите какую-то принципиальную проблему в языках с определенными типами, но от меня эта проблема как-то ускользает.
Это была попытка донести аргумент, что в итоге программы выполняются не в мире концепций, а на реальном железе, у которого есть железные же ограничения.
Работать с числами в строковом представлении можно, но для процессора придется все-таки их переводить в те представления чисел, которые поддерживаются в архитектуре вычислений этого процессора.
И все это придется делать за счет дополнительных приседаний, которых можно попытаться избежать, если в языке есть типы данных, нативные для оборудования.
Но выполнять этот код вряд ли будет человек, все-таки.
Чтобы тот мог понять, что за магия тут происходит.
Если ИИ ассистент сам написал код, сам его запустил и сам обработал результат, то получается, что вообще нет человека, для которого этот код был написан с замыслом "чтобы человек мог понять".
А код, который "для человека", есть. Странно.
Для машины есть ассемблер.
А есть люди, кто пишут код на ассемблере. И тут непонятно, получается, для кого они пишут.
Можно, конечно, сделать числа в языке только одного типа, условно, хранить как строки произвольной длины. И использовать длинную арифметику для работы с ними. Со всем сопутствующим оверхедом.
Насколько программы замедлятся из-за этого - неясно. Полагаю что существенно.
Это, конечно, не CLI в консоли, но в MS Outlook проблема управления подсказками ввода адресов в поле "Кому" решалась довольно интуитивно: пользователь мог не выбирать подсказку из всплывающего списка, а начать нажимать стрелки вверх/вниз и происходило перемещение по списку подсказок. Как в меню обычном. А выбрав ненужную подсказку можно было нажать DEL и удалить ее из этого списка навсегда.
Чтобы послушать какой-то трек в любимом проигрывателе
Эх, любимый проигрыватель... Любимый проигрыватель, так-то, тоже может иметь ограничения. Может не читать файлы с именами, содержащими символы отличными от какого-то ограниченного набора. Может не позволять путешествовать по папкам вообще или только до какого-то уровня вложенности, т.к. иначе получается слишком длинный путь, а разработчики переменную ограничили в длине...
По идее почти все современные проигрыватели умеют работать с m3u. Можно метаданные треков в нем вести, тогда и отдельного приложения не понадобится.
А сами директории и файлы Вы бы предложили называть по какому принципу?
Если вся информация содержится в метаданных и существует удобный UI для работы с метаданными, то папки и файлы можно называть рандомными uuid. Правда придется всегда только через этот UI работать.
Так и с задачами: насмотренность интервьюеров, стабильность путей решения задачи, хорошая скоррелированность оценок задачи с реальным уровнем навыка бывают важнее того, насколько задача реальна.
Интервьюеры через полгода-год берут на себя труд сходить к коллегам нанятого сотрудника и узнать его реальный уровень, потом сопоставляют его с уровнями решения своих задач и затем задачи корректируют опираясь на факты, а не на "мне так кажется"? Респект.
3ds должен поддерживать банк эмитент карты. Если эмитент протокол не поддерживает, то от эквайера ничего не зависит. Нажав я "оплатить со скидкой", банк Б пойдет в платежную систему за платежом с 3ds, система пойдет в банк В, выпустивший мою карту и увидит, что 3ds не поддерживается, после чего произойдет оплата по сценарию без 3ds.
Верно, но капитал этот, тем не менее, тоже когда-то появился у своего держателя.
Допустим кому-то дали денег родители, а откуда они взяли эти деньги? Предположим, что им дали их родители, а тем? В итоге, все-таки, в самом начале кто-то именно с полного нуля и начинал, при этом сумел не растратить заработанное и передал потомкам.
Людей одна-то воздуходувка раздражает, а тут тише чем 2-3.
Каждому свое, как говорится. Несмотря на то, что существуют экскаваторы, лопаты все еде продаются и используются.
Тут ситуация схожая - если работы для экскаватора, сиречь автономного грузовика, нет, то тогда копают лопатой (едет живой водитель на обычном транспорте).
Предлагаю вам самому посмотреть.
https://ru.wikipedia.org/wiki/Среда
В Википедии есть, на мой взгляд, довольно логичная гипотеза, объясняющая "серединность" среды:
В статье верно подчеркивается, что техническая сторона дела важна.
Однако я полагаю, что все же бОльшую роль в популярности видеохостингов и онлайн кинотеатров имеет библиотека контента - качественного и востребованного у пользователей. Если супер технологичный сервис не может заинтересовать покупателей тем, что предлагает - вряд ли техническое совершенство ему поможет всех победить.
Всем это всему миру или вы про РФ?
Вроде бы я и не настаивал, что числа должны быть абстрактно-универсальными.
Я как раз за то, чтобы не забывать, глядя на небоскребы, что в основе все-таки конкретные сталь и бетон, а не некий универсальный "строительный материал" знания о котором строителям этих небоскребов не важны.
Вроде бы никто и не мешает определять. Просто не на уровне самого языка, а пользуясь им. На то это и язык.
Не могу припомнить языки явно страдающие от поддержки встроенных типов. Но может такие и есть, просто я не в курсе.
На мой взгляд "работа с цветом", "работа с документами", "работа с авиабилетами" это не задача языка. Это задачи конкретных библиотек/фреймворков.
Например, есть задача "описать вкус кофе".
На русском языке можно миллионом разных способов описать вкус кофе, который вы выпили на завтрак.
Сам язык при этом не имеет средств для истинной передачи вкуса, чтобы читатель ощутил ровно то же, что и вы.
Однако это не мешает пользоваться языком для описания вкуса, причем так, что читатель поймет что же писатель хотел до него донести.
Так же и на языках программирования высокого уровня можно описать нужные алгоритмы и при этом не требуется, чтобы язык поддерживал именно этот конкретный алгоритм или именно под него был разработан.
Предметные домены, предметные же типы данных и связанные со всем этим абстрации должны жить в библиотеках, соглашусь.
Возможно, кстати, что вы видите какую-то принципиальную проблему в языках с определенными типами, но от меня эта проблема как-то ускользает.
Абсолютно верно. Неважно на чем написан код.
Важно что код этот: а) есть, б) человек его читать не будет.
И поэтому утверждение, что "код для человека пишется" не всегда истинно, т.к. в данном случае нет этого самого человека.
Это была попытка донести аргумент, что в итоге программы выполняются не в мире концепций, а на реальном железе, у которого есть железные же ограничения.
Работать с числами в строковом представлении можно, но для процессора придется все-таки их переводить в те представления чисел, которые поддерживаются в архитектуре вычислений этого процессора.
И все это придется делать за счет дополнительных приседаний, которых можно попытаться избежать, если в языке есть типы данных, нативные для оборудования.
Но выполнять этот код вряд ли будет человек, все-таки.
Если ИИ ассистент сам написал код, сам его запустил и сам обработал результат, то получается, что вообще нет человека, для которого этот код был написан с замыслом "чтобы человек мог понять".
А код, который "для человека", есть. Странно.
А есть люди, кто пишут код на ассемблере. И тут непонятно, получается, для кого они пишут.
Э... А для кого тогда пишется код, если не для машины?
Можно, конечно, сделать числа в языке только одного типа, условно, хранить как строки произвольной длины. И использовать длинную арифметику для работы с ними. Со всем сопутствующим оверхедом.
Насколько программы замедлятся из-за этого - неясно. Полагаю что существенно.
Этак гантелей не напасёсси на вас...
Это, конечно, не CLI в консоли, но в MS Outlook проблема управления подсказками ввода адресов в поле "Кому" решалась довольно интуитивно: пользователь мог не выбирать подсказку из всплывающего списка, а начать нажимать стрелки вверх/вниз и происходило перемещение по списку подсказок. Как в меню обычном. А выбрав ненужную подсказку можно было нажать DEL и удалить ее из этого списка навсегда.
Эх, любимый проигрыватель... Любимый проигрыватель, так-то, тоже может иметь ограничения. Может не читать файлы с именами, содержащими символы отличными от какого-то ограниченного набора. Может не позволять путешествовать по папкам вообще или только до какого-то уровня вложенности, т.к. иначе получается слишком длинный путь, а разработчики переменную ограничили в длине...
По идее почти все современные проигрыватели умеют работать с m3u. Можно метаданные треков в нем вести, тогда и отдельного приложения не понадобится.
Если вся информация содержится в метаданных и существует удобный UI для работы с метаданными, то папки и файлы можно называть рандомными uuid. Правда придется всегда только через этот UI работать.
"Последние 12 лет летаю на Airbus" - не вижу неоднозначности в этой фразе.
Интервьюеры через полгода-год берут на себя труд сходить к коллегам нанятого сотрудника и узнать его реальный уровень, потом сопоставляют его с уровнями решения своих задач и затем задачи корректируют опираясь на факты, а не на "мне так кажется"? Респект.
3ds должен поддерживать банк эмитент карты. Если эмитент протокол не поддерживает, то от эквайера ничего не зависит. Нажав я "оплатить со скидкой", банк Б пойдет в платежную систему за платежом с 3ds, система пойдет в банк В, выпустивший мою карту и увидит, что 3ds не поддерживается, после чего произойдет оплата по сценарию без 3ds.