Java vs Kotlin
 |
Наши проекты:
Журнал · Discuz!ML · Wiki · DRKB · Помощь проекту |
|
| ПРАВИЛА | FAQ | Помощь | Поиск | Участники | Календарь | Избранное | RSS |
| [216.73.216.120] |
|
|
Правила раздела:
1. Название темы - краткое описание кто/что против кого/чего
2. В первом сообщении - список параметров, по которым идет сравнение.
3. Старайтесь аргументировать свои высказывания. Фразы типа "Венда/Слюникс - ацтой" считаются флудом.
4. Давайте жить дружно и не доводить обсуждение до маразма и личных оскорблений.
2. В первом сообщении - список параметров, по которым идет сравнение.
3. Старайтесь аргументировать свои высказывания. Фразы типа "Венда/Слюникс - ацтой" считаются флудом.
4. Давайте жить дружно и не доводить обсуждение до маразма и личных оскорблений.
Модераторы: Модераторы, Комодераторы
| Страницы: (8) « Первая ... 4 5 [6] 7 8 все ( Перейти к последнему сообщению ) |
Java vs Kotlin
|
Сообщ.
#76
,
|
|
|
|
Кто-то однажды показывал колбасню из тернарных операторов - вот это был пейзаж ада. А здесь всё банально и очень просто. Какой? Определение недетеминированного типа? Именно - простым. Как задача поставлена, так она и сделана. Цитата Guderian @ А если условие чуть усложниться? Надо будет, скажем, отдельный тип для простых чисел. На что unsigned заменишь, чтобы контроль не потерять? Ни на что. Проверка просто будет в конструкторе с выбросом исключения если не пройдёт. Как, кстати, надо было и здесь сделать с проверкой >0 для натуральных чисел, я просто торопился. А никто и не утверждал обратного. korvin повёлся на банальнейший вброс, но для демонстрации преимуществ динамической типизации выбрал из рук вон плохой пример - вот и всё, что тут было. |
|
Сообщ.
#77
,
|
|
  |
Цитата MyNameIsIgor @ Кто-то однажды показывал колбасню из тернарных операторов - вот это был пейзаж ада. А здесь всё банально и очень просто. Простота разная бывает. Если речь о лаконичности, то это скорее относится к примеру korvin, поскольку с ростом сложности приложения, сложность поддержки его natural типа не меняется. Если же речь идет о простоте, когда сортир - это яма и доска с дырками, то да, на данном этапе все выглядит просто. А стоит заглянуть на несколько ходов вперед - на каждом шагу заботливо положена грабелька)) Цитата MyNameIsIgor @ Какой? Определение недетеминированного типа? Забавный каламбур в форме диалога получается. Учитывая, что детерминированный - суть определенный (даже и в мыслях не было, что этот термин нуждается в трансляции) выходит: Guderian: ...неопределенный тип... MyNameIsIgor: Какой? Определение неопределенного типа? Просто термин динамического типа претерпел уже такую инфляцию, что язык не поворачивается его активно использовать. Взять хотя бы упоминавшийся dynamic из шарпа. Назвали динамическим прокси-тип который транслирует запросы к... опять же "статическим" типам. Цитата MyNameIsIgor @ Именно - простым. Как задача поставлена, так она и сделана. Не простым, а сильно редуцированным. Как только приложение начинает свой рост и возникает необходимость в перегрузке кастингов/операторов, аксессорах и т.п. - начнутся проблемы. If-ами на каждом шагу будешь в землю вгрызаться. Как думаешь, сколько девелоперов из 100 забудут при реализации операции вычитания проконтролировать натуральность ее выхлопа? Цитата MyNameIsIgor @ А никто и не утверждал обратного. korvin повёлся на банальнейший вброс, но для демонстрации преимуществ динамической типизации выбрал из рук вон плохой пример - вот и всё, что тут было. Пока даже на такой плохой пример не нашлось достойной альтернативной реализации. |
|
Сообщ.
#78
,
|
|
|
|
Цитата Guderian @ Простота разная бывает. Если речь о лаконичности, то это скорее относится к примеру korvin, поскольку с ростом сложности приложения, сложность поддержки его natural типа не меняется. Глухой write only mode... Цитата MyNameIsIgor @ А никто и не утверждал обратного. korvin ни словом не обмолвился о лаконичности решения. Он поставил под сомнение саму возможность решения. И для тех, кто не читает тему, в которую постит, сообщаю, что вот это говорил не я. Цитата Guderian @ Забавный каламбур в форме диалога получается. Учитывая, что детерминированный - суть определенный (даже и в мыслях не было, что этот термин нуждается в трансляции) выходит: Guderian: ...неопределенный тип... MyNameIsIgor: Какой? Определение неопределенного типа? Да, забавно. Оказывается, вы неплохо работаете в роли текстового препроцессора - смысла не понимаете, но find & replace работает "на ура". Цитата Guderian @ Просто термин динамического типа претерпел уже такую инфляцию, что язык не поворачивается его активно использовать. Взять хотя бы упоминавшийся dynamic из шарпа. Назвали динамическим прокси-тип который транслирует запросы к... опять же "статическим" типам. Ну, ясно, из пальца был высосан термин и сделано наивнейшее предположение, что уж все то его точно знают. Цитата Guderian @ Не простым, а сильно редуцированным. Как только приложение начинает свой рост и возникает необходимость в перегрузке кастингов/операторов, аксессорах и т.п. - начнутся проблемы. If-ами на каждом шагу будешь в землю вгрызаться. Как думаешь, сколько девелоперов из 100 забудут при реализации операции вычитания проконтролировать натуральность ее выхлопа? Какие сто программистов? Которые будут операторы юзать? А на кой им проверять то? Проверку пишут один раз в реализации оператора и кидают исключение, если она не прошла. А для ста программистов оператор либо выполнился и вернул заведомо валидный результат, либо не выполнился вовсе - никаких проверок. Цитата Guderian @ Пока даже на такой плохой пример не нашлось достойной альтернативной реализации. Возможно, не нашлось реализации, которая удовлетворила бы вас... Но это только ваши проблемы, меня никак не касающиеся. |
|
Сообщ.
#79
,
|
|
|
|
Цитата MyNameIsIgor @ Глухой write only mode... Цитата MyNameIsIgor @ И для тех, кто не читает тему, в которую постит Цитата MyNameIsIgor @ вы неплохо работаете в роли текстового препроцессора - смысла не понимаете Опаньки... трололо понеслось)) На что только не пойдут люди для того чтобы защитить свой кусочек кода. Ну и что, что не масштабируется и костылей не огребешь, он же ж свой)) Цитата MyNameIsIgor @ korvin ни словом не обмолвился о лаконичности решения. Он поставил под сомнение саму возможность решения. Единственная цитата korvin, которую я прокомментировал - это: Потому как код… никакой. Но Ваше желание его защитить любой ценой мне вполне понятны и простительны. С нетерпением жду следующего выброса эмоций на вентилятор)) Цитата MyNameIsIgor @ Ну, ясно, из пальца был высосан термин и сделано наивнейшее предположение, что уж все то его точно знают. "Под детерминированностью процессов в мире понимается однозначная предопределённость" (с) Вика. Встает вопрос, почему я не мог использовать этот термин применительно к типу, который не "предопределен однозначно"? Цитата MyNameIsIgor @ Какие сто программистов? Которые будут операторы юзать? А на кой им проверять то? Проверку пишут один раз в реализации оператора и кидают исключение, если она не прошла. А для ста программистов оператор либо выполнился и вернул заведомо валидный результат, либо не выполнился вовсе - никаких проверок. Под "реализацией операции вычитания" подразумевалась именно реализация, а не использование. Сто программистов были упомянуты для статистики, ибо на одном статистику не меряют. Если бы меряли, то она была бы 0% валидного кода, ибо Вы же даже не задумались над тем, чтобы проконтролировать вход конструктора. И так, наверняка, поступило бы больше половины. Доведись мне поддерживать такой класс, писанный другим человеком, и поставь передо мной задачу добавить ему операцию умножения на константу, я бы прошляпил проверки запросто. А если бы не прошляпил , то совершил бы ошибку, поскольку в какой-то момент времени меня подвела память и я было подумал, что натуральные=неотрицательные)) Цитата MyNameIsIgor @ Возможно, не нашлось реализации, которая удовлетворила бы вас... Но это только ваши проблемы, меня никак не касающиеся. Я знаю, что это мои проблемы. Мои и моих заказчиков, которые частенько приходят ко мне с таким кодом, что без слез и не взглянешь. А все потому, что некие кодеры до меня решили, что проблемы, с которыми они не столкнулись сейчас - это проблемы тех разработчиков, что будут потом. И дальше одного хода в это программной партии они не видят. |
|
Сообщ.
#80
,
|
 |
Что именно? Тот же "неосилимый" полиморфизм, только в статике. Что пояснить?
|
|
Сообщ.
#81
,
|
|
|
|
Цитата Guderian @ Опаньки... трололо понеслось)) Т.е. перевернуть всё с ног на голову и сделать вид невинной овечки "я не понял, что с меня просят определение термина" - это "трололо понеслось))" в вашей терминологии. Продолжайте в том же духе, я начинаю запоминать ваши термины. Цитата Guderian @ На что только не пойдут люди для того чтобы защитить свой кусочек кода. Ну и что, что не масштабируется и костылей не огребешь, он же ж свой)) Цитата Guderian @ Потому как код… никакой. Ах, так вы, оказывается, вовсе не про возможность решения разговариваете, а про мой код? Впрочем, после кухонных терминов я должен был догадаться... Ну, давайте обсудим мой код, но прежде реализуйте заявленный вами функционал (т.е. с операторами) на любом языке программирования, я не настаиваю на статически типизированном. Цитата Guderian @ "Под детерминированностью процессов в мире понимается однозначная предопределённость" (с) Вика. Встает вопрос, почему я не мог использовать этот термин применительно к типу, который не "предопределен однозначно"? Защищать свой родной кухонный термин - ведь так это называется в вашей терминологии. Ну, что же, разжёвываю. Во-первых, термин "недетерминированный тип" не общепринятый, вы его сами придумали, и я не собираюсь предполагать, что именно вы под ним подразумевали. Во-вторых, он вполне определён однозначно, просто проверяется во время исполнения, а не компиляции. Как вам пришла мысль, что динамическая типизация недетерминирована, я даже предположить боюсь. Цитата Guderian @ Под "реализацией операции вычитания" подразумевалась именно реализация, а не использование. Сто программистов были упомянуты для статистики, ибо на одном статистику не меряют. Если бы меряли, то она была бы 0% валидного кода, ибо Вы же даже не задумались над тем, чтобы проконтролировать вход конструктора. И так, наверняка, поступило бы больше половины. Доведись мне поддерживать такой класс, писанный другим человеком, и поставь передо мной задачу добавить ему операцию умножения на константу, я бы прошляпил проверки запросто. А если бы не прошляпил , то совершил бы ошибку, поскольку в какой-то момент времени меня подвела память и я было подумал, что натуральные=неотрицательные)) Об этом мы поговорим после того, как вы покажете свою реализацию как я просил выше. Цитата Guderian @ Я знаю, что это мои проблемы. Мои и моих заказчиков Так вот и идите... решать их. |
|
Сообщ.
#82
,
|
|
|
|
Эх, холивары, они такие холивары)) Приступим к утренней разминке)
Цитата MyNameIsIgor @ Т.е. перевернуть всё с ног на голову и сделать вид невинной овечки "я не понял, что с меня просят определение термина" - это "трололо понеслось))" в вашей терминологии. Продолжайте в том же духе, я начинаю запоминать ваши термины. Поделюсь своими наблюдениями. Есть несколько категорий людей. Первые - самые мудрые, они быстро расшифровывают определение термина и дальше рубят по сути вопроса, не останавливаясь на мелочах. Вторым нужно объяснить, но после этого они уже берут быстрый старт. Третьим - сколько не объясняй. Из ваших пяти абзацев три касаются в той или иной степени термина. Это ж какое отсутствие аргументов надо иметь, чтобы так увлечься этим вопросом)) Но коль скоро он так Вас беспокоит, то каюсь. Использовал уродливый неологизм. Видимо, на это повлиял тот факт, что техническую литературу приходиться читать исключительно на англицком, а там фраза "determin{e|ed|ing|etc} type" в порядке вещей. Тот же драфт на C++0x - это ж пытка для моего неопытного ума: Цитата "Some objects are polymorphic (10.3); the implementation generates information associated with each such object that makes it possible to determine that object’s type during program execution. For other objects, the interpretation of the values found therein is determined by the type of the expressions (Clause 5) used to access them." Знакомая ситуация, правда? Кто-то недавно использовал полиморфизм в своем примере, чтобы "determine that object's type". Хотя хотелось бы, чтобы тип "determined by the type" выражения. А уж в разделе declarations/declarators от determine просто спасу нет: Цитата First, the decl-specifier-seq determines a type. In a declaration T D the decl-specifier-seq T determines the type T. [ Example: in the declaration int unsigned i; the type specifiers int unsigned determine the type “unsigned int” (7.1.6.2). —end example ] От такого засилия фраз, что тип детерминирован, я невольно привык его употреблять равно как и термины дефинитивный, декларативный, императивный и еще вагон других. Извиняюсь за свой, как Вы выразились "кухонный термин", навеянный прочтением стандартов и искренне надеюсь, что я был исчерпывающ в своем извинении)) Цитата MyNameIsIgor @ Ах, так вы, оказывается, вовсе не про возможность решения разговариваете, а про мой код? Я искренне полагал, что только я в "глухом write-only", как Вы изволили выразиться... А то, что я Вам адресовал, начиналось с цитаты korvin касающейся конкретного кода и моей фразы "Пример был…". Постараюсь в следующий раз сопровождать дополнительными указателями, подсказками, сигнальными флажками и т.п. Цитата MyNameIsIgor @ Ну, давайте обсудим мой код, но прежде реализуйте заявленный вами функционал (т.е. с операторами) на любом языке программирования, я не настаиваю на статически типизированном. Если я буду реализовывать на привычном мне шарпе, то у меня получится та же херня с теми же проблемами. И как я говорил ранее, не поможет даже dynamic. Так что, как бы это ни было для меня унизительно, я не смогу написать код лучше чем Ваш)) Я бы даже сказал по-другому. Это не столько проблемы того самого кода, поскольку он, по сути, выжимает все возможное из имеющихся средств и попросту аккумулирует классику ООП - полиморфизм + идея паттерна Factory Method. Проблема в самом ооп. А как на ооп-языках со статической типизацией написать лучше - я не знаю. Может быть я и сделал немного по-другому, но это больше нацелено на то, чтобы застелить все соломой и дизайн стал bulletproof. А концептуально - такая же херня)) Цитата MyNameIsIgor @ термин "недетерминированный тип" не общепринятый Не в защиту термина, а просто лингивистических размышлений цепочка: "тип" - общепринятый, "детерминированный" - общепринятый, а "не детерминированный тип" - не общепринятый)) Интересно, является ли общепринятым "синий икосаэдр"... Цитата MyNameIsIgor @ Во-вторых, он вполне определён однозначно, просто проверяется во время исполнения, а не компиляции. Как вам пришла мысль, что динамическая типизация недетерминирована, я даже предположить боюсь. Полиморфный костыль под названием number - это "определен однозначно"? Тогда в шарпе/яве "object x = любая_херня_хоть_число_хоть_строка" - это тоже однозначное определение. Ну и что, что всё есть object, использован тот же принцип. Ввели предка (Ваш класс number), определили его наследников (Ваши же integer, natural) и решили, что тип number, лежащий в корне иерархии наследования (не его ли вычислит auto?) - это однозначное определение. Т.е. неоднозначности integer это, или natural вообще не возникнет? Тогда добавьте, плиз, в natural метод foo и вызовите number->foo(). Посмотрим, так ли се "однозначно". Цитата MyNameIsIgor @ Так вот и идите... решать их. Не бздеть, у меня все под контролем)) А вообще, если отвлечься немного от холивара, то мне кажется имеет смысл говорить не о статическом и динамическом определении типов, а о декларативном и императивном. Если предикат вычислим во время компиляции, то это суть константа и здесь плюсЫ со своими возможностями метапрограммирования будут биться на равных. Значит плавно перетекаем в рантайм, где осуществляется вычисление предиката со всеми сопутствующими механизмами контроля. Но в случае с декларативным определением, транслятор имеет генеративные возможности по самостоятельному формированию необходимого контроля. А императивно мы сами должны его обеспечить, что не есть гут. |
|
Сообщ.
#83
,
|
|
|
|
Цитата Guderian @ Видимо, на это повлиял тот факт, что техническую литературу приходиться читать исключительно на англицком, а там фраза "determin{e|ed|ing|etc} type" в порядке вещей. Тот же драфт на C++0x - это ж пытка для моего неопытного ума: <и далее по тексту> Ваш ум действительно неопытный, если вы так и не поняли, что в приведённых цитатах нигде нет термина "детерминированный тип". Там есть только глаголы, относящиеся к прилагательному "тип": "определить тип", "определяется типом", "определяет тип". Надеюсь, вашего опыта использования русского языка хватит, чтобы понять разницу. Цитата Guderian @ Полиморфный костыль под названием number - это "определен однозначно"? А при чём тут моя реализация? Тип вполне однозначно определён и в примере korvin'а. Просто потому, что он однозначно определён уже в задании: это либо натуральные числа (надеюсь, не будете спорить, что это однозначное определение), либо целые (так же искренне надеюсь, что разночтений не возникнет). Цитата Guderian @ Тогда в шарпе/яве "object x = любая_херня_хоть_число_хоть_строка" - это тоже однозначное определение. Ну и что, что всё есть object, использован тот же принцип. Ввели предка (Ваш класс number), определили его наследников (Ваши же integer, natural) и решили, что тип number, лежащий в корне иерархии наследования (не его ли вычислит auto?) - это однозначное определение. Т.е. неоднозначности integer это, или natural вообще не возникнет? Тогда добавьте, плиз, в natural метод foo и вызовите number->foo(). Посмотрим, так ли се "однозначно". Вы в очередной раз путаете Божий дар с яичницей. Вы говорите не об определении типа, а о типизации. Во-первых, динамическая типизация вполне себе детерминирована. Во-вторых, по вашему выходит, что любой класс, который имеет (может иметь) наследников, является неопределённым типом, что есть явная чушь. Цитата Guderian @ Но коль скоро он так Вас беспокоит, то каюсь. Использовал уродливый неологизм. Цитата Guderian @ Извиняюсь за свой, как Вы выразились "кухонный термин", навеянный прочтением стандартов и искренне надеюсь, что я был исчерпывающ в своем извинении)) Я очень рад, что вы искренне раскаялись. Я подумаю над тем, принять ли ваши извинения. Если решение будет положительным, я сообщу вам отдельно. Цитата Guderian @ Третьим - сколько не объясняй. Наконец-то здравая мысль с вашей стороны. Я ею воспользуюсь и перестану вам что либо объяснять. Не обижайтесь, но надоедает даже такое увлекательное занятие, как кидать горох в стену. |
|
Сообщ.
#84
,
|
|
 |
Самое интересное, что спор на самом деле не имеет отношения к статической или динамической типизации.
Ясно, что независимо от вида типизации значение неизвестное во время компиляции, можно проверить только в рантайме. С другой стороны, чтобы выполнить проверку при компиляции транслятор должен поддерживать глубокую интерпретацию константных выражений (в том смысле, что должен уметь вычислять не только простые выражения, но и доступные для интерпретации функции/процедуры). Опять же, независимо от вида типизации язык может при этом иметь или не иметь средства для прерывания компиляции в таком случае. В общем дело упирается в наличие нужных средств управления компиляцией, а не в статическую/динамическую типизацию. |
|
Сообщ.
#85
,
|
|
|
|
Цитата MyNameIsIgor @ Ваш ум действительно неопытный, если вы так и не поняли, что в приведённых цитатах нигде нет термина "детерминированный тип". Там есть только глаголы, относящиеся к прилагательному "тип": "определить тип", "определяется типом", "определяет тип". Надеюсь, вашего опыта использования русского языка хватит, чтобы понять разницу. Не знаю, насколько опыт русского языка применим к документации на английском, а вот опыт последнего мне подсказывает, что форма инфинитива, на которую вы ссылаетесь, применительно к той ситуации в которой я этот термин употреблял, находится в форме страдательного залога и звучит как determined (в примерах, что я приводил - "determined by the type of the expressions"). И тут на арену выходят правила русского языка, ибо страдательный залог трансформируется в страдательное причастие, которое в русском языке звучит как "детерминированный". Вот такая адъективация получилась. Надеюсь, я не очень сложно объяснил мыслительные процессы своего неопытного ума?)) Цитата MyNameIsIgor @ А при чём тут моя реализация? Потому что, как я сказал предыдущие пятьдесят четыре раза, я обсуждал именно этот пример реализации. Цитата MyNameIsIgor @ Вы в очередной раз путаете Божий дар с яичницей. Вы говорите не об определении типа, а о типизации. Во-первых, динамическая типизация вполне себе детерминирована. Я всегда думал, что определение типа - это главный инструмент типизации и весь тред с того момента, как забили на Kotlin, строиться вокруг того, что динамическая типизация позволяет использовать предикаты, вычисляемые в рантайм, для определения типа. Динамическая типизация - да, детерминирована. В инструкции по ее использованию. Динамический тип тоже детерминирован. В момент присвоения переменной этого типа значения. Цитата MyNameIsIgor @ Во-вторых, по вашему выходит, что любой класс, который имеет (может иметь) наследников, является неопределённым типом, что есть явная чушь. Согласен. Ваша фраза "класс является неопределенным типом" - полная чушь, ибо класс является вполне определенным типом. Я бы даже сказал, что он и есть тот тип, которым является)) А есть также экземпляр этого класса и он тоже вполне определенного типа. Типа этого же класса. А есть декларация, которая принудительно указывает экземпляру этого класса некий полиморфный тип. Это может быть number, а может вообще абстрактный указатель. Так что вы получите в результате? Определенный тип или декларированный тип с некоторым контрактом number, который вы хотите получить от значения, тип который вам доподлинно неизвестен? Если вы уверены, что тип определен, то вызовите foo() специфицированного в natural, как я предложил. Лисп это может (он, правда, и крякать натуральное число может заставить, но это отдельная тема), а вы без дополнительного определения через кастинг? Я бы все-таки различал определение типа и декларирование. Цитата MyNameIsIgor @ Не обижайтесь, но надоедает даже такое увлекательное занятие, как кидать горох в стену. Какие у вас, однако, странные увлечения)) Может заменить на что-то более полезное для дальнейшего развития и роста?) |
|
Сообщ.
#86
,
|
|
|
|
Guderian
Цитата Guderian @ Вообще-то более близкий по смыслу перевод для determine - определять, determined - определенный, определяемый. То есть "determined by the type of the expressions" переводится на русский язык скорее, как "определенный по типу выражения", "определяемый типом выражения" (тип - в смысле тип значения)determined by the type of the expressions Статическая типизация тоже позволяет вычислять предикаты в рантайме. |
|
|
Сообщ.
#87
,
|
|
|
KISS
Если считать, как я привык делать, что by обозначает творительный падеж, то... Цитата amk @ "определяемый типом выражения" |
|
Сообщ.
#88
,
|
|
|
|
Цитата amk @ determine - определять, determined - определенный Я и сказал, что отсылка шла к форме инфинитива, т.е. determine = определять/детерминировать, а страдательный залог determined становится страдательное формой причастия - определенный/детерминированный. Или речь идет о том, что я использовал англицизм? Так он давно используется. Детерминированные функции, детерминированная машина Тьюринга и т.п. Никто же не говорит "определенная функция", когда подразумевает ее детерминированность. Так и я, стараюсь избегать терминов, которые могут вызвать разночтение. Ибо typedef тоже дает определенный тип, но смысл этой определенности другой. Декларация T D, тоже дает определенный тип, уже третьего смысла. В общем одно наше "определять" с тремя их determine/declare/define не всегда справляется)) Цитата amk @ Статическая типизация тоже позволяет вычислять предикаты в рантайме. Учитывая, что предикат - это функция, было бы удивительно, если бы язык со статической типизацией не умел бы вычислять функций. Другое дело, что когда идет разработка и результат вычисления в рантайм еще не известен, разработчик вынужден довольствоваться общением через контракты. А в языке с динамической типизацией в этом нет необходимости. Но этой дает как плюсы, так и минусы. Цитата amk @ В общем дело упирается в наличие нужных средств управления компиляцией, а не в статическую/динамическую типизацию. Моё имхо, что за управляемой компиляцией будущее. Цитата Qraizer @ Если считать, как я привык делать, что by обозначает творительный падеж, то... Если быть точным, то фраза была "is determined by". Форма глагола "be" + Participle II - это классическое определение passive voice, "by" в passive voice указывает действующее лицо. Сам по себе voice/залог - это форма глагола, поэтому и переводить ее лучше в глагольно/причастной форме. Адъективация же глагола до прилагательного "определяемый" теряет семантику приложения, которое повествует о совершённом действии и низводит его до характеристики объекта. Чтобы не терять смысла, обычно осуществляется трансформация английского страдательного залога в наше страдательное причастие, в нашем случае определять->определен(краткая форма причастия)->определенный(полная форма причастия). |
|
Сообщ.
#89
,
|
|
|
|
Цитата Guderian @ В данном случае ты воспользовался неоднозначностью перевода и подменил одно понятие другим. Это позволило тебе сделать пару утверждений, бессмысленных при общепринятом переводе, но утверждающих твою мысль при выбранном тобой.Так и я, стараюсь избегать терминов, которые могут вызвать разночтение. Цитата Guderian @ когда идет разработка и результат вычисления в рантайм еще не известен, разработчик вынужден довольствоваться общением через контракты. А в языке с динамической типизацией в этом нет необходимости Не хочешь же ты сказать, что в языке с динамической типизацией ты можешь проверить значение до рантайма. И в языке с динамической типизацией ты тоже до выполнения общаешься лишь через контракт. Другое дело, что в случае статической типизации ты можешь включить в контракт тип данных, а в случае динамической есть другие возможности, например наличие некоторого метода. Цитата Guderian @ Только вот об такой управляемой компиляции почему-то больше задумываются при статической типизации. А при динамической предпочитают двигаться в сторону "втометапрограммирования" (когда язык является метаязыком для себя же), и оставляя конкретные реализации программисту.за управляемой компиляцией будущее И слово "определяемый" в том контексте - не прилагательное, а причастие - форма страдательного залога настоящего времени. определенный - страдательный залог прошедшего времени определяющий - действительный залог настоящего времени определивший - действительный залог прошедшего времени определявший - несовершенный вид действительного залога прошедшего времени Адъективации причастия (не глагола) в данном случае не происходит. так что с переводами все в порядке. Правда, без учета окружения, возможно, что перевод выпал из контекста. |
|
Сообщ.
#90
,
|
|
|
|
Цитата amk @ В данном случае ты воспользовался неоднозначностью перевода и подменил одно понятие другим. Это позволило тебе сделать пару утверждений, бессмысленных при общепринятом переводе, но утверждающих твою мысль при выбранном тобой. Да я уже раз десять сказал, что неудачный для данного высокого общества подобрал термин)) По наивности думал, что у людей, которые с молоком матери (детерминированными алгоритмами, детерминированными машинами Тьюринга, детерминированными функциями и т.п.) должны были впитать принцип детерминированности, не будет проблем даже с такой непривычной формулировкой, которая поголовно встречается в англоязычной литературе. В том же упомянутом драфте я могу спокойной прочитать в разделе declarators про indetermined value и очень четко различается определение с дефинитивной точки зрения, декларативной и определение, как процесс (как дефинитивные, декларативные и оперативные нормы права, например). Читаю про auto - все четко: "determining the type specified for the contained declarator-id by such a declaration". Декларатор - отдельно, дереминирование - отдельно". Так что я, естественно, выбрал неудачные термин, ну а вы можете использовать "определенный" для typedef'ов, деклараторов, функций вычисления и еще чего угодно. Хотите дам вам обоим подсказку, чтобы меня окончательно растоптать в части этого термина и публично выпороть, но математически грамотно?)) Как известно, типизация осуществляется двумя способами - перечислением и предикатом принадлежности. Перечисление детерминировано по определению. Предикат - это функция, для функции определение детерминированности существует, значит детерминированность предиката и логичней рассматривать в первую очередь. А в примере с натуральными числами предикат является детерминированной функцией. Написал и прям сам расстроился, какое фиаско потерпел)) Что за жизнь, вот так и холиварь сам с собой)) Цитата amk @ Не хочешь же ты сказать, что в языке с динамической типизацией ты можешь проверить значение до рантайма. Я хочу сказать то, о чем писал уже пару раз до этого. В языке со статической типизацией я не могу получить доступ к методу foo, специфицированному в natural через контракт number. А в языке с динамической - запросто. Пусть сегодня это будет на Io.   // Модифицируем существующий числовой класс Number do ( isNatural := method(if(self > 0, true, false)) // Здесь и будет реализован наш предикат auto := method ( if ( isNatural == false, // Для ненатуральных чисел добавляем специфичный метод self negative := method(self * (-1)) ) return self ) ) x := 2 auto x isNatural println >> true y := (-3) auto y isNatural println >> false // Как бы язык со статической типизацией достучался до negative через полиморфный тип, если он у него не определен? // И где у меня здесь контракт? y negative println >> 3 // А вот и некоторого рода негативная сторона, о которой я говорил x negative println >> Number does not respond to 'negative' Цитата amk @ И слово "определяемый" в том контексте Возможны ты и прав. |
1 пользователей читают эту тему (1 гостей и 0 скрытых пользователей)
0 пользователей:
[ Script execution time: 0,0699 ] [ 14 queries used ] [ Generated: 8.09.25, 00:57 GMT ]