PHP vs другие WEB-ориентированные языки программирования

@Talamaur · Регистрация: 14.12.2015

Author24 — интернет-сервис помощи студентам

Здравствуйте. Как вы считаете есть ли будущее у PHP? Даже если судить по количеству людей онлайн в ветке C#, например, и PHP, то можно сделать вывод, что PHP не пользуется большой популярностью. Да и инструментарий ASP.NET будет побогаче чем PHP? Ведь все, что делается на пых можно сделать и на asp.net. Тогда зачем нужен данный язык? В своих взглядах могу и ошибаться и вывод про популярность яп это чисто личное мнение. Конечно каждый программист будет хвалить тот яп на котором программирует, но все же хотелось услышать мнение кто профессионально работает и может сказать плюсы и минусы того же PHP. Возможно пых легче и быстрее освоить чем asp.net? Но тогда возможен ли переход с php на asp.net? Хотя это маловероятно. Переход с не строго типизированного яп на строго типизированный будет сложным. И ведь тот же MS более активно работает над развитием своего яп.

@IamLost · 19.09.2019, 10:57

Не по теме:

Сообщение от Talamaur

PHP

Сообщение от Talamaur

C#

Сообщение от Fulcrum_013

выбирать современный профессиональный язык (C++) а не эти архаичные обрубки.

Тему можно закрывать.

@Talamaur · 19.09.2019, 11:30 **[ТС]**

Сообщение от IamLost

выбирать современный профессиональный язык (C++) а не эти архаичные обрубки.

И чем же С# является "обрубком" то?

@IamLost · 19.09.2019, 11:44

Сообщение от Talamaur

И чем же С# является "обрубком" то?

Это вопрос не ко мне, это вопрос к "профессионалу-не-быдлокодеру" Fulcrum_013.

@Fulcrum_013 · 23.09.2019, 19:31

IamLost, Во всем. Автоматика полностью устарела по состоянию на конец 60-х и в принципе ничего не способна автоматизировать в ООП языке. Алгебру над сущностями определить не позволяет. Дженерики к этому не приспособлены в принципе (даже наличие оператора/метода у типа-аргумента проверить в компайлтайме не в состоянии не говоря уже о чем то большем ). Т.е. ни о какой серьезной разработке на шарпе речи идти не может в принципе. Не годен даже для создания на нем серьезного оконного фреймверка. Борланд всю эту шнягу WinForms которая в исходе называлась C# Builder даже релизить отказался. Вышел из проекта и продал ее майкрасофту, которому нужен был фреймвер на языке основанном именно на изучаемой в школах жабе для замены ворд и эксель васика, за акции которые та купила когда входила в проект.

Добавлено через 7 минут
Настолько куцым по сравнению с реализацией на дельфе, в которой автоматики нет от слова совсем, оный WinForms оказался.

Добавлено через 3 минуты
т.е. по сути жаба это Simula-67 с фигурными скобками вместо begin/end. А шарп это еще чуток досыпанного в оную симулу синтаксического сахара.

Добавлено через 19 минут
В результате даже два мировых лидера в плане средств визуальной разработки даже совместно ничего толкового на нем сделать не смогли. Точно так же эпическим фейлом закончились попытки зарелизить борландовскую Delphi.NET и майкрософтовский С++.NET. Причина - GC абсолютно не предназначен для работы в графах ссылок характерных для паттернов ООП (не в состоянии ничего посчитать мусором без сторонней помощи в виде решения задачи управления взаимосвязями) и абсолютно не предназначен для управления ресурсами. При этом даже ручное решение задачи управления взаимосвязми/ресурсами без которой GC не в состоянии обеспечить уборку, побочным эффектом имеет и решение задачи управления памятью гораздо более эффективным методом чем это делает GC, что делает GC ненужным от слова совсем. Не говоря уже про современную кастомизируемую автоматику управления жизненным циклом. При этом дефрагментация, без которой GC работать не в состоянии абсолютно бессмысленна в системе со страничной организацией виртуальной памяти и вообще склона к сваливанию к еще более бессмысленной дефрагментации свопа. При этом чем больше объем обрабатываемых данных тем сильнее дефрагментация и сканирование бьют по быстродействию. Память она чертовски дешевая за счет того что чертовски медленная. Вообще GC разрабатывался в свое время для перфолент и потом магнитных лент где дефрагментация снижала потребное время перемотки. Но для памяти с произвольным доступом и особенно с страничной организацией виртуальной памяти - это самый неэффективный способ, кроме того что абсолютно бесполезный для ООП и управления ресурсами в плане автоматики.

Добавлено через 41 минуту
Если же к этому присовокупить неумение жабы/шарпа и прочих мусоросборников осуществлять статическую композицию и размещать временные интсансы классов на аппаратном стеке при абсолютном отсутсвии средств кастомизации алгоритмов распределения эмулированного стека с произвольным порядком высвобождения/удаления (именно эта шняга у них под капотом а не какая не куча) имеем еще и абсолютную неприспособленность всего этого поголовья к мультипотоку.
О какой серьезной разработке на таких языках вообще может идти речь?

Добавлено через 5 часов 31 минуту

Сообщение от Talamaur

Тогда зачем нужен данный язык?

В свое время был очень даже грамотным решением. Суть - обработка запросов в CGI пакетная. т.е. процесс-обработчик запускается генерит страницу и после этого завершается. А соответсвенно обработчик каждой страницы - отдельный софтинка которая с соседним обработчиком обмениваться данными может только через БД/диск. Ну и все бы ничего можно консольные софтинки на том же сишечке накатать и радоваться. Только вот места на хостинге по тем временам было ну очень ограниченным. а с динамическими библиотеками под линуксоидом было хуже чем никак. соответсвенно прилинковать всю толпу либ доступа к БД и т.д. к обработчику грубо говоря каждой кнопки получалось сильно жирно. Да и хостинг весь был шареный посему возможность побусурманить нужно было ограничивать. От и сотворили один модулек к которому прилинковали все-все нужные либы и виртуальную машину позволяющую доступ к функциям этих либ одобренных всевышним на свое усмотрение. При этом для запуска скриптов выделение памяти сделали на основе регионов. И регионы отваливали немерянные. ТАк чтобы для подавляющего большинства запросов GC за время работы скрипта не разу запускать не понадобилось а можно было после отработки скрипта отправить весь регион на переиспользование одним махом и без разбору. Отак собственно пых и родился. Кстати примерно так же примерно по тем же причинам родился ASP и живет он очень подобным пыху образом, только имеет несколько языков в арсенале своей VM а не один.

Сообщение от Talamaur

но все же хотелось услышать мнение кто профессионально работает и может сказать плюсы и минусы того же PHP

В свете перехода веба к дуплексным протоколам и интерактивной обработке запросов осуществляемой демонами на выделенных/виртуальных серверах обречен на вымирание как и любой язык с GC а тем более скриптовый. По тем же причинам на вымирание обречен и ASP.
Добавлено через 30 минут

Сообщение от Talamaur

Переход с не строго типизированного яп на строго типизированный будет сложным

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

Добавлено через 3 минуты
Реально динамическая типизация вредна в 99,9% случаев. А для тех 0,1% случаев где она реально нужна, она доступна и в языках со статической типизацией через библиотечные средства.

@Curry · 23.09.2019, 20:49

Сообщение от Fulcrum_013

А вот строгая типизация это реально перебор.

Это говорит о том, что вы ещё не до конца научились мыслить в рамках статической типизации, которая должна быть строгой.
Не строгая так же ведёт к ошибкам и "бессонным ночам отладки", только в слегка меньшей степени. Нежелание привести тип явно сродни нежеланию "секономить" на описании типа свойственному скриптосочинителям.
По проблемам с отладкой, по мне лучше уж строгая с GC, чем не строгая со смартпоинтерами.

@Fulcrum_013 · 23.09.2019, 21:56

Сообщение от Curry

которая должна быть строгой

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

Добавлено через 2 минуты

Сообщение от Curry

Не строгая так же ведёт к ошибкам и "бессонным ночам отладки", только в слегка меньшей степени

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

@Curry · 23.09.2019, 22:05

Сообщение от Fulcrum_013

Все проблемы ады из за строгой типизации.

Что за проблемы?
Она громоздкая. И проблемы с кодировками. Но это не относится к типизации.
Что в неё приделали? Она по прежнему со строгой типизацией.

Сообщение от Fulcrum_013

Наверное потому что сначала алгебру над сущностями определяю а потом уже все остальное.

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

@Fulcrum_013 · 23.09.2019, 23:03

Сообщение от Curry

По проблемам с отладкой, по мне лучше уж строгая с GC, чем не строгая со смартпоинтерами

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

Добавлено через 53 секунды

Сообщение от Curry

Продемонстрируйте кодом.

та демонстрировал уже кучу раз

Добавлено через 14 минут
Хотя бы на примере класса угла. Тут главное найти весчь саму в себе чтобы не было слишком объемно для демонстрации.

Добавлено через 1 минуту

Сообщение от Curry

Что в неё приделали? Она по прежнему со строгой типизацией.

ООП и перегрузку операторов которых в исходе не было.

Добавлено через 9 минут

Сообщение от Curry

Но это не относится к типизации.

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

Добавлено через 29 минут

Сообщение от Curry

По проблемам с отладкой, по мне лучше уж строгая с GC,

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

@Curry · 24.09.2019, 00:18

Сообщение от Fulcrum_013

демонстрировал уже кучу раз

Не видел. Дайте ссылку на вашу демонстрацию.

Сообщение от Fulcrum_013

ООП и перегрузку операторов которых в исходе не было.

Строгость типизации при этом не отменили.

Сообщение от Fulcrum_013

При неявной же типизации приведется само

Вот ваша нестрогая типизация (на входе везде 100 и 200)

C++

#include <iostream>
using namespace std;
 
int main() {
    unsigned char a,b;
    cin >> a >> b;
    cout << (1.0+a+b);
    return 0;
}

на выходе 98.http://ideone.com/eEzZup
В то время как

SQL

WITH Ada.Text_IO; USE Ada.Text_IO;  
WITH Ada.Integer_Text_IO; USE Ada.Integer_Text_IO;
 
PROCEDURE test IS
    subtype Byte IS INTEGER range 0..255;
    a,b : Byte;
    c: constant FLOAT := 1.0;
BEGIN
    GET(a); GET(b);
    put_line(FLOAT'Image(c + float(a+b)));
end test;

http://ideone.com/SzLWg1
И даже

C#

using System;
 
public class Test
{
    public static void Main()
    {
        Byte a,b;
        a=Byte.Parse(Console.ReadLine());
        b=Byte.Parse(Console.ReadLine());
        Console.WriteLine(1.0+a+b);
    }
}

http://ideone.com/PqtnfH
- только плюсы врут.

Сообщение от Fulcrum_013

акая же точность нужна в результирующем хранилище - это по определению зона ответственности программиста.

Вот именно. Тут нельзя бездумно полагаться на компилятор.

Сообщение от Fulcrum_013

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

Всё даст. Вы же даже не пытались узнать, как оно, в строгих языках.
https://blog.adacore.com/physi... neric-test

Сообщение от Fulcrum_013

А помогает здеся именно ООП

OOП здесь вообще не при чём. Совсем. Не ООПешный Haskell всё это позволяет описать, так что бы складывалось и умножалось то что надо с чем надо давая на выходе только то что разрешено.

@Fulcrum_013 · 24.09.2019, 01:19

Сообщение от Curry

Вот ваша нестрогая типизация (на входе везде 100 и 200)

Я конечно дико извиняюсь но типизация тут совсем даже не при чем.
На входе у плюсов ни разу не 100 и не 200 а 49 и 48. вы вводите два символа а не два числа. оно как бы было очень странно если бы char из потока читался как то по другому.
А с типизацией и счетом усе в полном ажуре
http://ideone.com/lZCxpM

Добавлено через 10 минут

Сообщение от Curry

Всё даст. Вы же даже не пытались узнать, как оно, в строгих языках.

Вы похоже не поняли о чем речь.
пример поведения которое должно быть обеспечено

C++

int main(){
    scalar a;
    vector v1,v2;
    point p1,p2;
    p1+=p2;//ошибка компиляции
    v = p2 - p1; // оk
    p2 = p1 + v;// ok
    p2 = v + p1 // ошибка компиляции
    v1 *= a; //ок
    v1 +=a;   // ошибка компиляции
    a+= v1*v2; //ok;
    a= v1/v2; - ошибка компиляции
}

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

Добавлено через 17 минут

Сообщение от Curry

OOП здесь вообще не при чём.

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

@Curry · 24.09.2019, 07:44

Сообщение от Fulcrum_013

Я конечно дико извиняюсь но типизация тут совсем даже не при чем.

Правда что ли? А я то думал, это баг в gcc.

Сообщение от Fulcrum_013

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

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

Сообщение от Fulcrum_013

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

Сообщение от Fulcrum_013

действие операторов ++ и -- меняется в зависимости от внутреннего состояния

А внутреннее состояние туда как попадёт? Через глобальную переменную что ли? Или состояние вместе с матрицей в типе находится? Во втором случае никаких проблем кроме как операторы нужно будет назвать по другому. -- - это в Haskell как в плюсах //.
К тому же в функциональных языках вместо того что бы делать итератор, делают функцию обхода контейнера которой
передают контейнер и другую функцию как аргумент. Последняя вызывается для каждого элемента контейнера который передаётся ей как аргумент.

@Fulcrum_013 · 24.09.2019, 14:42

Сообщение от Curry

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

НУ так о чем и говорю - к отлову ошибок строгость типизации вообще не при чем. Она только провоцирует ошибки.

Добавлено через 2 минуты

Сообщение от Curry

А внутреннее состояние туда как попадёт?

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

Сообщение от Curry

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

Добавлено через 3 минуты

Сообщение от Curry

Последняя вызывается для каждого элемента контейнера который передаётся ей как аргумент.

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

Добавлено через 1 час 48 минут

Сообщение от Curry

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

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

@Curry · 24.09.2019, 20:04

Сообщение от Fulcrum_013

НУ так о чем и говорю - к отлову ошибок строгость типизации вообще не при чем. Она только провоцирует ошибки.

В нестрогих плюсах что восьми битовые число, что символ -одно и тоже. И как его будет трактовать функция надо помнить - это источник ошибок. А функции не только из std бывают. В более строгих языках, хоть бы и pascal/delphi, число и символ разные, не смешиваемые без приведения, типы. По этому, там по типу аргумента понятно как будет парсится строка в число - как код первого символа строки, или как символную запись числа.

Сообщение от Fulcrum_013

НУ это уже проблемы Хацкеля как оно туда пободет

Это не проблемы Haskell, а проблемы проектирования. Вы предложили использовать плюсовые УНАРНЫЕ операторы.
Вторым аргументом состояние не передашь. Значит, или его заворачивать вместе с матрицей, или в глобальную переменную.
Последнее маразм лютый. На С, конечно, так функцией передаваемой в qsort и рулят, но на то оно и С.

Сообщение от Fulcrum_013

А внутри этой функции обхода нужно обойтить контейнер через итератор. по другому никак.

Итераторы ООП контейнеров служат для инкапуляции своего алгоритма, что бы внешне одинаково с ними работать можно было. Алгоритм итератора реализуется несколькими функциями в классе итератора.
Возможен другой подход, когда весь алгоритм итерации находится в одной функции, его не нужно размазывать по функциям, состояние всё, тоже, там же, в одной функции. Инкапсулируется автоматически, как состояние внутри функции, в данном случае for_each которой передаётся лямбда как тело цикла.

C++

fn main() {
    let v = vec![3,1,4,1,5,9,2,6];
    v.iter().for_each(|i|{
        println!("{}",i);
    });
}

http://ideone.com/dbdru2

Сообщение от Fulcrum_013

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

Haskell

import Data.List
 
testMatrix :: [[Int]]
testMatrix = [[ 1, 2, 3,4],
              [12,13,14,5],
              [11,16,15,6],
              [10, 9, 8,7]]
           
main :: IO ()
main = do
    let clockwise [] = []
        clockwise (h:t) = h++(clockwise $ reverse $ transpose t)
        contraclockwise = clockwise . transpose
    print $ zipWith (*) (clockwise testMatrix) (contraclockwise testMatrix)

http://ideone.com/XrJLCY
Никаких комбинаторных взрывов и прочего терроризма.

Добавлено через 18 минут

Сообщение от Fulcrum_013

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

Кстати, можете задать задачку в разделах по ФП языкам (Haskell,Erlang). Посмотреть, что будет.

@Fulcrum_013 · 24.09.2019, 20:49

Сообщение от Curry

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

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

Добавлено через 6 минут

Сообщение от Curry

Посмотреть, что будет

Та это давно известно. Если бы ФП которое родилось по большому счету в 40-х умело бы разруливать комбиноторные взрывы, то предназначенное именно для этого ООП в конце 60-х не родили бы.

@korvin_ · 24.09.2019, 21:08

Итераторы прекрасно пишутся чисто функционально так-то.

@~~Rich Froning~~ · 24.09.2019, 21:40

Сообщение от Talamaur

Да и инструментарий ASP.NET будет побогаче чем PHP?

Сколько сайтов работает на PHP и сколько на ASP.NET? В лучшем случае это соотношение будет сто к одному. В лучшем для ASP.NET

@Fulcrum_013 · 24.09.2019, 22:28

Сообщение от korvin_

Итераторы прекрасно пишутся чисто функционально так-то.

так они как то по определению нечистые.

@korvin_ · 24.09.2019, 22:58

Сообщение от Fulcrum_013

так они как то по определению нечистые.

Не по определению, а по нечистому варианту дизайна. Ничто не мешает задизайнить чистые итераторы.

@Fulcrum_013 · 24.09.2019, 23:03

Сообщение от korvin_

Ничто не мешает задизайнить чистые итераторы.

Он по определению состояние (положение головки чтения/записи).

@Talamaur 119 / 84 / 42 Регистрация: 14.12.2015 Сообщений: 945
		1
	PHP vs другие WEB-ориентированные языки программирования 19.09.2019, 10:39. Показов 2842. Ответов 34 Метки нет (Все метки) Здравствуйте. Как вы считаете есть ли будущее у PHP? Даже если судить по количеству людей онлайн в ветке C#, например, и PHP, то можно сделать вывод, что PHP не пользуется большой популярностью. Да и инструментарий ASP.NET будет побогаче чем PHP? Ведь все, что делается на пых можно сделать и на asp.net. Тогда зачем нужен данный язык? В своих взглядах могу и ошибаться и вывод про популярность яп это чисто личное мнение. Конечно каждый программист будет хвалить тот яп на котором программирует, но все же хотелось услышать мнение кто профессионально работает и может сказать плюсы и минусы того же PHP. Возможно пых легче и быстрее освоить чем asp.net? Но тогда возможен ли переход с php на asp.net? Хотя это маловероятно. Переход с не строго типизированного яп на строго типизированный будет сложным. И ведь тот же MS более активно работает над развитием своего яп. 0

@IamLost
	19.09.2019, 10:57 #2
	Не по теме: Сообщение от Talamaur PHP Сообщение от Talamaur C# Сообщение от Fulcrum_013 выбирать современный профессиональный язык (C++) а не эти архаичные обрубки. Тему можно закрывать. 0

@Talamaur 119 / 84 / 42 Регистрация: 14.12.2015 Сообщений: 945
	19.09.2019, 11:30 [ТС]	3
	Сообщение от IamLost выбирать современный профессиональный язык (C++) а не эти архаичные обрубки. И чем же С# является "обрубком" то? 0

@IamLost 88 / 108 / 6 Регистрация: 16.04.2019 Сообщений: 451 Записей в блоге: 4
	19.09.2019, 11:44	4
	Сообщение от Talamaur И чем же С# является "обрубком" то? Это вопрос не ко мне, это вопрос к "профессионалу-не-быдлокодеру" Fulcrum_013. 0

@Fulcrum_013 2063 / 1542 / 168 Регистрация: 14.12.2014 Сообщений: 13,402
	23.09.2019, 19:31	5
	IamLost, Во всем. Автоматика полностью устарела по состоянию на конец 60-х и в принципе ничего не способна автоматизировать в ООП языке. Алгебру над сущностями определить не позволяет. Дженерики к этому не приспособлены в принципе (даже наличие оператора/метода у типа-аргумента проверить в компайлтайме не в состоянии не говоря уже о чем то большем ). Т.е. ни о какой серьезной разработке на шарпе речи идти не может в принципе. Не годен даже для создания на нем серьезного оконного фреймверка. Борланд всю эту шнягу WinForms которая в исходе называлась C# Builder даже релизить отказался. Вышел из проекта и продал ее майкрасофту, которому нужен был фреймвер на языке основанном именно на изучаемой в школах жабе для замены ворд и эксель васика, за акции которые та купила когда входила в проект. Добавлено через 7 минут Настолько куцым по сравнению с реализацией на дельфе, в которой автоматики нет от слова совсем, оный WinForms оказался. Добавлено через 3 минуты т.е. по сути жаба это Simula-67 с фигурными скобками вместо begin/end. А шарп это еще чуток досыпанного в оную симулу синтаксического сахара. Добавлено через 19 минут В результате даже два мировых лидера в плане средств визуальной разработки даже совместно ничего толкового на нем сделать не смогли. Точно так же эпическим фейлом закончились попытки зарелизить борландовскую Delphi.NET и майкрософтовский С++.NET. Причина - GC абсолютно не предназначен для работы в графах ссылок характерных для паттернов ООП (не в состоянии ничего посчитать мусором без сторонней помощи в виде решения задачи управления взаимосвязями) и абсолютно не предназначен для управления ресурсами. При этом даже ручное решение задачи управления взаимосвязми/ресурсами без которой GC не в состоянии обеспечить уборку, побочным эффектом имеет и решение задачи управления памятью гораздо более эффективным методом чем это делает GC, что делает GC ненужным от слова совсем. Не говоря уже про современную кастомизируемую автоматику управления жизненным циклом. При этом дефрагментация, без которой GC работать не в состоянии абсолютно бессмысленна в системе со страничной организацией виртуальной памяти и вообще склона к сваливанию к еще более бессмысленной дефрагментации свопа. При этом чем больше объем обрабатываемых данных тем сильнее дефрагментация и сканирование бьют по быстродействию. Память она чертовски дешевая за счет того что чертовски медленная. Вообще GC разрабатывался в свое время для перфолент и потом магнитных лент где дефрагментация снижала потребное время перемотки. Но для памяти с произвольным доступом и особенно с страничной организацией виртуальной памяти - это самый неэффективный способ, кроме того что абсолютно бесполезный для ООП и управления ресурсами в плане автоматики. Добавлено через 41 минуту Если же к этому присовокупить неумение жабы/шарпа и прочих мусоросборников осуществлять статическую композицию и размещать временные интсансы классов на аппаратном стеке при абсолютном отсутсвии средств кастомизации алгоритмов распределения эмулированного стека с произвольным порядком высвобождения/удаления (именно эта шняга у них под капотом а не какая не куча) имеем еще и абсолютную неприспособленность всего этого поголовья к мультипотоку. О какой серьезной разработке на таких языках вообще может идти речь? Добавлено через 5 часов 31 минуту Сообщение от Talamaur Тогда зачем нужен данный язык? В свое время был очень даже грамотным решением. Суть - обработка запросов в CGI пакетная. т.е. процесс-обработчик запускается генерит страницу и после этого завершается. А соответсвенно обработчик каждой страницы - отдельный софтинка которая с соседним обработчиком обмениваться данными может только через БД/диск. Ну и все бы ничего можно консольные софтинки на том же сишечке накатать и радоваться. Только вот места на хостинге по тем временам было ну очень ограниченным. а с динамическими библиотеками под линуксоидом было хуже чем никак. соответсвенно прилинковать всю толпу либ доступа к БД и т.д. к обработчику грубо говоря каждой кнопки получалось сильно жирно. Да и хостинг весь был шареный посему возможность побусурманить нужно было ограничивать. От и сотворили один модулек к которому прилинковали все-все нужные либы и виртуальную машину позволяющую доступ к функциям этих либ одобренных всевышним на свое усмотрение. При этом для запуска скриптов выделение памяти сделали на основе регионов. И регионы отваливали немерянные. ТАк чтобы для подавляющего большинства запросов GC за время работы скрипта не разу запускать не понадобилось а можно было после отработки скрипта отправить весь регион на переиспользование одним махом и без разбору. Отак собственно пых и родился. Кстати примерно так же примерно по тем же причинам родился ASP и живет он очень подобным пыху образом, только имеет несколько языков в арсенале своей VM а не один. Сообщение от Talamaur но все же хотелось услышать мнение кто профессионально работает и может сказать плюсы и минусы того же PHP В свете перехода веба к дуплексным протоколам и интерактивной обработке запросов осуществляемой демонами на выделенных/виртуальных серверах обречен на вымирание как и любой язык с GC а тем более скриптовый. По тем же причинам на вымирание обречен и ASP. Добавлено через 30 минут Сообщение от Talamaur Переход с не строго типизированного яп на строго типизированный будет сложным Вы наверное хотели сказать с динамически типизированного на статически типизированный? Наоборот вздохнете с огромным облегчением и забудете про бессонные ночи ненужной отладки очень трудно обнаруживаемых багов вызванных несоответсвием типов. Все это отловит компилятор. Он в этом плане средство замены человеко-лет на машино-секунды. А вот строгая типизация это реально перебор. Неявная статическая а тем более настраиваемая гораздо более удобная штука. Добавлено через 3 минуты Реально динамическая типизация вредна в 99,9% случаев. А для тех 0,1% случаев где она реально нужна, она доступна и в языках со статической типизацией через библиотечные средства. 0

@Curry Модератор 5046 / 3275 / 526 Регистрация: 01.06.2013 Сообщений: 6,806 Записей в блоге: 9
	23.09.2019, 20:49	6
	Сообщение от Fulcrum_013 А вот строгая типизация это реально перебор. Это говорит о том, что вы ещё не до конца научились мыслить в рамках статической типизации, которая должна быть строгой. Не строгая так же ведёт к ошибкам и "бессонным ночам отладки", только в слегка меньшей степени. Нежелание привести тип явно сродни нежеланию "секономить" на описании типа свойственному скриптосочинителям. По проблемам с отладкой, по мне лучше уж строгая с GC, чем не строгая со смартпоинтерами. 0

@Fulcrum_013 2063 / 1542 / 168 Регистрация: 14.12.2014 Сообщений: 13,402
	23.09.2019, 21:56	7
	Сообщение от Curry которая должна быть строгой Она должна быть настраиваемой. Все проблемы ады из за строгой типизации. Идея того что она способна отловить ошибки путем запрета использования разных типов в одной операции оказалось полным фейлом ведущим к перегруженности кода операторами приведения типов ведущим к ошибкам. после чего в нее экстренно доделали средства определения алгебры над сущностями предметной области аналогичные плюсовым. Добавлено через 2 минуты Сообщение от Curry Не строгая так же ведёт к ошибкам и "бессонным ночам отладки", только в слегка меньшей степени Ни разу не замечал такого. Наверное потому что сначала алгебру над сущностями определяю а потом уже все остальное. 0

@Curry Модератор 5046 / 3275 / 526 Регистрация: 01.06.2013 Сообщений: 6,806 Записей в блоге: 9
	23.09.2019, 22:05	8
	Сообщение от Fulcrum_013 Все проблемы ады из за строгой типизации. Что за проблемы? Она громоздкая. И проблемы с кодировками. Но это не относится к типизации. Что в неё приделали? Она по прежнему со строгой типизацией. Сообщение от Fulcrum_013 Наверное потому что сначала алгебру над сущностями определяю а потом уже все остальное. Вы теперь в каждом посту про эту алгебру над сущностями. Продемонстрируйте кодом. 0

@Fulcrum_013 2063 / 1542 / 168 Регистрация: 14.12.2014 Сообщений: 13,402
	23.09.2019, 23:03	9
	Сообщение от Curry По проблемам с отладкой, по мне лучше уж строгая с GC, чем не строгая со смартпоинтерами Ну не знаю что там у вас за смартпоинтеры а у меня с отладкой особенно того что касается управления памятью и итераторов не то что проблем отладки то как таковой не было. Собралось и поехало. Наверное потому что для ООП пользую правила взаимосвязей ООП - композицию и аггрегацию, соблюдение которых делает GC ненужным от слова совсем, а не какую то абсолютно непригодную для управления активными сущностями муть по принципу нужен/не нужен которая совсем из другой песочницы управления пассивными буферами. Добавлено через 53 секунды Сообщение от Curry Продемонстрируйте кодом. та демонстрировал уже кучу раз Добавлено через 14 минут Хотя бы на примере класса угла. Тут главное найти весчь саму в себе чтобы не было слишком объемно для демонстрации. Добавлено через 1 минуту Сообщение от Curry Что в неё приделали? Она по прежнему со строгой типизацией. ООП и перегрузку операторов которых в исходе не было. Добавлено через 9 минут Сообщение от Curry Но это не относится к типизации. Еще как относится. Если нельзя смешивать типы то придется приводить. При этом запросто можно потерять точность и т.д. - оно выполнит все что программист укажет явно молча. При неявной же типизации приведется само и точность в промежуточных вычислениях гарантированно не потеряет потому что автоматически приводится только к более широкому типу. Какая же точность нужна в результирующем хранилище - это по определению зона ответственности программиста. Но если она окажется ниже чем промежуточного результата об этом очень четко будет сообщено. Опять же как строгая типизация не позволит сложить точку с точкой которые не должны складываться а сложить точку только с вектором, а при вычитании точек получить вектор? Или как она не даст умножить скорость на скорость а прибавить к скорости даст только дифференциал скорости? В том то и дело что никак. Только помешает в этом вопросе. А помогает здеся именно ООП и определение алгебры над сущностями. т.е. правил кого с кем можно складывать а кого с кем нет и т.д задаваемых программистом исходя из предметной области задачи а не взятых с потолка горе-разрабами языка. В плюсах так о птичках фундаментальные типы нужны только для того чтобы собрать типы предметной области. Точно так же как сырые указатели нужны только для того чтобы изготовить нужные для задачи смарты и итераторы. Добавлено через 29 минут Сообщение от Curry По проблемам с отладкой, по мне лучше уж строгая с GC, С GC хоть строгая хоть какая - ни автоматики никакой и потечет в конечном итоге гарантированно. И ловят эти косвенные утечки годами. 0

@Curry Модератор 5046 / 3275 / 526 Регистрация: 01.06.2013 Сообщений: 6,806 Записей в блоге: 9
	24.09.2019, 07:44	12
	Сообщение от Fulcrum_013 Я конечно дико извиняюсь но типизация тут совсем даже не при чем. Правда что ли? А я то думал, это баг в gcc. Сообщение от Fulcrum_013 при чем тут строгость типизации то? она для обеспечения этого вообще не при делах. это только перегрузкой операторов делается. Так разобрались бы вначале, прежде чем писать Сообщение от Fulcrum_013 Опять же как строгая типизация не позволит сложить точку с точкой которые не должны складываться а сложить точку только с вектором, а при вычитании точек получить вектор? Или как она не даст умножить скорость на скорость а прибавить к скорости даст только дифференциал скорости? Сообщение от Fulcrum_013 действие операторов ++ и -- меняется в зависимости от внутреннего состояния А внутреннее состояние туда как попадёт? Через глобальную переменную что ли? Или состояние вместе с матрицей в типе находится? Во втором случае никаких проблем кроме как операторы нужно будет назвать по другому. -- - это в Haskell как в плюсах //. К тому же в функциональных языках вместо того что бы делать итератор, делают функцию обхода контейнера которой передают контейнер и другую функцию как аргумент. Последняя вызывается для каждого элемента контейнера который передаётся ей как аргумент. 0

@Fulcrum_013 2063 / 1542 / 168 Регистрация: 14.12.2014 Сообщений: 13,402
	24.09.2019, 14:42	13
	Сообщение от Curry Так разобрались бы вначале, прежде чем писать НУ так о чем и говорю - к отлову ошибок строгость типизации вообще не при чем. Она только провоцирует ошибки. Добавлено через 2 минуты Сообщение от Curry А внутреннее состояние туда как попадёт? НУ это уже проблемы Хацкеля как оно туда пободет. но чтобы обойти матрицу по спирали нужно помнить текущее значение шага и где повернуть под капотом у того кто обходит. Сообщение от Curry К тому же в функциональных языках вместо того что бы делать итератор, делают функцию обхода контейнера которой Добавлено через 3 минуты Сообщение от Curry Последняя вызывается для каждого элемента контейнера который передаётся ей как аргумент. А внутри этой функции обхода нужно обойтить контейнер через итератор. по другому никак. Т.е. последовательно получить адреса элементов в заданной последовательности чтобы передать этой передаваемой функции. Добавлено через 1 час 48 минут Сообщение от Curry К тому же в функциональных языках вместо того что бы делать итератор, делают функцию обхода контейнера которой передают контейнер и другую функцию как аргумент. А теперя немного скомбинируем. Две матрицы одна обходится по часовой стрелке вторая против часовой. элементы перемножить. Вот тут и вылазит комбинаторный взрыв с которым ФП ничего сделать не в состоянии, а ООП справляется элементарно. Пример конечно немного притянутый потому что именно такое редко пользуется. Но как бы в определении алгебр такой же взрыв просто менее очевиден но зато гораздо гораздо мощнее. 0

@Fulcrum_013 2063 / 1542 / 168 Регистрация: 14.12.2014 Сообщений: 13,402
	24.09.2019, 20:49	15
	Сообщение от Curry Возможен другой подход, когда весь алгоритм итерации находится в одной функции При росте количества алгоритмов обхода и количества контейнеров которые нужно обойти синхронно этот подход приводит к комбинаторному взрыву и постоянному переписыванию оной функции для каждого из сочетаний в месте обхода. В отличии от итераторов у которых все это пишется один раз на итератор (а то и целую категорию итераторов) и комбинируется как угодно. Добавлено через 6 минут Сообщение от Curry Посмотреть, что будет Та это давно известно. Если бы ФП которое родилось по большому счету в 40-х умело бы разруливать комбиноторные взрывы, то предназначенное именно для этого ООП в конце 60-х не родили бы. 0

@korvin_ 4485 / 2720 / 485 Регистрация: 28.04.2012 Сообщений: 8,585
	24.09.2019, 21:08	16
	Итераторы прекрасно пишутся чисто функционально так-то. 0

@~~Rich Froning~~ Заблокирован
	24.09.2019, 21:40	17
	Сообщение от Talamaur Да и инструментарий ASP.NET будет побогаче чем PHP? Сколько сайтов работает на PHP и сколько на ASP.NET? В лучшем случае это соотношение будет сто к одному. В лучшем для ASP.NET 0

@Fulcrum_013 2063 / 1542 / 168 Регистрация: 14.12.2014 Сообщений: 13,402
	24.09.2019, 22:28	18
	Сообщение от korvin_ Итераторы прекрасно пишутся чисто функционально так-то. так они как то по определению нечистые. 0

@korvin_ 4485 / 2720 / 485 Регистрация: 28.04.2012 Сообщений: 8,585
	24.09.2019, 22:58	19
	Сообщение от Fulcrum_013 так они как то по определению нечистые. Не по определению, а по нечистому варианту дизайна. Ничто не мешает задизайнить чистые итераторы. 0

@Fulcrum_013 2063 / 1542 / 168 Регистрация: 14.12.2014 Сообщений: 13,402
	24.09.2019, 23:03	20
	Сообщение от korvin_ Ничто не мешает задизайнить чистые итераторы. Он по определению состояние (положение головки чтения/записи). 0