Lisp: More is less - <AUTHOR> http://jameso.be/2014/01/19/lisp.html <comment><USER2> This post repeats two memes that float around the programming language space. One is: "it's so powerful that it's bad". The other is: "it's ok, but not for large projects". I don't think I've ever seen any evidence attached to either. (If the OP contains any, I missed it.) But they're the sort of things that sound plausible and have more gravitas than "Here are my current preferences", so they get repeated, and no doubt the more they get repeated, the more they get repeated.

When I say "evidence" I'm not asking for formal studies; that's too high a bar for our field. But one can at least ask to hear about specific real-world experience.

Of the two arguments, the "too-powerful" one has the disadvantage of being prima facie absurd, so I think the "large-project" one is more harmful. So, where are the large Clojure and Common Lisp projects that have been harmed by this alleged language weakness? Let's find some practitioners who actually ran into this.

For what it's worth, I haven't. Since the best thing for a large project is not to be so large in the first place, applying language constructs to make codebases smaller is a great strength when the language lets you do it—and Lisp lets you do it.

Edit: [deleted off-topic bit]

<comment><USER3> > it's so powerful that it's bad

I had the pleasure of using Cascalog in production at work, which is written in Clojure. While it was in fact written by some very smart people, we had a very difficult time using some of its constructs that were very cleverly abstracted away behind macros.

The problem was that it felt nearly impossible to debug problems we had because of the long, impossible stack traces. Further, trying to get another very smart programmer to understand why some functions behaved in one way and some behaved in very different was very hard to convey. I'll reiterate that I thought the other guy I was working with was really smart, and I'm at least not an idiot, and we both felt like we had a really hard time unwrapping what the code was doing.

On the flip side, if it were written in Java (I think some parts are actually but more under the hood), you could point at the code and say "That's where the map function gets called on all the workers" (Cascalog is for Hadoop), or run the code and get some kind of stack trace where you could even begin to start figuring out what was going on. We weren't even doing anything cutting edge.

For me, I love the academic/fun endeavor. I have wasted countless hours playing and learning. But if you asked me if I would base any critical part of my production app on Clojure, especially when there are more than a couple people who weren't Lisp experts, I would have a really hard time justifying it after what I saw when I tried.

<comment><USER4> Finally some comment explaining a specific problem involving macros.

First of all Clojure has a problem with Stack traces, other lisps are much nicer in that respect (but do not have to face the JVM).

Anyway, macros can be difficult to debug, I am sure you have heard and used of the tools that usually exist in lisps, macroexpand etc. Nevertheless macros are Transformations of the AST and thus not as easily traceable as function calls.

Nevertheless, when working with ClojureScript on a web-app, I grew really fond of the possibilities macros offer, possibilities that are hardly possible with JavaScript (HTML templating within ClojureScript code, etc.). [http://blog.getprismatic.com/blog/2013/1/22/the-magic-of- mac...](http://blog.getprismatic.com/blog/2013/1/22/the-magic-of-macros- lighting-fast-templating-in-clojurescript)

I wrote some macros to help with HTML5 canvas contexts and these made my code a lot more reliable and readable.

The problem with keeping languages less powerful is, that you often end up with something like Java: Surely quite understandable when you look at a few lines of code, but in the end you need a whole lot of complicated patterns and best-practices, now you get hit by a boomerang at the back of your head.

Take away message: Macros should not be used on every occassion, but they are really helpful in central places.

</comment></comment></comment><comment><USER5> > _How can a static analysis tool keep up with a language that's being > arbitrarily extended at runtime? The prospect is daunting._

I don't really understand that point. In Racket, for example, programs macro- expand down to a very small set of primitives, such as `let-values` and `lambda`. This makes it easier to do analysis, not harder. For example, this is how something like Typed Racket can support every idiom in untyped Racket programs -- because they all expand down to a fairly manageable core set of forms. (Or if you need to analyze something no-so-primtive, you can stop expansion on whatever that is.)

Racket is descended from Scheme. I don't know if CL or Clojure expand down to quite such a small primitive core, but I imagine the story is roughly similar?

Anyway, writing such tools is not what the average programmer would do on a putative large project.

Any large project needs technical and social norms, mentoring, and leadership -- regardless of language. I think the language is the smallest part of it. Perhaps like how in security it's social not technical engineering that usually turns out to be the weakest link.

<comment><USER6> Furthermore: Lisps tend to prefer staged metaprogramming (eg. macros) over dynamic metaprogramming eg. python's __whatever__, Ruby's method_missing, and JavaScript's obj[foo + bar](). I'd much rather debug static metaprogramming techniques over dynamic ones any day of the week.

The fact is that Clojure/etc is _much_ easier to analyze statically than the popular everything-is-a-dictionary scripting languages. That should be obvious given that the reference implementation is a compiler, not an interpreter. But stuff like Typed Racket and Typed Clojure should eliminate any remaining doubt.

</comment></comment><comment><USER7> Starting with "Goodbye, static analysis" it was pretty hard for me to take this article seriously. Macros _desugar_ into primitive forms - this means most macro language extensions are amenable to static analysis! Clojure has Kibit, Eastwood, and Typed Clojure (a whole type system via ... macros!) for static analysis. In addition Clojure and ClojureScript now both have fairly powerful analyzers that catch bad style and errors today and can be extended to do even more.

<comment><USER8> Agree with everything you say, but it is worth noting that the insights you get from static analysis on desugared forms (which can be very large and complex!) is much harder to interpret than static analysis on the original forms.

So to make static analysis tools useful on macros, they really need some way to map back to the original source forms. Not all tools do this (either at all, or well) - and to the extent that they don't it is an big impediment for static analysis.

Also the killer challenge: macro expansion in Clojure can depend on a mutable environment at the time of macro expansion. This makes it impossible to do reliable static analysis, unless you are able to recreate the runtime environment at the time of macro expansion in your static analysis tool, which is hard/impossible in general.

This is part of the motivation for my little Kiss language experiment: with immutable environments you can keep the power of macros, but avoid the mutable environment problem. Ideally, macro expansion would be governed only by things that are provably compile-time constants (not sure how feasible this is while maintaining the dynamic flexibility of Clojure that we all love... but it's an attractive idea at least).

</comment></comment><comment><USER9> Good arguments for why Python is a great little language, but no convincing ones regarding Lisp: there are no large software projects undertaken in Lisp recently (or ever?) that have failed _because_ of it's extreme flexibility making collaboration impossible, no lisp programmers complain that there are too many ways of doing things or about "conceptual clutter" (ok, after my encounter with CL I'd complain about it, but I never got any real work done in CL so my opinion doesn't matter - maybe the "conceptual clutter" would've ended up to be "invaluable expresivity/flexibility" in a real world project) etc.

</comment><comment><USER10> Macros are used quite rarely in Clojure. In general they swing between two extremes, either as a means of providing some simple syntax sugar, or as what effectively amounts to a language extension.

The author cites Korma as an example of a library that uses macros, but Korma only uses macros to provide a small degree of syntax sugar. So instead of writing:

        (exec (where* (select* people) `(> :age 18)))

One can instead write:

        (select people (where (> :age 18)))

It's an extremely simple transformation, and can be expressed in a few lines of code.

There are some libraries, such as core.async or core.logic, that make more extensive use of macros, but these libraries are relatively rare, and take a lot of work to get right. It's something I'd expect to see in a dedicated library, not as part of a solution in a large software project.

Worrying about overuse of macros in Clojure is a bit like worrying about overuse of FFIs in Python. Sure, it's possible to abuse in theory, but it's not really a problem in practise.

</comment><comment><USER11> The OP is going to have kittens when he finds out about hylang ([https://github.com/hylang/hy](https://github.com/hylang/hy))

<comment><USER12> I recently found out about hy and I am seriously evaluating it for use with Django in production. Does anyone have experience using hy in production they could share?

<comment><USER13> [http://fraked.debian.net/](http://fraked.debian.net/)

[https://github.com/paultag/snitch/](https://github.com/paultag/snitch/)

<comment><USER12> If Debian thinks hy is stable enough to use in production I think it's good enough for me :)

P.S. I use Debian as my main OS for all my computers

</comment></comment></comment></comment><comment><USER14> What I value most in a programming language:

1\. I'm able to concisely express what I'm trying to do.

2\. I never, _never_ have to copy/paste or otherwise do repetitive work because one case is slightly different than another.

Number 2 is probably more important to me. It's why I'm happy when a language has first class functions and closures, and why I'm unhappy when the language is Java.

I think the cases where you can't modularize things enough such that you have to essentially include two version of the same thing is a programming language expressiveness failure.

Finally, I strongly disagree that programmers aren't or shouldn't be language designers. Nearly every worthwhile program I've written that people have used has needed an API or scripting/query language. So any language had damn well be suited to writing a parser. LISP fills that bill too.

If LISP has shortcomings, its expressiveness and power are not them. If you want to complain about a lack of consistent implementations, lack of libraries, difficulty interoperating with any other language, lack of a canonical free implementation, no decent supported GUI toolkit, or the impossibility of distributing binaries real people can use without spending thousand of dollars on a professional LISP environment, go right ahead.

</comment><comment><USER15> [edit: While I was typing this the title was changed. It was previously _Why Lisp isn 't (and shouldn't be) widely used in industry_, which colors my comment.]

This points out some very real potential dangers of large-scale collaboration with Clojure (and presumably some or many other Lisps/Lisp-likes).

However, I think the conclusion is overstated. Yes, based on what's provided, it may take more discipline and better, more explicit processes for a team to effectively collaborate in Clojure than in Python (using the author's running comparison). Yes, if we take this at face value, it does appear that people who depend on static analysis might find Lisp lacking.

But does this tell us why Lisp isn't widely used in industry? If we assume that "widely" means "as widely as Java or Python," which seems to be the statement made here, I don't think it's valid to cite the provided complaints as most or even a large portion of the explanation. The fact that there are no or almost no mainstream educational institutions teaching new students Lisp seems to me a far more likely candidate for front-runner on this issue.

That it shouldn't be _widely_ used is a little easier for me to agree with, only because I'm on board with some of the points here about the discipline and extra work it would take for a large team to effectively cooperate given the malleability of Lisp. I've worked with enough other programmers to know that kind of care and attention to process are very rare (and this isn't "all of you suck;" I know I have and will again cut corners and ignore protocol in situations where time or resources make it hard to do things perfectly every time).

Also, I think the author's last point is important to mention, because it'd be easy to miss it: He's not arguing that Lisp sucks. He states explicitly that it's great in at least some ways. I just don't think the black and white claims being made about its practicality are quite supported.

<comment><USER16> Although I love lisps, I'd rather jump in a very large Python project than a lisp one. Jumping into someone else Lisp code feels like a jungle to me. Jumping into someone else's Python code feels like my old good slipper. Part of it is due to the very strict Python standard of coding. But I think it's primarily because of the "One good way to do it" mentality. On the other hand, I feel telling a lisp programmer " _This_ is the _right_ way to do this" would be like an insult to their _creativity_. Obviously, it's not as much black and white, but hopefully you understand what I mean.

<comment><USER17> "Part of it is due to the very strict Python standard of coding."

I don't know about that. Good code is good code. It's sort of one of those, "I'll know it when I see it" things.

The ease of which you can code classes for the sake of classes in Python can make some really hairy code out of what should be simple programs. Was that necessarily the 'one right way to do it'? Who's to say. And all the static analysis tools and syntactic aren't going to undo those hairballs anytime soon.

You might just feel more comfortable with languages with lower code density. 'brandonbloom made a good blog about that[1]. I think it can be doubly applied to any situation where meta-programming is employed.

1: [http://www.brandonbloom.name/blog/2013/06/24/code- density/](http://www.brandonbloom.name/blog/2013/06/24/code-density/)

<comment><USER16> Take Javascript, if you want to iterate over a list, you have dozen of ways. One could hardly argue that one is better. Some prefer using built-in foreach, some .map, some underscore, some the native for(). As you say, great code is great code and as long as it's well written and understandable, it's good Javascript.

In python things are a bit different. There are agreed-on ways to do certain patterns. If someone uses a different method, I.e. [1,2,3].foreach(lambda x: something(x)) pythonist will all agree that this is no pep-8 standard and that for readability and maintenability's sake it should be changed to for x in [1,2,3]: something(x).

Another way to say that.. very good pythonists will agree on a "best way to do it", whereas in Lisp, very good lispers will agree that "both ways are very good and clean".

With all that being said, that's why I prefer to jump into a large python project (considering that pep 8 is strictly being used).

</comment></comment></comment></comment><comment><USER18> Don't fear the macro!

"Lisp isn't a language, it's a building material" \- Alan Kay.

Lisp is an opportunity to build a DSL that fits any given problem domain elegantly.

</comment><comment><USER19> Most of the complaints in this article boil down to "macros are too powerful." I think this is the key part of the argument:

"A smart programmer is not necessarily an empathetic language designer; they are occupations that require different skillsets. Giving any programmer on your team the ability to arbitrarily extend the compiler can lead to a bevy of strange syntax and hard-to-debug idiosyncrasies."

There are at least 2 counter-arguments to this:

1.) in the simplest case, just restrict the use of macros. A team can easily adapt the rule that only the most experienced engineer on the team is allowed to write or approve macros. (And in my experience, the need for macros is fairly rare. I think my ratio is something like 100 or 200 normal functions for every macro that I write.)

2.) macros allow all kinds of interesting type checking, and data structure validation, and therefore they make it surprisingly easy to validate data and types as your data and/or vars get passed around your system. Consider all of these very interesting tools you can use in the world of Clojure:

Prismatic Schema which allows validation that a data structure matches a schema of (possibly nested) types:

[https://github.com/prismatic/schema](https://github.com/prismatic/schema)

and this now offers coercion, which makes this fantastic for importing JSON from other sub-systems or outside vendors:

[http://blog.getprismatic.com/blog/2014/1/4/schema-020-back-w...](http://blog.getprismatic.com/blog/2014/1/4/schema-020-back- with-clojurescript-data-coercion)

(I assume you could easily validate before giving data to Liberator to export your data while conforming to your schema: [http://clojure- liberator.github.io/liberator/](http://clojure-liberator.github.io/liberator/) )

There is work being done on an optional type system:

[https://github.com/clojure/core.typed](https://github.com/clojure/core.typed)

Much effort has been made to make contract programming easy in Clojure:

[https://github.com/clojure/core.contracts](https://github.com/clojure/core.contracts)

But also I find the built-in syntax for writing pre and post assertions is clean and easy to use:

[http://blog.fogus.me/2009/12/21/clojures-pre-and- post/](http://blog.fogus.me/2009/12/21/clojures-pre-and-post/)

In short, there are an abundance of mechanisms available with Clojure which help facilitate the enforcement of any kind of schema or contract, and some of these tools are enabled (and their syntax is made clean) thanks to macros.

In short: macros can be used for evil, but they can also be used for good. They are very powerful, so everyone should be judicious about their use, but there is no reason to argue that macros render a Lisp unfit for programming in the large.

Having said all that, I'll remind everyone that the ultimate counter-argument is offered by Paul Graham, in his essay "Beating the averages":

[http://www.paulgraham.com/avg.html](http://www.paulgraham.com/avg.html)

If that essay does not convince you of the value of macros/lisp, then nothing will.

<comment><USER20> I mostly agree but fwiw, the usual counterargument on #2 is that those should be language facilities instead, which allows them to be carefully designed and then taken advantage of by the compiler. For example, in Racket (formerly PLT Scheme) you have: [http://docs.racket- lang.org/guide/contracts.html](http://docs.racket- lang.org/guide/contracts.html)

<comment><USER21> I'm not sure how well that specific example works. Are contracts built in to the language on a fundamental level, or are they just part of the standard library? Given that they're not included in racket/base, and given how flexible racket's core is, I would guess the latter, but I'm not sure.

<comment><USER22> "Are contracts built in to the language on a fundamental level, or are they just part of the standard library? "

One of the points of Lisp is that that difference doesn't matter.

But besides that, in this case it couldn't possibly matter. You write contracts for your functions. If they're violated at runtime you'll get a clear error that stops execution to contain damage, and assigns blame to the contract violator. At what point in that process does it matter whether contracts are "built into the language"?

<comment><USER21> To be clear, I'm not suggesting it's an important question per se.

_delerium presented an argument that the things people do with macros should be implemented as language facilities instead. Ve used racket contracts as an example.

I was saying that if racket contracts are not implemented as language facilities, it's not a very good example.

</comment></comment></comment></comment></comment><comment><USER23> I wasn't excited about scala's macros initially [a], but Eugene's Burmako's recent talk [b] on the constraints the developers worked with to keep macros consistent and interoperable was illuminating, and has changed my mind to a large degree [c].

In the end, they only directly added support for 1) type-safe macros, aka "black-box" macros 2) ...invoked transparently as methods, aka "def macros"

They identified "white-box" (non-type safe) macros and quasiquoting as distinct from black-box macros, because the type signature of a black-box macro tells you approximately what it will do, meaning that you can treat it as a "black box". But additionally, in order to write a meaningful type signature, the input to a black-box macro must _already_ be valid scala code! This means that the addition of macros cannot actually result in new scala syntax [d].

[a] [https://news.ycombinator.com/item?id=3709193](https://news.ycombinator.com/item?id=3709193)

[b] [http://www.infoq.com/presentations/scala- macros](http://www.infoq.com/presentations/scala-macros)

[c] still hoping the existence of scala macros leads to the deprecation of a bunch of other features though

[d] see the explanation starting around 33m30s in [b]

</comment><comment><USER24> I remember seeing the same kind of arguments about Ruby when it began to become popular. "Ruby is too dynamic. You shouldn't use it on large-scale projects."

Learning a language involves more than just learning syntax and semantics. You also need to learn how to write for maintainability. It sounds like the author is less certain about how to do that with Lisp, but instead of seeing it as a chance to learn more he writes off the entire Lisp family as impractical.

<comment><USER25> Exactly. I think it's part of a larger learning pattern that people go through: one starts learning about a new tool, library, or approach, and at some point, realizes that it's not perfect -- there are some cons.

I guess there are several ways to respond at that point: one is to persevere, learning more and coming to a better understanding of what advantages and disadvantages are, as well as the appropriate use cases.

Another is to just give up and write a proscriptive blog post, possibly also with a biased, incomplete comparison of the new thing to an old thing.

The latter approach is extremely frustrating for several reasons: 1) often, the authors ignore or fail to grasp both the pros of the new thing as well as the cons of the old; 2) the proposed solution is to throw out the baby with the bathwater, instead of to figure out how to improve the new thing; 3) it provides fuel for others' confirmation bias.

</comment></comment><comment><USER26> "OOP is widely-used and easily comprehended because it is a fairly simple way of modeling reality that is compatible with how human beings do it" I don't see how OOP is "fairly simple", "modeling reality" and "compatible with how beings do it". How inheritance, polymorphism, interfaces, classes, objects, types is a "simple" model of reality? You're simply used to think OOP way, that's all.

</comment><comment><USER27> If I had the choice to develop a functionality as a Lisp macro or alternatively as an XML-based DSL for Java, I would know what I'd prefer...

</comment><comment><USER28> Haskell, by its lazy evaluation, is basically a macro-only language, and people seem to be doing fine in that end of the world.

Granted, space leak issues are pretty difficult to analyse, so it makes the language seem hard to use in practice, but that's because all the low-hanging fruit like type errors are solved by how the language is designed, so you only end up with the hard bugs.

<comment><USER29> > _Haskell, by its lazy evaluation, is basically a macro-only language, and > people seem to be doing fine in that end of the world._

They aren't that many to begin with, so it could just be (self-)selection bias.

Forth people do fine using Forth too, but I don't see that as a point that it's an appropriate language for most projects and/or people.

<comment><USER30> There are more people in the #haskell channel on Freenode IRC than #clojure, #scala, #lisp, #racket, or #ruby.

<comment><USER28> didn't even know that.

BTW the people on #haskell are quite active, and nice :)

(maybe a pointless counter-example, I once went onto #ruby, and asked about an easy way to make a function name refer to a function( to be able to do things like list map f easily, without the superflous do |x| f x end ), and I got yelled at because I was trying to write "non-ruby code".

<comment><USER22> The Ruby community is very close-minded. I've been a victim of that behavior in #ruby as well. If you asked an equivalent question on #ror (the Rails channel) you'd get more than yelled at - no one would take you seriously from that point on.

To answer your question, because methods aren't first-class in Ruby, you can't pass them around the way you want to. I've decided I don't want my languages telling me what I can or can't do when I know what I want to do is a simple matter of making more types of pointers first-class.

<comment><USER28> I figured that out later on, that I should probably not think of ruby as functional ( my brain hardwires no parentheses languages to functional languages I think). After which the experience becomes slightly less frustrating

</comment></comment></comment></comment></comment></comment><comment> r-s A large reason there is fewer large lisp projects, is that its pretty hard to get a team of lisp developers. Also, many programmers who do know languages like a lisp or Haskell are often going to be better programmers and will require a higher salary. Not everyone who codes in these languages is a great programmer, but I suspect there is some correlation.

<comment><USER27> Another reason: they don't tell you or it is in a domain which the average developer does not know anything about.

How large is the scheduler for the Hubble Space Telescope, which has been adopted for many other telescopes?

Who are the users of AllegroGraph?

How complex is PTC's CAD system which uses Common Lisp? A few years ago they mentioned 7 million lines of Lisp.

</comment></comment><comment><USER31> "OOP is widely-used and easily comprehended because it is a fairly simple way of modeling reality that is compatible with how human beings do it."

I disagree with this. Ask any non-programmer "is a square a rectangle?" Or "is a list of triangles a list of shapes?" and they will say "Yes!"

Yet as soon as either of these becomes mutable it all falls apart and intuition fails. You cannot change the height of a square independently of its width, you cannot add a square to a list of triangles (but you can add a square to a list of shapes).

Human beings reason "immutably".

"Fine only do OO with immutable objects!" I hear you say. It's a good idea buy you're now on the path (that I took a few years ago) towards functional programming.

This is why I think that OO, and more particularly mutable state, are quite difficult for new programmers to grasp.

</comment><comment><USER32> As a tangent, we still don't have a good definition of 'large' software project. Clojure hasn't been around for 8 years, so we don't have 10 or 15 year projects to look at. And I think we'd have heard if there was a 1500 developer team using it. It sounds absurd, but there have been plenty of projects this size and they 'work' insomuch as they generate enough revenue the sponsoring companies paid for them to get that size.

</comment><comment><USER33> I think the designers of Clojure intend it as a language for experts. In many fields non-experts can make nice progress, but they need to be aware that they may stub their toes. So, pull requests, code reviews, pairing, etc. are available and well established as means for helping people make the transition from beginner to journeyman (person) and beyond. If I know how to walk, but not how to ride a bike, I hardly think others should be denied nice bike routes.

</comment><comment><USER34> > OOP is widely-used and easily comprehended because it is a fairly simple way > of modeling reality that is compatible with how human beings do it.

Have we not learn by now that these systems are not easy to reason about. Are not all the things one first learns (ie Animal -> Dog) bullshit and should be avoided.

Why is it in every good OO book that, composition is better then inheritance. Why is every OO book full of examples about how to avoid mutabiltiy and make the system easy to reason about?

The idea that OOP systems (as generally) thougth of goes completly out of the window as soon as you have any kind of concurency, even just event handling.

> which rejects OOP

It does not reject, it takes the usful features like polymorpism and gives them to you. Protocols are better then interfaces, better then duck typing.

> In Clojure, if I want to define a symbol there are nine different ways of > doing so.

There are a lot more then nine. But I would recomend rich or stus talks on simple vs easy. Just saying there is nine of something and thus its complicated is idiotic.

Java has only one thing, classes, does that make it simply, or does that just mean that its hoplessly overloaded?

Clojure is extreamly simply. State can only live in a var, atom, ref or agent. Every one of these has clear semantics, this includes clear sematnics in a multithreaded world. No other language has such clearly defined state management.

> Clojure claims to include these language features as a way to mitigate the > complexity of parallelism; frankly, I've never found threading or > interprocess communication to be any sort of conceptual bottleneck while > working on some fairly complex distributed systems in Python.

Distributed system != Shared Memory

Nobody, really nobody can say taht distributed systems are easy. Just listen to the people that implment this stuff. But it is clear that a language generally does not really help you with reasoning about that system.

However when you run on a 16 core with shared memory and you have to do lock ordering and all this stuff,then you will defently be happy for the tools that clojure provides.

> Less is more (as long as "less" is sufficiently convenient).

Clojure is actually a much smaller and much simpler langauge then python every can hope to be. Clojure is simple, and strives for simplicity in every feature of the langauge. See here:

\- Simplicity Ain't Easy - Stuart Halloway [http://www.youtube.com/watch?v=cidchWg74Y4](http://www.youtube.com/watch?v=cidchWg74Y4)

\- Simple Made Easy [http://www.infoq.com/presentations/Simple-Made- Easy](http://www.infoq.com/presentations/Simple-Made-Easy)

<comment><USER35> OOP isn't be all end all, and it isn't really easy to get into. But, that doesn't mean that modelling hierarchies is not necessary in some domains. E.g. DOM was a very big reason why Rust was considering adding OOP. The performance and the readability is hurt when you don't have to represent hierarchy.

Article simply says that giving ALL programmers power to design language leads to bad things. Lisp, Clojure, etc. And I can see why. People love making their own languages, it's fun, but a good programmer and a good language designer are two mostly unrelated things. Good programmer often needs to look at problem from a weird angle, while a language designer needs to find shared views. I'm not saying they don't have a lot in common as well, but I can see how programmers can design AWFUL languages.

Note: Good programmer means a good general programmer i.e. someone that solves various tasks in his favorite programmer language.

<comment><USER34> Two points

1\. > But, that doesn't mean that modelling hierarchies is not necessary in some domains.

Agree but the addition of full OOP seams overkill to reach this goal. Look at this clojure code:

>(derive ::rect ::shape) >(derive ::square ::rect) > (parents ::rect) -> #{:user/shape} (ancestors ::square) -> #{:user/rect :user/shape} (descendants ::shape) -> #{:user/rect :user/square}

Clojure gives you hierarchy 'À la carte'. This means that you know longer tie the two things together, it easy in clojure for example to have many diffrent hierarchy that are independent but still dont get in each others way. Modeling the same with objects is hard. Just a example, for often good reasons multiple inheritance is not allowed in most languages, however if you use hierarchy as a domain model and not as programming model you generally want it.

2.

I agree with the articles point, people should not invent there own langauges for everything, however that is a terrible reason to discard the language for 'large scale' production use. Every language has features that generally should be avoided, every language make it easy to do the wrong thing. Macros are relatively easy to understand, compared some other language features I could name. Also the effect of macros is generally local, unlike say monkey patching.

<comment><USER35> > however that is a terrible reason to discard the language for 'large scale' > production use

I think article by `large scale` means something that needs lots of people working on it. I can see how several programming departments might form their own lisp-tribes that can't speak to each other because they disagree over tiny details (or engaged in power play).

<comment><USER34> The same thing can happen in any language and with any detail. Power play normally is political not really about language.

Also one could easly argue that macros help with this situation because the 'right way' can be encoded in a macro and then you can require everybody to use it. That seams a better solution then long documents that explain in detail how X is done (because the langauge can reduce the code dublication). I remember such things in my (short) C++ experiance.

<comment><USER35> Or just use a language that has one way of doing things? C++ with it's pre- compiler magic, and several (three or four ) ways to define a variable is a rather bad example.

Things like this are bumps on a road, where your organization is a car with bad suspension. Sure, bad suspension will cause problems down the road, but no reason to drive your car through rocky terrain.

</comment></comment></comment></comment></comment></comment><comment><USER17> This is just fuel in search of fire.

"OOP is widely-used and easily comprehended because it is a fairly simple way of modeling reality that is compatible with how human beings do it."

Close, but no pants, Buckwheat!

</comment><comment><USER36> You don't find large-scale Clojure projects, because Clojure is very concise.

<comment><USER8> Also I would guess that people who like Clojure's philosophy are much more likely to build simple / loosely coupled / composable services than a big monolithic project.

</comment></comment><comment><USER37> Using a Lisp does not necessarily preclude static anlysis.

</comment><comment><USER38> I don't find the arguments against macros workable since the emergence of syntax transformation while modeling a problem shows many deep relationships between parts of the domain .. in the cases I've seen. Just want to share some stuff that I haven't seen others write about.

I don't code much lisp these days (though getting into clojurescript a bit now), but when I used to, the cycle went pretty much like this -

1\. Express what you want to express as an s-expression, capturing known structures in the simplest way I can think of.

2\. Figure out which aspects can be "functions" straight forwardly and which are macros and implement them.

3\. Test and iterate a bit till I like the way domain elements are composing and the way the composition looks in code. Try to reduce the required concepts in each iteration.

4\. Document the relationships that have emerged from this process so others can understand it.

5\. Usually I'm done, but sometimes (the few) users of my "api" come back with questions, based on which I iterate a bit more.

I've mostly followed this in building the "editing style specification language"[1] part of the product "muvee Reveal" (an automatic video editor)[2], built in a custom scheme dialect called "muSE"[3]. (Full disclosure: I've happily worked for muvee Technologies from 2002 to 2011.)

Btw - most discussion on macros and lisp seem to first assume that there two things - a) functions and b) macros. There are more, depending on the kind of lisp system you're working with.

You could form a taxonomy of sorts based on whether argument forms are evaluated and whether the result form is evaluated -

1\. Argument forms are evaluated before "apply", result is a value (i.e. not evaluated). => Function

2\. Argument forms are unevaluated before "apply", result is code (i.e. is evaluated). => Traditional macro

3\. Argument forms are evaluated before "apply", result is code (i.e. is evaluated).

4\. Argument forms are unevaluated before "apply", result is a value. => Traditional macro (depending on system)

In the course of using the domain modeling approach above, I've written stuff like functions that create one or more macros, macros that evaluate to function values (not s-expressions) and such stuff that might be considered an "abomination" by the OP ... but in the context of the domain, the _concepts_ are usually clear enough to be used without major issues.

[1]: [https://code.google.com/p/muvee-style- authoring/](https://code.google.com/p/muvee-style-authoring/) [2]: [http://www.muvee.com/en/products/reveal](http://www.muvee.com/en/products/reveal) [3]: [https://code.google.com/p/muvee-symbolic- expressions/](https://code.google.com/p/muvee-symbolic-expressions/)

</comment><comment><USER22> The author of the blogpost is pretending to be "one of us" (people that get lisp) - in "Lisp devotees (myself once included)" \- but apparently they never understood it if they're still thinking that lisps' advantages "make Lisp into an unweidly, conceptual sledgehammer that's often out of scale with the problem being solved.". The word "often" there also makes me think they're making a point without experience or proper evidence.

They're a lisper who broke their teeth in Clojure. I think when people like me disdain Clojure's lispness is because we think it doesn't really teach you the philosophy behind it. This is not an argument, just my perception.

They're also in favor of code censorship (let's remember that censoring is detrimental to creative processes):

"Giving any programmer on your team the ability to arbitrarily extend the compiler can lead to a bevy of strange syntax and hard-to-debug idiosyncrasies. "

I use Racket in production along with my team and may I suggest a humble, easy solution: one person makes a pull request, another reviews the pull, and if there are new macros introduced we can discuss it with the team to see if it's necessary. It's so simple. The blogpost author is making a big deal out of nothing. To prefer a language that doesn't allow that power because the author has a problem trusting others instead of choosing to communicate with their team members is appalling.

The author also keeps mentioning Python's "simplicity". How can anything be as simple as (function args)? I'm yet to understand what people that argue this point mean by "simplicity".

Then the author talks about static checks. "How can a static analysis tool keep up with a language that's being arbitrarily extended at runtime?". Simple, do macro expansion before static type checking, as Typed Racket does.

They're also still playing with SQL DSLs too. I think that's such a waste of effort. SQL is already a DSL for talking to the DB. I don't want another layer because I'm not going to be manipulating SQL in my code, because "SQL" has nothing to do with the problem domain I'm working on. At that point any SQL queries have already been abstracted away inside functions that have meaningful names like associate-product-to-customer or whatever. I don't want to talk about SQL ever in my problem domain abstraction layer. Using SQL DSLs as an argument against macros with the angle of static type checking is a poor argument because SQL DSLs are usually for people that use mutable code anyway. I use Typed Racket's DB library and its querying functions work together with the type system to let me know if I'm not handling some potential kind of value that might come from the database.

The author then mentions Unix's consistency. Unix couldn't even decide on a standard notation for command line arguments. Then onto that fallacy that reality is object-oriented. Objects can't possibly be as composable as functions because Objects break down into methods (which are not composable, are not first class, etc) whereas functions (lambdas) can make up everything and can really be thought of as an atom for computation (i.e. Lambda Calculus).

Complaints like "Clojure has nine different ways to define a symbol" are moot. Pick one that your team likes and go with it. On to the next thing. Also, to argue against Lisps by arguing against Clojure is like arguing against democracy by arguing against the Democratic Republic of the Congo.

I do believe the blogpost author is severely misguided in their criticism. To say things like "Python wants the conceptual machinery for accomplishing a certain thing within the language to be obvious and singular" while ignoring the fact that lisps machinery is obviously much simpler and obvious and singular - again, (function args) - is disingenuous. It does make me believe that all their SICP reading was for nothing (I've only lightly skimmed SICP and I don't pretend to have read it).

The author does acknowledge (en passant) that certain Schemes (they don't identify which) don't suffer from this complexity (which makes the whole post look more like a criticism of Clojure). I'd invite the author to look into Racket.

They say that lisps "impose significant costs in terms of programmer comprehension". My experience is that if you divide your layers of abstraction correctly you will be able to work in the problem domain layer where nothing is obscure. And that layer is built from smaller in the layer below, parts that are also clear in what they accomplish because they only do one thing in their abstraction level. I've found that following this rule of only doing one thing per function makes for code that is easy to understand all the way from the bottom to the top layers. Programming this way, however, is the classic, boring way to write code [1], and because it's not a fad I guess people aren't too much into it.

Also to the point above, having already rewritten a significant portion of a Rails legacy app into Racket with the help of my coworkers, it seems that lisps introduce more understanding and shed more light onto the code, precisely because it makes everything explicit (we code in functional style so we pass every argument a function needs) and does away with "Magic" that Rails and rails fans like so much. When something gets annoying to write we implement our own "magic" on top of it, not in terms of silly runtime transformations that lesser languages like Ruby need to resort to, but through dynamic variables (Racket calls them parameters), monadic contexts, etc, i.e. things that can be checked at compile time.

And finally: "I think it'd be irresponsible to choose Lisp for a large-scale project given the risks it introduces". Well, the only risk I've personally witnessed is the very real risk of your coworkers starting do dislike more mainstream, faddish languages like Python and Ruby, because they don't allow the same freedom and simplicity and explicitness that lisp does (lisp has a long tradition of making things first-class, which consequently makes these things explicit).

[1] We use top-down design to decide what the interface for a given abstraction layer will look like, and bottom-up to decide which functions should be written in the layer below; then we cycle that process by refining the layer below through the same process of defining its interface top-down and then the layer below it as bottom-up. And we use algebraic type checking along with contracts to enforce post-conditions and properly assign the blame to the right portion of the code to speed up debugging. These are all old techniques.

<comment><USER26> By "simplicity" they mostly mean "what I'm used to". Same applies for people calling "Windows simpler than Linux". It's the same argument over and over: illegibility (because you're not used to it), too much power to handle (because you're not used to it)...

<comment><USER38> Right on. Jeff Raskin's equation is pure gold -

        Intuitive = Familiar

</comment></comment></comment><comment><USER39> A lot of confusion comes from regarding Clojure as a Lisp (in my opinion, to call Clojure a Lisp is the same fallacy as to call Ruby a Smalltalk) and especially thinking that Clojure is "what a Lisp should be".

On the contrary, beauty of Lisp comes from being accidentally discovered minimal set of unique interweaving features (very few special forms, high order procedures, list structure, to glue code and data together, macros, the way to use Lisp as a meta-language to itself, type-tagging of values, instead of declaring variables, and, the numeric tower, and lexical scooping, as recent addirion).

This set of features is very balanced and good-enough. Adding more "foreign" features actually ruins the balance.

Having "just this" and following the paradigm of layered DSLs embedded in a Lisp, popularized by SICP, lots of complicated things could be created, including CLOS which is nothing but a DSL (a bunch of macros and procedures).

This notion of what a Lisp is actually helpful to understand not just Clojure but also Haskell, which is, in some sense, also a small kernel based on Lambda Calculus and tons of syntactic sugar.

By adding more and more features without breaking the balance we got Common Lisp, while an attempt to keep the balance produced R5RS.

If we switch the perspective on what Clojure is to the notion of a scripting language for the JVM (a-la Ruby) with sometimes looks like a Lisp and sometimes behaves like a Lisp, but strictly speaking not a Lisp, because the unique balance was ruined by adding stuff, everything, it seems, falls into its places.

Arc is a dialect of Lisp, Clojure is language of its own, but marketed as a "modern dialect of Lisp", which makes no sense.

<comment><USER40> The difference between Ruby and Smalltalk is clear, but your analogy is lost on me. I consider Clojure a lisp by any common definition. Why do you not?

<comment><USER39> Take a look at _arc.arc_ and _news.arc_ \- that is why.

</comment></comment></comment><comment><USER41> The biggest problem with LISP is the lack of large organizations who use it.

C has all these problems as do C++, Java, Python, Ruby.

<comment><USER42> Google (ITA Software) is not large enough.

<comment><USER27> If one needs a large organization for a Lisp program, then something is wrong.

<comment><USER41> Oh I'm not disagreeing with the logic, it's just that our industry moves as a herd, if there aren't large orgs doing it it's hard to justify to manager types.

Manager types barely tolerate literate programmers, let alone someone who can make something that a mouth breathing moron can't understand.</comment></comment></comment></comment>


Apple OS X El Capitan - <AUTHOR> http://www.apple.com/live/2015-june-event/40d96cf4-33a4-48ca-9335-815af736ce39/ <comment><USER2> > Metal is coming to Mac, paving the way for new levels of realism and detail > in games and other apps.

I'm guessing this is _yet another API_ like Mantle/Vulkan that is also seated comfortably in the Apple walled garden and increases the development costs: _awesome!_

<comment><USER3> And it's 40% faster! .... Of course they forgot to mention that OGL drivers on OS X were about 30% slower than OGL/DX drivers on Windows on the same hardware running same scene. So instead of updating their OpenGL 3D performance they just kept it back and now you're forced to use a proprietary walled garden API for full performance.

This kind of behaviour makes me really really sorry to be an Apple customer :/

<comment><USER4> > This kind of behaviour makes me really really sorry to be > an Apple > customer :/

Well, don't be then. I don't get this cry about walled gardens. Feel free to roam in the jungle if you don't like them.

<comment><USER5> > Well, don't be then. I don't get this cry about walled gardens. Feel free to > roam in the jungle if you don't like them.

I really don't get why people pull this "if you don't like it, leave" argument (in everything from politics to tech). There are lots of reasons someone might want to use a mac (I do), one is perfectly entitled to complain about aspects of Apple's approach to try to make the argument for change.

<comment><USER2> I think it originates from misunderstanding what a walled garden is and why they are great for customer retention. The whole point of walled garden is locking people in.

Avoiding a walled garden can only happen _before_ you invest in the garden. Once you have spent money in iTunes or the store (or e.g. even have a long list of contacts in some IM client) you are stuck unless you are happy to lose those purchases/data.

<comment><USER6> I had this experience leaving the Apple walled garden about six years ago and moving on to Ubuntu (with Windows for gaming purposes in free time). I just kind of ate the costs. I suppose technically I still have access to my video content purchased on iTunes, but I'd have to boot to Windows or use a VM to get to it.

My rationale was kind of along the lines of avoiding the sunk cost fallacy: just because I'd been invested in the Apple ecosystem for 20-some years and buying iTunes stuff for more than half a decade didn't mean that I should just _keep_ doing that when I was unhappy with other things. But that cost-benefit calculus might work out differently for other people. The lock-in is very real if you don't want to lose your stuff. It's a reason that I still refuse to buy movies from any online service. Only discs that I can rip or DRM free downloads for me from now on, so I don't end up walled-in again.

Eventually I was able to rescue all my protected music at least by paying what ammounted to a $25 ransom for a year of iTunes Match (or whatever they call it now) so I could download DRM free versions of the music I'd already paid for.

<comment><USER7> I did a similar "switch" where I kept my macbook/retina display laptop hardware but switched to Windows 8 for the OS.

It's been a good experience except for one thing: Apple delivers no drivers for the integrated video, disables it in EFI from Bootcamp, so it runs hot and has a short battery life when not in OS X. I haven't seen anyone reporting success working around this problem, and it's been going on for years for us "switchers" to Windows.

<comment><USER8> that is strange, as other macbooks that only have an iGPU work fine on windows 8.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER9> Since no one already mentioned about it, here's an update to WebKit in Safari 9.0[1]. Just to pick a few:

* Force Touch Trackpad Mouse Events

* Content Blocking Safari Extensions (bytecode-compiled content blocklist for both iOS and OSX)

* SFSafariViewController for iOS (as an alternative to UIWebKit and WKWebKit)

* ECMAScript 6 support

* CSS properties are now unprefixed (including flexbox!)

I'm excited about the content blocking extension; it replaces the existing canLoad API that needs to be called on every request (which may result in some performance hit) with a JSON ruleset that will be bytecode-compiled and blocked by Safari itself. The better news is that an iOS app could also provide the JSON block list, so this works on Mobile Safari too.

[1]: [https://developer.apple.com/library/prerelease/mac/releaseno...](https://developer.apple.com/library/prerelease/mac/releasenotes/General/WhatsNewInSafari/Articles/Safari_9.html#//apple_ref/doc/uid/TP40014305-CH9-SW5)

<comment><USER10> Looks like some of the most useful ES6 features (such as lambda arrows and rest/spread/destructuring) are still not supported, so Babel isn't going away any time soon.

Also interesting to see that they redesigned Dev Tools again. I'm guessing enough people found the new ones so much harder to use than the original (that Chrome is still iterating on) that they felt the need to make it look more like what people were used to.

Finally, it looks like they're introducing a filter variant called backdrop- filters. It's in the Apple-edited CSS Filters spec, but I don't see any noise about it from the Chrome or Firefox evangelism teams. I wonder if it will be Apple-proprietary, or if other vendors are interested in it:

[https://code.google.com/p/chromium/issues/detail?id=497522](https://code.google.com/p/chromium/issues/detail?id=497522)

</comment></comment><comment><USER11> For anyone else who's wondering where the actual information is: you have to scroll up, not down. Far from obvious on a mobile device.

<comment><USER12> Thank you. I was wondering about it.

</comment></comment><comment><USER13> It looks like an incremental release. Not a bad idea considering how many bugs / issues Yosemite had. Hopefully, El Capitan fixes most of them.

<comment><USER14> Same, I'm still on Mavericks, and Yosemite still feels like "bleeding edge" to me.

<comment><USER6> I have to support an elementary school full of Macs, and Yosemite has been my ongoing nightmare. (Well, that and the bad joke known as OS X Server.) I won't update during the year for obvious reasons, but I'm still trying to decide whether or not I'm going to have to fragment my environment again (after just getting it all together with 10.9, finally). The incentive from Apple is very strong to install 10.10, but it just runs like utter garbage on all our older machines. And we can't run out and buy new ones whenever they feel like killing all hardware more than about 3 or 4 years old.

I'm still trying to convince people that our younger kids can learn just fine using the web browser on Windows and that we're overpaying money for these Macs (about double what we'd pay for a comparable Windows machine from our vendors) and wasting our tight budget. But there are a few people who just will not let them go. It's a real PITA running this mixed environment without another person to do sys/net admin stuff, or someone to handle more front-line support.

At this point, I'd take Apple just putting a stop to releasing these updates for iOS and OS X out at the beginning of the school year. It would be so much better if they'd do it about 4 months earlier.

<comment><USER15> >The incentive from Apple is very strong to install 10.10

And what incentive is that? Unless you need to latest Xcode to develop iOS apps, I don't see a reason to use Yosemite. I, for one, am happy to have stayed on 10.9 and will stick with it until El Capitan proves to be an "upgrade".

<comment><USER16> > And what incentive is that?

For one thing, they won't sell you Mavericks anymore. If you didn't buy it while it was out, it is simply unavailable for you to purchase. They obviously _could_ sell it to you, but they won't. It's a matter of intentional policy to make sure you don't buy in at any point earlier than the current one.

(Take that in, BTW. That means someone at Apple made the judgment that it is literally more important that you have their latest than it is for everyone to have a stable, reliable OS.)

<comment><USER17> Ah come on. Yosemite is not a stable, reliable OS? That's just hyperbole... Running 10.10.3 on half a dozen machines, mostly older ones, and it's stable, reliable and working just fine. MBPro's, Mac Mini's, MBAir, iMac.

<comment><USER18> Not sure if you're being sarcastic or not ...

Overall OS stability has gone down with Yosemite. I have to restart far more often than I should -- usually after coming out of sleep mode.

</comment></comment></comment></comment></comment></comment></comment><comment><USER19> [http://www.apple.com/osx/elcapitan- preview/](http://www.apple.com/osx/elcapitan-preview/) is the right link.

</comment><comment><USER20> When Apple switched from the big cats naming scheme to "places in California" I predicted (mostly to my adult children, who all have Apple computers): "How much ya wanna bet it's gonna be a cold day in hell when they name a build after someplace in SOUTHERN California?" If I'm wrong, I suppose the first build named after something in SoCal will be called "Joshua Tree" \-- nice tie in with U2.

<comment><USER21> I'm looking forward to OS X 10.12, La Brea.

<comment><USER6> Considering how 10.10 traps machines older than about 3 years in the digital equivalent thereof, they missed their chance.

<comment><USER22> Happily using 10.10 on a 6 year old macbook pro :)

<comment><USER23> Me too :)

</comment></comment></comment></comment></comment><comment><USER24> Anyone know what Python version comes bundled with El Capitan? I assume it's still 2.7.x, but one can always dream they have moved to Python 3 :)

<comment><USER25> I'm guessing 2.7 but I think we'll need a few months until the preview is available to know for sure.

<comment><USER26> Few months? I'm downloading it right now.

<comment><USER27> I've never used a preview build - will there be a DMG or do I need an existing Mac to upgrade?

</comment></comment></comment></comment><comment><USER28> Welp... it looks like OS X is about to discover tiling window management lite. ;)

<comment><USER29> On a serious note: if you need automatic window tiling in OS X, you should check out Amethyst [0] (available via homebrew cask). I mention this everywhere I can because I spent a lot of time searching for and testing various window management software for OS X myself, and Amethyst is only easy, fully functional alternative I've found that works out of the box.

[0]: [https://github.com/ianyh/Amethyst](https://github.com/ianyh/Amethyst)

<comment><USER30> Sorry, amethyst is nowhere near real tiling window managers. Hopefully with this we'll see real tiling window managers.

<comment><USER29> In what way? What functionality do you think that Amethyst is missing?

As for "Split View", it looks more like a simple two-window extension of the existing full screen functionality to me.

</comment></comment></comment></comment><comment><USER31> It is amusing how they are touting 'faster app switching' for the new release, when it was instant a few versions ago and has got steadily slower over the last few OSX releases (even on the latest hardware). It's good they are finally addressing some of the performance issues, but it's a bit embarrassing that things got to this point.

</comment><comment><USER32> I wonder if discoveryd will come back or if it's gone for good.

</comment><comment><USER33> Hooray for native window snapping. This is one less utility app I need to install on a fresh copy of OS X.

</comment><comment><USER34> Any word on minimum specs from people who've got the beta?

I'm guessing that moving the system graphics frameworks over to Metal will result in the minimum specs being bumped to whatever they've written Metal drivers for.

<comment><USER35> At minimum it would be supporting whatever Yosemite did.

And surely the OS would be falling back to existing behaviour if Metal is not supported.

</comment></comment><comment><USER36> I didn't see a list of supported hardware. Anyone know if a mid-2009 Macbook will be supported?

Also, I'm really hoping Apple supports ed25519 in ssh in 10.11... No reason why this is not available at this point.

<comment><USER37> In the same boat here, still running Mavericks on my MBP 17" from mid-2009.

Wonder how the performance is gonna be...

<comment><USER36> Yosemite on the MacbookPro mid-2009, slowest CPU is surprisingly spry on a SSD (Samsung EVO). The only two things I really miss are AESNI speed FileVault and updated SSH.

It's not going to set any records but totally usable for more normal tasks. What I really want is an up to date SSH without having to do ports/homebrew etc. so that I don't have to have exceptions for my setup.

</comment></comment></comment><comment><USER38> I say bring it! I moved all my development into a linux VM, so i'm shielded from them totally mucking things up further. Will be just another upgrade for me, instead of a nightmare.

Apple wants more entrenchment; to make it even harder to switch to something else. I'm already stuck on OSX because of itunes purchases and iphone sync, but that's really all it does for me at this point.

I definitely gave up features when switching to linux, And I'd do it again in a heartbeat. The less I rely on OSX, the better off I am. I've just been bitten too many times by attempts at innovation that only hinder me, and running old OSX because the newer version has problems or issues is not really a great solution either.

</comment><comment><USER39> Intelligence is a pretty nifty feature.

</comment><comment><USER40> I'm seeing a slide with almost no information. Is there a better link for this?

<comment><USER41> For now, I think this is the link [http://www.apple.com/osx/elcapitan- preview/](http://www.apple.com/osx/elcapitan-preview/)

</comment></comment><comment><USER42> I was probably stupidly hoping this might finally be the release where they actually did something about their awful antiquated filesystem. Maybe next year.

<comment><USER43> I've been hoping for exactly the same thing.

</comment></comment><comment><USER44> will we be able to change the zoom on the font in an email without increasing the font size? Huge PITA on Mac compared to Windows.

<comment><USER45> Right-click in the window's toolbar (or title bar), choose "Customize Toolbar...", and drag the "Smaller"/"Bigger" pair of control into the toolbar.

I agree this is not very discoverable compared to the usual Zoom In / Zoom Out menu items. Mail suffers from its age in many ways.

<comment><USER44> thanks for responding, I will try this out at home. Microsoft Outlook for Mac 2011 does not have this functionality, although the Windows version has for years.

I figured other users might have this type of problem as well but for all the downvotes...I guess not.

This minor feature was enough to drive me away from Mac Mail, and Outlook for Mac, over to Outlook on a Windows Virtual Machine.

Having a high-res 27" monitor is a blessing in many ways, but a literal headache in others, particularly late night.

</comment></comment></comment><comment><USER46> gotta love the adoption rate being percentage and not numbers. osx would show as a flat line...

<comment><USER47> Using numbers for adoption rate would make no sense at all. There would be no context for it. The comparison is how many installs are on the latest version. It would have to be X number out of Y number of installs in order to find out how many installs are running the same version. And then if you're doing X out of Y, you might as well normalize Y to 100, then you get a percent.

If you're looking to see how many of your users are on the latest version, percent is the only thing that makes any sense.

<comment><USER48> I think the point is, if Apple (or Google or whoever) would be the clear market leader, they'd probably show total count and be like "whoa, look, our last OS was the fastest growing from since beginning of time!!!!" (showing X units sold/year instead of percentage/months). And all fanboys would go "woohhooo, AppGooSoft is so awesome, everybody buys it!".

<comment><USER47> And that would be true in that case, but why would anyone take time from a keynote to highlight a metric they're not good at? What Apple is doing right is getting the majority of their devices upgraded to the latest version as soon as possible. They're doing better than Google in that regard. Meanwhile during Google's keynote, they would say how many Android devices are shipping compared to iOS devices, and say nothing about how quickly people are upgrading.

Toyota is showing off their Prius and say that it gets 100mpg. You're sitting in the back saying "yeah but the Vayron goes 200mph, why don't you show off how fast _your_ car goes?" Everyone is good at something and not good at everything.

The actual point the parent was trying to make is that Apple sux and Google rox, which is massively off topic.</comment></comment></comment></comment>


Drone used to save two swimmers caught in rough surf - <AUTHOR> http://www.smh.com.au/nsw/world-first-a-drone-has-been-used-to-rescue-two-swimmers-struggling-in-heavy-surf-20180118-h0kg9m.html <comment><USER2> Discussion: [https://news.ycombinator.com/item?id=16175512](https://news.ycombinator.com/item?id=16175512)

Other submissions of the same story from different sources, which might be useful in evaluating some of the comments on that page:

[https://news.ycombinator.com/item?id=16180146](https://news.ycombinator.com/item?id=16180146)

[https://news.ycombinator.com/item?id=16177381](https://news.ycombinator.com/item?id=16177381)

[https://news.ycombinator.com/item?id=16176665](https://news.ycombinator.com/item?id=16176665)

[https://news.ycombinator.com/item?id=16176430](https://news.ycombinator.com/item?id=16176430)</comment>


I'm not a robot: Amazon workers condemn unsafe, grueling conditions at warehouse - <AUTHOR> https://www.theguardian.com/technology/2020/feb/05/amazon-workers-protest-unsafe-grueling-conditions-warehouse <comment><USER2> Without taking a side in this battle...it strikes me that Amazon's biggest incentive for automating its distribution network, aside from labor cost itself, is that robots don't write petitions.

</comment><comment><USER3> I remember the very early days at Amazon in distribution operations.

It was an incredibly eclectic and progressive group of awesome freaks.

We needed to:

1)delight the customer 2)manage the constant growth of orders 3)grow the team to help manage the constant growth

Somehow we managed to achieve all 3, although often not unlike the famously funny I Love Lucy skit:

[https://www.youtube.com/watch?v=NkQ58I53mjk](https://www.youtube.com/watch?v=NkQ58I53mjk)

But from my anecdotal perspective, I do believe it resulted in the rise of a harsher and more transactional culture.

In order to achieve the 3 above, it meant there was precious little time to invest in helping those who were struggling in a very high operational tempo environment.

It was very much sink or swim.

If you were a proven consistent swimmer, there was certainly far more sympathy for having an occasional bad day.

If not, it was very much a cold and clinical:

"Knock knock" "Who's there?" "Not you anymore."

It doesn't make it ok.

But it doesn't make it illegal or evil either.

Amazon distribution operations was not, and is not, for everyone.

"March or die." [https://www.youtube.com/watch?v=L7z691yC9pc](https://www.youtube.com/watch?v=L7z691yC9pc)

Having seen many thousands come in/out of Amazon's gen 1&2 distribution center doors across numerous locations(20 years ago), a high percentage of people quickly leave when they learn they can't hide from their lack of reasonable productivity.

But there are very few companies on the planet that have created as many opportunities for unskilled workers to develop and grow with the company as well as earn a stake in the outcome.

A guy working for me who started as an Associate and was promoted to Lead when we were expanding beyond books is now Director of Logistics.

Countless others were promoted and transferred within the company.

Early stage Amazon distribution operations associates stock options are easily worth $2-3+ million, not including additional stock units gained since.

There isn't the same upside on stock units today, but wages and benefits are much better compared to 20 years ago.

Things could have been better, and they have gotten better, and there's certainly more room for improvement.

But if Amazon wasn't valued at $1 trillion, this would be a non story.

It's not that I'm unsympathetic, it's that when I look at the profit per employee for Amazon's distribution operations, it has far more in common with Applebee's that Apple.

</comment><comment><USER4> Frankly it is criminal what this organization gets away with with regards to humane labor practices. And it is criminal that one person made such a huge fortune off of the backs of so many other people. Perhaps the 21st century will see an end to this scale of exploitation, perhaps not.</comment>


Ask HN: How to say "I continued working for free" in your resume? - <AUTHOR> I was holding down 2 part-time jobs at the same location, one of which was a sysadmin position.
Once a full-time sysadmin was found, I handed over that position but continued to work (unpaid) to assist in the transition and, later on, to help with high workloads and major outages.
In total, I did paid work for about 8 months, and unpaid work on the side for 2.5 years.
How do you put that down in your resume? Do you change the from-to dates to the full period of paid + unpaid work? Or do you separate the two? Add an N.B.?
I'm sure others have been in this position before. I'd be very grateful if you could share your experiences. <comment><USER2> Since you generally don't mention your salary on your Resume, simply put it as a regular work experience. You may want to specify "full-time" versus "part- time" but it doesn't really help. This is only if someone asks you about this specific experience that you can give more details.

Remember, a Resume is a showcase of things you've done and would like to share with the world. We don't mention everything on a Resume. As long as everything is legit, you're good to go. Avoid going into too many details as it makes it confusing for a recruiter and you may get penalized for that. Show case what you've done during your part time experience under the same employer (when you were full time).

</comment><comment><USER3> There's no need to mention it was unpaid, unless it was infrequent enough that you think the company would deny you worked there at all. If the other part- time job was at the same company, I think your CV would look like this (newest role first - so, reverse chronological order):

Other Job, CORP: Other job's responsibilities, and additional sysadmin work (specific technologies or routine tasks)

Sysadmin + Other Job, CORP: Job responsibilities

</comment><comment><USER4> FWIW, the resume-friendly term is "pro bono".

</comment><comment><USER5> You can put whatever you want on your resume!

What do you think will look better to the person reviewing your resume? 8 months of work or 2.5 years? Or put it one way on one resume and another way on another and see which gets a better response.

It's a resume not a deposition.

</comment><comment><USER6> Can you explain what you mean by working for free?

It sounds like you got a new position at the same organization, but some of your duties were carried over. Were you specifically not paid for the sysadmin work you did after getting that new position? If not I would say that you were paid for that role. On your CV you can list those activities under your new role.

I would certainly never advertise that you did free work for a company(volunteer work is another story.) It makes the work you did seem like it was of low value.

You might get better feedback if you post a link to your resume. That way we could give more specific feedback, about your CV.

</comment><comment><USER7> You consulted. There's no need to mention the pay or not for the work.

</comment><comment><USER8> Why does it matter? Just put down what you did regardless of pay.

</comment><comment><USER9> The same way you say, "At XYZ Corp, I earned $125,500 per year." \--- namely, you don't.

You don't put these numbers into your resume when they are nonzero, so why put them in when they are zero.

</comment><comment><USER10> You don't need to claim your income on your resume. Volunteer work should only be labeled as such to your advantage. Inform your work that you will be doing this, if you will be using them as reference.

</comment><comment><USER11> Simply don't mention that it changed to unpaid. It sounds like you were doing real "job-like" work. It's not like you were doing unpaid contributions to a mate's hobby project.

</comment><comment><USER12> Why did you work unpaid for 2.5 years?

</comment><comment><USER13> Doesn't matter how much you got paid, just put it as normal work.

</comment><comment><USER14> Work is work. Just write it as a normal job.

I don't know the details, but don't work for free -- this is called slavery and it is illegal.

</comment><comment><USER15> You didn't work since you weren't paid. You volunteered your time to aid in a transition period, help reduce workloads, and keep your skills sharp. However I'd probably not mention that as that could throw up warning signs that would attract the DoL as there are strict rules on what constitutes volunteer work.

<comment><USER16> What? Work is work, regardless of whether paid or not.

I just spent 4 months, 2 full time, and 2 crunch-time working on an open- source project that I didn't get paid for - according to your definition I shouldn't be able to list it on a resume.

What matters more than the payment is the scope/amount of such work. If the remainder of 2.5 years (unpaid) was just ad-hoc, or "once in a while", I would mark it as such.

<comment><USER15> > What? Work is work, regardless of whether paid or not.

Most certainly not; within the context of providing services to a legal business entity within the United States, work is defined be receiving compensation for your time, skills, and knowledge. If you are doing something for a business entity and you are not receiving compensation, then it is defined as volunteer work, and there are strict limits on what can be done by a volunteer, chief of which is the volunteer's work must not be crucial to the operations of the business. Otherwise the DoL will classify it as work, and force the business to pay the social security and unemployment tax for your time.

The free software project is not run by a for-profit entity and as such is not bound by those laws.

> What matters more than the payment is the scope/amount of such work.

That's fairly idealistic. This tells me you value your time (and by extension, yourself) very low. Also, the Dept Of Labor would disagree with you.

<comment><USER17> While this might be a problem for the business, it has no bearing on what the employee can or should put on their resume.</comment></comment></comment></comment>


Teacher effectiveness ratings, programmers, and Khan Academy's data - <AUTHOR> http://bjk5.com/post/18609999923/teacher-effectiveness-ratings-programmers-and-khan

<comment><USER2> Teaching is a lot like programming in this respect -- if you try to enforce metrics of "performance", you usually end up with optimization for those metrics and dumber, less-educated students. Similarly, _students_ tend to optimize too, just from a different standpoint. Examples of this:

If you rate teachers based on the grades their students get, they will usually award their students higher grades for the same (or worse) performance. This isn't just a joke; many, many professors have reported their deans bearing down on them for awarding _too many bad grades_ , often to students who are so incompetent that they cannot write basic English sentences or perform long division. The solution -- not remedial courses, or letting them drop out (that would hurt financial aid income) -- but letting them pass even though they lack the basic skills to learn in that class, let alone pass. This also leads to the student mentality that they are being "given" grades (and thus can beg for higher grades) as opposed to _earning them_ through their own effort in the class.

If you rate teachers based on the number of their students pass a standardized test, the teachers will focus solely on the contents of that standardized test and put a huge amount of effort into educating the few students who Don't Get It, at the cost of all the students that do. I had this experience in primary and secondary school, where teachers lamented that they had to go over material for the Standards of Learning tests constantly and repeatedly, dramatically lowering the amount they actually had time to teach. The end result is a quick dropping of everyone to the lowest common denominator -- which often just ends up shifting the entire bell curve to a lower point.

If you rate teachers based on student evaluations, your results are nearly useless. Most students don't bother to write in much detail, since they're just glad to be done with the final exam (I did this too!)-- and often they use it for "revenge" on professors they thought were too hard. The teachers who get the best evaluations are often (though not always) the teachers who gave the easiest work and grades, and whose students turn out to be the most woefully unprepared for what comes next. Just like customers of your software are not always good judges of what they really want, students are often terrible judges of what good education actually is.

As far as I can see, nobody has come up with a magical metric for rating teachers. If anything, most of the metrics out there are outright counterproductive -- and you can see it in schools across America, where teachers are being constantly urged to inflate grades for their 'customers', overlook plagiarism, ignore the most talented students in favor of the least talented ones, and help drive down the quality of education for the next generation.

<comment><USER3> >As far as I can see, nobody has come up with a magical metric for rating teachers. If anything, most of the metrics out there are outright counterproductive -- and you can see it in schools across America, where teachers are being constantly urged to inflate grades for their 'customers', overlook plagiarism, ignore the most talented students in favor of the least talented ones, and help drive down the quality of education for the next generation.

You can do things to improve the quality of data - use multiple metrics, don't announce them up front and certainly don't standardize - so that optimizing for a specific test doesn't justify the cost, also change testing as needed/with dynamic feedback and use the results to get insight in to the problem. Computers can only help with this sort of thing. Ultimately it's about defining the objective of education, what environment students are supposed to be prepared by it and exposing them to that environment, just like you want to test the system in production as soon as you can, benchmarks are always synthetic and can't replace "real world" testing.

Data won't capture everything and could in fact be 100% misleading - that's the nature of imperfect knowledge - but if used correctly it can help provide insight in to situation. Just don't conflate benchmarks and reality, use it as a tool for improved feedback/analysis. Of course this approach is absolutely incompatible with bureaucratic systems. Heck the entire education system is based around optimizing for arbitrary/artificial evaluation metrics (all that crap about higher education and signaling, that starts with primary education).

As for favoring least talented over most talented, that's just different objectives, I don't think it changes with more quantifiable information about students performance, do you want to raise the bottom at the expense of the top.

</comment></comment><comment><USER4> The author is making a straw man argument, though it does not seem to be intentional (edit: I am referring to Rubinstein's original analysis). The author points out that using data for a single class and single year is not a reliable indicator (second graph). That is uncontested and exactly why ratings are based on 3 years of data and multiple classes where possible. Even this cannot provide a single, accurate percentile value. That is why confidence intervals are used and are rather prominently displayed in all the graphs; e.g. <[http://www.nytimes.com/schoolbook/school/656-ps-009-teunis-g...](http://www.nytimes.com/schoolbook/school/656-ps-009-teunis- g-bergen/teachers>);

Given the example above, there is one teacher who has is 50th percentile for career math, but the confidence interval (CI) indicates that this may really be anywhere from well below average to well above average. In contrast there is another teacher with a value of 3 and the highest bounds of the CI still place them well below average. Conversely there is a teacher that is 90th pctl and even the lowest bounds of the the confidence interval still makes this a highly effective teacher.

In sum, the data make evident that a few teachers are fairly unambiguously ineffective (at least with regards to test results), a few are unambiguously effective, but for the majority the most that can be said is that they are neither the best nor the worst, but somewhere in the middle.

So if you reserve yourself to making conclusions merited by the data, then there is some value to this (i.e. identifying the extremely ineffective and effective). As it stands now, the teacher with a 3 may very well have tenure and be paid considerably more that the teacher with a 90 (given that pay is a function largely of seniority and education, and nearly all teachers have tenure). That is what this exercise is meant to address.

So you definitely cannot assign a fine-grained single value to every teacher (and the authors analyses speak to that issue), but there does not mean you cannot make any conclusions at all. If folks make conclusions that exceed what is supported by the data that is a fault of the analyst or perhaps a function of poor communication or visualization, not evidence that the data is junk.

That said, the test could be improved (and supposedly are being improved) and the very least the measurements place more focus on the subjects being tested.

And the teacher effectiveness data is only 40% of the new approach to evaluating teachers in NY; the other 60% including peer evaluation. It may be useful if that became part of the public data so a more balanced picture is available; but it is unclear if that data would be public.

<comment><USER5> _So if you reserve yourself to making conclusions merited by the data, then there is some value to this (i.e. identifying the extremely ineffective and effective)._

Yes. Anyone who cares about the education of children will welcome any further improvements in evaluating teachers, but there is already actionable information available today. Bill Gates makes the good point that the best system of evaluating teachers should lead to interventions to help each teacher do better. But the existing performance gap, which may also be shown by which teachers other teachers who have children choose for their own children, could guide a system of encouraging the worst performers to seek other occupations

[http://hanushek.stanford.edu/sites/default/files/publication...](http://hanushek.stanford.edu/sites/default/files/publications/Hanushek%202009%20Teacher%20Deselection.pdf)

while rewarding teachers who teach effectively and are willing to take on challenging classrooms with students who have the greatest need.

[http://hanushek.stanford.edu/sites/default/files/publication...](http://hanushek.stanford.edu/sites/default/files/publications/Haycock%2BHanushek%202010%20EdNext%2010%283%29.pdf)

<comment><USER4> Current accountability reform places too much faith in the power of incentives and hence many metrics (not only teacher effectiveness and not only the NYC accountability system) are not directed to offering any sort of guidance towards improving schools. The NYC Progress Reports, which give schools grades, are another prime example of this. Personally, I hope that the next stage in accountability will see a shift to making the data more actionable from the perspective of practitioners and it is something I have been encouraging for a few years. I think part of the obstacle, though perhaps not the primary one, is the criticism that measurements are not accurate. So given the option of re-thinking how to make actionable reports or measurements vs. just improving what exists (via extending and revising statistical methods, refining business rules, improving data quality, and including additional data sources) the latter is winning out even in areas where there may be diminishing returns to doing this.

On the other hand, one could argue that the issue of how to improve the schools is addressed by other projects or other areas in the system, and it sufficient for these tools just to make clear and accurate evaluations. We are dealing with a big problem, both in terms of depth and significance. So there is room to approach this from many angles.

Regarding the issue of making the data public (i.e. Gates' Op Ed), there are competing values at play. Yes, it will be misused and some folks will be unfairly hurt. I would rather have data public (not just the teacher effectiveness data), and allow everyone the option to create there own diverse conclusions, perform their own analyses (like the one linked to), and as a society we can become more sophisticated and knowledgeable about these issues. The alternative is that the only people that will has access to this data is bureaucrats with a specific policy agenda and a handful of academics. Broader society, especially parents, has a right to weigh-in on these issues and be a part of this discussion and they cannot do this effectively without open data. To reiterate, I don't want technocrats driving education (that is part of the broader problem with current reform); hopefully open data such as this can limit that.

The solution is to do a better job of disclosing the information and providing the necessary context rather than just hide it. NYTimes did a pretty sweet job in this respect . I like where they are going with schoolbook.

I would like to see the media and public consistently push government for better open data. Right now that is not happening, and agencies are not going to make big changes in this area in the absence of that pressure.

</comment></comment></comment><comment><USER6> Of course, the real problem is crappy metrics. And this is why "teach to the test" is given such a bad rap.

If the tests were actually well-written, testing all sorts of critical reasoning and problem-solving abilities, then teaching-to-the-test would be the correct strategy, and metrics would be tremendously useful.

It makes me think somewhat of exams used for foreign students of English. The American TOEFL exam is extremely limited, and test prep can be extremely effective, without actually improving your day-to-day English. The British IELTS exam is extremely wide-ranging, and test prep is basically worthless, because it really does a good job of testing your English. To improve your test scores, you truly do have to improve your real-world English.

</comment><comment><USER7> I don't see a problem with effective metrics; they might help identify where teachers might need help.

The problem, is that usually nobody really does proper statistical analysis. The metrics I've seen, are usually like "mean student grade performance". In which case, what you'd want to do is have a really small class of smart kids. (Ergo, kudos to the teacher who finds a way to dump the idiots.)

I do think, however, you could do polling of teachers by asking the students, teachers, and other staff. In most cases you could easily have enough coworkers to figure out who's respected and who needs help.

</comment><comment><USER8> I'm looking at the original posts that inspired this:

[http://garyrubinstein.teachforus.org/2012/02/26/analyzing- re...](http://garyrubinstein.teachforus.org/2012/02/26/analyzing-released-nyc- value-added-data-part-1/)

[http://garyrubinstein.teachforus.org/2012/02/28/analyzing- re...](http://garyrubinstein.teachforus.org/2012/02/28/analyzing-released-nyc- value-added-data-part-2/)

In particular, the "same grade, different subjects" plot looks like a good correlation. Some noise, but otherwise exactly what you'd expect. Anyone know where to get the raw data so I can do more careful plots (e.g., a density plot instead of a scatter plot [1])?

Note that noise simply means you need more than a single year's data to make a decision.

[1] In a scatterplot, if two points overlap (which they likely do in this data), the apparent density is understated.

[edit: found the data here: [http://www.ny1.com/content/top_stories/156599/now- available-...](http://www.ny1.com/content/top_stories/156599/now-available-- 2007-2010-nyc-teacher-performance-data) ]

</comment><comment><USER9> Any field that produces only one metric will find people optimizing on it. Eventually the metric loses it's value. This is true in teaching, programming, and most everything. Life's not so one dimensional.</comment>


Cuba's 'sonic weapon' may have been mosquito gas - <AUTHOR> https://www.bbc.com/news/world-latin-america-49770369 <comment><USER2> I wonder if this is a sort of example where being wealthy relative to most of the population was a disadvantage. Perhaps they oversprayed in an attempt to make this upscale area more mosquito free than usual.

</comment><comment><USER3> Why is this linking to a google redirect? It's not like the URL is shorter that way.

</comment><comment><USER4> Better link: [https://www.bbc.com/news/world-latin- america-49770369](https://www.bbc.com/news/world-latin-america-49770369)

Also: [https://news.ycombinator.com/item?id=21017914](https://news.ycombinator.com/item?id=21017914)

<comment><USER5> URL changed to that from [https://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=newss...](https://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=newssearch&cd=2&cad=rja&uact=8&ved=0ahUKEwibrKjOtujkAhVMm- AKHbipA5QQxfQBCC4wAQ&url=https%3A%2F%2Fwww.bbc.com%2Fnews%2Fworld-latin- america-49770369&usg=AOvVaw3P8AyY1Oh1vQ4WfCeBCZNh). Thanks!</comment></comment>


Sexy image effect like in flash in pure CSS3... - <AUTHOR> http://www.nikesh.me/blog/2010/07/sexy-image-effect-like-flash-in-pure-css3/

<comment><USER2> HTML is getting more _flashier_ day by day

<comment><AUTHOR> yes it is ... :P nd thanks to CSS3 nd HTML5</comment></comment>


Stop Relying on GUI; CLI ROCKS - <AUTHOR> https://github.com/you-dont-need/You-Dont-Need-GUI <comment><USER2> There's a simple reason that even expert computer users still use the GUI for these types of tasks (copying, moving and deleting files/folders).

It is much faster to switch to the right directory path via a gui than typing out the entire path on the command line. (most times you are already using a gui based file explorer anyway) so the right context is already there in front of you.

It is just too slow to type everything for most users.

The only faster workflow I can think is a gui launcher/searcher (like launchy on windows, spotlight on mac) that "learn" your habits.

<comment><USER3> I still use GUI's as a map for directory trees, but when I use the command line, I use Bash and Bash autocompletes command/file/directory names.

None of which should be taken as a claim that I am an expert computer user. GUI's and the command line place different cognitive demands on tasks and provide different efficiencies: it's harder to automate tasks with the GUI and it's hard to see the lay of the land on the command line.

</comment></comment><comment><USER4> Does ncurses/terminal based apps like mc (midnight commander), MITMProxy (Man- in-the-moddle proxy) count as command line?

I find myself wanting more apps like this.

<comment><USER2> Exactly! Simple and fast text based GUIs. Where did they disappear to? =)</comment></comment>


Is this extension's UI appealing? - <AUTHOR> https://chrome.google.com/webstore/detail/aobclpbhnodnafnndcfgfecfeloganfm I wanted to build a chrome-extension about saving multiple tabs in a click, that a lot many other extensions do, but with a more simpler and elegant design.<p>Want to get opinions and suggestions from everyone out there who shares the some idea of having intuitive design and ease of use while developing applications. <comment><USER2> Honestly, I think the dark colors should be changed to something lighter, fixing the fonts as well. Other than that it works as intended.

<comment><AUTHOR> sure.. will include the option of setting the color tone in next revision. thanks for reviewing

<comment><USER2> Sounds good, and you're welcome.

</comment></comment></comment><comment><USER3> looks good to me. seems to be inspired from one of the JS links you have mentioned. nice effort, try using a bit soft color tone.

<comment><AUTHOR> thanks for reviewing.. will definitely add the option of changing the color tone in the options page in next revision.

<comment><USER3> Also try doing animations using jquery once you append the list of links with new links, like making the new links come to top, it will help in finding the location of the new links, once the list gets big.

<comment><USER3> 'fade in' effect will be a good choice, to make the user see for the change in his list.</comment></comment></comment></comment>


AllVid Battle Lines: Google, Best Buy, Sony Ally Against Big Cable - <AUTHOR> http://www.wired.com/epicenter/2011/02/allvid-tech-alliance/

<comment><USER2> From the article, the National Cable and Telecommunications Association is quoted as saying that "Sony/Google are asking the Commission to ignore copyright, patent, trademark, contract privity, licensing, and other legal rights and limitations that have been thoroughly documented." Such dishonesty defines the terms of the conflict, and makes it clear that the conflict is not at all about who is right, or what is best for consumers, but rather what makes the most money in the very short term.

Not, of course, to say that the AllVid Alliance isn't also pursuing similar motivations. Rather, it seems that in this case that the NCTA relies heavily upon dishonesty about the AllVid Alliance's position in order to make their case. That should say something about which side consumers, developers, activists, etc. should be most comfortable supporting.</comment>