Апгкменты поражают своей силой, конечно же.

А думаете FPC там осилят или будут кнопочке в лазарусе расскидывать?

На экономическом МГУ программирования сводят к листам Екселя (!). Негативные примеры достоверно свидетельствуют гарантировано лишь о лени и забивании.

В МГТУ Си довольно успешно используеьтся на непрофильных спецухах и средних студентах.

Книжка несомненно хорошая и нужная. Но видится, что для поднятия интереса к FPC и Linux нужна книжка уровня, как:
Поляков Д.Б., Круглов И.Ю. Программирование в среде Турбо Паскаль (версия 5.5.): Справ.- метод. пособие. - М.: Издательство МАИ, А/О «Росвузнаука», 1992,. 576 с.

Ну дык уже ведь объяснялось выше: кретинической массе пасквилянтов AVR/AVR32 не нужен.

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

VB - умер, а то что вместо него придумали в MS - VB.net это совсем другой язык ничем не оправдывающий свое существование - т.к. де факто это C# с другими ключевыми словами.

Ты в курсе что на паскале написаны например первые версии Mac OS? И это было задолго до того как маг скатился в голимое айронби

Самая первая Windows была написана на паскале...

Вряд ли. Смысл?

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

>В целом с тобой согласен, просто я не уверен, что в школе надо давать азы создания динамических веб-страниц

Да проснись ты наконец. «Динамические веб-страницы», это совсем из другой оперы. Вот ЛОР, например - динамическая веб-страница. А gmail, google reader и google docs - веб приложения, и строятся они на основе совершенно других принципов.

По идее, сейчас нет необходимости генерить HTML на стороне сервера, как это делает PHP или JSP. Помотри на JQuery, посмотри на googl'евские виджеты, на yahoo'вские виджеты. Или вообще киллер-пример, где веб-приложения крутятся в среде CouchDB, и где веб-сервак выполняет функции обратного прокси, урл-реварйтера, управления доступом и раздатчика статического контента.

Вы очень точно описали использование Паскаля и его последствия

>Этого в Паскале не было. А в С есть. Ужас.

чего «Этого»? возведения в произвольную степень нет ни в паскале ни в СИ, есть в стандартной библиотеке как первого, так и второго.

за список софта спасибо - не знал, что скупе начинали пейсать на делфях. теперь-то весь он юзает кьют...

и да, если честно, пока я нахожу лазарус немногим удобней кьюта для кухонного домашнего кодинга прикладных программ =)

толсто ведь...

>А думаете FPC там осилят или будут кнопочке в лазарусе расскидывать?

вообще то паскаль традиционно изучают в _школах_ РФ по предмету информатика. и вполне осваивают на уровне синтаксиса, базовых структур и алгоритмов. есть наработанные методики обучения и проверки знаний. после этого освоить другой язык программирования проблем не представляет. В ВУЗах введение в язык программирования - это 2 - 3 лекции, но это срабатывает если есть фундамент в виде программирования на уроках информатики в школе.

На экономическом МГУ программирования сводят к листам Екселя (!). Негативные примеры достоверно свидетельствуют гарантировано лишь о лени и забивании.

бывают задачи которые эффективно не покрыть excel'ем.

В МГТУ Си довольно успешно используеьтся на непрофильных спецухах и средних студентах.

так никто и не говорит, что это не возможно. но на этом уровне pascal выглядел бы не хуже, а с учётом некого бэкграунда и свойств самого языка (более строгой типизацией относительно СИ, поддержка ООП, исключений, простых дин. массивов БЕЗ указателей, абстракций более высокого уровня таких как потоки ввода вывода) возможно был бы эффективнее позволяя более концентрироваться на задаче чем на технологии программирования.

>теперь-то весь он юзает кьют...

по-моему и сейчас не весь - версия под Win32 сильно отличаеться интерфейсом от версий под другие платформы, скорее всего гуйня под вин все ещё там лепиться на Дельфах. Мне интерфейс и скорость работы скайпа под Win субьективно больше нравится..

СИ это язык в большей степени системный чем прикладной, соответственно и решение задач прикладных а не системных чаще всего будет менее эффективно чем на языках с более высоким уровнем абстракции.

python вполне удобен как прикладной язык, но на мой взгляд, он слишком высокоуровневой для начала. именно за эти свойства ругали БЕЙСИК как первый язык обучения.

Lisp - это язык общего назначения и величайшее достижение человеческой цивилизации. В частности, стандартный язык - CL.

>См. абстрактные типы данных.

Я конечно могу ошибаться, но разве в паскале есть полноценные абстрактные типы? Такие как в ML, когда компилятор _запрещает_ делать предположения о структуре абстрактного типа вне «родного» модуля?

Более того, учить сразу ООП с нуля трудоёмко опасно.

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

Но, дело в том, что в ООП ко всему прочему жестко прицеплено понятие интерфейса. Раз подтип - будь добр наследовать весь интерфейс, раз интерфейс - будь добр быть типом. Хочешь заимплементить интерфейс? Пожалуйста, но реализуй его _весь_, потому что иначе ты не сможешь быть подтипом и т.д.

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

И наверно самой главной проблемой в изучении ООП, является то что оригинальные исследовательские статьи уже безнадежно устарели, да и искать их сложновато. В современном же варианте доступны либо тонны словоблудия а-ля Буч и сотоварищи, или тонны матана навроде vObj Одерского.

Блин, это же антиреклама.

а я даж не знаю, на чем вендовый скупе последних версий писан - там сингл ехе и никаких зависимостей длл окромясь kernel32.dll... но под линь есть только старый скупе, версии эдак второй вроде. так он мне более сносен - на ноуте грузится быстрей, нежели последний скуп под венды на компе (комп в раз эдак 5+ шустрей и моццней ноута), что не может не огорчать...

а насчет внешнего вида - дык в кюте его можно почти как и в жаве настраивать вроде =)

В стандартной библиотеке паскаля её не было, добавили в fpc, но преподы уже привыкли давать через ln и эксп (кстати, в дельфях-то она есть? %)

[i]Lisp - это язык общего назначения и величайшее достижение человеческой цивилизации. В частности, стандартный язык - CL.[/i]

Только что бы читать на нем программы, нужно притворяться интерпретатором, а нормальные человеки это не любят.

> бывают задачи которые эффективно не покрыть excel'ем.

Это было к тому, что на экономе полный развал и задница, а не как пример осмысленного выбора.

поддержка ООП, исключений

Я скромно надеюсь, что это в школе обходят. Иначе Си точно проще. Особенно учитывая, что базовый ввод-вывод не использует исключения. Даже при чтении файлов fscanf уже поще, ясно как он сооюбщает об ошибке.

возможно был бы эффективнее позволяя более концентрироваться на задаче чем на технологии программирования.

В паскале вместо (в худшем случае --- кроме) указателей придется объяснять: var, setlength, high, разницу между разными видами массивов, «почему массивы хоть с трёх и по любому ordinal, а динамические от нуля», «почему передача массива не как var карасется расстрелом», «почему не надо делать SetLenght +1» и так далее.

Не, для школьников всё равно, я согласен. Для 80% школьников это недостижимый идел по информатики, судя по абитуре.

Кстати интересно, авторы ЕГЭ про какой паскаль знают? %)

> Только что бы читать на нем программы, нужно притворяться интерпретатором, а нормальные человеки это не любят.

Поддерживаю.

да ну, Component Pascal и Oberon-2 это не совсем паскаль.
Совсем паскаль — это к примеру Delphi или FPC: OOП с общим базовым классом, RTTI, классы как метаклассы (через RTTI), исключения.
Oberon-2, Modula — это ООП через связанные процедуры, расширяемые записи: PROCEDURE (T: Tree) totalSum(): INTEGER; — функция, над деревом. Аналогично, так же можно сделать PROCEDURE (A: ARRAY OF INTEGER) totalSum(): INTEGER; — то есть, расширять базовые типы (INTEGER, STRING, массивы). Методы не принадлежат классам. Такое нельзя сделать в ООП с общим базовым классом.
Это похоже на Go и интерфейсы : http://www.inr.ac.ru/~info21/go.htm http://research.swtch.com/2009/12/go-data-structures-interfaces.html

> РАЯ

по-моему, где-то лежит виртуальная машина КУМИР: http://lpm.org.ru/kumir2/

> Для i386 под MS-DOS видел весьма толковую реализацию с IDE а-ля Borland Turbo C++, но она не поддерживала даже подпрограммы, не говоря о классах.

её сейчас допортировали до Qt

> Сейчас перед основами программирования не принято стало давать информатику и основы алгоритмизации, имхо это плохо. Если бы давали... Тема была бы пуста

Вроде бы пытаются ситуацию налаживать:
http://www.inr.ac.ru/~info21/troitsklicej/bytic-xx-2009.htm
http://www.inr.ac.ru/~info21/troitsklicej/vtorojetap.htm
http://www.inr.ac.ru/~info21/texts/2006-09-SFO/v2public.htm http://www.inr.ac.ru/~info21/texts/2003-08-JMLC/ru.htm http://www.inr.ac.ru/~info21/MIL/welcome.html http://www.inr.ac.ru/~info21/princypKalashnikova.htm

скачаемс, мож с третьего раза получица.

А ещё был такой язык РАПИРА. У него с читаемостью вроде получше, чем у РАЯ было.

ух ты, даже ООП и IDE есть

> Oberon-2, Modula — [...] Методы не принадлежат классам.

Это местный вариант обобщенных функций лиспа?

> Хм, чот сейчас сунулся в инет, и не нашел достоверного источника о том, что MS Windows 1.0? анонсированная в 1983м году была написана на Pascal. А тыкать в книги по Win 3.0 API где описывался сей исторический факт думаю тыкать бесполезно (особенно если учесть что я их выкинул давно).

Можно потыкать в windows.h, там декларации были WINAPI PASCAL ...
Правда в случае Win 3.0 одно с другим не связано — сначала Win 1.0 писали на паскале, потом переписали на Си, но соглашение о вызовах функций оставили паскалевское, «потому что это сократило размер программ, вызывающих эти функции на 30%» — сdecl должно само подчищать стек после вызова функции, в pascal стек чистит сама вызваемая процедура последней инструкцией.

Интересно, Boost для FPC уже написали? в FPC есть дженерики

> gcc Столлман написал на Паскале =))

по-моему, на лиспе. На своём особенном лиспе, как с емаксом. Эти RTL и GIMPLE деревья в компиляторе — сущий лисп.

А ты что для этого сделал?

Ты себе представляешь процесс добавления поддержки новой архитектуры в компилятор? Так и представил, я, тогда вчерашний школьник, сижу добавляю поддержку несуществующей в те годы архитектуры =))) Появляется AVR32, говорят - вот вам gcc и g++ для него, а ты говоришь «нет! я буду чесать против шерсти ради паскаля»...

> Но, дело в том, что в ООП ко всему прочему жестко прицеплено понятие интерфейса

не в любом ООП, а только в ООП с общим предком и вирт. функциями. Например, в Objective C интерфейс — это «категория» или «протокол», и отделено от конкретных классов. В лиспе интерфейсы — это протоколы, в Go вообще нет ООП, но есть интерфейсы.

Хочешь заимплементить интерфейс? Пожалуйста, но реализуй его _весь_, потому что иначе ты не сможешь быть подтипом и т.д.

оно в общем-то и логично, ради цельности такого интерфейса.

Я прекрасно понял красоту Си. А еще я вижу код чистых Сишников и математиков. Это, мягко говоря п..ц.

строки

>Насколько я понял, фундаментальная проблема Пасквиля для прикладного >программирования осталась неизменной со времен Турбо-Пасквиля: >размерность типа string всё так же 255 символов. Не смешно.

я скажу наоборот, в паскале есть стока разных строк, что с ума сойти, есть shortstring, есть ansistring, который сейчас по умолчанию, кажись, string, есть pchar, есть widestring... причем сам strin, т. е. ansistring это менеджед динамический массив, занимает до двух не то четырех гигабайт места. при присваивании этой строки другой на самом деле копируется указатель на нее, а не она вся, есть reference count этих указателей, короче, сложно.

в этом смысле Вирт решил не заморачиваться, и удалить строки из следующих языков (модула-2, оберон) - решил, что хватит array of char

>Ты себе представляешь процесс добавления поддержки новой архитектуры в компилятор? Так и представил, я, тогда вчерашний школьник, сижу добавляю поддержку несуществующей в те годы архитектуры =))) Появляется AVR32, говорят - вот вам gcc и g++ для него, а ты говоришь «нет! я буду чесать против шерсти ради паскаля»...

да поняли уже все твою точку зрения) А теперь пойми и ты если бы все рассуждали как ты и уповали на уже готовые решения Линукс бы так и остался малоюзабельной осью в вакууме без драйверов, программ и фреймворков. Но ведь нашлись чудаки чешушие против шерсти и написавшие и драйверы, и программы, и фреймворки? Так же и с Паскалем..

Вброс

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

Как видим, делфи в сааааамом низу рейтингов, а сами дельфисты в большинстве своем (по крайней мере, украинские опрошенные) страстно желают валить на жавы и шарпы =)

>я скажу наоборот, в паскале есть стока разных строк, что с ума сойти, есть shortstring, есть ansistring, который сейчас по умолчанию, кажись,

не верно - в Делфи string это WideString сейчас, а в FPC это UTF8 по умолчанию.

при присваивании этой строки другой на самом деле копируется указатель на нее, а не она вся,

нет такой фигни сейчас со строками в Паскале..

>оно в общем-то и логично, ради цельности такого интерфейса.

Да, очень «логично». То-то в любой уважающей себя библиотеке масса оберток интерфейсов. С точки зрения стирания типов все логично: мы стерли до типа интерфейса и «забыли» какой тип у объекта.

С точки зрения удобства - крайне нелогично. Намного удобнее работать с неизвестным типом A with Interface. И хотя A - неизвестный, он _всегда_ конкретен. Он не связан напрямую с интерфейсом, но компилятору дается подсказка о том, что некоторые методы с такой-то сигнатурой _могут_ быть реализованы.

Конечно, стирание крайне полезно. Но именно тогда, когда нам _нужно_ стереть информацию о типе. Увы языки типа Явы и C# вынуждают использовать его даже там, где это не нужно.

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

> Зачем учить школьников языкам программирования?

Поставис вопрос шире. Зачем учить школьников вообще чему-то?

а ещё если учесть что Делфи и Паскаль по-сути одно и тоже то позиция Паскаля в предложенной таблице поднимаеться вверх и обгоняет Perl, Ruby и JavaScript))

>это был просто компилятор pascal под лицензией GPL.

Не «просто компилятор». Он разрабатывался как часть GCC, но в основное дерево разработки GCC так и не попал

> вот вам gcc и g++ для него

Это уже два разных компилятора? :-)

Аналогично, так же можно сделать PROCEDURE (A: ARRAY OF INTEGER) totalSum(): INTEGER; — то есть, расширять базовые типы (INTEGER, STRING, массивы).

не, наврал. Базовые типы нельзя расширять, только «указательные», то есть, классы: методы классов

Методы не принадлежат классам.

Это и так и не так: можно писать методы в классах, и тогда реализации автоматически наследуются в потомках, можно писать ad-hoc полиморфизм, когда классы расширяются интерфейсами, то есть, в таком виде:

MODULE blah;

 IMPORT StdLog;
 
TYPE Pclass1* = POINTER TO class1;
	class1=EXTENSIBLE RECORD 
  	foo* : INTEGER;
	END;
	Pclass2* = POINTER TO class2;
	class2=RECORD 
    ch*: CHAR;
  	END;
   Pclass3* = POINTER TO class3;
   class3=RECORD (class1)
     r*:REAL;
   END;
  AR = ARRAY OF INTEGER;

 PINT= POINTER TO INTEGER;  (*error*)

VAR o1: Pclass1;
		 o2: Pclass2;
       o3: ARRAY 3 OF INTEGER;
  	  I: INTEGER;


PROCEDURE (t: Pclass1) totalSum*(): INTEGER , NEW, EXTENSIBLE;
BEGIN
  RETURN 1;
END totalSum;

PROCEDURE (t: Pclass2) totalSum*(): INTEGER, NEW, EXTENSIBLE ;
BEGIN
  RETURN 2;
END totalSum;
PROCEDURE (t: PINT) totalSum*(): INTEGER, NEW, EXTENSIBLE; (*error*)
BEGIN
  RETURN 3;
END totalSum;
PROCEDURE (t: INTEGER) totalSum*(): INTEGER, NEW, EXTENSIBLE; (*error*)
BEGIN
  RETURN 4;
END totalSum;

 PROCEDURE Test* ();

BEGIN
   NEW(o1);
  I:=o1.totalSum();

   StdLog.Int(o1.totalSum());
   StdLog.Ln;

   NEW(o2);
  I:=o2.totalSum();

   StdLog.Int(o2.totalSum());
   StdLog.Ln;

   StdLog.Int(1.totalSum()); (*error*)
   StdLog.Ln;

END Test;
   
END blah. 

 blah.Test();

В Component Pascal нельзя расширять базовые классы вроде INTEGER, а в Go — можно, потому что интерфейсы не привязаны к типам. o2 и o1 — это такой «ad-hoc полиморфизм», вроде утиной типизации для «интерфейса» totalSum.

Опрос релевантен только для Украины. Например, утверждается, что «Cobol наконец-то умер» при том, что его на Украине и не было никогда. Ну кому там мог Cobol понадобиться?