Apa lima hal yang Anda benci tentang bahasa favorit Anda? [Tutup]

Ada sekelompok Perl-benci di Stack Overflow belakangan ini, jadi saya pikir saya akan membawa pertanyaan " Lima hal yang Anda benci tentang bahasa favorit Anda " ke Stack Overflow. Ambil bahasa favorit Anda dan ceritakan lima hal yang Anda benci tentang itu. Itu mungkin hal-hal yang hanya mengganggu Anda, kelemahan desain yang diakui, masalah kinerja yang diakui, atau kategori lainnya. Anda hanya harus membencinya, dan itu harus menjadi bahasa favorit Anda.

Jangan membandingkannya dengan bahasa lain, dan jangan berbicara tentang bahasa yang sudah Anda benci. Jangan membicarakan hal-hal yang Anda sukai dalam bahasa favorit Anda. Saya hanya ingin mendengar hal-hal yang Anda benci tetapi menoleransi sehingga Anda dapat menggunakan semua hal lain, dan saya ingin mendengarnya tentang bahasa yang Anda harapkan akan digunakan orang lain.

Saya menanyakan hal ini setiap kali seseorang mencoba mendorong bahasa favorit mereka pada saya, dan kadang-kadang sebagai pertanyaan wawancara. Jika seseorang tidak dapat menemukan lima hal untuk dibenci tentang alat favoritnya, dia tidak tahu cukup baik untuk mengadvokasi atau menarik dolar besar menggunakannya. Dia belum menggunakannya dalam situasi yang cukup berbeda untuk sepenuhnya mengeksplorasi. Dia menganjurkannya sebagai budaya atau agama, yang berarti bahwa jika saya tidak memilih teknologi favoritnya, saya salah.

Saya tidak terlalu peduli bahasa mana yang Anda gunakan. Tidak ingin menggunakan bahasa tertentu? Kalau begitu jangan. Anda menjalani due diligence untuk membuat pilihan berdasarkan informasi dan masih tidak menggunakannya? Baik. Terkadang jawaban yang tepat adalah "Anda memiliki tim pemrograman yang kuat dengan praktik yang baik dan banyak pengalaman di Bar. Mengubah ke Foo akan menjadi bodoh."

Ini juga pertanyaan yang bagus untuk ulasan kode. Orang yang benar-benar tahu basis kode akan memiliki segala macam saran untuknya, dan mereka yang tidak mengetahuinya dengan baik akan memiliki keluhan yang tidak spesifik. Saya bertanya hal-hal seperti "Jika Anda dapat memulai kembali dari proyek ini, apa yang akan Anda lakukan secara berbeda?" Di negeri fantasi ini, pengguna dan programmer bisa mengeluh tentang apa saja dan semua yang mereka tidak suka. "Saya ingin antarmuka yang lebih baik", "Saya ingin memisahkan model dari tampilan", "Saya akan menggunakan modul ini daripada yang lain ini", "Saya akan mengganti nama rangkaian metode ini", atau apa pun yang benar-benar mereka don Saya suka tentang situasi saat ini. Begitulah cara saya memahami seberapa banyak pengembang tertentu tahu tentang basis kode. Ini juga petunjuk tentang seberapa banyak programmer

Benci bukan satu-satunya dimensi mencari tahu seberapa banyak orang tahu, tetapi saya telah menemukan itu menjadi yang cukup bagus. Hal-hal yang mereka benci juga memberi saya petunjuk seberapa baik mereka berpikir tentang subjek tersebut.

Lima hal yang saya benci tentang Jawa:

• Tidak ada fungsi kelas satu.
• Tidak ada inferensi tipe.
• Kurangnya standar waras dalam misalnya grafik.
• NullPointerException tidak mengandung informasi lebih lanjut tentang apa itu null.
• Proliferasi kerangka kerja yang tidak dapat dikonfigurasi "" / antarmuka penyedia layanan / kelas pabrik / sistem injeksi ketergantungan. Konfigurasi ini hampir tidak pernah digunakan, KERING dilanggar secara mengerikan, dan kode berukuran empat kali lipat dan separuh terbaca.

Saya tahu, saya harus memeriksa Scala.

Wow, saya terkejut bahwa SQL belum membuatnya di sini. Tebak itu berarti tidak ada yang menyukainya :)

• Sintaks yang tidak konsisten di seluruh implementasi
• Perbedaan kode yang tidak kentara dapat memiliki konsekuensi kinerja besar-besaran untuk alasan yang tampaknya tidak jelas
• Dukungan buruk untuk manipulasi teks
• Biaya masuk yang mudah tetapi kurva belajar yang curam menuju penguasaan bahasa
• Standardisasi minimal di seluruh komunitas untuk praktik terbaik, ini termasuk gaya sintaksis.

... Dan beberapa alasan bonus untuk membencinya, tanpa biaya tambahan

• klausa WHERE menjadi yang terakhir, membuatnya mudah untuk melakukan UPDATE atau DELETE sebelum waktunya, menghancurkan seluruh tabel. Sebaliknya, DI MANA harus pergi ke suatu tempat di depan.
• Sulit untuk menerapkan divisi relasional.
• Saya dapat menetapkan nilai ke NULL, tetapi saya tidak dapat mengujinya untuk kesetaraan dengan NULL. Saya dapat memeriksa IS NULL, tapi itu hanya mempersulit kode - menurut saya, tidak perlu demikian.
• Mengapa kita perlu meresepkan rumus untuk kolom yang dikelompokkan secara lengkap, daripada menetapkan alias pada kolom dan kemudian mengelompokkan berdasarkan alias (atau indeks kolom seperti dengan SORT)?

JavaScript :

1. Semua hal yang paling keren benar-benar rumit, tetapi kemudian, semua kesejukan ini juga terbungkus dalam sejumlah kecil kode sehingga Anda merasa bodoh karena berjuang untuk mengikutinya

2. '+' adalah pilihan operator yang absurd untuk penggabungan dalam bahasa yang diketik dengan lemah. Apakah mereka mencoba menakuti para noobs?

3. Ini adalah ladang ranjau kompatibilitas lintas-peramban (tidak peduli apakah itu dihidupkan atau tidak)

4. Ini umumnya tidak dipercaya - terkait dengan scummery seperti memblokir tombol kembali, pop-up yang tidak pernah mati, dll.

5. Hampir tidak mungkin untuk debug karena hanya ada beberapa pesan kesalahan yang berbeda dan beberapa jenis yang berbeda (Nomor, String, Objek, dll.)

Jika bukan karena jQuery, saya mungkin masih akan membencinya seperti dulu :)

PHP:

1) Memaksa saya untuk membuat variabel yang tidak perlu:

$parts = explode('|', $string);
$first = $parts[0];

2) Implementasi lambdas jadi lumpuh itu kira-kira setara dengan menggunakan eval()dan sangat salah saya tidak pernah menggunakannya (lihat http://www.php.net/create_function ).

3) Sistem coba / tangkap yang hanya dapat menangkap sekitar 80% kesalahan yang mungkin terjadi.

4) Dukungan Regex sama lemahnya dengan dukungan lambda karena harus ditulis dalam string biasa, membuat salah satu alat pemrograman yang paling sulit dipelajari sekitar tiga kali lebih sulit. Dan PHP seharusnya menjadi bahasa "mudah"?!?!?

5) Tidak ada cara untuk menarik barang dengan aman dari $ _POST tanpa menulisnya dua kali atau membangun fungsi Anda sendiri, atau menggunakan operator '@':

$x = isset($_POST['foo']['bar']) ? $_POST['foo']['bar'] : null;

6) Jawaban bonus: '@'. Jika Anda tidak dapat repot menulis kode dengan benar, cukup tambahkan '@', dan sangat buruk bagi siapa pun yang harus men-debug kode Anda nanti.

C ++

• Terlalu mudah untuk merusak memori secara acak dan membuat bug yang hampir mustahil ditemukan (walaupun, Valgrind berupaya keras untuk memperbaikinya).
• Pesan kesalahan templat.
• Saat menggunakan templat, mudah untuk akhirnya harus memasukkan semuanya dalam satu file, dan kemudian mendapatkan waktu kompilasi yang bodoh.
• Perpustakaan standar adalah lelucon di zaman modern (masih ada utas atau jaringan secara default?)
• Banyak bit C jahat yang mengintip (khususnya, semua konversi antara short / int / unsigned / dll.)

C # / .NET:

• Kelas harus disegel secara default
• Seharusnya tidak ada lockpernyataan - sebagai gantinya, Anda harus memiliki objek penguncian tertentu, dan harus ada metode seperti Acquireyang mengembalikan token kunci sekali pakai. Konsekuensi: seharusnya tidak ada monitor untuk setiap objek.
• GetHashCode()dan Equals()tidak boleh di System.Object- tidak semuanya cocok untuk hashing. Sebaliknya, memiliki IdentityCompareryang melakukan hal yang sama, dan menjaga IComparer<T>, IComparable<T>, IEqualityComparer<T>dan IEquatable<T>antarmuka untuk perbandingan kustom.
• Dukungan yang buruk untuk kekekalan
• Cara yang buruk untuk menemukan metode ekstensi - itu harus menjadi keputusan yang jauh lebih sadar daripada fakta bahwa saya menggunakan namespace.

Itu dari atas kepala saya - tanyakan saya besok dan saya akan datang dengan 5 yang berbeda :)

C

• manipulasi string.

Harus berurusan secara manual dengan buffer string adalah rasa sakit yang rawan kesalahan. Karena begitu banyak komputasi yang benar-benar bergerak dan memodifikasi string (komputer tidak cukup banyak digunakan untuk hal-hal yang berderak angka besar seperti yang orang pikir mereka akan kembali ketika), sangat bagus untuk dapat menggunakan bahasa yang dikelola atau string C ++. objek untuk berurusan dengan ini. Ketika saya harus melakukannya dalam C lurus, rasanya seperti berenang di pasir apung.

Bagaimana dengan lima hal yang saya benci dari daftar "Hal yang saya benci tentang beberapa bahasa"? : D

5- Melukis merah oranye tidak membuatnya menjadi apel.

Ketika suatu bahasa dirancang, para desainer biasanya memikirkan apa manfaatnya. Menggunakannya untuk sesuatu yang sama sekali berbeda bisa berhasil, tetapi mengeluh ketika itu tidak bodoh. Ambil Python. Saya yakin seseorang memiliki atau seseorang suatu hari nanti akan membuat utilitas untuk membuat exe dari kode Python. Mengapa di bumi Tuhan Anda inginkan melakukan itu? Itu akan rapi — jangan salah paham — tetapi tidak ada gunanya. Jadi berhentilah mengeluh tentang hal itu!

Proyek yang dirancang dengan baik kemungkinan akan berisi kode dari berbagai bahasa. Itu tidak berarti Anda tidak dapat menyelesaikan proyek dengan hanya satu bahasa. Beberapa proyek mungkin baik dalam kemampuan bahasa apa pun yang Anda gunakan.

4 - Apakah Anda berdiri di atas kaki kayu?

Platform bisa menjadi pengaruh besar dari apa yang bisa dilakukan oleh bahasa. Dengan pengumpul sampah saat ini, atau bahkan pascals upaya awal pada "pengumpulan sampah", dapat membantu dalam memori memudar (mungkin malloc lebih banyak ram ??). Komputer lebih cepat dan tentu saja, kami berharap lebih banyak dari bahasa kami. Dan sejujurnya, kita mungkin harus. Namun, ada harga yang sangat besar untuk membayar kenyamanan kompiler untuk membuat tabel hash atau string atau berbagai konsep lainnya. Hal-hal ini mungkin tidak diwariskan ke platform tempat mereka digunakan. Untuk mengatakan mereka mudah dimasukkan ke bahasa hanya memberitahu saya Anda mungkin tidak memiliki kaki untuk berdiri.

3- Kesalahan siapa ini?

Bug. Kamu tahu. Saya suka serangga. Mengapa saya suka bug. Karena itu berarti saya dapat mempertahankan pekerjaan saya. Tanpa bug, akan ada banyak toko pizza tertutup. Namun, pengguna membenci bug. Tapi di sini ada sedikit air dingin. Setiap bug adalah kesalahan pemrogram. Bukan bahasa. Bahasa dengan sintaks yang ketat yang secara signifikan akan mengurangi berapa banyak bug yang mungkin dihasilkan akan menjadi bahasa yang sama sekali tidak berguna. Kemampuannya mungkin bisa dihitung dengan satu tangan. Anda ingin fleksibilitas atau kekuatan? Anda punya bug. Mengapa? Karena Anda tidak sempurna, dan Anda membuat kesalahan. Ambil contoh yang benar-benar dapat diidentifikasi di C:

int a[10];
for (int idx = 0; idx < 15; idx++) a[idx] = 10;

Kita semua tahu apa yang akan dilakukan. Namun, apa yang mungkin sebagian dari kita tidak sadari adalah .. bahwa fungsionalitas dapat sangat bermanfaat. Tergantung apa yang kamu lakukan. Buffer overruns adalah biaya fungsionalitas itu. Kode itu di atas. Jika saya benar-benar merilisnya ke publik. Itu lagi .. katakan dengan saya .. "Salahku". Bukan C karena mengizinkan saya melakukannya.

2 - Bukankah seharusnya kita meletakkan itu di tempat sampah?

Sangat mudah untuk menunjuk fitur dalam bahasa yang tidak kita mengerti karena kita tidak sering menggunakannya dan menyebutnya bodoh. Mengeluh bahwa itu ada di sana, dll. Goto selalu menghibur saya. Orang-orang selalu mengeluh tentang keberadaan goto dalam bahasa. Namun saya yakin program terakhir Anda termasuk jenis goto. Jika Anda pernah menggunakan istirahat atau melanjutkan, Anda telah menggunakan goto. Itu apa adanya. Memang, itu adalah goto "aman", tetapi memang demikianlah adanya. Goto memiliki kegunaannya. Apakah goto "implisit" seperti melanjutkan atau menghancurkan digunakan atau gotos eksplisit (menggunakan kata kunci "goto" yang sebenarnya untuk bahasa apa pun). Bukan berarti pengembang bahasa sempurna, tetapi biasanya ... jika fungsionalitas telah ada sejak awal waktu (untuk bahasa itu). Kemungkinan aspek itu adalah kualitas yang menentukan bahasa itu. Berarti .. itu Sedang digunakan dan kemungkinan tidak berkeliaran karena kompatibilitas ke belakang. Ini digunakan hari ini. Seperti 5 menit yang lalu. Dan digunakan dengan benar. Yah .. bisa dibilang seseorang menggunakannya dengan tidak benar, tetapi itu berhubungan dengan # 3 dalam daftar saya.

1. - Semuanya adalah objek.

Oke .. ini benar-benar bagian dari # 2. Namun sejauh ini ini adalah keluhan paling menyebalkan yang saya lihat dalam daftar kebencian. Tidak semuanya adalah objek. Ada banyak sekali konsep yang tidak termasuk atau perlu menjadi objek. Menempatkan barang-barang di tempat yang bukan milik mereka hanya jelek dan dapat mengurangi efisiensi suatu program. Tentu. Mungkin tidak banyak tergantung pada bahasanya. Ini juga berhubungan dengan # 5. Ini berarti ... ya. Global tidak masalah. Fungsi seperti metode statis seharusnya ok. Menggabungkan pemrograman OO dengan fungsi global tidak masalah. Sekarang .. itu tidak berarti kita semua harus keluar dan "membebaskan" kode kita dari model objek itu juga. Saat mendesain bagian kode atau keseluruhan proyek, apa yang terjadi di balik layar harusdipertimbangkan saat menyusunnya. Bukan hanya di mana konsep itu hidup dan banyak faktor lainnya. Mengapa membungkus fungsi global dalam kelas atau konsep ruang nama jika tidak ada gunanya? Ambil variabel anggota statis. Itu sangat menghibur saya karena .. well..Tergantung pada bahasa dan implementasi tentu saja, tetapi secara umum, Anda baru saja menyatakan global. Ya, ada beberapa alasan untuk membungkus konsep non-OO ini dalam pembungkus OO. Salah satunya tentu saja mendokumentasikan kode diri. Itu bisa masuk akal. Jadi .. seperti yang saya katakan. Jangan keluar dan "bebaskan" kode Anda. Tetapi setiap bahasa modern yang bagus akan memiliki konsep global di luar pemodelan OO itu. Ya saya secara khusus bermaksud menunjukkan bahwa bahasa pemrograman OO tanpa konsep global kemungkinan besar memiliki cacat desain yang serius. Sekali lagi .. tergantung pada niat dan desain bahasa jadi saya tidak mencoba untuk memilih bahasa tertentu dan ada terlalu banyak untuk dianalisis di sini. Siapa pun, Pertimbangkan di mana kode itu harus hidup dan menjadi yang paling efektif. Menambahkan sekelompok suar ke sesuatu yang tidak menambah fungsionalitas atau dukungan hanya mengurangi keyboard lebih cepat. Tidak ada gunanya bagi siapa pun. Yah .. kecuali Anda suka poin brownies dari orang yang mungkin salah mengajari Anda bahwa semuanya adalah objek.

Singkatnya, pemrograman tidak hanya mengetuk keyboard tanpa berpikir. Ada banyak pertimbangan desain untuk proyek apa pun. Saya tahu ini klise, tetapi Anda harus melihatnya dari setiap sudut. Bahkan dengan jenis bahasa yang aman saat ini. Anda tidak hanya membuang kode dan mengharapkannya berfungsi dengan baik. Tentu .. ini mungkin berhasil, tetapi mungkin bukan cara yang tepat untuk melakukannya. Secara keseluruhan, pilih bahasa dan format yang paling cocok untuk pekerjaan tertentu DAN lingkungan. Tetapi tidak ada bahasa yang menghilangkan pemikiran di baliknya. Jika Anda tidak berpikir .. Anda hanya mengetik.

Lima hal yang saya benci tentang Jawa (yang, saat ini, adalah bahasa favorit saya) tanpa urutan tertentu.

1. Sebanyak saya penggemar Java Generics, ada banyak keanehan yang muncul dari cara itu dirancang. Karena itu ada banyak keterbatasan menjengkelkan dengan obat generik (beberapa di antaranya adalah hasil dari penghapusan tipe).
2. Cara Object.clone () dan antarmuka Cloneable bekerja benar-benar rusak.
3. Alih-alih mengambil jalan-tinggi dan menjadikan segala sesuatu objek (mis. SmallTalk), Sun malah menciptakan dua kategori tipe data yang berbeda: Objek dan primitif. Akibatnya sekarang ada dua representasi untuk tipe data fundamental dan keingintahuan aneh seperti tinju / unboxing dan tidak bisa menempatkan primitif dalam Koleksi.
4. Ayunan terlalu rumit. Jangan salah paham: ada banyak hal keren yang bisa dilakukan dengan Swing tetapi ini adalah contoh bagus dari rekayasa berlebihan.
5. Keluhan terakhir ini sama-sama karena kesalahan Sun dan mereka yang telah menulis pustaka XML untuk Jawa. Perpustakaan XML Java terlalu rumit. Untuk sekadar membaca dalam file XML, saya sering harus khawatir tentang parser apa yang saya gunakan: DOM atau SAX? API untuk masing-masing sama-sama membingungkan. Dukungan asli dalam bahasa untuk dengan mudah parsing / menulis XML akan sangat bagus.
6. java.util.Date menyebalkan. Tidak hanya rumit tetapi tidak perlu, tetapi semua metode yang berguna telah usang (dan diganti dengan yang lain yang menambah kompleksitas).

Ruby memiliki banyak kekurangan terkait dengan kecepatannya, tetapi saya tidak membencinya. Ini juga memiliki kekurangan dengan penginjilan komunitas yang berlebihan, tetapi itu tidak terlalu mengganggu saya. Inilah yang saya benci:

• Penutupan (blok) memiliki 4 sintaks pembuatan yang berbeda, dan tidak ada satupun yang optimal. Sintaks elegan tidak lengkap dan ambigu dengan hash, dan sintaksis lengkap jelek.
• Komunitas cenderung menentang dokumentasi nyata, lebih suka 'membaca kode'. Saya menemukan ini kekanak-kanakan dan malas.
• Memprogram penyalahgunaan program, khususnya di perpustakaan, membuat bug mimpi buruk untuk dilacak.
• Pada catatan terkait, metaprogramming meresap membuat IDE komprehensif sulit, jika bukan tidak mungkin, untuk membuat.

• Cara block passing ke fungsi dilakukan konyol. Tidak ada alasan blok harus dilewatkan di luar daftar parameter, atau memiliki sintaks khusus ganjil untuk mengakses (menghasilkan). Saya berpendapat bahwa blok seharusnya diberi sintaks yang kurang ambigu (atau hash bisa menggunakan pembatas yang berbeda; mungkin <> daripada {}), dan meneruskan sebagai parameter untuk metode seharusnya sama seperti semua parameter lainnya.

  object.method(1, {|a| a.bar}, "blah")
  

  Keanehan ini, seperti blok harus menjadi parameter terakhir yang dilewati dan melewati lebih dari satu blok berbeda dengan sintaks yang lebih lama, benar-benar mengganggu saya.

Perl

• Penggunaan campuran sigils

  my @array = ( 1, 2, 3 );
  my $array = [ 4, 5, 6 ];
  
  my $one  = $array[0]; # not @array[0], you would get the length instead
  my $four = $array->[0]; # definitely not $array[0]
  
  my( $two,  $three ) = @array[1,2];
  my( $five, $six   ) = @$array[1,2]; # coerce to array first
  
  my $length_a = @array;
  my $length_s = @$array;
  
  my $ref_a = \@array;
  my $ref_s = $array;
  

  • Misalnya tidak ada yang sama:

    $array[0]   # First element of @array
    @array[0]   # Slice of only the First element of @array
    %array[0]   # Syntax error
    $array->[0] # First element of an array referenced by $array
    @array->[0] # Deprecated first element of @array
    %array->[0] # Invalid reference
    $array{0}   # Element of %array referenced by string '0'
    @array{0}   # Slice of only one element of %array referenced by string '0'
    %array{0}   # Syntax error
    $array->{0} # Element of a hash referenced by $array
    @array->{0} # Invalid reference
    %array->{0} # Deprecated Element of %array referenced by string '0'
    

  Di Perl6dalamnya tertulis :

  my @array = ( 1, 2, 3 );
  my $array = [ 4, 5, 6 ];
  
  my $one  = @array[0];
  my $four = $array[0]; # $array.[0]
  
  my( $two,  $three ) = @array[1,2];
  my( $five, $six   ) = $array[1,2];
  
  my $length_a = @array.length;
  my $length_s = $array.length;
  
  my $ref_a = @array;
  my $ref_s = $array;
  

• Kurangnya OO sejati

  package my_object;
  # fake constructor
  sub new{ bless {}, $_[0] }
  # fake properties/attributes
  sub var_a{
    my $self = shift @_;
    $self->{'var_a'} = $_[0] if @_;
    $self->{'var_a'}
  }
  

  Di Perl6dalamnya tertulis :

  class Dog is Mammal {
      has $.name = "fido";
      has $.tail is rw;
      has @.legs;
      has $!brain;
      method doit ($a, $b, $c) { ... }
      ...
  }
  

• Fitur regex yang didesain dengan buruk

  /(?=regexp)/;           # look ahead
  /(?<=fixed-regexp)/;    # look behind
  /(?!regexp)/;           # negative look ahead
  /(?<!fixed-regexp)/;    # negative look behind
  /(?>regexp)/;           # independent sub expression
  /(capture)/;            # simple capture
  /(?:don't capture)/;    # non-capturing group
  /(?<name>regexp)/;      # named capture
  /[A-Z]/;                # character class
  /[^A-Z]/;               # inverted character class
  # '-' would have to be the first or last element in
  # the character class to include it in the match
  # without escaping it
  /(?(condition)yes-regexp)/;
  /(?(condition)yes-regexp|no-regexp)/;
  /\b\s*\b/;              # almost matches Perl6's <ws>
  /(?{ print "hi\n" })/;  # run perl code
  

  Di Perl6dalamnya tertulis :

  / <?before pattern>  /;   # lookahead
  / <?after pattern>   /;   # lookbehind
  / regexp :: pattern  /;   # backtracking control
  / ( capture )        /;   # simple capture
  / $<name>=[ regexp ] /;   # named capture
  / [ don't capture ]  /;   # non-capturing group
  / <[A..Z]>           /;   # character class
  / <-[A..Z]>          /;   # inverted character class
  # you don't generally use '.' in a character class anyway
  / <ws>               /;   # Smart whitespace match
  / { say 'hi' }       /;   # run perl code
  

• Kurangnya beberapa pengiriman

  sub f(   int $i ){ ... }  # err
  sub f( float $i ){ ... }  # err
  sub f($){ ... } # occasionally useful
  

  Di Perl6dalamnya tertulis :

  multi sub f( int $i ){ ... }
  multi sub f( num $i ){ ... }
  multi sub f( $i where $i == 0 ){ ... }
  multi sub f(     $i ){ ... } # everything else
  

• Operator kelebihan muatan

  package my_object;
  use overload
    '+' => \&add,
    ...
  ;
  

  Di Perl6dalamnya tertulis :

  multi sub infix:<+> (Us $us, Them $them) |
                      (Them $them, Us $us) { ... }
  

Saya akan melakukan PHP sesuka saya dan Python akan dilakukan terlalu banyak.

• Tidak ada namespace; semuanya ada dalam semacam namespace yang sangat besar yang merupakan neraka di lingkungan yang lebih besar

• Kurangnya standar ketika datang ke fungsi: fungsi array mengambil jarum sebagai argumen pertama, tumpukan jerami sebagai argumen kedua (lihat array_search ). Fungsi string sering mengambil tumpukan jerami pertama, jarum kedua (lihat tegap ). Fungsi lain hanya menggunakan skema penamaan yang berbeda: bin2hex , strtolower , cal_to_jd

  Beberapa fungsi memiliki nilai pengembalian yang aneh, dari apa yang normal: Ini memaksa Anda untuk memiliki variabel ketiga yang dideklarasikan entah dari mana sementara PHP dapat secara efisien menafsirkan array kosong sebagai false dengan jenis jugglingnya. Hampir tidak ada fungsi lain yang melakukan hal yang sama.

  $var = preg_match_all('/regexp/', $str, $ret);
  echo $var; //outputs the number of matches 
  print_r($ret); //outputs the matches as an array
  

• Bahasa (hingga PHP6) melakukan yang terbaik untuk menghormati kompatibilitas mundur yang hampir terbelakang, menjadikannya membawa praktik dan fungsi buruk saat tidak diperlukan (lihat mysql_escape_string vs. mysql_real_escape_string ).

• Bahasa berkembang dari bahasa templating ke full-backend. Ini berarti siapa pun dapat mengeluarkan apa pun saat mereka mau, dan itu akan disalahgunakan. Anda berakhir dengan mesin templat untuk bahasa templating ...

• Mengisap mengimpor file. Anda memiliki 4 cara berbeda untuk melakukannya (termasuk, include_once, butuhkan, require_once), semuanya lambat, sangat lambat. Bahkan seluruh bahasanya lambat. Setidaknya, lebih lambat dari python (bahkan dengan kerangka kerja) dan RoR dari apa yang saya kumpulkan.

Saya masih suka PHP. Ini adalah gergaji pengembangan web: Anda ingin situs kecil hingga sedang dilakukan dengan sangat cepat dan pastikan siapa pun dapat meng-host-nya (walaupun konfigurasi mungkin berbeda)? PHP ada di sana, dan itu sangat umum di mana hanya membutuhkan 5 menit untuk menginstal tumpukan LAMP atau WAMP penuh. Yah, aku akan kembali bekerja dengan Python sekarang ...

Berikut adalah beberapa hal yang saya sukai tentang Jawa (yang bukan bahasa favorit saya):

• Penghapusan tipe generik (yaitu tidak ada generik terverifikasi)
• Ketidakmampuan untuk menangkap beberapa pengecualian (dari jenis yang berbeda) dalam satu blok tangkap
• Kurangnya destruktor (finalisasi () adalah pengganti yang sangat buruk)
• Tidak ada dukungan untuk fungsi penutupan atau memperlakukan sebagai data (kelas batin anonim adalah pengganti yang sangat bertele-tele)
• Pengecualian yang diperiksa secara umum, atau lebih khusus, membuat pengecualian yang tidak dapat dipulihkan diperiksa (mis. SQLException)
• Tidak ada dukungan tingkat bahasa untuk koleksi literal
• Tidak ada inferensi tipe ketika konstruktor dari kelas generik dipanggil, yaitu parameter tipe harus diulangi di kedua sisi '='

C ++

1. Sintaks Templat
2. Masalah Warisan Berlian
3. Banyaknya / kurangnya perpustakaan standar yang dimiliki bahasa modern (meskipun dorongan sudah dekat).
4. IOS mengalir
5. Sintaks yang digunakan di sekitar IOStreams

Python

1. Spasi bermakna (kadang-kadang)
2. kata kunci yang digarisbawahi
3. Dukungan utas terbatas (setidaknya saat ini)
4. "diri" bukannya "ini"
5. Spasi bermakna (kadang-kadang)

Objektif-C

1) Tidak ada ruang nama, hanya konvensi penamaan manual - Saya tidak keberatan dengan itu dalam hal pemisahan kelas, tapi saya rindu untuk dapat mengimpor semua definisi kelas dalam namespace dalam satu baris (seperti import com.me.somelibrary. *).

2) Perpustakaan masih memiliki beberapa lubang di area penting seperti dukungan RegEx.

3) Properti sintaksis agak canggung, membutuhkan tiga baris (dalam dua file terpisah) untuk mendeklarasikan properti.

4) Saya suka model retain / release, tetapi lebih mudah daripada seharusnya untuk merilis referensi dan kemudian secara tidak sengaja memanfaatkannya nanti.

5) Meskipun sebenarnya bukan fitur bahasa, Xcode sangat terkait dengan penggunaan Objective-C Saya tidak bisa tidak memikirkan aspek itu ... pada dasarnya pelengkapan otomatis, sangat rapuh. Ini lebih seperti sebuah sistem yang memberi penghargaan kepada Anda untuk menemukan sesuatu yang Anda inginkan ada, dan kemudian menyajikannya sebagai pilihan sesudahnya. Tapi saya rasa saya tidak pernah menyukai mesin autocomplete.

C ++

• String.
  Mereka tidak dapat dioperasikan dengan string platform, jadi Anda akhirnya menggunakan std :: vector setengah waktu. Kebijakan salin (salin saat menulis atau salinan dalam) tidak ditentukan, sehingga jaminan kinerja tidak dapat diberikan untuk sintaks langsung. Terkadang mereka bergantung pada algoritma STL yang tidak terlalu intuitif untuk digunakan. Terlalu banyak perpustakaan menggulung sendiri yang sayangnya jauh lebih nyaman untuk digunakan. Kecuali jika Anda harus menggabungkannya.

• Berbagai representasi string
  Sekarang, ini sedikit masalah platform - tapi saya masih berharap akan lebih baik ketika kelas string standar yang tidak terlalu keras kepala akan tersedia sebelumnya. Representasi string berikut yang sering saya gunakan:

  • LPCTSTR generik,
  • LPC (W) STR yang dialokasikan oleh CoTaskMemAlloc,
  • BSTR, _bstr _t
  • (w) string,
  • CString,
  • std :: vektor
  • roll-my-own class ( sigh ) yang menambahkan pemeriksaan jangkauan dan operasi dasar ke (w) char * buffer yang diketahui panjangnya

• Membangun model.
  Saya muak sampai mati dari semua waktu yang dihabiskan untuk berkeliaran dengan siapa-termasuk-apa, deklarasi maju, mengoptimalkan header yang sudah dikompilasi dan termasuk untuk menjaga setidaknya peningkatan waktu membangun tertahankan, dll. Itu hebat di tahun delapan puluhan, tapi sekarang? Ada begitu banyak rintangan untuk mengemas sepotong kode sehingga dapat digunakan kembali sehingga bahkan anjing ibu pun bosan mendengarkan saya.

• Sulit untuk diuraikan
  Ini membuat alat eksternal sangat sulit untuk ditulis, dan diperbaiki. Dan hari ini, kami para C ++ kurang banyak dalam rantai alat. Saya suka refleksi dan delegasi C # saya, tetapi saya bisa hidup tanpanya. Tanpa refactoring yang bagus, saya tidak bisa.

• Threading terlalu sulit
  Bahasa bahkan tidak mengenalinya (sekarang), dan kebebasan dari kompiler - meskipun hebat - adalah menyakitkan.

• Inisialisasi statis dan sesuai permintaan Secara teknis, saya menipu di sini: ini adalah potongan puzzle lain dalam "bungkus kode untuk digunakan kembali": Adalah mimpi buruk untuk mendapatkan sesuatu yang diinisialisasi hanya ketika diperlukan. Solusi terbaik untuk semua masalah redist lainnya adalah melemparkan semuanya ke header, masalah ini mengatakan "neeener - Anda tidak bisa".

Memang, banyak yang di luar ruang lingkup bahasa yang ketat, tetapi IMO seluruh toolchain perlu dinilai dan perlu berkembang.

JavaScript :

• The Objectprototipe dapat dimodifikasi. Setiap objek tunggal dalam program Anda mendapatkan properti baru, dan sesuatu mungkin rusak.

• Semua objek adalah peta hash, tetapi sulit untuk menggunakannya dengan aman. Khususnya, jika salah satu kunci Anda kebetulan berada __proto__, Anda dalam masalah.

• Tidak ada penutupan objek pada waktu referensi fungsi. Bahkan, tidak ada penutupan objek sama sekali - sebaliknya, thisdiatur setiap kali suatu fungsi dipanggil dengan notasi objek atau newoperator. Menghasilkan banyak kebingungan, terutama ketika membuat event callback, karena thistidak diatur ke apa yang diharapkan oleh programmer.

  • Konsekuensi: memanggil suatu fungsi tanpa notasi objek atau newhasil operator thisdisetel sama dengan objek global, menghasilkan banyak kerusakan.

• Operator tambahan kelebihan beban juga melakukan penggabungan string, meskipun kedua operasi secara fundamental berbeda. Menghasilkan rasa sakit ketika nilai yang Anda harapkan menjadi angka sebenarnya adalah string.

• ==dan !=operator melakukan pemaksaan tipe. Perbandingan antara berbagai jenis melibatkan daftar aturan yang tidak dapat diingat oleh manusia secara penuh. Ini dimitigasi oleh keberadaan ===dan !==operator.

• Keduanya nulldan undefinedada, dengan makna yang agak berbeda, namun berlebihan. Mengapa?

• Sintaks aneh untuk mengatur rantai prototipe.

• parseInt(s)mengharapkan nomor gaya-C, jadi perlakukan nilai dengan angka nol di depan sebagai oktal, dll. Anda setidaknya bisa parseInt(s, 10)tetapi perilaku defaultnya membingungkan.

• Tidak ada ruang lingkup blok.

• Dapat mendeklarasikan variabel yang sama lebih dari sekali.

• Dapat menggunakan variabel tanpa mendeklarasikannya, dalam hal ini bersifat global dan mungkin merusak program Anda.

• with { }.

• Sangat sulit untuk didokumentasikan dengan alat seperti JavaDoc.

Python:

• Kurang mengetik statis
• Penanganan argumen default (khususnya fakta bahwa Anda dapat mengubah argumen default untuk penelepon berikutnya!)
• Terlalu banyak garis bawah yang diperlukan (konstruktor harus dipanggil __init__ )
• Kurangnya anggota dan fungsi pribadi yang layak (konvensi hanya mengatakan bahwa sebagian besar hal yang dimulai dengan garis bawah bersifat pribadi, kecuali untuk semua hal seperti __getattr__ itu tidak)
• Sintaks lucu untuk printmemasukkan file (tetapi mereka memperbaikinya dengan Python 3)

C #

• Saya berharap saya bisa switch()pada tipe apa pun, dan itu casebisa berupa ekspresi apa pun.

• Tidak dapat menggunakan sintaks penginisialisasi objek dengan bidang / private setreadoply / autoprops. Secara umum, saya ingin bantuan bahasa untuk membuat jenis yang tidak dapat diubah.

• Penggunaan {}untuk namespace dan kelas dan metode dan blok properti / pengindeks dan blok multi-pernyataan dan inisialisasi array . Membuatnya sulit untuk mengetahui di mana Anda berada saat mereka berjauhan atau tidak cocok.

• Saya benci menulis (from x in y ... select).Z(). Saya tidak ingin harus kembali ke sintaks pemanggilan metode karena sintaks kueri melewatkan sesuatu.

• Saya ingin doklausa pada sintaks kueri, yang seperti foreach. Tapi itu sebenarnya bukan permintaan.

Saya benar-benar mencapai di sini. Saya pikir C # luar biasa, dan sulit untuk menemukan banyak yang rusak.

PHP

1. Tidak ada fitur debugging jika Anda tidak mengontrol server, dan bahkan kemudian mereka agak payah
2. Jumlah ekstrim dari kode PHP buruk yang mengambang memberi semua programmer PHP nama yang buruk
3. Penamaan fungsi yang tidak konsisten
4. Ketidakmampuan untuk memiliki variabel yang diketik statis jika saya mau (saya penggemar dinamis mengetik 90% dari waktu)
5. REGISTER_GLOBALS adalah iblis

C (OK, itu bukan favorit saya, tapi belum selesai.)

• Sintaks perpustakaan socket.
• Tidak ada fungsi yang berlebihan.
• String C-style.
• Buffer overruns.
• Sintaksis samar. Saya tidak tahu berapa kali saya mencari hal-hal seperti atoi, menampar dahi saya, dan berteriak, "Tentu saja!"

EDIT: Saya mungkin bisa menghasilkan lebih banyak jika saya menggunakan lebih banyak kode perpustakaan (seperti yang saya lakukan dengan soket, tetapi itu sangat buruk), tapi saya sudah merasa seperti saya selingkuh karena memilih C. Jadi, ada banyak bahasa hanya untuk mengambil bagian yang baik dari C dan ganti yang buruk itu seperti memukuli kuda mati.

Gangguan Umum:

1. Kata kunci seringkali terlalu bertele-tele.
2. Dukungan perpustakaan sangat menyedihkan.
3. Tidak berfungsi dengan baik di OS yang ingin menangani memori lebih ketat.
4. Tidak memiliki fasilitas yang baik untuk berinteraksi dengan OS.
5. Fasilitas "loop" tidak didefinisikan dengan baik, dan tentu saja tidak terlihat seperti Lispy.

BrainF * ck

• Puncak Anda adalah bahwa Anda sedang menyelesaikan Turing ?! Saya dapat melakukan lebih banyak dalam ekspresi reguler Perl!

• Kekurangan benda. Ayo, teman-teman! Itu seperti, halo ...

• Tidak ada perpustakaan jaringan. Yang saya inginkan adalah mengikis halaman web, GOSH.

• Tidak ada fungsi kelas satu. Selamat - Anda bisa bersimpati dengan teman-teman Java Anda.

• Pita tanpa batas untuk penyimpanan dan tidak ada yang lain. Ini sangat anal megah sehingga kami mungkin juga menulis Lisp.

JavaScript

1. angka sebagai string - Matematika bisa membuat frustasi ketika angka diinterpretasikan sebagai string. 5 + 2 = 52? Grrr ...
2. izin - semua hal terbaik memerlukan izin dari pengguna!
3. pembaruan layar - Browser harus dalam kondisi mantap untuk memperbarui layar. Sepertinya tidak ada cara untuk memaksa layar untuk memperbarui di tengah skrip.
4. Lambat - meskipun Google Chrome bagus ...
5. Perbedaan browser membuat penggunaan bahasa [disensor].

PHP:

• Seseorang tidak pernah dapat memastikan bahwa ekstensi hampir umum tertentu tersedia di semua webserver.
• mencoba menjadi segalanya di masa depan (kebohongan, penutupan, ...)
• banyak risiko keamanan untuk pengguna yang tidak berpengalaman
• lebih banyak operator kelebihan akan menyenangkan
• semua programmer miskin yang tidak belajar bagaimana membuatnya bekerja dengan baik, dan berikan nama yang buruk

Namun demikian PHP adalah bahasa (scripting). ;-)

VB6

1. Hanya untuk Windows.
2. Tidak lagi didukung.
3. Array dapat dimulai dari angka berapa saja, kemudian semua dinormalisasi ke 0.
4. aplikasi yang dikompilasi tergantung pada banyak dll untuk berjalan dengan baik.
5. Banyak kontrol rumit seperti kontrol browser atau potongan kode yang rumit cenderung merusak IDE ketika Anda menjalankan kode yang tidak dikompilasi, tetapi berfungsi dengan baik ketika dikompilasi.

Ruby adalah bahasa favorit saya, inilah yang saya tidak suka:

• Utas hijau + memblokir C perpustakaan = raksasa gagal
• BEGITU LAMBAT
• Perpustakaan standar itu sendiri tidak konsisten dengan penggunaan bang! metode
• Modul termasuk + ekstensi berantakan.
• "Kelas Terbuka" tidak dapat dicakup - Saya ingin menambahkan String # dostuff, tapi saya tidak ingin itu bocor ke semua perpustakaan pihak ketiga
• Tidak ada solusi pengemasan penyebaran biner.

Delphi:

• IDE agak tidak stabil.
• Wawasan kode terkadang membingungkan.
• Debugging terkadang buggy.
• Memperbarui beberapa file proyek bisa jadi merepotkan.
• Jika memulai ketika satu atau lebih paket tidak tersedia, pesan kesalahan muncul beberapa kali.

JavaScript

• Setiap skrip dieksekusi dalam 'namespace' global tunggal ... sesuatu yang harus Anda perhatikan ketika bekerja dengan skrip dari berbagai sumber

• Jika variabel digunakan tetapi belum didefinisikan sebelumnya, itu dianggap sebagai variabel global

• Vendor peramban membuat standar sesuka mereka, membuat pengkodean bagi kami pengembang menggunakan bahasa yang begitu indah lebih sulit dari yang seharusnya

• Case-Sensitivity - mengingat tidak ada IDE yang layak untuk mengembangkan js dengan pengecekan waktu kompilasi

• Penanganan masalah (seperti penggunaan hasOwnPropertymetode) untuk melakukan beberapa operasi sederhana.

Haskell:

1. Ruang bocor dari evaluasi malas.
2. Hirarki Numerik tidak dikonstruksikan berkenaan dengan abstraksi matematika.
3. IO monadik yang ketat dapat mempersulit proses debug.
4. Implementasi besar menangani I / O dengan cara yang tampaknya tidak cukup kompatibel dengan standar. (Khususnya, mengeluarkan karakter hanya menghasilkan bit 8 yang rendah - dan kemudian kode dibangun yang menggunakan asumsi ini untuk melakukan biner I / O. Ick.)
5. Asosiasi ($)operator dapat diubah untuk membuat beberapa ekspresi lebih cantik.

Sebagian besar tidak naik ke tingkat kebencian, dan ada orang yang mencoba untuk memperbaiki atau membangun solusi yang solid untuk masing-masing.

Sunting: Ada beberapa kebingungan tentang poin 5. Secara khusus beberapa orang tampaknya berpikir saya maksud urutan argumen, yang saya tidak lakukan. Daripada menjelaskan apa yang saya maksud, saya hanya akan mengarahkan orang ke tautan berikut, http://hackage.haskell.org/trac/haskell-prime/wiki/ChangeDollarAssociativity , yang mengekspresikannya dengan baik.