Здравствуйте, _Obelisk_, Вы писали:
_O_>Здравствуйте, INTP_mihoshi, Вы писали:
INT>>Это все ограничения, наложенные синтаксисом. Я справшиваю, какие различия остнануться, если отбросить синтаксис.
_O_>Это не синтаксис а семантика! _O_>В случае C++-а у нас вызываются default constructor и деструктор. В случае же Java у нас не вызывается ничего.
Мы как раз и занимаемся вот уж пятый год проблемой интеграции разных языков (включая языки формальных спецификаций) в рамках одной модели (реализация MDA иными словами). Проблем из-за различия в семантике лезет куча.
Здравствуйте, mihailik, Вы писали:
INT>>А чем вообще различаются языки, если "снять" с них синтаксис?
M>А чем отличаются ножи, если отломать у них лезвия? Язык это и есть синтаксис, способ записи.
Ну, во-вторых, синтаксис — это скорее ручка, чем лезвие. Может быть, например, нож со сменными лезвиями.
А во-первых, нож — это скорее то, что режет, а не то, что имеет лезвие.Лезвие — это лишь один из способов реализации функции ножа.
> INT>>Возьмем, например, ТруООП язык, тот же смоллток. Добавим юнит-тесты и
JIT — компиляцию тех кусков, которые возможно. > INT>>Есть ли хоть что-то в каком-нибудь языке, что нельзя этим
проэмулировать? > > T>У каждого языка свое применение. Одни дают большую свободу, но не
контролируют программиста. В других прыжок на месте считается попыткой к
бегству. В этом основная разница компиляторов. > > Эти различия проявляются на уровне синтаксиса. В одних языках + обозначает
сложить два int или два float, в других — предполагается, что если типы
операндов не те, то их нужно привести к "правильным". > Да, первый подход можно назвать более строгим, чем второй. Но это
синтакчические различия. А я спрашиваю о том, какие есть различия кроме
синтаксических.
А чем вообще различаются языки, если "снять" с них синтаксис? Во всех широко используемых языках один "суповой набор" — объекты, переменные, функции, алгоритмы, компайлтайм и рантайм. Может быть, с отделением семантики отвалятся и кажущиеся различия?
Возьмем, например, ТруООП язык, тот же смоллток. Добавим юнит-тесты и JIT — компиляцию тех кусков, которые возможно.
Есть ли хоть что-то в каком-нибудь языке, что нельзя этим проэмулировать?
Классы — легко. Строгая типизация — покрывается юнит-тестами. Присобачить поле "тип" к каждому объекту, юнит-тесты на автомате проверяют соответствие, в релизе эти поля можно и выкинуть. Полиморфизм — автоматом, наследование-реализацией объекта "Класс", инкапсуляция — автоматом и теми же юнит-тестами.
Здравствуйте, INTP_mihoshi, Вы писали:
INT>А чем вообще различаются языки, если "снять" с них синтаксис?
Читайте книгу Кауфмана "Языки программирования" — там все написано.
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Здравствуйте, INTP_mihoshi, Вы писали:
INT>А чем вообще различаются языки, если "снять" с них синтаксис? Во всех широко используемых языках один "суповой набор" — объекты, переменные, функции, алгоритмы, компайлтайм и рантайм. Может быть, с отделением семантики отвалятся и кажущиеся различия?
Не все так просто, скажем в С++/C есть указатели, а в Java их нет.
В Java если переменная имеет своим типом класс, то ее семантика — reference, а в C++ это не так.
Т.е. это будет иметь совершенно разную семантику в С++ и Java.
class A { }
A a;
Здравствуйте, INTP_mihoshi, Вы писали:
INT>А чем вообще различаются языки, если "снять" с них синтаксис? Во всех широко используемых языках один "суповой набор" — объекты, переменные, функции, алгоритмы, компайлтайм и рантайм. Может быть, с отделением семантики отвалятся и кажущиеся различия?
Если "снять с них синтаксис", то асм получится
INT>Возьмем, например, ТруООП язык, тот же смоллток. Добавим юнит-тесты и JIT — компиляцию тех кусков, которые возможно. INT>Есть ли хоть что-то в каком-нибудь языке, что нельзя этим проэмулировать?
У каждого языка свое применение. Одни дают большую свободу, но не контролируют программиста. В других прыжок на месте считается попыткой к бегству. В этом основная разница компиляторов.
Здравствуйте, LaptevVV, Вы писали:
LVV>Здравствуйте, INTP_mihoshi, Вы писали:
INT>>А чем вообще различаются языки, если "снять" с них синтаксис? LVV>Читайте книгу Кауфмана "Языки программирования" — там все написано.
Здравствуйте, _Obelisk_, Вы писали:
_O_>Здравствуйте, INTP_mihoshi, Вы писали:
INT>>А чем вообще различаются языки, если "снять" с них синтаксис? Во всех широко используемых языках один "суповой набор" — объекты, переменные, функции, алгоритмы, компайлтайм и рантайм. Может быть, с отделением семантики отвалятся и кажущиеся различия?
_O_>Не все так просто, скажем в С++/C есть указатели, а в Java их нет. _O_>В Java если переменная имеет своим типом класс, то ее семантика — reference, а в C++ это не так.
_O_>Т.е. это будет иметь совершенно разную семантику в С++ и Java. _O_>class A { } _O_>A a;
Это все ограничения, наложенные синтаксисом. Я справшиваю, какие различия остнануться, если отбросить синтаксис.
Здравствуйте, Tan4ik, Вы писали:
T>Здравствуйте, INTP_mihoshi, Вы писали:
INT>>А чем вообще различаются языки, если "снять" с них синтаксис? Во всех широко используемых языках один "суповой набор" — объекты, переменные, функции, алгоритмы, компайлтайм и рантайм. Может быть, с отделением семантики отвалятся и кажущиеся различия?
T>Если "снять с них синтаксис", то асм получится
Нет. Преобразование из программы в АСМ (или MSIL) происходит с потерей информации. Асмом невозможно выразить понятия более высокого порядка, например, тот же тип объекта. Это если забыть что лююой знаковой системой можно выразить сто угодно Например, принять MOV А, #NN за символ с кодом #NN и "написать" этими символами программу на Паскале
INT>>Возьмем, например, ТруООП язык, тот же смоллток. Добавим юнит-тесты и JIT — компиляцию тех кусков, которые возможно. INT>>Есть ли хоть что-то в каком-нибудь языке, что нельзя этим проэмулировать?
T>У каждого языка свое применение. Одни дают большую свободу, но не контролируют программиста. В других прыжок на месте считается попыткой к бегству. В этом основная разница компиляторов.
Эти различия проявляются на уровне синтаксиса. В одних языках + обозначает сложить два int или два float, в других — предполагается, что если типы операндов не те, то их нужно привести к "правильным".
Да, первый подход можно назвать более строгим, чем второй. Но это синтакчические различия. А я спрашиваю о том, какие есть различия кроме синтаксических.
Здравствуйте, INTP_mihoshi, Вы писали:
INT>Это все ограничения, наложенные синтаксисом. Я справшиваю, какие различия остнануться, если отбросить синтаксис.
Это не синтаксис а семантика!
В случае C++-а у нас вызываются default constructor и деструктор. В случае же Java у нас не вызывается ничего.
Здравствуйте, _Obelisk_, Вы писали:
_O_>>Это не синтаксис а семантика! _O_>>В случае C++-а у нас вызываются default constructor и деструктор. В случае же Java у нас не вызывается ничего.
_O_>Мы как раз и занимаемся вот уж пятый год проблемой интеграции разных языков (включая языки формальных спецификаций) в рамках одной модели (реализация MDA иными словами). Проблем из-за различия в семантике лезет куча.
О, спасибо за интересные буквы Как раз то, что надо. Уже читаю спецификацию...
Здравствуйте, INTP_mihoshi, Вы писали:
INT>А чем вообще различаются языки, если "снять" с них синтаксис? Во всех широко используемых языках один "суповой набор" — объекты, переменные, функции, алгоритмы, компайлтайм и рантайм. Может быть, с отделением семантики отвалятся и кажущиеся различия?
Основное назначение языка программирование — это передача знаний от человека к компьютеру. Человек в программе описывает то, что он хочет, чтобы выполнил компьютер.
Основными критериями хорошего языка (если отвлечься от производительности) является:
1. Краткость. Т.е. человек должен написать как можно меньше, а компьютер понять как можно больше
2. Точность формулировок. Т.е. компьютер должен как можно точнее понять то, что хотел сказать человек
Если опираться на вышеприведенные утверждения, то сразу станет понятно, что синтаксис в ряде случаев важен. Особенно в тех случаях, когда он позволяет более кратко и емко записать, то что мы хотим.
Сравним по этим критериям, например, определение массива:
Ассемблер
q db(10)
C/C++
char q[10];
C#
byte[] q = new byte[10];
на первый взгляд, все эти объявления одиннаково лаконично, но если присмотреться по внимательнее, то окажется, что каждый следующий язык понимают чуть больше информации, чем предыдущий.
С/C++ понимает, что это не просто массив, а что массив именно байт, и что операции над возможны, только как над byte-ами
C# дополнительно понимает, что массив именно 10 элементов, и записать за границы массива нельзя.
Еще больше различий начинается, когда мы переходим к определению, своих сущностей (классов, типов, объектов).
INT>Возьмем, например, ТруООП язык, тот же смоллток. Добавим юнит-тесты и JIT — компиляцию тех кусков, которые возможно. INT>Есть ли хоть что-то в каком-нибудь языке, что нельзя этим проэмулировать?
INT>Классы — легко. Строгая типизация — покрывается юнит-тестами. Присобачить поле "тип" к каждому объекту, юнит-тесты на автомате проверяют соответствие, в релизе эти поля можно и выкинуть. Полиморфизм — автоматом, наследование-реализацией объекта "Класс", инкапсуляция — автоматом и теми же юнит-тестами.
Но опять все упирается в лаконичность.
Смолтолк позволяет более гибко (более лаконично) записать отношения между классами, но при этом он жертвует compile-проверками.
Что приводит к тому, что мы вынуждены на смалтоке "разбавлять лаконичность водой", вынуждены писать тесты даже для простейших кусков кода.
Также смалток жертвует вторым критерием "точностью", если при статической типизации компилятор точно знает, какого типа входной объект, и поэтому может лучше соптимизировать выходной код, то в смолтоке выходной код должен быть в любую минуту быть готовым к любой неожиданности, что приводит к лишним проверкам.
Здравствуйте, INTP_mihoshi, Вы писали:
INT>А чем вообще различаются языки, если "снять" с них синтаксис? Во всех широко используемых языках один "суповой набор" — объекты, переменные, функции, алгоритмы, компайлтайм и рантайм. Может быть, с отделением семантики отвалятся и кажущиеся различия?
INT>Возьмем, например, ТруООП язык, тот же смоллток. Добавим юнит-тесты и JIT — компиляцию тех кусков, которые возможно. INT>Есть ли хоть что-то в каком-нибудь языке, что нельзя этим проэмулировать?
INT>Классы — легко. Строгая типизация — покрывается юнит-тестами. Присобачить поле "тип" к каждому объекту, юнит-тесты на автомате проверяют соответствие, в релизе эти поля можно и выкинуть. Полиморфизм — автоматом, наследование-реализацией объекта "Класс", инкапсуляция — автоматом и теми же юнит-тестами.
А я с тобой полностью согласен
Семантика процедурного и объектного подхода давно проработана. Можно попробовать ее отделить.
Одна проблема. Нужно позаботиться, чтобы эту семантику можно было читать. То есть какой-либо текстовый или графический язык снова необходим!
Но если берем текстовый — получаем обычный язык программирования! Ну, или несколько. Включая язык написания юнит тестинга.
Попытки сделать эффективные графические языки программирования предпринимаются не первый раз.
Например, это RADы (графические языки для создания интерфейсов), UML и прочая Model-Driven Architecture, старенькие блоксхемы...
Пожалуй, моделирование и проектирование (хотя бы в рамках системного подхода, всего помаленьку) + программирование (UI+ООП+RDB+OODB) + специфицирование (UI-tests+те же unit-tests+DB-tests) — это наиболее перспективный и эффективный подход. Надо работать дальше... сделать удобную и полнофункциональную среду для разработки проектов, например. Обеспечить поддержку библиотеками, шаблонами и примерами. И методологию задокументировать. Чтобы был рай. Как видишь, хотели самого нового и удобного, а получилось все как есть.
Кстати, добавлю про АОП. Штука хорошая, только опять же, чтобы не забыть, где мы ее применяли и как , нужны те же язык моделирования + язык программирования + язык специфицирования...
Здравствуйте, DarkGray, Вы писали:
DG>Здравствуйте, INTP_mihoshi, Вы писали:
INT>>А чем вообще различаются языки, если "снять" с них синтаксис? Во всех широко используемых языках один "суповой набор" — объекты, переменные, функции, алгоритмы, компайлтайм и рантайм. Может быть, с отделением семантики отвалятся и кажущиеся различия?
DG>Основное назначение языка программирование — это передача знаний от человека к компьютеру. Человек в программе описывает то, что он хочет, чтобы выполнил компьютер.
Ты только описал основную (ИМХО) проблему ЯП Когда-то это действительно было так. В те светлые времена, когда было хотя бы примерно известно, кто и для кого пишет программу. Уже давно одну программу пишет не один человек и даже не одна организация и используется она уже далеко не только для генерации кода.
DG>Основными критериями хорошего языка (если отвлечься от производительности) является: DG>1. Краткость. Т.е. человек должен написать как можно меньше, а компьютер понять как можно больше DG>2. Точность формулировок. Т.е. компьютер должен как можно точнее понять то, что хотел сказать человек
Я бы добавил еще — 3. Безопансоть. Т.е. компьютер должен быть защищен от глупости пользователя.
DG>Если опираться на вышеприведенные утверждения, то сразу станет понятно, что синтаксис в ряде случаев важен. Особенно в тех случаях, когда он позволяет более кратко и емко записать, то что мы хотим.
Важен-то он важен. Вот только пункт 2. не выполняется никогда. Именно из-за ограничений, наложенных синтаксисом.
DG>Сравним по этим критериям, например, определение массива: DG>Ассемблер DG>
DG>q db(10)
DG>
DG>C/C++ DG>
DG>char q[10];
DG>
DG>C# DG>
DG>byte[] q = new byte[10];
DG>
DG>на первый взгляд, все эти объявления одиннаково лаконично, но если присмотреться по внимательнее, то окажется, что каждый следующий язык понимают чуть больше информации, чем предыдущий.
Вот только объяснить компьютеру, что тебе _на самом деле_ нужно пока что еще никому не удавалось.
DG>С/C++ понимает, что это не просто массив, а что массив именно байт, и что операции над возможны, только как над byte-ами DG>C# дополнительно понимает, что массив именно 10 элементов, и записать за границы массива нельзя.
Тогда как на самом деле нам было нужно десять флагов... Впрочем, не помню, может в C# есть какой-то специальный метод объявления флаговых переменных...
DG>Еще больше различий начинается, когда мы переходим к определению, своих сущностей (классов, типов, объектов).
Еще бы, ведь нам надо так обработать их напильником, чтобы они втиснулись в рамки этого конкретного языка... А отпиленные части придется держать в голове, в тестах, в документации...
DG>Но опять все упирается в лаконичность. DG>Смолтолк позволяет более гибко (более лаконично) записать отношения между классами, но при этом он жертвует compile-проверками. DG>Что приводит к тому, что мы вынуждены на смалтоке "разбавлять лаконичность водой", вынуждены писать тесты даже для простейших кусков кода.
Но не должны же мы это делать ручками каждый раз, правда? Мы же, вроде бы, программисты... И должны уметь автоматизировать такие задачи.
DG>Также смалток жертвует вторым критерием "точностью", если при статической типизации компилятор точно знает, какого типа входной объект, и поэтому может лучше соптимизировать выходной код, то в смолтоке выходной код должен быть в любую минуту быть готовым к любой неожиданности, что приводит к лишним проверкам.
А это, кстати, проблема разделения комапайл и рантайма. И того же синтаксиса. Именно они мешают нам проверять такие вещи только на этапе компиляции/линковки/тестирования.
Посмотри, кстати, на Eiffel. Там уже просекли, что одной только информации о типе недостаточно и проверки на состояния входных параметров должны быть более гибкими. Так что "строгость" т.н. строго типизированных языков — тоже "строга" лишь частично.
Здравствуйте, BUran, Вы писали:
BU>А я с тобой полностью согласен BU>Семантика процедурного и объектного подхода давно проработана. Можно попробовать ее отделить. BU>Одна проблема. Нужно позаботиться, чтобы эту семантику можно было читать. То есть какой-либо текстовый или графический язык снова необходим! BU>Но если берем текстовый — получаем обычный язык программирования! Ну, или несколько. Включая язык написания юнит тестинга. BU>Попытки сделать эффективные графические языки программирования предпринимаются не первый раз. BU>Например, это RADы (графические языки для создания интерфейсов), UML и прочая Model-Driven Architecture, старенькие блоксхемы...
Все так, но посмотри на математику. Там ведь как-то смогли отделить символ от объекта. Понадобилось им новое обозначение — добавили. Не совпали в обозначениях — поматюгались, синхронизовались и работаем дальше.
Язык-то необходим, но надо уметь различать язык и описываемый объект, смысл и артефакты. Наверно, проблема в привычке... В конуе концов, изначально все сводилось действительно к тексту — к машинному коду. Но сейчас нам надо как-то описывать реальные понятия и объекты...
Здравствуйте, BUran, Вы писали:
BU>Здравствуйте, INTP_mihoshi, Вы писали: BU>нужны те же язык моделирования + язык программирования + язык специфицирования...
А, кстати, не пробовал ли кто нибудь когда нибудь создать язык, программы на котором являються одновременно и моделью и спецификацией и исполняемым(компилируемым) кодом?
BU>>нужны те же язык моделирования + язык программирования + язык специфицирования...
U>А, кстати, не пробовал ли кто нибудь когда нибудь создать язык, программы на котором являються одновременно и моделью и спецификацией и исполняемым(компилируемым) кодом?
Здравствуйте, uriy999, Вы писали:
U>Здравствуйте, BUran, Вы писали:
BU>>Здравствуйте, INTP_mihoshi, Вы писали: BU>>нужны те же язык моделирования + язык программирования + язык специфицирования...
U>А, кстати, не пробовал ли кто нибудь когда нибудь создать язык, программы на котором являються одновременно и моделью и спецификацией и исполняемым(компилируемым) кодом?
Здравствуйте, INTP_mihoshi, Вы писали: INT>Возьмем, например, ТруООП язык, тот же смоллток. Добавим юнит-тесты и JIT — компиляцию тех кусков, которые возможно. INT>Есть ли хоть что-то в каком-нибудь языке, что нельзя этим проэмулировать?
Да. Семантика, братец, семантика. Если в языке А нет области видимости internal protected, то никакими средствами ты ее не сэмулируешь.
... << RSDN@Home 1.1.3 beta 2 >>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, INTP_mihoshi, Вы писали: INT>>Возьмем, например, ТруООП язык, тот же смоллток. Добавим юнит-тесты и JIT — компиляцию тех кусков, которые возможно. INT>>Есть ли хоть что-то в каком-нибудь языке, что нельзя этим проэмулировать? S>Да. Семантика, братец, семантика. Если в языке А нет области видимости internal protected, то никакими средствами ты ее не сэмулируешь.
Ты не понял вопроса. В ТруОО языках можно изобразить и internal protected, и external protected, и protected, but accessible if reallyreally needed. Разумеется, на КлассовоОриентированнных языках эти не сделать — им в своих бы спецификаторах разобраться.
Здравствуйте, 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>Вобщем, поживем — увидим...
Поживем — увидим, доживем — узнаем, выживем — учтем
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>Ты говоришь о выделении сущности явлений, а на самом деле распыляешься в детали. Это всё равно как искать сущность пиджака, отрезая у него пуговицы и лацканы.
, нужны те же язык моделирования + язык программирования + язык специфицирования...
Когда-то это действительно было так. В те светлые времена, когда было хотя бы примерно известно, кто и для кого пишет программу. Уже давно одну программу пишет не один человек и даже не одна организация и используется она уже далеко не только для генерации кода.
мешают нам проверять такие вещи только на этапе компиляции/линковки/тестирования.
Надо значит упрощать или переформулировать задачу...
