And at the end of the day CPUs run machine code. Another interesting point is that soft devs arguing about which programming language might be the best often treat CPUs as a magic black box. But all the different CPU architectures, designs and add-ons have an impact on what can be done with a specific CPU. We should consider the whole package!
an installation of a horrible Perl web groupwareWe need names!I don't wanna, because I actually like the authors, and I don't want them get pissed at me.
Still, I've produced working systems that use Perl, mostly making up for lacking functions in other stuff.
If you learn Perl by working with well-organized code, you mostly see the power and ease of Perl expressions. But, if basically the only Perl code you work with for a couple of years is copy-pasta spaghetti, I'm sure you can see why one might develop to an aversion to the language, even though it's not the languages fault per se.
If you learn Perl by working with well-organized code, you mostly see the power and ease of Perl expressions. But, if basically the only Perl code you work with for a couple of years is copy-pasta spaghetti, I'm sure you can see why one might develop to an aversion to the language, even though it's not the languages fault per se.That is true for any language, even. =)
I also severely dislike the Systems Hungarian notation, where the type of a variable is part of the variable name. I'm not sure where that came from; perhaps it is the repetition that annoys me.
What do you use to *debug* PHP?
I also severely dislike the Systems Hungarian notation, where the type of a variable is part of the variable name. I'm not sure where that came from; perhaps it is the repetition that annoys me.
What do you use to *debug* PHP?
A very strong degausser on the storage media. That should teach it.
I also severely dislike the Systems Hungarian notation, where the type of a variable is part of the variable name. I'm not sure where that came from; perhaps it is the repetition that annoys me.Popularising it is Microsoft's fault. The original instigator is probably languages that infer type from the initial letter of a variable e.g. IMPLICIT types in FORTRAN.
What do you use to *debug* PHP?A very strong degausser on the storage media. That should teach it.
I also severely dislike the Systems Hungarian notation, where the type of a variable is part of the variable name. I'm not sure where that came from; perhaps it is the repetition that annoys me.Hungarian notation was invented by an actual Hungarian, Charles Simonyi, originally at Xerox PARC, later of Microsoft.
What do you use to *debug* PHP?
A very strong degausser on the storage media. That should teach it.
That's the problem with these newfangled SSDs. A degausser won't work. I suggest a flamethrower.
I was going to suggest one of those thermite weld pots they use to join rails. That's pretty definitive.
If you learn Perl by working with well-organized code, you mostly see the power and ease of Perl expressions. But, if basically the only Perl code you work with for a couple of years is copy-pasta spaghetti, I'm sure you can see why one might develop to an aversion to the language, even though it's not the languages fault per se.That is true for any language, even. =)Languages with more concise and powerful expressions are a bit more vulnerable to it, though.
At the extreme end, things like complex regular expressions are pretty much write-only by humans.
I also severely dislike the Systems Hungarian notation, where the type of a variable is part of the variable name. I'm not sure where that came from; perhaps it is the repetition that annoys me.Popularising it is Microsoft's fault. The original instigator is probably languages that infer type from the initial letter of a variable e.g. IMPLICIT types in FORTRAN.I mentioned it, of course, because of Perl sigils ($ for scalars, @ for arrays, and % for hashes, & for subroutines, and * for typeglobs).
(defun square (x) (* x x))
(square 9)
=> 81
(set 'foo (function square))
(funcall foo (13))
=> 169
If you learn Perl by working with well-organized code, you mostly see the power and ease of Perl expressions. But, if basically the only Perl code you work with for a couple of years is copy-pasta spaghetti, I'm sure you can see why one might develop to an aversion to the language, even though it's not the languages fault per se.That is true for any language, even. =)Languages with more concise and powerful expressions are a bit more vulnerable to it, though.
At the extreme end, things like complex regular expressions are pretty much write-only by humans.That's the fault of the reader not taking enough time. It's the same as people complaining mathematics or physics are hard because they try to read pages full of equations in textbooks as quickly as they read pages from a spy novel – and often not even studying what ∫ or ∑ or other symbols actually mean. Or *, +, ? etc in regular expressions.
SLOW DOWN!
I personally prefer programming languages with a single namespace — such as Pascal, Dylan, Scheme — but I seem to be in a minority. I've learned to cope. By reading the respective manuals.
If you learn Perl by working with well-organized code, you mostly see the power and ease of Perl expressions. But, if basically the only Perl code you work with for a couple of years is copy-pasta spaghetti, I'm sure you can see why one might develop to an aversion to the language, even though it's not the languages fault per se.That is true for any language, even. =)Languages with more concise and powerful expressions are a bit more vulnerable to it, though.
At the extreme end, things like complex regular expressions are pretty much write-only by humans.That's the fault of the reader not taking enough time. It's the same as people complaining mathematics or physics are hard because they try to read pages full of equations in textbooks as quickly as they read pages from a spy novel – and often not even studying what ∫ or ∑ or other symbols actually mean. Or *, +, ? etc in regular expressions.I disagree, because modifying a complex regular expression is completely different to understanding one.
As an overly simplified example, consider the regular expression /ab*c/. This matches any substring starting with a, ending with c, and containing only zero or more b in between. Because of a change elsewhere, we now need to change this expression so that it matches those substrings, but also the ones that start with ac followed by zero or more d after, matching the longest matching substring of course. Do you modify the expression, or do you rewrite it?
if ($ARGV[0] =~
/^(?&fpconst)$
(?(DEFINE)
(?<osg>[-+]?) # optional sign
(?<int>\d++) # integer
(?<dec>\.(?&int)?) # decimal fraction
(?<fpconst>(?&osg)\ * ( (?&int)(?&dec)? | (?&dec) )(?: [eE](?&osg)(?&int) )?)
)/x
){
print "yes\n";
} else {
print "no\n";
}
$ perl isfp.pl 123
yes
$ perl isfp.pl 123e
no
$ perl isfp.pl 123e4
yes
$ perl isfp.pl 123.e4
yes
$ perl isfp.pl 123.34e4
yes
$ perl isfp.pl 123.
yes
By "write-only", I mean that even if you fully understand what the code (or here, expression) does, modification may not be feasible, and rewriting the part will actually save time and effort, and yield a more reliable result.
I personally prefer programming languages with a single namespace — such as Pascal, Dylan, Scheme — but I seem to be in a minority. I've learned to cope. By reading the respective manuals.Is that a veiled insult suggesting that I just don't get it because I do not read manuals, eh?
QuoteBy "write-only", I mean that even if you fully understand what the code (or here, expression) does, modification may not be feasible, and rewriting the part will actually save time and effort, and yield a more reliable result.Fair enough but as you yourself said, that's not what is usually meant by "write-only".
QuoteI personally prefer programming languages with a single namespace — such as Pascal, Dylan, Scheme — but I seem to be in a minority. I've learned to cope. By reading the respective manuals.Is that a veiled insult suggesting that I just don't get it because I do not read manuals, eh?Nope, it's about me. I try not to be ambiguous about insulting someone, or do it by accident.
I was going to suggest one of those thermite weld pots they use to join rails. That's pretty definitive.I don't think my "explosion containment pie dish" (per BigClive) could handle thermite, though. Darned stuff burns through everything.
Perhaps an industrial shredder?
Shredding harddrives is fun. Before such things were available, I used to take them apart, and cut the platters into small strips with a metal shears before distributing the slivers one in each waste basket on a stroll through town. Being a bit tedious, this operation was reserved for things like Kerberos KDC machines and such.
Shredding harddrives is fun. Before such things were available, I used to take them apart, and cut the platters into small strips with a metal shears before distributing the slivers one in each waste basket on a stroll through town. Being a bit tedious, this operation was reserved for things like Kerberos KDC machines and such.A hot torch is easier. Just burn the thin coating off the aluminium platter, and twist it into a pretzel. Assuming fume extraction is available, of course. Then the bit carrying parts literally do not exist anymore.
Actually, recovering data from a physically malformed platter is nigh impossible, so just taking out the platters and hammering or otherwise taking your frustration out on them a bit is more than enough.
Plus, the magnets are quite fun to play with, and when taken apart, the boards and spindle magnetics can be put in e-waste, and the cast aluminium parts in metal recycling.
at that point "nigh impossible" can change to "recoverable with enough money, a clean room, a tunnelling SEM and time".
If you ran a TLA, what would you pay to get access to an SSH key or VPN keys for a techie who had 'root' or 'enable' on core networks of a large international telco?
If you ran a TLA, what would you pay to get access to an SSH key or VPN keys for a techie who had 'root' or 'enable' on core networks of a large international telco?