Hacker Newsnew | past | comments | ask | show | jobs | submit | Sssnake's commentslogin

>>random redditard

>OK, this is HN.

I believe that was his/her point. I'm clearly not the first person to have noticed that your contributions are few and far between, with much garbage taking up that in between. Your posts would be welcomed on reddit, here they serve only to drag HN down.


Excuse me, I maintained a serious responce in this thread, against some immature kid defending a "satire" submission that wouldn't even have made even reddit. And which, besides dragging 37 Signals in the mud, with FUD and unsubstanciated claims, he also wents on to call people names.

You somehow think this is acceptable, but find my contributions "garbage"? Last time I checked, my "garbage" contribution was the top thread in this post, whereas the "satire" shouldn't even be posted in the first place.


Haskell is already heavily used in finance, and they chose to go this route because all the feedback they were getting from financial firms wanting to use haskell. Your little bubble doesn't generalize to the whole world.


If by "heavily" you mean there are a few notable (and exciting!) projects out there, then sure. But what percentage of working quants code in Haskell ever? Probably <5%.


What's 5% of say $100B? Nothing to sneeze at, I'd say.


I don't see what that has to do with anything. You made a bizarre assumption that the financial world is hard for haskell to break into, when both history and the current behavior of financial firms says otherwise.


>so why an arbitrary restriction saying once X years are up, you can't sell it anymore (or can't effectively since anyone can have it for free).

That is backwards. We set up an arbitrary restriction saying people can't reproduce it, and that is the only reason this artificially created business exists. There is no reason for this arbitrary restriction to extend indefinitely. The business would exist just fine with 20 year copyright, so we should do that.


Yes, it is needed. That is what the license is, special permission.


No. You. Do. Not. It's called a mechanical license.

"Since the Copyright Act of 1909, United States musicians have had the right to record a version of someone else's previously recorded and released tune, whether it's music alone or music with lyrics.[7] A license can be negotiated between representatives of the interpreting artist and the copyright holder, or recording published tunes can fall under a mechanical license whereby the recording artist pays a standard royalty to the original author/copyright holder through an organization such as the Harry Fox Agency, and is safe under copyright law even if they do not have any permission from the original author. Other agents who can facilitate clearance include Limelight, the online mechanical licensing utility powered by RightsFlow. The U.S. Congress introduced the mechanical license to head off an attempt by the Aeolian Company to monopolize the piano roll market.[8]"


You're saying "Mechanical License", but I thought cover songs were Compulsory Licenses [1].

[1] https://en.wikipedia.org/wiki/Compulsory_license#United_Stat...


Would you please not use all caps for emphasis?


You just quoted something saying exactly what I said, while acting like you disagree. Once again, a license is special permission. That is precisely what it is, that is the whole point. Saying "you don't have to have special permission because you get special permission" is insane.


Sync licenses (eg to sync a song with video) require the songwriter's explicit consent in every case, but while a license fee is required to re-record a particular song, explicit consent is not required. That's why one-hit wonders' songs are often hard to find on places like iTunes or Amazon MP3 Store if you don't know the performing artist's name, because anyone can cover it, and there are entire operations who make a business out of producing terrible covers of popular songs to get some accidental purchases.

Any artists who haven't allowed their recordings to make it to electronic distribution are also drowned in poor covers online. AC/DC was a great example of this problem until they finally gave in and released their stuff digitally. There's still a ton of AC/DC cover recordings on iTunes.


>And Haskell's rules are a pain.

How?


Somehow, I find myself caught doing an incorrect indent regularly. I appreciate Python's ':' marker, which unambiguously tells you "either write the next statement on the same line, or indent". I remember it being criticized, but I think it's actually really good.


I don't know how you think that was the point. He doesn't say anything like that. In fact he takes the exact opposite position when dealing with parsing, saying to just write more code. Why would something which literally requires no extra effort (producing useful error messages without semicolons) be misdirected effort, while writing a more complex parser is cool?


I re-read the article and I concluded that we are both right. I direct you to the following statement:

"The principles are rarely orthogonal and frequently conflict."

Producing genuinely useful error messages at all requires a complex parser, IMHO. It's not computationally obvious to look at a line of code and say 'actually you just missed this one character'. Requiring a terminating character gives you at least a sanity check starting point to work with - it alone will catch whole categories of errors.


I think it is worth considering that perhaps obvious architecture is the wrong thing to make, rather than existing languages being wrong for making it.


>and the brags need to be objectively accurate

No, it just needs to be convincing. Plenty of convincing lies (or unproven claims) are used to sell programming languages.


The problem with inaccurate bragging is that the loop ends up unclosed; the advocate says "This language is so fast!", the earliest of the early adopters try it and it isn't fast, and so they slag your language on their blog. And in this case, there is a such thing as bad publicity.

Even when I disagree with the propaganda of a language community (lookin' right at you, Node), there is enough truth that it made it through that gauntlet. In that case I'd argue it isn't that they lie about Node, it's that they lie about all the other languages they putatively compare themselves to. Apparently that strategy does work....


cough, cough


This is a good example of how hn is suffering from the real slashdot effect lately. That is, people posting authoritative sounding but completely wrong information and getting upvoted for it.


Depth doesn't come from complex controls, but complex controls are almost always needed to be able to play a game with any depth.


It's hard for me to gauge whether this is true or not. There are some amazing deep games like chess and bridge that have extremely simple controls. Do these counterexamples disprove the rule, or are they rare outliers?


Games in general don't have to have control complexity in order to have depth, but some genres have to be significantly dumbed-down in order to work with touch controls.

The concept of an on-screen virtual analog stick is great in theory. I practice, its always going to be terrible in comparison to its physical counterpart. Games like Modern Combat 4 are pretty impressive when you first see them, but 5 minutes in you realize two things: The controls are bad, and the entire game has been dumbed-down because the developers know that the controls are bad. Its not even their fault. They did as good of a job as anyone has, but a capacitive touchscreen just isn't going to offer the user a pleasant experience in a 3d fps.

Certain genres are well-suited to touch controls. Many genres are not. Board games and card games work very well.


I would say any strategy game would be just fine with touch controls. Any quest or exploration game too. Many puzzle-type or construction-type games as well. So I don't think touch is a huge problem here except for some genres like hardcore "click-click-click" action or racing games.


>I would say any strategy game would be just fine with touch controls.

I'd agree that board-game style strategy/war games would work, and also quite a few turn-based strategy games.

Its also possible to make certain types of real-time strategy games. Unfortunately, complex RTS games like Starcraft probably can't be done well without extreme oversimplification.


What would be the problem with Starcraft? I can't think of a lot of things that you can't do using touch/twofinger touch/long touch.


I think you'd need to slow down starcraft for it to be playable as the same game. People hit 60-100 actions per minute, like jumping around the map and directing units, setting build queues. Without hotkeys, you'd drop to around 20apm, and you'd be unable to do any micromanagment of units in battle. So it's not that any one action is impossible, just that lots of tactics that require many actions would be impossible.


Maybe for hardcore sport-like starcraft players this is true. But when I played starcraft I never did nearly anything like 100 apm neither my game ever required me to. Yes, that'd probably mean I'd lose miserably if I ever play 1-on-1 against a hardcore sport players, but that's not why I would be playing it and I'd probably never play with them anyway, I'm not in the same league. So I think for a casual player it would be OK. And hardcore players would have their hardcore setups.


There's also the accelerometers, compass, perhaps more. X-Plane is basing the primary controls on those and I find it works amazingly well (I've been playing the Android version).


Mario. Sonic. Doom. Complex controls?


The missing element for all three of those (which are action games) is latency.

With mobile touch-screen controls the game has to somehow register a button-press as soon as a button-press is made.

But it must also never (to a first approximation) register a button-press when a button-press was not requested (e.g. an accidental brush of a finger against the screen).

It's hard enough to do this anyways, but the "input device" does no favors for the game developer either. There's a reason that input devices on consoles and computers have evolved over the years into the shapes they have, they are meant to be easy to hold in a certain position (so that you always know where the buttons are) and perhaps more important, they have tactile features that allow your finger to quickly find and stay near the buttons. It's the reason that buttons and the D-pad are not fully-flush with the shell, even though that might have been more stylish.

Imagine trying to play Super Mario World with a NES-shaped rectangular controller where there are no tactile buttons. This might have worked if you only needed Left, Right, Jump, but even that game required all of the following for the best gameplay: Left/Right, Up/Down (for pipes and to literally scroll the screen up), Jump, Run/Hold/Fireball, Spin Jump, Pause, Drop Stored Item and Shoulder Left/Right (to scroll the screen). And if the input wasn't right you'd either jump into a spike you had meant to run under or accidentally run off a cliff you'd meant to jump past.

The controls on Mario seem complex only because they were so completely intuitive when you were actually playing them but I assure you they were far more difficult to implement than you think. It's not until you start playing platformer games with horrible controls that you can realize the great job done by the development teams at Sega (for Sonic) and Nintendo.


In this context, yes. Precision jumping and strafing-while-turning-while-firing are basically impossible with touchscreen controls; at least I've yet to see them done well.


On a phone, yes, they can be harder to control.


Chess is deep but it's not complex. Starcraft is both deep and complex. Candy Crush is shallow and simple. I can't think of a game off the top of my head that's really complex and really shallow but whatever it is it's definitely not on a mobile device.


I'm not so sure. I suspect writing a near-optimal Candy Crush AI would be quite difficult.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: