Да, вы правы, если рассматривать рынок одного товара, то монополия там не является закономерным итогом. Я имел ввиду, что если взять "рынок", как рыночную экономику, без внешнего регулирования, то (в определенных отраслях) монополии там возникнут неизбежно.
Концентрация власти приводит к все большему вмешательству во все сферы жизни, и в экономику в первую (ну или вторую :) ) очередь.
С другой стороны, контроль за ресурсами, который порождает плановая экономика, приводит к возможности значительно усилить текущую власть. Ну и, соответственно, не родился еще человек, который бы этой возможностью не воспользовался.
Видно что у всех разница идет в 2 раза по одной профессии в зависимости от квалификации и типа транспортного средства.
При этом продавец пива в кинотеатре за одну субботу мог заработать годовой заработок капитана, продавая сушеную рыбу из-под прилавка по 2 рубля (лично знаю человека, который так делал).
С другой стороны, чтобы их потратить, нужны были связи, просто так в обычном магазине делать было нечего.
Огромный объем неудовлетворенного спроса породил теневой нерегулируемый рынок, в его худшем проявлении. Это, кстати, еще один недостаток любой плановой экономики (с обычными неидеальными людьми) — рынок возникает там стихийно, потому что это естественный процесс, избавиться от него невозможно, но так как его наличие отрицается, то он не регулируется и все "прелести" теневого рынка там в полный рост.
Но гигантские корпорации — это совсем не аналог плановой экономики в государстве. Корпорации работают в условиях рынка — то есть существует конкуренция, существует определенная денежная масса у людей, конкуренция. Собственники и менеджмент корпорации заинтересованы в ее эффективной работе.
То есть плановой экономику делает планирование спроса и предложения, а не планирование деятельности внутри экономического агента.
Вот как вы оцениваете качество изготовленной одежды?
В том-то и прелесть, что не нужно выдумывать и что-то оценивать, потребители сами решают, что им нужно, а производители подстраиваются.
Я вам привёл пример конкуренции в плановой экономике. То что чего-то не было в СССР не означает, что с текущем развитием науки и техники нельзя это осуществить.
Конкуренция — это немного другое. Это когда твое предприятие неэффективно — оно терпит убытки и закрывается. А когда тебе дарят грамоту и медаль — это, мягко сказать, мало кого мотивирует.
Монополии повсюду, во всех сферах. По вашему, государства и монополии не применяют плановые методы расчёта, скользящее планирование? Или вы наблюдаете вокруг честный рынок?
Монополии — это неизбежный результат "чистого рынка".
Вы не понимаете происхождение цены, упростили всё до угадывания. А как на счёт себестоимости, нормы прибыли? Они с ценой никак не коррелируют?
В плановой экономике нет прибыли, товары отпускаются по полной себестоимости. В рыночной экономике, грубо говоря, продают за столько, за сколько готовы купить. Нормы прибыли и тп — это способ формализации.
Плановая экономика лишена двух сильнейших мотиваторов:
Возможности заработать больше других
Возможности это заработанное потратить
Деньги для большинства людей являются, все-таки, самым сильным мотиватором. Уберите его — и получите немотивированный и ленивый персонал, который работает лишь бы не уволили (а увольнять не будут, потому что все такие. И потом — какой смысл увольнять: все вокруг колхозное, ни у кого, кроме государства, нет заинтересованности в производительности и нормальной работе).
В общем, для эффективного контроля нужен собственник — человек, чей заработок напрямую зависит от эффективности предприятия.
Второе — в плановой системе отсутсвует конкуренция и порождаемая ей обратная связь. Что делать, если предприятие выпустило миллион пар обуви, которая на 10 размеров меньше (ну ошибка вышла). В конкурентной среде ничего страшного не произойдет (спрос удовлетворят конкуренты), в плановой экономике — ну что ж, все ходим в старом этот год.
Короче, все проблемы централизации в полный рост, ради теоретической эффективности и мифической справедливости.
А если вам надо дифференцировать какое-то относительно небольшое конечное количество случаев?
То значит вы используете исключения для бизнес логики (ну либо это такой АПИ у библиотечного кода, как в случае с System.IO.*), и лучше бы их заменить на что-то другое (но в шарпе нет хороших альтернатив)
Просто речь о том что проблема с сотнями декларируемых исключений если и бывает, то очень-очень редко и обычно легко решается.
По-хорошему, количество возможных исключений для метода — это произведение количества всех возможных исключений для всех АПИ, которые вызываются методом + количество исключений, которые выбрасываются непосредственно. То есть оно достаточно большое.
Но поинт не в том. Если для нормального использования АПИ вам нужно знать типы исключений, которые в нем выбрасываются, значит (скорее всего), АПИ выбрасывает эти исключения в качестве некоего аналога возвращаемого значения (а не в случае исключительной ситуации). И это неправильно.
Проблема checked exception в том, что не совсем понятно их назначение.
Если они нужны для того, чтобы декларировать какие вообще исключения могут выбрасываться методом — то их будут сотни в любом методе, пользоваться этим будет невозможно (даже с автоматическим выводом).
Если их использовать для того, чтобы декларировать, какие исключения может выбрасывать конкретный метод — тоже сомнительная полезность. Почему одни исключения мы декларируем, а другие игнорируем? Разделяем опять же исключения на "бизнес-логику" и "ошибки платформы" — а почему они разные, они же не всегда должны по-разному обрабатываться?
Как быть с интерфейсами? Checked Exceptions — это свойство интерфейса или реализации?
Много вопросов, и мало пользы. Они реально нужны только в том случае, если исключениями описывается бизнес-логика, но для этого не стоит использовать исключения.
Проблема в шарпе — это не исключения, а отсутствие хорошего способа выразить ошибочный, но ожидаемый, результат операции. В других языках для этого применяются алгебраические типы, в сишарпе для этого применяется либо null (плохо, т.к. легко игнорируется и не несет информации об ошибке), либо самописный класс (который работает плохо, т.к. нет способа принудить к проверке правильности), либо исключения, которые не для этого предназначены.
Сами исключения как механизм обработки ошибочных ситуаций, при которых невозможно штатное продолжение выполнения кода, работает, на мой взгляд, хорошо.
Исключения хороши тем, что а) их невозможно случайно проигнорировать и б) если их не нужно обрабатывать в каком-то месте — то их можно не обрабатывать, а обработать выше по стеку. Все способы с возвратом ошибки раздувают код, так как вынуждают обрабатывать ошибки сразу после вызова.
Небольшая поправка: буддизм не говорит, что сознание первично. Он говорит, что сознание придает форму "пустоте" — в повторяющихся взаимодействиях простых вещей сознание выделяет объекты, события и наделяет из свойствами.
Как по мне, многословность redux существенна только в маленьких проектах. В примере, где логики две строки — да, многословно, в реальном коде — терпимо.
Мне нравится редакс именно за разделение на экшены, редьюсеры и сайд-эффекты. Код значительно медленнее превращается в бардак.
МобХ опять сводит все это в одно место.
Самое неприятное место для меня был connect. Сейчас его заменили хуками — и это совсем другое дело, наконец-то можно пользоваться без боли и проблем с типизацией.
Если есть задача генерации валидаторов по типам — в некоторых случаях можно решить обратную задачу — написать валидаторы и вывести по ним типы. Тем более, что обычно в типах недостаточно информации для валидации (типа длин строк, ограничения на значения, enum и тп).
Еще один вариант, если есть возможность использовать JSON-схемы для валидации — использовать инструменты для генерации типов из схемы.
Пишу на обеих платформах.
Node JS с Typescript — неплохо для бека, за счет мощной системы типов Тайпскрипта. Реально не хватает ее в C#.
В остальном, особенно что касается бизнес-логики, сравнивать нечего — в ноде нету и близко чего-то подобного LINQ, менее удобный dependency injections и много чего другого.
Ну так они решили подзаработать на волне спроса. Или вы думаете, что если бы государство не купило производителя, то он бы перестал производить?
Да, вы правы, если рассматривать рынок одного товара, то монополия там не является закономерным итогом. Я имел ввиду, что если взять "рынок", как рыночную экономику, без внешнего регулирования, то (в определенных отраслях) монополии там возникнут неизбежно.
Концентрация власти приводит к все большему вмешательству во все сферы жизни, и в экономику в первую (ну или вторую :) ) очередь.
С другой стороны, контроль за ресурсами, который порождает плановая экономика, приводит к возможности значительно усилить текущую власть. Ну и, соответственно, не родился еще человек, который бы этой возможностью не воспользовался.
Но в рыночной экономике вы можете предложить оплату на, скажем, 15% выше рынка, и выбрать лучшее. В плановой экономике есть тарифная сетка.
При этом продавец пива в кинотеатре за одну субботу мог заработать годовой заработок капитана, продавая сушеную рыбу из-под прилавка по 2 рубля (лично знаю человека, который так делал).
С другой стороны, чтобы их потратить, нужны были связи, просто так в обычном магазине делать было нечего.
Огромный объем неудовлетворенного спроса породил теневой нерегулируемый рынок, в его худшем проявлении. Это, кстати, еще один недостаток любой плановой экономики (с обычными неидеальными людьми) — рынок возникает там стихийно, потому что это естественный процесс, избавиться от него невозможно, но так как его наличие отрицается, то он не регулируется и все "прелести" теневого рынка там в полный рост.
Но гигантские корпорации — это совсем не аналог плановой экономики в государстве. Корпорации работают в условиях рынка — то есть существует конкуренция, существует определенная денежная масса у людей, конкуренция. Собственники и менеджмент корпорации заинтересованы в ее эффективной работе.
То есть плановой экономику делает планирование спроса и предложения, а не планирование деятельности внутри экономического агента.
В том-то и прелесть, что не нужно выдумывать и что-то оценивать, потребители сами решают, что им нужно, а производители подстраиваются.
Конкуренция — это немного другое. Это когда твое предприятие неэффективно — оно терпит убытки и закрывается. А когда тебе дарят грамоту и медаль — это, мягко сказать, мало кого мотивирует.
Монополии — это неизбежный результат "чистого рынка".
В плановой экономике нет прибыли, товары отпускаются по полной себестоимости. В рыночной экономике, грубо говоря, продают за столько, за сколько готовы купить. Нормы прибыли и тп — это способ формализации.
Проблемы плановой экономики — совсем не невозможность расчета, а централизация, невозможность эффективного контроля, и слабо мотивированные работники.
Плановая экономика лишена двух сильнейших мотиваторов:
Деньги для большинства людей являются, все-таки, самым сильным мотиватором. Уберите его — и получите немотивированный и ленивый персонал, который работает лишь бы не уволили (а увольнять не будут, потому что все такие. И потом — какой смысл увольнять: все вокруг колхозное, ни у кого, кроме государства, нет заинтересованности в производительности и нормальной работе).
В общем, для эффективного контроля нужен собственник — человек, чей заработок напрямую зависит от эффективности предприятия.
Второе — в плановой системе отсутсвует конкуренция и порождаемая ей обратная связь. Что делать, если предприятие выпустило миллион пар обуви, которая на 10 размеров меньше (ну ошибка вышла). В конкурентной среде ничего страшного не произойдет (спрос удовлетворят конкуренты), в плановой экономике — ну что ж, все ходим в старом этот год.
Короче, все проблемы централизации в полный рост, ради теоретической эффективности и мифической справедливости.
То значит вы используете исключения для бизнес логики (ну либо это такой АПИ у библиотечного кода, как в случае с System.IO.*), и лучше бы их заменить на что-то другое (но в шарпе нет хороших альтернатив)
По-хорошему, количество возможных исключений для метода — это произведение количества всех возможных исключений для всех АПИ, которые вызываются методом + количество исключений, которые выбрасываются непосредственно. То есть оно достаточно большое.
Но поинт не в том. Если для нормального использования АПИ вам нужно знать типы исключений, которые в нем выбрасываются, значит (скорее всего), АПИ выбрасывает эти исключения в качестве некоего аналога возвращаемого значения (а не в случае исключительной ситуации). И это неправильно.
Проблема checked exception в том, что не совсем понятно их назначение.
Если они нужны для того, чтобы декларировать какие вообще исключения могут выбрасываться методом — то их будут сотни в любом методе, пользоваться этим будет невозможно (даже с автоматическим выводом).
Если их использовать для того, чтобы декларировать, какие исключения может выбрасывать конкретный метод — тоже сомнительная полезность. Почему одни исключения мы декларируем, а другие игнорируем? Разделяем опять же исключения на "бизнес-логику" и "ошибки платформы" — а почему они разные, они же не всегда должны по-разному обрабатываться?
Как быть с интерфейсами? Checked Exceptions — это свойство интерфейса или реализации?
Много вопросов, и мало пользы. Они реально нужны только в том случае, если исключениями описывается бизнес-логика, но для этого не стоит использовать исключения.
Проблема в шарпе — это не исключения, а отсутствие хорошего способа выразить ошибочный, но ожидаемый, результат операции. В других языках для этого применяются алгебраические типы, в сишарпе для этого применяется либо null (плохо, т.к. легко игнорируется и не несет информации об ошибке), либо самописный класс (который работает плохо, т.к. нет способа принудить к проверке правильности), либо исключения, которые не для этого предназначены.
Сами исключения как механизм обработки ошибочных ситуаций, при которых невозможно штатное продолжение выполнения кода, работает, на мой взгляд, хорошо.
Исключения хороши тем, что а) их невозможно случайно проигнорировать и б) если их не нужно обрабатывать в каком-то месте — то их можно не обрабатывать, а обработать выше по стеку. Все способы с возвратом ошибки раздувают код, так как вынуждают обрабатывать ошибки сразу после вызова.
Небольшая поправка: буддизм не говорит, что сознание первично. Он говорит, что сознание придает форму "пустоте" — в повторяющихся взаимодействиях простых вещей сознание выделяет объекты, события и наделяет из свойствами.
Как по мне, многословность redux существенна только в маленьких проектах. В примере, где логики две строки — да, многословно, в реальном коде — терпимо.
Мне нравится редакс именно за разделение на экшены, редьюсеры и сайд-эффекты. Код значительно медленнее превращается в бардак.
МобХ опять сводит все это в одно место.
Самое неприятное место для меня был connect. Сейчас его заменили хуками — и это совсем другое дело, наконец-то можно пользоваться без боли и проблем с типизацией.
Если есть задача генерации валидаторов по типам — в некоторых случаях можно решить обратную задачу — написать валидаторы и вывести по ним типы. Тем более, что обычно в типах недостаточно информации для валидации (типа длин строк, ограничения на значения, enum и тп).
Еще один вариант, если есть возможность использовать JSON-схемы для валидации — использовать инструменты для генерации типов из схемы.
Пишу на обеих платформах.
Node JS с Typescript — неплохо для бека, за счет мощной системы типов Тайпскрипта. Реально не хватает ее в C#.
В остальном, особенно что касается бизнес-логики, сравнивать нечего — в ноде нету и близко чего-то подобного LINQ, менее удобный dependency injections и много чего другого.
Так вам зарплату монополист назначил или нет?
Изначально речь шла о неравенстве, а "разобщенность и индивидуализм" это уже вы сами придумали.
Дружность и коллективизм не отменяет неравенство.
Нет.