Худший враг вашего кода

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

Надо переписовать с нуля. Версию номер 2.

Я где-то читал, что при поддержке ООП один человек в состоянии поддерживать около 10000 строк нерегулярного кода. Все, что больше, либо повторения, либо не поддерживается.

Плагинная технология решает.

> Я где-то читал, что при поддержке ООП один человек в состоянии поддерживать около 10000 строк нерегулярного кода. Все, что больше, либо повторения, либо не поддерживается.

1. Как можно поддерживать объектно-ориентированное программирование?

2. Что значит «поддерживать»?

3. Какой код называется нерегулярным?

Главный враг кода - это сложность ака complexity. Она может вызываться добавлением ненужных фич ака feature bloat, отсутствием мозга и непродуманной архитектурой, слишком сильными связями между компонетнами.

Всё это рассматривалось у Брукса и Рэймонда

Способы борьбы - уменьшение связи между компонентами, всевозможное упрощение и тд

Главный враг кода - создатель кода, во всех его проявлениях.

Брехня

 radws% find . -name '*.java'| while read f; do echo `wc -l $f` ; done | awk '{summ+=$1}; END {print summ}' 
30874 

спасибо, очень интересно написано

плагины, уменьшение связей ..

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

по-моему, он и так нашел решение всех проблем, когда говорил об Interpreter, нужен просто более высокий уровень. если не на много выше - то, может, хватит и «более мощного языка»

Domain-specific Language?

Стив Макконнелл, Совершенный код: «Главным Техническим Императивом Разработки ПО является управление сложностью.» (с)

в самой книге очень внятно и в подробностях разжевано что к чему.

> он говорит совсем про другое: что переход с джавы на более динамический язык

тот же Макконнелл приводит сравнительную таблицу функциональности операторов различных языков.
так вот если взять функциональность C за 1, то у Java будет 2.5, а у Python 6.

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

> Хотелось бы лучше понять слова Стива

«Статически типизированные языки сосут, динамически типизированные языки рулят». Причем статически типизированные языки рассматриваются на примере Явы.

По-моему, это тот самый Стив, который ниасилил Скалу.

ну да

>Статически типизированные языки сосут, динамически типизированные языки рулят

вермишель

нет. все, что он сказал - что не меняя логику, библиотеки и vm, можно уменьшить код, и объяснил зачем. и что у джавы не хватает «compression facilities» вроде шаблонов и макросов либо большей динамичностью.

>>Статически типизированные языки сосут, динамически типизированные языки рулят

вермишель

нет.

Если ты отвечаешь мне, цитируй только то, что я в самом деле сказао=л.

все, что он сказал - что не меняя логику, библиотеки и vm, можно уменьшить код

Ага, и совершенно случайно все его кандидаты на роль «Next Java» - динамически типизированные. Если читать внимательно, то это именно гон против статически типизированных языков.

у джавы не хватает «compression facilities» вроде шаблонов и макросов либо большей динамичностью.

Причем дальше речь идет только о динамичности.

Впрочем, если хочешь видеть то, что хочешь - ТНБ в помощь.

>нет. все, что он сказал - что не меняя логику, библиотеки и vm, можно уменьшить код, и объяснил зачем. и что у джавы не хватает «compression facilities» вроде шаблонов и макросов либо большей динамичностью.

Тут не все так просто, эти самые «compression facilities» тема для отдельного холивара. Я например сильно сомневаюсь, что повсеместное применение шаблонов и макросов сильно улучшат сопровождение сильно раздутого кода. Вполне может и наоборот, все сделать только хуже.

ИМХО большой оверхед раздутого кода всегда говорит о проблеме в архитектуре. И все сваливать на язык глупо. Плохому танцору ...

Что такое ТНБ?

> >нет. все, что он сказал - что не меняя логику, библиотеки и vm, можно уменьшить код, и объяснил зачем. и что у джавы не хватает «compression facilities» вроде шаблонов и макросов либо большей динамичностью.

Тут не все так просто, эти самые «compression facilities» тема для отдельного холивара. Я например сильно сомневаюсь, что повсеместное применение шаблонов и макросов сильно улучшат сопровождение сильно раздутого кода.

Да, серебрянной пули нет и одним «метапрограммированием» в виде шаблонов/дженериков/макросов сыт не будешь, и выехать на них не получится.

ИМХО большой оверхед раздутого кода всегда говорит о проблеме в архитектуре. И все сваливать на язык глупо.

Да, глупо. Самый простой пример - это студенческие поделки на Си/Си++/Ассемблере. 99% - каша. В прямом смысле. Но это всего лишь говорит о квалификации программиста.

> Что такое ТНБ?

Так Называемый Бог.

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

> ему для конкретной его игры хочется динамический

Но он не говорит «my game next language», он говорит «Next Java». Это называется «троллинг». Ну к примеру:

For dynamic systems you need dynamic languages.

Folks wondering if dynamic typing can work in «big» systems: the answer is that they don't get all that big, because of the dynamic typing.

еще стоит почитать статью Dynamical lang* strike back :)

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

> For dynamic systems you need dynamic languages.
по-моему, хорошая идея, не строить на статическом языке динамическую среду, а выбрать динамический язык и обходиться его средствами (он как раз вспоминал про лисп)

а так, да, немного пафосно

>> For dynamic systems you need dynamic languages.

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

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

Вот и Великий Ворчун Steve Yegge своими силами допетрил до философии suckless software.

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

Если без изменения языка - то соглашусь, хотя лисперы могут и поспорить. А если с изменением - MS успешного прошла в обоих направлениях, от динамики к статике в VB, и от статики к динамике в VB.NET. Другой пример - ActionScript, который EcmaScript с добавленой статической типизацией.

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

Common Lisp?

Ну вот, говорил же, что лисперы могут поспорить :-)

спецы по джаве, какие вообще преимущества дает jvm для написания _игры? автор ведь на ruby не стал бы писать, а о jruby думает

> от динамики к статике в VB

Когда это обычный VB был статическим? O_o Версию, пожалуйста.

Другой пример - ActionScript, который EcmaScript с добавленой статической типизацией.

Какая чушь... ECMAScript со статической типизацией - это уже другой язык, не ECMAScript. У него как минимум компилятор другой, и, вероятно, рантайм.

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

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

Common Lisp?

Говорят, компилятор что-то проверяет (опционально, без гарантий), и что с того? В стандарте описана проверка типов? Если нет, то это и не проверка, а добрая воля авторов конкретной версии компилятора.

>suckless software
а freeping ceaturing отменяется? тем более это игра

VB5 и VB6. И в натив компилил. Можно было написать в начале файла Option Explicit - и все, полная статика. Довелось на нем писать.

Какая чушь...

это уже другой язык, не ECMAScript

Ты читаешь вообще, что я пишу? Я же так и написал, с изменением языка. Вобщем то я написал, что согласен с тобой, а ты сразу чушь. Был лучшего о тебе мнения.

Ну и в дополнение - ActionScript обратно совместим с EcmaScript 3. То есть обычный js в нем вполне себе компилится.

Рантайм там не совсем другой, потому что tamarin, который адоб подарил мозилле, чтобы та его в фокс вставила. Вот здесь его пилят сейчас http://hg.mozilla.org/tamarin-central/.

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

> VB5 и VB6. И в натив компилил. Можно было написать в начале файла Option Explicit - и все, полная статика. Довелось на нем писать.

Не были они статически типизированными. Можно было написать имя проперти неправильно и получить ошибку на этапе выполнения.

это уже другой язык, не ECMAScript

Ты читаешь вообще, что я пишу? Я же так и написал, с изменением языка.

Я написал, что в динамический язык почти невозможно ввести статические проверки, а ты отвечаешь, что можно сделать новый язык. Да, можно, кто бы спорил.

Вот, так уже лушче. Насчет VB, ну я так хорошо в свое время на нем пописал, до сих пор помню. Когда ставишь Option Explicit - все типы в файле проверяет компилятор, не рантайм. Специально дизасемблировал, чтобы убедится, был call из таблицы виртуальных методов (COM же).

Второй вариант, когда ты мог получить в рантайме ошибку - это объявление переменно as Object. В этом случае да, делается GetIDsOfNames и потом Invoke, все правильно. Но это не динамический язык, это просто сахар для вызова динамики. В VB.NET сделано то же самое, не будешь же ты говорить, что он динамический.

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

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

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

> Насчет VB, ну я так хорошо в свое время на нем пописал, до сих пор помню. Когда ставишь Option Explicit - все типы в файле проверяет компилятор, не рантайм.

Я не буду спорить,потому что на VB писал, слава ТНБ, недолго (и давно). Но Option Explicit помню, и то, что она не спасала от опечаток, тоже помню.

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

Какое это отношение имеет к Стиву и его нытью? :) Он говорил о статических и динамических языках, не о гибридах.

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

>Но Option Explicit помню, и то, что она не спасала от опечаток, тоже помню.

Ну и добро, скорее всего дело было в Object, или еше в старых комках без type library, больше там вариантов нет.

Какое это отношение имеет к Стиву и его нытью?

Я эту статью давно читал, не помню уже, что именно там, поэтому Стива воспринимаю в целом. В Next Big Language он как раз и предлагал смешанный язык, с тонким намеком на ES4. Но увы, микрософт , эппл и яху завалили ES4, в котором должна была появится статика. Вместо этого они выпустили ES5, в котором вообще ничего не сделано фактически. Как великое достижение предподностся NativeJson, аж смешно. Ну ждем ES6, может в этот раз никто не помешает.

>в реальной жизни код на них быстро выродится в чисто динамический.

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

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

s/вмести/ввести/, надо спелчекер таки включить :-)

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

если так, то совсем неинтересно

Не говоря уже о том, что эклипс просто не сможет загрузить и проиндексировать проект такого размера (по словам стива). Хотя java-комьюнити постоянно твердит о том, что с приходом современных IDE размер кода не имеет значения

Если он так насиловал с особым ценизъмомъ свой Eee PC 701, то вполне возможно. А исходники Eclipse/Jboss миллион строк содержат? Их же как-то в эклипсе открывают. Мож, скачать, попробовать и убедиться что 64-битной жабе и 4гб озу это под силу?

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

*индексер

Ненене, я не про баги. Я чисто про объем, который не дает взлететь IDE у Стива Йягга

мало ли из-за чего у него он зависает на сутки :)

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

Если в качестве источника взять содержимое /dev/sda, то можно получить и более впечатляющие результаты. Которые, увы, исходного утверждения не опровергают...