Bir sonraki soyutlama seviyesi nedir? [kapalı]


15

Programlama dilleri başlangıçta sadece sıralı olarak yürütülen kod satırlarını kullandığından ve ilk soyutlama seviyelerinden biri olan işlevler dahil edildi ve daha sonra soyutlamak için sınıflar ve nesneler oluşturuldu; bir sonraki soyutlama seviyesi nedir?

Sınıflardan daha soyut olan nedir veya henüz var mı?


17
Bunun bir sıralamayla doğrusal bir ilerleme olduğunu düşünüyorsunuz ("X, Y'den daha soyut, Z'den daha soyut"). Naçizane size katılmıyorum.

2
Neden farklı olduğunuzu söylemek iyi bir fikir olabilir . ;) (okuyun: İlgileniyorum!)
sergserg

3
Nihai "soyutlama" yı öneriyorum: Yazdığımı değil, düşündüğümü yap. ;)
Izkata

1
@Delnan: Soyutlama toplam bir emir sunmaz, ancak "daha soyut", "daha az soyut" demek mümkündür. Örneğin, birleştirme sıralamasının genel bir uygulaması, yalnızca tamsayılar için çalışan bir birleştirme sıralaması uygulamasından daha soyuttur.
Giorgio

2
Bros, sana bir kategori teorisi öğren. O zaman soyutlamanın medeni insanlar gibi gerçekten ne anlama geldiğini tartışabiliriz.
davidk01

Yanıtlar:


32

Bilgisayar tarihi ile ilgili bazı yanılgılarınız olduğunu düşünüyorum.

İlk soyutlama (1936'da), aslında, yüksek dereceli fonksiyonlar kavramının ve onu takip eden tüm fonksiyonel dillerin temeli olan Alonzo Church'un Lambda Calculus'uydu. Doğrudan Lisp'e (1959'da oluşturulan ikinci en eski üst düzey programlama dili) ilham verdi ve bu da ML'den Haskell ve Clojure'a kadar her şeye ilham verdi.

İkinci soyutlama prosedürel programlama idi. Her seferinde bir komut olmak üzere sıralı programların yazıldığı von Neumann bilgisayar mimarilerinden çıktı. FORTRAN (en eski üst düzey programlama dili, 1958) prosedür paradigmasından çıkan ilk üst düzey dildi.

Üçüncü soyutlama, aslında Absys (1967) ve daha sonra Prolog (1972) tarafından örneklenen, aslında bildirimsel programlama idi. İfadelerin bir dizi talimat yürütmek yerine bir dizi beyan veya kural eşleştirilerek değerlendirildiği mantık programlamanın temelidir.

Dördüncü soyutlama daha sonra 60'lı yıllarda Lisp programlarında ilk kez ortaya çıkan, ancak daha sonra 1972'de Smalltalk tarafından örneklendirilen nesne yönelimli bir programdı. (Smalltalk'ın mesaj geçiş tarzının Tek Gerçek nesne yönelimli soyutlama. Buna dokunmayacağım.)

Diğer tüm soyutlamalar, özellikle de geleneksel von Neumann bilgisayar mimarisinde, bu dört temanın varyasyonlarıdır. Bu dördünün ötesinde sadece bir varyasyon veya bunların bir kombinasyonu olmayan başka bir soyutlama olduğuna ikna olmadım.

Ancak soyutlama, özünde, bir algoritmayı modellemenin ve tanımlamanın bir yoludur. Algoritmaları bir dizi ayrık adım, uyulması gereken bir kurallar kümesi, bir matematiksel fonksiyonlar kümesi veya etkileşen nesneler olarak tanımlayabilirsiniz. Algoritmaları tanımlamak veya modellemek için başka bir yol düşünmek çok zordur ve var olsa bile, faydasına ikna olmadım.

Bununla birlikte, kuantum hesaplama modeli vardır. Kuantum hesaplamada, kuantum algoritmalarını modellemek için yeni soyutlamalar gereklidir. Bu alanda bir neofit olarak, bu konuda yorum yapamam.


4
Unsur Odaklı Programlama başka bir soyutlama şekli olarak düşünülebilir mi?
Shivan Dragon

Nesneye yönelik programlama 60'lı yıllarda Lisp'ten mi çıktı? [alıntı gerekli], büyük zaman. Duyduğum her şey , 60'lı yıllarda Lisula ile ilgisi olmayan zorunlu bir dil olan ALGOL'un doğrudan soyundan gelen Simula'dan geldiğini söylüyor . Smalltalk, Simula tarafından tanıtılan kavramları alıp daha “lispy” hissetmek için onları döndürerek ortaya çıktı.
Mason Wheeler

3
@MasonWheeler: Lisp 1 ve 1.5 kılavuzlarındadır ve Lispers'in özellikle yaşlılar olmak üzere nesne odaklı programlar yapmaktan bahsettiğini duymak yaygındır. Yapay zeka adamları o sırada Lisp'de nesne sistemleri yapma konusunda büyüklerdi.
greyfade

2
@ShivanDragon: Hayır derdim. Bu sadece, ek koşum takımlarıyla prosedürel olmayan bir program yürütmenin bir yoludur. Algoritmaları gerçekten modellemez ve veri yapılarının tasarımını etkilemez.
greyfade

4
Aslında, SKI birleştirici hesabı hem lambda hesabından hem de Turing Makinesinden önce gelir.
Jörg W Mittag

4

Birçoğu için, ikili programlamanın mevcut çağındaki en soyut kod soyutlama biçimi "üst düzey işlev" dir. Temel olarak, işlevin kendisi veri olarak ele alınır ve işlevlerin işlevleri, işlenenlerin sonuçlarını tanımlayan işleçlerle ve bu işlemlerin "iç içe geçmesini" tanımlayan önceden belirlenmiş bir işlem sırasıyla matematiksel denklemlerde göreceğiniz gibi tanımlanır. Matematiğin yapısında çok az sayıda “zorunlu komut” vardır; düşünebileceğim iki örnek "x'in bir değere sahip olmasına veya bazı kısıtlamalara uygun herhangi bir değere sahip olmasına" ve girdinin çıktıyı üretmek için gereken ifadeyi belirlediği "parçalı fonksiyonlara" ilişkindir. Bu yapılar kendi işlevleri olarak kolayca temsil edilebilir; "işlev" x her zaman 1 döndürür ve "aşırı yüklenmeler" fonksiyonlar, kendilerine bile, adlandırılmış bir fonksiyon grubunun "parça parça" olarak değerlendirilmesine izin veren (nesne yönelimli aşırı yüklerin aksine, değerler girişine göre tanımlanabilir) olarak tanımlanır. Bu nedenle, program düşük düzeyde zorunluluk kavramını ortadan kaldırmakta ve bunun yerine girdi verilerinin "kendini değerlendirmesine" odaklanmaktadır.

Bu üst düzey işlevler "işlevsel diller" in omurgasını oluşturur; Bir programın yaptığı, birbirinin içine yerleştirilen ve gerektiğinde değerlendirilen "saf işlevler" (bir veya daha fazla giriş, bir veya daha fazla çıkış, yan etki veya "gizli durum") olarak tanımlanır. Bu gibi durumlarda, çoğu "zorunlu mantık" soyutlanır; çalışma zamanı, işlevlerin gerçek çağrısını ve bir işlevin bir veya diğer aşırı yüklenmesinin çağrılması gerekebilecek koşulları yönetir. Böyle bir programda, kod bir şey "yapmak" olarak düşünülmez, bir şey "olmak" olarak düşünülür ve programın ilk girdi verildiğinde tam olarak ne olduğu belirlenir.

Üst düzey işlevler artık birçok zorunlu dilin temelini oluşturmaktadır; .NET'in lambda ifadeleri temel olarak başka bir "fonksiyona" anonim "fonksiyonel girişe izin verir (zorunlu olarak teorik olarak uygulanmak zorunda değildir), böylece çok genel amaçlı" fonksiyonların "oldukça özelleştirilebilir" zincirlenmesine "izin verir istenen sonuç.

Programlama dillerinin son turunda yaygın olarak görülen bir diğer soyutlama, "ördek-tipi" kavramına dayanan dinamik değişken tiplemesidir; Ördek gibi görünüyor, ördek gibi yüzüyor, ördek gibi uçuyor ve ördek gibi quacks, buna ördek diyebilirsiniz. Aslında bir yeşilbaş mı yoksa kanvas sırt mı olduğu önemli değil. Bu aslında bir kaz veya kuğu ise önemli, ancak OLABİLİR sonra tekrar bu olabilir önemli değildir önemsediğiniz tüm yüzüş ve sinekler ve bu ise tür bir ördek gibi görünüyor. Bu, nesne mirasında nihai kabul edilir; Eğer umurumda değil edilir , ona bir isim vermek için hariç; daha önemli olan ne yaptığıdır. Bu dillerde temel olarak sadece iki tür vardır; "atom", tek bir bilgi unsuru (bir "değer"; bir sayı, karakter, fonksiyon, ne olursa olsun) ve bir atomdan ve gruptaki diğer her şeye bir "işaretçiden" oluşan "demet". Tam olarak bu türlerin çalışma zamanı tarafından ikili olarak nasıl uygulandığı önemsizdir; bunları kullanarak, basit değer türlerinden dizelere ve koleksiyonlara kadar aklınıza gelebilecek hemen hemen her türün işlevselliğini elde edebilirsiniz (bu değerler farklı "türlerden" olabileceğinden "karmaşık türler" aka "nesneler" e izin verir).


1
"Ördek yazmak" (en azından sizin tarif ettiğiniz gibi) gerçekten yeni değildir veya dinamik olarak yazılmış dillerle sınırlı değildir; en iyi OCaml'de görülen "yapısal alt yazı" olarak statik olarak yazılan dillerde uzun zamandır var.
Tikhon Jelvis

2

SQL gibi Etki Alanına Özgü Diller daha yüksek bir soyutlama sırası olarak düşünülebilir. SQL, depolama gibi işlemleri ortadan kaldıran ve küme teorisine dayalı daha üst düzey işlevler sağlayan çok hedefli bir dildir. Ayrıca bugün kaç ana dilin belirli bir mimariyi değil, bir Sanal Makineyi (JVM veya .NET CLR gibi) hedeflediğini düşünün. Bir örnek için C #, yerel çalışma zamanı motoru tarafından yorumlanan (veya daha sık JIT'd - Sadece Derlenmiş - yerel bir uygulama için) olan IL'ye derlenir.

Bir çalışma programı oluşturmak için çok fazla teknik deneyim olmadan kullanılabilecek çok yüksek seviyeli diller oluşturmak için kullanılan DSL'ler kavramı hakkında çok fazla yayın yapıldı. Birinin varlıklarını ve etkileşimlerini düz İngilizce'ye yakın bir şekilde tanımlayabildiğini ve işletim ortamının basit bir kullanıcı arayüzü sunmaktan, verileri bir tür veritabanında depolamaya kadar her şeyi ele alıp almadığını düşünün. Bu işlemler soyutlandıktan sonra, programlamanın ne kadar zahmetsiz olabileceğini hayal edebilirsiniz.

Günümüzde JetBrains MPS (DSL'leri veya bir dil üreticisini tanımlamak için bir araç takımı) gibi bazı varlıklar var . Microsoft, M dili (M dili o kadar eksiksizdi ve dil M'de tanımlanmıştı ) ile bu alana kısa bir giriş yaptı (ve çok umut verici olabilirim ).

Konsept eleştirmenleri, programcıları program geliştirme işinden kaldırma konusunda önceki başarısız girişimlere işaret ediyor, DSL çalışma tezgahları arasındaki fark (Fowler'in dediği gibi), geliştiricilerin Alan Adı Uzmanlarının ifade etmek için kullanabileceği kavramları kodlamaya katılmasıdır. alanlarının ihtiyaçları. Tıpkı OS ve Language satıcılarının programlama için kullandığımız araçları yaratması gibi, işletme kullanıcıları için araçlar sağlamak için DSL'leri kullanırdık. Veriler ve mantığı tanımlayan DSL'ler düşünülebilirken, geliştiriciler verileri depolayan ve alan ve DSL'de ifade edilen mantığı uygulayan tercümanlar oluştururlar.


1

Meta yapıların, modüllerin, çerçevelerin, platformların ve hizmetlerin hepsinin sınıflardan daha üst düzey özellik gruplamaları olduğunu iddia ediyorum. Programlama sistemi soyutlama hiyerarşim:

  • Hizmetler
  • platformlar, çözelti yığınları
  • çerçeveler
  • modüller, paketler
  • meta yapılar: metasınıflar, yüksek dereceli fonksiyonlar, jenerikler, şablonlar, özellikler, yönler, dekoratörler
  • nesneler, sınıflar, veri türleri
  • fonksiyonlar, prosedürler, altyordamlar
  • Kontrol Yapıları
  • Kod satırları

Metasınıflar , üst düzey işlevler ve jenerikler gibi meta yapılar , temel sınıflara, işlevlere, veri türlerine ve veri örneklerine açıkça soyutlama ekler. Özellikler, yönler ve dekoratörler, kod özelliklerini birleştirme ve benzer şekilde diğer sınıfları ve işlevleri 'hızlandırma' için yeni mekanizmalardır.

Ön-nesne dillerinde bile modül ve paketler vardı, bu yüzden onları sınıfların üzerine koymak tartışmalı olabilir. Bu sınıfları ve meta yapıları içeriyorlar, bu yüzden onları daha üst sıralara yerleştiriyorum.

Çerçeveler en düşük cevaptır - sofistike üst düzey soyutlamalar sağlamak için çoklu sınıfları, meta yapıları, modülleri, işlevleri ve benzerlerini düzenlerler. Yine de çerçeveler neredeyse tamamen programlama alanında faaliyet gösteriyor.

Çözüm yığınları veya platformları genellikle birden çok sorunu çözmek için birden çok çerçeveyi, alt sistemi veya bileşeni bir ortamda birleştirir.

Son olarak, orada hizmet olarak dağıtılan --often Web veya ağ hizmetleri. Bunlar, komple paketler halinde sunulan mimariler, çerçeveler, çözüm yığınları veya uygulama yetenekleridir. İç kısımları genellikle opaktır, öncelikle yönetici, programlama ve kullanıcı arabirimlerini ortaya çıkarır. PaaS ve SaaS yaygın örneklerdir.

Şimdi, bu ilerleme birkaç nedenden dolayı tamamen tatmin edici olmayabilir. Birincisi, mükemmel doğrusal veya hiyerarşik olmayan şeylerin düzgün bir doğrusal ilerlemesini veya hiyerarşisini yapar. Tamamen geliştirici kontrolü altında olmayan "yığınlar" ve hizmet gibi bazı soyutlamaları kapsar. Ve yeni bir sihirli pixie tozu oluşturmuyor. (Spoiler: Sihirli peri tozu yok. )

Bence sadece yeni soyutlama seviyelerine bakmak bir hata . Yukarıda sıraladığımların hepsi, şu anda olduğu kadar önemli veya popüler olmasalar bile, yıllardır var olmuştur . Ve o yıllar boyunca, her kodlama seviyesinde mümkün olan soyutlamalar gelişti. Artık sadece diziler değil, genel amaçlı, genel koleksiyonlarımız var. Sadece dizin aralıklarını değil, koleksiyonları da gözden geçiriyoruz. Liste kavrayışlarımız ve liste filtre ve harita operasyonlarımız var. Birçok dilin işlevlerinde değişken sayıda bağımsız değişken ve / veya varsayılan bağımsız değişken olabilir. Ve bunun gibi. Her düzeyde soyutlamayı artırıyoruz , bu nedenle daha fazla seviye eklemek genel soyutlama seviyesini artırmak için bir gereklilik değildir.


1

Sınıflardan sonraki soyutlama meta sınıflarıdır . Bu kadar basit ;)

örnekleri sınıf olan bir sınıf. Tıpkı sıradan bir sınıfın belirli nesnelerin davranışını tanımlaması gibi, metasınıf da belirli sınıfların davranışlarını ve örneklerini tanımlar. Nesneye yönelik tüm programlama dilleri metasınıfları desteklemez. Yapanlar arasında, metasınıfların sınıf davranışının herhangi bir yönünü ne kadar geçersiz kılabileceği değişir. Her dilin kendi metaobject protokolü, nesnelerin, sınıfların ve metasınıfların nasıl etkileştiğini yöneten bir dizi kural vardır ...


1
Metasınıflar, dilin miras hiyerarşisinin (nesnelerinin) kök nesneleridir. .NET nesnedir. Ayrıca arayüzleri metasınıf olarak düşünebilirsiniz; mirasçılarının arayüzünü, mirasçının gerçek "ebeveyn" sınıfından bağımsız olarak tanımlarlar.
KeithS

1
@KeithS, kelimenin herhangi bir bağlamda ne anlama geldiğini görmedim - CLOS'tan UML'ye C #. Bir metasınıf, örnekleri sınıf olan bir sınıftır - zayıf bir uygulama, Typeyansıtıcı yetenekler sağlayan ancak mutasyona sahip olmayan C # ' dir ( CLOS'ta olabildiğince MyTypesöyleyerek yeni bir yöntem ekleyemezsiniz typeof(MyType).Methods += new Method ( "Foo", (int x)=>x*x ))
Pete Kirkham

1

Kimsenin kategori teorisinden bahsetmediğine şaşırdım.

Programlamanın en temel birimi tiplere dayanan işlevdir. Fonksiyonlar genellikle f: A -> B olarak belirtilir, burada A ve B tiptir. Türleri ve işlevleri çağırdığım bu şeyleri doğru bir şekilde koyarsanız, kategori adı verilen bir şey elde edersiniz. Bu noktada durmak zorunda değilsiniz.

Bunları, kategorileri alın ve kendinizle bunları ilişkilendirmenin doğru yolunun ne olacağını sorun. Eğer doğru yaparsanız, iki kategori arasında yer alan ve genellikle F: C -> B olarak adlandırılan bir functor olarak adlandırılan bir şey elde edersiniz.

Tüm functorları alıp doğru şekilde bir araya getirebilirsiniz ve doğru olanı yaparsanız, iki functorun birbiriyle nasıl ilişkilendirileceğini merak etmeye başlarsınız. Bu noktada doğal dönüşüm adı verilen bir şey elde edersiniz, mu: F -> G, burada F ve G functor'lardır.

Bu noktada bilgim bulanıklaşıyor, ancak bunu yapmaya devam edebilir ve soyutlama merdivenine tırmanmaya devam edebilirsiniz. Nesneler ve sınıflar, soyutlama merdivenden ne kadar yükseğe çıkabileceğinizi açıklamaya bile yaklaşmazlar. Yukarıdaki kavramları hesaplamalı olarak ifade edebilen birçok dil vardır ve bu dillerden en önemlisi Haskell'dir. Eğer gerçekten soyutlamanın ne hakkında olduğunu bilmek istiyorsanız, o zaman git Haskell veya Agda veya HOL veya ML öğrenin.


1

Bence aktör modeli aday listesinde eksik.

Aktörler tarafından kastettiğim şu:

  • bağımsız varlıklar
  • ileti alan ve ileti alındığında,
  • yeni aktörler yaratmak,
  • sonraki mesaj için bazı dahili durumları güncelleyin,
  • ve mesaj gönder

Bu model deterministik Turing makinelerinin ötesinde bir şeydir ve eşzamanlı programlara bakarken gerçek dünyadaki donanımımıza daha yakındır. Ekstra (maliyetli) senkronizasyon adımları uygulamadığınız sürece, bu günlerde, kodunuz veri aldığında, bu değer aynı kalıbın diğer tarafında, belki de aynı çekirdeğin içinde değişmiş olabilir.

Kısa tartışma / giriş: http://youtube.com/watch?v=7erJ1DV_Tlo


yayınınızın okunması oldukça zordur (metin duvarı). Sakıncası var düzenleyebilir daha iyi bir şekle ing?
sivri

0

Seni doğru anlarsam, "artan soyutlamalar", çoğunlukla kodun yeniden kullanımı ile ilişkili, giderek artan büyük mantık kapsüllemeleri olarak düşünülebilir.

Birbiri ardına yürütülen özel talimatlardan , talimatların mantıksal bir gruplandırmasını tek bir öğeye çevreleyen veya özetleyen işlevlere / alt rutinlere geçiyoruz . Sonra belirli bir mantıksal varlık veya kategoriyle ilgili alt rutinleri kapsayan nesneler veya modüller var , böylece Stringsınıf altındaki tüm dize işlemlerini veya Mathmodül altındaki tüm ortak matematik işlemlerini (veya C # gibi dillerde statik sınıfı) gruplandırabilirim .

Eğer bu bizim ilerlememizse, sırada ne var? Bir sonraki adımı attığınızı sanmıyorum. Diğerlerinin yanıtladığı gibi, ilerlemeniz yalnızca zorunlu / prosedürel programlama stilleri için geçerlidir ve diğer paradigmalar soyutlama kavramlarınızı paylaşmaz. Ama eğer metaforunuzu mantıksal olarak genişletebilecek bir şey varsa, bu hizmetler .

Hizmet, işlevselliği ortaya çıkaran bir varlık olması bakımından bir sınıfa benzer, ancak endişelerinizi, kendiniz somutlaştırdığınız nesnelerle arka arkaya göre çok daha katı bir şekilde ayırmayı ima eder. Sınırlı bir işlem grubunu ortaya çıkarır, iç mantığı gizler ve aynı makinede çalışması gerekmez.

Yine, güzel bir ayrım var. Çoğu durumda, bir hizmetin proxy'si olarak işlev gören bir nesne kullanırsınız ve ikisi çok benzer olacaktır, ancak mimari olarak ikisi farklıdır.


0

Yeni soyutlama biçimleri alt düzey çalışmaları sizden gizler. Adlandırılmış yordamlar ve işlevler program adreslerini sizden gizler. Nesneler, dinamik bellek yönetimini ve bazı türe bağlı "if ifadeleri" ni gizler.

Düşük seviyeli angaryalarınızı sizden gizleyecek bir sonraki pratik soyutlamanın işlevsel reaktif programlamanın olduğunu ileri sürüyorum . Javascript'te açıkça yönetmeniz gereken geri aramaları gizleyen ve bağımlılıkları güncelleyen http://elm-lang.org/ gibi bir şeydeki "sinyallere" bakın . FRP, büyük ölçekli internet uygulamalarında ve yüksek performanslı paralellikte ihtiyaç duyulan süreçler arası ve makineler arası iletişimin karmaşıklığını gizleyebilir.

Önümüzdeki 5 yıl boyunca hepimizin heyecanlanacağı şeyin bu olduğuna eminim.


1
FRP harika, ancak oldukça spesifik bir programlama (yani reaktif programlama) ile ilgileniyor . Diğer program türlerini modellemek için pek iyi değildir. Ancak, temsil programlama daha genel sıralama - algebras-- açısından sizin kod yazmadan olan soyutlama yeni bir seviyeye için iyi bir aday.
Tikhon Jelvis

0

Set teorisi - ilişkisel veritabanlarında kısmen uygulandığı gibi, aynı zamanda SAS ve R gibi istatistik dillerinde de OO'dan farklı ama tartışmasız daha yüksek bir soyutlama seviyesi sağlar.

Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.