Внешний контекст определяет, где в программе будет точка входа.
“главный класс” указывается в манифесте
Может и не указываться, тогда с консоли вручную задаётся транслятору. Потому метод, видимо, и прибит гвоздями, чтоб не писать каждый раз в манифест.
У Джавы, стандартного исполняемого файла и нет
Мы же тут изначально сравнивали языки с Го, который (кроме jgo-like) компилируется прямо в бинарь, чем и выигрывает в микросервисах. И опенждк таки поддерживает теперь нативные сборки. Ранее можно было взять, например, ExcelsiorJet.
Так конечно, точка входа зависит от контекста. Но это не значит, что её нет. Каждый контекст определяет свою точку входа.
У стандартных исполняемых файлов всегда есть главная точка входа и может быть много второстепенных (инициализирующие вектора TLS). Это собственно и определяет необходимость метода main в программах на Си и на Яве. И стартовую инструкцию в машинном коде - собственно она и прописана в coff/elf-файле. Вопрос: как вы выбираете точку входа в Смолтоке? Это в режиме консоли-интерпретатора делается? Тогда всё равно начальная точка входа - запуск интерпретатора. В Прологе, например, тоже можно загрузить код, т.е. набор правил, и потом сделать произвольный запрос или даже ничего не делать. Но это в интерактивном режиме. В автономном режиме в итоге всё равно какая-то конкретная команда отдаётся. Если мы говорим о других контекстах, например драйверах, там точки входа - колбэки. Но в этом случае и драйвер нельзя стандартной программой назвать, а программа в этом случае - ядро ОС, и точка входа в неё тоже часто определяется используемым загрузчиком. Как-то давно ушли в прошлое времена, когда адрес запуска машины определялся вручную переключателями. Хотя кнопка РЕЗЕТ осаётся.
Я кажется понял очередную причину, по которой Ява фэйлит в современных облачных трендах. Если кто помнит, когда в начале 2010-х начала развиваться мода на облака, в Ява-мире, например, в Оракле, понимали это очень по-своему. Оракл предлагал принцип multitenancy - это когда на одном ява-сервере (в одной ява-машине) могут запускаться много клиентских приложений, причём в разных контекстах, изолированно друг от друга. То есть приложения - аналоги сервер-сайд апплетов, и как бы соседствуют. Изоляция обеспечивается SecurityManager-ом. Даже на уровне JPA начали вводить изоляцию в версии 2.2.
У меня в то время тоже были идеи по воплощению чего-то такого. В пределе - создание из ява-машины отдельной ОС как хоста для облака. У Орала заявка была в виде JRockitVM. См какие-то мысли здесь.
Но вернёмся к реалиям. Я как бы напомню (или просвещу), что и сервлеты, и ЕЖБ-бины задумывались как масштабируемые по горизонтали сущности, для них даже пулы были. Не говоря уж о пулах потоков и соединений.
Так вот это оказалось несостоятельным как раз потому, что не учли природу человека, как обычно. Людям ООП не нужно, им нужен Бейсик. Вот выясняется, что ООП - слишком сложно, поэтому лучше притащим монолитный Спринг и будем фигачить в процедурном стиле. Будем писать God-objects с 40+ методов на борту.
Вы как бывалый рыбак, наверное, знаете, что Спринг внутри построен на тех самых отрицаемых вами принципах ООП Явы, и активно использует глубокое наследование. Да Спринг превращает Яву в частично динамический язык, но сгенерированные инстансы при этом тоже наследуются от вашей "плоской" реализации. И всё же
Синглотоны - это тоже своего рода объекты.
Сессии разного рода - не синглтоны в нормальном случае. Если у вас только синглтоны, возможно, и Спринг вам не нужен.
Спринг - монолит, и изначально рушил всю систему модульности и объектности Явы (супротив е-бинов), почему и оказывается теперь в пролёте. Те же е-бины - полноценные объекты и множатся как сервлеты.
Не знаю, как у вас, а у меня даже синглтоны наследовали общий функционал, вынесенный в базовые классы и интерфейсы. Просто потому, что проще отнаследовать, чем писать портянки из кейсов. И класс для этого конечно нужен.
Главный метод - требование императивной сути самой архитектуры фон Неймана, а в теории объектов такого не было. По идее у них нет точки входа. И что-то я не помню, чтоб в Яве (в т.ч 21) эту принципиальную проблему устранили.
"Философия Ява" описывает базис языка, как он был задуман и должен был использоваться, поэтому при обсуждении ООП не устарела.
Ну так я же не говорю про вас конкретно. Вы сказали: считается. Значит считается кем-то, и для этих кого-то ООП слишком сложно. Если ООП сложно для упомянутого "Яндекс + нейро", то это вообще не показатель.
Ну почему же, Ява изначально заточено конкретно под ООП (см. "Философия Ява") и запрещает иной подход - даже главный метод должен был быть объявлен в классе. Статические методы очень не приветствуются.
О да, только ботов-экспертов мы тут и ждали все эти годы. А своё мнение есть? И если ООП сложно - тогда, простите, что вообще может быть просто? Может быть, ошибка в выборе профессии (в консерватории надо подправить)?
Вас же никто не принуждает писать на этих языках в стиле ООП, ну в плюсах как минимум, в Яве сложнее. Пишите на плюсах как на Си и будет вам счастье. Используйте столько ООП, сколько вам реально надо.
Хм, алгоритмы тоже можно разные применять для решения одной и той же задачи. Сколько существует алгоритмов сортировки? И кстати, именно полиморфизм часто выбирает более оптимальный алгоритм в той или иной ситуации. В виде наследования или шаблонов тех же.
Можно спорить по поводу является ли полиморфизм лишним или нет. Мне сложно представить себе Java Swing, переписанный без него. Хотя ГУИ есть даже на Прологе. А утиная типизация - конечно плюс.
Вы затрагиваете уже отвлечённые философские вопросы. Я не теоретизирую на эту тему. Рассматриваю прикладные проблемы - а ИИ это все-таки уже используемая прикладная сфера. Какая математическая модель должна использоваться и в какой сфере она применима - не мои вопросы, я не обладаю достаточной компетенцией, т.е. у меня нет научной степени. Но я хотя бы знаю про теоремы о расширении модели, и вверх и вниз. Ну а насчёт реализации математической модели - это программирование, и на эту тему можно написать не одну статью.
Я хочу заметить, что предложение было не оценивать "качество", а по сути участвовать в процессе вывода. Система правил, я думаю, примерно понятна: факты окружающего мира. Как оно будет реализовано - это уже второй вопрос. Я не просто так вспомнил Ватсона. Эта машина вроде как научилась верно отвечать на поставленные вопросы общего характера. Можно конечно придумать и другую систему правил: можно например вспомнить одно фантастическое произведение (на помню автора, Хаксли, м.б), где создали машину времени, перемещающую не в эту реальность, а в реальность мира, составленного из всех произведений фантастов. В общем, здесь фантазия не ограничена. Но мне кажется, наиболее практичной будет именно база знаний о реальном мире.
Очевидно, нет. Логика - это не поток (сознания или чего-то ещё). Логика - это чётко структурированные выводы. Я для этого даже картинку привёл. Посмотрите, там всего 2 абзаца. На самом деле, я пока так не делаю. У меня приложение на другом движке сделано, более древнем - диалинговском.
Я не углубляюсь столь глубоко в дебри математики. Думаю, что прикладной математики в виде чего-то наподобие Пролога вполне хватит. Сильно сомневаюсь, что система аксиом как-то сильно повлияет на приложение логики в данном случае. Я же здесь привёл аристотелевскую логику как предшественника матлогики (любой версии), чтобы показать мощь и выразительность языка.
Если нельзя не делать - то сделает отписку, но не бред. Она может быть ошибочной, даже фантазией на тему, но в ней будет осмысленное содержимое. Вранье должно быть убедительно, и это прекрасно знают все, кто врёт.
Нейросети будут убедительны только по форме, не по содержанию. Это как раз потому, что человек может оперировать на уровне семантики и выше, нейросеть - надёжно только на уровне синтаксиса и статистических закономерностей.
Опять же вы говорите "имя метода" - это слово, уровень морфологии-лексики, это детали. Человек мыслит не только слово, но и его конкретное значение И значение в данном контексте и глобальное значение понятия/явления. Может быть у других не так, но я представляю себе не набор букв, а что делает и для чего метод, имя которого я пытаюсь вспомнить. В конце концов, иногда можно будет даже написать метод заново исходя из его смысла, с другим именем.
У людей есть какое-то общее представление об устройстве мира и разных вещей, если не считать младенцев. Чем старше - тем больше опыт и желания судить обо всём на свете. Да, мнения часто даются не специалистами, но плохо это только тогда, когда оно преподносится как экспертное. А личное мнение может (и считаю, должен) иметь каждый.
Про эффект Манделы может и слышал, но не помню, расскажите, если не сложно и имеет отношение к теме.
Так различия как раз в том, о чём я писал: у нейронки нет логики, она работает на статистике. Не логика, а вероятность. У человека логика есть, он умеет размышлять (reasoning)
Внешний контекст определяет, где в программе будет точка входа.
Может и не указываться, тогда с консоли вручную задаётся транслятору. Потому метод, видимо, и прибит гвоздями, чтоб не писать каждый раз в манифест.
Мы же тут изначально сравнивали языки с Го, который (кроме jgo-like) компилируется прямо в бинарь, чем и выигрывает в микросервисах. И опенждк таки поддерживает теперь нативные сборки. Ранее можно было взять, например, ExcelsiorJet.
Так конечно, точка входа зависит от контекста. Но это не значит, что её нет. Каждый контекст определяет свою точку входа.
У стандартных исполняемых файлов всегда есть главная точка входа и может быть много второстепенных (инициализирующие вектора TLS). Это собственно и определяет необходимость метода main в программах на Си и на Яве. И стартовую инструкцию в машинном коде - собственно она и прописана в coff/elf-файле.
Вопрос: как вы выбираете точку входа в Смолтоке? Это в режиме консоли-интерпретатора делается? Тогда всё равно начальная точка входа - запуск интерпретатора.
В Прологе, например, тоже можно загрузить код, т.е. набор правил, и потом сделать произвольный запрос или даже ничего не делать. Но это в интерактивном режиме. В автономном режиме в итоге всё равно какая-то конкретная команда отдаётся.
Если мы говорим о других контекстах, например драйверах, там точки входа - колбэки. Но в этом случае и драйвер нельзя стандартной программой назвать, а программа в этом случае - ядро ОС, и точка входа в неё тоже часто определяется используемым загрузчиком.
Как-то давно ушли в прошлое времена, когда адрес запуска машины определялся вручную переключателями. Хотя кнопка РЕЗЕТ осаётся.
Я кажется понял очередную причину, по которой Ява фэйлит в современных облачных трендах.
Если кто помнит, когда в начале 2010-х начала развиваться мода на облака, в Ява-мире, например, в Оракле, понимали это очень по-своему. Оракл предлагал принцип multitenancy - это когда на одном ява-сервере (в одной ява-машине) могут запускаться много клиентских приложений, причём в разных контекстах, изолированно друг от друга. То есть приложения - аналоги сервер-сайд апплетов, и как бы соседствуют. Изоляция обеспечивается SecurityManager-ом. Даже на уровне JPA начали вводить изоляцию в версии 2.2.
У меня в то время тоже были идеи по воплощению чего-то такого. В пределе - создание из ява-машины отдельной ОС как хоста для облака. У Орала заявка была в виде JRockitVM. См какие-то мысли здесь.
Но вернёмся к реалиям. Я как бы напомню (или просвещу), что и сервлеты, и ЕЖБ-бины задумывались как масштабируемые по горизонтали сущности, для них даже пулы были. Не говоря уж о пулах потоков и соединений.
Так вот это оказалось несостоятельным как раз потому, что не учли природу человека, как обычно. Людям ООП не нужно, им нужен Бейсик. Вот выясняется, что ООП - слишком сложно, поэтому лучше притащим монолитный Спринг и будем фигачить в процедурном стиле. Будем писать God-objects с 40+ методов на борту.
Я сам лично сейчас рассматриваю Го как замену Яве, поэтому именно мнение Ява-программистов мне было более интересно.
К тому же Ява - один из самых выраженных классических объектных языков.
В Асме она есть, без этого никак.
Думаю, что и в смолтоке должна быть скрытая.
ну да, я конечно имел в виду классический Паскаль
Вы как бывалый рыбак, наверное, знаете, что Спринг внутри построен на тех самых отрицаемых вами принципах ООП Явы, и активно использует глубокое наследование. Да Спринг превращает Яву в частично динамический язык, но сгенерированные инстансы при этом тоже наследуются от вашей "плоской" реализации.
И всё же
Синглотоны - это тоже своего рода объекты.
Сессии разного рода - не синглтоны в нормальном случае. Если у вас только синглтоны, возможно, и Спринг вам не нужен.
Спринг - монолит, и изначально рушил всю систему модульности и объектности Явы (супротив е-бинов), почему и оказывается теперь в пролёте. Те же е-бины - полноценные объекты и множатся как сервлеты.
Не знаю, как у вас, а у меня даже синглтоны наследовали общий функционал, вынесенный в базовые классы и интерфейсы. Просто потому, что проще отнаследовать, чем писать портянки из кейсов. И класс для этого конечно нужен.
Главный метод - требование императивной сути самой архитектуры фон Неймана, а в теории объектов такого не было. По идее у них нет точки входа. И что-то я не помню, чтоб в Яве (в т.ч 21) эту принципиальную проблему устранили.
"Философия Ява" описывает базис языка, как он был задуман и должен был использоваться, поэтому при обсуждении ООП не устарела.
Ну так я же не говорю про вас конкретно. Вы сказали: считается. Значит считается кем-то, и для этих кого-то ООП слишком сложно. Если ООП сложно для упомянутого "Яндекс + нейро", то это вообще не показатель.
Ну почему же, Ява изначально заточено конкретно под ООП (см. "Философия Ява") и запрещает иной подход - даже главный метод должен был быть объявлен в классе. Статические методы очень не приветствуются.
-
О да, только ботов-экспертов мы тут и ждали все эти годы. А своё мнение есть?
И если ООП сложно - тогда, простите, что вообще может быть просто? Может быть, ошибка в выборе профессии (в консерватории надо подправить)?
Вас же никто не принуждает писать на этих языках в стиле ООП, ну в плюсах как минимум, в Яве сложнее. Пишите на плюсах как на Си и будет вам счастье.
Используйте столько ООП, сколько вам реально надо.
Хм, алгоритмы тоже можно разные применять для решения одной и той же задачи. Сколько существует алгоритмов сортировки? И кстати, именно полиморфизм часто выбирает более оптимальный алгоритм в той или иной ситуации. В виде наследования или шаблонов тех же.
Можно спорить по поводу является ли полиморфизм лишним или нет. Мне сложно представить себе Java Swing, переписанный без него. Хотя ГУИ есть даже на Прологе.
А утиная типизация - конечно плюс.
Вы затрагиваете уже отвлечённые философские вопросы. Я не теоретизирую на эту тему. Рассматриваю прикладные проблемы - а ИИ это все-таки уже используемая прикладная сфера. Какая математическая модель должна использоваться и в какой сфере она применима - не мои вопросы, я не обладаю достаточной компетенцией, т.е. у меня нет научной степени. Но я хотя бы знаю про теоремы о расширении модели, и вверх и вниз.
Ну а насчёт реализации математической модели - это программирование, и на эту тему можно написать не одну статью.
Я хочу заметить, что предложение было не оценивать "качество", а по сути участвовать в процессе вывода.
Система правил, я думаю, примерно понятна: факты окружающего мира. Как оно будет реализовано - это уже второй вопрос.
Я не просто так вспомнил Ватсона. Эта машина вроде как научилась верно отвечать на поставленные вопросы общего характера.
Можно конечно придумать и другую систему правил: можно например вспомнить одно фантастическое произведение (на помню автора, Хаксли, м.б), где создали машину времени, перемещающую не в эту реальность, а в реальность мира, составленного из всех произведений фантастов. В общем, здесь фантазия не ограничена. Но мне кажется, наиболее практичной будет именно база знаний о реальном мире.
Очевидно, нет. Логика - это не поток (сознания или чего-то ещё). Логика - это чётко структурированные выводы. Я для этого даже картинку привёл. Посмотрите, там всего 2 абзаца.
На самом деле, я пока так не делаю. У меня приложение на другом движке сделано, более древнем - диалинговском.
Я не углубляюсь столь глубоко в дебри математики. Думаю, что прикладной математики в виде чего-то наподобие Пролога вполне хватит. Сильно сомневаюсь, что система аксиом как-то сильно повлияет на приложение логики в данном случае.
Я же здесь привёл аристотелевскую логику как предшественника матлогики (любой версии), чтобы показать мощь и выразительность языка.
Если нельзя не делать - то сделает отписку, но не бред. Она может быть ошибочной, даже фантазией на тему, но в ней будет осмысленное содержимое. Вранье должно быть убедительно, и это прекрасно знают все, кто врёт.
Нейросети будут убедительны только по форме, не по содержанию. Это как раз потому, что человек может оперировать на уровне семантики и выше, нейросеть - надёжно только на уровне синтаксиса и статистических закономерностей.
Опять же вы говорите "имя метода" - это слово, уровень морфологии-лексики, это детали. Человек мыслит не только слово, но и его конкретное значение И значение в данном контексте и глобальное значение понятия/явления. Может быть у других не так, но я представляю себе не набор букв, а что делает и для чего метод, имя которого я пытаюсь вспомнить. В конце концов, иногда можно будет даже написать метод заново исходя из его смысла, с другим именем.
У людей есть какое-то общее представление об устройстве мира и разных вещей, если не считать младенцев. Чем старше - тем больше опыт и желания судить обо всём на свете. Да, мнения часто даются не специалистами, но плохо это только тогда, когда оно преподносится как экспертное. А личное мнение может (и считаю, должен) иметь каждый.
Про эффект Манделы может и слышал, но не помню, расскажите, если не сложно и имеет отношение к теме.
Так различия как раз в том, о чём я писал: у нейронки нет логики, она работает на статистике. Не логика, а вероятность. У человека логика есть, он умеет размышлять (reasoning)