Simple made easy

http://www.infoq.com/presentations/Simple-Made-Easy

Rich Hickey's presentation which received a standing ovation from Dr. Sussman.

The real problem is twofold
1.People add safety-cruft into boxed objects, OOP where it lowers performance(getters and setters, access through a layer of method calls)
2.GC algorithms(especially stop-the-world) interrupt the flow of program. Most of the objects are dynamic and need to be checked for references inside a huge dependency tree: this can't be fast by design, either there are leaks or with strict checks the GC will steal alot of execution time(stop-the-world will halt it if executed at same thread).

>>121 --> >>120

>>118
C, when compiled directly to machine code, will always yield lower performance at the same levels of complexity as a higher level language
This is a highly debatable assertion, but regardless, you're just proving the point of >>117.  Start with C because it's simple.  That's Hickey's mantra, after all.  You're preaching about not choosing a language based on performance (premature optimization), but then you say not to use C because it's lower performance.

>>123
Please, define ``simple''.

>>120
Please try to ignore troll posts.

>>124
Compare its feature set and implementation to other commonly used languages. The other languages will be comparatively complex.

>>123
http://shootout.alioth.debian.org/u32q/which-programming-languages-are-fastest.php

And I hope you do not believe the assertion that speed is everything - speed AND memory consumption, i.e. total efficiency, is more important. I wish that site would publish efficiency metrics, but I did my own analysis on their data and C/C++ comes out 1st place in 9/14 of their benchmarks.

>>124
It's closest to how a computer actually works without being assembly language.

>>117
A really hope this is a troll post. It makes 0 sense to me. There is nothing clever, complex, or optimized about functional programming. You work directly at the level of the problem you are solving using the simplest of semantics that yield no incidental complexity.

This is not how C works.

>>127
well that's the thing, FP is simple in terms of the problem you are trying to solve, and C is simple in terms of the hardware you're trying to manipulate.

nobody is saying you should write device drivers in Clojure, just that you should write the things you normally write in Java in Clojure

GUYS.... I just noticed this thread was still going, and took a massive SHIT. It was totally simple, and easy at the same time.

>>125
Compare its feature set and implementation to other commonly used languages. The other languages will be comparatively complex.
500+ pages of unspecified behavior? Underspecified != simple, unsafe != near the machine, bad design != low-level.

>>126
It's closest to how a computer actually works without being assembly language.
Except it isn't. Forth is much more ``low-level'', simplier and powerful than C.
C can't even manipulate its own return stack.

>>123,126
People gave up on using "benchmarks" as the measure of a language's efficiency long ago, for several reasons.  Probably the most important one is that they're too easy to manipulate.  There was a great site, years ago, where you could choose your favorite language and it would generate benchmark results that showed that your language was the fastest.  And the benchmark results weren't fake, they were just tailored to the strengths of whatever language you chose.

The only benchmark that really matters is what people do with languages in the real world.  Whether /prog/ likes it or not, C and C++ are still the standard for things where performance matters.  When Modern Warfare 15 is written in Clojure, then we'll all acknowledge the fact that functional programming is really swell.

Boo hoo, I know that pointing out the fact that the "industry" still uses C and C++ is considered a troll here, but hey, suck a dick.

>>132
But benchmarks are not easy to manipulate when they're about solving real-world problems, like the ones on that site.

And real-world problems is where everything matters.

I find the amount of FP propaganda in textbooks is irritating:
http://img252.imageshack.us/img252/5074/lolskell.png

This thread again.

1. Things don't actually need to be fast, they only need to appear fast (cache, progressive update, etc), there are a hundred other factors that would determine software success.
2. Any language worth a shit has FFI to handle extreme cases of pareto's principle that need to be solved in the constant time interval.
3. Since speed is absolutely everything Lotus 1-2-3 continues to bask in the dollars as everyone waited for them to port an app COMPLETELY WRITTEN IN ASSEMBLY to Windows, while Excel has been left to rot for being just barely Real World performance grade in the early 90s. oh wait, no.

>>135
There are things that need to be fast or they're unusable.
Would you play any video at 2fps?
Would you wait 20 seconds to load every webpage?
Would you wait a minute for a VM for load each time a script is loaded?

>>136
Would you play any video at 2fps?
If a tight loop needs to convolve and shuffle bits then don't write it Prolog. Pareto principle.
Would you wait 20 seconds to load every webpage?
How much of Firefox as a full package is actually compiled code? I've heard of significant amount of the UI code base written in XUL JavaScript. Again, Pareto principle.
Would you wait a minute for a VM for load each time a script is loaded?
People still use CGI? Pareto principle.

I've heard of significant amount of the UI code base written in XUL JavaScript.
And it shows.

>>136
it's funny because most of those are not CPU bound, performance wise.

IHBT

>>139
Unfortunately, with the software these days, they are, even if they weren't.