Сергей Протько

перестаньте мыслить классами и все станет куда проще. На основе вашего списка выделите объекты, которые будут фигурировать в игре. Это будет:

- Клетка поля. У нее есть прямая связь с каждой из соседей и она знает есть на ней мина или нет. Так же для упрощения мы можем запихнуть в нее состояние мины (взорволась, обезврежена, необнаружена).
- Управляющая логика тоже должна где-то находиться. Назовем эту логику - контроллер. При указании координат клетки на поле, которую мы хотим нажать, мы должны отправлять этой клетке сообщение. Эта клетка уже в случае чего попросит соседние и так пойдет цепная реакция. В итоге все обязанности будут просто отслеживаться.
- Логика отображения. То есть что-то что берет текущее состояние игрового поля и будет заниматься его отображением на экран.

ruby-doc.org/core-2.2.0/Bignum.html#method-i-2D

нет. есть возможность оперировать переменными через функции instance_variable_get/instance_variable_set

Однако как и в случае PHP - это плохая практика. Используйте хэш-мэпы.

then - не обязательно писать и оно относится к ифу,

Правда что-ли? А из документации не понятно.

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

if user.isAbleToPay? then pay

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

Ruby - надо знать английский и переходить на unix-like операционки (linux, bsd, mac os).

PHP - можно ничего не знать, задачи всеравно будут.

Профит учить Ruby если все же хватит сил - у Ruby комьюнити есть определенная культура, в частности это самое любящее тестирование и TDD техники комьюнити из всех. В PHP с этим в среднем гораздо хуже... Так что решайте сами.

С Ruby есть риск надолго стать пленником RoR, с PHP - стать пленником устаревших статей, разных CMS-кой аля джумлы или друпалы, словом... фильтровать информацию от треша сложнее.

Идея транслятора была да чет как-то нет.

не говорите, что лучше на java!

Правда глаза режет?

jython или jruby

Для этих двух инструментов справедлива аксиома Эскобара в контексте вопроса.

https://github.com/damonkohler/sl4a

Имеет ли смысл осваивать php, или лучше сразу питон/руби?

Если вы сразу знаете что после PHP уйдете в Python/Ruby - то лучше сразу Python/Ruby. C PHP проще уходить в Java/C#.

а вообще очень неплохо было бы выучить два варианта из вашего списка. Или хотя бы попробовать хотя бы два (а лучше все три). Так как Python и Ruby в чем то похожи (Ruby был создан под влиянием perl и python) а учить python как-то приятнее, то рекомендую попробовать именно PHP и Python. А там уже думать.

Мое субъективное мнение о местах каждого из этих языков:
- Ruby - быстрая разработка, прототипирование, проекты с простой бизнес логикой
- Python - скрипты автоматизации, ресерчи, наукоемкие вычисления и все такое (ооочень большой выбор качественных библиотек на эту тему).
- PHP - тут есть два мира, один - wordpress и все подобное, другой - WEB приложения. скоро выходит PHP7 с тайпхинтингом для скаляров, хотят впихнуть структуры, словом PHP идет в сторону C# скорее. А так как объектная модель похожа на Java/C# то вся литература для этих языков (а ее оочень много хорошей) для PHP так же справедлива что проще в плане обучения. То есть из трех вариантов для чего-то сложного я бы выбрал именно PHP. А для чего-то попроще и под web - скорее уж Ruby.

Я знаю, PHP и Java

Вот из этого и выбирайте. Оба норм, под PHP проще чуть, но если Java знаете лучше (хотя тогда и с php нет проблем)... ну короче вы поняли.

То есть вы не заметили что в RoR пишут на Ruby а в PlayFramework на Java? Не заметили что это ну вот вообще принципиально разные языки? Я даже не знаю с чего начать... там различается все. Начиная синтаксисом и заканчивая идеологией.

Я думаю решений под Java для работы с миграциями выше крыши. Да и ORM лучше чем nHibernate еще поискать нужно... без понятия что значит "сделать нереально". Вы думаете AR в RoR даст вам больше власти? Может вы просто не умеете готовить PlayFramework?

Словом вопрос из разряда "Не знаю как правильно, июль или июнь".

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

А так вот довольно интересное решение основанное на атомарных операциях.

Мне не понятно почему в два раза дороже. Ладно бы там на 30% дороже, но в два? Сроки разработки этого проекта на Ruby даже чуть меньше, чем на PHP или приблизительно равны. Покрытие кода тестами и прочее сильно много разницы в сроках так же не дает.

Вывод, либо вы нашли разработчика на Ruby с завышеным рейтом, либо разработчика на PHP с рейтом в два раза ниже. Если второе, то стоит задаться вопросом, а хватит ли у него квалифакации? Может быть во время оценки он не учел покрытие кода интеграционными/функциональными тестами, может еще чего.

По хорошему стоимость не должна так уж сильно различаться. Рейт сильного Symfony девелопера не ниже рейта хорошего RoR девелопера. Сроки по вашему скудному описанию скорее меньше будут у RoR. Вывод, RoR должен обойтись дешевле. По возможностям Symfony больше подходит для долговременных проектов, он быстрее Ruby (на hhvm так прилично быстрее), но под RoR больше качественных готовых решений, что так же должно сократить сроки разработки.

Словом... мутно как-то. Опишите как вы получили "в 2 раза дешевле".

Вы про ключевое слово "yield"? Почитайте про генераторы.

Это все разруливается в рантайме. То есть до момента непосредственно вызова функции ( оператора) не известно что именно будет вызвано. Разбор же исходников, смею предположить, организован как и у всех посредствам AST.

supervisord

А вообще, не лучше ли найти причину подвисаний? Пусть лучше крешается а не виснет.

stackoverflow.com/questions/715604/why-do-dynamic-...

По сути в ruby/python не нужны абстрактные классы. Во всяком случае так считали авторы языков, основываясь на идее, что в этих языках все проверки на существование методов происходят в рантайме, ну и можно в рантайме подменять методы и много чего еще творить с классами.