Why yes, that was the entire treatise of every objection I've ever had with Tcl.
Here's a couple others I have just off the top of my head:
* OOP still requires manual destruction of objects.
* Events execute only in the global scope.
I'm sure there will be hundreds who will leap to the "defense" of Tcl against these "attacks", but really don't bother. Since I've joined the very large crowd who doesn't actually use it anymore, and it's not like there's any jobs that require me to even use it -- the closest it gets is tweaking an Expect script or two -- there's no reason anyone should actually have to care.
Yes, it's possible to "get used to" Tcl, and I did for some years. It's not the worst language I've ever programmed in, but that's unfortunately what has to pass for praise as well.
> (in other words, there is no file system that support letting users to set programs to be "setuid 0, but only allow sending signals to arbitrary processes, without any other special ability of the root user"
Doesn't it sound barkingly insane to say "run as a God User except only able to do X, Y, and Z?" Why indeed even have root in the first place? But that's still what these capabilities are -- set a single set of bits in a process (to all zeros no less) and let it do everything, THEN strip out what it can do afterward.
Sane security models that have anything like a superuser don't allow them to do much of anything except adopt a different set of permissions.
Re:Tcl language vs. Tcl environment
on
Tcl/Tk 8.5.0 Released
·
· Score: 2, Interesting
> Tcl is incredibly simple once you understand it.
I've never seen a language that actually parses comments, the way Tcl does. There's nothing simple about that.
Fantastic indeed, and the syntax looks nice. But you still have to manually destroy objects. Basically, writing Tcl like any other high level language in existence means having crippling memory leaks. So you learn to avoid objects like the bolted-on kludge that they still are. Even perl at least got the memory management part right.
Python tkinter ought to look nice, but Tcl continues to be a non-starter.
Bah, that's just a simple phrase translator. Try LOLPYTHON to actually program that way. I'm quite positive the lameness filter will rightly defy my efforts to post a sample here, so CLICKIE PLZ THX LOL.
Recursive patterns (which were in perl before 5.10, there's just nicer syntax sugar for them now) effectively turn the NFA of a regular expression engine into a pushdown automaton, meaning they can count. This makes them able to parse balanced expressions, so yes technically you could parse HTML with a regex. In fact, I believe they're turing-complete, even without the benefit of/e.
Whether you'd actually want to is another matter. 5.10's regex engine may not be recursive when backtracking, but when you tell it to go recursive, one way or another it's going to use a pretty big stack to parse anything even moderately deeply nested. There's plenty of better-suited parsing modules on CPAN, and now with the extensible ~~ operator, we might even get to see some of them used more liberally. Me, I can't wait to make it work with xpath.
> open SOME_FILE, ">some_filename.foo" or die("Some kind of error occurred");
Just to nitpick, the recommended modern perl idiom looks like:
open my $file, '>', 'some_filename.foo' or die "Couldn't open file for writing: $@";
Or use Fatal qw(open); and skip the "or die" part altogether. Arguably it's behavior that should have been been in perl from the start, but perl still doesn't have a decent exception mechanism built-in.
> The === sign is a PHPism for equal in value and of the same type,
Actually it's lifted from Javascript, where it means the same thing as lisp's eq (but not perl's), or python's is. But as usual, PHP got it head-slappingly wrong and now we're all stuck with it.
Last time I checked, the Supreme Court was the absolute ultimate political appointee. In fact, as ideologies go, getting your guy elected president is pretty much for the purpose at giving him a shot to appoint some supreme court justices.
Clarence Thomas once went an entire session without saying a single word in oral arguments.
Re:Bet there still isn't a decent "Stop!" button
on
HTML V5 and XHTML V2
·
· Score: 2, Interesting
> A suggested implementation is for the disabling bit to be at the parser level.
The natural tag for controlling the parsing would be a processing instruction.
<?secure on key:hkwh45kdfhgkjwh45?> blah blah blah blah <?secure off key:hkwh45kdfhgkjwh45?>
Good luck getting that into a standard, but heck, you don't really even need the cooperation of the W3C to do this.
Re:Bet there still isn't a decent "Stop!" button
on
HTML V5 and XHTML V2
·
· Score: 1
Any user agent would have to treat your document as tag-soup instead of parsing a DOM-tree because that would be the only way to recognise the on and off states.
DOM trees are still ordered (otherwise flow layout wouldn't work), so this would work:
Not that I'd use tags like that, or even think it's a good idea, and it would be a O(n) thing to search through sibling tags, but the DOM API is still quite well up to the task.
Personally I think the proper solution for script injection is to simply not do it, and control your output.
> What a world we live in when the supposed alpha geeks are the laggards of a technology bell curve!!
Not really. Grumbling old hidebound greybeards that scoff at every fancy-dancy technology are just displaying a variation of the insecure know-it-all and above-it-all-ism that pervades geek culture. Really, it's not just limited to geeks -- these days, everyone thinks themselves an expert on everything after watching a few episodes of 24 and Dr Phil -- it's just that geeks have the knowledge in the technology area for the constant scoffing to sound plausible.
The distinction between port filtering + ACLs and today's notion of "firewall" that's actually useful is of a stateful firewall, doing stateful packet inspection, with policies based on not just the packet you're picking a TCP header out of. If you tried to sell a stateless filter as a "firewall" today, you'd be laughed out of the market.
And no, I don't see any need to firewall a web farm either.
Oh please, it takes a lot of work to destroy the earth. We're really only up to the task of maybe wiping off the top layer of scum called "life", not the planet itself.
> Note this well. The US's most significant "victory" in GWI was bombing the shit out of a RETREATING army.
Look, I'm no fan of what we've done in Iraq, but a retreating army is still an army, one that has not surrendered, and therefore you still destroy it if you can. You don't shoot civilians, you don't shoot surrendering forces, but everything else really is fair game.
Yeah, it was grisly, but you want to talk war crimes, how about the bombing of water treatment plants?
Slashdot Mirror
Does it make their claims wrong?
Why yes, that was the entire treatise of every objection I've ever had with Tcl.
Here's a couple others I have just off the top of my head:
* OOP still requires manual destruction of objects.
* Events execute only in the global scope.
I'm sure there will be hundreds who will leap to the "defense" of Tcl against these "attacks", but really don't bother. Since I've joined the very large crowd who doesn't actually use it anymore, and it's not like there's any jobs that require me to even use it -- the closest it gets is tweaking an Expect script or two -- there's no reason anyone should actually have to care.
Yes, it's possible to "get used to" Tcl, and I did for some years. It's not the worst language I've ever programmed in, but that's unfortunately what has to pass for praise as well.
> (in other words, there is no file system that support letting users to set programs to be "setuid 0, but only allow sending signals to arbitrary processes, without any other special ability of the root user"
Doesn't it sound barkingly insane to say "run as a God User except only able to do X, Y, and Z?" Why indeed even have root in the first place? But that's still what these capabilities are -- set a single set of bits in a process (to all zeros no less) and let it do everything, THEN strip out what it can do afterward.
Sane security models that have anything like a superuser don't allow them to do much of anything except adopt a different set of permissions.
> Tcl is incredibly simple once you understand it.
I've never seen a language that actually parses comments, the way Tcl does. There's nothing simple about that.
> at last a sanctioned OO framework http://wiki.tcl.tk/TclOO.
Fantastic indeed, and the syntax looks nice. But you still have to manually destroy objects. Basically, writing Tcl like any other high level language in existence means having crippling memory leaks. So you learn to avoid objects like the bolted-on kludge that they still are. Even perl at least got the memory management part right.
Python tkinter ought to look nice, but Tcl continues to be a non-starter.
Yes. foo(*args). Or if you like your args named, foo(**kw)
> How about ubiquitous mobile Internet access?
Show me a cell phone that doesn't have internet.
> DVD Audio? SuperAudio CD?
They shipped fine. Market failures are not vapor.
> FTTH?
FIOS ring a bell?
> LEO satellite phone and internet service?
A small fraction of Iridium might indeed become vapor as this spectacular market failure is de-orbited.
Bah, that's just a simple phrase translator. Try LOLPYTHON to actually program that way. I'm quite positive the lameness filter will rightly defy my efforts to post a sample here, so CLICKIE PLZ THX LOL.
Still, LOLPYTHON has nothing on Perligata
> There is no other language where pointer to function can be used with such ease.
Don't use many other languages, do you? To wit, in python:
dispatch = dict(foo=func1, bar=func2, blah=func3)
dispatch[op]()
The same code in perl:
my %dispatch = (foo => \&func1, bar => \&func2, blah => \&func3);
$dispatch{op}->();
Don't even get me started on Scheme.
Recursive patterns (which were in perl before 5.10, there's just nicer syntax sugar for them now) effectively turn the NFA of a regular expression engine into a pushdown automaton, meaning they can count. This makes them able to parse balanced expressions, so yes technically you could parse HTML with a regex. In fact, I believe they're turing-complete, even without the benefit of /e.
Whether you'd actually want to is another matter. 5.10's regex engine may not be recursive when backtracking, but when you tell it to go recursive, one way or another it's going to use a pretty big stack to parse anything even moderately deeply nested. There's plenty of better-suited parsing modules on CPAN, and now with the extensible ~~ operator, we might even get to see some of them used more liberally. Me, I can't wait to make it work with xpath.
> open SOME_FILE, ">some_filename.foo" or die("Some kind of error occurred");
Just to nitpick, the recommended modern perl idiom looks like:
open my $file, '>', 'some_filename.foo' or die "Couldn't open file for writing: $@";
Or use Fatal qw(open); and skip the "or die" part altogether. Arguably it's behavior that should have been been in perl from the start, but perl still doesn't have a decent exception mechanism built-in.
> The === sign is a PHPism for equal in value and of the same type,
Actually it's lifted from Javascript, where it means the same thing as lisp's eq (but not perl's), or python's is . But as usual, PHP got it head-slappingly wrong and now we're all stuck with it.
> GTA still sells, so an AO rating is actually likely to increase sales
GTA is rated M. The old version which isn't sold anymore was rerated AO.
> AO? No problem.
It is to all the sputtering jowl-wagging moral guardians in office.
At least Python has polymorphic operators and knows that numbers and strings are different things.
Actually, perl has overloaded operators too. Now itdoes, anyway. Scalars are a remnant from perl 1, and themselves some sort of throwback to awk.
He will disappoint you. Bank on it. The other 99.99% of us will, however, probably like it.
Last time I checked, the Supreme Court was the absolute ultimate political appointee. In fact, as ideologies go, getting your guy elected president is pretty much for the purpose at giving him a shot to appoint some supreme court justices.
Clarence Thomas once went an entire session without saying a single word in oral arguments.
> A suggested implementation is for the disabling bit to be at the parser level.
The natural tag for controlling the parsing would be a processing instruction.
<?secure on key:hkwh45kdfhgkjwh45?>
blah blah blah blah
<?secure off key:hkwh45kdfhgkjwh45?>
Good luck getting that into a standard, but heck, you don't really even need the cooperation of the W3C to do this.
Any user agent would have to treat your document as tag-soup instead of parsing a DOM-tree because that would be the only way to recognise the on and off states.
DOM trees are still ordered (otherwise flow layout wouldn't work), so this would work:
<secure state="on"/> blah blah blah <secure state="off"/>
Not that I'd use tags like that, or even think it's a good idea, and it would be a O(n) thing to search through sibling tags, but the DOM API is still quite well up to the task.
Personally I think the proper solution for script injection is to simply not do it, and control your output.
> What a world we live in when the supposed alpha geeks are the laggards of a technology bell curve!!
Not really. Grumbling old hidebound greybeards that scoff at every fancy-dancy technology are just displaying a variation of the insecure know-it-all and above-it-all-ism that pervades geek culture. Really, it's not just limited to geeks -- these days, everyone thinks themselves an expert on everything after watching a few episodes of 24 and Dr Phil -- it's just that geeks have the knowledge in the technology area for the constant scoffing to sound plausible.
The distinction between port filtering + ACLs and today's notion of "firewall" that's actually useful is of a stateful firewall, doing stateful packet inspection, with policies based on not just the packet you're picking a TCP header out of. If you tried to sell a stateless filter as a "firewall" today, you'd be laughed out of the market.
And no, I don't see any need to firewall a web farm either.
Oh please, it takes a lot of work to destroy the earth. We're really only up to the task of maybe wiping off the top layer of scum called "life", not the planet itself.
Do you really think laser target designators just look for a shiny red dot and not a coded signal of some sort?
Besides, you don't need a target designator for this weapon. It IS a laser. You use a camera to acquire the target.
Where have all the Star Wars Nerds gone?
Fried by lasers, every one.
Oh when will they ever learn...
And now you know ... The Rest of The Story!
> Note this well. The US's most significant "victory" in GWI was bombing the shit out of a RETREATING army.
Look, I'm no fan of what we've done in Iraq, but a retreating army is still an army, one that has not surrendered, and therefore you still destroy it if you can. You don't shoot civilians, you don't shoot surrendering forces, but everything else really is fair game.
Yeah, it was grisly, but you want to talk war crimes, how about the bombing of water treatment plants?