А с чего волноваться, за пять будущих лет можно очень далеко уйти вперед в знаниях опыте и т.д.
Вполне возможно нужно наоборот радоваться т.к. будет проще найти себе сотрудников в будущем.
>>Одна из первопричин — это то, что операторы сами навариваются на фроде
Мне кажется что тут не все так просто, ведь деньги на счету — это деньги которые уже у оператора. При этом если человек потратит много на всяких мошенников, он скорее всего потратит меньше на звонки смс и т.д., а часть денег которые уже были у оператора, оператору придется отдать мошенникам.
Да это шучу я так :)
Сам одно время играл и по затраченному времени, поднялся на это диаграмме почти на самый верх,
но ощущения потом были, что в «яму» упал :)
Ошибки бывают разные, просрать почти все деньги фирмы «компания испытывает серьезные трудности с дальнейшим ведением бизнеса» фатальная за гранью по-моему :)
>>Преодолев определённый размер, процедурный проект стал лапшой, которую крайне сложно распутывать
Т.е. по вашему процедурный код в любом случае станет лапшой, а ООП никогда лапшой не станет?
>>ради этого и придумано ООП — части проекта мало связаны меж собой и их проще обновлять и изменять.
Т.е. по вашему декомпозиция в процедурном стиле вообще не доступна?
Это неплохая вообщем-то религия :)
Для того чтобы не напрягать пальцы есть IDE, а вот с сокращениями надо быть осторожным, ведь найдется кто-нибудь кто их сразу все использует, я вот в Perl с этим столкнулся, вы как-нить посмотрите на досуге, там даже аски-картины рисовать можно :)
На самом деле нормальных сравнительных тестов так похоже никто и не проводил на реальных задачах.
Ну т.е. написать одинаково хорошо один и тот же высоконагруженный проект на двух языках и посмотреть что будет.
А так конечно глупо сравнивать ROR к примеру c ORM и т.д. и т.п. с native PHP и чистыми sql запросами.
Мое чисто субъективное мнение, что PHP все-таки немного быстрее, чем к примеру Perl, но это вполне возможно связано с тем, что особенности PHP я знаю на порядок лучше.
Ну так на PHP тоже никто не мешает написать прямыми руками и хорошо оптимизировать. :)
А вообще, есть еще обработка больших объемов данных, приложения с постоянными соединениями где Java скорее всего будет уже намного более продуктивней.
Довольно очевидно как бы. Нет гравитации — меньше стрессов для организма. Меньше активности — опять же меньше стрессов. Где-то даже уже вроде было исследование на тему того, что лень немного помогает жить дольше. Ток вот толку в этих знаниях на практике.
По-моему не важно сколько, важно как.
Странная штука, странный судья, странное наказание.
Наверное судя людей, он по аналогии хочет отрезать немножко мозга или чего-нибудь еще.
И вообще фигня какая-то, не верю :)
Жестокое задание, вчера весь вечер думал, специально не ища ответов.
Выше я конечно, поторопился, налажал — не учел, что неразбившийся первый шарик можно использовать еще раз, но в любом случае у меня алгоритм получается далеко не самый эффективный, я бы такое собеседование не прошел :(
Да и на самом деле самолюбие можно засунуть подальше и узнать о своих минусах. Года четыре назад на собеседовании, потратив минуты три, мне человек обрисовал что со мной не так и куда мне двигаться, даже потом прислал подборку очень полезных ссылок. И вот так одно короткое собеседование стало полезнее даже чем значительное время практической работы.
Вполне возможно нужно наоборот радоваться т.к. будет проще найти себе сотрудников в будущем.
Мне кажется что тут не все так просто, ведь деньги на счету — это деньги которые уже у оператора. При этом если человек потратит много на всяких мошенников, он скорее всего потратит меньше на звонки смс и т.д., а часть денег которые уже были у оператора, оператору придется отдать мошенникам.
Сам одно время играл и по затраченному времени, поднялся на это диаграмме почти на самый верх,
но ощущения потом были, что в «яму» упал :)
Слово «яма» внизу смотрится, по-моему, совсем не гармонично :)))
Т.е. по вашему процедурный код в любом случае станет лапшой, а ООП никогда лапшой не станет?
>>ради этого и придумано ООП — части проекта мало связаны меж собой и их проще обновлять и изменять.
Т.е. по вашему декомпозиция в процедурном стиле вообще не доступна?
Для того чтобы не напрягать пальцы есть IDE, а вот с сокращениями надо быть осторожным, ведь найдется кто-нибудь кто их сразу все использует, я вот в Perl с этим столкнулся, вы как-нить посмотрите на досуге, там даже аски-картины рисовать можно :)
Ну т.е. написать одинаково хорошо один и тот же высоконагруженный проект на двух языках и посмотреть что будет.
А так конечно глупо сравнивать ROR к примеру c ORM и т.д. и т.п. с native PHP и чистыми sql запросами.
Мое чисто субъективное мнение, что PHP все-таки немного быстрее, чем к примеру Perl, но это вполне возможно связано с тем, что особенности PHP я знаю на порядок лучше.
А вообще, есть еще обработка больших объемов данных, приложения с постоянными соединениями где Java скорее всего будет уже намного более продуктивней.
По-моему не важно сколько, важно как.
Наверное судя людей, он по аналогии хочет отрезать немножко мозга или чего-нибудь еще.
И вообще фигня какая-то, не верю :)
Выше я конечно, поторопился, налажал — не учел, что неразбившийся первый шарик можно использовать еще раз, но в любом случае у меня алгоритм получается далеко не самый эффективный, я бы такое собеседование не прошел :(
Интересно, вот, а такое бы совсем не прокатило? За PHP извиняюсь :)
Очень часто был вопрос «почему вы решили поменять работу».