All streams
Search
Write a publication
Pull to refresh
59
0
Pavel Minaev @int19h

User

Send message
Тонна легаси сама по себе никуда не пропадет.
Я бы не назвал ни Obj-C, ни C# «платформо-зависимыми аналогами C++». Obj-C еще можно так назвать с натяжкой, если вспомнить Obj-C++. А так это сильно разные языки с сильно разными возможностями; из общего у них только немного синтаксиса.
>> Деструкторы — вещь безумно полезная… на фоне проблем языков, существовавших до появления c++. В современном мире есть аналоги, которые могут успешно конкурировать.

Например? Из известного мне это только scope guards, но они не покрывают все сценарии. GC аналогом не является (если вы думаете, что деструкторы нужны для управления памятью — это уже принципиальная ошибка).

>> Не очень знаком с шаблонами (и откровенно плохо их помню) в c++, но что-то не очень представляю как они должны спасти, если тип — везде масса.

Типом в данном случае будет не просто масса, а «масса в кг», и в случае использования масс с разными единицами, нужно будет явно приводить что-то к чему-то. В C++ это делается на шаблонах, и есть готовая реализация в виде Boost.Units. Вот кусок примера из их документации:

quantity<si::volume>    vs(1.0*pow<3>(si::meter));
quantity<cgs::volume>   vc(vs);
quantity<si::volume>    vs2(vc);

quantity<si::energy>    es(1.0*si::joule);
quantity<cgs::energy>   ec(es);
quantity<si::energy>    es2(ec);

quantity<si::velocity>  v1 = 2.0*si::meters/si::second,
                        v2(2.0*cgs::centimeters/cgs::second);
}


Соответственно, при умножении расстояния на время, например, у вас получается именно скорость, а не что-то иное — причем именно в той системе измерения, в которой были входные параментры. Если это разные системы, то вам придется написать явное приведение через static_cast, чтобы однозначно задать, в чем должен быть результат.

В F# аналогичная, но более простая фича есть на уровне языка — возможно, с этим будет проще разобраться.
Судя по описанию выше, это настолько малое подмножество JVM, что общее там по факту только название.
Модель setjmp/longjmp — это худшее, что вообще придумано на тему. Зачем её использовать, если уже давно все сделали лучшие альтернативы?
Опенсорсное решение в виде джаббера уже много лет есть, но воз и ныне там.

И знакомых вы не переведете в массе. Потому что у них тоже есть знакомые, и т.д.
MSN был дико популярен в США (примерно как ICQ в России), да и сейчас имеет немало пользователей там, так что если у кого-то есть знакомые американцы…

Но вообще я это вспомнил только как единственную объективную плюшку от объединения аккаунтов. Хотя вру, еще профит в том, что при использовании Win8, оно будет автологиниться.

А так большинство это делает по более обыденным причинам. Например, чтобы не париться с лишним логином-паролем (мой случай). Или просто потому, что скайп предложил это сделать при входе.
Вы могли и не заводить, а вот ваши собеседники завели. В скайпе уже довольно давно можно привязать свой логин к аккаунту MS, и заходить в него через последний. Это, в частости, позволяет использовать его как клиент для MSN/Live Messenger.
Вы всерьез считаете, что единственное, что держит большинство пользователей скайпа на нем — это отсутствие альтернативного IM с крипто и P2P?
>> Не приведены они, потому что в части, где анализируется проблема инкремента в Swift, мы не сравниваем его с Objective-C, т.к. в первом случае мы работаем со структурой (в Swift даже Int — структура ), а во втором — с простым типом.

Какая разница, структура это или нет? Структура — это value-тип, т.е. реально никаких дополнительных расходов на разыменование здесь нет, а представление в памяти идентично. Соответственно, вменяемый компилятор должен сгенерировать здесь тот же самый код.

В CLR Int32 — это тоже структура, но это не мешает JIT-компилятору делать ++ на ней обычный INC.
Динамическая типизация дает возможность городить трудноанализируемый огород, но ей необязательно пользоваться. Более того, ей можно пользоваться очень выборочно, аккуратно инкапсулируя подобные куски в код с более аккуратным внешним интерфейсом.

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

.egg не работают с pip. Собственно, основной профит с колес для конечного пользователя пакетов, это именно то, что теперь у него pip install будет сразу ставить бинарные пакеты, если разработчик озаботился таковыми, а не пытаться собрать их.
> Только вот при увеличении кодовой базы будет всё сложнее развивать проект и поддерживать качество кода.

Почему?

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

Но, да, список все равно странноватый. C# там точно не к месту — это дитя Java и Delphi.

Реально Симула была прямым вдохновлением для C++, причем это вполне достоверно — помимо вполне очевидных синтаксических заимствований, Бьёрн об этом говорил открыто уже много раз, и в C++ FAQ есть соответствующий пункт.

Насколько она был прямым вдохновением для Java, я не знаю, но факт то, что объектная модель последней намного ближе к оригинальной симуловской (классы исключительно как reference-типы, одиночное наследование), чем плюсовая. А Гослинг в свое время работал над одним из популярных компиляторов Симулы, и высказался по этому поводу так: «Simula pushed my love for object oriented programming. Simula was pure and simple. It was really a lovely language to use». И вроде бы как-то раз на JavaOne он обмолвился, что она оказала сильное влияние на дизайн языка.

Про «повлияли» — видимо, имелось в виду, что повлияли C++/C#/Smalltalk/Java, причем в каждом конкретном случае имеют смысл только некоторые комбинации — т.е., например, Obj-C явный наследник Smalltalk.
Поигрался с Cim — там честные виртуальные вызовы, т.е. например:

begin
    class Base;
    virtual:
        procedure Foo is
            procedure Foo;
        ;
    begin
        procedure Foo;
        begin
            outtext("Base");
        end;
    end;

    Base class Derived;
    begin
        procedure Foo;
        begin
            outtext("Derived");
        end;
    end;

    ref(Base) obj;
    obj :- new Base;
    obj.Foo;
    obj :- new Derived;
    obj.Foo;
end


Печатает «Base Derived». Судя по этому, такое поведение ожидается.
В Википедии есть конкретный пример про virtual, где он используется ровно так, как в C++. Но вообще, конечно, это надо смотреть в спеке. Но там не текст, а отсканированные картинки, плюс терминология очень запутанная, так что я пока так и не смог разобраться.

Если судить по этой книге (по которой я, собственно, в свое время и изучал Симулу), необходимость указывать класс объекта через QUA — это не связанное с виртуальными функциями ограничение оператора точка, которое обходится использованием INSPECT.
ИМХО, для ООП достаточно понятия object identity, и полиморфизма поведения (т.е. какой-либо механизм, при котором данный вызов может обрабатываться по-разному в зависимости от типа объекта). Т.е. например Go — несомненно объектно-ориентирован. Равно как и JS. И даже Lua.

Что касается цитаты Алана Кэя… может, он и придумал термин «ООП», но Simula, которая по факту уже была вполне себе ООП, появилась за несколько лет до Smalltalk. А объектная модель плюсов, это дальнейшее развитие Simula (в т.ч. и синтаксис — «virtual» родом именно оттуда). Так что не думаю, что у Кэя есть монополия на это дело.
У вас бит четности отклеился.

Information

Rating
Does not participate
Location
North Bend, Washington, США
Date of birth
Registered
Activity