Реально цены выросли несильно, большой процент товаров - местные, в иенах. Кроме того, 10 лет назад иена аномально выросла после известного землетрясения/цунами. Так что да, живём :)
Ради бога. Если они вам мешают, и вы решите жить без денег, не навязывая эту систему остальным, не вижу проблем. На мой вкус "мир без денег" -- это не та цель, к которой хочется стремиться, но никому не навязываю :)
Если вы находитесь на необитаемом острове, то токены на руках у вас не являются деньгами, т.к. их ни при каком раскладе нельзя рассматривать мерой стоимости (с чего бы?)
В жизни вообще мало что является "критически важным", можно одной пшеницей питаться. Деньги являются полезным инструментом, и при этом если вам с соседом хочется заниматься бартером, вы в своём праве.
Если же вас смущает, что деньги могут "протухнуть" на необитаемом острове, ну что ж с того? Бананы тоже тухнут, железо ржавеет, люди болеют. У любого средства есть пределы применимости.
С этим можно поспорить, но ради бога. Исходный тезис в том, что по определению (см. хотя бы википедию) деньги -- это "всеобщий эквивалент, выступающий измерителем стоимости товаров или услуг, легко на них обменивающийся".
Соответственно, если вы утверждаете, что на деньги в ваших руках нельзя легко получить стройматериалы или топливо, то у вас по определению не деньги, вот и вся история.
Не, ну что, если у вас нету тёти, то вам её не потерять. Если в языке нет слов "вор", а также "автомобиль", "интернет" или "антибиотик" -- лучше в таких местах не жить, очевидно.
Это рассуждение на уровне анекдота выше. Если у вас есть "деньги", но вы не можете на них купить материалы и нанять людей, то это и не деньги вовсе, а не пойми что. Я тоже могу на принтере напечатать "деньги", а потом жаловаться, что мне за них ничего не продают.
Смысл денег ровно в том, что вы можете на них купить что вам нужно. А если не можете, то к деньгам содержимое вашего кармана имеет косвенное отношение. В своё время, если помните, люди довольно чётко проводили линию между "деревянными" рублями и "деньгами", то есть валютой. Вот это примерно о том.
Мне кажется, у вас какая-то нездоровая нелюбовь у этому нехитрому инструменту. Ну да, допустим, можно обойтись электронными взаимозачетами, где в системе будут исключительно бананы, стройматериалы и дрели, и у каждого на личном счёте будет указано, сколько он должен отработать за месяц, и сколько дрелей ему надо выдать. Но зачем? Эта задача прекрасно решается хоть деньгами, хоть ракушками, хоть золотыми слитками, и довольно странно выбрасывать рабочий инструмент на помойку.
Ну и анекдот выше относится к тому идиотскому типу юмора, когда автор по сути высмеивает сам себя. Инопланетянин должен вычеркнуть собеседника из списка разумных, очевидно.
Вот мне вот что удивительно читать. Вы в этой реплике и ниже столько раз упоминаете "нас", "мы" и так далее. Объясните, с чего мне отождествлять себя с руководством, проводящим текущую политику? Я за них не голосовал ни разу, моего мнения они не спрашивали. Более того, если вы посмотрите на поло-возрастно-бэкграундный состав хотя бы Совета безопасности, то увидите, что они крайне криво отражают население страны. По крайней мере, там нет людей моего возраста и похожего на моё образование. Они меня не представляют, и, соответственно, проводимая ими политика -- это их политика. "Нашей" (моей) тут даже близко нет. Нравится она или нет -- вопрос другой, но присоединять себя к этой компании довольно нелогично.
Судя по исходной статье -- для университета. Ну если студенту только тексты набирать и интернет читать, вполне норм, не все же программирование изучают.
Скорее нет, чем да. Логарифмическая линейка -- аналоговое устройство, а "аддиаторы" условно цифровые, дискретные, На мой взгляд, ближайшие родственники -- это, с одной стороны, счёты (абак, соробан), а с другой -- машины, в которых движущиеся рейки соединены с шестерёнками, напр., Comptator.
Да, тут масса тем. Касательно len(x) vs x.len() -- у меня был научрук, вот он любил подобные вопросы. Байт-код Java исполняет компилятор или интерпретатор? А если процессор реализует байткод нативно, т.е. байткод является его ассемблером?
Концептуально разницы между этими вызовами нет, но второй синтаксис недаром победил. Рано или поздно появляются случаи, когда приходится копаться в "кишках" объекта. Допустим, у нас len() определяется для C-строки, и тогда вычисление len() занимает O(N). Мы решаем кэшировать значение где-то в поле _lenCached, но если функция len() получает доступ к этому полю, то получают и все на свете, а для типа данных "строка" по идее операция доступа к такому полю не определена ("тип есть область значений + допустимые операции"). Тогда надо определять функцию len() как friend (в терминах C++), и в итоге приходим туда, откуда вышли -- есть функции-члены класса и "внешние".
Для меня ООП -- это прежде всего попытка моделирования мира в рамках классической модели Платона-Аристотеля-Линнея. У вещи есть "идеал" (платоновский эйдос), есть свойства сущностные и случайные (эссенция и акциденция по Аристотелю), есть иерархия типов по категориям рода и вида (Линней). Альтернативы на больших масштабах по сути нет, если только речь не идёт о моделировании процессов как таковых (и на этой базе основана библиотека C++ STL, например, но это именно что библиотека алгоритмов).
Что касается неоптимальности представления точек в виде объектов -- ну, да, есть такое. Наверно, если вы работаете с векторами, то объектом должен быть вектор, а не точка. Можно ещё сделать какой-то собственный "векторный" аллокатор памяти или ещё как-то решить этот вопрос "на другом этаже", но в целом, конечно, ООП про представление знаний, а не о том, как это представление хранить в последовательных ячейках памяти.
В некотором смысле тут нет противоречия. Если тип - это множество допустимых значений и операций над ними, то есть ли разница, писать o.f() или f(o)? Скажем, в Ada 95 поддерживается только второй синтаксис (при этом с динамической диспетчеризаций), и язык по мнению авторов вполне себе поддерживает ООП.
С тезисами согласен, но один момент заслуживает отдельного обсуждения. Аргумент по итогу сводится к тому, что Фортран, Кобол, ИИ недостаточно хороши, чтобы ими можно было пользоваться без "прокладки" в виде программиста. Однако это не объясняет почему идея аутсорса в условную Индию точно так же не выстрелила, хотя на другом конце тоже вполне себе программисты-люди, и среди них немало хороших.
Мне кажется, что и сейчас, и в обозримом будущем имеет смысл чётко разделять цели и средства. Средство я могу отдать на аутсорс, а цель нет. Если я пишу описание приложения для Гуглплея, цель -- оптимизация для поисковой машины, а текст лишь средство. Нетрудно убедиться, что такие тексты изобилуют к месту и не к месту вставленными ключевыми словами и вообще составлены для гуглоробота, а не для конечного пользователя. Такую работу совершенно спокойно можно аутсорсить Chat-GPT или исполнителю из Индии.
С другой стороны, мы имеем текст вроде этой статьи. Автору хочется поделиться именно своими мыслями (или написать софт, который он хочет написать), и в этом случае сама идея аутсорса звучит достаточно странно. Даже если речь идёт о простом приложении типа калькулятора, автор должен детально продумать и решить для себя, чем этот калькулятор отличается от любого другого, а это уже половина работы, если не больше.
Думаю, ваш пример не совсем релевантен, потому что исходный автор Qt приложения, вероятно, не мог предположить всех хотелок заказчика и бил наверняка, использовав заведомо достаточно мощный фреймворк. Вы уже знали, что конкретно требуется, и могли "срезать углы" без опаски.
Реально цены выросли несильно, большой процент товаров - местные, в иенах. Кроме того, 10 лет назад иена аномально выросла после известного землетрясения/цунами. Так что да, живём :)
Нюанс в том, что украинская армия очевидным образом воюет за интересы Украины. Армия РФ как бы формально "наша", но хз что за интересы она отстаивает.
А какая разница, если по гамбургскому счету?
Ради бога. Если они вам мешают, и вы решите жить без денег, не навязывая эту систему остальным, не вижу проблем. На мой вкус "мир без денег" -- это не та цель, к которой хочется стремиться, но никому не навязываю :)
Если вы находитесь на необитаемом острове, то токены на руках у вас не являются деньгами, т.к. их ни при каком раскладе нельзя рассматривать мерой стоимости (с чего бы?)
В жизни вообще мало что является "критически важным", можно одной пшеницей питаться. Деньги являются полезным инструментом, и при этом если вам с соседом хочется заниматься бартером, вы в своём праве.
Если же вас смущает, что деньги могут "протухнуть" на необитаемом острове, ну что ж с того? Бананы тоже тухнут, железо ржавеет, люди болеют. У любого средства есть пределы применимости.
С этим можно поспорить, но ради бога. Исходный тезис в том, что по определению (см. хотя бы википедию) деньги -- это "всеобщий эквивалент, выступающий измерителем стоимости товаров или услуг, легко на них обменивающийся".
Соответственно, если вы утверждаете, что на деньги в ваших руках нельзя легко получить стройматериалы или топливо, то у вас по определению не деньги, вот и вся история.
Не, ну что, если у вас нету тёти, то вам её не потерять. Если в языке нет слов "вор", а также "автомобиль", "интернет" или "антибиотик" -- лучше в таких местах не жить, очевидно.
Где связь? В кабалу люди попадали вот прямо с античности, а может, и в доисторические времена. Эта проблема с деньгами вообще никак не связана.
Это рассуждение на уровне анекдота выше. Если у вас есть "деньги", но вы не можете на них купить материалы и нанять людей, то это и не деньги вовсе, а не пойми что. Я тоже могу на принтере напечатать "деньги", а потом жаловаться, что мне за них ничего не продают.
Смысл денег ровно в том, что вы можете на них купить что вам нужно. А если не можете, то к деньгам содержимое вашего кармана имеет косвенное отношение. В своё время, если помните, люди довольно чётко проводили линию между "деревянными" рублями и "деньгами", то есть валютой. Вот это примерно о том.
Мне кажется, у вас какая-то нездоровая нелюбовь у этому нехитрому инструменту. Ну да, допустим, можно обойтись электронными взаимозачетами, где в системе будут исключительно бананы, стройматериалы и дрели, и у каждого на личном счёте будет указано, сколько он должен отработать за месяц, и сколько дрелей ему надо выдать. Но зачем? Эта задача прекрасно решается хоть деньгами, хоть ракушками, хоть золотыми слитками, и довольно странно выбрасывать рабочий инструмент на помойку.
Ну и анекдот выше относится к тому идиотскому типу юмора, когда автор по сути высмеивает сам себя. Инопланетянин должен вычеркнуть собеседника из списка разумных, очевидно.
Вот мне вот что удивительно читать. Вы в этой реплике и ниже столько раз упоминаете "нас", "мы" и так далее. Объясните, с чего мне отождествлять себя с руководством, проводящим текущую политику? Я за них не голосовал ни разу, моего мнения они не спрашивали. Более того, если вы посмотрите на поло-возрастно-бэкграундный состав хотя бы Совета безопасности, то увидите, что они крайне криво отражают население страны. По крайней мере, там нет людей моего возраста и похожего на моё образование. Они меня не представляют, и, соответственно, проводимая ими политика -- это их политика. "Нашей" (моей) тут даже близко нет. Нравится она или нет -- вопрос другой, но присоединять себя к этой компании довольно нелогично.
ну для таких задач экран в 14 дюймов в принципе не подходит, на мой взгляд.
Судя по исходной статье -- для университета. Ну если студенту только тексты набирать и интернет читать, вполне норм, не все же программирование изучают.
Скорее нет, чем да. Логарифмическая линейка -- аналоговое устройство, а "аддиаторы" условно цифровые, дискретные, На мой взгляд, ближайшие родственники -- это, с одной стороны, счёты (абак, соробан), а с другой -- машины, в которых движущиеся рейки соединены с шестерёнками, напр., Comptator.
Спасибо :)
Да, тут масса тем. Касательно len(x) vs x.len() -- у меня был научрук, вот он любил подобные вопросы. Байт-код Java исполняет компилятор или интерпретатор? А если процессор реализует байткод нативно, т.е. байткод является его ассемблером?
Концептуально разницы между этими вызовами нет, но второй синтаксис недаром победил. Рано или поздно появляются случаи, когда приходится копаться в "кишках" объекта. Допустим, у нас len() определяется для C-строки, и тогда вычисление len() занимает O(N). Мы решаем кэшировать значение где-то в поле _lenCached, но если функция len() получает доступ к этому полю, то получают и все на свете, а для типа данных "строка" по идее операция доступа к такому полю не определена ("тип есть область значений + допустимые операции"). Тогда надо определять функцию len() как friend (в терминах C++), и в итоге приходим туда, откуда вышли -- есть функции-члены класса и "внешние".
Для меня ООП -- это прежде всего попытка моделирования мира в рамках классической модели Платона-Аристотеля-Линнея. У вещи есть "идеал" (платоновский эйдос), есть свойства сущностные и случайные (эссенция и акциденция по Аристотелю), есть иерархия типов по категориям рода и вида (Линней). Альтернативы на больших масштабах по сути нет, если только речь не идёт о моделировании процессов как таковых (и на этой базе основана библиотека C++ STL, например, но это именно что библиотека алгоритмов).
Что касается неоптимальности представления точек в виде объектов -- ну, да, есть такое. Наверно, если вы работаете с векторами, то объектом должен быть вектор, а не точка. Можно ещё сделать какой-то собственный "векторный" аллокатор памяти или ещё как-то решить этот вопрос "на другом этаже", но в целом, конечно, ООП про представление знаний, а не о том, как это представление хранить в последовательных ячейках памяти.
В некотором смысле тут нет противоречия. Если тип - это множество допустимых значений и операций над ними, то есть ли разница, писать o.f() или f(o)? Скажем, в Ada 95 поддерживается только второй синтаксис (при этом с динамической диспетчеризаций), и язык по мнению авторов вполне себе поддерживает ООП.
Да, совершенно не массовый по сравнению с ожиданиями, цитируемыми в тексте. Ну аутсорсят чего-то, но не конец профессии же.
С тезисами согласен, но один момент заслуживает отдельного обсуждения. Аргумент по итогу сводится к тому, что Фортран, Кобол, ИИ недостаточно хороши, чтобы ими можно было пользоваться без "прокладки" в виде программиста. Однако это не объясняет почему идея аутсорса в условную Индию точно так же не выстрелила, хотя на другом конце тоже вполне себе программисты-люди, и среди них немало хороших.
Мне кажется, что и сейчас, и в обозримом будущем имеет смысл чётко разделять цели и средства. Средство я могу отдать на аутсорс, а цель нет. Если я пишу описание приложения для Гуглплея, цель -- оптимизация для поисковой машины, а текст лишь средство. Нетрудно убедиться, что такие тексты изобилуют к месту и не к месту вставленными ключевыми словами и вообще составлены для гуглоробота, а не для конечного пользователя. Такую работу совершенно спокойно можно аутсорсить Chat-GPT или исполнителю из Индии.
С другой стороны, мы имеем текст вроде этой статьи. Автору хочется поделиться именно своими мыслями (или написать софт, который он хочет написать), и в этом случае сама идея аутсорса звучит достаточно странно. Даже если речь идёт о простом приложении типа калькулятора, автор должен детально продумать и решить для себя, чем этот калькулятор отличается от любого другого, а это уже половина работы, если не больше.
А чего ж их не устраивало тогда? Ну 300 МБ и 300 МБ, не конец света.
Думаю, ваш пример не совсем релевантен, потому что исходный автор Qt приложения, вероятно, не мог предположить всех хотелок заказчика и бил наверняка, использовав заведомо достаточно мощный фреймворк. Вы уже знали, что конкретно требуется, и могли "срезать углы" без опаски.