Неосилятор ищет язык.

> Т.е. с чисто практической стороны удобнее и безопаснее интерфейсы имхо.

Только если вы предпочитаете статику. Я же предпочитаю динамику и чего вы так боитесь за свои ноги мне не понятно, у меня вот вроде все целы.

А позвольте поинтересоватся какое у вас там соотношение юнит тестов и ассертов(кб) к коду(кб) ? Мой опыт говорит что сильная динамика требует на порядок больше тестов чем статика. Но в общем да это дело привычки.

> сильная динамика требует на порядок больше тестов чем статика.

Мне не понятно, что значит требует. Для меня юнит-тесты это прежде всего:

1. Средство разработки дизайна системы
2. Механизм повышения производительности процесса разработки за счёт преодоления «проклятия выбора» (вместо пустых размышлений, постоянный кодинг)
3. Инструмент для тестирования логики.

Ни одна из этих целей не связана с отловом ошибок кодирования, но обычно они все выявляются при прохождении тестов. Правда, обычно ошибки кодирования я вылавливаю ещё на стадии экспериментов в REPL, так что каких-либо проблем именно с этим не имею вообще.

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

> Какого именно кода?

Такого, о котором идет речь последние пятдесят постов:

http://www.linux.org.ru/jump-message.jsp?msgid=6008391&cid=6017014

совершенно несвязанный класс, с тем же набором методов, с теми же сигнатурами, который возьмут и передадут (в функцию - L.O) и который тут совершенно не подходит?

> «проклятия выбора»

А это еще что такое?

> совершенно несвязанный класс, с тем же набором методов, с теми же сигнатурами, который возьмут и передадут (в функцию - L.O) и который тут совершенно не подходит?

Тогда внимательно смотри на этот код: http://www.linux.org.ru/jump-message.jsp?msgid=6008391&cid=6016720 — класс FAIL как раз такой, как ты просишь: подходит по сигнатурам, но реализует какую-то совсем свою семантику. И в этом же примере кода показано, что ежели забыть STATIC_CHECK'и, то объекты класса FAIL проглотятся «на ура».

> «статика vs динамика». Но это вопрос медицинский (к психологам), одним нравится один подход, а другим другой. Здесь нет технических аспектов, а только одни психологические.

Серьёзная заявка. ))

А как ты себе представляешь систему масштаба линуксового ядра написанную на динамическом языке? Я не про объём кода, я про процесс разработки в первую очередь.

> А как ты себе представляешь систему масштаба линуксового ядра

написанную на динамическом языке? Я не про объём кода, я про

процесс разработки в первую очередь.

А что не так? Лисп-машины то были, их же как-то делали. Или возьми те же SBCL или Clozure CL, которые написаны в основном на CL.

Я же просил _без_ шаблонов.

> Лисп-машины то были

При чём тут лисп-машины? Речь идет о разработке масштабного ПО.

> При чём тут лисп-машины? Речь идет о разработке масштабного ПО.

А это и было масштабное ПО, угу.

>Я же просил _без_ шаблонов.

А без шаблонов никак. Это очевидно.

>Я же просил _без_ шаблонов.

Напоминаю, речь шла о плюсовом аналоге вот такой конструкции: http://www.linux.org.ru/jump-message.jsp?msgid=6008391&cid=6016397

Как тут без шаблонов-то?

> А это и было масштабное ПО

Написанное на лиспе?

> , речь шла о плюсовом аналоге вот такой конструкции

А, ну да, верно.

> Написанное на лиспе?

Угу, поэтому они так и назывались, Лисп-машины, там было специально железо и весь софт на лиспе. К.О. в бешенстве.

> Лисп-машины, там было специально железо и весь софт на лиспе

Лисп-машины, было специально железо

Лисп-машины, специально железо

Лисп-машины, железо

железо

Я начинаю беспокоиться за К.О. Мне кажется, он нас покинул.

и весь софт на лиспе.

«весь» - это интерпретатор самого лиспа, надо полагать? Да еще и сделанный для специально заточенного под него железа? Ну, тут уж без вариантов, написать его на чём-то еще, кроме лиспа, шансов не было.

А теперь вернемся к _моему_ вопросу - как будет выглядеть разработка _крупного_ проекта (десятки разработчиков x десятки месяцев) на динамическом языке?

Статическую «утку» дать не могут, согласен. Динамическая утка вполне есть — man dynamic.

То есть ты будешь ловить в рантайме эксепшены, а я править ошибки после компиляции. Да, это хорошая замена.

Впрочем и статическую утку сделать можно на уровне компилятора языка (но это будет уже не C#, конечно).

Обязательно обсудим, когда появится этот чудесный язык.

Примеры вещей?

template< typename T > T try_repeat_in_powerful_sharp( T value ) { return sin( value ); }

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

Нельзя вызвать статический метод:

template< typename C > struct object { object() { C::created(this); } ~object() { C::destroyed(this); } }; 

template< typename T, int N > array { T items[ N ]; };

template< typename T > T * make() { return new T; }
template< typename T, typename T1 > T * make( T1 x1 ) { return new T( x1 ); };
template< typename T, typename T1, typename T2 > T * make( T1 x1, T2 x2 ) { return new T( x1, x2 ); };

template< unsigned  N > struct sum { static const unsigned value = N + sum< N - 1 >::value; };
template<> struct sum< 0 > { static const unsgigned value = 0; };

[quote]Можно пример, когда (при корректно настроеном runtime) компилятор «проглотит» generic код, а JIT не осилит создать instance'ы?[/quote] [code=cpp] using System;

namespace Fail { class Point< T > { Point(T x, T y) { X = x; Y = y; } public T X { get; private set; } public T Y { get; private set; } }

class PolarPoint { public PolarPoint(float r, float phi) { X = (float)(r * Math.Cos(phi)); Y = (float)(r * Math.Sin(phi)); } public float X { get; private set; } public float Y { get; private set; } }

public class Line< P, T > { public Line(T x1, T y1, T x2, T y2) { A = (P)Activator.CreateInstance( typeof(P), new object[] { x1, y1 } ); B = (P)Activator.CreateInstance( typeof(P), new object[] { x2, y2 } ); }

public P A { get; private set; } public P B { get; private set; } }

class Program { static void Main(string[] args) { var line1 = new Line<Point<double>, double>(0.0, 0.0, 0.0, 0.0); Console.WriteLine(line1); var line2 = new Line<PolarPoint, double>(0.0, 0.0, 0.0, 0.0); Console.WriteLine(line2); } } } [/code] Вдогонку: как сделать Line с одним параметром, чтобы избежать ошибок и как ввести в него свойство Length, например; [quote]Эти строки в студию?[/quote] Очевидно, что если ты боишься, что твою структуру, используют в каком-то шаблоне без ее согласия, что найдется функция, куда случайно кто-то передаст эту структуру, при этом случайно ее интерфейс совпадет с требуемым и пройдет проверку типов, то просто чуть усложни работу с ней: [code=cpp] template< class = void > struct fail { void f() {} void g() {} }; [/code] [quote]И этот человек будет мне рассказывать о не знание когда и как инстанцируются дженерики.[/quote] Под инстанцированием я имел в виду создание нового типа: Tuple.Create(new object()).GetType() != Tuple.Create(new int?()).GetType(). [quote]В MS CLR создается ровно 1 инстанс на все ref-type'ы (для value-types твое высказываение верно).[/quote] В C++ тоже самое. Все равно разбухание? [quote]Описаный тобой механизм используется(использовался?) в mono, но это поправимо (если еще не поправили, я давно не смотрел исходники).[/quote] Как поправимо? [quote]Преувеличиваешь. 97 метров (mono 2.10.1). И этот размер нужен 1 раз на все программы.[/quote] При фичах ты вспоминаешь об офтопной реализации, при размере - о моно. Давай остановимся либо на 850Мб/2Гб 4-го фреймворка, либо на компактной, но тормозной и текучей моно. И да, где моно по умолчанию установлено? Значит, этот размер приплюсуй к первой программе на моно, которую пользователь захочет установить.

Можно пример, когда (при корректно настроеном runtime) компилятор «проглотит» generic код, а JIT не осилит создать instance'ы?

using System;

namespace Fail
{
    class Point< T >
    {
        Point(T x, T y) { X = x; Y = y; }
        public T X { get; private set; }
        public T Y { get; private set; }
    }

    class PolarPoint
    {
        public PolarPoint(float r, float phi) { X = (float)(r * Math.Cos(phi)); Y = (float)(r * Math.Sin(phi)); }
        public float X { get; private set; }
        public float Y { get; private set; }
    }

    public class Line< P, T >
    {       
        public Line(T x1, T y1, T x2, T y2)
        {
            A = (P)Activator.CreateInstance( typeof(P), new object[] { x1, y1 } );
            B = (P)Activator.CreateInstance( typeof(P), new object[] { x2, y2 } );
        }

        public P A { get; private set; }
        public P B { get; private set; }
    }

    class Program
    {
        static void Main(string[] args)
        {
            var line1 = new Line<Point<double>, double>(0.0, 0.0, 0.0, 0.0);
            Console.WriteLine(line1);
            var line2 = new Line<PolarPoint, double>(0.0, 0.0, 0.0, 0.0);
            Console.WriteLine(line2);
        }
    }
}

Вдогонку: как сделать Line с одним параметром, чтобы избежать ошибок и как ввести в него свойство Length, например;

Эти строки в студию?

Очевидно, что если ты боишься, что твою структуру, используют в каком-то шаблоне без ее согласия, что найдется функция, куда случайно кто-то передаст эту структуру, при этом случайно ее интерфейс совпадет с требуемым и пройдет проверку типов, то просто чуть усложни работу с ней:

template< class = void >
struct fail
{
  void f() {}
  void g() {}
};

И этот человек будет мне рассказывать о не знание когда и как инстанцируются дженерики.

Под инстанцированием я имел в виду создание нового типа: Tuple.Create(new object()).GetType() != Tuple.Create(new int?()).GetType().

В MS CLR создается ровно 1 инстанс на все ref-type'ы (для value-types твое высказываение верно).

В C++ тоже самое. Все равно разбухание?

Описаный тобой механизм используется(использовался?) в mono, но это поправимо (если еще не поправили, я давно не смотрел исходники).

Как поправимо?

Преувеличиваешь. 97 метров (mono 2.10.1). И этот размер нужен 1 раз на все программы.

При фичах ты вспоминаешь об офтопной реализации, при размере - о моно. Давай остановимся либо на 850Мб/2Гб 4-го фреймворка, либо на компактной, но тормозной и текучей моно. И да, где моно по умолчанию установлено? Значит, этот размер приплюсуй к первой программе на моно, которую пользователь захочет установить.

> «весь» - это интерпретатор самого лиспа, надо полагать?

Ну пойди хоть просветись что такое лисп-машины, что на них делалось, ну и заодно что такое Xerox PARC.

> А теперь вернемся к _моему_ вопросу - как будет выглядеть разработка

_крупного_ проекта (десятки разработчиков x десятки месяцев) на

динамическом языке?

Отлично будет выглядеть. Можешь попробовать погуглить как DARPA делала «Dynamic Analysis and Replanning Tool» или как работает ITA Software.

> Можешь попробовать погуглить

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

> Это очень трогательно

Ты сомневаешься в том, что DART и Remote Agent это очень большие проекты, в разработке которых участвовали сотни инженеров?

> При чём тут неймспейс?

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

И?

А утиная типизация это по определению и есть возможность использования семантически аналогичного функционала у разных классов без указания на их аналогичность explicit. Но компилятор не может в семантику, он только на имя и сигнатуру метода может посмотреть. Что ведет к - см. выше. Так что это, в отличии от полноценных интерфейсов, не более чем кривой костыль.

> Соответственно, неймспейс засран.

Чего? Что значит засран? И почему «соответственно»? Что вообще не так то?

Что ведет к - см. выше.

Выше сказана что-то совершенно невменяемое.

Так что это, в отличии от полноценных интерфейсов,

не более чем кривой костыль.

В ваших словах логика не обнаружена.

Кстати, посмотри на defgeneric в CLOS и поймешь что такое полноценное решение и почему интерфейсы костыль.

template< typename T > T try_repeat_in_powerful_sharp( T value ) { return sin( value ); }

И какой профит в возможности написания заведомо некорректного кода?

Запарился писать, чего ни придет в голову - ничего нет. Как вообще тебе пришло в голову убогие дженерики всерьез сравнивать с темплейтами.

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

> Чего? Что значит засран? И почему «соответственно»? Что вообще не так то?

Он засран именем метода класса. Если типизация нормальная (как с интерфейсами) то ты можешь хоть в каждом интерфейсе по методу с тем же названием засунуть - все будет хорошо. А с утиной типизацией если у тебя класс реализует два одинаковых метода - значит он неявно реализует один интерфейс. И тебе метод придется переименовывать, если этого (реализации одного интерфейса) не предполагается. В варианте с интерфейсами за всем этим следит компилятор, при утиной типизации тебе придется делать это руками.

> Если типизация нормальная (как с интерфейсами) то ты можешь хоть

в каждом интерфейсе по методу с тем же названием засунуть - все

будет хорошо.

Потрясающее, вы предлагаете использоваться статическую типизацию как аргумент для запутывания кода программы? Компилятор может там чего-то и отследит, но только для поддержки всё равно придётся нанимать тех же самых индусов, которые этот код и писали.

Вообще, рассуждения просто левые и притянуты за уши.

Ну пойди хоть просветись что такое лисп-машины,

http://en.wikipedia.org/wiki/Lisp_machine

Lisp machines were general-purpose computers designed (usually through hardware support) to efficiently run Lisp as their main software language. In a sense, they were the first commercial single-user workstations. Despite being modest in number (perhaps 7,000 units total as of 1988[1]),

Как я и говорил,

The operating systems were written in Lisp Machine Lisp, InterLisp (Xerox) and later partly in Common Lisp.

что на них делалось

Ну так что же? Гугл молчит, а объём продаж внушают суеверный ужас и предположение, что всё, что на них делалось - разовые расчеты в лучшем случае и студентческие лабы - в худшем.

Будь бетменом, покажи _объемные_ програмные проекты на Lispe.

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

http://code.djangoproject.com/ticket/137

http://code.djangoproject.com/changeset/15611

> 850Мб/2Гб 4-го фреймворка

Тебе 2 рубля жалко?

>То есть ты будешь ловить в рантайме эксепшены, а я править ошибки после компиляции. Да, это хорошая замена.

...try_repeat_in_powerful_sharp...

Нельзя вызвать статический метод

Нельзя создать объект с нетривиальным конструктором

Ладно, уел. В C# static-утки нет, следовательно нет всего, что на нее намертво завязано.

Нельзя задать, что параметр дженерика - ValueType

Можно.

class SomeName<T> where T : struct {}

void SomeMethod<T>() where T : struct {}

нельзя специализировать дженерик

нельзя задать тип по умолчанию.

Нельзя. Но можно вот так:

class SomeClass<T1, T2> {}

class SomeClass<T> {}

Типы по-умолчанию точно заменит (хотя возможны каверзы вроде ненаследуемых аттрибутов).

Невозможно передать число

Любые вычисления во время компиляции

Это уже метапрограммирование. Да, generic'и для них не предназначены, есть более другие средства.

> A = (P)Activator.CreateInstance( typeof(P), new object[] { x1, y1 } );

Рефлексия. Так что ничего удивительного, что компилятор пропустил.

Вдогонку: как сделать Line с одним параметром, чтобы избежать ошибок и как ввести в него свойство Length, например;

Задача интересная, буду думать как решить.

то просто чуть усложни работу с ней:

Что-то не понял. Можешь пояснить свой код? С твоими изменениями проблема продолжает проявляться: http://codepad.org/iOFbQYbz

Под инстанцированием я имел в виду создание нового типа: Tuple.Create(new object()).GetType() != Tuple.Create(new int?()).GetType().

Не удивительно, ибо int? — value-type. А для них для каждого создается отдельный instance (по понятным, думаю, причинам).

В MS CLR создается ровно 1 инстанс на все ref-type'ы (для value-types твое высказываение верно).

В C++ тоже самое. Все равно разбухание?

Для каких типов в C++ создается 1 инстанс?

Как поправимо?

Сорцы в руки и вперед. Если это реализовано в MS CLR, можно сделать и в Mono. Не так там все страшно, в конце-концов.

При фичах ты вспоминаешь об офтопной реализации, при размере - о моно. Давай остановимся либо на 850Мб/2Гб 4-го фреймворка, либо на компактной,

Я упоминал оффтопную только в 1м моменте — способе инстанцирования дженериков. Хорошо, останемся с mono.

но тормозной

По сравнению с чем?

и текучей моно.

Прошу ссылку на описание утечек.

И да, где моно по умолчанию установлено? Значит, этот размер приплюсуй к первой программе на моно, которую пользователь захочет установить.

OpenSUSE, Ubuntu (ежели мне не изменяет память). Даже если не стоит — 1 раз поставить 100 мб не так и сложно.

> Потрясающее, вы предлагаете использоваться статическую типизацию как аргумент для запутывания кода программы?

При чем тут запутывание кода программы? У вас пересечение имен методов может случиться банально с классами некоторой библиотеки, или вы предлагаете при написании каждого метода шерстить сорцы каждой подключенной библиотки и проверять - а нету ли там метода с тем же именем? Успехов. Но вообще идея, конечно, замечательная. Как я уже сказал - вместо того, чтобы позволить решить проблему компилятору, лучше самим руками следить, чтобы, не дай боже, метод не оказался назван одинаково...

> У вас пересечение имен методов может случиться банально с классами

некоторой библиотеки

И что?

или вы предлагаете при написании каждого метода шерстить сорцы

каждой подключенной библиотки

Зачем?

Вы выдумали себе проблему, которой реально вообще нет.

> И что?

И то, что раз такой метод есть в библиотеке - вы не имеете права называть так свои методы.

Зачем?

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

> Ты сомневаешься в том, что DART и Remote Agent это очень большие проекты

Чувак, с 99 года утекло много времени, а на словосочетания «Remote Agent» гугл дает полтора ляма ссылок. Если ты уж откапываешь антиквариат, то давай хотя бы ссылки приличные. Твой DART я найти не осилил.

И да, почему я должен думать, что это большие проекты? Робототехника конца прошлого века опереровала проектами малой и средней величены.

Хотя я нисколько не сомневаюсь, что над софтиной работало куча народу, так как это был (и остался) единственный способ повысить надежность софта.

> Вы выдумали себе проблему, которой реально вообще нет.

плюсую, «страшно» представить во что превратился бы STL, если б пришлось решать эту «проблему»

П.С. если я конечно правильно понял суть

> Я, правда, не знаю, за каким хреном ты упёрся рогом в свой

несчастный лисп.

Млин, ты же сам просил привести аналог ядра Linux, я и привёл пример операционной системы + полноценной оконной системы (первой в мире) + много чего ещё на динамическом языке в одном флаконе. Других примеров реализации ядра операционной системы на динамическом языке я не знаю (но может они и есть).

Будь бетменом, покажи _объемные_ програмные проекты на Lispe.

Так чем DART не устроила?

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

софтверный bloatware в студии с во-от такими чудными ошибочками:

Не понял, вы таки утверждаете, что есть языки, софт на которых не содержит ошибок? И зачем вы там выше на ядро Linux ссылались? RoR или Django не являются аналогами. Или типа статически типизированный С (!), особенно тот, на котором пишут ядро, защищает от каких-то там ошибок???

> плюсую, «страшно» представить во что превратился бы STL, если б пришлось решать эту «проблему»

А с чего бы он должен был во что-то превратиться?

> Твой DART я найти не осилил.

Как страшно жить, прям не думал. Одна из самых известных программ в области искусственного интеллекта (в области планирования). Она управляла поставками американской армии во время первой войны в заливе. По результатам чего DARPA заявила, что одна эта программа многократно окупает все вложения агенства в область ИИ за предшествующие 30 лет. Я то думал, что это все знают.

словосочетания «Remote Agent»

Что, не слышал этой известной истории, когда спутник у другой планеты (забыл какой уже) под управление программы на лисп должен был выполнить серию экспериментов, как вдруг в программе обнаружилась ошибки. Славные специалисты NASA подключились к удалённому на сотни миллионов миль REPL, отладили и исправили программу, а им за это потом орден дали?

> ты же сам просил привести аналог ядра Linux, я и привёл пример операционной системы + полноценной оконной системы (первой в мире) + много чего ещё на динамическом языке в одном флаконе.

Ты это серьёзно? Ты действительно думаешь, что то, что крутилась на тех железках, и линуковое ядро - это в одной весовой категории? И DOS 3.0 это полный аналог Win7 ?

Так чем DART не устроила?

Тем, что я не смог её (или его?) нагуглить.

Не понял, вы таки утверждаете, что есть языки, софт на которых не содержит ошибок?

Как я люблю лоровских телепатов. Жаль, их модули не содержат никакой коррекции ошибок.

И зачем вы там выше на ядро Linux ссылались? RoR или Django не являются аналогами.

Я не говорю про анаглои по решаемым задачам. Я говорю про аналоги по объему труда. Еще раз медленно и печально: _большие_ проекты, _много_ разработчиков (не путать с тестерами, менеджерами, техписами и секретаршами).

Или типа статически типизированный С (!), особенно тот, на котором пишут ядро, защищает от каких-то там ошибок???

Расскажи, как те ошибки, на которые я дал ссылки, могли бы появиться в линуксовом ядре. Или не лев толстой.

> Что, не слышал этой известной истории, когда спутник у другой планеты (забыл какой уже) под управление программы на лисп должен был выполнить серию экспериментов, как вдруг в программе обнаружилась ошибки.

наверное оно:

http://ti.arc.nasa.gov/static/asanicms/pub-archive/archive/2000-0176.pdf

> Одна из самых известных программ

В узких кругах.

Она управляла поставками

Ок, специализированный пакет логистики, рабтающий в одном (прописью - одном) экземпляре.

Что, не слышал этой известной истории

Да плевать мне на историю. Я тебя не байки просил потравить, что ты всё с темы соскакиваешь? Я задал прямой вопрос - о применимости динамических языков в крупных проектах. Ты мне вместо аналогов (хрен с ним, с ядром) каких-нибудь MySQL, Firefox, Tomcat, Apache, 1C и иже с ними начинаешь травить какие-то пионерские страшилки. Скажи просто «Да, не знаю. Да, видимо, не применимы». Будь мужиком, блеать.

> Я не говорю про анаглои по решаемым задачам. Я говорю про

аналоги по объему труда.

Научитесь выражать свои мысли ясно или мыслить болеё чётко. Поскольку речь шла о возможности применения динамических языков для больших проектов, то стоило сослаться на что-нибудь другое. Потому что ссылка на ядро Linux в данном контексте совершенно не уместна. Ведь если такой большой проект, как ядро Linux, можно писать на C, то совершенно очевидно, что аналогичный по размеру проект можно спокойно писать вообще на любом языке - уже по любому будет лучше, чем на С, а на динамическом типа Python будет на много лучше (чем на C).

Так что будет считать, что вы сами ответили на свой вопрос в момент его постановки.

> Расскажи, как те ошибки, на которые я дал ссылки, могли бы появиться в линуксовом ядре. Или не лев толстой.

Затраты на исправление подобных «ошибок» не превосходят затрат на их исправление при статической отладке в том же Си.

Ты, питушок, покажи хоть один масштабный проект, над которым ты работал, или который сам написал.

Или не кукарекай, питушок.

> Ведь если такой большой проект, как ядро Linux, можно писать на C, то совершенно очевидно, что аналогичный по размеру проект можно спокойно писать вообще на любом языке

Совершенно не очевидно. Пруф в студию.

> Затраты на исправление подобных «ошибок» не превосходят затрат на их исправление при статической отладке в том же Си.

Я с этим нисколько не спорю. Вопрос только в том, когда именно эти затраты производятся - до коммита, или после.

И да, почему «ошибок» в кавычках? Это не ошибки, а корректный код?

> Ведь если такой большой проект, как ядро Linux, можно писать на C, то совершенно очевидно, что аналогичный по размеру проект можно спокойно писать вообще на любом языке - уже по любому будет лучше, чем на С, а на динамическом типа Python будет на много лучше (чем на C).

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