| |||||||||||||
|
| |||||||||||||
'make' year for Perl'make' year for PerlPosted Jan 8, 2009 10:33 UTC (Thu) by rwmj (guest, #5474)In reply to: 'make' year for Perl by tzafrir Parent article: The Grumpy Editor's guide to 2009
Which Linux distribution has a working perl6 implementation? You might also ask which distributions are using Python 3. I guess Debian have packaged it. Fedora have passed on Python 3 (for now at least). Python 3 isn't backwards compatible, in a way which means you have to maintain two branches of your code. Whereas Perl 6 runs all existing Perl 5 code, no branching required. (Of course, I'm hoping that 2009 will be the year of the strongly-typed HM-based functional language, and we can finally give all dynamic languages the heave-ho in order to write better quality software). Rich.
(Log in to post comments)
'make' year for Perl Posted Jan 8, 2009 17:50 UTC (Thu) by lysse (guest, #3190) [Link]
"Better quality" surely remains an unproven assertion in this context - possibly even an unproveable one.
'make' year for Perl Posted Jan 8, 2009 17:59 UTC (Thu) by rwmj (guest, #5474) [Link] Well, I'd certainly like the compiler to identify some of the bugs for me earlier, instead of me having to try in vain to test every path through the code. My time is valuable, and wasting in tracking bugs and testing things that can be easily found by the compiler is just stupid. But hey, most people are still writing C that lets you stomp all over memory (when, that is, you're not sitting there worrying about who owns that bit of memory and who is responsible for freeing it). Rich.
'make' year for Perl Posted Jan 9, 2009 0:32 UTC (Fri) by lysse (guest, #3190) [Link]
As I understand it, one of the advantages of increased dynamism in one's language environment is that one can write code with a reduced number of paths through it. Ultimately - even truistically - the only way to write code with fewer bugs is to write less code.
The ideal for a compiler (or a language, maybe?) is that it is able to separate, as far as is possible, those bits of the program which can be precomputed (eg. type information) and precompute them, leaving only those bits which actually depend on real-time input for runtime. However, it's not readily apparent to me that languages such as Haskell - which impose a strict separation between compilation and execution, with the aim of doing as much reduction as possible in the former - are more capable of doing that than languages such as Lisp - which effectively abolish the distinction between the two, allowing the full power of the execution environment to be present at compilation; I suspect that the relative power of the two approaches comes down purely to personal preference, or "which confuses/annoys me less", and that there's no inherent superiority in either approach.
'make' year for Perl Posted Jan 9, 2009 1:42 UTC (Fri) by dlang (✭ supporter ✭, #313) [Link]
while I agree that writing less code tends to generate fewer bugs, I adamantly disagree with the statement that the only way to write code with fewer bugs is to write less code.
even the statement that less code => fewer bugs is only true if all else remains equal. not all lines of code are the same. 100 lines of simple commands can be substantially less buggy than 5 lines of library calls with 50 options to each call.
using the language that best matches the abstraction of your code both decreases the lines of code needed, and decreases the errors. but the big win is in the fit, not in the lines of code.
'make' year for Perl Posted Jan 9, 2009 17:27 UTC (Fri) by lysse (guest, #3190) [Link]
> even the statement that less code => fewer bugs is only true if all else remains equal. not all lines of code are the same. 100 lines of simple commands can be substantially less buggy than 5 lines of library calls with 50 options to each call.
I realised after I'd posted that what I'd written was a bit ambiguous on precisely this point - so for the record, I am in complete agreement with you on this point. Indeed, in some ways libraries offer the worst of both worlds - they are neither designed to be specific to the task at hand, nor necessarily as well-debugged as their generality would necessitate - but that's a rant for another day. Please don't think I'm lending support to the "if there's a library for it, use the library" school of coding! Rather, I regard using a library as outsourcing; you're still responsible for every line of code in that library connected with the parts of it you're using, even though you delegated the authorship of the code you're using to the library's authors.
But I'm going to abandon this conversation at this point, anyway, because the one thing that's become more apparent to me than anything else over the 15 years I've been paying attention is that whatever anyone says about programming, and however anodynely they seek to express it, someone will come along and disagree with it in the violent and unshakeable conviction that they Know the Truth about it and have a Duty to Correct the Evil Lies - and if (but only if) you're really really lucky, they haven't misunderstood the first half of the second sentence to which they're replying and gone off half cocked. Worse, I've been that person way too often myself. So forgive me if I skip the whole damn sideshow this time; it's old and tedious and does absolutely nothing for anyone, and it disproportionately upsets me.
'make' year for Perl Posted Jan 9, 2009 19:10 UTC (Fri) by dlang (✭ supporter ✭, #313) [Link]
no problem. I've just seen too many people who believe the letter of your initial statement that I didn't want to leave it sit.
I agree with the rest of your statements as well.
'make' year for Perl Posted Jan 10, 2009 6:30 UTC (Sat) by Ze (subscriber, #54182) [Link]
>>As I understand it, one of the advantages of increased dynamism in one's language environment is that one can write code with a reduced number of paths through it.
Whoever said that lied to you. A dynamic language has just as many paths through it. Just some of them are generated by the compiler/interpreter. The downside is since you give it less constraints it can do less optimisation and more importantly less error checking. >>Ultimately - even truistically - the only way to write code with fewer bugs is to write less code. Yes but that means less functionality.
>>The ideal for a compiler (or a language, maybe?) is that it is able to separate, as far as is possible, those bits of the program which can be precomputed (eg. type information) and precompute them, leaving only those bits which actually depend on real-time input for runtime. However, it's not readily apparent to me that languages such as Haskell - which impose a strict separation between compilation and execution, with the aim of doing as much reduction as possible in the former - are more capable of doing that than languages such as Lisp - which effectively abolish the distinction between the two, allowing the full power of the execution environment to be present at compilation;
The languages which separate compilation and execution (which btw isn't a restriction of the language but rather of the tools we choose to write , we could write an interpreter for c++ if we wanted).
The power that some languages have is they can create code on the fly. Ironically this was something that assembly had but when it came to write 'c' it was stripped out. It's a feature that's rarely needed or desirable. It's far more often misused than it used correctly.
If one wished , one could add an 'eval' to compiled languages by seperately compiling the extra code as needed and having a few constraints on optimisations for the original code. One particular optimisation that we would need to be very careful with is where instead of having two variables 'foo' and 'bar' we instead alias 'bar' to 'foo' since our analysis shows that 'foo' and 'bar' always have the same value.
>>I suspect that the relative power of the two approaches comes down purely to personal preference, or "which confuses/annoys me less", and that there's no inherent superiority in either approach.
Consider the wasted time spent reanalysing a program every time you run it? and consider that you need to run it anyway to test it. Why not trade some of that reanalysis time for better optimisation? or time you could spend doing other things?
IMHO that was one of the things that scripting has historically got wrong but that's due to the fact that historically they didn't create an intermediate format but rather put the code into an 'abstract syntax tree' and interpreted it from that. That has changed though since a lot of them convert the AST into an intermediate form that is more linear and then interpret that.
Unfortunately it's one of the things that history has landed in our laps and it's not something we'll rid ourselves of soon.
'make' year for Perl Posted Jan 11, 2009 2:49 UTC (Sun) by dlang (✭ supporter ✭, #313) [Link]
compiled vs interpreted languages are a perfect example of what Linus has said about git, performance is a feature in and of itself, and at some point performance isn't just about doing things a in less time, but it fundamentally changes how you do things.
the speed of the edit-compile-test loop is the key difference between languages.
for traditional compiled languages the compile step takes a significant amount of time, so you do more work between compile steps.
for interpreted languages the 'compile' step is invisable to the user (it exists to some extent, but it's part of the run), so the tendancy becomes to tweak one thing, test it, then go to the next.
depending on what the testing steps require a project may fit better into one model than the other. small projects or projects that are generally stateless (many web projects for example) are much faster to develop with an interpreted language, projects that take a long time to test (it may be that they have a lot of state in them and so take many steps to test the change) don't benifit from the interitive approach of interpreted languages, and so the compile step doesn't hurt as much, and the other advantages in traditional compiled langages like strong typing and faster run-time performance are still there, so they tend to be better done using a 'compiled' language
now, in many cases the langugage is not selected based on what's best for the project, and many cases where the project has shifted over time (what started as a quick and simple program grew to be a monster), so you see a lot of projects written and maintained in inappropriate langugaes
it would be nice if there were interpreters and compilers for the same language so that development could take advantage of the strengths of the interpreted approach and production could take advantage of the compiled approach, but such situations are very rare.
'make' year for Perl Posted Jan 10, 2009 13:24 UTC (Sat) by epa (subscriber, #39769) [Link] Whereas Perl 6 runs all existing Perl 5 code, no branching required.Huh? You seem to be comparing an existing, working program (Python 3) with something that does not exist yet. Or have I missed something, and a Perl 6 implementation that 'runs all existing Perl 5 code' has been released without anyone noticing? I am aware that the Parrot and Rakudo developers have been making good progress. That is not the same as saying that Perl 6 has been released in anything like a usable state, or will be in the next 12 months. According to the current road map there are a couple of years to wait.
|
|
||||||||||||