Языки в бане
От: INTP_mihoshi Россия  
Дата: 18.03.04 08:37
Оценка:
А чем вообще различаются языки, если "снять" с них синтаксис? Во всех широко используемых языках один "суповой набор" — объекты, переменные, функции, алгоритмы, компайлтайм и рантайм. Может быть, с отделением семантики отвалятся и кажущиеся различия?

Возьмем, например, ТруООП язык, тот же смоллток. Добавим юнит-тесты и JIT — компиляцию тех кусков, которые возможно.
Есть ли хоть что-то в каком-нибудь языке, что нельзя этим проэмулировать?

Классы — легко. Строгая типизация — покрывается юнит-тестами. Присобачить поле "тип" к каждому объекту, юнит-тесты на автомате проверяют соответствие, в релизе эти поля можно и выкинуть. Полиморфизм — автоматом, наследование-реализацией объекта "Класс", инкапсуляция — автоматом и теми же юнит-тестами.
Re: Языки в бане
От: LaptevVV Россия  
Дата: 18.03.04 08:48
Оценка:
Здравствуйте, INTP_mihoshi, Вы писали:

INT>А чем вообще различаются языки, если "снять" с них синтаксис?

Читайте книгу Кауфмана "Языки программирования" — там все написано.
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Re: Языки в бане
От: _Obelisk_ Россия http://www.ibm.com
Дата: 18.03.04 08:49
Оценка:
Здравствуйте, INTP_mihoshi, Вы писали:

INT>А чем вообще различаются языки, если "снять" с них синтаксис? Во всех широко используемых языках один "суповой набор" — объекты, переменные, функции, алгоритмы, компайлтайм и рантайм. Может быть, с отделением семантики отвалятся и кажущиеся различия?


Не все так просто, скажем в С++/C есть указатели, а в Java их нет.
В Java если переменная имеет своим типом класс, то ее семантика — reference, а в C++ это не так.

Т.е. это будет иметь совершенно разную семантику в С++ и Java.
class A { }
A a;



Душа обязана трудиться! (с) Н.Заболоцкий.
Re: Языки в бане
От: Tan4ik Россия  
Дата: 18.03.04 08:52
Оценка:
Здравствуйте, INTP_mihoshi, Вы писали:

INT>А чем вообще различаются языки, если "снять" с них синтаксис? Во всех широко используемых языках один "суповой набор" — объекты, переменные, функции, алгоритмы, компайлтайм и рантайм. Может быть, с отделением семантики отвалятся и кажущиеся различия?


Если "снять с них синтаксис", то асм получится

INT>Возьмем, например, ТруООП язык, тот же смоллток. Добавим юнит-тесты и JIT — компиляцию тех кусков, которые возможно.

INT>Есть ли хоть что-то в каком-нибудь языке, что нельзя этим проэмулировать?

У каждого языка свое применение. Одни дают большую свободу, но не контролируют программиста. В других прыжок на месте считается попыткой к бегству. В этом основная разница компиляторов.
---
С уважением,
Лазарев Андрей
Re[2]: Языки в бане
От: INTP_mihoshi Россия  
Дата: 18.03.04 09:08
Оценка:
Здравствуйте, LaptevVV, Вы писали:

LVV>Здравствуйте, INTP_mihoshi, Вы писали:


INT>>А чем вообще различаются языки, если "снять" с них синтаксис?

LVV>Читайте книгу Кауфмана "Языки программирования" — там все написано.

Читал. Там как раз о синтаксисе.
Re[2]: Языки в бане
От: INTP_mihoshi Россия  
Дата: 18.03.04 09:09
Оценка:
Здравствуйте, _Obelisk_, Вы писали:

_O_>Здравствуйте, INTP_mihoshi, Вы писали:


INT>>А чем вообще различаются языки, если "снять" с них синтаксис? Во всех широко используемых языках один "суповой набор" — объекты, переменные, функции, алгоритмы, компайлтайм и рантайм. Может быть, с отделением семантики отвалятся и кажущиеся различия?


_O_>Не все так просто, скажем в С++/C есть указатели, а в Java их нет.

_O_>В Java если переменная имеет своим типом класс, то ее семантика — reference, а в C++ это не так.

_O_>Т.е. это будет иметь совершенно разную семантику в С++ и Java.

_O_>class A { }
_O_>A a;

Это все ограничения, наложенные синтаксисом. Я справшиваю, какие различия остнануться, если отбросить синтаксис.
Re[2]: Языки в бане
От: INTP_mihoshi Россия  
Дата: 18.03.04 09:20
Оценка:
Здравствуйте, Tan4ik, Вы писали:

T>Здравствуйте, INTP_mihoshi, Вы писали:


INT>>А чем вообще различаются языки, если "снять" с них синтаксис? Во всех широко используемых языках один "суповой набор" — объекты, переменные, функции, алгоритмы, компайлтайм и рантайм. Может быть, с отделением семантики отвалятся и кажущиеся различия?


T>Если "снять с них синтаксис", то асм получится


Нет. Преобразование из программы в АСМ (или MSIL) происходит с потерей информации. Асмом невозможно выразить понятия более высокого порядка, например, тот же тип объекта. Это если забыть что лююой знаковой системой можно выразить сто угодно Например, принять MOV А, #NN за символ с кодом #NN и "написать" этими символами программу на Паскале

INT>>Возьмем, например, ТруООП язык, тот же смоллток. Добавим юнит-тесты и JIT — компиляцию тех кусков, которые возможно.

INT>>Есть ли хоть что-то в каком-нибудь языке, что нельзя этим проэмулировать?

T>У каждого языка свое применение. Одни дают большую свободу, но не контролируют программиста. В других прыжок на месте считается попыткой к бегству. В этом основная разница компиляторов.


Эти различия проявляются на уровне синтаксиса. В одних языках + обозначает сложить два int или два float, в других — предполагается, что если типы операндов не те, то их нужно привести к "правильным".
Да, первый подход можно назвать более строгим, чем второй. Но это синтакчические различия. А я спрашиваю о том, какие есть различия кроме синтаксических.
Re[3]: Языки в бане
От: Tan4ik Россия  
Дата: 18.03.04 09:48
Оценка: :)
> INT>>Возьмем, например, ТруООП язык, тот же смоллток. Добавим юнит-тесты и
JIT — компиляцию тех кусков, которые возможно.
> INT>>Есть ли хоть что-то в каком-нибудь языке, что нельзя этим
проэмулировать?
>
> T>У каждого языка свое применение. Одни дают большую свободу, но не
контролируют программиста. В других прыжок на месте считается попыткой к
бегству. В этом основная разница компиляторов.
>
> Эти различия проявляются на уровне синтаксиса. В одних языках + обозначает
сложить два int или два float, в других — предполагается, что если типы
операндов не те, то их нужно привести к "правильным".
> Да, первый подход можно назвать более строгим, чем второй. Но это
синтакчические различия. А я спрашиваю о том, какие есть различия кроме
синтаксических.

Блоксхемы рулят
Posted via RSDN NNTP Server 1.8 beta
---
С уважением,
Лазарев Андрей
Re[3]: Языки в бане
От: _Obelisk_ Россия http://www.ibm.com
Дата: 18.03.04 09:59
Оценка:
Здравствуйте, INTP_mihoshi, Вы писали:

INT>Это все ограничения, наложенные синтаксисом. Я справшиваю, какие различия остнануться, если отбросить синтаксис.


Это не синтаксис а семантика!
В случае C++-а у нас вызываются default constructor и деструктор. В случае же Java у нас не вызывается ничего.



Душа обязана трудиться! (с) Н.Заболоцкий.
Re[4]: Языки в бане
От: _Obelisk_ Россия http://www.ibm.com
Дата: 18.03.04 10:02
Оценка: 7 (2) +1
Здравствуйте, _Obelisk_, Вы писали:

_O_>Здравствуйте, INTP_mihoshi, Вы писали:


INT>>Это все ограничения, наложенные синтаксисом. Я справшиваю, какие различия остнануться, если отбросить синтаксис.


_O_>Это не синтаксис а семантика!

_O_>В случае C++-а у нас вызываются default constructor и деструктор. В случае же Java у нас не вызывается ничего.

Мы как раз и занимаемся вот уж пятый год проблемой интеграции разных языков (включая языки формальных спецификаций) в рамках одной модели (реализация MDA иными словами). Проблем из-за различия в семантике лезет куча.



Душа обязана трудиться! (с) Н.Заболоцкий.
Re[5]: Языки в бане
От: INTP_mihoshi Россия  
Дата: 18.03.04 10:17
Оценка:
Здравствуйте, _Obelisk_, Вы писали:

_O_>>Это не синтаксис а семантика!

_O_>>В случае C++-а у нас вызываются default constructor и деструктор. В случае же Java у нас не вызывается ничего.

_O_>Мы как раз и занимаемся вот уж пятый год проблемой интеграции разных языков (включая языки формальных спецификаций) в рамках одной модели (реализация MDA иными словами). Проблем из-за различия в семантике лезет куча.


О, спасибо за интересные буквы Как раз то, что надо. Уже читаю спецификацию...
Re: Языки в бане
От: DarkGray Россия http://blog.metatech.ru/post/ogni-razrabotki.aspx
Дата: 18.03.04 10:23
Оценка:
Здравствуйте, 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-проверками.
Что приводит к тому, что мы вынуждены на смалтоке "разбавлять лаконичность водой", вынуждены писать тесты даже для простейших кусков кода.
Также смалток жертвует вторым критерием "точностью", если при статической типизации компилятор точно знает, какого типа входной объект, и поэтому может лучше соптимизировать выходной код, то в смолтоке выходной код должен быть в любую минуту быть готовым к любой неожиданности, что приводит к лишним проверкам.
Re: Языки в бане
От: BUran Россия http://www.buriy.com/
Дата: 18.03.04 10:34
Оценка:
Здравствуйте, INTP_mihoshi, Вы писали:

INT>А чем вообще различаются языки, если "снять" с них синтаксис? Во всех широко используемых языках один "суповой набор" — объекты, переменные, функции, алгоритмы, компайлтайм и рантайм. Может быть, с отделением семантики отвалятся и кажущиеся различия?


INT>Возьмем, например, ТруООП язык, тот же смоллток. Добавим юнит-тесты и JIT — компиляцию тех кусков, которые возможно.

INT>Есть ли хоть что-то в каком-нибудь языке, что нельзя этим проэмулировать?

INT>Классы — легко. Строгая типизация — покрывается юнит-тестами. Присобачить поле "тип" к каждому объекту, юнит-тесты на автомате проверяют соответствие, в релизе эти поля можно и выкинуть. Полиморфизм — автоматом, наследование-реализацией объекта "Класс", инкапсуляция — автоматом и теми же юнит-тестами.


А я с тобой полностью согласен
Семантика процедурного и объектного подхода давно проработана. Можно попробовать ее отделить.
Одна проблема. Нужно позаботиться, чтобы эту семантику можно было читать. То есть какой-либо текстовый или графический язык снова необходим!
Но если берем текстовый — получаем обычный язык программирования! Ну, или несколько. Включая язык написания юнит тестинга.
Попытки сделать эффективные графические языки программирования предпринимаются не первый раз.
Например, это RADы (графические языки для создания интерфейсов), UML и прочая Model-Driven Architecture, старенькие блоксхемы...

Пожалуй, моделирование и проектирование (хотя бы в рамках системного подхода, всего помаленьку) + программирование (UI+ООП+RDB+OODB) + специфицирование (UI-tests+те же unit-tests+DB-tests) — это наиболее перспективный и эффективный подход. Надо работать дальше... сделать удобную и полнофункциональную среду для разработки проектов, например. Обеспечить поддержку библиотеками, шаблонами и примерами. И методологию задокументировать. Чтобы был рай. Как видишь, хотели самого нового и удобного, а получилось все как есть.
Кстати, добавлю про АОП. Штука хорошая, только опять же, чтобы не забыть, где мы ее применяли и как , нужны те же язык моделирования + язык программирования + язык специфицирования...
/bur
Re[2]: Языки в бане
От: INTP_mihoshi Россия  
Дата: 18.03.04 11:40
Оценка:
Здравствуйте, 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. Там уже просекли, что одной только информации о типе недостаточно и проверки на состояния входных параметров должны быть более гибкими. Так что "строгость" т.н. строго типизированных языков — тоже "строга" лишь частично.
Re[2]: Языки в бане
От: INTP_mihoshi Россия  
Дата: 18.03.04 11:50
Оценка:
Здравствуйте, BUran, Вы писали:

BU>А я с тобой полностью согласен

BU>Семантика процедурного и объектного подхода давно проработана. Можно попробовать ее отделить.
BU>Одна проблема. Нужно позаботиться, чтобы эту семантику можно было читать. То есть какой-либо текстовый или графический язык снова необходим!
BU>Но если берем текстовый — получаем обычный язык программирования! Ну, или несколько. Включая язык написания юнит тестинга.
BU>Попытки сделать эффективные графические языки программирования предпринимаются не первый раз.
BU>Например, это RADы (графические языки для создания интерфейсов), UML и прочая Model-Driven Architecture, старенькие блоксхемы...

Все так, но посмотри на математику. Там ведь как-то смогли отделить символ от объекта. Понадобилось им новое обозначение — добавили. Не совпали в обозначениях — поматюгались, синхронизовались и работаем дальше.

Язык-то необходим, но надо уметь различать язык и описываемый объект, смысл и артефакты. Наверно, проблема в привычке... В конуе концов, изначально все сводилось действительно к тексту — к машинному коду. Но сейчас нам надо как-то описывать реальные понятия и объекты...
Re[2]: Языки в бане
От: uriy999 Россия http://yurnik.narod.ru
Дата: 18.03.04 12:22
Оценка:
Здравствуйте, BUran, Вы писали:

BU>Здравствуйте, INTP_mihoshi, Вы писали:

BU>нужны те же язык моделирования + язык программирования + язык специфицирования...

А, кстати, не пробовал ли кто нибудь когда нибудь создать язык, программы на котором являються одновременно и моделью и спецификацией и исполняемым(компилируемым) кодом?
Усё уже украдено — до нас...
Re[3]: Языки в бане
От: Tan4ik Россия  
Дата: 18.03.04 12:43
Оценка:
BU>>нужны те же язык моделирования + язык программирования + язык специфицирования...

U>А, кстати, не пробовал ли кто нибудь когда нибудь создать язык, программы на котором являються одновременно и моделью и спецификацией и исполняемым(компилируемым) кодом?


Овчинка выделки...
---
С уважением,
Лазарев Андрей
Re[3]: Языки в бане
От: _Obelisk_ Россия http://www.ibm.com
Дата: 18.03.04 13:27
Оценка:
Здравствуйте, uriy999, Вы писали:

U>Здравствуйте, BUran, Вы писали:


BU>>Здравствуйте, INTP_mihoshi, Вы писали:

BU>>нужны те же язык моделирования + язык программирования + язык специфицирования...

U>А, кстати, не пробовал ли кто нибудь когда нибудь создать язык, программы на котором являються одновременно и моделью и спецификацией и исполняемым(компилируемым) кодом?


Мы это с UML 2.0 проделали



Душа обязана трудиться! (с) Н.Заболоцкий.
Re: Языки в бане
От: Sinclair Россия https://github.com/evilguest/
Дата: 18.03.04 14:24
Оценка:
Здравствуйте, INTP_mihoshi, Вы писали:
INT>Возьмем, например, ТруООП язык, тот же смоллток. Добавим юнит-тесты и JIT — компиляцию тех кусков, которые возможно.
INT>Есть ли хоть что-то в каком-нибудь языке, что нельзя этим проэмулировать?
Да. Семантика, братец, семантика. Если в языке А нет области видимости internal protected, то никакими средствами ты ее не сэмулируешь.
... << RSDN@Home 1.1.3 beta 2 >>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[2]: Языки в бане
От: INTP_mihoshi Россия  
Дата: 18.03.04 14:39
Оценка:
Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, INTP_mihoshi, Вы писали:

INT>>Возьмем, например, ТруООП язык, тот же смоллток. Добавим юнит-тесты и JIT — компиляцию тех кусков, которые возможно.
INT>>Есть ли хоть что-то в каком-нибудь языке, что нельзя этим проэмулировать?
S>Да. Семантика, братец, семантика. Если в языке А нет области видимости internal protected, то никакими средствами ты ее не сэмулируешь.
Ты не понял вопроса. В ТруОО языках можно изобразить и internal protected, и external protected, и protected, but accessible if reallyreally needed. Разумеется, на КлассовоОриентированнных языках эти не сделать — им в своих бы спецификаторах разобраться.
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.