Which language would annoy a PHP user?

We have nobody who coordinates the programmers at the company. Everybody uses the technology he wants.

Which programming language would you suggest to learn that would annoy a PHP user (who knows a bit of Java) and give him a bad time if he has to take over a project?

Agda.

Assembly machine code or binary

PHP.

Python.

Just make up some shit language and write the interpreter in PHP.

Haskell. ``Why can't I mutate this global variable? I want a refund!''

>>7

Global variables are very useful.

Erlang. Useful for web development and strange enough.

>>8
So you like mutexes up your ass?

>>10

What you are trying to say is that if I use global variables I will also use many mutexes, or that it is desirable to do so.

>>11
Only if you have concurrent access to them.

But no, seriously, there's nothing more I hate than doing a fucking autopsy to some hack's code to see where the values for their handy global variables come from.

Rails is the worst exponent in this.

>>12

Your qualm isn't with global variables.

>>13
With respect to concurrency, they are "only" an important factor in a larger problem.

With respect to the second, they very much are.

>>12
>le pedophile sage

>>12

A Smalltalk environment usually features a variable "chasing" tool, which lists all accesses (you can filter for read or write) of that variable in the system.

Common Lisp has dynamic binding (roughly, the variable binding can proceed with the call stack).

C# or JS

XSLT

Everything constructed by real computer scientists.
Take Haskell + Yesod. When asked why by your boss, you can tell him it's because of superior security and scaling than pretty much everything else.

>>19
Haskal a shit

日本語

>>19
PHP was constructed by real computer scientists.

GHC performs type erasure. You can't have security and type erasure at the same time.

>>22
I don't believe that.
PHP was just what you get when you put a few existing languages in a blender then write some terrible standard libs for it

>>22
>tagged unions

PHP is what you get when you add all existing C apis

>>24
If you're talking about being able to do something like:

data Shape = Circle Float Float Float | Rectangle Float Float Float Float
Where Circle and Rectangle are your "tags" and Shape is your union, well, that does nothing to change the fact that GHC will do type erasure.

Any strongly type language will do, go for C++.
If you do not agree, then choose Go.

>>27-sama thinks that C++ is strongly typed o_O

>>28
get out of here anime-faggot

>>29
wow! rude

Erlang.
- He may have heard of it because of Web programming hipsters and HNdit, it won't sound too esoteric at first.
- If he never had any prior exposure to FP and find himself maintaining your code, the too obvious lack of assignment will give him (and you) something to laugh about.

Another valid choice is Haskell, for the same reasons.

>>26
I can't quite follow. Why would type erasure a problem in a language like Haskell?

>>6 Actually, that already exists. It's called LOLCODE.

>>32

Whatever the source language, compilers that do type erasure are not to be trusted.

Think about it: just because the compiler thinks it "proved" that x location in memory is always going to be type y doesn't mean it actually will.

>>34
That mostly seems to be a problem of memory manipulating, unchecked languages like C, are you sure that's really a problem of Haskell?
I mean, that is pretty much the point of Haskell that everything is proved mathematically before compilation, except, maybe in monads.
But I guess, the dangerous monad stuff is hidden in the framework, so if the framework guys fuck up, that's another problem.

See, I'm not claiming that Haskell is perfect (in fact, my ghc version has a proven compiler bug which renders yesod unusable), but after all, the typing seemed pretty much thought through.

>>35

It's not the source that matters: it's the resulting binary output that does (the stuff your operating system loads and puts into the program segment of the process: the stuff that gets attacked: the source is not attacked).

Even though Haskell the language does not provide an explicit means of adressing memory (for the most part, I'm sure there's some way to do it if you really want to), this does not mean that GHC will also output binary that refrains from addressing memory (of course it addresses memory).

By optimizing out pervasive bounds and type checks from the output code it's that much less secure. In comparison, if an attack has to deal with a program that is doing run time type and bounds checking everywhere it's quite a pain.

>>35

Also. The flaw in your thinking is the part where you say "Everything is proved mathematically before compilation" (more accurately, not entirely mathematically but heuristically, and more accurately, during compilation ;)

Specifically, the flaw is in assuming that apriori deductions hold in a running system.

>>36
>>37
Ok.
BTW: Has that something to do with this?
http://okmij.org/ftp/Haskell/types.html#branding

whitespace or brainfuck for sure.

>>38

I suppose it has "something" to do with it.

What you linked to discusses how to statically (i.e. by analyzing the program text prove the resulting output "cannot" address memory outside the allocated range) i.e. the discussion is about how to eliminate run time bounds checking (exactly what I would say is a bad idea if you care about security).

In the short history of computers there's been two kinds of people:

1. The kind that put a clear division between programming a computer, and using the computer (henceforth "the static" people) (think about the word "application", a computer is
"applied", when it is used you are using an application of the computer (this is a fundamentally static world view word!)) and,

2. the kind that place no such division: using the computer is programming the computer (henceforth "the dynamic" people).

Now, the static people will obviously place great utility on proving things apriori about a program (i.e. from the known relationship between program text, compiler, instruction set, and machine). This is because in the static world, a computer program defines all a machine can possibly do during its run: When a machine is not programmable while it is running, then every single possible thing that can happen during a it's run can be proved apriori by proving the properties of the program, the compiler, the machine language, and the machine; it's just a question of effort.

Now by contrast, the dynamic people, although also recognizing and placing much utility on apriori proofs, know that such proofs can't completely describe all the possibile actions of a machine during its run, because things can change. The only things you can really know at run-time are the properties you prove at run-time (and only at the time you have proved them!).

If the static world view holds, and a computer really can't be programmed at run time, then security just boils down to proving that your program can't do any wrong by analyzing the program text. On the other hand, if a computer can be programmed at run time, then that is not enough, and security must be enforced (at some resource cost!) at run time.

Thankfully, the static world view does not hold. The computer I own is still programmable, while it is running. The programs I run on it can indeed be modified while my computer is running. My computer lives in the dynamic world.

However my computer is also an insane asylum. It is inhabited by a bunch of loony programs and programming languages that, unable to cope with reality, like to pretend they are living in a static world. The machine itself is schizophrenic and has multiple personalities (modes) that like to pretend they can e.g. make sure a program that doesn't modify itself or other programs at runtime (HAHAHA).

This is why computers today are so fundamentally insecure: Denial. The static people are in denial of reality. When faced with what is actually required to make the static world view true (that computers are not programmable while they run!) they either agree that this would be a good idea, or because being normal people who love computers, they recoil in horror. However unfortunately many of thos latter group are so traumatized they collapse inward, and denial sets in. There's also a number of people who have never given this any thought.

But that essentially is the choice: abandon the run-time programmable computer, or abandon any notions that security can be proved statically.

Look up "capabilites" or "tagged architectures" and follow the rabbit hole to know what security might be like in a world that admits that computers should be and indeed are constantly programmable machines.

Well that sure seems more like a problem of architecture.

>>42
Bullshit.
It's well know that moot is the one who answers the red phone at FBI HQ.
Are you accusing him of being a double agent?

>>42

Yes with regards to the last thing I said. However, all things being equal, a program performing run-time type and bounds checking is always more secure than a program not doing so.

This is why when e.g. compiling C programs optimized for security you pass -fstack-protector-all, NO optimization (or -O0) and you enable mudflap (-fmudflap ?) in GCC.