Здравствуйте, INTP_mihoshi, Вы писали: S>>Да. Семантика, братец, семантика. Если в языке А нет области видимости internal protected, то никакими средствами ты ее не сэмулируешь. INT>Ты не понял вопроса. В ТруОО языках можно изобразить и internal protected, и external protected, и protected, but accessible if reallyreally needed.
Это интересно как? И что такое ТруОО язык? INT> Разумеется, на КлассовоОриентированнных языках эти не сделать — им в своих бы спецификаторах разобраться.
... << RSDN@Home 1.1.3 beta 2 >>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, INTP_mihoshi, Вы писали: S>>>Да. Семантика, братец, семантика. Если в языке А нет области видимости internal protected, то никакими средствами ты ее не сэмулируешь. INT>>Ты не понял вопроса. В ТруОО языках можно изобразить и internal protected, и external protected, и protected, but accessible if reallyreally needed. S>Это интересно как? И что такое ТруОО язык? INT>> Разумеется, на КлассовоОриентированнных языках эти не сделать — им в своих бы спецификаторах разобраться.
ТруОО язык — это объектно-ориентированный язык в изначальном понимании. Определен создалетелем ОО подхода Аланом Кеем следующим образом
# Объект — базовая единица объектно-ориентированной системы.
# Объекты могут обладать состоянием.
# Посылка сообщения — единственный способ обмена информацией между объектами.
Классово-ориентированные языки отличаются от ОО языков прежде всего тем, что они используют элементы, не являющиеся объектами, в частности, классы и нативные переменные.
Здравствуйте, INTP_mihoshi, Вы писали:
INT>А чем вообще различаются языки, если "снять" с них синтаксис? Во всех широко используемых языках один "суповой набор" — объекты, переменные, функции, алгоритмы, компайлтайм и рантайм. Может быть, с отделением семантики отвалятся и кажущиеся различия?
Ясно, что все языки по большому счету, это одно и тоже.
Пространство задач, которые могут быть реализованы на разных языках по сути совпадают.
Но есть такая вещь, как динамика показателей языка в зависимости от различных параметров — тех же размера проекта и его сложности.
Можно рассмотреть следующую курьезную концепцию. Возьмем некоторое счетное множество типичных проектов (можно из конкретной предметной области). Для каждого проекта будем определять некоторый числовой показатель, условно названный "стоимость разработки" (складывающееся из цены, времени, сложности сопровождения и т.д.) в зависимости от языка разработки.
Теперь рассмотрим для каждого языка числовую последовательность, состоящую из его значений "стоимость разработки".
Для удобства упорядочим проекты так, что соответствующая числовая последовательность, скажем для ассемблера, является неубывающей.
Теперь рассмотрим предел отношения i-ого значения последовательности для языка X к итому значению для ассемблера. Эту величину назовем ассимптотическим коэффициентом эффективности данного языка.
Вот это и есть то, за что мы должны бороться при выборе языка.
INT>Возьмем, например, ТруООП язык, тот же смоллток. Добавим юнит-тесты и JIT — компиляцию тех кусков, которые возможно.
JIT там есть. Юнит-тесты есть.
INT>Есть ли хоть что-то в каком-нибудь языке, что нельзя этим проэмулировать?
INT>Классы — легко. Строгая типизация — покрывается юнит-тестами. Присобачить поле "тип" к каждому объекту, юнит-тесты на автомате проверяют соответствие, в релизе эти поля можно и выкинуть. Полиморфизм — автоматом, наследование-реализацией объекта "Класс", инкапсуляция — автоматом и теми же юнит-тестами.
Вот интересная статья про Lisp (еще один динамический язык, построенный на минимальном числе концепций, его часто ставят в одну линейку со Smalltalk): http://www.norvig.com/java-lisp.html
Здравствуйте, uriy999, Вы писали:
BU>>нужны те же язык моделирования + язык программирования + язык специфицирования... U>А, кстати, не пробовал ли кто нибудь когда нибудь создать язык, программы на котором являються одновременно и моделью и спецификацией и исполняемым(компилируемым) кодом?
А как он будет выглядеть?
Здравствуйте, BUran, Вы писали:
BU>Здравствуйте, uriy999, Вы писали:
U>>А, кстати, не пробовал ли кто нибудь когда нибудь создать язык, программы на котором являються одновременно и моделью и спецификацией и исполняемым(компилируемым) кодом? BU>А как он будет выглядеть?
Придумать можно, главное задачу осмыслить.
Например, в progstone есть фраза:
---
Определения объектов содержат допускаемые намерением варианты использования, выраженные в сжатой форме. Однако реально нет более мелкого дробления, когда мы можем заключить намерение в комментарий, а действие в код без того, чтобы комментарии не стали глупыми.
---
Привет, тезка
U>>>А, кстати, не пробовал ли кто нибудь когда нибудь создать язык, программы на котором являються одновременно и моделью и спецификацией и исполняемым(компилируемым) кодом? BU>>А как он будет выглядеть? U>Придумать можно,
Меня устраивает системный анализ и семантические сети как главенствующие подходы к языку. Тогда получится графический язык. Плюс текстовые интерпретации. Но ты посмотри, сколько умники из OMG накидали в спецификации для MDA! Мне столько глупого кода в жизни писать не захочется Надо значит упрощать или переформулировать задачу...
Самое главное, что я бы хотел получить от этого языка — легкую читаемость. Причем очень быструю. Не быструю читаемость кода каждой функции, а, например, если хочешь вычленить работу с только одним ресурсом каким-то типа файла — вот, пожалуйста, на здоровье. И желательно, в виде семантической сети или понятного описания. Раньше хотел еще лог вызовов каждой функции получать отдельно "по заявкам", но это сделали. U>Главное задачу осмыслить.
я над этим работаю онтологии, понимаешь ли... U>Например, в progstone есть фраза: U>--- U>Определения объектов содержат допускаемые намерением варианты использования, выраженные в сжатой форме. Однако реально нет более мелкого дробления, когда мы можем заключить намерение в комментарий, а действие в код без того, чтобы комментарии не стали глупыми. U>---
Хорошая фраза, и progstone тоже
Как развитие темы советую это: http://yazyk.wallst.ru ,
только там надо хорошо покопаться прежде чем до хороших вещей доберешься
Сам читаю сейчас.
U>Вобщем, поживем — увидим...
Поживем — увидим, доживем — узнаем, выживем — учтем
Здравствуйте, mihailik, Вы писали:
INT>>А чем вообще различаются языки, если "снять" с них синтаксис?
M>А чем отличаются ножи, если отломать у них лезвия? Язык это и есть синтаксис, способ записи.
Ну, во-вторых, синтаксис — это скорее ручка, чем лезвие. Может быть, например, нож со сменными лезвиями.
А во-первых, нож — это скорее то, что режет, а не то, что имеет лезвие.Лезвие — это лишь один из способов реализации функции ножа.
INT>>>А чем вообще различаются языки, если "снять" с них синтаксис?
M>>А чем отличаются ножи, если отломать у них лезвия? Язык это и есть синтаксис, способ записи.
INT>Ну, во-вторых, синтаксис — это скорее ручка, чем лезвие. Может быть, например, нож со сменными лезвиями.
Можно размусоливать эти ручки-лезвия сколько угодно, только так ты ещё дальше уйдёшь от реальных вещей.
Синтаксис языка программирования — это его ключевое неотделимое свойство. Ты предлагаешь его откусить и рассматривать какой-то остаток.
Ну давай, отдели. Возьми перл, паскаль и SQL и отдели в них синтаксис, чтобы не быть голословным. Если ты говорил, значит что-то имел ввиду. Вот и поясни, что ты имел ввиду под отделением синтаксиса хотя бы на этом примере.
Здравствуйте, mihailik, Вы писали:
INT>>>>А чем вообще различаются языки, если "снять" с них синтаксис? M>>>А чем отличаются ножи, если отломать у них лезвия? Язык это и есть синтаксис, способ записи. INT>>Ну, во-вторых, синтаксис — это скорее ручка, чем лезвие. Может быть, например, нож со сменными лезвиями. M>Можно размусоливать эти ручки-лезвия сколько угодно, только так ты ещё дальше уйдёшь от реальных вещей.
Я всего лишь ответил тебе в выбранной тобой терминологии
M>Синтаксис языка программирования — это его ключевое неотделимое свойство. Ты предлагаешь его откусить и рассматривать какой-то остаток. M>Ну давай, отдели. Возьми перл, паскаль и SQL и отдели в них синтаксис, чтобы не быть голословным. Если ты говорил, значит что-то имел ввиду. Вот и поясни, что ты имел ввиду под отделением синтаксиса хотя бы на этом примере.
Остаются основные типы данных (скаляр/хэш/массив в Перле, таблица в SQL, классы/целые и т.д. в Паскале)
Остается принцип последовательного ввыполнения операций, концепция переменных, вызова функций, возможности компилироваться или интерпретироваться... Строгая типизация в Паскале и отсутствие оной в Перле, наличие или отсутствие сборки мусора.
Вообще, если попытаться систематизировать:
1. Способы группировки и хранения данных (скаляры, структуры, массивы, таблицы, диск или память)
2. Способы определения порядка выполнения действий (классы, функции, циклы)
3. Компилируемость и интерпретируемость
4. Способы контроля корректности кода (типизация, классы)
Здравствуйте, DarkGray, Вы писали:
INT>>Вообще, если попытаться систематизировать: INT>>1. Способы группировки и хранения данных (скаляры, структуры, массивы, таблицы, диск или память)
DG>Имхо, лучше разнести способ группировки и способы хранения (способ "получения данных"). DG>способ группировки: интерфейс/структура, массив, ассоциативный массив, xml(ассоциативное дерево?) DG>способ хранения/получения: непосредственное хранение, вычисление на основе других данных, DG> "транспортировка" из другого источника.
Можно и разнести. Я их объединил потому что они зависят друг от друга.
INT>>>Ну, во-вторых, синтаксис — это скорее ручка, чем лезвие. Может быть, например, нож со сменными лезвиями. M>>Можно размусоливать эти ручки-лезвия сколько угодно, только так ты ещё дальше уйдёшь от реальных вещей. INT>Я всего лишь ответил тебе в выбранной тобой терминологии
А по-моему, ты воспользовался терминологией чтобы уйти от темы.
Во всяком случае, я не понял, почему синтаксис ручка а не лезвие. И где ты видишь аналогию сменных лезвий.
M>>Ну давай, отдели. Возьми перл, паскаль и SQL и отдели в них синтаксис, чтобы не быть голословным. Если ты говорил, значит что-то имел ввиду. Вот и поясни, что ты имел ввиду под отделением синтаксиса хотя бы на этом примере.
INT>Остаются основные типы данных (скаляр/хэш/массив в Перле, таблица в SQL, классы/целые и т.д. в Паскале) INT>Остается принцип последовательного ввыполнения операций, концепция переменных, вызова функций, возможности компилироваться или интерпретироваться... Строгая типизация в Паскале и отсутствие оной в Перле, наличие или отсутствие сборки мусора.
Ну, в общем я не понял, причём здесь отделение синтаксиса. Ты просто перечислил какие-то свойства языков. И если синтаксис перла ещё как-то можно назвать его важнейшим свойством, то этот беспорядочный набор свойств вообще непонятно как анализировать.
Ты говоришь о выделении сущности явлений, а на самом деле распыляешься в детали. Это всё равно как искать сущность пиджака, отрезая у него пуговицы и лацканы.
Здравствуйте, mihailik, Вы писали:
M>Ты говоришь о выделении сущности явлений, а на самом деле распыляешься в детали. Это всё равно как искать сущность пиджака, отрезая у него пуговицы и лацканы.
Надо значит упрощать или переформулировать задачу...
