Морально устаревшие элементы языков программирования высокого уровня
Языки высокого уровня были задуманы, чтобы облегчить программирование по сравнению с ассемблером и машинным кодом. В этом они достигли достаточно больших успехов. Но для их использования существовало еще одно ограничение – скорость компиляции кода. Поэтому в языках высокого уровня остались элементы, которые нужны только компилятору, но не нужны человеку.
Однако сейчас производительность обработки текста программы (компиляции) уже не имеет решающего значения, а каждый введенный программистом символ, наоборот, стоит все дороже и дороже. Поэтому некоторые элементы оформления кода можно считать морально устаревшими.
Объявление библиотек и структуры объектов
В целях повторного использования кода программа делится на модули или классы.
Чтобы собрать эти объекты вместе, нужно указать компилятору, где их искать.
Самый логичный с точки зрения программиста вариант – указать, где расположена библиотека ядра, несколько личных библиотек, причем все это указывать в проекте.
В самой программе достаточно указать только имя класса. Библиотеки должны быть проиндексированы, чтобы по имени класса определить, есть ли он в библиотеке и должна ли подключаться библиотека. В любом случае имя класса уникально.
Однако что мы видим на практике?
В Паскале, в Си++ и в Java программист должен явно указывать, какие библиотеки использовать (uses, include и import соответственно).
Особенно страшно дело выглядит в Си++ - программист должен указывать еще и заголовочные файлы (с расширением H), следить, чтобы заголовочные файлы не включались дважды. Одно это отталкивает от Си++, несмотря на все преимущества ООП.
В Java можно включать библиотеки верхнего уровня, при этом подбиблиотеки включаются автоматически – по сути, подключаются лишние библиотеки ради упрощения написания кода. Подход хороший, но не идеальный. Идеально было бы определять библиотеки автоматом, по составу классов.
Конечно, использование IDE немного нивелирует эти проблемы, но IDE все равно не решает всех проблем, в любом случае человек видит этот лишний, по сути, мусорный код, и тратит на него свое внимание. Программа в любом случае может лучше человека определить, какие модули нужны.
Поэтому нужно запретить явное указание библиотек человеком для улучшения читаемости и скорости ввода программ.
Объявление интерфейса вместе с реализацией
Если объявлять интерфейс класса отдельно от реализации, как это принято в Си++ и Паскаль, код программы увеличивается и по сути, дублируется. Ничто не мешает компилятору собрать объявление из реализации класса. В Java это поняли и поэтому код стал лаконичнее и прозрачнее. В Си и Паскале при изменении интерфейса приходится менять еще и реализацию, т.е. делать никому не нужную, излишнюю работу.
Объявление переменных
В этом плане отстает только Паскаль. Только в угоду компилятору локальные переменные можно объявлять только в начале процедуры, хотя ничто не мешает определить, сколько локальных переменных используется в процедуре и отвести под них необходимое место.

XDiaBLoFixin,

Не мусорный, после того как класс написан, достаточно при использовании смотреть в .h-файл, чтобы узнать интерфейс. Это очень удобно. З.Ы. Прошу прощения, Вы ещё студент, и не имеете опыта работы?

Почему H файл (интерфейс) не может быть создан на основе имеющейся реализации?
Вы забываете, что это удобство вылазит боком в том, что человек должен сначала долбить интерфейс, потом реализацию. По крайней мере в Java не так.

eee-pcтак, например, никто не заставляет вам обьявлять реализацию в си отдельно. но при этом отдельная реализация позволяет разделять headers что существенно упрощает линковку. не говоря уже о том, что можно писать херову кучу классов в одном файле (в яве на это есть ограничения)
Вы говорите о упрощении линковки... А не кажется ли вам, что линковка уже морально устарела?
Перечитайте еще раз пост. Зачем человеку думать о линковке, если этим должен заниматься компилятор. Человеку достаточно указать имя классов...

XDiaBLoЕсли не объявлять интерфейс отдельно в С++ например, то методы будут inline, насколько мне известно, а это не всегда то что нужно.
Опять 25. Я вам и объясняю, что С++ как язык высокого уровня в части линковки уже УСТАРЕЛ !

MasterZiv
потому что в Java сборка происходит при запуске

Тем более - если сборка происходит при сборке, банальный кэш имен классов решает проблему - зная имя найти имя библиотеки как два байта переслать. Смысл программисту напрягаться и указывать библиотеку?


MasterZiv
А на самом деле тут дело ещё хуже, чем в С/С++, как ни странно.
В С/С++ сборка вынесена из языка, и в заголовочном файле
только на логическом уровне указывается, что есть какая-то
такая функция или переменная, которую я буду использовать.
А где она физически находится, и вообще как сборка физически
производится, на уровне языка вообще не определяется. Т.е.
язык отделён от физического уровня сборки. В Java же классы --
это элементы в том числе и физической организации программы,
и ты В ИСХОДНЫХ КОДАХ их должен указывать.

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

MasterZiv
Бред. Ничего не дублируется.

Ну как же не дублируется, если интерфейс и реализация содержат одни и те же заголовки, без IDE никак.


MasterZiv
Ну, паскаль и не только в этом плане отстаёт. Да он вообще сдохнет
совсем скоро, и туда ему и дорога.

Солидарен.

цешарпщикFixinВ Паскале, в Си++ и в Java программист должен явно указывать, какие библиотеки использовать (uses, include и import соответственно). Uses, include и import нужны для того, чтобы было понятно из какой библиотеки ты будешь дергать класс Date (к примеру), из java.util или из javax.sql.SQLDate

Можешь тупо без import всё писать, но все названия классов при этом раскрывать полностью, никто import делать не заставляет же

Это нужно для тех классов, где имена дублируются.
Опять же, расстановкой приоритетов библиотек в проекте эта проблема решается.

Ты хочешь сказать, что если я напишу класс TDialog и не укажу библиотеку, она мне найдет сама нужную библиотеку при условии уникальности имени класса??? Сильно сомневаюсь, скорее пошлет.

XDiaBLoFixinXDiaBLoЕсли не объявлять интерфейс отдельно в С++ например, то методы будут inline, насколько мне известно, а это не всегда то что нужно.
Опять 25. Я вам и объясняю, что С++ как язык высокого уровня в части линковки уже УСТАРЕЛ !
Да чтож это блин? Всё там замечательно, мне ничто не мешает, и вполне удобно. Файлы интерфейсов пользователю реализаций, даже удобнее чем компилятору, т.к. не надо лопатить исходник, достаточно посмотреть заголовки функций.

Еще раз:
1. Файл интерфейса можно получить автоматом, если надо, или в той же IDE посмотреть только заголовки функций, зачем требовать его обязательное наличие?
2. Почему я должен писать IF DEFINE в каждом H-файле.
3. Зачем я должен следить за именами H-файлов?
4. Зачем мне вообще H-файлы, если найти нужное описание класса может и сам компилятор?
5. Допустим, пусть есть интерфейс, но почему тогда я не могу просто написать в реализации, что в данном файле я описываю класс такой то (один раз), затем пишу имя каждого метода (без параметров, параметры будут вытягиваться из объявления) и просто писать код метода.
Зачем этот бред с дублированием информации. С++ - это язык для компилятора, а не человека.

XDiaBLo

Ну как же? А охота писать каждый раз полный путь до класса, с указанием пакета??? Так удобнее???

Вы о чем? если имя класса уникально, JAVA должна сама его найти, а если есть варинаты swing/awt, то я в проекте укажу предпочитаемую библиотеку или укажу вызов import явно.
Мысль понятна?

Проблема в том что без import JAVA не найдет мой класс, даже если его имя уникально, вот!

XDiaBLo
Ваши проблемы надуманны. Если бы кто-то сделал язык, пользуясь вашими рекомендациями, я бы его придушил.

Может обоснуете, или я буду считать это эмоциями?

XDiaBLo
Не катит. Это половинчатое решение, т.к. очень часто имя будет неуникально. Да и к путанице приведёт сей подход.
Очень часто - это в каких случаях?
Для своего проекта я использую свои имена классов и полностью их контролирую и мне не нужно указание import.
А путаница идет как раз от того, что классы называются одинаково. Смысл?

Зачем нужны заголовки и импорты в программах высокого уровня?

В C++ для ООП include используется для включения объявлений классов. После компиляции программа определяет, какие классы используются в программе и собирает их из LIB-библиотек и OBJ-файлов. При этом она сама определяет, из какой библиотеки брать тот или иной файл.
Спрашивается – почему нельзя проиндексировать H-файлы библиотеки и проекта и составить индекс используемых классов?
Тогда компилятор бы определял, какие классы используются в проекте и сам бы подключал нужные H-файлы.

Зачем нужны интерфейсы?
В некоторых случаях интерфейсы действительно нужны, когда реализация не задается или откладывается. Но чаще бывает, что реализация известна.
Предлагается использовать следующий подход: разрешать описывать реализацию вместе с интерфейсом или по отдельности.
Если интерфейс описан отдельно, то реализация выглядит так:
#Implementation ClassName
Method1 {
}
Method2 {
}
То есть в реализации дублируются только название класса (один раз) и название методов, без параметров. Если так уж нужно разделить реализацию и интерфейс.

BagaBagaПредлагаю Fixin реализовать компилятор, который ему так нравится. Со всеми так необходимыми ему фишками.

PS
А потом посмотрю, как поможет ему уникальность, когда в новой внешней библиотеке, на которую собрались "перехать" - о чудо! - вдруг случится пересечение с именами из его чудо-проекта...
Вы не слышали рекомендацию, что в названиях классов нужно указывать имя/ник своей компании и т.п.? Мне кажется, проблема надумана и высосана из пальца.

XDiaBLoМеня ни капли не напрягает создать заголовочный файл вручную, меня не раздражают конструкции рода
А ведь я очень раздражительный человек :-\

Эту работу должен делать компьютер, а не человек. Не все как вы спокойно относятся к монотонному труду.

XDiaBLoВаши проблемы тоже в основном зиждятся на эмоциях и нелюбви к каким-либо фичам. Почему я на эмоции не могу отвечать эмоциями? Ну просто вы же не слушаете мои аргументы, зачем я их вообще пишу?
Слив засчитан. Моя тема посвящена не эмоциям, а лишнему тексту, который должен набирать человек, хотя вместо него это может и должен делать компилятор.

случайныйнаборсимволовтутТоварищ просто никогда в жизни не писал серьезных программ, не работал в команде...
Зачем ему отделение реализации от интерфейса, если у него все реализации в OnButtonClick (Кнопка1Нажатие раз он одинэсник) живут?
Для таких как он современные IDE естественно неудобны - у них другая целевая аудитория. Подстраивать же средства разработку под ламеров... ну странный подход. Казалось бы, от того что каждый инженер должен уметь писать программы общество со времен Фортрана ушло...

Да вы што. H-файлы тоже нужны для командной разработки? Без них ну никак в командной разработке, да? Давайте поговорим про H-файлы.