Ask Slashdot: What Are the Strangest Features of Various Programming Languages?

itwbennett writes: Every programming language has its own unique quirks, such as weird syntax, unusual functionality or non-standard implementations -- things that can cause developers new to the language, or even seasoned pros, to scratch their heads in wonder (or throw their hands up in despair). Phil Johnson has rounded up some of the strangest — from the + operator in JavaScript to the trigraphs in C and C++ and indentation level in Python. What programming language oddities cause you the most grief?"

Comments

Powershell

[Anonymous Coward]

-eq as the equality operator in Powershell is pretty odd.

Re:Powershell

[Bacon Bits]

Two reasons:

1. POSIX environments have already been done on Windows, and they universally suck. SFU/Interix is shit. Cygwin is shit. MKS Toolkit is shit. MinGW/MSYS, which does a better job than any of them, is mostly shit. Even UnxUtils, which is just binaries modified for use with the actual Windows cmd shell are mostly shit. There are so many fundamental differences of philosophy that make working with a Windows system as though it were a POSIX system fundamentally untenable. You're stuck with mostly just munging text files in a binary world.

2. Powershell is what .NET developers think Windows administrators want in a shell. That's why you're allowed to do stuff like import .NET assemblies and use essentially unmodified C# code, but there's still no native SFTP client or server.

Powershell is about 90% of what an administrator actually wants in a shell, and it's actually not that bad. Compared to cmd.exe or VBscript it's balls out fantastic. However, an administrator shouldn't need to learn about .NET objects to be able to write a script, and they shouldn't feel like there's such a fundamental separation between what the shell can do with .NET piping and what executable programs can do. There's a very real encouragement to make everything in Powershell written in and with Powershell exclusively. Like no calling of a binary to do something unless you have no other choice. The shell and the community philosophy very much discourage that... for no real reason other than it's more difficult to get a .NET object out of a binary file and manipulate it with arbitrary .NET methods. I've seen people re-implement a command line zip program with [System.IO.Compression] instead of just using 7z.exe. Why? Just so they can use .NET objects that they never do anything with.

Honestly I really love Powershell, but I wish the philosophy were geared more around getting shit done than getting shit done with .NET.

Lua[0]?

[ThisIsSaei2561]

Lua's standard is, for things like arrays, to start counting from 1. The unlearning of old habits made this a hard adjustment.

Re:Perl: TMTOWTDI

[i kan reed]

You just haven't run into another python developer who's "clever" enough yet.

for a,b,c,d in [x.q for x in y if x.z]+[x.r for x in y if x.z]:
        a.m=b or c and d

(none of these variables are boolean)

Re:PHP

[tepples]

Many of us have read the PHP is a fractal of bad design article and a commonly cited rebuttal. I tried to reconcile the two and ended up with about a half dozen legit complaints.

Python False = True

[underqualified]

False and True are variables and you can assign one to the other. False = True print False Not that anyone sane would do this in real code, but the thought is still scary.

if(allocation_succeeded)

[tepples]

if (a = b) assigns the contents of b to a and executes the code following if b 0. Who the hell thought that would be a good idea?

If b is an expression that returns a reference to a newly allocated resource, such as fopen or malloc, this if statement represents trying to allocate a resource and then skipping the following compound statement if the allocation failed. It's what they had before exceptions, and it's what they still have on microcontrollers too small to have the overhead of a full-featured exception handler.

strings terminated by a binary zero rather than their physical size. Who the hell thought that would be a good idea?

Probably the same way that most popular operating systems store text files as a list of lines separated by newline characters, encoded as 0x0A on UNIX or Windows but 0x0D on Apple II or classic Mac OS. VMS is an exception in that its "non-stream" text files have each line prefixed by its length.

Re:cmp %rdi,%rax

[bluefoxlucid]

I always liked the target-first approach of Intel. Like strcpy(dst, src). I know I'm mucking with (dst) string, and not doing anything with (src). The same with (MOV %eax, 0xdeadbeef).

Imagine strcpy(src,dst), which many people would say is more logical because you're saying "Perform a string copy from (src) to (dst)." We say "Copy from source to destination" all the time--it's how we think, right? And then: strncpy(src,dst,32). So with strcpy(), the last argument is the thing we mess with; while strncpy() it's some argument in the middle.

This is why strcpy(dst,src) and strncpy(dst,src,len) are set: the first argument is the target. These calls immediately tell you what they actually change. printf() changes nothing, but uses the first argument as its format--it emits a modified content of the first argument based on subsequent arguments; sprintf() changes the first argument to a modified copy of the second argument using all further arguments. If something is changed, it's the first things that are changed.

In Intel assembly, a glance down the left side of the screen rapidly tells you what's roughly going on. You don't need to read the whole line; you just look at opcodes and targets, quickly recognizing which opcodes modify their targets. This immediately tells you flow; and attaching the source data for the modification provides you with logic. This is less decoding than trying to interpret an individual opcode, rearrange it in your head, extract its behavior, extract its logic, and build incrementally with that.