Apakah Anda melihat penggunaan untuk "pemrograman Spreadsheet"? [Tutup]

Beberapa waktu yang lalu saya menemukan konsep menggunakan spreadsheet (maksud saya sel dan rumus bukan kode makro) sebagai cara untuk menentukan logika pemrograman. Idenya adalah:

• buat spreadsheet dengan aliran perhitungan yang terdefinisi dengan jelas (yang terkadang lebih cocok dengan paradigma "aliran data" dari spreadsheet daripada gaya pemrograman prosedural atau berorientasi objek)

• tentukan sel input

• tentukan sel output

• mengkompilasi semuanya menjadi kelas yang dapat dieksekusi yang berdiri sendiri (atau fungsi, prosedur, ...)

• gunakan dalam kode normal dalam proyek perangkat lunak yang lebih luas

• gunakan spreadsheet sebagai kode sumber untuk dipertahankan dari waktu ke waktu

Idenya adalah untuk menggunakan teknik ini untuk masalah yang benar-benar cocok dengan model dan bahwa ini akan mengarah pada kode yang terdokumentasi dengan baik dan mudah dipelihara secara alami. Saya tertarik mengetahui apakah Anda telah berpengalaman menggunakan teknik dan untuk apa. Contoh aplikasi yang muncul di benak saya adalah kalkulator tarif asuransi, yang biasanya dirancang, dibuat dan divalidasi oleh aktuaris pada lembar Excel dan hanya kemudian dikodekan (ini adalah proses yang menyakitkan) dalam beberapa logika pemrograman yang sulit dipelihara.

Meskipun ini bukan gaya "bangun spreadsheet, kompilasi menjadi kode" yang Anda tanyakan, ekstensi dataflow Sel ke CLOS menggunakan model yang serupa: Rumus yang mengekspresikan aliran data dan transformasi menjadi representasi "sumber bahan" / " catatan "untuk desain objek / kelas. Anggap itu cara alternatif untuk membangun apa yang Anda tanyakan.

Dan hanya untuk bersenang-senang: spreadsheet makro

yang kadang-kadang lebih cocok dengan paradigma "dataflow" dari spreadsheet daripada gaya pemrograman berorientasi prosedur atau objek

Jujur, saya hampir tidak bisa memikirkan perhitungan dunia nyata mana pun ini berlaku. Pemrograman "Dataflow" dapat dengan mudah dilakukan banyak bahasa pemrograman modern (lihat LINQ di dunia .NET, atau daftar operator pemrosesan Perl dan Python), dan menurut pengalaman saya, yang menghasilkan kode yang jauh lebih dapat dikelola daripada banyak "rumus spreadsheet" dengan referensi sel yang sulit dipelihara.

Di sisi lain, saya dan rekan saya telah membuat banyak aplikasi berbasis spreadsheet (MS-Excel, tepatnya), di mana Excel digunakan baik sebagai alat yang ramah pengguna untuk memasukkan data input / membuat masker input dengan sangat cepat, atau untuk membuat output yang diformat, atau keduanya. Dalam semua kasus itu, perhitungan atau pemrosesan data itu tidak dilakukan (atau hanya sebagian dilakukan) oleh rumus Excel, tetapi oleh kode program, karena rumus Excel tidak cukup kuat atau alat yang sepenuhnya salah (dan percayalah, kami memiliki banyak pengetahuan apa yang mungkin dengan rumus Excel dan apa yang tidak).

Sejak saya membaca artikel ini, saya terus-menerus memikirkan konsep ini. Saya pikir pasti ada gunanya.

Satu hal tentang mengoptimalkan hal semacam itu, spreadsheet sangat mirip dengan ruang memori. Ini juga sangat mirip dengan ruang tampilan dan cetak (seperti dalam x, y). Banyak sekali manfaatnya di sana.

Ketika Anda mencatat pemeliharaan, itu membuka banyak ide untuk saya. Saya tidak tahu apa yang ada di luar sana untuk dikompilasi dengan benar-benar dan fitur bahasa, perpustakaan dll. Mungkin cukup menyebalkan. Tetap saja, mungkin ada masa depan di suatu tempat.

Saya benar-benar hanya menulis skrip VB untuk spreadsheet, buku angka, dan akuntansi "perangkat lunak" kebanyakan. Jangan pernah membuat aplikasi yang dapat dieksekusi dari spreadsheet apa pun kecuali antarmuka file excel dari aplikasi C ++.

Ya, namun saya menganggapnya lebih sebagai "pengujian spreadsheet" daripada "pemrograman spreadsheet". Sebagai contoh, baru-baru ini saya sedang mengerjakan fitur untuk proyek kami yang melibatkan melakukan perhitungan pada sejumlah besar catatan database. Perhitungannya relatif sederhana namun penting dan oleh karena itu perlu perhatian pengujian khusus. Selain itu, formula yang kami gunakan memerlukan sedikit adaptasi agar dapat diterapkan pada situasi kami.

Saya menjalankan beberapa perhitungan dengan tangan untuk menulis tes unit saya, sementara tester yang saya kerjakan membuat spreadsheet seperti yang Anda gambarkan untuk digunakan dalam tes ujung ke ujung. Karena adaptasi rumus sumber, kami tidak memiliki data uji independen untuk dibandingkan, oleh karena itu spreadsheet memberikan semacam cek gaya "pembukuan entri ganda" yang memberi kami keyakinan bahwa kode itu benar.

Jadi ya, saya melihat teknik ini sangat berguna sebagai sumber data uji untuk kasus-kasus di mana perhitungan yang terlibat mudah diimplementasikan dalam spreadsheet tetapi sebaliknya harus diterapkan dalam kode. Namun, spreadsheet seperti itu tidak boleh digunakan untuk "menentukan logika pemrograman" per se, tetapi hanya hasil akhir yang diperlukan.

Spreadsheet "pemrograman" adalah jenis pemrograman aliran data.

Kami memiliki masalah linguistik dengan itu, kita tidak boleh menyebutnya "pemrograman", karena jauh lebih sedikit daripada yang kita sebut pemrograman, tapi itu lebih jelas daripada memasukkan data ke suatu program.

Pemrograman dataflow adalah arsitektur dan disiplin, di mana aplikasi adalah jaringan modul independen, mereka saling mengirim pesan (data). Model ini tidak berlaku untuk setiap masalah, hanya untuk masalah, di mana ada sumber data atau aliran (atau ada lebih banyak), yang masuk ke jaringan pemrosesan, dan menghasilkan data keluaran / aliran. Lihat daftar di bawah.

Pemrograman dataflow memiliki beberapa jenis, mari kita lihat beberapa:

• Spreadsheet: nomor input diproses oleh rumus, lalu hasil angka dan grafik. Karakteristik khusus: waktu exectuion adalah "one-shot", ketika nilai input (komponen) berubah, bagian yang sesuai dari grafik pemrosesan kembali berjalan dan menghasilkan output.
• Unix pipe: shell meluncurkan beberapa program, dan menghubungkan stdout-> stdin. Karakteristik khusus: hanya penautan gaya pipa yang diizinkan, grafik adalah satu antrian.
• Eksekusi tersinkronisasi: ada jam, yang memicu pemrosesan bingkai atau sampel dalam frekuensi yang ditentukan. Setiap komponen berjalan satu kali dalam satu siklus jam. Sistem pemrosesan video dan audio contoh, mereka bekerja pada frame / sample rate yang ditentukan.
• Eksekusi asinkron: grafik dalam keadaan idle, sampai peristiwa eksternal terjadi. Kemudian memproses acara, menghasilkan beberapa output (atau tidak), dan pergi ke keadaan siaga.

Kembali ke pertanyaan Anda: Saya kira ya, sebaiknya mempublikasikan aplikasi dataflow sebagai aplikasi mandiri. Saya sudah membuatnya. Dua kali .

Saya dan teman saya telah membuat sistem DF prototipe untuk otomatisasi rumah. Kami tidak memiliki editor grafik, sehingga aplikasi tidak dapat diedit oleh pengguna, beberapa parameter disimpan dalam file konfigurasi, tetapi tidak ada yang lain. Kami memiliki bahasa skrip DF, yang "dikompilasi" ke kode C ++ (daftar pembuatan komponen dan definisi pesan), yang dikompilasi ke executable asli. Modul-modul tersebut adalah kelas C ++ (kelas lain, hanya untuk mendapatkan beberapa info tentang sistem kami: Pesan, Dispathcer, Komponen (abstrak), Port (abstrak), ConsumerPort, ProducerPort).

Selain itu, kami kagum dengan keunggulan yang diberikan sistem DF: kami telah membuat aplikasi sniffer serial dalam waktu 2 menit, atau kami telah membuat program uji di tempat , yang berkedip lampu satu-per-satu (tidak ada dokumentasi pada ID perangkat keras). Kami telah membuat komponen MIDI dan joypad hanya untuk bersenang-senang, saya juga membuat organ ringan dengannya (lihat http://homeaut.com/under_construction/ ).

Saya hanya dapat melihat satu kesulitan jika spreadsheet: karena setiap angka dan formula (berpotensi: setiap sel) adalah komponen, grafik Anda belum final. Saat Anda menambahkan baris ke aplikasi penjumlahan () sederhana Anda, itu berarti grafik aliran data diubah. Jadi, Anda harus "memprogram ulang" grafik dalam run-time, atau kita harus menyebutnya "metaprogramming". Di Excel, makro akan melakukan pekerjaan itu, tapi kemudian kami kehilangan kemurnian aliran data.

Saya punya solusi yang tidak terlalu buruk tapi tidak sempurna. Saya telah membuat spreadsheet, aplikasi AJAX dengan PHP backend. Sumbu vertikal adalah waktu (hari), garis-garisnya adalah komponen. Ada beberapa komponen, seperti input (garis dapat diedit oleh pengguna), rata-rata vertikal, rata-rata / jumlah horisontal, dan beberapa perhitungan statistik khusus domain. Hanya ada satu masalah dengan itu: ini "satu dimensi". Selama saya hanya ingin jumlah dan rata-rata dan apa pun, saya dapat menambahkan baris baru, dan membuat komponen, yang menghitung barang. Tetapi ada kendala yang kuat: kolom selalu berhari-hari (saya telah membuat "tampilan" minggu dan bulan, yang menampilkan data harian sebagai jumlah / rata-rata, tetapi masih satu dimensi). Saya tidak bisa menunjukkannya, ini kolaboratif dan membutuhkan tugas PHP backend untuk menjalankan 7/24, tidak didukung oleh penyedia host saya.

Jadi, model saya (yang dapat digambarkan sebagai: "hari secara horizontal") tidak dapat menangani masalah jenis lain.

Saya punya ide, bagaimana mengatasi masalah ini: tab .

Ketika Anda terjebak di Excel, dan harus membuat tabel lain, Anda bisa menggunakan area berbeda di tab yang sama, atau membuka tab lain. Juga, referensi antar tab tidak nyaman, saya lebih suka metode pertama. Saya pikir, tab harus ditampilkan pada layar yang sama, seperti jendela yang tidak tumpang tindih.

Setiap meja harus memiliki sumbu tumbuh: vertikal, horizontal atau tetap. Tabel pertumbuhan vertikal memiliki komponen garis (seperti spreadsheet berbasis hari saya), di mana semua kolom memiliki rumus "sama", komponen horizontal memiliki komponen kolom, tabel ukuran tetap sama seperti spreadsheet apa pun.

Jadi, ketika pengguna menambahkan baris / kolom baru, baris / kolom baru akan memiliki rumus yang sama.

Juga, dalam spreadsheet, saya benci hal itu, bahwa saya perlu menyalin rumus yang sama 1000 kali, jika saya memiliki 1000 baris. Ini sumber bug (menyimpan versi formula lama di beberapa baris), pemborosan memori (menyimpan formula yang sama 1000x).

Mungkin saya salah, dan ada bug konsep dalam model ini, tapi saya harap itu adalah pemikiran yang bagus.

Pemikiran saya adalah menggunakan spreadsheet untuk menentukan logika perhitungan dan saat melakukan ini mencoba untuk mengatur spreadsheet sedemikian rupa untuk membuatnya ramah bahasa pemrograman. Maksud saya ramah -> menggunakan rentang nama / referensi alih-alih koordinat cellXY, dan memecah rumus menjadi potongan-potongan kecil.