nousernamesleft

A language without a global lock to make threads useless.

>Does Mysql lend itself innately to scalability at Amazon/Google scale that is hard to do with Postgres ?

No, quite the opposite actually. Mysql scales poorly with high concurrency, and replication suffers from "oops I stopped working and you have to manually intervene now" syndrome.

They use mysql because it is what most customers want.

Django requires multiple processes, which makes sharing things like connections quite difficult. That is not sane.

Why do you present a false dichotomy? The gnome team (and presumably at least some gnome users) consider them features. Those features are implemented as non-portable crap. Saying gnome works fine on openbsd and pointing to part of gnome working only after an openbsd guy ripped out big chunks of it is just silly.

Not everyone runs some PHP damaged setup where connection pooling has to be pushed out to a proxy. Some people use sane applications in the first place. There is no reason for those people to add an extra layer of latency and potential failure to achieve what they already have.

What a remarkably dishonest argument. The example of gnome running on openbsd is precisely because the openbsd ports people patched the hell out of it to remove all the non-portable crap. Leaving a gnome with a bunch of features gone. And notice Antoine who did that work and provided that screenshot is one of the people who thinks there is no future for gnome on non-linux systems: https://lists.debian.org/debian-devel/2013/10/msg00580.html

You suspect wrong. Being new does not mean the same as being modern. Systemd solves a problem that doesn't exist. You are never going to see that kind of nonsense in openbsd for example.

>Isn't it logical that after 10+ years of making things also possible on BSD, we now have Linux as main focus?

Sure. But then don't keep lying and pretending it is portable. If you are writing linux only software then don't get mad when BSD people call it linux only software.

>My issue here is that types, once defined, rarely change in any significant fashion. Refactoring is (generally) an exercise in mutation of logic, not so much the underlying types. When types do change the code that operates on them drastically changes as well. We're no longer refactoring at that point, we're re-writing and then the issues more or less disappear.

That is the exact opposite of my current experience. I'm changing types constantly. As I flesh out more code, I realize I needed to pass an (Account, Client) not just a Client. Now the compiler tells me every single line in every single file where I need to fix the code to handle that.

>What? In Scala it is perfectly possible to pass an uninitialized reference to a piece of code

Because scala has to make bad concessions to java compatibility. Scala itself is fine, but java opens the door to problems. I did not say scala accomplished this, I said static type systems can. Use ocaml or haskell.

>Just as long as the count and the X co-ord are of different types. Which I'd guess isn't always the case.

But you control the types, that is the point. So if you choose not to use the type system, then obviously it protects you from very little. That is not a problem with the type system, it is a problem with you. You could write a program using only strings if you really hated yourself, and you would thus get absolutely no benefit from the type system. But nobody would be silly enough to blame the type system.

>My belief is that the class of errors they catch are among the most trivial, and most easily caught in testing (unit-testing or otherwise). Thus I simply don't see big gains in either runtime correctness or refactorability. Maybe slight ones, but nothing worth the loss of expression provided by more dynamic languages.

I do not believe your earlier claim to not have been writing java in scala now. If you think there is a "loss of expression", you do not have experience with a modern statically typed language.

>"Static type checking limits programs to only expressing things that the static type system can prove are OK

And if you have no idea how much you can express with the type system, then you draw bad conclusions from that.

>Marlow is _full-time_ at Facebook

And? Before that he was full time at Microsoft. He was never an employee of any sort of official ghc company working on ghc full time.

>Not saying he's joined the dark side like Erik Meijer

What dark side and what is wrong with Erik?

>If that's true, then it'd make Ken Levine just an asshole

That would probably be the nicest thing anyone has ever said about him. He is not well liked by past co-workers or employees.

And yet the whole first part of his talk was problems with scala that are not problems in haskell. And many of those problems exist precisely because of java compatibility, which he acknowledges and says is not a good enough reason to do things poorly. By his own measure it seems like he should be using haskell.

Yeah, for example: PHP's accidental broken support for octal numbers is definitely the fault of all the people who use PHP, not a problem with the language.

>Simon Marlow, Haskell's lead compiler developer in recent years, quit, leaving arguably a much larger gap than @paulp leaving Tyepsafe

Quit what? He is still a ghc developer. He quit his job at Microsoft Research to go work at Facebook, but that doesn't seem quite comparable to quitting a job working at the official scala company on the official scala compiler.

Yes. http://www.ats-lang.org/

>In some sense this is all a moot point, because any difference in development speed between statically-typed and dynamically-typed languages is dwarfed by one's familiarity with the languages in question

I dunno, I have 11 years of python experience, and almost a year of haskell experience. I am more productive in python when doing small (<100 lines) scripting type tasks. But I am noticeably more productive in haskell when writing bigger things. Haskell has a relatively crappy web ecosystem, yet I'm still more productive with snap+postgresql-simple+digestive-functors then I have ever been with any python framework (from zope way back in the day to django and flask). Tasks that are more skewed to haskell's strengths like highly concurrent network servers make the difference even more pronounced.

>Over the years I've worked pretty deeply with both static (C++/Java/Scala) and dynamic languages (Python/Ruby). I simply don't agree.

How did you use scala? Did you write java code in scala as most people with a C++/C#/java background do? Because that would completely explain the rest of your post. In particular, this statement:

>In my experience issues of type safety are rare

I've been doing pretty exploratory, "refactor the hell out of it every other day" kind of coding lately. I would literally rather not program than have had to do it in a language other than haskell. If I were to record this process, I am sure I would come up with several hundred type errors being caught over the course of a week.

>The same types of bugs are going to crop up in Scala, Python, Java, or even Fortran unless you have tests to help you discover those issues.

The obvious example of that being a bad assumption is that static type systems can completely eliminate unexpected NULL errors. It can eliminate "oops I used the count as the X co-ord by mistake" style errors. It can eliminate a huge class of errors that java programmers don't recognize are in fact type errors.

>Logic errors are generally independent of type issues

Which is why it is so nice to let the computer deal with type errors and be able to concentrate on logic errors instead of constantly having to worry about type errors manually.

>There was a program "UO Extreme"

Yeah, I know the guy who wrote it.

>which let you fast walk

No, it let you work around having a high latency dialup connection. All it did was watch for outgoing movement request packets and respond to them with OKs. The server was still checking though. So if you tried to move somewhere you couldn't, your client would see the OK from UOE, then later see the "nope" from the server and you would rebound back to where you were, and you would often get your client's idea of your position desynced from the servers, which was the one that actually mattered.

>You could dye items glitched out colors, because the server didn't check that you chose a valid color from the dialog

Yes, there were many bugs. Large and complex software has bugs. That bug was fixed. Which demonstrates exactly my point, that you can in fact do everything server side.

>You could reveal hidden people, because the server just tagged them with a "hidden" flag, instead of not sending their location at all.

Which packet sets the "hidden" flag again? http://necrotoolz.sourceforge.net/kairpacketguide/

If you just check that they did face the right way, then cheating is still trivial. Just instantly turn and fire instead of just firing (this is what aimbots actually do anyways). The problem is you can't have the client send all 1000 "the mouse position changed" events to the server and have it approve them to ensure that you actually moved the mouse rather than just instantly changing to pointing straight at the enemy's head.

>The F2P game

You've already explained a big chunk of the issue right there. There are many poorly written games. PoE is one of them. That doesn't mean you can't write a similar game well.

First person shooters are split, part server and part client. For example, an enemy comes in range of you, your cheat automatically triggers a "shoot at the precise direction of their head" command to be send to the server. The server does not check if you were actually facing that direction, it does not check if you actually turned to face them in a manner that a human could. So things like aimbots are common where you literally click "next target" and it cycles through all the enemies heads. There is really no way to prevent this kind of cheating. Slower paced RPG style games where you just send "attack target with ability X" can be handled entirely server side. As we start seeing more fast paced action style MMOGs and fewer "computer reproduction of pen+paper+dice" style MMOGs the line gets blurred and more impossible to deal with cheats become problems.

>WoW has a demanding enough latency requirement

And yet ultima online proved that excuse was bogus before WoW ever existed.

You might want to re-read my post. I specifically pointed out that shooters are the standard example of where you can't do everything server side, where as traditional MMOGs you can.

>Cheating in MMO games is always a battle

Cheating in MMOGs isn't much of a battle. Do everything on the server: problem solved. Consider UO did this correctly in 1997 and yet games like WoW came out much later and still did it wrong (let the client choose its x,y,z position and tell the server, rather than asking the server "is it legal for me to move to x,y,z?").

It is faster paced games where you can't do everything server side that are the problem, first person shooters being the prime example.

Realistically that isn't much of an issue. If you are doing something at this level, you pick your hardware for the task. You don't need to support every random old dell PC someone wants to use like a general purpose OS has too (linux, the BSDs, etc). And of course, intel cards are not hard to find.

Huh? Are you sure they weren't marked as duplicates of the original request made in 2010, which was closed as "fixed" in 2012? The functionality was available as a library on hackage starting in 2009. It was added to the standard library in 2012 as part of ghc 7.6.1. Your website says you were testing with 7.6.3.

https://www.haskell.org/ghc/docs/latest/html/users_guide/rel...

Yeah I was just referencing the standard pattern for doing this, I didn't intend it to be complete code. Using a table that stores a new copy of the item for each "update" and having a convenience view that shows the "current" one is pretty standard, and I don't get how it doesn't accomplish his goal.

It is still information, which can be useful. For example, I am working on a redesign of a website where they are insisting on making the text unreadably small because "it looks like geocities" if they text is normal. If these kinds of people repeatedly see people complaining about small text, they will eventually get a clue and the web will have fewer unreadable sites.

That seems like an overly complex way to do the standard:

    create table foo_history;
    create view foo as select * from foo_history order by date_added desc limit 1;

>And "anti-GNU people" is just a lame insult

It is an insult? Like "people with common sense" or "individuals of sound mind"?