Hacker Newsnew | past | comments | ask | show | jobs | submit | kentnl's commentslogin

Posted - January 13, 2011

Marked Dead - April 22, 2011

Today - Aug 5, 2014


Yeah, being eVIl, they probably use Vi.


As rms might say, "vi vi vi, the number of the beast"


Well... I assume they could use Monodevelop on BSD...


That's still partially rubbish, because you don't build technology on top of a fax machine. Many of the technologies at the higher level are directly written in C, and its going to be a while before the C goes away.

I.e.: its like a world where all our cellphones/email still, under the covers, run over fax, and we still need a fax machine in every house to make this possible. =P

Without people to write the languages in C, and without people to hack on the kernel in C, there will be no more languages, and existing C based languages will get no more features.

The best you can do now is write one high-level language in another, and that tends to be reasonably slow.

Just because you don't understand something, or because you don't know anybody who does, that doesn't mean that technology is disappearing, it just means you're in a selective circle.


I was specific to not imply any level of the levels of complexity would ever go away. That's like saying assembly has gone away. It has for the vast majority, but not for those who actually code compilers or reverse engineer software. That group is extremely small compared to the rest, hopefully we can agree on that. I expect that eventually languages like C will be similar to the way cobol is now :)


Without a testing infrastructure, you pretty much rely on programmers having code doing what they say it does, instead of having proof it does what they say it does.

Given human penchant to slip up and not realise problems until after they are encountered, having tests makes pretty much the difference between "science" and "hypothesis"


Not entirely true. Languages with strong static type systems like Haskell and OCaml go a long way towards being provably correct without test suites. Dynamic languages like Perl however have no such guarantees.

The fact that the cross product of several generations of interpreter, several platforms, and tens of thousands of distributions is generated automatically by a handful of volunteers is a strong argument for CPAN/Perl being unique amongst the dynamic languages in it's testing and compatibility.

Additionally, people who aren't in the right circles probably never know how much grepping through CPAN happens when new features and syntax is suggested for the core Perl5 language. All done by the porters to be sure that new syntax won't break existing code without some fore-knowledge. This is on top of the automated testing.


It depends which graphs you look at:

These graphs tell me

1. Perl is slightly faster. 2. Perl uses much less memory on average 3. Perl uses less code.

http://shootout.alioth.debian.org/u32/benchmark.php?test=all...

http://shootout.alioth.debian.org/u32q/benchmark.php?test=al...

However, on Ruby18 you do have a substantially bigger problem:

http://shootout.alioth.debian.org/u32/benchmark.php?test=all...

Lies, Damned lies.


> These graphs tell me

It must be the spectacles you're looking through.

These graphs tell me that

- about the same number of Perl programs are faster than the Ruby 1.9 programs by about the same amount, as there are Ruby programs faster than Perl programs

- some of the Perl programs use half the memory of the corresponding Ruby 1.9 programs

- the Perl programs and Ruby 1.9 programs use about the same amount of code.


Probably a good reason to use Perl too, finding a machine without it is hard. =)


Because sometimes objects are the right answer, and when they are the right answer, you want to be maximally equipped to use them as easy as possible.

Perl doesn't bash you over the head and make you use objects by making "int" an object, but they're there if you need them.

( And if you really need to, you can make int at least look like an object )


Tests. Integrated Bug Tracking. There's 2 reasons.


Sweet! Then lead with that. I'm not saying that CPAN isn't better than Rubygems somehow, but that "easy installation" isn't a selling point.


You haven't really started using Ruby till you start trying to JAPH and golf it. Fortunately, that phase will pass and you'll return to writing maintainable code =).

>> "The idea of making tools that are joyful to use to the programmers ... basically due to it's syntax."

Thats pretty much entirely "who is working in this language" based imo. As for syntax being a limitation, its interesting you complain that, because others have complained that the syntax is too dynamic, too augmentable, and too unpredictable, hence people talking stuff about it being impossible to write a parser for it =).

Granted, often when this feature is used, its often abused, and there are various 'source filters' in Acme:: you'd get shot if you tried using them in production ( Switch.pm is one such shootable offsense ... with great power comes ... extra unwanted side effects ).

But an example of a Good use of the source filter/metaprogramming nature intrinsic to Perl is MooseX::Declare ( its only part source filter, but its "Sane" because its smart enough to not cause too many unwanted side effects ) to provide alternative class declaration syntax, that some would claim, even looks readable!.

   use 5.010;
   use MooseX::Declare; 
   
 
   class Foo { 
         method hello( $what ){ 
             say "Hello $what";
         }
   }

   Foo->new()->hello("World");  # Hellow World\n


Nice idea, but what tends to happen is this:

    -- User1235 has joined #perl --
    user1235> PERL SUCKS 111!!!11!!1!!11!!
    -- Chanserv set mode +o mst --
    -- user1235 was kicked ( troll ) --
The people who are honestly interested tend not to need the door shown to them, and people who aren't interested can't be convinced by such tactics.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: