|
Re: Steve Yegge on how to build IDEs and improve speed of dynamic languages
by Erez (Priest) on May 13, 2008 at 08:21 UTC
|
It's interesting to see that searching for Perl through Yegge's blog reveals an interesting pattern.
Last time I read some of his comments, way back in 2007, he used to accompany every mention of Perl with a profound exclamation of his dislike of the language. Looks like he doesn't do that these days, and the reason appears to be that the Perl community have, oddly enough, failed to lash at him for his opinions.
As I've done for a great many other programming languages, I've bashed on Perl's technical weaknesses at length in the past. To my continued amazement, the Perl folks are the only ones who never get upset. They just say "Haha, yeah, boy, you're right, it sure is ugly. Heh. Yeah, so, um, anyway, I'm going to get back to work now..." It's awesome. I've gained so much respect for them. It's almost enough to make me go back to programming in Perl.
But as it is, he's a fairly interesting writer, whose scope of articles tend to extend way over the threshold of reader interest (I never managed to finish reading any of his blog posts). And it doesn't look like he "gets" Perl 6.
| [reply] |
|
|
Looks like he doesn't do that these days, and the reason appears to be that the Perl community have, oddly enough, failed to lash at him for his opinions.
Well, maybe the Perl community is so used to people with no clue having random opinions about the language that it stopped caring. (Or maybe it has better things to do.)
Complaining that Perl code is line noise and unmaintainable is as retarded as complaining about Python's whitespace or the many parens in Lisp code. These things are simply not relevant issues.
So eventually you either flip the bozo bit on those people, or you just can't be arsed.
/J
| [reply] |
|
|
| [reply] |
|
|
| [reply] |
|
|
I'm also not offended by the word script. The way I see it, as Perl people, we have two alternatives when it comes to language advocacy, one is to explain to everyone that using a "scripting language" means using a general usage, Turing complete, full featured language that can do any and all of the things other languages can, but because of its nature gives one a more expressive, more productive, more natural, flowing and powerful way of expressing himself in a way that allows for him to achieve more, sooner, or, to stop saying scripts and start calling it "programs".
Being a lazy bum that I am, I vote the second.
| [reply] |
|
|
|
|
| [reply] |
Re: Steve Yegge on how to build IDEs and improve speed of dynamic languages
by moritz (Cardinal) on May 13, 2008 at 08:13 UTC
|
It's really a nice talk (and it's fun reading his rants ;).
The drawback of all these optimizations is that they need to be implemented, which tends to be non-trivial in perl (and a lot of work in any compiler). So far we don't have JIT, which you'd need for example for that trace tree optimization.
Perl tends to be hard to optimize because it has overloads and tied variables. Maybe a JIT compiler should ignore such cases, and delegate to the normal executor if either of those cases is detected.
In parrot land it's quite different: most (or all) of these optimizations could be implemented. PAST is a quite high level representation of programs, so all dynamic languages built on top of parrot+PAST could profit from optimizations in the PAST compiler.
Currently the effort is more geared towards feature completeness than optimizations, so I guess we won't see many of these in parrot 1.0, but parrot development will not stop with 1.0 ;-) | [reply] |
Re: Steve Yegge on how to build IDEs and improve speed of dynamic languages
by jplindstrom (Monsignor) on May 13, 2008 at 13:02 UTC
|
I think he said something like that the same things that would make dynamic languages faster would also be the same things that would make it easier to create IDEs for them. But I lacked an in-depth discussion about that (except: "use runtime information", maybe that was his sole connection between performance and IDEs).
/J
| [reply] |
|
|
The connection is that the tools, both the optimizer and the IDE, should work with educated guesses that work most of the time, and prepare to deal with the rest.
One of these examples was "If a variable is used in a loop, guess that it's dynamic type is the same through all iterations, and optimize for that case".
For the IDE tools that would "If this looks like a function declaration, act as if it's a function declaration, even though an obscure source filter could have broken it, in theory".
| [reply] |
Re: Steve Yegge on how to build IDEs and improve speed of dynamic languages
by dragonchild (Archbishop) on May 13, 2008 at 14:17 UTC
|
I'm still trying to find a reason why I would use an IDE that has anything more than gVim does. The whole "refactoring help" thing just makes me think that IDEs exist for bad programmers who don't know how to design in the first place.
My criteria for good software:
- Does it work?
- Can someone else come in, make a change, and be reasonably certain no bugs were introduced?
| [reply] |
|
|
I can understand that there are people who start from the perfect design and then implement it and never change anything - but I don't believe that this is the most efficient way of programming. You might disagree - but at least don't put this inflammatory label of 'bad programmer' on people who work by constantly refining their design.
| [reply] |
|
|
Shoot, I refactor as much as the next guy. I'm just wondering why people build such large edifices that they need a tool in order to manage it. Take Linux, one of the largest coding projects around. Or, Apache. I don't think they use IDEs to manage the codebase. That's because it's not a monolithic codebase. Things are broken out into black-box subsystems that can change and grow without affecting everything else. And, if you cannot identify the basic subsystems in an application, both those that exist now and those that are likely to exist, you are a bad programmer. Period.
My criteria for good software:
- Does it work?
- Can someone else come in, make a change, and be reasonably certain no bugs were introduced?
| [reply] |
|
|
|
|
|
|
|
| [reply] |
|
|
I'm still trying to find a reason why I would use an IDE that has anything more than gVim does
Doesn't that mean that gVim is just a less complex (powerful) IDE?
I mean it's an Environment in which you Develop programs, and unless you're driving it using batch scripts, you are probably using it Interactively.
Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
"Science is about questioning the status quo. Questioning authority".
In the absence of evidence, opinion is indistinguishable from prejudice.
| [reply] |
|
|
My understanding was that the I was for Integrated because IDEs integrate project management, editing, code browsers, compilation and linking, debugging and various other tools into one GUI environment.
Perl is environmentally friendly - it saves trees
| [reply] |
|
|
|
|
|
