Oracle is really an acronym, short for One Real Asshole Called Larry Ellison.

This move is hardly surprising given Oracle's policies, honestly it's surprising they're doing it this late.

My guess is that they wanted to wait until their lawsuit against Google is resolved. The plan was to win the lawsuit to prove they own all APIs and designs, then kill all alternative Java implementations (both OpenJDK and JREs). Then they would herd everyone to use their implementations, wait a year or two, and start squeezing money out of them.

Webdriver is what you're looking for. Selenium and other tools rely on it. Gotta warn you though - running inbrowser tests is a pain in the ass, always.

This one takes the cake. Beauty of for ($i=0 or $var=fread(STDIN, 8192); is astonishing. I'm 100% serious.

Goddamnit... I should be working, and I'm writing a bash one liner...

Doesn't match the input precisely, but it's easy to adjust

bash-4.2$ echo "qwertyqwer" | fold -w 1 | nl | tr -s ' ' | sort --key 2 | uniq -c  -f 1 | grep -F '    1 ' | cut -c 8- | sort --numeric | head -n 1 | cut -f 2
t
bash-4.2$ echo "qwertywert" | fold -w 1 | nl | tr -s ' ' | sort --key 2 | uniq -c  -f 1 | grep -F '    1 ' | cut -c 8- | sort --numeric | head -n 1 | cut -f 2
q
bash-4.2$ echo "yellow" | fold -w 1 | nl | tr -s ' ' | sort --key 2 | uniq -c  -f 1 | grep -F '    1 ' | cut -c 8- | sort --numeric | head -n 1 | cut -f 2
y
bash-4.2$ echo "tooth" | fold -w 1 | nl | tr -s ' ' | sort --key 2 | uniq -c  -f 1 | grep -F '    1 ' | cut -c 8- | sort --numeric | head -n 1 | cut -f 2
h

There's also the social issues of everyone

Real programmers are antisocial :P

But, honestly, yeah, I get why people are sticking to it... it's easier. But, to be honest, I think that programmers should always expand their experience and skills, keep digging deeper and deeper. Right now they're relying on github UI, without being even aware that you can do it all faster if you know underlying tools.

I wonder why people still don't self host their git repos. Git was designed for it, it's trivial and efficient - but people still keep using terrible services, which are a centralised point of failure (against main git purposes) and try to enforce their bullshit "principles" (against Free Software development model/ideals).

I'd try a different approach from most of the people. Making a decision based on languages, compilation procedures is tricky, with all JIT, bytecode compilers, wrappers, and so on.

I'd make a decision based on purpose and development procedure. If the software that you're writing is a big-thing, which will be either sold to customers, deployed somewhere or published as an open source project, then you are definitely coding.

If you are writing a small utility which will be used by your friends, workmates, only by you and which is written just for one purpose, then it's scripting.

Of course, the definition leaves a lot of wiggle room, but I think gives a better distinction.

Well, I used lisp dialects (clisp and scheme in particular) a while ago, but never for anything user-interfacing. User interaction, from what I remember was considered something "impure", as side-effect based operations interfered with the strictly functional approach.

I'm tempted to learn Haskell, but that will require some time.

I've seen the video, but to form any opinion I'd need to spend a few hours at least. I'll try to take a look if I have a free weekend.

Clumsiness as in "a lot of code to accomplish a simple thing". I dislike Java because of this too. Reasons are pretty simple - I'm lazy, and more lines of code => more places for a bug.

What I have to admit about Free Pascal, is that it's very logical. Something that's missing in recently pushed swift. Once you start to understand its design principles everything looks reasonable.

Lazarus...? What year is it?

To be honest, long ago somewhere deep down I liked Free Pascal, but there were issues making it quite clumsy for rapid development. I haven't re-examined it lately, but I doubt it's more convenient than Python / PyQT combo for when I need to hurry. For fancy stuff C++ / QT take the cake.

Pretty much; Randall Munroe (as usually) got it right.

From my point of view it stems from overcorrecting after realising the previous issue, and the common trend in IT to apply a good/decent idea with a quasi-religious fanaticism until it starts to look like a caricature of itself.

Holy fuck. Not that it was unexpected, but it's still "Holy-fuck"worthy. They won't stop messing with userspace tools until all is merged into systemd. When I first saw this gif, I found it funny - https://imgur.com/gallery/D1XK8nk - I do not find it funny anymore.

In 5 years somebody will come with a novel idea and say "This systemd thing is too big, let's split it into separate tools, loosely integrated with shell scripts..." Mind my words :)

Assorted stuff, which comes to my mind after a few years in industry:

1. Be paranoid

2. Don't read/save data that you don't need, try to convince designers (if possible) to avoid storing sensitive data, if your app can work fine without it

3. Read stuff from netsec sub, and owasp. If you write web applications/services scan them with Owasp ZED

4. Know what's happening underneath. Don't trust libraries blindly - try to at least learn their general logic. For example - take the famous bash "shellshock" bug - some people didn't even know they could have been affected, because they didn't know that their software is calling the default system shell to execute something.

5. Don't try to invent your own encryption/hashing/password hashing. Also try to stay up to date with what is currently the most secure solution. For example - today I would stick to TLS for connection cryptography, sha3 for hashing/HMAC, bcrypt for passwords.

6. Use prepared statements when communicating with DBs. If your tools don't allow that, change tools, as in 2015 it's not acceptable.

7. With frontend services/sites - filter outgoing data, don't try to protect from HTML/script injection on the input layer, as you'll usually fail, and you might end up double-escaping stuff (which sometimes can introduce new dangers)

8. Handle your encodings correctly. If for example your filter assumes that the input is utf-8, and your logic takes it as ISO-8859-01, your filter may ignore dangerous characters, and let some "s slip through.

9. Ask others to review your code if you're not feeling well with it. Offer workmates a beer for finding a security hole in it, once you're confident

10. If you filter stuff, know that 127.211.112.12 is also localhost (whole 127.0.0.0/8 is)

11. Also know that http://3331396748/ is a perfectly fine URL

12. So is http://voat.co.

13. If you use C++ don't write as if you were using Java - objects don't have to be allocated with new - leave them on the stack, unless you really need to have them allocated dynamically

14. In C - watch all your string operations, use valgrind and maybe some kind of fuzzer, many great bugs could have been avoided in this way

15. If you're caching stuff, make sure that the cache is safe (for example if you display user's private messages, don't cache the template in /tmp/ . Preferably don't cache it at all

16. In Java - use char[] or some secure class for sensitive data - String will stay in your memory until your program dies, or possibly longer. You can't overwrite String with zeroes, like you would with char[]

17. Never ever trust HTTP headers, especially referer

18. In webapps - use CSRF always with your forms, even if you don't think it's needed

19. Also in webapps - don't perform any data modifying operations with GET links, especially with predictable get links - everyone can embed an image like <img src='http://yoursite.com/user/grantPermission?perm=admin&user=evilHacker" /> in their page, and lure one of the admins to it

20. Avoid security-by-obscurity approach, but don't make it too easy for the attackers too. Hiding some obvious stuff will deter script-kiddies

21. Secure your error messages, make sure that your crashing webserver/webapp doesn't spit put whole exception traces

22. If you use tempfile watch your permissions, make sure that you're writing to the same file that you created, use mkstemp or equivalents

23. If you write a suid program/daemon, do the suid-requiring stuff, and as soon as you're done, drop your privilege

24. Don't use regexes for html parsing

25. Prefer whitelists over blacklists when validating stuff

26. Make sure that the default configuration of your program is secure

27. Actually try to make the insecure configuration difficult and obvious (for example, it's more a safete than security feature, but I like hdparm's approach - if you want to do dangerous you have to add an additional paramter: hdparm -J 300 --please-destroy-my-drive /dev/sdX)

28. Minimize the attack surface - the less input/types of input/methods/services/ports you make available, the less combinations of attack are possible

29. Use secure random generators, /dev/urandom on linux sucks, /dev/random is a minimum (and it's not perfect either)

30. Don't log sensitive data... I know it sucks, but know that once in a while someone will end up with DEBUG log level in production

What then do you call someone who has been programming Java for 20 years

Hard to say, my first guess would be "a masochist" ;)

If you're committing to github, throw in the word "retard" from time to time.

PHP has a lot of issues, but I think that a lot of its reputation is due to the fact, that many PHP devs are people who transitioned from HTML and Jquery-javascript, rather than people who learned some C, Java or any other language first. Without that, it's hard to form good habits when starting with a language with permits everything (think $$var...).

Python. It's great when you want to see results quickly. It's also great if you go back to your code after 6 months and want to quickly figure out what is it doing. Doing stuff in a simple and explicit way is one of the main Python philosophies.

When you want to speed up your app, you can easily integrate components in C, and swap the bottleneck with a compiled module. Unless you need to run heavy computations (and GIL bites your ass) Python is a pretty universal solution.

What was your first language?

Pascal, then C++

If this wasn't your first, why'd you transition?

I didn't really transition, I just try to keep up with many languages. I'm decent in Python, PHP and Java. Mediocre in bash, C and JS. Beside that I keep trying to learn other things, right now, for example Haskell. I used to hack simple things in D, Ada, and Common Lisp, but I don't really remember much of that stuff.