Как вы относитесь к паскалю? , (есть гипотеза)

Цитата [S]mike @ 04.01.14, 23:28

Цитата D_KEY @ 04.01.14, 19:26

Скорее всего, код чаще читаю, чем пишу.

О чем тогда спорим?

А у тебя не так? Сколько времени ты тратишь на непосредственное написание какой-то фичи, а сколько на чтение своего и чужого кода в проектах(в том числе и во время реализации фичи)? Я вообще не понимаю, как может быть проблемой добавление поля

Добавлено 05.01.14, 10:38
Надо бы это как-то замерить...

Цитата --Ins-- @ 04.01.14, 09:09

Цель - чисто визуальное отделение объявлений и заголовков от реализации для лучшей читаемости кода.

Т.е. то, что в части реализации могут быть объявлены приватные переменные, типы, процедуры и т.д. тебя не смущает?

Добавлено 05.01.14, 11:28

Цитата OpenGL @ 04.01.14, 09:53

обучаясь реализовывать алгоритмы.

При изучении алгоритмов, не учат их реализовывать.

Цитата korvin @ 05.01.14, 11:28

Цитата OpenGL @ 04.01.14, 09:53

обучаясь реализовывать алгоритмы.

При изучении алгоритмов, не учат их реализовывать.

Что? Не обращают внимание на детали, да. Но простая реализация на практических занятиях обычно требуется.

Цитата korvin @ 05.01.14, 11:28

При изучении алгоритмов, не учат их реализовывать.

Тогда толку от такого обучения будет немного.

Цитата --Ins-- @ 05.01.14, 06:41

А, ну это ты просто иде пользоваться не умеешь, иначе бы знал, что это можно делать не подымаясь наверх

Это ты про Introduce Field в рефакторинге? Смешно. В диалоге даже нету возможности указать тип переменной, что он там "угадает" - никому непонятно. В Эклипсе для всех джава рефакторингов есть превью, кстати.

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

Цитата D_KEY @ 05.01.14, 10:37

А у тебя не так? Сколько времени ты тратишь на непосредственное написание какой-то фичи, а сколько на чтение своего и чужого кода в проектах(в том числе и во время реализации фичи)? Я вообще не понимаю, как может быть проблемой добавление поля

Если проект - чистый саппорт, то может и да, чтение чужого кода будет занимать больше времени. Но отсутствие интерфейса у класса не является для меня проблемой - есть окно Outline в Эклипсе. Там очень удобно, что есть фильтры, можно включить сортировку - чего в интерфейсе класса не сделаешь.

А как в новом или развивающемся проекте без написания нового кода?

Цитата [S]mike @ 05.01.14, 12:53

Цитата D_KEY @ 05.01.14, 10:37

А у тебя не так? Сколько времени ты тратишь на непосредственное написание какой-то фичи, а сколько на чтение своего и чужого кода в проектах(в том числе и во время реализации фичи)? Я вообще не понимаю, как может быть проблемой добавление поля

Если проект - чистый саппорт, то может и да, чтение чужого кода будет занимать больше времени.
...
А как в новом или развивающемся проекте без написания нового кода?

Так даже этот новый код ты читать будешь больше, чем писать, нет? Ну или по крайней мере сопоставимое время... Или написал неглядя чтоб работало и забыл ? Мне почему-то кажется, что код в принципе больше читают, чем пишут. Но нужно как-то замерить...

Добавлено 05.01.14, 18:16

Цитата

Но отсутствие интерфейса у класса не является для меня проблемой - есть окно Outline в Эклипсе. Там очень удобно, что есть фильтры, можно включить сортировку - чего в интерфейсе класса не сделаешь.

Оно может и удобно при написании кода, но вот при чтении... Не знаю. В общем, в возможности отделения объявлений от определений я вижу только достоинства, а вот недостатки(дублирование, например) вполне компенсируют средства IDE. Я кстати, так и не понял твой пример... По мне так проще переключиться на объявление класса(без реализации), добавить поле и вернуться к тому же месту реализации, где ты остановился, чем искать в единой портянке место для поля...

Вообще, мой опыт работы с шаблонными классами в плюсах, где часто пишут как раз портянки(ибо определение шаблона должно быть в заголовочных файлах), говорит о том, что это менее удобно, чем разделение... Потому люди таки стараются разделять объявления и определения даже для шаблонов... А еще я уверен, что если бы в Яве так можно было делать, то люди бы так и делали

Цитата D_KEY @ 05.01.14, 18:08

Так даже этот новый код ты читать будешь больше, чем писать, нет?

Дык, ты же просматриваешь новые строчки и соседние, а не весь код.
Мне нравится вывод diff на втором мониторе...

Цитата D_KEY @ 05.01.14, 18:08

А еще я уверен, что если бы в Яве так можно было делать, то люди бы так и делали

Ага - сейчас же В плюсах это больше необходимость, чем удобство - для линковки. В джаве и шарпе же не имеет вообще значение, в каком порядке ты декларируешь методы, переменные, классы - крайне удобно, кстати.

Цитата [S]mike @ 05.01.14, 23:21

В плюсах это больше необходимость, чем удобство - для линковки.

Не для линковки, а для компилятора, ибо язык требует объявления всех используемых сущностей.

Цитата [S]mike @ 05.01.14, 23:21

В джаве и шарпе же не имеет вообще значение, в каком порядке ты декларируешь методы, переменные, классы

Эта фича ортогональна разделению объявления и реализации.

Читал статью, в которой сам Вирт позиционировал паскаль как язык для демонстрации современных (на момент его создания) методов программирования.

Это:

• описанные Дейкстрой принципы структурного программирования;
• описанные им же методы доказательства правильности программ (инварианты и т.п.);
• структуры данных (включая работу с динамической памятью);
• демонстрация работы достаточно сложных алгоритмов манипулирования данными;

При этом к языку предъявлялись

• Язык должен был иметь простую грамматику, чтобы уменьшить количество допускаемых студентами ошибок, и чтобы разработка компилятора не занимала много времени (в то время ещё существовала конкуренция среди платформ).
• Язык должен был допускать быструю компиляцию (в то время это означало ещё и однопроходность). Качество объектного кода не имело большого значения, большинство программ должны были исполняться один-два раза. В принципе компилятор мог компилировать программу в память и сразу запускать её на исполнение.
• Компилятор должен был давать качественную диагностику ошибок во время компиляции.
• Требовался мгновенный контроль ошибок исполнения (выход за пределы массива, выход за пределы допустимых значений, доступ по пустому указателю и т.п.).
• Поскольку язык не предназначался для написания серьёзных программ, не требовалась развитая библиотека, достаточно было некоторого базового набора функций. По этой же причине не требовалась поддержка раздельной компиляции модулей.

Существующие языки этим требованиям не удовлетворяли, поэтому Вирт и взялся за разработку нового языка и компилятора для него.
В принципе этим требования лучше отвечал бы какой-нибудь интерпретируемый язык, но тут Вирт похоже дал слабину, надеясь, что паскаль может пригодиться и в промышленном программировании (например для написания простых программ). Или может быть у него было какое-то предубеждение против интерпретаторов - может он думал, что работа с интерпретатором как-то расслабит студентов (вроде именно это было главным фактором).
Так и родился язык, почти не допускающий эффективной компиляции, имеющий слабенькую библиотеку, который тем не менее благодаря простоте и возможности создания исполняемых файлов занял довольно большую долю в разработке ПО.
Для промышленного программирования Вирт позднее разработал семейство похожих на паскаль (видимо в расчёте, что студенты пересядут на них с учебного паскаля) "модул". Позднее он перешёл к ним и в учебном процессе.
Однако модулы, хоть и были заметно развитее Паскаля, тоже оказались в каком-то смысле ущербными (в частности, их невозможно оказалось совмещать с другими языками, с тем же фортраном, на котором к тому времени было написано множество библиотек).

Кстати, Turbo-Pascal 5.5 уже был ОО языком, хотя, похоже, почти никто его ОО-возможностями не пользовался.

Цитата amk @ 07.01.14, 20:29

Кстати, Turbo-Pascal 5.5 уже был ОО языком, хотя, похоже, почти никто его ОО-возможностями не пользовался.

Только Вирт не имел никакого отношения к turbo pascal, к моменту появления которого(первой версии) у него уже была Модула-2.

amk

Цитата amk @ 07.01.14, 20:29

Кстати, Turbo-Pascal 5.5 уже был ОО языком, хотя, похоже, почти никто его ОО-возможностями не пользовался.

Borland удачно продавал Visio библиотеку.

Цитата Pavia @ 08.01.14, 16:06

Borland удачно продавал Visio библиотеку.

TurboVision. Visio - это совсем другое и от Microsoft.

Сообщение отредактировано: trainer - 09.01.14, 08:29

Наверное, имелся в виду Turbo Vision

Все-таки, мне кажется, что не Visio, а Turbo Vision...