Наболело:
21) Используйте мутабельные структуры. Все это любят.
22) Изменяйте значения входных аргументов функции. Все это любят ещё больше.
23) Передавайте в функцию побольше всего. Функция разберётся, что из этого ей надо. Передавайте разными аргументами. Половину — булевскими. Комбинируя сочитания для удобства.
Комбинируя?
Своими глазами видел десяток конструкторов в классе. Отличались они порядком параметров.
В ряде случаев он читабельнее, но это на мой взгляд.
Я думаю, что проблема в преждевременной оптимизации. Если команде нравится foreach/for/while/… — пожалуйста, пока это не пробивает производительность. Начинаются проблемы — только тогда надо микрооптимизацией заниматься. Иначе легко весь проект загубить.
Надо понимать плюсы и минусы каждого — и всё будет хорошо.
Как пример машин вне Тьюринга мне припоминаются нейронные сети. Вроде, даже слышал, что на них проблема самоостанова решается, но утверждать не берусь.
Ну, я считаю, что он и так остался почти один.
Столлман популяризирует free software (свободное), а большая часть программ, программистов и пользователей пользуются open software (открытым). Можно, конечно, собирать статистику, если есть желание.
Это большая разница, в «Revolution OS» об этом говорится, мол, Столлман требовал бесплатности программ, но кто-то там решил показать бизнесу, что тут можно зарабатывать — и создал опенсорс. Который взлетел.
Думаю, имеются в виду прыжки времени из-за шаловливых ручек пользователя. Помню, болтал по Skype и одновременно настраивал ntpd. Я отмотал время назад, и в итоге Skype показывал, что я разговариваю 1 000 000 часов. Всё остальное работало, что очень мне понравилось)
Или всем знакомые проблемы с SSL сертификатами, когда из-за кривого локального времени сертификат недействителен.
А, а ещё в *nix может возникнуть time paradox, при попытке удаления файла раньше, чем он был создан. (не проверял, кто сталкивался — буду рад узнать больше)
Я думаю, что менять параметры можно, однако слишком опасно: побочные эффекты могут проявиться из ниоткуда. Это же сильно нелинейная система — процедурный мир.
Как было подмечено выше, баш удобен потому что содержит сотню программ от grep до sox и perl, связи между которыми делают язык *sh гибким. «Всегда есть ещё один способ сделать X».
PowerShell на мой взгляд недотягивает. Через консоль по-быстрому задеплоить солюшн — ок. Попытка сделать клон *sh — явно нет: слишком многого недостаёт.
В дополнение предыдущему комментарию: я никогда не понимал, почему не упоминают в подобных списках мощную художественную литературу.
Мы — разработчики, мы делаем продукт для людей, и нам критично важно понимать, чего люди хотят. Более того, мы редко работаем поодиночке и намного чаще — командой. Нужны способы коммуникации.
Если работника в команде невозможно понять из-за кучи мусорных слов и бедного словаря — это проблема не ниже отсутствия мотивации. В первую очередь надо читать и осознавать Достоевского и Уайльда, Лондона, Пастернака в конце концов — я не видел ещё такого красивого русского языка, как в его письмах Цветаевой — и только потом книжки про правильное построение выступления.
Сложно успешно читать лекции и вести за собой людей, если ты нем.
Где-то в статье о геймдеве я прочитал хороший совет: «Писать прототипы, не обращая внимания на чистоту кода нормально, если после появляения убеждённости в том, что концепция работает, прототит будет выброшен. Вне зависимости от того, насколько он удовлетворяет заказчика».
Абсолютно согласен с данным отношением к proof of concept: доказано — перепиши начисто.
Я недавно попытался сделать меню на основе графа. Написал граф, привязал к нему меню. Граф-то рабочий, а вот меню юзать неудобно. Много кода при создании.
Спасибо за идею, надо будет обязательно попробовать вариант со машиной состояний.
Вообще меня удивляет, что в игровых фреймворках до сих пор нет вменяемого UI-комплекса. Казалось бы, вещь, которая всем нужна.
Всё зависит от кода, а точнее от его возраста, сложности и читабельности.
Я вот недавно дебажил легаси, который где-то глубоко-глубоко внутри сервера делал
switch (intVariable)
{
case 0:
GetA().Foo();
break;
case 1:
GetB().Foo();
break;
case 2:
GetC().Foo();
break;
// ...
}
А проблема в том, что классы A, B и C наследуются от одного предка и оверрайдят Foo(). То есть понять просто глядя на код, какой из методов вызовется, оч сложненько.
public abstract class AbstractScene
{
public abstract void Draw();
public abstract void Update();
}
public class StringScene : AbstractScene
{
public StringScene(string text)
{
this.Text = text;
}
public string Text { get; set; }
public override void Draw()
{
//...
}
public override void Update()
{
//...
}
}
public class IntScene : AbstractScene
{
public IntScene(int number)
{
this.Number = number;
}
public int Number { get; set; }
public override void Draw()
{
//...
}
public override void Update()
{
//...
}
}
//...
public class Game1 : Game
{
private AbstractScene scene;
protected override void Initialize()
{
this.scene = new StringScene("Ima scene"); // инициализировать логично сценой меню или загрузки.
base.Initialize();
}
protected override void Update(GameTime gameTime)
{
this.ReadKey(); // операции ввода и апдейт мира - две независимые операции. Интересно, кстати,
this.scene.Update(); // почему они не разделены на уровне движка?
base.Update(gameTime);
}
protected override void Draw(GameTime gameTime)
{
this.scene.Draw();
base.Draw(gameTime);
}
private void ReadKey()
{
if (Keyboard.GetState().IsKeyDown(Keys.S))
{
scene = new StringScene("Ima scene");
}
if (Keyboard.GetState().IsKeyDown(Keys.I))
{
scene = new IntScene(1);
}
}
}
Плюс такого подхода в том, что сцена инкапсулирует своё поведение, не давая свои поля на изменение в обход механизмов сцены. В большинстве случаев, такое поведение будет максимально корректным.
Основной минус подхода, предложенного в статье — это то упущение, что ничто — кроме голоса совести — не мешает мне поменять местами в свичах вызовы методов.
Спасибо за перевод. Часто пытаюсь представить, что было бы, увидь эти ребята те результаты своих работ, которые мы имеем сейчас. Понравился бы Ada Аде?)
21) Используйте мутабельные структуры. Все это любят.
22) Изменяйте значения входных аргументов функции. Все это любят ещё больше.
23) Передавайте в функцию побольше всего. Функция разберётся, что из этого ей надо. Передавайте разными аргументами. Половину — булевскими. Комбинируя сочитания для удобства.
Я думаю, что проблема в преждевременной оптимизации. Если команде нравится foreach/for/while/… — пожалуйста, пока это не пробивает производительность. Начинаются проблемы — только тогда надо микрооптимизацией заниматься. Иначе легко весь проект загубить.
Надо понимать плюсы и минусы каждого — и всё будет хорошо.
Кстати, а квантовый ассемблер относится к таким?
Знания медленно устаревают, а новички быстро плодятся.
Так что спасибо.
Столлман популяризирует free software (свободное), а большая часть программ, программистов и пользователей пользуются open software (открытым). Можно, конечно, собирать статистику, если есть желание.
Это большая разница, в «Revolution OS» об этом говорится, мол, Столлман требовал бесплатности программ, но кто-то там решил показать бизнесу, что тут можно зарабатывать — и создал опенсорс. Который взлетел.
Думаю, имеются в виду прыжки времени из-за шаловливых ручек пользователя. Помню, болтал по Skype и одновременно настраивал ntpd. Я отмотал время назад, и в итоге Skype показывал, что я разговариваю 1 000 000 часов. Всё остальное работало, что очень мне понравилось)
Или всем знакомые проблемы с SSL сертификатами, когда из-за кривого локального времени сертификат недействителен.
А, а ещё в *nix может возникнуть time paradox, при попытке удаления файла раньше, чем он был создан. (не проверял, кто сталкивался — буду рад узнать больше)
PowerShell на мой взгляд недотягивает. Через консоль по-быстрому задеплоить солюшн — ок. Попытка сделать клон *sh — явно нет: слишком многого недостаёт.
Но не прижилось. Вот тут уже интересно подумать почему.
Мы — разработчики, мы делаем продукт для людей, и нам критично важно понимать, чего люди хотят. Более того, мы редко работаем поодиночке и намного чаще — командой. Нужны способы коммуникации.
Если работника в команде невозможно понять из-за кучи мусорных слов и бедного словаря — это проблема не ниже отсутствия мотивации. В первую очередь надо читать и осознавать Достоевского и Уайльда, Лондона, Пастернака в конце концов — я не видел ещё такого красивого русского языка, как в его письмах Цветаевой — и только потом книжки про правильное построение выступления.
Сложно успешно читать лекции и вести за собой людей, если ты нем.
Абсолютно согласен с данным отношением к proof of concept: доказано — перепиши начисто.
Спасибо за идею, надо будет обязательно попробовать вариант со машиной состояний.
Вообще меня удивляет, что в игровых фреймворках до сих пор нет вменяемого UI-комплекса. Казалось бы, вещь, которая всем нужна.
Я вот недавно дебажил легаси, который где-то глубоко-глубоко внутри сервера делал
А проблема в том, что классы A, B и C наследуются от одного предка и оверрайдят Foo(). То есть понять просто глядя на код, какой из методов вызовется, оч сложненько.
Спасибо дебагеру)
Плюс такого подхода в том, что сцена инкапсулирует своё поведение, не давая свои поля на изменение в обход механизмов сцены. В большинстве случаев, такое поведение будет максимально корректным.
Основной минус подхода, предложенного в статье — это то упущение, что ничто — кроме голоса совести — не мешает мне поменять местами в свичах вызовы методов.
Теоретически, можно интерпретировать по-разному: от C++ до Delphi, емнип. Что сейчас с ним будет — хороший вопрос.