Also, while it might be true that "people who don't know much about Haskell" often say that everything is a function, it's also the case that people who do know a lot about the language find the notion to be pedagogically useful: On page 13 of The Haskell School of Expression, Paul Hudak offers that pi (which is of type Floating a => a and thus clearly not a function) "can be thought of as a function with no arguments".
ones = 1 : ones
"ones" is not "recursively applied to itself". "ones" is not a function. "(:)" is a function.
In actuality, "ones" is both an argument and a result of the (:) function (aka "cons").
This works in Haskell because "ones" is not an atomic value or function; "ones" is a "lazy" structure, where some of the elements's values depend on other element's values, and Haskell uses a "call-by-need" graph reduction algorithm to evaluate arbitrarily complex* computations down to values, not in any sort of sraihtforward order suggested by "argument -> function -> result -> lvalue" in an imperative or strict language.
Laziness is at the core of the runtime system's model for computing a result from a program, and it's not something you can translate line-by-line from a non-lazy program, even a functional language program.
I'm not just being pedantic. Haskell (with a runtime like GHC, required for this conversation to really make sense) really is different from other programming systems. ("Programming system"! Not just "language"!).
The runtime system ("RTS") is not just a C runtime that provides a statement language and shim over OS system calls.
The RTS is not "just" a VM like Java VM.
The RTS is (metaphorically) like perl's "perl -nple" or a SQL RDBMS query planner, where the runtime is itself a program that takes your code as input and does its own extremely sophisticated computation that is not at all visible in your program's code.
[] Arbitrarily* complex, but still "causal" structures that admit at least one valid order of evaluation. Trying to define "ones = ones" or other non-disentanglable cyclic dependencies leads to a runtime failure ("<loop>" exception).
[] In some cases, the graph solver might practically fail to solve a graph that is theoretically solvable. Let's ignore that.
http://darcs.haskell.org/ghc/docs/comm/the-beast/stg.html
http://hackage.haskell.org/trac/ghc/wiki/Commentary/Compiler...
http://www.reddit.com/r/programming/comments/i4jb1/haskells_...
-------------
Also, Simon M started Google +ing about what he's up to
One of these things is not like the others.
While we are strongly committed to the vigorous enforcement of intellectual property rights, existing tools are not strong enough to root out the worst online pirates beyond our borders. That is why the Administration calls on all sides to work together to pass sound legislation this year that provides prosecutors and rights holders new legal tools to combat online piracy originating beyond U.S. borders while staying true to the principles outlined above in this response.
We fully support the censorship of the internet, which baffles and scares us. However, this single step may have been too drastic. Please allow us some time to find stepping stones.
Is it possible that Obama just has different values from you? The way I read it, he very plainly is in favor of prosecuting copyright violators, and simply wants to eliminate some of the more egregious provisions of the currently proposed law.
I don't think Obama is trying to obfuscate that view in any way, and is being very clear about it.
Any provision covering Internet intermediaries such as online advertising networks, payment processors, or search engines must be transparent and designed to prevent overly broad private rights of action that could encourage unjustified litigation that could discourage startup businesses and innovative firms from growing.
Proposed laws must not tamper with the technical architecture of the Internet through manipulation of the Domain Name System (DNS), a foundation of Internet security
etc etc
It's not a perfect statement, but real politics is about compromise.
Perhaps a solution can be found so goods manufactures can have some course of action against counterfeit-good websites, without it destroying the internet. I'm not sure what that solution could be, but we shouldn't preclude the possibility.
In much the same way, the emergency of 9/11 is over, yet the patriot act still lives. Similarly, bureaucracies get created, but never seem to get destroyed.
Compromise slows things down, but it never seems to stop it. And compromise always goes one way. That's why we can't be satisfied with compromise.
Just ask Japan and half of Europe after WW2 for example. Maybe that enabled the great 30 years that followed ?
When Lamar Smith held hearings on the bill, Google was the only anti-SOPA tech company invited to speak. Truth is, Google was a cynical choice for the token opposition, since they aren't very popular in congress right now — because of anti-trust, among other things — and they're terribly disorganized when it comes to politics. So there was no real tech input in crafting or modifying this legislation (I don't count GoDaddy). If this response is genuine in its request for legislation crafted by both sides of the issue, it will not be an amended version of any of the current bills. Anyway, I'm told that it's extremely unlikely SOPA will make it out of committee — non-judiciary members who don't have a stake in the issue are inclined to vote no after being flooded by constituent calls, and leadership doesn't like to introduce bills on the floor of the house that won't pass.
If you're offered a seat at the table, isn't it better to try to influence the process? Sure, if you get steam-rolled and ignored you have every right to complain and be angry, but why not do so when and if that happens, not before?
There are many such examples from all over the world; millions if you look at the actual details of laws, rather than just the broad strokes.
So, perfect example of the ratchet effect: go forward, but then not all the way back. Okay, okay, ratchets don't allow any backward movement, but close enough.
We can't win by repeatedly compromising between the status quo and the extremist positions adopted by the MAFIAA. The best we can do is lose more slowly. To win, we need to take the offensive legislatively as well as technologically. I tweeted 25 proposals for this yesterday; here are a couple:
• Instead of fighting to keep DMCA's safe-harbor provisions, let's work to expand them. For example, make filing a false notice costly for the filer: provide a civil cause of action to the speaker whose speech is squelched, with statutory damages of, say, US$3000.
• Legalize noncommercial copyright infringement completely, as long as proper credit is given. The current copyright law was written over the course of 200 years with the idea that it was regulating the commercial activities of publishing companies, and it's far, far too complex to expect ordinary people to understand, particularly in relation to their hobbies. But over the last 30 or 40 years, it's accidentally come to apply every time you SMS your friends or celebrate a birthday in a restaurant. Laws should codify and enforce social norms, not contradict them. This proposal would bring copyright law in line with current social norms among the YouTube set.
• The NET Act redefined "commercial gain" to include the expectation of receiving copyrighted works. Repeal that, because otherwise it criminalizes BitTorrent. (It was actually enacted in order to criminalize David LaMacchia's open-access FTP site, which was a sort of mid-1990s version of MediaFire or DropBox.)
• Require all software developed under government contracts to be released as open source unless it's classified. Taking taxpayer money and investing it in the creation of privately-owned capital goods, such as valuable software copyrights, is straight-up corruption, bordering on embezzlement. If the taxpayers paid for it, they should have the right to use it, as long as that use doesn't interfere with the use it was built for.
• Eliminate FCC device approval for license-free bands like ISM 2.4GHz; prosecute only if illegal emissions occur. This would open up an immense space for hobbyist experimentation in new means of communication, and additionally make it a lot easier to get Wi-Fi cards working on Linux, since right now manufacturers claim the FCC forbids them from providing source to their radio firmware.
The civil court system?
This is Obama's passivity during the LGBT rights activities during 2011 all over again.
(Well, except that I am sure he wasn't paid to sit idly by when the LGBT movement was at its apex.)
Keep calm and carry on.
Despite the economy and foreign policy being by far the most important issue throughout his presidency, his administration has been quite active and successful on LGBT issues.
They've repealed DADT, changed the rules for LGBT in foreign service and passed Matthew Shepard hate crimes legislation.
He's done all this without making LGBT issues a public spectacle, with a Congress that hates him and a public that hasn't made up its mind. It's for these reasons that HRC provides its full-throated support for Obama.
Again -- I'm sorry for derailing the SOPA discussion, but we should keep our facts and impressions well-founded or our primary arguments will fall flat.
This thread seems to be full of a depressing amount of cynicism, FUD, or outright lies aimed at the people responsible, but it seems to be one big ad hominem. I don't see a lot of comments even trying to address the substance of the statement.
I do see several posts dismissing the whole response as empty rhetoric that doesn't say anything, even though there are several measures they say quite plainly and unambiguously they won't support (and it is good that they won't). OK, we get it, some of you don't trust Obama/government/the US/whoever. If you start from the position that they're just generating emtpy waffle to appease the critics, you have immediately rendered any contribution you might make irrelevant, since you presuppose that nothing you say matters anyway.
I don't see a single post acknowledging that any realistic official position on this sort of issue must strike a balance between addressing genuine problems with piracy and addressing genuine technical/ethical concerns with the measures used to do so. In fact, that's my big problem with much of the opposition to proposed laws like this: it's all reactive and complaining about bad laws, but no-one is stepping up to propose a real solution that is more technically and ethically acceptable and still does something about the original problem. Shouting abuse from the cheap seats isn't going to advance the debate in any useful way.
Sadly, the level of debate here is more like Slashdot lite than anything constructive: information wants to be free, they wouldn't have bought it anyway so it's not a lost sale, artists aren't entitled to any income and should just give live performances, the big media companies are asking for it with their consumer-hostile policies, intellectual property isn't real property and copyright infringement isn't theft, yada yada. It's just rationalising breaking the law, and I would bet good money that most people doing so haven't got the slightest clue about how many people work in creative industries and the real economics of those industries, though I'd also bet that the same people are among the first to complain about the state of the economy as their taxes go up, unemployment rises, their investment/pension returns fall, and so on.
So, can we please try to have a constructive, balanced debate about this issue from now on? We have clearly reached a tipping point. There is potentially more public awareness and support for action from other businesses both large and small now than at any time in a generation. We can make a robust case that the whole system is broken and needs to be restored to some kind of sanity that can be accepted as reasonable by most people and enforced against the remainder, or we can continue to throw stones at the glass house and convince the political classes beyond any doubt that the lobbyists are the only sane people in the game.
I agree that there is rampant cynicism abound, but it is not without merit. Obama "quite plainly" (in fact, explicitly) doesn't support NDAA, yet he somehow managed to reconcile has lack of support with making the bill into law. The people believe the white house is full of shit.
>Sadly, level of debate here is more like Slashdot lite than anything constructive:
No HN post is complete without a smug jab at an inferior web community, great way to elevate the debate.
>yada yada. It's just rationalizing breaking the law
Another quality debate technique: aggregate every position enumerated by the silly neckbeards and broadly dismiss them all in a single rhetorical stroke.
>I would bet good money that most people doing so haven't got the slightest clue about how many people work in creative industries and the real economics of those industries
That is just insulting. Particularly on HN, many of those who take the positions you casually dismiss represent a surplus of extremely creative and successful software developers who endure the dubious menace of piracy on a daily basis. The reason these people say things like "do live shows" is because they responded to the reality of a digital world by creating value that is not intrinsically bound to a sequence of ones and zeroes (SaaS etc) instead of refusing to adapt.
>So, can we please try to have a constructive, balanced debate about this issue from now on? We have clearly reached a tipping point. There is potentially more public awareness and support for action from other businesses both large and small now than at any time in a generation.
I agree that a more constructive debate would benefit everyone, but we don't just throw all our ideas out the window in an effort to placate those who might just be on the wrong side of history.
To do that would be to accept the premise that there was an original problem. I think most people here would agree with me when I say that the current laws are entirely adequate to deal with online piracy. We've already compromised. Current laws restrict our free speech a little bit to protect the profits of copyright holders. I'd prefer if current laws were relaxed or repealed, Hollywood would prefer if my rights were infringed upon even more. In what way is the status quo not an adequate compromise?
In the way that the current laws are flagrantly abused by significant numbers of people, at an unknown but substantial cost to the legal rightsholder.
Whether new laws are required to address this situation or more effective enforcement of existing laws would suffice is a different question, of course.
My problem with this kind of legislation however is: - that it vastly overestimates the real scale of the problem - that when legitimate alternatives appear - like with iTunes vs music piracy - the problem tends to evaporate or at least start a significant downward trend - that even if the 2 previous points were incorrect, it still doesn't take into account the relative weight of the problem it tries to correct and the problem it creates
So IMO, not implementing the legislation will not damage the other industries, while at the same time not impede the downward trend in piracy - provided legitimate alternatives are available. Implementing the legislation OTOH may or may not stop piracy quicker, at the cost of a lot of collateral damage.
If lawmakers absolutely must legislate something, I'd propose to make laws that remove barriers and obstacles to implement those "legitimate alternatives". For example, set up globally centralized licensing to break down geographic barriers, or an official way to figure out from who you need to license a song, a movie, code. Basically remove every obstacle between the consumer and the licensor. If that happens, I'm willing to bet that piracy will be a fraction of the problem it is now.
But yes, you'll never eliminate it completely - but I think that even the most strident pro-IP people realize they'll never be able to banish all piracy from this world.
The times are changing. I'm not saying "they don't get it" as in "they're stupid, they don't know what they're talking about" (they certainly do, otherwise they wouldn't have received lobby money), I'm just saying that they cannot see that the whole world is changing, or if they do see that, they have the audacity to think that they can do something to stop it.
Anyway, as a guy living in Europe this whole SOPA thing reminds me of one of Marx's stories, about a English industrialist in the mid 1800s who had just set foot in Australia and who wanted to mimic the same capitalistic conditions there (children working 16 hours per day etc.) as he had done in native England. But much to his surprise, Australia being a new world with new rules and capitalism not being a universal or Platonic-like truth, he wasn't able to exploit people in Australia as he used to do in England.
And about "cynicism", I know I'm probably in the minority, but to my knowledge there's nothing wrong with thinking critically about the world surrounding you and not just thinking that there's some "ideal" to which all those around you would eagerly submit.
But some things are not changing. Good content does not create itself. Most of the time, the best content is not created by hobbyists working in their spare time, either. We've been trying this experiment for a while now, and everything from Open Source software to self-published books paints a very clear and consistent picture: while there are the occasional gems, most of the work simply isn't very good by professional standards.
Creating the most informative, useful, interesting or entertaining content usually involves a lot of hard work. Often that work is done by a whole network of people with specialist skills. Often that work is not particularly enjoyable or glamorous. Often that work is not done by people who are going to reap vast rewards if the product is a hit, but rather by people paid a relatively low wage for their efforts. Still, the people doing that work have rent to pay and mouths to feed and interests of their own to support.
Now, I will be the first to agree that modern copyright laws in many jurisdictions have gone way too far in some respects. That is harmful to consumers, because it prevents them from doing otherwise reasonable things (or punishes them if they do those things anyway). IMHO, it is also harmful to businesses, because any law that loses the support of the public by going too far also loses any useful impact to the extent that the underlying idea is reasonable.
But a lot of the nay-sayers in this debate seem to see only the free side of this situation. They see that the marginal cost of distribution is now near zero, and conclude that everyone should be entitled to good content for free because it's out there anyway. They ignore, deliberately or out of ignorance, the often very high fixed costs associated with creating good content in the first place, or they decide (within some ethical framework that I have never understood) that it's OK for other people to contribute to that cost but they don't have to themselves. Then they rationalise their position with the kinds of excuse I mentioned before.
If this trend continues, we will develop an entire generation with a horribly damaging entitlement culture, and unless a viable alternative economic model develops sooner rather than later, content production will become a race to the bottom and good content (by today's professional standards) will become one of those mythical things we explain to our grandchildren starting with the words "When I was your age...".
This is not inevitable. All it takes to stop it is near-global standardisation on a fair economic framework that promotes the creation of good content. Whether that is copyright or something else is an interesting question. But as long as we confine the debate to a black-and-white "Big Media Bad, Cheap Freeloading Good" or "Cheap Freeloading Bad, Big Media Good" result, no real solution is going to get anywhere and we're just going to see a continuing arms race between commercial content producers and freeloaders with increasingly absurd penalties hitting the players on both sides when they lose.
While it's tempting for me to caricature my idealogical opponents using examples of pithy, meaningless platitudes such as this one, I shall strive not to follow your example. If you really do value honest discussion, I think you'll find such preaching to be self-defeating.
> "...everything from Open Source software to self-published books paints a very clear and consistent picture"
Please do break this down with some stats and examples. You can't possibly be so naive to think this statement will be taken as axiomatic.
> "...while there are the occasional gems, most of the work simply isn't very good by professional standards."
Ah, an ad-hominem of your own, most self-righteously disguised. I am writing this comment entirely using tools that are covered under OSS licenses. I earn my living using the same tools, and my work is also covered under an OSS license. You'll note that I said "earn", and from that you might deduce that commerce and OSS are not mutually exclusive. You might also observe a counter-point to your rather haughty categorizations of "professional" and "hobbyist" creation. I even have hope that you may perceive the irony of accusing your opponents of being "black-and-white". Speaking of which...
> But as long as we confine the debate to a black-and-white "Big Media Bad, Cheap Freeloading Good" or "Cheap Freeloading Bad, Big Media Good"
You seem to have created your own personal straw-man using the most radical contingent of anti-IP viewpoints. I'm surprised you didn't call them freetards. Your post consists almost entirely of shallow, difficult-to-argue-with assertions seemingly aimed at thick-headed techno-communists. Do you honestly expect many folks here to recognize only the marginal cost of content production? Any answer other than "no" will tell me that you haven't been paying much attention. So long as you only hear what you want to hear, you won't be able to intelligently converse with the many folks here who are somewhere in between the extremes. Folks like me, who might say things like...
- I highly value content and the minds that produce it. Perhaps more than anything else, art is what makes life worth living for me. I require it, and I thus require content producers to produce it. I am willing to pay for it, but like everything else that I buy, the cost must be sustainable.
- Technology has long been at point where content is presented and used in its purest form: a totally non-rivalrous and totally non-excludable commodity. The carriers required in earlier times, e.g. books, CDs, etc., are no longer required. Any piece of content is now exactly equivalent to any other piece of information -- the words of a book, a song, a picture, an idea, a rumor, a number. There is nothing novel to me about the idea of copyright, or in its value as a temporary monopoly on the distribution of information intended to incentivize the creation of said information. Again, if you pay attention, I think you'll find this to be a commonly accepted notion around here.
- When non-rivalrous and non-excludable goods are treated like rivalrous and/or excludable goods for the purposes of regulation, bad things generally happen. The methods by which this must be done are obtuse, ineffective, and in my opinion, often unethical. Think censorship, DRM, security-through-obscurity, etc.
- It seems to me that if someone wants to make money from a completely non-rivalrous and non-excludable product, the onus is very much on them to distribute their product in a commercially viable way. Some artists are embracing the inevitable challenges of making money from information in today's market. The large distribution cartels (e.d. RIAA) have completely rejected them, and expect governments to maintain the old business models for them using force.
There is indeed much room for compromise, but be not mislead about the depth of the convictions of those who disagree with you, nor of the scope of their knowledge and experience.
To address your specific points:
> Please do break this down with some stats and examples.
OK, Open Source first:
Linux vs. Windows/MacOS (on the desktop)
OpenOffice vs. MS Office or Apple iWork
GIMP/Inkscape/Scribus vs. Adobe Creative Suite
Blender and related tools vs. Autodesk suite and related tools
??? vs. Exchange Server
??? vs. Skyrim/Battlefield 3/any other AAA game you like
??? vs. any serious CAD package
??? vs. any serious business admin suite
And those are all big name products, the kind of thing where there is critical mass for developers to build and sustain a serious OSS project, and where there are plausible alternative revenue streams available via selling support, commercial sponsorship by a company that wants to software to exist for other reasons than selling it directly, etc. Generally, OSS does best in those sorts of areas: system/server software, programming software, geek toys, mass-market content production/consumption tools, basically anything a lot of geeks are going to be interested in. There are very few OSS success stories in more specialist niches or in building the kinds of professional software that keep businesses running.
As for self-published books, I'll give you the challenge on that one: please name one textbook that you would want your kids' school to use that was self-published by the author(s) without any sort of copyright-based incentive scheme but is as good or better in quality than textbooks produced following the traditional publishing route.
> Ah, an ad-hominem of your own, most self-righteously disguised.
You need to look up what ad hominem means. I am not attacking the creators of the work. I am attacking the quality of the work. There is no logical fallacy there.
> You seem to have created your own personal straw-man using the most radical contingent of anti-IP viewpoints.
The trouble is, they aren't particularly radical viewpoints among the anti-IP crowd. Read any debate on tech-heavy forums like this one or Slashdot, and you'll find plenty of people who really believe we should abolish penalties for any non-commercial copying of works under copyright. Plenty of people really do quote the "information wants to be free" line and use the near-zero marginal cost to justify rampant piracy while totally disregarding the fixed up-front costs of development. Plenty of people really do claim that piracy isn't costing copyright holders anything because there's no guarantee that anyone ripping a copy without paying would have paid for a legal copy anyway, a position about as plausible as the movie industry claiming that their actual losses due to infringement are greater than the global GDP. This is not some extreme caricature I've conjured up to make an argument. These are views publicly expressed by large numbers of anti-copyright advocates all the time. When faced with this sort of advocacy, often by people who are essentially defending breaking the law by claiming it's bad law, it's hardly surprising that politicians who aren't particularly technically literate are sceptical.
> Do you honestly expect many folks here to recognize only the marginal cost of content production?
Based on the overwhelming consensus of the comments that had been made when I wrote my first post to this thread -- not to mention the common groupthink on various other forums with an ongoing interest in this subject -- I not only expect it, I think it is pretty much proven beyond any doubt. A few more reasonable people have posted to this particular discussion since, fortunately.
> It seems to me that if someone wants to make money from a completely non-rivalrous and non-excludable product, the onus is very much on them to distribute their product in a commercially viable way.
And what way is that, exactly, if we don't enforce copyrights?
> Some artists are embracing the inevitable challenges of making money from information in today's market.
And they represent a tiny fraction of the content consumed today.
Indeed, one of the strongest arguments for the effectiveness of copyright as an economic tool and against the effectiveness of various oft-proposed alternative incentive schemes is that typically today's copyright laws don't prevent anyone from adopting one of the alternatives if it really does provide a better incentive. However, almost no-one has done so successfully.
> The large distribution cartels (e.d. RIAA) have completely rejected them, and expect governments to maintain the old business models for them using force.
That is how laws work. But bizarrely, a lot of people seem to think it's entirely reasonable for the law to prohibit copyright infringement, yet for the entire burden of finding infringers and bringing them to justice to fall on the copyright holder. I wonder how those people would feel if their houses were burgled and the police told them to do their own forensic work, arrest the burglers when they found them, and take them to court personally? Or, to give a more directly comparable scenario to avoid any concerns about comparing physical and intellectual property, how would those people feel if they were tricked out of a normal return on their retirement savings by professional fraudsters, and the police gave a similar response?
> There is indeed much room for compromise, but be not mislead about the depth of the convictions of those who disagree with you, nor of the scope of their knowledge and experience.
The scale of global piracy makes the convictions of those who disagree with me (or just don't care) quite clear.
Laws concerning art should get us as close to that society as possible. We should value both our freedoms and plentiful art, not just the latter as you seem to be arguing.
Copyright and patents are a compromise: since there are no effective business models that generate high-quality liberated content, we will make do with high-quality restricted content instead. It's the poverty mentality: since we can't have both our freedoms and high-quality content, we'll take just the latter.
Increasingly, though, the premise of that compromise is no longer true. Thanks largely to the Internet, more and more businesses are successfully generating high-quality open source software, and more and more artists are distributing high-quality art that they encourage people to be creative with.
Since we don't need that compromise as much any more, one would expect to see IP laws get gradually less and less restrictive. Every year, we should be seeing fair use getting expanded, copyright terms getting shorter and software patents getting weaker. We don't need to abolish copyright and patents all at once, until we find good enough business models that are widely applicable. But we certainly don't need more laws like SOPA.
> "But some things are not changing. Good content does not create itself. Most of the time, the best content is not created by hobbyists working in their spare time, either. We've been trying this experiment for a while now, and everything from Open Source software to self-published books paints a very clear and consistent picture: while there are the occasional gems, most of the work simply isn't very good by professional standards."
I suggest you familiarise yourself much more with open source software. I would argue that the best operating system kernels, the best browsers, the best servers, the best programming languages, the best databases, the best virtualization software and the best media players are all open source. Most of these (such as Linux, Apache, Firefox, Chrome, Hadoop, etc) are not developed solely by "hobbyists", but primarily but by fully-paid developers. The same goes for books: a lot of O'Reilly's books nowadays are licensed freely, and yet they still make a profit. These products are definitely very good by professional standards. Computer engineers were the first to catch on to these business models, but they will spread to other types of art, just as the Internet is spreading across domains. The law should embrace this change, not resist it.
This time they tried the excuse of music and movies (because hey, who doesn't like good music and entertainment?). Next time they'll try with something else (maybe the usual standby, child porn).
Make no mistake about it: SOPA/PIPA will happen, unless we really ratchet up the resistance. A few phone calls to a senator don't cut it. Users likes us, and companies like Google, Facebook, etc. need to put down some serious cash.
Welcome to the big leagues!
"Information wants to be free" is real, and passing laws to stop it is a fool's errand.
We should be working to harness this new distribution network, and build content businesses that work with piracy, not against it.
"While we have serious concerns with SOPA as written, we look forward to working with the Committee to find focused mechanisms that effectively target foreign rogue sites. Already, Google and other companies are engaged in voluntary, industry-led efforts to attack the problem. As detailed below, we believe that legislation guided by common sense principles and focused on eliminating the financial incentives for rogue sites – while avoiding collateral damage – would receive wide support from the technology sector."
Not everyone who is against SOPA is also (publicly) OK with online piracy...they limit their arguments to the logistical problems introduce by SOPA enforcement
edit: minimap exists! (Obviously only in GUI Emacs)
Animated sub-line scrolling probably requires hacking the Emacs source. Indent guides might be possible just in elisp, but I don't know how good they would look.
http://stackoverflow.com/a/4160949
http://www.emacswiki.org/emacs/SmoothScrolling
http://zwell.net/content/emacs.html
https://emacs.wordpress.com/2007/09/10/smooth-scrolling/
Yes, trying to do fancy things in Elisp can be a bit kludgy.
you can't implement minimap in CLI. It's a GUI concept.
Feel free to ask questions here. I'll try my best to respond to them. We're preparing for ICFP tomorrow, and my train back from Yokohama was pretty late, so I probably won't be able to answer right away.
I originally wrote/released the enumerator package because iteratees seemed really interesting, but I didn't like the function names or docs. That's it. The sole advantage enumerator has is that it's prettier.
Compare:
mapStream :: (Monad m, ListLike (s el) el, ListLike (s el') el', NullPoint (s el), LooseMap s el el') => (el -> el') -> Enumeratee (s el) (s el') m a
Map the stream: another iteratee transformer Given the stream of elements of the
type el and the function (el->el'), build a nested stream of elements of the type
el' and apply the given iteratee to it.
map :: Monad m => (ao -> ai) -> Enumeratee ao ai m b
map f applies f to each input element and feeds the
resulting outputs to the inner iteratee.
After wrestling with this since thursday, I wrote a function that's something like (wrapEnum :: Enumerator ai m b -> IO (Enumerator ao m b)), so I can convert an enumerator of one type into an enumerator of another type (I'm not looking at the code right now; that signature is obviously lacking, but it's the idea, anyhow). I think that's probably horribly wrong, but I just can't wrap my head around the type and behaviour of Enumeratees, even after reading the really pretty and simple ones that come with the snap-core package.
I think the idea is awesome, and I'm very happy about being able to use other people's Enumeratees like the various compression ones and ideas that I can express as a map or a fold, but I'm definitely missing something.
Making them return a Step allows both types of extra input to be stored, and possibly consumed later by other iteratees.
You can use (=$) or ($=) to modify how extra input is handled (by discarding it at certain points). Your wrapEnum is probably a special case of ($=).
It is extra work to use persistent's enumerator interface though.
When some people talk about functional programming, they talk about monads and iterating with recursion and lambda calculus.
Other people talking about functional programming mean using data-oriented abstractions, where functions operate on data in well-defined ways, to avoid state and interlocked dependencies[3]. I've been calling the latter a "functional style", but clearly there is ambiguity and people get turned off and say things like "we're using an OO language why would i want FP"
in Avdi Grimm's talk "Confident Code"[2] he calls this style "narrative structure", compared to "haphazard structure"[4]. I like that; "functional" envokes all sorts of emotion about being hard to understand and unnecessary. "Narrative" or "confident" or "data-oriented" are more articulate, and don't evoke flame wars.
Avdi's example (code screenshot) is the most articulate example of this I've yet seen. https://lh4.googleusercontent.com/-Cs-muD17ato/Tk6b1Rb9MwI/A...
And it's in ruby. Nothing hard here, but it meets a functional style per John D Cook's definition[1]: "OO makes code understandable by encapsulating moving parts. FP makes code understandable by minimizing moving parts." "functional in the small and OO in the large" seems a good path. The Scala community seems to get this, and seems to me Scala is mainstreaming much quicker than any of the pure functional languages.
[1] http://www.johndcook.com/blog/2010/11/03/object-oriented-vs-... [2] http://avdi.org/talks/confident-code-2010-01-12/confident-co... [3] http://www.dustingetz.com/how-to-become-an-expert-swegr [4] http://www.dustingetz.com/confident-code-vs-timid-code
That's what I like about Erlang as well. Once you recognize processes as your objects, this philosophy just flows out of the language.
It is paradoxical. Fifteen years ago, OO was this giant, over-sold piece of junk that was going to magically make random code piece. But, but it does/did have merits for ginormous software operations employing many, many mediocre programmers. It contains a simple metaphor and simple device for turning totally bad code into slightly less bad code, for allowing completely unrelated stuff to relate together in a half-assed way. OO isn't about giving programmers more power but allowing the power one programmer to interface with that of another (even perhaps another inferior programmer).
FP is about power. You could anhilate whole galaxies with the power of a third order functional if your mind was strong enough to wrap itself around such a thing - from another link currently up: "Lisp's purpose in the programming language galaxy is to assist our most gifted fellow humans in thinking previously impossible thoughts, remember?" Essentially, neither Lisp nor FP nor Logic Programming exist to collect the multitude of junk that enterprises have and make it more sensible.
==> I am speaking "jocularly" here. I actually think collecting the junk of enterprises is a worthy activity. Large scale programming in a typical enterprise (not Google) requires you to make allowances for a multitude of human foibles and this can expand you as a human being and not just a genius.
Just consider, there are geniuses who just produce "amazing stuff" for others to run after trying to understand, there are geniuses who explain to other geniuses and there are geniuses who explain to normal people. All have their place.
haha, nice. i don't think it's quite that cynical, hybrid OOP/FP languages like Scala seem to have a better industry record than pure functional languages, at least for the internet companies we hear all about.
OO isn't inherently bad, and FP isn't inherently good, but knowing how to think in FP will certainly make us better engineers, and the "functional in the small, object-oriented in the large" seems to be gaining acceptance in elite circles.
Type system for OOP was developed during some 25 years: http://lucacardelli.name/Talks/2007-08-02%20An%20Accidental%...
Lambda calculus was introduced in 1936 and in 1948 it was given simple type system (along Fortran one, which, in turn, was introduced in 1958, ten years later).
Year after Simula-67 was introduced, logician Hindley presented a polymorphic type system with type inference for lambda-calculus, which was later rediscovered by Milner and incorporated into ML in 1978.
Simula-67 didn't have proper parametric polymorphism. I know no such examples before ML.
Functional programming is based on logic and could be a basis for logic on its own. Consider Type Theory by Per Martin-Loef. Or even simpler extension of polymorphic type system fo lambda calculus: Haskell's type classes, where type represents theorem, and function text serves as a proof.
OOP, on other hand, does not represent some simple kind of logic. I emphasize simple, because Luca Cardelli finally found some logic out there.
So I think that OOP is inherently less useful that FP.
well i mean most software isn't understood, using Linus's metaphor, most software works due to "years and years of testing on thousands of machines", not due to "thinking and analyzing"[1]. and, i think, teams that are capable of "think and analyse" can out-compete teams that don't.[2]
[1] http://www.dustingetz.com/linus-think-and-analyze-motherfuck... [2] http://www.dustingetz.com/re-seth-godin-how-do-you-know-when...
But "thinking and analyzing" I think also applies to my problem with type theorists! They spend a lot of time coming up with new ways to use various formalisms to capture various intents of the programmer (like the deadlocks and accounting of effects in an uncle post), but they don't spend much time doing science: the kind of science that happens when you have a control group. They've got their heads down at too low a level.
That's a bit of an attack on the whole edifice of computer "science", but I think it's long overdue. I don't think we're going to find any magic formalism that revolutionizes the world, making writing programs of arbitrary complexity trivial for schoolchildren. I think we need to spend more time looking at actual people, their strengths and weaknesses, and crafting our formalisms around those - and that work is only honest if it actually measures effects on average joes doing work, not rework of existing programs by talented graduate students.
Types allow requirements changes to be propagated through all program. State-of-the-art type systems even allow accounting of effects, like prevent deadlocks by ensuring a specific order of locking: http://www.cs.st-andrews.ac.uk/~eb/writings/fi-cbc.pdf
This is just another tool in a toolbox. You can use it. Or you can throw it away as "no one seem to use it".
"Types allow requirements changes to be propagated through all program" - what does this even mean, and why is it a justification for powerful types? I designed a system once that let you describe the program at a high level, using a DSL. I've outlined it several times on this site here (here's one link: http://news.ycombinator.com/item?id=2192322). Now that system allowed requirements changes to be propagated throughout the whole program, because the level of description of the program was dense enough that it could just about be considered detailed requirements (i.e. it was powerful - see below). It worked because it was focused on a reasonably precise niche. It did enough checks during the compilation process that you could be fairly sure that if it didn't find any errors, it would work without bugs (i.e. it was good - again, below). But the level of type system it had was no more advanced than Pascal - and I mean early Pascal, no objects etc. If you can get the same effects without a very abstract and powerful type system, isn't that better, because it reduces the overall expressiveness of the language - i.e. reducing the solution space that needs to be searched? Form can be liberating.
Preventing deadlocks by ensuring a specific order of locking. Fantastic; good work. How many people are using it? Which large shipping systems are using it? What was the prior rate of deadlocks for similar systems at that level of complexity, how long did those deadlocks take to be fixed, and how much time and money was saved by using this new technique? Because frankly, deadlocks are trivial to debug; the relevant threads are stopped, and after you attach a debugger the stack traces tell you exactly which locks were taken and in which order. Debugging races is a wee bit harder.
I have TAPL by Pierce right here on my bookshelf. Here's a typical sentence which illustrates my problem: "Perhaps the best illustration of the power of recursive types is the fact that we can embed the whole untyped lambda-calculus - in a well-typed way - into a statically typed language with recursive types." (pp 273). It seems to me to take for granted that a statically typed language is good[1], and that a good measure of power for a statically typed language is how expressive it is (i.e. what shapes of programs it can express, not e.g. how syntactically light it can be in doing so). And this is probably right and good, for type systems. But I have a different perspective of "good" and "power" in a programming language (as distinct from a type system). A good language is one whose target audience finds it easy to express their intent in such a way that the computer can understand. A powerful language is one in which complicated effects can be expressed with succinctness. And this is the core of it: type theorists spend entirely too much time on theoretical benefits, and far too little time on whether these benefits are worthwhile. Perhaps that's not their job, you say: and I agree to you to the extent that you also agree, then, that much of their work is irrelevant because of that.
[1] I happen to like statically typed programming languages, but I understand why some people don't. I wrote an extended reply on this topic to Paul Biggar some time ago, again on this site: http://news.ycombinator.com/item?id=1110653
Software engineering is the only field of engineering whose practitioners do not use a basics grounded in math. Electrical people have Maxwell, ohm, gauss etc. Mechanical engineers and dynamics, civil continuums and so on. None of these professions you will note, came after the math. The math came as a result from studying and generalizing on these and then feeding the results back providing a net gain for both. This leads me to believe we are in early stages yet. We have the catapult without trigonometry. We do not have enough understanding to build stuff to withstand earthquakes. You say that most languages don't have well founded types but you fail to note that many of those same projects often have massive teams, massive code bases, fail often, run over time and are insecure.
But all that said, programming is different isn't it? You can get instant feedback and build something that you think is good because it fits all the white swans you put inside it. So I think before we have a foundation we will need tools that are built from and require a basic understanding of category theory and types. These can then be used to quickly iterate tests and do so with strong guarantees without having to write annoyingly tedious constructive proofs. Genetic programming is stupid but what if it could reason about types and try hypothesis on a meta level as well? Or what if tools such as http://lambda-the-ultimate.org/node/1178 were developed into the typical programmers toolchain? But yes, complex types without tools are a hard sell.
"You say that most languages don't have well founded types but you fail to note that many of those same projects often have massive teams, massive code bases, fail often, run over time and are insecure" - are you suggesting that correlation is causation? Of course you aren't. But you might be guilty of thinking that something must be done, powerful type systems are something that seem good, therefore they should be used. And it's precisely this kind of implication that I'm skeptical of. When we start seeing substantial bodies of industrial software using advanced type systems rather than incorporating more limited, less orthogonal and less general subsets, I'll dial back my skepticism; but I'm willing to bet, at this point, that if that does happen, we won't have seen the end of massive software failures. I think that's a social problem, not a technical one. Our reach forever exceeds our grasp.
Already I use types in Haskell and F# to help me figure out how to layout the code - I write some basic code where I know which function it will feed into, I don't have to think much as I try to get the code to fit the types. Nothing fancy but still highly useful.
As for code transformation I don't mean generic stuff like Visual Basic to Java, I mean having a team able to write the tools themselves with full awareness of the requisite semantic mappings. Or even better, creating a dsl for the domain and then having that map down to appropriate platform specific code. But it need not be traditional development you could extend it to machine learning - say you are doing genetic programming to fit data, using types to have some level of axiomatic reasoning rather than random cross over may be fruitful. There are all sorts of uses where application of basic - not fancy theory is helpful.
That is hilarious! I just showed this to my black, British cat, Mr. Fluffer Wickbidget, III, and he spit out the milk which he had been lapping from the palm of my hand.
You should sit down with the brilliant Hongwei Xi, the creator of the amazing ATS programming language, and see what he thinks of your jocular comment. If you're lucky, he might explain to you the reality of his Applied Type System, which not only provides for a very practical use of types, with the side benefit of theorem proving, but has also been shown to be almost as fast as C.
... OOP is inherently less useful that FP ...
Is it that hard to see different uses for different languages? Original BASIC was neither OO nor FP and came after both. Still it satisfied a particular need. C++ is the worse programming language in the world, except for all the others - in the domain it is used in.
Okey. How about language that could encompass all of them? The thing about such language is that it have to be functional one, at the core. Be it Lisp, or Haskell, or Agda2.
Let's look at Haskell. It has OO: http://homepages.cwi.nl/~ralf/OOHaskell/ Everything in mainstream OOP languages and then some, all in Haskell type system. It has BASIC: http://hackage.haskell.org/package/BASIC
I embedded to Haskell a MIPS assembler, a language to describe CPU cores, and some other things.
I am not an expert in Lisp, but an avid reader of HN should know that it pretty good in encompassing languages.
As for C++, it's domain shrinks every year.
I just think it's important to not to confuse power and flexible with usefulness. Rigidity and limits have their uses.
As far as c++ goes, it's market share shrinks every year yet since the market grows and c++'s share began huge, c++ gains more users and more market position every years than the total users of functional programming languages. That may change in the future. FP will have to show its usefulness and not only its power and flexibility for this to happen.
Mobile seems to be generating a resurgence of interest in C++. Squeezing every last bit of performance out of tightly constrained CPU and RAM matters again.
The only metric is loses on is its high score in impenetrability.
They split program into slow and fast parts, slow parts used compact byte-code interpreter, fast parts were compiled into native code with optimizations.
They didn't used "code compression" like Forters do - Forters refactor common pieces of code into separate definitions. Nevertheless, they made quite balanced system.
When I finally come to create my own map of some small island of history of computing, namely "type systems", I was thrilled, no less.
The superheroes are among us, I think. ;)
Functional programming is just the general notion of using more functions, and less computer-architectury things, to express your ideas. It's not necessarily about map/reduce, monads, or whatever. Encode your ideas mostly as functions where possible. That's it.
It's bad to say that functional programming is hard on purpose, or that it makes you a part of some elite cadre. Functional programming should be, and usually is, no harder than any other way to explicitly write down your ideas. The whole point is to make it more simple to express your ideas in a way that can be evaluated by a computer. Functional programming isn't hard. Programming is hard.
Umm, no, that is not what functional programming is. Functional programming is, basically, programming without side-effects. A purely functional language will have variables that are completely immutable. This is a bit of a shift away from the way things are done in C or C++.
Speaking just for myself, I started into the programming world with Java (not counting QBasic), and I am finding it incredibly hard to wrap my brain around the idea of functional programming.
My understanding is that most programmers that have a background primarily working with non-functional languages have a challenging time initially grasping the concepts of functional programming. However, I would guess that a programmer that learns a functional programming style early on would probably have very little difficulty understanding non-functional constructs.
For more information, I would like to point you towards some easy reading:
* http://en.wikipedia.org/wiki/Side_effect_(computer_science)
* http://learnyouahaskell.com/introduction#so-whats-haskell
Edit: To whoever down-voted me, I would appreciate some explanation of your views. The fact is that functional programming is not just using functions. The article plainly refers to functional programming languages and not simply using functions. There is a difference.
As my cousin points out, it's true that it's easy to think of functions as just being macros in a language like C. If you call a function which doesn't have a return value, and which modifies some global state, that's not a "real" function, just a stored procedure.
However, if you write a C function which doesn't modify global state, but simply takes an input and returns an output, as even novice programmers do all the time, hey presto— that's the functional paradigm! There's nothing mystical about it, and what the GP is saying is that telling people who have done this that functional programming is something different is fundamentally confusing.
Thank you for your thoughtful reply. I really do appreciate it.
It isn't the programming that is the hard thing. Writing some code to do something meaningful is not what is giving me a problem. Actually, it is trying to develop a deep understanding of functional programming that I am finding difficult. Maybe the problem is that I am confusing functional programming with purely functional programming?
My apologies to tumult if it came off that I was lecturing in my original post. I find it challenging to get tone perfectly right on the Internet. Face to face conversation or conversation over a phone is far better.
I think maybe this entire thread comes down to a question of semantics. When I program in non-functional languages I tend to lean towards using map/reduce type constructs a lot, but I never really thought of that as "functional programming". I guess I always thought that in order to really do functional programming, you really needed to have some kind of deep understanding of it.
Maybe if I had a formal computer science background, my perspective would be a little bit different because I would have more easily seen the point that you are making. As it stands, my background is in the social sciences and my knowledge of the science part of computer science is sometimes lacking.
Perhaps you are right, I should have been better informed before attempting to inform others. But if I had not typed my original post, then I would have never received your helpful reply and I would still be in the dark!
Yeah, you nailed it. Writing a whole program with purely functional constructs is a little mind bending, since procedurally fundamental things like "printf" don't really exist. But that's just something that's much easier to do procedurally; it's hard for everyone, and there's no real secret to understanding it.
The important thing to remember is that languages don't have just one paradigm. An imperative language with first-class functions (as most high-level scripting languages have) is functional, just not "as" functional as, say, Haskell. You can use functional concepts in a language which isn't purely functional, just like you can use OO concepts in a language which isn't purely OO.
The good news is it sounds like you get functional programming much more than you thought, and you've definitely got the right attitude towards learning.
As long as you're open to being corrected, and honest about the limits of your knowledge, there's nothing wrong with trying to teach something you don't fully understand yourself. Teaching is one of the best ways to learn. Keep it up :)
My understanding is that most programmers that have a background primarily working with non-functional languages have a challenging time initially grasping the concepts of functional programming.
However, I would guess that a programmer that learns a functional programming style early on would probably have very little difficulty understanding non-functional constructs.
I'd argue that the algorithmic / data structures material (maybe with an intro to some FP language mixed in) is much more important than those elective classes, because the elective stuff is much easier to pick up later on (as needed), while someone who doesn't know their algorithms could spend a whole career writing buggy, slow code because of it.
Sorry, typed this on a phone, hard to edit.
f(x) = 2x + 5
The only difference between the trivial example with f(x) above, and say, Haskell, is that the functions you're working with in Haskell are much more complicated. Boil it down though, and they're still pure, mathematical functions nonetheless.
Now, you can (should?) write purely functional programs in C if you follow the same principals. The main difference is that C doesn't force you do write your code this way, and since writing purely functional code can be a bit tedious, most people don't.
This leads to impure functions in your code, like when you read a file from disk -- if the file is there, the function does one thing; if not, it may do something else (like crash). Since the output of an impure function can vary depending on when/where/why/how it's executed, it can be much harder to find bugs in it, since the code may compile and run just fine until the moment it doesn't.
Anyway, that's the basic rundown on FP. I'm not an FP expert, so if I've missed anything, someone please correct me.
But the term "FP" is as much about freedom from side effects, lambdas, currying, and sometimes lazy evaluation as it is about the superficially-similar functions in a typical imperative language.
The fundamental language feature that makes true functional programming possible is first class functions, since that allows higher order functions and anonymous functions. The lack of that feature in most mainstream languages is why functional programming feels so foreign to most programmers. Sure, you can write functions without side effects, but making good use of them without polluting your namespace, explicitly passing around function pointers, or having lots of extra boilerplate code lying around is difficult in a lot of languages.
That's constantly changing though. I think as more languages start adding support for higher order functions, even established languages like C++ and Java, we'll see more and more people using a functional style and less nonsense discussion about how "hard" it is, because it really isn't hard at all. Already, you see bits and pieces of functional Javascript code littered all over the Internet on a regular basis.
In fact, I'm willing to bet that at some point in the future, functional programming techniques be considered easier and more natural than a purely imperative approach, simply because more programmers will have encountered it sooner in their programming careers and made effective use of it. It'll be an everyday occurrence to meet a programmer who uses anonymous functions for callbacks and commonly makes use of fold, reduce, and map instead of explicit loops and state variables.
Meanwhile, meeting someone who knows what a pointer is or even how to manage heap memory will be a one in twenty event, and chances are that person will be an embedded developer who also knows how to write interrupt handlers and even a custom, deterministic memory allocator for real time applications.
e.g. "The phrase "object-oriented" means a lot of things. Half are obvious, and the other half are mistakes." -- Paul Graham
This is the best description that I've found:
OOP to me means only messaging, local retention and protection and hiding of state-process, and extreme late-binding of all things - Alan Kay
http://wcook.blogspot.com/2011/04/paul-graham-on-objects-in-...
"object-oriented design is the roman numerals of computing." -- Rob Pike
And Rob shared an office with Bjarne for quite a while.
(The article is full of technical inaccuracies. Compressors, depending on how they are set, do not reduce the attack transients of a sound like a snare drum, they exaggerate it. Also, it's from 2009.)
I don't want to be too hard on this guy, but this is a bad article. Sorry. This article uses incorrect terms to define things. It also doesn't explain or illustrate why monads are useful. You cannot read this article and learn anything about monads.
It's not useful on a theoretics level, and it's also not useful on a practical Haskell level. I don't think the author understands what he is writing about. (Don't get me wrong, by the way – it's totally fine to write about something you don't understand in order to learn more about it. But maybe don't publish it prominently on your website and peddle it out to newbies as learning material.)
The overabundance of bad monad articles is making it harder for Haskell newbies to learn. There are many good, free resources for learning about Haskell, such as Real World Haskell. This is not one of them.
Think of a monad as a spacesuite full of nuclear waste in the ocean next to a container of apples. now, you can't put oranges in the space suite or the nucelar waste falls in the ocean, BUT the apples are carried around anyway, and you just take what you need. - Dons, talking about bad monad explanations
edit: also, if you're really interested in seeing what a Haskell monad looks like literally translated into JavaScript, I wrote a comment here on HN a year ago with some code: http://news.ycombinator.com/item?id=1275860 I could leave better comments if I wrote it again today, but the code is correct and works.
You see, I already sensed that monads:
- were a way that you could sort of simulate side effects using pure functions
- had to do with the type signatures of functions
What I gleaned from the article is that monads:
- have to do with making functions composable
- work by way of the abstractions bind and unit in order to make type signatures match
Did the article harm my (lack of) understanding of monads?
For a "state" monad, that calculation is maintaining/passing the state. For a "logging" monad, that calculation is maintaining the log. For an "error handling monad", that calculation is checking for and propagating errors.
Take the OP's example for the Writer monad, in which several functions needed to return a debug string "<function name> was called" in addition to their main return value. If I had these two functions+:
(def sine (x)
[(Math.sin x) "sine was called"])
(def cube (x)
[(* x x x) "cube was called"])
(mac defWriter (name parms body...)
`(def ,name ,parms
[,@body (+ ,name " was called.")]))
(defWriter sine (x)
(Math.sin x))
(defWriter cube (x)
(* x x x))
+ Forgive me for indulging in the syntactic sugar from my own lisp->javascript project in these examples, but since we're dealing in JavaScript I couldn't resist. https://github.com/evanrmurphy/lava-script
monads are not for simulating side effects. they can model many things.
functions are already composable with the dot (.). if you want to compose arbitrary structures, use Control.Category.
unit does not have anything in particular to do with monads.
'bind' is specific to each monad and defines its behavior. there is no abstract or generic bind.
the article didn't teach you anything.
ask #Haskell on freenode if you have questions.
'In Haskell, everything is a function' is absolutely wrong. People who don't know much about Haskell often say this. There's a post by Conal Elliott about this incorrect meme: http://conal.net/blog/posts/everything-is-a-function-in-hask...It's simply not true. In fact, because Haskell is statically typed, it's very easy to tell what's a function and what's not: If its type doesn't have an -> in it, it's not a function.