Рецензия на книги А. В. Столярова

Учитывая все тенденции, я не исключаю, что в какой-то момент может появиться обязательный режим со статической типизацией, например, или вообще какой-нибудь Python-4. С параллельностью в последнее время всё становится лучше, от GIL постепенно избавляются.

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

Я это воспринимаю как «первородный бульон» с идеями, которые в отрыве от именно конкретной реализации были особо никому не нужны.

дык питон для нубов середины 0ых не снеба упал - он проиграл php в индустрии но сохранился в ресёче среди phd публики и продолжал тюнится

то что втут он до очередного хайпа -АИ был в backend-почти-онли - ну вот такое большое человечество

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

Если бы было понятно, как это сделать, это сделали бы давно, даже я бы попробовал сделать.

Но языки развиваются, каждый живой язык смотрит на другие, как на полигон идей. Посмотрим.

Это всё копиум.

Ты не понимаешь о чем пишешь. Ещё раз — там другая библиотека компонентов. А Delphi это, в первую очередь, компоненты.

Иди погрепай по гитхабу да посмотри, сколько ты найдешь новых проектов.

Это не показатель.

ООП это контроль за типами данных, основная суть ООП

Картинка

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

Это объяснение от Sendi Metz идеи Alan Kay.

I’m sorry that I long ago coined the term «objects» for this topic because it gets many people to focus on the lesser idea. The big idea is «messaging».

(с) Alan Kay

1,2,3

он проиграл php в индустрии

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

да блин питон пухнет по очевидным социологическим причинам

в части скриптоты ( если игнорировать просто неудачные некоторые решения) первые питоны ближе к скриптоИдеалу чем текущие

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

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

не сказать что «умысел» но в социумах роль личностей(героев и нет) высока

то что Гвидо из Бенилюкса не помешало

Это не суть, это хрень какая-то. Суть должна отражать правило, которое делает эту концепцию уникальной, давать отличительную черту.

Есть три основные «концепции», которые позволяют делать код более безопасным:

1. структурное программирование – это, по сути, запрет на goto (исключения тоже выбиваются из этой концепции)

2. функциональное программирование – это запрет на изменение значений переменных (формально их вообще нет)

3. объектно-ориентированное программирование – это запрет на произвольную интерпретацию данных (нельзя передавать сырой указатель на переменную)

Каждая из этих концепций отнимает свободу при написании кода, но делает код более предсказуемым и более удобным для анализа. ЕМНИП, Роберт Мартин примерно так же сформулировал это все.

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

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

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

qulinxao3, респект. Сейчас, я нашел источник цитаты.

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

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

https://news.ycombinator.com/item?id=2452126

 What they did have was an obsessive focus on the user, and on getting things done so they could move on to get other things done. Navel-gazing about what language was best or whether we should be using OOP or how stupid the previous engineers were was generally reserved for the B-players.

Это не суть, это хрень какая-то.

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

Ты не понимаешь о чем пишешь.

Нет, это по твоей части, клоун. Еще раз: человеческий ресурс и накопленный опыт.

Это не показатель.

Действительно, количество существующих и новых проектов - не показатель.

Показатель - слова анонимного столяровского шизика с лора.

Нет, это по твоей части, клоун. Еще раз: человеческий ресурс и накопленный опыт.

Ну т.е. Си это мёртвый язык?

Действительно, количество существующих и новых проектов - не показатель.

То есть мысль о том, что не все проекты выкладываются в публичный доступ тебе не доступна? Ну и кто тут шизик? :)

Даже не обсуждая написанное по существу…

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

и

объектно-ориентированное программирование – это запрет на произвольную интерпретацию данных (нельзя передавать сырой указатель на переменную)

нет ли тут противоречия?

нет ли тут противоречия?

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

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

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

Например Си. В нём невозможно ООП?

Ну т.е. Си это мёртвый язык?

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

мысль о том, что не все проекты выкладываются в публичный доступ тебе не доступна?

И тут мы возвращаемся к вопросу о том, кто этим занимается: компании, у которых есть человеческий ресурс и накопленный опыт.

На коммерческих лиспах тоже есть банковский софт. Это не делает конкретный диалект более живым.

Ну и кто тут шизик?

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

Речь шла о чистой концепции. Реализация от нее всегда отличается.

объектно-ориентированное программирование – это запрет на произвольную интерпретацию данных (нельзя передавать сырой указатель на переменную)

Что за глупости вы пишите? Передача указателя на переменную — это основа функционирования полностью ООП языка Ruby. Когда вы одному объекту передаете другой объект, не копируя его в память, а давая на него ссылку.

УКАЗАТЕЛЬ — это ССЫЛКА.

Честно, вы что ни напишите, это какая-то лютая дичь. То вы путали устройство ЭВМ и устройство процессора, заявляя, что ассемблер — это высокоуровневый язык. Теперь вы рассказываете про указатели в ООП, вообще не понимая, о чем пишете.

Например Си. В нём невозможно ООП?

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

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

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

Обычно различают понятия «указатель» и «ссылка».

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

Со ссылками ничего подобного делать нельзя, они неразрывно связаны с объектом, на который указывают.

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

Идите книги прочитайте POODR от Sandi Metz - там про ООП, главу про указатели у Jon Bodner в Learning Go: An Idiomatic Approach to Real World Go Programming.

Ваши сентенции вызывают бурю эмоций. Мягко говоря. На столько у вас не высокая квалификация, но высокий апломб. Тогда вы хоть в OOП и указателях будете разбираться.

Обычно различают понятия «указатель» и «ссылка».

Это синонимы.

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

То о чем вы говорите называется «арифметика указателей», и она не обязательно должна присутсвовать в языке программирования. Указатели могут быть, а арифметики указателей не быть, как в Go.

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

Идите книги почитайте. У вас низкая квалификация.

Обычно различают понятия «указатель» и «ссылка».

Это синонимы.

Нет.

Он вообще-то прав. У указателей в Go отломали всю арифметику, так что это скорее ссылки, только с более явным синтаксисом. Чтобы вчерашние студенты не выстрелили в ногу.

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

Обычно различают понятия «указатель» и «ссылка».

Это синонимы.

Нет.

Для первокурсника, конечно, нет. Но для специалиста это синонимы: передача адреса объекта в функцию вместо копирования объекта называется «copy by reference». Передадача копии называется «copy by value».

Точно так же, как функция, метод и процедура — синонимы.

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

Потому что…

компании, у которых есть человеческий ресурс и накопленный опыт.

На коммерческих лиспах тоже есть банковский софт. Это не делает конкретный диалект более живым.

Конечно делает, так как пишется новый софт.

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

Ты не только скромный, но ещё и великодушный! :)

Речь шла о чистой концепции. Реализация от нее всегда отличается.

Разве?

объектно-ориентированное программирование – это запрет на произвольную интерпретацию данных (нельзя передавать сырой указатель на переменную)

Он вообще-то прав.

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

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

Конечно делает, так как пишется новый софт.

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

Ты не только скромный, но ещё и великодушный! :)

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

Разве?

Да. В плюсах ты можешь передать void*.

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

Согласен.

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

А вот это утверждение делает невозможным реализацию ООП на языке Си.

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

Еще раз: указатель указывает на область памяти и можно менять точку, куда он указывает, а ссылка неразрывно связана с объектом, да, она обычно тоже указывает на область в памяти, где лежит объект, но ты ее менять не можешь, поэтому она гарантирует то, что там есть объект, и то, что он именно нужного типа. Указатель ничего этого не гарантирует.

А вот это утверждение делает невозможным реализацию ООП на языке Си.

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

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

Да. В плюсах ты можешь передать void*.

Могу. Поэтому в С++ нет ООП?

указатели обычно raw адрес в памяти - и в отсутсвии mmu в языке - полный доступ к области

ссылка - это может быть и хэндл в некоей таблице которую менеджит рантайм языка и интерфейс не такой неограниченый(возможно) чем raw указатель

тут ещё лексика-жаргоны разных языков программирования и переводчики не факт что хотя-бы кандидаты наук

в Си смысле указатели есть только в языках которые могут прямо взаимодействовать с железом

Могу. Поэтому в С++ нет ООП?

Еще раз:

Это именно то, о чем я говорил: реализация расходится с теорией. Как бы ООП сделать можно, но вместе с ним есть и пляски вокруг указателей. Формально Си - императивный, но с прикрученным ООП переходит в разряд мультипарадигменных. Собственно, плюсы относятся туда же.

При чем тут формат передачи?

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

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

Хоть 25 раз. В моем сообщении написано, что «указатель» и «ссылка» это синонимы того, же порядка что «функция» и «метод».

Вы продолжаете вести бесконечный спор, уже вопросы ООП забыты, перешли на оспаривание разницы между «указателем» и «ссылкой».

ссылка это скорее хэндл

а указатель буквально адрес - указатель в этом смысле уже разименован

кста поэтому паскаль (либо асм) полезен перед С++ ( да и перед С)

хэндл это индекс некоей таблицы ( да даже прерываний таблицы)

а указатель это адрес (даже если по факту мы в защищёном режиме и его неизвестное число раз отранслирует железо )

у них пересечение но это разные понятия

указатели обычно raw адрес в памяти - и в отсутсвии mmu в языке - полный доступ к области

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

Объяснение указателей через ссылки было дано, чтобы показать абсурдность определения ООП, данного soomrack.

soomrack — это пользователь, вызывающий у меня своими сентенциями бурю эмоций. То он Ассемблер в высокоуровневые языки определит, то ООП опишет как запрет на использование указателей, что является откровенной чушью, вроде «слышал звон, да не знаю, где он».

Здесь же идут рассуждения об «общих принципах» и

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

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

У тебя в голове вообще ничего не щелкает при фразе «реализация отличается от теории», нет?

Тут вот ведь что получается, данное определение просто запрещает существование ООП в языках типа Си, а оно вообщем-то есть.

Наоборот может быть, то есть теоретически возможно, а практически недостижимо — полно примеров.

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

В общем тут одно из двух либо теория не правильная либо природа не такая.

Либо теория не высечена в камне, потому что не является законом природы.

просто допустим:

чел курил Си - в Си указатель это типизированый(или нет) адрес

чел затем покурил С++ где святой Бъёрн обсемантил &ident в профиле функции|метода как var Симулы от которого(in_out и прочие сочетания Ады который в нонешних С++ добуккипились до const на мутабелное с const - ибо во всём нужна точность) в Сях ибо низы железа отказались в пользу ручного труда

в интерпретирующих (а какие ща не :) ) языках нет почвы различать указатели и ссылки ибо редко какой интерпретатор позволяет без последсвий(крахом например) делать открытые операции на сердце - модифицировать потроха обьектов на прямую

т.е id в питоне это адрес но не указатель :)

у них пересечение но это разные понятия

Есть 4 распространенных языка: С, С++, PHP, Go. В них ссылки и указатели практически синонимы.

• Указатели с арифметикой: C, C++
• Указатели без арифметики: Go
• Ссылки как часть синтаксиса: PHP

Везде выполняется одна задача: передаем ссылку на данные в функцию, и при изменении данных они меняются как у вызывающей стороны, так и у вызываемой.

В Ruby и JS тоже есть ссылки, но они — внутренняя механика языка, работающая при передаче объектов в функцию.

Что тут за спор о том, что «ссылка» и «указатель» — это не синонимы? Посмотрите PHP.

если Разработчик фонат власяницы то вполне у него ООП и в сях случится - про это даже книжки есть

разные тезаурусы

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