прочитал, в вики об этом языке. Чтож, кое-что в этом есть, но мне кажется перспективеней если уж на то пошло, создавать процы у которых нативный код джава. (такие уже были) Что касается того, что го может быть компилирован в объектный код, чтож, джава это тоже умеет. Здесь вопрос, либо Гугл имеет шкурные интересы двинуть свой язык, либо что-то принципиально важное. Однако, го имеет возможность создавать системные штуки, ну дак и джава это может посредством создания проца хавающие джава байткод, либо просто юзающий натив функции. , однако принесет что-то новое это вопрос.
Не знаю, может меня ща закидают подушками, но мне не нравится идея выполнения кода в jvm, не нравится идея интерпритации(компиляции в байткод) и много еще чего не нравится. Для ентерпрайза может это все круто, но для души - не очень Ну вот я щаз занимаюсь прощупыванием языка на предмет низкого уровня - стараюсь спускаться все ниже, пока язык позволит. Но как я понимаю, позволяет он даже загрузчики ОС писать.
Fail, а что тут такого. Не вижу криминала в том, чтобы не программить на сях и убогом якобы объектом языке спласплас, а просто программить на реально объектном языке. Ну и конечно оставить возможность программить на самом низком языке, которые понимает проц. Это маст хэв. Тогда, мы имеем с одной стороны полный контроль над машиной в виде объектного кода и высокоуровневый производительный язык которы позволяет быстро ваять нужные приложения. Думаю за этим будущее. Если конечно, что весьма вероятно, не возникнет более высокоуровневый язык вместо явы. Но не думаю, что голанд является таковым. Не по Сеньке шапка пока.
Так нет криминала, все верно. На голанге получается компактней код - много всего там под капотом напихано. Можно обрезать пакуемый в бинарь рантайм - есть такие утилиты из коробки. Можно взаимодействовать с библиотеками на сях, можно писать на асме. Можно равсокеты делать. Ну, скажем так, языком можно пользоваться в определенной близко-системной нише.
Си и Си++ мейнстримовские яп. Си++ это Си с классами, расширенная версия Си, не хотите юзать ООП, пишите в стиле Си используя структуры.
Ronin_, си плас плас это не объектный язык, как бы его не объявляли. Это улучшенный си. Скорось разработки доказывает это. Тут спорить не очем.
голанд ничего принципиально нового не предлагает. И это главное. принципиально новое будет тогда, когда программить будет еще легче и проще это и есть цель и тенденция. Наверное это будет образам. Скажем, программер говорит, хочу новый загрузчик ОС, от должен делать то-то и то-то, а детали уж пусть язык сам разруливает. Или, человек рисует окошко и говорит вот окошко в виде избушки на курьих ножках, хочу такую, и чтобы когда юзер нажал на створку дверки было действо такое и такое. Думаю, в помощь будет ии. Но при всем этом благолепии, должно сохранится доступ к самому объектому коду, для полного контроля, что там нам иск. интеллект нахерачил. Более того считаю, что доступ к коду процессора убережет человечество от искусственног интеллекта, если тот пойдет в разнос. Например, допустим искусственный интеллект решил нас порабатить, но некие хакеры, зная объектный код знают уязвимости искусственного интеллекта, затем побеждают его тем, что знают о нем больше чем он сам.
Ronin_, скорость разработки на яве в разы быстрее сплас пласа. Вы друг мой голос из прошлого. Замечательную ты демонстрируешь неувязку. ООп замачательное, но ява не нравиться из за привязки к ООп. Забавный фортель.
Давайте по порядку. Сейчас есть IDE которые облегчают написание кода и скорость часто не нужна, как в поговорке - "тише едешь, дальше будешь". ООП замечельно там где лучше не городить на структурах, а взять ООП. И в обратном случае где ООП не нужно, то писать в процедурном стиле и вот тут Java этого не умеет, поэтому и написал что привязка к ООП. Вы программист? Не хочу вас обидеть, но вы писали на старом васме что не программист.
Ronin_, я был не программистом, но теперь программирую не совсем на ооп. Это называется design patterns такие как сомманд, стейт, чен оф коммандс, но и то, все эти конструкции я изменяю в своих проектах. Надеюсь удовлетворил любопытство. Иде не панацея, если не врубаешься в архитектуруру. Дезайн паттерн предлагает общатся с программерами на одном языке. Ява легко может программит на процедурном языке. Это и нужно например, для доступа к сист. функам.
Вообще, я считаю прорывом будет, когда какой-нибудь язык из коробки (то есть штатный синтаксис) позволит и старыми методами выделать память на хипе (типа new/delete), и создавать garbage collected-объекты, которые сами будут удаляться, без всяких костылей типа shared_ptr, unique_ptr и т.д. Вот тогда поле непаханное будет: хочешь писать ентерпрайс - ваяешь классиики и в ус не дуешь, так как есть gc. Хочешь лоулевел - пишешь что-то си-подобное, где память выделяешь/освобождаешь сам.
Да поправят меня гуру программирования, после пару своих проектов я понял, что программист должен всего-то уметь: 1) создавать гуи приложения 2) уметь работать и разрабатывать базы данных 3) уметь работать с сетью(клиент-сервер) 4) это создание так называемых ER систем. Все это добро делается шаблонами, и желательно, чтобы программист создав основную архитектуру сделал это так, чтобы: -было понятно другим программерам. -легко расширяемо(опять дизайн паттерн в руки) -легко изменяемо. Используя шаблоны это легко достижимо. В общем во всем этом многообразии классов, я понял одно, что все они созданы, чтобы получать, обрабатывать и выдавать данные. Данные здесь ключевое слово. Ну а создав свою библиотеку шаблонов проектирования, создание сложных и больших проектов быстро уже проще. До Scrum and Agile я еще не дошел. что это на пальцах может кто-то объяснить без академического тумана?
neutronion_old_school, Программист должен уметь только одно - составлять эффективный алгоритм решения задачи. А то, что ты перечислил относится к говнокодерам, для которых программирование - это копание в документации фреймворка в поисках виджета, решающего возникшую задачу; если таковой найден не будет, поиск переносится на гитхаб и форумы, и если и там ничего подходящего не найдется, он решить эту задачу просто не в состоянии.
Ну, может джуниор или стажёр да. Настоящий же программист должен ещё уметь решать поставленные задачи оптимальным способом. Паттерны программирования - вещь очень опасная. Их нужно не только знать, но и своевременно отказываться от их применения. Далеко не всякое решение можно уложить в типовой паттерн. Проблема классов, как раз, в том, что они не масштабируются. Решая задачу средствами ООП, можно в десятки раз проиграть по производительности. Всё это абсолютное заблуждение. Scrum и Agile - это всего лишь методика разработки программного обеспечения, когда на этапе начала проекта сложно представить конечный результат, который получится. Однако за счёт того, что в первую очередь делаются наиболее важные вещи, ценность проекта быстро вырастает. Плюс чтобы иметь примерно предсказуемую динамику проекта его выполнение бьют на спринты (фиксированные промежутки времени в несколько недель), в течение которых закрываются несколько "хотелок" по проекту. По сути, все хотелки проходят декомпозицию на задачи так, чтобы задачу можно было выполнить в среднем за один день, а на следующий день отчитаться об успехах/неуспехах на стендапе. Таким образом сразу становится видно, где всё хорошо по срокам, а где - завал.
Three Big Lies in software development: http://cellperformance.beyond3d.com/articles/2008/03/three-big-lies.html
слишком общо, что конкретно там нужно уметь. Список в студию. Ну я и не юзаю их как они есть, во-первых приходится их комбинировать и изменять по свои нужды Не замечал, лагов пока в своих приложениях. ОБычно лагает какая-то одна часть. Легко исправляемо путем профайлинга и рефакторингом. Насчет масшабирумости, возможно и так, но для этого существуют паттерны которые маштабируются. Наверно это касается ER систем скорее. Пример маштабирования в студию. вот за это спасибо, доходчиво объяснил. Интересная технология и здравая.
Оптимизация бывает по разным критериям. Оптимизированная под одни требования задача будет совершенно неприемлима под другие требования. Программист от тех макак, что вы описали, как раз тем и отличается, что самостоятельно принимает решения о том, каким образом он будет решать задачу, а не будет кодить то, что ему скинули сверху в виде красивых UML-диаграмм. Наверное, вы никогда не имели дела с Big Data или тем случаем, когда стандартных средств ЯП уже не хватает для оптимального решения задачи и нужно переходить на лоулевел, задействуя всякие аппаратные фишки типа SIMD и ему подобных. В этом случае все ваши классы будут только мешать, а обычное представление данных в виде plain-массивов и bulk-операций с ними будут рулить. Потому что не проседает кэш и хип не дёргается постоянно, чем, кстати, и грешит ООП-подход. Кстати говоря, вы путаете рефакторинг с реинжинирингом, это говорит о вас как о хреновом проектировщике. В нормальном проекте рефакторинг осуществляется постоянно, а суть его заключается просто в переделке интерфейсов, переносе методов в другие единицы трансляции, переименований и прочих мелочей. Реинжиниринг - это смена алгоритма или протокола взаимодействия систем либо их внутренней организации. Пример масштабирования - любая, задача, касающася, в первую очередь, геймдева. Если вам нужно применить одно действие на куче игровых объектов, то гораздо эффективнее будет, если вы не будете дёргать один и тот же метод на 100500 объектах, которые у вас раскиданы по хипу чёрти как, а напишете функцию, которая примет массив из 100500 структур и применит трансформацию на каждом элементе в цикле. Последовательное чтение/запись памяти на современных процах работает значительно эффективнее за счёт присутствия механизма префетчинга данных в кэш из оперативной памяти. Не считаться с аппаратной платформой, на которой будет работать ваше приложение - это самый что ни на есть весомый просчёт проектирования системы в целом. Но enterprise-приложений это не касается, там заказчики готовы мириться с тем, что приложения требуют многоядерные серваки, жрут дохрена памяти, а работают при этом аццки медленно (в реальности скорость могла бы быть в разы выше). Конкретный пример херового дизайна - это Apache POI, которая котова ужрать всю вашу оперативную память, лишь бы был документ пожирнее. Но зато объектики, интерфейсы и все дела при нём.
rmn, Возможно я и говнокодер, но мне достаточно, что поставленные задачи мой говнокод решает, что я в нем разбираюсь даже после нескольких месяцев простоя, и легок к изменениям. Насчет умения эффективного алгоритма решения проблемы, для меня это звучит как требования некоторого эйч ар менеджера, который нахватался терминов и вот пишет объявление о вакансии для программеров сам того не зная, что значит программировать. По-моему скромному мнению, умение создавать архитектуру важнее всего в программостроении. А эффективных алгоритмов в сети уже такое кол-во, что через пять минут в гугле можно нарыть что хочешь. А вот архитектуру твоего конкретного приложения, кроме тебя батенька, никто и не ведает. Хорошая архитектура это база, на которой строй хоть какие алгоритмы. Ну например, паттерн стратегия, в ней любой может написать алго(плохой хороший, уродливый) это не важно, так как этот паттерн легко менят алгоритмы, если вдруг окажется что Вася Пупкин сморозил или ошибся или неэффективен.
