Здравствуйте, Зверёк Харьковский, Вы писали:
ЗХ>PL/I я сходу занес в число "ископаемых". А Ада, как я понимаю — вполне жива.
С тех пор как минобороны штатов сняла ограничение на языки на АДА пишут очень мало. И в основном в госстуруктурах США. Так что для всего остального мира язык мертв. Последний стандарт АДА 95.
ЗХ>ОК. Гляну. Но ничего не обещаю. ЗХ>Потому что PHP я, например, сознательно не добавил за общей заурядностью.
Руби — это один из самых интересных исследовательских языков программирования созданных за последнее время. Я сам его не видел, но часто слышал как его приводят в пример. Ктому же именно его так никто толком и не описан на русском (вроде).
ЗХ>...и тем не менее. остальных причин это не отменяет.
Согласен.
... << RSDN@Home 1.1.4 beta 3 rev. 207>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, INTP_mihoshi, Вы писали:
INT>P.S. Вообще, пожалуй, это и может быть критерием: язык (или языки) для обучения должен позволять обучать концепциям и методам программирования, а не своим личным языковым квиркам (т.е. особенностям).
Какие проблемы будут с Шарпом? Что на нем нельзя изучить?
... << RSDN@Home 1.1.4 beta 3 rev. 207>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, Сергей Губанов, Вы писали:
VD>>>Кстати, интересно а эта программа "ИНФОРМАТИКА-21" кем была запущена? И кто ее развивает? Ну, не часная же это инициатива? А то на сайте ничего тайти не удается. Так же интересно как это все связано с министерством образования?
СГ>>Там все написано:
VD>А можно в двух словах? Он к государству имеет отношение или это частная инициатива?
Частная инициатива пытающаяся влиять на государство с целью того, чтобы в средней школе информатику преподавали на основе языка Component Pascal в среде BlackBox.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, Сергей Губанов, Вы писали:
СГ>>Как возник этот проект СГ>>http://www.inr.ac.ru/~info21/kak.htm
VD>Кстати, слова "по-дилетантски спроектированного" выдают скорее дилетантство писавших статью.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, Sinclair, Вы писали:
VD> Вот только такая учеба сравни с колеченьем.
И что с Вами таким делать? Либо аргументированно это объясните, либо я опять скажу (со ссылкой на info21), что компетентные в этом вопросе люди утверждают прямо противоположное.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, Sinclair, Вы писали:
S>>Отсутствие концепции интерфейса не даст возможности разделить спецификацию поведения от ее реализации. Я понимаю — он пытается до последнего цепляться за свое утверждение "алгоритмы+структуры=программы". Имхо подобное преподавание ООП оставит о нем совершенно неверное представление в головах учеников.
VD>Гы. Там не только интерфейсов нет. Там даже человеческой защиты нет. Поинтерисуйся о методах скрытия (инкапсуляции) применяемых в Обероне 2.
Кстати, хорошая тема, надо будет ее как-нибудь развить в отдельной ветке. Сейчас только вскользь упомяну, что с инкапсуляцией в оберонах все в порядке.
Здравствуйте, serg_mo, Вы писали:
_>Представь себе, открывал неоднократно, и VS и IDEA. Действительно, было интересно, особенно то, что для того, чтобы поэкспериментировать с каким-либо классом, приходилось создавать новый проект, компилять его... _>И все для того, чтобы посмотреть, как работает какой-то метод.
Потому что это средства профессинональной разработки. Для того чтобы просто поэкспериментировать можно использовать снипет компиляторы.
_>Я абсолютно согласен, зная С/С++, изучение Явы или Шарпа не будет большой проблемой (ну, может, разве что анонимные классы в Яве поднапрягут слегка . Но это при условии, что ты знаком с С. Я знаю людей, которые шли по пути Pascal/Delphi и имели большие трудности с освоением синтаксиса C#, хотя люди были хорошие программисты.
Я сам больше 6 лет писал на Дельфи. Сложностей освоения джавы я не испытывал.
Здравствуйте, VladD2, Вы писали:
VD>Между целыми и булевыми, и списками и булевыми: VD>
VD>a = [1, 2]
VD>if a[0]:
VD> c = 1
VD>if a:
VD> c = 2
VD>a = 1
VD>if a:
VD> c = 2
VD>
Кстати, очень удобно. Ещё никто не жаловался, даже наоборот...
Если сильно захотеть, это можно конечно назвать неявным приведением к типу, но можно и не называть. А сказать, что запись вида "if a:" или "not a" приводит к проверке поддержки объектом acheckfortruth-интерфейса, отвечающего за такого рода проверки.
В шарпе, при подстановке в foreach у последовательностей неявно запрашивается IEnumerable. Это тоже плохо?
Ещё, как ни ужасно это звучит, при передаче фактичеких параметров в функции они автоматически кастятся к типам формальных (если, опять же, поддерживают нужные интерфейсы).
Вот напугал. А в Zonnon-е есть абстракция еще более крутая чем интерфейс, называется definition.
definition подобны interface плюс следующие фичи:
1) definition кроме методов могут включать в себя еще и переменные
2) definition может иметь предопределенную реализацию (implementation) некоторых методов.
Другими словами, с помощью definitions создается тот же самый эффект, какой создавался в Си++ посредством множественного наследования, вот только без всяких побочных эффектов самого множественного наследования как такового, поскольку definitions — это все таки интерфейс.
Здравствуйте, Сергей Губанов, Вы писали:
СГ>Здравствуйте, VladD2, Вы писали:
VD>>Здравствуйте, Сергей Губанов, Вы писали:
СГ>>>Как возник этот проект СГ>>>http://www.inr.ac.ru/~info21/kak.htm
VD>>Кстати, слова "по-дилетантски спроектированного" выдают скорее дилетантство писавших статью.
СГ>Но он действительно по-дилетантски спроектирован.
В отношении программирования ситуация очень похожа: навыки беспорядочного, "корявого" программирования быстро становятся привычкой и формируют совершенно неадекватное программистское мышление...
Умение "правильно" программировать ИМХО не зависят от языка программирования. Можно коряво программировать и на Пакале и на Обжект Паскале (ака Дельфи) и на С и на С++ и на Яве и ...
На любом языке программирования можно создавать неработоспособные или неэффективные системы.
Другое дело, что язык и/или среда программирования может слегка корректировать программиста, но это никогда не остановит программиста от создания монстров.
Здравствуйте, Mamut, Вы писали:
M>Умение "правильно" программировать ИМХО не зависят от языка программирования. Можно коряво программировать и на Пакале и на Обжект Паскале (ака Дельфи) и на С и на С++ и на Яве и ...
Именно поэтому все из перечисленных Вами языков были отвергнуты. В качестве стандарта был выбран Component Pascal на котором коряво программировать не получится.
Коряво программировать в пределах одного модуля — возможно не получится.
Но умение правильно программировать не упирается только в типобезопасность, или в легкость синтаксиса, или удобство подмножества каких-либо операций (арифметических или иных). Такие "фишки" — та самая "слегка" помощь программисту, которая никак не поможет ему в создании сложной системы, например.
Умение правильно программировать — это прежде всего умение понять поставленную задачу, умение планировать, умение разделять задачу на более мелкие задачи, умение отслеживать зависимости и много еще чего.
При этом:
— типобезопасность? Если изначально были неправильно выбраны типы, то горе-программер никуда не уйдет от рефакторинга всего кода, где эти типы использованы (ну или будет использовать какой-нибудь reinterpret_cast в С++).
— модуль, как логическая структура программы? Неправильное разбиение на модули — и все, программа рухнула, так как начнется взаимный импорт модулей, количество зависимостей возрастет настолько, что в программе без банки пива и опять же рефакторинга всего кода не обойтись.
При чем все это справедливо и для других языков программирования, не только для Оберона.
Язык не может быть панацеей для программиста. Вне зависимости от языка можно создать монструозные неэффективные программы. И Оберон никак не поможет человеку, нежелающему научится думать и планировать. А для обучения этому С# или Питон ничем не хуже Оберона (или даже лучше — ввиду того, что они широко распространены и активно развиваются)
Здравствуйте, Сергей Губанов, Вы писали:
СГ>Вот напугал. А в Zonnon-е есть абстракция еще более крутая чем интерфейс, называется definition.
СГ>definition подобны interface плюс следующие фичи:
СГ>1) definition кроме методов могут включать в себя еще и переменные СГ>2) definition может иметь предопределенную реализацию (implementation) некоторых методов.
Проанализируем с точки зрения Java (хоть она и не упоминалась в контексте предыдущего сообщения).
Для Java (например) это были бы вредные фичи. Интерфейс — это контракт на поведение, абсолютно без намеков на реализацию.
Пункт второй привносит зависимость от реализации в интерфейсе (интерфейс здесь и ниже имеется ввиду как Java-интерфейс + 2 вышеприведенных пункта) — что нарушает такой принцип как stable Abstractions Principle — абстрактные сущности должны быть стабильны. А зависимость от реализации делает сущность (интерфейс + 2 приведенных пункта) нестабильной.
Пункт первый, кстати, вреден по той же причине. Переменные — часть реализации. А вот свойства — это часть интерфейса, они хоть и зло (поскольку описывают не поведение, а содержание), но зло меньшее чем переменные (переменные в моем понимании — поля в Java-классах).
Так что с моей точки зрения эта "более крутая абстракция" либо плоха, либо просто предлагает другую концепцию, нежели "классическое"ООП (в моем понимании, конечно ).
P.S. Тем не менее я согласен с тем, что подключения предопределенных реализаций интерфейсов полезная штука (при отсутствии множественного наследования).
P.P.S. Так, мысли вслух, про Zonnon ничего не знаю
Здравствуйте, Сергей Губанов, Вы писали:
СГ>Частная инициатива пытающаяся влиять на государство с целью того, чтобы в средней школе информатику преподавали на основе языка Component Pascal в среде BlackBox.
Ясно. Будем надеяться оно не поддастся.
... << RSDN@Home 1.1.4 beta 3 rev. 207>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Сергей Губанов, Вы писали:
СГ>Но он действительно по-дилетантски спроектирован.
Автор этих строк спроектировал хотя бы один язык? Я уже не говорю о том, что на С++ работает половина программистов.
С теми условиями (сохранение обратной совместимости с С) сделать нечто другое было просто невозможно. Почти все отрицательные черты являются следствием наследия С. А то что спроектировал Страуструп более мнее неплохого качества. Можно было конечно сделать и лучше, но уж дилетанством — это не назавешь.
Ну, а подобные заявления выдают в авторе крикливого дилетанта. В общем, на вашем месте я спягчил бы формулировку. А то как-то совсем не серьезно.
... << RSDN@Home 1.1.4 beta 3 rev. 207>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Сергей Губанов, Вы писали:
СГ>Именно поэтому все из перечисленных Вами языков были отвергнуты. В качестве стандарта был выбран Component Pascal на котором коряво программировать не получится.
А можно поглядеть на примеры кода написанного на нем?
... << RSDN@Home 1.1.4 beta 3 rev. 207>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, eugals, Вы писали:
E>Кстати, очень удобно. Ещё никто не жаловался, даже наоборот...
Ну, да. Очень удобно. Если не думать о последствиях. На Перле тоже очень удобно писать...
E>Если сильно захотеть, это можно конечно назвать неявным приведением к типу, но можно и не называть.
Это если очень захотеть, то можно попробывать не назвать вещи своими именами. А по факту — это неявное приведение с понижением. Половина опечаток пропрет даже глазом не моргнешь.
E>В шарпе, при подстановке в foreach у последовательностей неявно запрашивается IEnumerable. Это тоже плохо?
Это понижающее приведение. С ним ошибок быть не может.
E>Ещё, как ни ужасно это звучит, при передаче фактичеких параметров в функции они автоматически кастятся к типам формальных (если, опять же, поддерживают нужные интерфейсы).
При понижающем приведении это нормально. Но когда int приводится к bool или список приводится к bool, то это уеж чревато ошибками.
Ну, а объявление переменной при первом использовании, да еще и внутри вложенных блоков с видимостью во вне — это просто бардак. Тут еже баги будут пить дать.
... << RSDN@Home 1.1.4 beta 3 rev. 207>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.