А пока такого языка нет — будем использовать то, что лучше подходит для наших текущих задач. И будем изучать и запоминать эти тонкости, чтобы не наступать на грабли. И будем ругать создателей, говнокодеров и самих себя за то, что чего-то где-то не учли из-за незнания особенностей реализации…
Неинтуитивно, неинтуитивно…
А использование указателей на массивы в Си интуитивно?
Вспомним, что Java уже живет достаточно долго, и является, фактически, переходником с C++. И создавался он не так масштабно (иначе бы шаблоны сразу включили в язык, и не парились бы потом с Generic'ами), просто потом оказалось, что без этого жить становится сложно.
Да, хотелось бы много чего, а много чего не хотелось бы… Может быть, ты именно тот, кто, наконец, напишет идеальный, интуитивный и быстрый язык, в котором не будет таких неприятных «мелочей», и все будет работать именно так, как ты ожидаешь?
Если ты или кто-то другой осилит такую задачу и не просадит производительности и т.д., то программерское сообщество его не забудет )
ИМХО, до сих пор удобнее использовать локальный клиент и регулярно забирать письма. Тем более что сейчас почтовики (например, TheBat) имеют мобильные версии, которые могут быть установлены на флэшку.
А ты их все читаешь? ) Или все-таки фильтруешь?
Просто интересно, насколько в реальности спам наносит ущерб времени, желательно в процентаже от времени просмотра почты.
Еще бы поднапрячься и умудриться посчитать его фактический заработок, и от него уже выставлять счетчик. А вот так, навскидку, получится примерно то же самое, как Microsoft считает потери от пиратства ) Т.е. считают, что вместо пиратской копии человек купил бы точно такой же лицензионный продукт, хотя в большинстве случаев это не так.
В дополнение: а вот каждой точке такого пространства уже можно присвоить численное значение по шкале «эмоциональное хорошо-плохо». Причем подчеркну, что эмоциональное — «рациональное хорошо-плохо» будет определяться другими факторами.
Всегда присутствует итоговая скалярная оценка по шкале «хорошо/плохо»
Не согласен. Более правильным является представление, где каждая эмоция представляет собой отдельный верктор в n-мерном пространстве. Какие-то из них можно взять за базисы, а остальные построить на них (одни эмоции являются ). В итоге эмоциональное состояние описывается точкой этого пространства.
Директор фирмы не определяет сроки. Он либо соглашается со сроками заказчика, либо может попробовать их подвинуть путем переговоров. Но последнее слово всегда за заказчиком. И если его Ваши сроки не устроят — проект уже не Ваш.
Серьезные проекты тоже заваливаются из-за невлезания в сроки и в бюджет. А предварительная оптимизация, увеличивающая время разработки, сильно бьет по этому параметру.
Правильнее всего локализовать код так, чтобы потом его можно было легко заменить на оптимизированный вариант, и оставить в таком виде. А когда дойдет до существенных нагрузок — вспомнить про такие места, искать среди них самые узкие — и исправлять их. А оптимизировать то, что отрабатывает один раз при старте системы, которая перезапускается раз в год — как правило, не самое лучшее решенеи.
Кстати, в топике не замечена одна важная черта хорошего алгоритма.
Он должен учитывать рефлексность врага и незнание того, какой ход ты сделаешь сейчас. За счет того враг отстает в своем «знании» на один ход, за который можно успеть захватить ключевую планету раньше него.
IMHO, тщательный алгоритм вычисления оценки позиции, а также просчет на несколько ходов вперед должен быть лучше, чем переключение стилей игры.
Пока еще не додумал учет истории и оптимальное распределение посылаемых кораблей между планетами. Где-то через неделю-другую планирую выложить то, что получилось.
А вообще после обдумывания алгоритма бота полезно посмотреть, как сейчас играют топовые боты. Насколько я смотрел — все мыслят примерно одинаково:
— Вначале захватим несколько ближайших планет
— Потом анализируем, чего хотим захватить
— Рассчитываем ход, на котором накопим нужную массу кораблей, и посылаем так, чтобы к этому ходу все корабли достигли места назначения
— Ключевые планеты, которые стремится захватить алгоритм — покрупнее и поближе к центру. Причем при этом часто пренебрегают нейстральными планетами, валяющимися рядом, хотя прирост кораблей на них за несколько ходов окупает захват.
— После захвата одной или нескольких ключевых планет картина начинает напоминать поток в сети — все корабли по оптимальному маршруту отправляются на ключевые планеты.
А использование указателей на массивы в Си интуитивно?
Вспомним, что Java уже живет достаточно долго, и является, фактически, переходником с C++. И создавался он не так масштабно (иначе бы шаблоны сразу включили в язык, и не парились бы потом с Generic'ами), просто потом оказалось, что без этого жить становится сложно.
Да, хотелось бы много чего, а много чего не хотелось бы… Может быть, ты именно тот, кто, наконец, напишет идеальный, интуитивный и быстрый язык, в котором не будет таких неприятных «мелочей», и все будет работать именно так, как ты ожидаешь?
Если ты или кто-то другой осилит такую задачу и не просадит производительности и т.д., то программерское сообщество его не забудет )
Integer.equals(int -> Integer)или
int == (Integer -> int)?
Просто интересно, насколько в реальности спам наносит ущерб времени, желательно в процентаже от времени просмотра почты.
Не согласен. Более правильным является представление, где каждая эмоция представляет собой отдельный верктор в n-мерном пространстве. Какие-то из них можно взять за базисы, а остальные построить на них (одни эмоции являются ). В итоге эмоциональное состояние описывается точкой этого пространства.
Правильнее всего локализовать код так, чтобы потом его можно было легко заменить на оптимизированный вариант, и оставить в таком виде. А когда дойдет до существенных нагрузок — вспомнить про такие места, искать среди них самые узкие — и исправлять их. А оптимизировать то, что отрабатывает один раз при старте системы, которая перезапускается раз в год — как правило, не самое лучшее решенеи.
Он должен учитывать рефлексность врага и незнание того, какой ход ты сделаешь сейчас. За счет того враг отстает в своем «знании» на один ход, за который можно успеть захватить ключевую планету раньше него.
Пока еще не додумал учет истории и оптимальное распределение посылаемых кораблей между планетами. Где-то через неделю-другую планирую выложить то, что получилось.
А вообще после обдумывания алгоритма бота полезно посмотреть, как сейчас играют топовые боты. Насколько я смотрел — все мыслят примерно одинаково:
— Вначале захватим несколько ближайших планет
— Потом анализируем, чего хотим захватить
— Рассчитываем ход, на котором накопим нужную массу кораблей, и посылаем так, чтобы к этому ходу все корабли достигли места назначения
— Ключевые планеты, которые стремится захватить алгоритм — покрупнее и поближе к центру. Причем при этом часто пренебрегают нейстральными планетами, валяющимися рядом, хотя прирост кораблей на них за несколько ходов окупает захват.
— После захвата одной или нескольких ключевых планет картина начинает напоминать поток в сети — все корабли по оптимальному маршруту отправляются на ключевые планеты.