Re[56]: Nemerle через 5 лет - выстрелит или скончается?
От: VladD2 Российская Империя www.nemerle.org
Дата: 25.10.14 00:39
Оценка:
Здравствуйте, alex_public, Вы писали:

_>Ну а в остальном я в общем то согласен. Только вывод бы немного переделал: для достижения одинаковой скорости разработки на C# и C++, требуется чтобы программист C++ был заметно более высокого уровня.


А если представить обратную ситуацию? Ну, программист на Шарпе заметно более высокого уровня? Что будет?

А если представить, что он не Шарп, а Немарл использует?

Пойми, я решу задаче на любом языке. Даже на ассемблере, если нужно. Но чем выше уровень языка, чем более сложную задачу я смогу решить. Сравнимые же задачи будут решаться быстрее.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[66]: Nemerle через 5 лет - выстрелит или скончается?
От: alex_public  
Дата: 25.10.14 05:04
Оценка:
Здравствуйте, VladD2, Вы писали:

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


Безусловно, но это ты описал теоретическую область применимости платформы, а не рыночную нишу. Фокус в том, что ниша определяется не той областью, где язык может решить задачу, а той, где он решает её лучше остальных по сумме параметров. Так вот java/c# очевидно являются лучшими при главном упоре на минимизацию расходов it отдела какой-то корпорации. Это безусловно очень большая ниша, но при этом она всё же намного меньше вышеуказанной области применимости самой платформы.

VD>Не надо тешить себя сказками и мифами.

VD>Ди не стал популярным. И не стал в те времена когда С++11 еще не было и не ясно будет ли. Причина тут та же что с Немерлом. Отсутствие брэнда с кучей ресурсов (амин, пиар, бабла).

Ты не понял мою мысль. ) D конечно же не был популярен в смысле применения в реальных проектах. Но про него многие знали и в головах он вполне чётко держался как потенциальное будущее (типа вот сейчас там инфраструктуру ещё подтянут и точно надо перебираться туда с отсталого C++). А вот в последнее время, в связи с развитием C++, народ уже не особо думает о нём как о явном будущем. Теперь частично такие взгляды кидаются на Rust, а частично и на будущее стандарты самого C++...

VD>Я не очень понимаю что ты имеешь в виду. Возможность выражения монад или использование дженериков с переменным числом аргументов типов? Если первое, то — да. Если второе, то — нет, так как они не поддерживаются. Вместо этого (как в С++03) придется создать дцать перегрузок.


Второе. ) Так получается, что лямбды в C++ мощнее чем в C#?)

VD>В немерле для монадных игрушек сделан ComputationExpressions.


Хм, вообще никакого описания не ставите? А как тогда народу незнакомому с Nemerle оценить его крутизну (она же как раз в таких вещах проявляется)?

VD>Ну, и с переменным число параметров в макросах тоже никаких проблем. Так что твой примерчик переписывается на макрах в разы проще. Я правильно понимаю, что он тупо объединяет кортежи (или что-то на них похожее) в один кортеж?


С помощью нормального МП понятно что можно что угодно сделать. Собственно даже и нормального не требуется, т.к. работа с кортежами есть в C++ давным давно (на базе игр в шаблоны). Фокус в том, что здесь это не МП. )

Ну и да, там объединяются и выводятся кортежи с помощью классических приёмов ФП. Но как бы этот тест был написан не ради кортежей, а ради демонстрации современных возможностей лямбд в C++. Понятно что прямо такой код вряд ли кто-то будет писать на практике, но у подобных лямбд есть очень много интересных способов использования. Кстати, я уже сам натыкался в старом коде на проблему, самым эффективным решением которой, как раз они и были бы.

VD>А зачем создавать в донте несовместимый со остальными языками дотнета набор коллекций? Ну, разве что для особо требовательных к скорости вычислений коду. Но тут проще взять и написать его с использованием встроенного массива, так как быстрее все равно ничего не будет, а он обеспечивает вполне приличный уровень абстракции для большинства задач.


Вообще речь шла не о самих коллекция, а об алгоритмах работы с ними. Т.е. замена linq. Благодаря МП алгоритм может автоматически распознавать тип коллекции (например тот же встроенный массив) и применять соответствующие оптимизации. Конечно подобное можно реализовать и во время выполнения, но понятно, что эффективность такого кода будет совсем низкая.

VD>Сдается мне, что всю клиенскую часть вы спокойно могли бы писать на дотнете и Моно (если вам важна поддержка Линукса и Макоси).


Если ты про мой текущий проект, то его программную часть можно разделить на 3 чёткие части:
1. Реалтайм в микроконтроллерах. Тут просто по условию задачи подходит только C или C++. Мы выбрали C++ (что кстати считается "продвинутым" решением — здесь индустрия только ещё начинает переползать с C).
2. Решение без GUI (собственно у железа даже экрана нет), требующее высокого быстродействия и взаимодействия с драйверами. В качестве платформы Linux. Здесь мог бы подойти любой быстродействующий системный язык (например D). Мы выбрали C++.
3. Решение с GUI, требующее высокого быстродействия. Желательна максимальная кроссплатформенность. Здесь подходит любой быстродействующий язык с наличием удобных GUI библиотек (C++, кто ещё?). Мы выбрали C++.

Куда ты тут предлагаешь засунуть дотнет? )

_>>А есть какой-то общий известный каталог таких библиотек для Nemerle? ) Интересно посмотреть что там уже наделали... )

VD>https://github.com/rsdn/nemerle/tree/master/snippets
VD>Правда класть туда проекты не является обязательным, по этому ряд больших проектов лежит в отдельных репозиториях.

Что-то там в основном просто какие-то примеры тестовых программок на Nemerle, а не библиотеки. А те, что вроде как библиотеки (типа Nemerle.Statechart), вообще без строчки документации. Что-то это как-то не сравнимо с тем же Boost'ом. Я конечно понимаю, что количество разработчиков не сравнимое, но как вообще начать пользоваться такой библиотекой? Бродить по исходникам?

_>>Для небольшого проекта при таких условиях я бы точно выбрал Питон. )

VD>Динамически типизируемый язык для больших проктов? Гы-гы. Разве что проект состоит из кучи мелких слабо связанных друг-другом скриптов (как в вебе).

Гмммм...

_>>Специализация тоже о многом говорит. ) К примеру если один дизайнер "специализируется" в Фотошопе, а другой в Paint'е, то... )))

VD>Вот это и есть надменность. По факту же Шарп сложнее плюсов. Для того чтобы писать качественный код на нем нужно так же быть профессионалом. при этом у шаприста профессионала будет куда более высока производительность нежели у профи плюсовика. Да, МП нет. Код, при использовании одинаковых алгоритмов, получится чуть быстрее на плюсах. Потребление памяти в разы больше чем на плюсах. Но проект будет сдан значительно раньше (опять же при равном его качестве).

Это был пример актуальности информации о специализации, а не аналогия на сравнение натива и .net'a. Если же говорить про последнее, то тут наверное самой корректной аналогией будет старый пример: автомобили с ручной и автоматической коробкой передач. Автоматическая коробка плохо подходит для гонок (быстрого кода) и особого бездорожья (системного кода), но отлично подходит для того, чтобы отвести детей в школу (написать корпоративную формочку), что является намного более востребованной задачей. Это всё очевидно и ты вроде как с этим всем согласен. Но почему-то никак не можешь понять другую простейшую вещь: профессиональный гонщик отвезёт детей в школу на машине с ручной коробкой передач (напишет GUI на C++) не менее безопасно и комфортно. )

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


Всё верно.

VD>Ну, вот и не тешь себя сказками, что те кто выбирают другие языки менее профессиональны и у них там какие-то проблемы с порогом вхождения в унылый С++. Таких проблем нет. Просто есть языки на которых мы в разы эффективнее, так как они спроектированы в разы лучше плюсов. Для МП в них применяются специально предназначенные для этого вещи. Память управляется автоматически. Получить неиниализированные данные невозможно в принципе. Типизация строже. Так что ошибок в коде становится намного меньше. Все это позволяет больше времени уделять алгоритмам и фичам. В итоге вместо примитивного Spirit-а мы имеем офигительные Nemerle.PEG и Ninta.


А никто и не говорил о профессиональном уровне отдельных людей — профессионал останется собой и при написание bat файлов. Речь шла о предназначение языка.

Да, и речь тут шла про C#, а не про Nemerle. С позиционированием последнего как раз есть большие вопросы, т.к. на нишу C#/Java он не очень попадает из-за сложности (даже само понятие МП не у всех приживается), а на нишу C++ из-за ограничений .net'a.

VD>Вообще-то кортежи есть в стандартной библиотеки дотнета. Но работать с ними так же не удобно как и на С++, так как для удобной работы с ними нужен паттерн-матчинг.


Я же говорю, там кортежи времени исполнения — это вообще не то (подобную ерунду на любом языке за пару минут можно накидать, но эффективность понятно какая будет). Да, и на C++ действительно не хватает пары синтаксических удобств для работы с кортежами, которые есть в других языках (типа Swift'a). Например для распаковки требуются уже объявленные переменные http://en.cppreference.com/w/cpp/utility/tuple/tie и т.п. мелочи. Но в целом работа как раз вполне удобная.

VD>Ты сильно ошибаешься, если думаешь, что я не смотрю по сторонам. Я смотрел и Ди, и Раст. Но ничего интересного для Немерла там не увидел. Там есть интересные решения, вроде шаблонов с переменным числом параметров, но их нужно не в немерл, а в дотнет добавлять. В немерле же есть макры с переменным числом параметров, что для большинства применений хватает. Во стальном немерл — супер-сет к этим языкам. Все что есть в них, есть и в немерле.


Не, я не про сами языки, а про то, как они распорядились обладанием возможностью МП. К примеру в стандартной библиотеке D (в исходниках, а не в интерфейсе!) есть много любопытных решений... Одно я тут уже упоминал — очень эффективная реализация стандартных алгоритмов работы контейнерами. Так что использование абстракции типа linq (там это Range) не привносит вообще никаких накладных расходов.

VD>Статья твоя о JS. Все что там сказано о GC — это, что что для его хорошей работы нужно много памяти, которой на старых айфонах нет.


Про JS там было только вступление) И достаточно памяти нет не только на старых айфонах, а считай во всей мобильной разработке.

_>>Про разные мелкие косяки в дискуссии со мной (типа как с Sign# и т.п.) умолчим.

VD>Не надо умалчивать. Если у тебя есть что возразить, приведи доказательства. Я знаю о чем говорю.

Просматривал код ядра Singularity? )

_>>Но тебе уже несколько человек в этой темке указывали на то, что ты абсолютно не верно проводишь сравнения с C++.

VD>У меня к этим людям нет особого доверия. Они имеют однобокий опыт в отличии от меня и тех людей мнению которых я доверяю.

Какое отношение имеет опыт работы на .net'е к оценке правильности написания на C++? )

VD>Давай ты мне ссылок дашь подтверждающих эти домыслы обо мне. Выводы я делаю исключительно на опыте разработки софта и фактах. Все наши приложения работали достаточно быстро и на C, и на C++, и на C# и на Nemerle. Если это было не так, мы брали в руки профайлер и добивались необходимой производительности.


Я не знаю какой там у тебя был когда-то код, я вижу твои высказывания по C++ в этой темке. И из них можно сделать только один из следующих выводов:
1. Ты никогда полноценно не знал C++.
2. Знал, но подзабыл в последнее время (переучился на другой стиль).
3. Всё прекрасно знаешь, но специально говоришь о таком коде на C++ (благо язык позволяет и такое писать), в сравнение с которым аналог на Java/C# может оказаться выигрышным.

VD>И не надо мне пытаться внушить, что у меня задачи какие-то не требовательные. Почти все мои задачи были требовательны к производительности. Даже код пакета подготовки статей для РСДН будучи переписан с С++-ных регекспов и вордовских сктиптов стал в 100 раз быстрее будучи переписаым на немерле. Но не из-за того, что немерл какой-то супер быстрый, а потому, что вместо того чтобы вынимать данные из вордовский файлов через атомйшон, я тупо распарсил его ХМЛ-ник и вынул все нужные данные. Получилось гибче и в сто раз быстрее.


А если бы ты на C++ написал с парсингом xml? ) Или на Питоне (в котором парсер xml написанный на C)? )

VD>Вывод на экран ни разу не проблема для дотнета. Даже, при использовании WPF, может и по круче получиться. Ну, а "кодеки", если там реально нужны разные SIMD-инструкции и т.п., конечно лучше на плюсах или видеокарте реализовывать. Это то где их ниша пока что свободна.


Речь про вывод FHD/4K видео с минимальной задержкой. Что-то я сомневаюсь... ) У меня тут в миллисекундах промерен весь тракт до OpenGL/DirectX. )

VD>А зачем нужны окна от С++? Кодек — это по сути тупая функция. А писать нужно на том, что сокращает твое время и улучшает результат. WPF на винде — это то что доктор прописал для подобных задач. Глядишь и кодеки не придется писать, так как там много всего из коробки поддерживается.


Я же говорю, как раз здесь требуется быстродействие. )

_>>Ну и потом с помощью правильных инструментов (весь GUI задаётся в специальном удобном редакторе, который потом автоматически генерирует весь нужный C++ код) GUI легко делается и в C++.

VD>Хреновенький и простенький — возможно. Но с WPF-ом его вряд ли можно сравнить. Плюс пишете вы уже все равно не на С++, а на каком-то другом языке. То что с него генерируется уже рояли не играет.

Интерфейс не пишется, а "рисуется" мышкой в редакторе. ))) После чего генерируется C++ код и остаётся только пронаследоваться от созданного абстрактного класса и реализовать все чистые виртуальные функции (так редактор задаёт обработчики событий, настроенные в нём). В данном случае весьма эффективен и процесс разработки и получаемый результат.

Да, кстати... А что, сложный интерфейс — это теперь стало плюсом ПО? ) На мой взгляд это как раз большой минус и его надо максимально избегать.
Re[57]: Nemerle через 5 лет - выстрелит или скончается?
От: alex_public  
Дата: 25.10.14 05:24
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>А если представить обратную ситуацию? Ну, программист на Шарпе заметно более высокого уровня? Что будет?


А такой программист не очень интересен нормальному не it бизнесу (на который и ориентированы java/c#), т.к. слишком дорого стоит (причём речь не столько про зарплату, сколько про заменимость). Так что ему остаётся достаточно специфическая ниша — it компании, которые при этом работают на .net. Обычно это в некотором роде сервисные компании, занимающиеся достраиванием блоков инфраструктуры платформы (библиотеки, инструменты и т.п.). Хотя в последнее время появилась новая ниша для использования java/c# it компаниями — мобильная разработка. Но судя по объёмам и качеству создаваемого ими ПО, там ситуация с уровнем оказалась ещё хуже, чем в корпоративном секторе.

VD>Пойми, я решу задаче на любом языке. Даже на ассемблере, если нужно. Но чем выше уровень языка, чем более сложную задачу я смогу решить. Сравнимые же задачи будут решаться быстрее.


Безусловно. И чем выше уровень языка, тем уже круг решаемых им задач. В идеале приходим к использованию каких-нибудь DSL'ей. )

Так вот на мой взгляд сейчас самым простым и одновременно эффективным вариантом реализации подобного является приложение на C++ (получаем быстродействие) с интегрированным в него скриптовым языком (получаем гибкость и скорость разработки).
Re[66]: Nemerle через 5 лет - выстрелит или скончается?
От: Evgeny.Panasyuk Россия  
Дата: 25.10.14 07:21
Оценка:
Здравствуйте, VladD2, Вы писали:

EP>>Сглаживание последствий багов, никак не отменяет того что это баг.

VD>Зато позволяет не потерять все незаписанные данные от того, что в реализации фичи вызываемой по кнопке закрался баг.

Не, не позволяет в общем случае Баг может делать что угодно.

VD>Мы эту проблему еще 10 лет назат с Пашей Кузнецовым обсуждали. Я его так и не смог убедить, что не для всех задач лучшей реакцией на ошибку является немедленное падение с дампом.


Зависит от задач. Где-то лучше падение с дампом, где-то лучше попытка сохранить пользовательские данные (например что-то типа std::at_quick_exit), а где-то может и spinning до приезда реанимационной бригады.

EP>>Да, для некоторых классов багов, языки с GC и выключенным unsafe — дают определённые гарантии, которых нет в C++ без внешних тулз

WH>>>Знаешь, как в яндексе борются с утечками памяти и проездами по памяти?
WH>>>Рестартом демона по таймеру. Ну, или по факту выпадения в кору.
EP>>Да и вообще, для критичных проектов нужен fault-tolerance в той или степени, и не важно на чём написаны
VD>Дык его невозможно гарантировать на не безопасных системах типов. Ведь при испорченной памяти вообще ничего гарантировать нельзя.

Его нельзя гарантировать вообще нигде
Re[67]: Nemerle через 5 лет - выстрелит или скончается?
От: DarthSidius  
Дата: 25.10.14 07:33
Оценка:
Здравствуйте, alex_public, Вы писали:

_>Это был пример актуальности информации о специализации, а не аналогия на сравнение натива и .net'a. Если же говорить про последнее, то тут наверное самой корректной аналогией будет старый пример: автомобили с ручной и автоматической коробкой передач. Автоматическая коробка плохо подходит для гонок (быстрого кода) и особого бездорожья (системного кода), но отлично подходит для того, чтобы отвести детей в школу (написать корпоративную формочку), что является намного более востребованной задачей. Это всё очевидно и ты вроде как с этим всем согласен. Но почему-то никак не можешь понять другую простейшую вещь: профессиональный гонщик отвезёт детей в школу на машине с ручной коробкой передач (напишет GUI на C++) не менее безопасно и комфортно. )


Опять неверные аналогии. АКПП рулят. В формуле-1 запрещены правилами. А по поводу бездорожья... На джипах и даже танках давно уже устанавливаются.
... << RSDN@Home (RF) 1.2.0 alpha 5 rev. 58>>
♠♠♥♠♠♦♥
Re[67]: Nemerle через 5 лет - выстрелит или скончается?
От: VladD2 Российская Империя www.nemerle.org
Дата: 25.10.14 13:43
Оценка:
Здравствуйте, Evgeny.Panasyuk, Вы писали:

EP>Не, не позволяет в общем случае Баг может делать что угодно.


Может. В С++ может по памяти пройтись или свалить все приложение (эксцепшон в деструкторе). В управляемом мире критичным будет только баг в критичном месте. Ошибка в меню копирования не свалит весе приложение, например.

VD>>Мы эту проблему еще 10 лет назат с Пашей Кузнецовым обсуждали. Я его так и не смог убедить, что не для всех задач лучшей реакцией на ошибку является немедленное падение с дампом.


EP>Зависит от задач.


Решил в капитана очевидность поиграть. Или просто так соглашаешься?

EP>Его нельзя гарантировать вообще нигде


Почему же нельзя? Можно. Есть стратегии разработки позволяющие реализовать отказоустойчивые системы. Но это не про плюсы.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[58]: Nemerle через 5 лет - выстрелит или скончается?
От: VladD2 Российская Империя www.nemerle.org
Дата: 25.10.14 14:11
Оценка: +1
Здравствуйте, alex_public, Вы писали:

_>А такой программист не очень интересен нормальному не it бизнесу (на который и ориентированы java/c#),


Я устал тебе повторять, что тебе нужно как-то бороться со своими предрассудкам (уж не знаю, как это назвать, чтобы не обидеть). У нас в конторе сотни программистов в основном пишущих на управляемых языках. Среди них десятки высококлассных специалистов. Да и остальные не ламеры.

Так что этот миф забудь. Ява и шарп — это языки общего назначения пригодные как для бизнеса, так и для разработки любого другого софта, за редким исключением.

_>т.к. слишком дорого стоит (причём речь не столько про зарплату, сколько про заменимость).


Ну, ты вряд ли заменишь наших специалистов. И что? Делаем вывод, что ты неквалифицированный специалист? И зарплаты у них скорее всего выше твоих. Опять делаем вывод о твоей квалификации?

Может тебе стоит сменить позицию на более взвешенную и менее смешную и признать, что класс специалиста никак не зависит от языка? Спецы могут быть и на ПХП. Им даже труднее .

_>Так что ему остаётся достаточно специфическая ниша — it компании, которые при этом работают на .net. Обычно это в некотором роде сервисные компании, занимающиеся достраиванием блоков инфраструктуры платформы (библиотеки, инструменты и т.п.). Хотя в последнее время появилась новая ниша для использования java/c# it компаниями — мобильная разработка. Но судя по объёмам и качеству создаваемого ими ПО, там ситуация с уровнем оказалась ещё хуже, чем в корпоративном секторе.


Ты сотворил для себя миф и боишься с ним расставаться.

_>Безусловно. И чем выше уровень языка, тем уже круг решаемых им задач.


Вовсе нет.

_>В идеале приходим к использованию каких-нибудь DSL'ей. )


DSL и языки общего назначения (GPL) — это разные вещи. DSL могут прекрасно дополнять GPL-и. Если язык тюринг-полный, то решать на нем можно любые задачи. Просто он может быть не очень удобен или не обладать некими свойствами делающими его применение менее целесообразным чем другим. Но от уровня языка это не зависит.

_>Так вот на мой взгляд сейчас самым простым и одновременно эффективным вариантом реализации подобного является приложение на C++ (получаем быстродействие) с интегрированным в него скриптовым языком (получаем гибкость и скорость разработки).


Ну, да. Любой язык хорош, так как на нем можно реализовать лисп-машину, на которой просто и быстро решить задачу. (ц)

Зачем мне два языка, если используемый мной язык выше уровнем чем используемый тобой скриптовый язык и обеспечивает производительность на уровне мало отличимом от того что предоставляют С++-ные компиляторы?

Как бы производительность ведь не догма. Это всего лишь один из критериев. И максимальная производительность нужна редко. Обычно нужна приемлемая производительность. Скажем мне по фигу будет ли игра обеспечивать 120 FPS или 100500, ведь приемлемым является 60.

Скрипты же это не только тормоза, но и баги. От проходов по памяти они защитят, но от ошибок типов в рантайме — нет. А это очень частая причина ошибок. Пока проект мелкий и кода мало это не заметно и даже кажется (по сравнению с С++), что на скрипте писать быстрее. Но с ростом кодовой базы становится все сложнее поддерживать проект в качественном состоянии.

Так на фиг мне это нужно?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[68]: Nemerle через 5 лет - выстрелит или скончается?
От: Evgeny.Panasyuk Россия  
Дата: 25.10.14 14:21
Оценка:
Здравствуйте, VladD2, Вы писали:

EP>>Не, не позволяет в общем случае Баг может делать что угодно.

VD>Может. В С++ может по памяти пройтись или свалить все приложение (эксцепшон в деструкторе). В управляемом мире критичным будет только баг в критичном месте. Ошибка в меню копирования не свалит весе приложение, например.

Нет таких гарантий в общем случае.

VD>>>Мы эту проблему еще 10 лет назат с Пашей Кузнецовым обсуждали. Я его так и не смог убедить, что не для всех задач лучшей реакцией на ошибку является немедленное падение с дампом.

EP>>Зависит от задач. Где-то лучше падение с дампом, где-то лучше попытка сохранить пользовательские данные (например что-то типа std::at_quick_exit), а где-то может и spinning до приезда реанимационной бригады.
VD>Решил в капитана очевидность поиграть. Или просто так соглашаешься?

Соглашаюсь и дополняю, вроде очевидно. Ах да, такого же не может быть, "кругом враги! Nemerle в опасносте!"

EP>>>>Да и вообще, для критичных проектов нужен fault-tolerance в той или степени, и не важно на чём написаны

VD>>>Дык его невозможно гарантировать на не безопасных системах типов. Ведь при испорченной памяти вообще ничего гарантировать нельзя.
EP>>Его нельзя гарантировать вообще нигде
VD>Почему же нельзя? Можно. Есть стратегии разработки позволяющие реализовать отказоустойчивые системы.

Эти стратегии не дают 100% гарантии, а лишь увеличивают шансы на достойную встречу fault, который может быть любого рода.

VD>Но это не про плюсы.


Опять жёсткий bias
Re[68]: Nemerle через 5 лет - выстрелит или скончается?
От: alex_public  
Дата: 26.10.14 03:52
Оценка:
Здравствуйте, DarthSidius, Вы писали:

DS>Опять неверные аналогии. АКПП рулят. В формуле-1 запрещены правилами. А по поводу бездорожья... На джипах и даже танках давно уже устанавливаются.


Хыхы, я смотрю аналогия вышла не просто хорошая, а великолепная. Если по ней самой начинаются аналогичные споры. Причём что самое забавное, те же самые персонажи находятся с тех же самых сторон.

Да, но должен признать, что автор этой аналогии не я — она гуляет по сети уже давным давно. Ещё с тех времён, когда как раз только ручной и автоматический вариант были актуальны. Если говорить про наше время, то у автомобилей, помимо тех двух старых решений, развились альтернативные, которые совмещают в себе их преимущества. Например роботизированная коробка передач (с двойным сцеплением естественно, а не первые неудачные поделки). И если снова проводить аналогию, то это наверное больше всего похоже на нативный код управляемый скриптом. Возможно за подобным будущее)
Re[59]: Nemerle через 5 лет - выстрелит или скончается?
От: alex_public  
Дата: 26.10.14 04:17
Оценка:
Здравствуйте, VladD2, Вы писали:

_>>А такой программист не очень интересен нормальному не it бизнесу (на который и ориентированы java/c#),

VD>Я устал тебе повторять, что тебе нужно как-то бороться со своими предрассудкам (уж не знаю, как это назвать, чтобы не обидеть). У нас в конторе сотни программистов в основном пишущих на управляемых языках. Среди них десятки высококлассных специалистов. Да и остальные не ламеры.

Ты работаешь в не it компании? ) Хм, а мне казалось что ты вроде к JB имеешь какое-то отношение...

VD>Так что этот миф забудь. Ява и шарп — это языки общего назначения пригодные как для бизнеса, так и для разработки любого другого софта, за редким исключением.


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

VD>Может тебе стоит сменить позицию на более взвешенную и менее смешную и признать, что класс специалиста никак не зависит от языка? Спецы могут быть и на ПХП. Им даже труднее .


А я где-то с этим спорил? ) Я же тебе сам уже третий раз привожу пример с написание bat файла профессионалом. )))

VD>DSL и языки общего назначения (GPL) — это разные вещи. DSL могут прекрасно дополнять GPL-и. Если язык тюринг-полный, то решать на нем можно любые задачи. Просто он может быть не очень удобен или не обладать некими свойствами делающими его применение менее целесообразным чем другим. Но от уровня языка это не зависит.


Ну да, на Прологе (явный GPL) например очень "удобно" занимается фильтрацией видео в реальном времени. )))

А вот например задавать нетривиальную логику поведения на нём действительно очень удобно. Причём настолько, что можно не полениться интегрировать его в сложное приложение на другом языке.

VD>Зачем мне два языка, если используемый мной язык выше уровнем чем используемый тобой скриптовый язык и обеспечивает производительность на уровне мало отличимом от того что предоставляют С++-ные компиляторы?


Нуну)

VD>Как бы производительность ведь не догма. Это всего лишь один из критериев. И максимальная производительность нужна редко. Обычно нужна приемлемая производительность. Скажем мне по фигу будет ли игра обеспечивать 120 FPS или 100500, ведь приемлемым является 60.


VD>Скрипты же это не только тормоза, но и баги. От проходов по памяти они защитят, но от ошибок типов в рантайме — нет. А это очень частая причина ошибок. Пока проект мелкий и кода мало это не заметно и даже кажется (по сравнению с С++), что на скрипте писать быстрее. Но с ростом кодовой базы становится все сложнее поддерживать проект в качественном состоянии.


VD>Так на фиг мне это нужно?


Ты знаешь, общетеоретически я даже с тобой согласен, что лучше бы один язык решающий все проблемы. Но вот практически в данный момент развития индустрии выходит так, что самое лучшее сочетание эффективного кода и эффективной разработки дают именно такие гибридные решения.
Re[69]: Nemerle через 5 лет - выстрелит или скончается?
От: DarthSidius  
Дата: 27.10.14 04:50
Оценка:
Здравствуйте, alex_public, Вы писали:

_>И если снова проводить аналогию, то это наверное больше всего похоже на нативный код управляемый скриптом. Возможно за подобным будущее)


Нативный код тире ручное управление. Уже не в кассу. Так что не будущее, а прошлое.
... << RSDN@Home (RF) 1.2.0 alpha 5 rev. 58>>
♠♠♥♠♠♦♥
Re[70]: Nemerle через 5 лет - выстрелит или скончается?
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 24.11.15 10:25
Оценка: :)
Здравствуйте, DarthSidius, Вы писали:

_>>И если снова проводить аналогию, то это наверное больше всего похоже на нативный код управляемый скриптом. Возможно за подобным будущее)


DS>Нативный код тире ручное управление. Уже не в кассу. Так что не будущее, а прошлое.


Тренд последних лет — всё более глубокое управление нативными ресурсами с помощью скрипта, т.е. высокоуровневыми методами. Скажем, если раньше скриптом задавалось только поведение, то сейчас контролируется и многозадачность, и многопоточность, и IO, и многое другое. Естественно, раз мы используем скрипт, то вовсе не нужно писать createThread что бы использовать многозадачность
Re[4]: Nemerle через 5 лет - выстрелит или скончается?
От: QrystaL Украина  
Дата: 10.05.21 15:02
Оценка:
Здравствуйте, VladD2, Вы писали:
VD>https://github.com/rsdn/nemerle/commits/

Когда планируется мерж ветки https://github.com/rsdn/nemerle/tree/retarget-compiler в мастер?
Re[5]: Nemerle через 5 лет - выстрелит или скончается?
От: VladD2 Российская Империя www.nemerle.org
Дата: 11.05.21 20:26
Оценка:
Здравствуйте, QrystaL, Вы писали:

QL>Когда планируется мерж ветки https://github.com/rsdn/nemerle/tree/retarget-compiler в мастер?


Пока что не планируется. Они живут параллельно. В retarget-compiler компилятор на основе dnLib. В мастере на основе SRE. В dnLib недоделан плагин к ИДЕ и есть проблемы с дебаг-символами. Так что пока что для отладки и разработки используется компилятор из мастера, а для сборки под любую платформу из retarget-compiler. Если убрать эти две проблемы, можно в мастер будет перевести retarget-compiler, а поддержку СРЕшного отсновить. Но пока вот так.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.