Здравствуйте, Воронков Василий, Вы писали:

ВВ>Здравствуйте, BlackEric, Вы писали:

>>>>Под Win 32 для этого практически идеально подходит .NET. Можно писать фактически все кроме драйверов.
BE>>В общем-то это верно начиная с Win 7. Для XP таскать за собой .Net желающих не много.

ВВ>А что за проблема-то такая "таскать .NET"? Кстати, в Виста .NET тоже был.

BE>>А FreePascal (Lazarus) кросплатформенен. Хотя экзотика редкая

ВВ>.NET вообще-то тоже

Ага. Только Mono из всех линуксовых дистрибов кроме Novell пытаются вытравить.

Здравствуйте, Mystic, Вы писали:

M>Здравствуйте, gandjustas, Вы писали:

G>>А на деле оказывается достаточно. Особенно когда касается бизнес-приложений.

M>В бизнес-приложениях зачастую производительность не главное.
Агащазблин. Много разработчиков обломалось из-за таких суждений. Сама скорость выполнения операций не сильно имеет значение, зато имеет значение User Experience.

M>В случае .NET хорошо писать не задумываясь о том, что будет в результате на асемблере.
Это не только .NET касается, даже C.

Здравствуйте, Воронков Василий, Вы писали:

ВВ>Ну например хотим дописывать на С++. Я вообще сишные либы упаковывал в менеджд библиотеки. А это как раз и получалось С -> С++, а поверху толстым слоем С++/CLI.

Не вижу проблем компилировать сишные файлы как сишные и добавить отдельно рядом C++ модули для расширения.
Если же охота в сишных модулях использовать C++ то по моему это будет некрасиво и коряво, или их так придется
переделывать что на этом фоне затраты "портирование" с Си на C++ будут очень малой величиной.
Кстати не стоит забывать что С++ не совместим не только с Си, но и с C++, даже сейчас когда компиляторы стремятся
все-таки следовать стандарту перенос например между bcc, gcc и скажем VC может быть более проблематичным чем с си на С++.

ВВ>>>Ну если ты пишешь "в стиле С", то конечно типизация никак не улучшится. Ну так не пишите на Obj С как на простом С, в чем проблема-то? ООП ж для кого-то прикручивали.
FR>>А получится?
FR>>В том же D можно легко так писать, практически D содержит в себе как подмножество яву, так что даже библиотеки в почти автоматическом режиме транслируют http://www.dsource.org/projects/dwt

ВВ>Не очень понял, что получится? На Obj C в ОО-стиле писать? А что мешает?

Скажем необходимость писать некоторые части на Си если ОО подмножество языка не достаточно мощно.
Вот например на C++ практически невозможно выделить безопасное подмножество языка.

ВВ>При таком подходе Apple Obj C тоже не папа, а сугубо отчим. Ибо появился сей язык тоже весьма давно.



ВВ>Факторов-то много, тут гадать бессмысленно. Опять же не сказать, что у того же Эпла выбор был слишком большой.
ВВ>Ну и да, изобрести язык можно хоть в гараже, но без "папы" он олимп не завоюет.

Да ладно тот же питон и руби без папы как-то стали известными, папы уже позже пришли.

Здравствуйте, BlackEric, Вы писали:

ВВ>>.NET вообще-то тоже
BE>Ага. Только Mono из всех линуксовых дистрибов кроме Novell пытаются вытравить.

Ну в виндовых "дистрибутивах" Джавы, например, нет, однако это совсем не мешает мне пользоваться десктопными приложениями на Джаве — тем же ОО или Эклипсом.

Здравствуйте, gandjustas, Вы писали:

M>>Во-первых, напрягает постоянно вставлять unsafe.
G>А ты что пишешь такое то?

Поиск/перебор. Данные читаются из базы, обрабатываются и пишутся в файл, который проецируется в память. Потом все запросы идут в тулзовину, которая бегает по памяти и ищет результат.

M>>Плюс часто генерируется ужасный код.
G> А оно тебя как волнует? Думаешь на делфи менее ужасный код генерируется со вставкой финализирющих блоков?

Ну уж точно код вроде этого

            System.Drawing.Color Color = System.Drawing.Color.Black;
            if (Color == System.Drawing.Color.Black)
                System.Console.WriteLine("Catastrophic execution");

Не будет скомпилирован как

;            System.Drawing.Color Color = System.Drawing.Color.Black;
0000005c  lea         rcx,[rsp+40h] 
00000061  call        FFFFFFFFF5A8CBF0 
00000066  mov         qword ptr [rsp+000000D0h],rax 
0000006e  lea         rcx,[rsp+40h] 
00000073  mov         rax,qword ptr [rcx] 
00000076  mov         qword ptr [rsp+20h],rax 
0000007b  mov         rax,qword ptr [rcx+8] 
0000007f  mov         qword ptr [rsp+28h],rax 
00000084  mov         rax,qword ptr [rcx+10h] 
00000088  mov         qword ptr [rsp+30h],rax 

;            if (Color == System.Drawing.Color.Black)
0000008d  lea         rcx,[rsp+20h] 
00000092  mov         rax,qword ptr [rcx] 
00000095  mov         qword ptr [rsp+58h],rax 
0000009a  mov         rax,qword ptr [rcx+8] 
0000009e  mov         qword ptr [rsp+60h],rax 
000000a3  mov         rax,qword ptr [rcx+10h] 
000000a7  mov         qword ptr [rsp+68h],rax 
000000ac  lea         rcx,[rsp+70h] 
000000b1  call        FFFFFFFFF5A8CBF0
000000b6  mov         qword ptr [rsp+000000D8h],rax 
000000be  lea         rcx,[rsp+70h] 
000000c3  mov         rax,qword ptr [rcx] 
000000c6  mov         qword ptr [rsp+000000B0h],rax 
000000ce  mov         rax,qword ptr [rcx+8] 
000000d2  mov         qword ptr [rsp+000000B8h],rax 
000000da  mov         rax,qword ptr [rcx+10h] 
000000de  mov         qword ptr [rsp+000000C0h],rax 
000000e6  lea         rcx,[rsp+58h] 
000000eb  mov         rax,qword ptr [rcx] 
000000ee  mov         qword ptr [rsp+00000090h],rax 
000000f6  mov         rax,qword ptr [rcx+8] 
000000fa  mov         qword ptr [rsp+00000098h],rax 
00000102  mov         rax,qword ptr [rcx+10h] 
00000106  mov         qword ptr [rsp+000000A0h],rax 
0000010e  lea         rdx,[rsp+000000B0h] 
00000116  lea         rcx,[rsp+00000090h] 
0000011e  call        FFFFFFFFF5A7DEA0 
00000123  mov         byte ptr [rsp+000000E0h],al 
0000012a  movzx       eax,byte ptr [rsp+000000E0h] 
00000132  test        eax,eax 
00000134  je          0000000000000148 

;                System.Console.WriteLine("Catastrophic execution");
00000136  mov         rcx,12969090h 
00000140  mov         rcx,qword ptr [rcx] 
00000143  call        FFFFFFFFF81DFAE0

Здравствуйте, BlackEric, Вы писали:

BE>Это Pascal (Delphi)?

Компиляторы слабоваты, ну и синтаксис уже маргинальный

BE>Если в нем разрешить описывать переменные в любом месте (как в Java) и для любителей разрешить вместо begin/end писать {}, то будет почти идеально

Ну с сишным синтаксисом может что и выйдет толковое, но тогда лучше с нуля написать, в том же Дельфи мусора тоже немало накопилось.

Здравствуйте, FR, Вы писали:

FR>Не вижу проблем компилировать сишные файлы как сишные и добавить отдельно рядом C++ модули для расширения.
FR>Если же охота в сишных модулях использовать C++ то по моему это будет некрасиво и коряво, или их так придется
FR>переделывать что на этом фоне затраты "портирование" с Си на C++ будут очень малой величиной.
FR>Кстати не стоит забывать что С++ не совместим не только с Си, но и с C++, даже сейчас когда компиляторы стремятся
FR>все-таки следовать стандарту перенос например между bcc, gcc и скажем VC может быть более проблематичным чем с си на С++.

Ну мне, например, охота получить одну-единственную динамическую библиотеку, которую к тому же можно подписать и кинуть в ГАК.
Кстати, справедливости ради, некоторые вещи все же собирались так практически без приседаний.

И это, если такой способ некошерный, то что же тогда эта "совместимость"-то означает? Может, я не хочу для большой библиотеки сидеть импорт описывать, мне прилинковаться хочется. В моем понимании — независимо даже от практической ценности — совместимость языка Х и языком У означает, что я могу использовать статическую либу на Х в языке У без приседаний вообще.

Не, я понимаю, что такой же трюк для разных компиляторов без приседаний также не всегда пройдет. Ну так это, собственно, и говорит о слабой совместимости разных компиляторов

ВВ>>Не очень понял, что получится? На Obj C в ОО-стиле писать? А что мешает?
FR>Скажем необходимость писать некоторые части на Си если ОО подмножество языка не достаточно мощно.
FR>Вот например на C++ практически невозможно выделить безопасное подмножество языка.

Да там нет никакого безопасного подмножества тоже. Можешь по-прежнему в память из ружья стрелять. Там есть своя система типов, эта система типов, извините за тавтологию, более типобезопасна. Вот и все. Но на самом деле это не мало.

Здравствуйте, Воронков Василий, Вы писали:


ВВ>Ну мне, например, охота получить одну-единственную динамическую библиотеку, которую к тому же можно подписать и кинуть в ГАК.
ВВ>Кстати, справедливости ради, некоторые вещи все же собирались так практически без приседаний.

ВВ>И это, если такой способ некошерный, то что же тогда эта "совместимость"-то означает? Может, я не хочу для большой библиотеки сидеть импорт описывать, мне прилинковаться хочется. В моем понимании — независимо даже от практической ценности — совместимость языка Х и языком У означает, что я могу использовать статическую либу на Х в языке У без приседаний вообще.

А где есть проблемы прилинковать, если конечно сишный lib собран тем же компилятором?

ВВ>Не, я понимаю, что такой же трюк для разных компиляторов без приседаний также не всегда пройдет. Ну так это, собственно, и говорит о слабой совместимости разных компиляторов



ВВ>Да там нет никакого безопасного подмножества тоже. Можешь по-прежнему в память из ружья стрелять. Там есть своя система типов, эта система типов, извините за тавтологию, более типобезопасна. Вот и все. Но на самом деле это не мало.

Конечно немало, но хочется большего

Здравствуйте, FR, Вы писали:

FR>А где есть проблемы прилинковать, если конечно сишный lib собран тем же компилятором?

Да много где. Например, несовместимость extern C и extern C++ указателей.
Т.е. не сказать, что прям проблемы, но, скажем так, необходимость тратить время на всякую фигню, и часто время немалое.

ВВ>>Да там нет никакого безопасного подмножества тоже. Можешь по-прежнему в память из ружья стрелять. Там есть своя система типов, эта система типов, извините за тавтологию, более типобезопасна. Вот и все. Но на самом деле это не мало.
FR>Конечно немало, но хочется большего

А большего — это явно выделенный безопасный сабсет языка с GC, блекджеком и шлюхами? Что-то мне начинает казаться, что описанный тобой язык давно существует и называется C++\CLI

Здравствуйте, Воронков Василий, Вы писали:

ВВ>А что есть нормальная статическая проверка типов? По сравнению с чем ее нет в Obj C?
По сравнению с C++, например. Я имел ввиду, что в Obj-C любому объекту можно послать любое сообшение, и если объект его не может обработать, то оно упадёт в рантайме, в отличии от С++, где такое компилятор не пропустит. Если к функции добавить один параметр, то в С++ все её "старые" вызовы станут ошибками компиляции, а в Obj-C — ошибками времени выполнения (предупреждения компилятора будут, но это совсем не то же, что и ошибки.)

ВВ>Отсутствие шаблонов — минус. Но, кстати, тут бы определиться — шаблоны и статическая типизация вообще не очень дружат. А так, в Obj C есть свои фишки: вместо параметрического полиморфизма — полиморфизм через протоколы, в качестве модных ныне extension methods из C# — категории. Вообще язык совсем не примитивен.
А можно подробнее, каким образом шаблоны не дружат со статической типизацией?
Протоколы в С++ реализуются с помощью классов без членов-данных (и в других языках множественное наследование для интерфейсов присутствует.) Категории (extension methods) — я не очень в курсе того, по каким причинам они появились, но на данный момент для меня они выглядят как синтаксический сахар, и не больше. А кстати зачем они нужны? (Просто интересно, может у них есть какая-то дополнительная польза, кроме сахарной.)

Здравствуйте, 24, Вы писали:

24>Здравствуйте, Воронков Василий, Вы писали:

ВВ>>А что есть нормальная статическая проверка типов? По сравнению с чем ее нет в Obj C?
24>По сравнению с C++, например. Я имел ввиду, что в Obj-C любому объекту можно послать любое сообшение, и если объект его не может обработать, то оно упадёт в рантайме, в отличии от С++, где такое компилятор не пропустит. Если к функции добавить один параметр, то в С++ все её "старые" вызовы станут ошибками компиляции, а в Obj-C — ошибками времени выполнения (предупреждения компилятора будут, но это совсем не то же, что и ошибки.)

Это не совсем так. Во-первых, поддерживаются оба подхода и вполне можно использовать статическую типизацию. Во-вторых то, что вы описали — это фича, а не бага, ибо Смоллток же, блин. Как можно больше "решений" о типах переносится в рантайм специально, но если вы не хотите — ну просто не пишите так. Проблемы нет.

ВВ>>Отсутствие шаблонов — минус. Но, кстати, тут бы определиться — шаблоны и статическая типизация вообще не очень дружат. А так, в Obj C есть свои фишки: вместо параметрического полиморфизма — полиморфизм через протоколы, в качестве модных ныне extension methods из C# — категории. Вообще язык совсем не примитивен.
24>А можно подробнее, каким образом шаблоны не дружат со статической типизацией?

Может, у нас путаница в терминах или в чем-то еще? Речь о C++ templates. Каким образом они могут дружить-то? Там чистая утиная типизация — что смогу, то и вызову. В отличие, скажем, от стандартного ОО-полиморфизма.
Про генерики в шарпе речи нет.

24>Протоколы в С++ реализуются с помощью классов без членов-данных (и в других языках множественное наследование для интерфейсов присутствует.) Категории (extension methods) — я не очень в курсе того, по каким причинам они появились, но на данный момент для меня они выглядят как синтаксический сахар, и не больше. А кстати зачем они нужны? (Просто интересно, может у них есть какая-то дополнительная польза, кроме сахарной.)

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

Здравствуйте, Mazay, Вы писали:

M>Интересно, вот это что?
M>http://github.com/graydon/rust/graphs/languages
M>Доля кода на соответствующих языках в проекте?

Типа того, там же репозиторий доступен — всё видно.

Здравствуйте, Воронков Василий, Вы писали:

ВВ>Здравствуйте, BlackEric, Вы писали:

ВВ>>>.NET вообще-то тоже
BE>>Ага. Только Mono из всех линуксовых дистрибов кроме Novell пытаются вытравить.

ВВ>Ну в виндовых "дистрибутивах" Джавы, например, нет, однако это совсем не мешает мне пользоваться десктопными приложениями на Джаве — тем же ОО или Эклипсом.

OO не на Джаве

Здравствуйте, Курилка, Вы писали:

ВВ>>Ну в виндовых "дистрибутивах" Джавы, например, нет, однако это совсем не мешает мне пользоваться десктопными приложениями на Джаве — тем же ОО или Эклипсом.
К>OO не на Джаве

Как так? По всем признакам на Джаве, JRE запускается и все такое. Может, там не все на Джаве, конечно. Тут не знаю, не проверял.

Здравствуйте, Воронков Василий, Вы писали:
ВВ>Во-вторых то, что вы описали — это фича, а не бага, ибо Смоллток же, блин. Как можно больше "решений" о типах переносится в рантайм специально,
Я бы назвал это багофичей — оно может быть как полезно, так и нет, в зависимости от условий. Но лично для меня это чаще баг, чем фича.

ВВ>Может, у нас путаница в терминах или в чем-то еще? Речь о C++ templates. Каким образом они могут дружить-то? Там чистая утиная типизация — что смогу, то и вызову. В отличие, скажем, от стандартного ОО-полиморфизма.
Именно о C++ templates. Типизация внешне выглядит как утиная, но все проверки допустимости вызова при инстанциировании шаблона делает компилятор, и в рантайм ошибочных вызовов не пропустит. Единственный побочный эффект — километровые сообщения об ошибках в случае таковых.

P.S. Если не затруднит, то для меня привычнее общение на "ты" в форумах

Здравствуйте, 24, Вы писали:

ВВ>>Может, у нас путаница в терминах или в чем-то еще? Речь о C++ templates. Каким образом они могут дружить-то? Там чистая утиная типизация — что смогу, то и вызову. В отличие, скажем, от стандартного ОО-полиморфизма.
24>Именно о C++ templates. Типизация внешне выглядит как утиная, но все проверки допустимости вызова при инстанциировании шаблона делает компилятор, и в рантайм ошибочных вызовов не пропустит. Единственный побочный эффект — километровые сообщения об ошибках в случае таковых.

Проверки делают при раскручивании шаблонов. А вот определено ли в стандарте С++ *когда* именно, т.е. на какой стадии, должны инстанцироваться шаблоны? Я, честно говоря, уже не помню, но что-то мне кажется, что нет.
Опять же допустимость вызова == наличие соответствующего члена, к примеру, а не соответствие определенному контракту. Это не только выглядит, но это и есть утиная типизация. На ваш твой взгляд тот факт, что в существующих реализациях это делает компилятор позволяет говорить о статической типизации? А ведь в сущности это чистая динамика только в компайл-тайме.

Здравствуйте, Воронков Василий, Вы писали:

ВВ>Да много где. Например, несовместимость extern C и extern C++ указателей.
ВВ>Т.е. не сказать, что прям проблемы, но, скажем так, необходимость тратить время на всякую фигню, и часто время немалое.

На фоне всего остального фигня.


ВВ>А большего — это явно выделенный безопасный сабсет языка с GC, блекджеком и шлюхами? Что-то мне начинает казаться, что описанный тобой язык давно существует и называется C++\CLI

Блин я тут мечтаю о прекрасной лани, ну на худой конец и лось сгодится, а ты мне вместо одногорбого верблюда впариваешь двугорбого да еще прихрамывающего, тьфу

Здравствуйте, Воронков Василий, Вы писали:

ВВ>Может, у нас путаница в терминах или в чем-то еще? Речь о C++ templates. Каким образом они могут дружить-то? Там чистая утиная типизация — что смогу, то и вызову. В отличие, скажем, от стандартного ОО-полиморфизма.

Утиная типизация никак ни противоречит жесткой статической как пример OCaml объекты и ML структуры утино типизированы. Ну и в версии языка 3.12 которая должна скоро выйти введены явно полиморфные типы которые по сути вводят аналог С++ шаблонов для обычных функций.

Здравствуйте, FR, Вы писали:

ВВ>>Может, у нас путаница в терминах или в чем-то еще? Речь о C++ templates. Каким образом они могут дружить-то? Там чистая утиная типизация — что смогу, то и вызову. В отличие, скажем, от стандартного ОО-полиморфизма.
FR>Утиная типизация никак ни противоречит жесткой статической как пример OCaml объекты и ML структуры утино типизированы.

Да нету в Ocaml никакой утиной типизации. То, что ты называешь утиной типизацией, это просто структурные типы. ИМХО это разные все же вещи.

FR>Ну и в версии языка 3.12 которая должна скоро выйти введены явно полиморфные типы которые по сути вводят аналог С++ шаблонов для обычных функций.

Полиморфные типы? Не знаю таких Знаю полиморфные варианты — но они откровенно weakly typed.

Здравствуйте, FR, Вы писали:

ВВ>>Да много где. Например, несовместимость extern C и extern C++ указателей.
ВВ>>Т.е. не сказать, что прям проблемы, но, скажем так, необходимость тратить время на всякую фигню, и часто время немалое.
FR>На фоне всего остального фигня.

Да как сказать. Если кода много, а разработчик о С++ особо не думал, то вполне можно повозиться.
Но, честно говоря, я уже давно этими вещами не занимался, может, я и преувеличиваю проблемы.

ВВ>>А большего — это явно выделенный безопасный сабсет языка с GC, блекджеком и шлюхами? Что-то мне начинает казаться, что описанный тобой язык давно существует и называется C++\CLI
FR>Блин я тут мечтаю о прекрасной лани, ну на худой конец и лось сгодится, а ты мне вместо одногорбого верблюда впариваешь двугорбого да еще прихрамывающего, тьфу

Неужели тебя не привлекает написать шаблоно-генерик для класса, который будет контролироваться GC?