При сравнении хелловорлдов Паскаль не заборол разве что ассемблер

И во всяком случае это был бы более содержательный спор чем сравнение хелловорлдов по скорости и количеству сисколлов.

Мое мнение – изучать программирование имеет смысл в том же порядке как оно развивалось. Даже если примитивную процедурщину сейчас никто не использует (что вообще говоря неправда), мне кажется именно паскаль даст хорошее представление о базовых алгоритмах и структурах. При этом не грузя человека всякой низкоуровневой фигней типа адресной арифметики и ручного управления памятью. Это уже можно будет освоить потом, если понадобится.

Делфи 7 Энтерпрайз же, ну.

Turbo Pascal, который использовал виртуальную машину

Эм… Нет.

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

В этих системах «реального времени» оператор следил за параметрами через морду и нажимал на кнопки для реакции системы? Тогда это не реальное время.

Нет, следил ПЛК. А морда просто что-то показывала ему.

Видимо я попутал с UCSD Pascal.

Такие морды можно хоть на питоне написать.

Python - это вообще интерпретируемый язык программирования, а не компилируемый. Поэтому и жрёт больше ресурсов.

Вот тебе правильная версия на С:

Для HelloWorld Assembler лучший язык (комментарий)

Так я к тому, что упомянутые морды - не аргумент, даже на тормозном питоне будут работать.

Так и запишем: паскаль – язык для хэлловорлдов.

Для всяческих МК ещё есть mikroPascal © для микрохэлловорлдов :)

Так вот почему в p-code используется буква P! Это из-за Паскаля, получается?

Я всегда думал что да, но не уверен что именно поэтому.

Почему Go быстрее C++?

Там наверное iostream, который всегда был тугим.

Так вот почему в p-code используется буква P!

На самом деле в оригинале это был portable-code.

Лучше скажи, где он применяется, кроме хллоувордов?

Где угодно. Это такой же универсальный язык программирования как и C/C++ и Go.

Например?

Про свободные CudaText, Double Commander, PeaZip, eMKatic,... и т.д. я всё время упоминаю, но наиболее популярен последнее время такой диалект Паскаля как Delphi. Вот на нём написаны вагон и тележка: https://jonlennartaasenden.wordpress.com/2014/11/06/famous-software-made-with... .

Сделал то же самое (fpc -O3 hello.pas), получил бинарник в 178K. Даже не хочу знать, что оно туда положило.
Явно не уровень «Паскаль не заборол разве что ассемблер».

Во-первых, для того, чтобы отделить отладочную информацию, нужно использовать опции "-XX -Xg -Xs". Тогда будет так:

32K     pashw
64K     pashw.dbg

стандартные библиотеки Паскаля весят больше, но и умеют больше

Не вижу ни одного uses.

но и умеют больше

К слову, у Go бинарники получаются меньше.

Всё равно происходит линковка для поддержки минимального функционала.

В Go аналогично, только там базовый функционал на порядки жирнее (да и ввод-вывод в базовый функционал не входит).

$ du -h gohw
2,0M    gohw

$ du -h gohw
1,4M    gohw

$ cat gohw.go
package main

import "fmt"

func main() {
    fmt.Println("Hello, World!")
}

К слову, у Go бинарники получаются меньше.

Как раз таки больше, причём на порядки.

Это только компилятор Go из состава GCC умеет динамически линковать. А стандартный golang линкует статически на многие мегабайты.

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

Да. И если сравнивать статически слинкованные бинарники Паскаля и Go, то первые гораздо худее.

Я хотел дописать там выше, что я начал сравнивать Паскаль с Си, но было уже поздно править.

да и ввод-вывод в базовый функционал не входит

Мдя? Таки это базовый набор.

package main

func main() {
	println("hello")
}

https://play.golang.org/p/vwYxg-fMM28

Гм. Значит, ввод-вывод в Go разделили на разные наборы.

Не, просто одно абсолютно минимальное для внутренних нужд aka что то впроде puts. fmt пакет же даёт полный набор printf.

Но всё равно, если мы уже сравниваем минимальные hello word’ы, то будь те уж пожалуйста как минимум в теме того, что вы сравниваете.

Разрешение в виде обёртки для актуальных версий данных библиотек.

OK. Переделал тест. Go улучшил свои позиции:

$ cat results_by_taskclock.txt
,10   Assembly Language: syscalls:     2 taskclock:     0,10 instructions:            9
,17              Pascal: syscalls:    12 taskclock:     0,17 instructions:            4
,40         C - syscall: syscalls:    24 taskclock:     0,40 instructions:          109
,45           C - stdio: syscalls:    27 taskclock:     0,45 instructions:          180
,61       /usr/bin/echo: syscalls:    33 taskclock:     0,61 instructions:          219
,98                 PHP: syscalls:    73 taskclock:     0,98 instructions:          458
,09                Rust: syscalls:    91 taskclock:     1,09 instructions:          523
,20                  Go: syscalls:   174 taskclock:     1,20 instructions:          309
,59                Perl: syscalls:   307 taskclock:     1,59 instructions:            2
,63                 C++: syscalls:    59 taskclock:     1,63 instructions:            2
,82                Bash: syscalls:   178 taskclock:     1,82 instructions:            1
,46                 TCL: syscalls:   215 taskclock:     5,46 instructions:            6
,25              Python: syscalls:   789 taskclock:    13,25 instructions:           39
,83                Ruby: syscalls:  1128 taskclock:    37,83 instructions:          158
,44              NodeJS: syscalls:  1292 taskclock:    77,44 instructions:          251
,14                Java: syscalls:  3758 taskclock:    80,14 instructions:          195

А что это за число в начале и так мало instructions?

И, что странно, почему нет Makefile с использованными параметрами сборки в part1.tar.gz?..

Кстати, на opennet из интересного добавили ещё OCaml, Lua.

Это, по ходу, так выполнилась в цикле строчка

printf "%08.2f% 20s: syscalls: % 5d taskclock: % 8.2f instructions: % 12d\n" ${taskclock} "${language}" ${syscalls} ${taskclock} ${instructions} >>results_by_taskclock.txt

В той же строчке про Паскаль должно было быть так:

syscalls=12
instructions=4 945

Хорошо, что Delphi мертвее, чем сам Pascal.

Получается, что паскаль не годится даже для хэллоуволдов, чёрт, да для чего ж его использовать…

Ага, что аж выкатили новую версию в ноябре: https://www.embarcadero.com/products/rad-studio/whats-new-in-10-3-rio

laba1.pas, как сейчас помню

Получается, что паскаль не годится даже для хэллоуволдов

Это ещё по какой логике? Он же как раз заборол все остальные языки помимо ассемблера.

помимо ассемблера.

this. Очевидно, что для написания hello world нужен ассемблер.

Хелловорлды можно писать даже на Яве и NodeJS. Это тяжёлый софт работающий с большими массивами данных на тяжёлых и медленных языках сожрёт все ресурсы и уйдёт в своп.

Отличный тест! Значит в следующий раз когда я захочу написать «хелловорлд» - воспользуюсь Pascal.

Всколыхнулось че-то в душе. Ностальжи...

Блин, есть тут идея одной нужной мне утилитки, на лазарусе ее чтоль собрать?

И часто ты этого хочешь?

Безусловно нет.

А почему?

$ [s]dumpbin.exe[/s] objdump $QT_LIBNAME.so > /dev/mosk

????

$ cat /dev/mosk | /dev/hands > $QT_LIBNAME.pas :)

cat $QT_LIBNAME.pas

unit <$QT_LIBNAME>;

interface

procedure qtSomething1(const paramSomething:string); stdcall; external name ‘qtSomething1’;

…

procedure qtSomethingN(const paramSomething:string); stdcall; external name ‘qtSomethingN’;

implementation

end.

PROFIT!!!

А если ты даже в паскальные заголовки для cpp либ не умеешь, то… зачем тебе разрешение? :)

Вообще-то… уже опять умеет с «Tokio» начиная :) Просто… кросскомпиляцией.

«Что нового в RAD Studio 10.2 RAD Studio 10.2 включает первый Linux-компилятор для RAD Studio» (с)

Дельфи гибнет как никогда раньше :) Idera не даст соврать :)

Под «cpp» ты, видимо, имеешь в виду C, а Qt перепутал с WinAPI.
Вот с GTK можно так сделать, и примерно так и делают: Lazarus CCR: GTK 3 (но не руками, а через генератор из интроспекции GObject).

А libQt5Pas – это C++-библиотека с миллионом обёрток в простые (не перегруженные) функции.