Сколько зарабатывает Pascal программист?

На питоне ооп более внятное чем на плюсах вообще то.

?! Тупо nested структура без ограничений по видимости, да даже замыкания в перле и JS (прости господи!) лучше, менее удобные, но как организация кода на парадигме ООП – лучше.

Области видимости это баловство. А вот понятия объекта и экземпляра класса улучшают понимание плюсового ооп в тч.

Я не считаю, что существует какой-то единственно правильный путь. Стартовать можно с чего угодно, а потом выбрать специализацию или сменить парадигму.

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

нужна строгая типизация

внезапно питон строго типизированный яп, а вот с/с++ нет

указатели

обычные указатели как раз таки приводят к появлению ненадежного кода.

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

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

Да, единственно правильного пути нет. Просто я вот преподавал программирование и алгоритмы математикам и робототехникам, и могу сказать, что те, кто начинал с питона имели кучу сложностей, т.к. у них не сформировалось никакое понимание, чего там под капотом…

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

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

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

ограничение области видимости, это один из основных столпов ООП

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

Понятие объекта и экземпляра класса в Питоне очень мутно.

Совершенно прозрачно.

А передача по ссылке или по значению, это же жуть в питоне!

В питоне все всегда передаётся по ссылке.

Никто не говорит что питон идеальный яп, да там много косяков. Но для обучения он хорош, и в своей нише (маленькие приложения, быстрое прототипирование и тд) он вне конкуренции.

Аннотирование функций - там кстати офигенный встроенный хелп, именно просмотр аннотаций он и предоставляет:-)

внезапно питон строго типизированный яп, а вот с/с++ нет

Да ты верно шутишь, или мы по-разному понимаем строгую типизацию. То, что переменная может менять свой тип в процессе исполнения кода это кошмар и ужас. В С/C++ с типами есть много вольностей, тут не спорю, иногда они очень неудобны, а иногда это хорошая возможность для оптимизации на уровне компилятора… Хочется совсем строгой типизации, по военному, то тогда бери Ada.

У питона даже стандарта нет. Это, кстати, означает, что писать код нужно под конкретный компилятор и не менять его в течении всей жизни продукта.

Никаких шуток, я просто констатирую факты «Python (МФА: [ˈpʌɪθ(ə)n]; в русском языке встречаются названия пито́н[23] или па́йтон[24]) — высокоуровневый язык программирования общего назначения с динамической строгой типизацией»(с) вики например.

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

Ну вики для меня не аргумент. Я сам туда могу всякое написать (и писал, правда старался писать разумное).

Формально понятия «строгая типизация» нету, есть понятие «сильная типизация». Проблема в том, что ее определение не рассматривает ситуацию, когда переменная меняет тип в процессе исполнения программы. С моей т.з. это очень плохо, это может привести к ошибкам и сильно затрудняет анализ кода. В моем «идеальном языке» этого быть не должно.

Впрочем, если говорить исходя из определения «сильная типизация», то да, питон сильно типизированный язык.

В питоне все всегда передаётся по ссылке.

Кроме базовых типов, они копируются

Аннотирование функций - там кстати офигенный встроенный хелп, именно просмотр аннотаций он и предоставляет:-)

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

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

В C++ это сломать сложнее, чем в питоне, и не с каждой опцией компилятора это возможно (как и переменный с модификатором const). Но это очень важный элемент, который должен быть. ООП это в первую очередь ограничение по приведению типов, так же как и функциональное программирование это в первую очередь ограничение по модификации переменных (запрещено!). Все базовые концепции, по своей сути, это ограничения возможностей программиста, чтобы его код был более предсказуемым, и соотв. более понятным. Вспомни статью Дейкстры про процедурное программирование – это отказ от goto, чтобы не было перехлестывающих циклов… В питоне ограничение видимости это соглашения, а в С++ это правила при компиляции…

PS: пойми меня правильно, мне нравится питон, я не считаю его плохим языком, и я его использую довольно часто. На мой взгляд из скриптовых языков он лучший, я на него перешел с perl, который мне очень нравился, и фич которого мне очень не хватает в питоне, да и в других языках, у перла есть эндемичные фичи… Но чем больше знаешь язык (любой), тем больше начинаешь его ненавидеть.

Нисколько, гыыывв

Расскажите вот этому перцу что строгой типизации не бывает

Кауфман В. Ш. 4.2.3. Строгая типизация и уникальность типа // Языки программирования. Концепции и принципы. — ДМК Пресс, 2011. — С. 93. — 464 с. — (Классика программирования). — 1000 экз. — ISBN 978-5-94074-622-5.

Я плюсы ненавижу куда сильнее чем питон, да:-) Хотя у питона для этого объективно поводов побольше…

Но тем не менее, мы говорили про обучение. И питон ОЧЕНЬ хороший яп для обучения, я тоже программировать учу, правда не школьников:-)

Основная беда питона - его пихают не туда. А насчёт базы - конечно лучше если сючеловек знает скока байт во флоте и что такое вообще байт. Но для всяких дата сцайнтистов это знание лишнее:-)

Кроме базовых типов, они копируются

Нет. Все всегда передаётся по ссылке. Просто неизменяемые объекты при изменении по ссылке замещаются новыми, а изменяем изменяются. Функция id в помощь.

Список кстати тоже базовый тип, и он изменяется.

Пожалуйста, будьте аккуратнее с терминологией.

Так, стоп. Ты передаешь целое число и оно передается как копия.

#!/usr/bin/python


def print_var(var: int):
    var = var + 1
    print(var)


def main():
    var = 0
    print_var(var)
    print(var)



if "__name__" == "__name__":
    main()

1
0

PS: список это уже сложный тип (но базовый, его предоставляет python), и он передается по ссылке. Тут вот нехватает стандарта с его четко зафиксированной терминологией (поэтому с ней невозможно быть «аккуратным»).

Кауфман В. Ш. 4.2.3. Строгая типизация и уникальность типа

Проблемы перевода. Правильно было бы перевести «сильная типизация»…

Впрочем это уже софистика… Я ведь сказал, что я согласен, что питон имеет сильную типизацию, но мне не нравится, что тип переменных не определен «навсегда», что их можно менять по ходу кода…

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

Основная беда питона - его пихают не туда. А насчёт базы - конечно лучше если сючеловек знает скока байт во флоте и что такое вообще байт. Но для всяких дата сцайнтистов это знание лишнее:-)

о чем и речь.

Вроде как нет, примитивы тоже передаются по ссылке, там штука в mutability. Строка или tuple например ни разу не примитивы, но они immutable, потому при изменении ссылка меняется

а браузер – на си

Хромиум? На крестах вроде как, не на чистой сишке

в контексте противопоставления питону, плюсы – тоже си :)

Все, на чем стоит айти – написано а си

Примеры будут? Помимо очевидного ведра линуха.

Не только линукс – все ОСи. ДНС серверы, веб серверы, компиляторы, браузеры – вообще вся основа, все основное. Неужели не очевидно?

( понятно, есть примеры написанного не на си, но это – исключения в общей массе )

Но чем больше знаешь язык (любой), тем больше начинаешь его ненавидеть.

Ты что-то делаешь неправильно :)

Летаю, когда надо, а куда деваться? Про всё подряд думать – крыша поедет

А конструкторы самолетов не летают, бг-г-г. Ну тут ты прав по поводу «про всё подряд думать».

При последнем проходе пузырька изменился кусок массива, который уже пройден. В результате функция сортировки завершается, а массив неотсортирован

Есть куча разных вариантов барьеров записи. По-твоему, как реализованы параллельные сборщики мусора? Да вот так же. И да, они пересчитывают ссылки, если после последнего просчета они были изменены.

Я тоже. Блокировать на запись надо весь сортируемый диапазон. Теоретически, конечно, можно делать прямую сортировку и блокировать только отсортированную часть. Но тогда сама сортировка медленней

Блин, ну mergesort by-design реализуем с параллельными читателями — просто потому, что конечный результат пишется в новую область памяти.

А что они значат, рассказывай?

Каст B в тип int * A.

Объявление функции A с аргументом типа B и возвращающей ссылку на int.

Объявление типа B, который является ссылкой на функцию int *A().

Это многокритериальная оптимизация, но главным, доминирующим критерием является стоимость создания продукта. Соотв. эта стоимость и определяет ниши: для веба это JS, для железа это C, для проектов со сложной логикой и математикой это С++, для простой автоматизации рутины это Python, есть свои ниши и у Java, и у Lua, и у Ada, и у многих других

«Лишь были б желуди: ведь я от них жирею». «Сэкономив» в коротком сроке, разрабы по отдельности уже сотни и тысячи раз переплатили за эту экономию долгосрочными издержками на сложностях доработки, поддержки, неэффективности использования железа, и так далее. Например, если бы в питон изначально была заложена возможность оптимизации, то тот же TensorFlow скукожился бы в разы, потому что кучу функций больше не пришлось реализовывать заново ad-hoc с целью оптимизации.

А так то задним умом все сильны

При чем тут задний и передний ум к языку, синтаксический разбор которого оказался в принципе невозможен без семантического (угадай название ЯП)? Кто-то в 80-х годах рискнул бы сказать, что это хорошая идея? Нет, потому что в крупных корпорациях технические вопросы при принятии решений, как правило, не учитываются. Или была какая-то особо острая потребность написать в камне JS за десять дней и больше не дорабатывать его?

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

Список недостатков сможешь написать?

Да, могу — классы. Одного этого, думаю, хватит. К сожалению, я потерял цитату от одного из приближенных к разработке жавы, где тот признавался, что классы были величайшей ошибкой при разработке языка.

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

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

Есть отдельно сильная/слабая типизация — это про типы значений. И отдельно статическая/динамическая типизация — это про типы переменных.

Неявные преобразования типов в Си++ тоже затрудняют анализ кода.

Хочешь точно анализировать код — есть Ада, Haskell, Idris, …

#!/usr/bin/python
def print_var(var):
    var = var + [1]
    print(var)

def main():
    var = [0]
    print_var(var)
    print(var)

if "__name__" == "__name__":
    main()

[0, 1]
[0]

В чём разница? В обоих примерах ты не меняешь переданный по ссылке объект.

есть Ада, Haskell, Idris, …

Забыли про Modula-3.

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

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

Все всегда передаётся по ссылке.

Строго говоря, не по ссылке, а по соиспользованию (call by sharing). При передаче по ссылке

def f(x):
  x = 1

y = 5
f(y)
print y

вернуло бы 1. Как происходит, например в С++, если тип аргумента заканчивается на «&».

С++ 2022 года очень сильно отличается от С++ 1990 года

Это да.

на С++ в 2022 году можно писать гораздо более понятный, чистый, ясный, безопасный код, чем на С++ в 1990 году

А вот это нет😆

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

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

То, что переменная может менять свой тип в процессе исполнения кода это кошмар и ужас.

В Питоне она явно должна менять тип, а в Си со сродниками горы неявных приведений, но это другое.

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

Я ещё много страниц назад писал, что одним языком никак не обойдёшься, универсальных языков не бывает. Вот для азов как раз хорош Питон, если человек вообще первый раз редактор кода открывает. Через полгода, а это считанное количество уроков в усреднённых реалиях, даже на основы ООП не хватит, можно Си давать, опять же, без фанатизма, чтобы было понятно, что там под капотом. Желательно даже по минимуму углубляться в тонкости Си, а вместо этого рассказать в общих чертах про устройство компьютера, память, стек, аллокации, вот это всё. Если обучающиеся это поймут в заданные сроки, это уже хорошо, уже не зря информатику преподавали. Обычно там тупо училка смывается, а дети в контру гоняют.

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

Кресты, го, недораст, жаба - ок

Не ОК. Кроме Pascal вообще затрудняюсь что-то подходящее назвать для роли первого ЯП.

BASIC?

Паскаль это не лучший выбор из возможных. Тут спору нет, имхо, его надо заменять на С в физмат классах и на Питон в остальных местах, как можно скорее. soomrack ★★★ (17.12.22 05:49:01 IRKT)

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

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

Но для обучения он хорош

Нет, для обучения он плох.

BASIC?

Те же недостатки что у Python, только ещё и устаревший. Для обучения программированию непригоден и писать на нём имело смысл только для восьмибитных ретрокомпьютеров, где ничего другого просто не было. А на 16+ битных машинах basic уже не нужен.

Нет, для обучения он плох.

Нет, хорош.

. На мой взгляд из скриптовых языков он лучший

А вот это вряд ли. Вы так думаете, наверное, только потому, что Tcl не использовали.

Слушай, ну вот пример, 20 назад был javascript и basic в браузерах. Basic продвигал майкрософ, который тогда занимал очень большую нишу со своим IE. Basic был гораздо более аккрутано спроектирован, чем JS. Но на JS писали много, а на Basic – нет. Инструмент должен соответствовать уровню пользователей, очень мало людей будет пользоваться тем, что неудобно, чему нужно учиться, в то время, когда им нужно вот здесь и сейчас.

Было много языков, но потребители выбрали это. Если бы питон спроектировали как ты хочешь, то скорее всего потребители выбрали бы другой язык. Со временем потребители становятся умнее и язык тоже начинает развиваться…

Неоднократно натыкался на мнение, что именно для введения в программирование - он (был) идеален. Он давал ощущения контроля над железом «на кончиках пальцев». Ты включал комп, набирал команду - и она мгновенно работала! А теперь? Включи, загрузи ОС, запусти IDE, набери код, скомпилируй, запусти, дождись - лично мне уже скучно стало, а мне не 7-8-10 лет, а как бы прилично за 40.
Про то, насколько за это время выросло время отклика системы на действия пользователя - уже написано и измеряно достаточно, повторяться не буду.
Некоторые отцы специально покупают винтажные 8-битные компы для того чтобы показать детям всю прелесть той эпохи, когда комп после покупки был только твой, а не принадлежал корпорациям, следящим за каждым твоим шагом и решающим что тебе запускать, когда и как.
Считайте меня олдфагом, но никакая Raspbery PI уже не даст этого ощущения. Да, современные ОС подарили нам мощность, функциональность и безопасность, и Basic в них действительно не актуален.
Но какой ценой?

Считайте меня олдфагом, но никакая Raspbery PI уже не даст этого ощущения.

Попробуйте KolibriOS.

А вот это вряд ли. Вы так думаете, наверное, только потому, что Tcl не использовали.

Я использовал. Tcl как и Perl отлично работает пока структуры примитивные. Но как только надо работать со списком списков или чем-то подобным, начинается кошмар. В то время как на Питоне, JS или Лиспе тривиально работать со структурами любой вложенности.

Вот более наглядный пример:

#!/usr/bin/python


def print_int(var: int):
    var += 1
    print(var)


def print_list(var: list):
    var[0] = 1
    print(var)


def main():
    var = 0
    print_int(var)
    print(var)

    var = [0, 1]
    print_list(var)
    print(var)


if __name__ == "__main__":
    main()

1
0
[1, 1]
[1, 1]

Ну вот это как-то странно и нелогично с т.з. написания кода. Я, конечно, понимаю почему так происходит, но это как-то неправильно. Если выражение «var = var + 1» я еще могу представить, как создание совершенно новой переменной «var», то уж «var += 1» для меня выглядит, как работа со старой.

А поскольку тут нет указателей, то передача переменной это передача переменной, а не указателя на нее. И объяснять логику почему тут все так происходит тем, кто не знаком с указателями, как-то непросто…

Язык программирования «Электроника МК-61» чем не вариант?

В Питоне она явно должна менять тип, а в Си со сродниками горы неявных приведений, но это другое.

Что значит явно?

var = 1
var = '1'
var = [1]

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

В Си переменная получила тип при рождении и он всегда с ней, ты точно знаешь, что она именно этого типа, всегда, до самой смерти.

Неявные приведения это да, особенно когда есть UB, это плохо. Но тут уж надо пользоваться ADA, и пр. Хотя ООП как раз должно было решать эту задачу, т.е. контролировать приведение типов и в С++ на уровне объектов можно добиться хорошей строгости.

то уж «var += 1» для меня выглядит, как работа со старой.

А вот это одна из тонкостей Питона. В Си a += n и a = a + n были тождественны. В Питоне для списков += меняет объект.

А поскольку тут нет указателей, то передача переменной это передача переменной, а не указателя на нее.

Передача ссылки, хранящейся в переменной. Является ли эта ссылка указателем или копией для неизменяемых объектов с точки зрения семантики неважно.