The Lisp Curse - <AUTHOR> http://www.winestockwebdesign.com/Essays/Lisp_Curse.html <comment><USER4> Will it be too much to ask that the lispers build cool shit, and then brag about how lips made it easy? That would be more pleasant compared to this chest thumping.

The traits associated with lispers(lone wolves, nih syndrome, not interested in boring tasks viz. documentation) aren't unique to lipsers. Most of the good programmers, regardless of their language choice, suffer from this mentality, and a lot of good stuff comes out of it.

CLOS is cool - I get it. And extending the language by parse time code transformations is cool - I get that too. But does anyone seriously think that's the only thing that makes cool shit possible? There is a lot of great stuff out there which is written in languages which don't have macros, lot of stuff which was written by lone wolves, lot of stuff which existed but was re- written just because.

When someone is orgasming to perceived benefits of lisp(not all of it is real), why does he have to make it look like "look lisp is so powerful, so powerful it's harmful"? Can't you just leave it at lisp is powerful and it helped me build this thing super fast. Why is this pathetic excuse of "it's so powerful it's harmful" necessary?

And before you take out your pitch forks, please, you aren't the only one who programs lisp. I like Clojure, but mostly because of its nice seq abstractions, small core, interesting concurrency primitives, jvm. Macros are very low in my list of reasons to like Clojure. I tried liking Racket, and though I still like it, I would have preferred a higher level seq abstraction. I have skimmed through "Practical Common Lisp" and I fail to see the charm - there isn't anything which can't be conveniently and concisely coded in Ruby or Python. Lisp has its benefits, but they are overblown.

<comment><USER5> I'd tend to agree. The powerful metaprogramming features of Lisp are often unnecessary in day-to-day code, and definitely overhyped. It's poor form to use a macro when something simpler will do. They're just another tool, and when you need them it's great to have them, but do all projects demand _the_ most powerful language features? Hardly.

However, I'm also with the author in that there are obvious social issues arising from the existence of many implementations. If I write in C (or even C++) using standard libraries, then I can be reasonably assured that my code will compile anywhere. For obvious reasons, that's not the case with Lisp dialects despite their superficial similarities, but I think that catches many neophytes off guard.

So even if such detrimental personality traits aren't peculiar to Lispers, there is a strong apparent correlation because of the "fractured" community. Still, I think that has less to do with the power of the language and more to do with its simplicity and lack of BDFL. Anybody can make their own Lisp, their own object system, and no one will object—no pun intended.

<comment><USER4> > However, I'm also with the author in that there are obvious social issues > arising from the existence of many implementations.

There are issues with competing implementations, but I would say that's not totally bad(options are good) and over time, some equals become more equals than others. Python has numerous web frameworks, attributed to the fact that it's easy to define your own, but a newbie is more likely going to stick with Django.

As I said, people re-implementing things "just because" isn't unique to lisp and might not be as bad. Look at Flask - it was an April Fool's joke by Armin which is now a proper micro framework. It isn't like Django wasn't the dominant and recommended framework when Flask came into being. It's good to have options and progress depends on people fooling around.

Look at async scene. You have twisted and you have gevent and you have diesel. Templates? Jinja2, Mako, Django, Cheetah etc.

Python or Lisp, most of the people are going to make their choices and stick with it. It's not like everyone who programs lisp starts writing their own CLOS, and not everyone who programs Python tries to write his own framework regardless of how easy it is.

> For obvious reasons, that's not the case with Lisp dialects despite their > superficial similarities, but I think that catches many neophytes off guard.

I don't know. Doesn't most of the programmers program to a particular scheme or lisp implementation(sbcl, racket, clozure, gambit, clojure)?

> So even if such detrimental personality traits aren't peculiar to Lispers, > there is a strong apparent correlation because of the "fractured" community.

I think more than the "fractured" community, it depends on the out of the box experience. If I am programming Racket, I won't try to build an object system of my own - the one it provides is good. If I am programming Clojure, though it doesn't provide a conventional object system, I agree with the choices and won't try to implement my own.

<comment><USER6> > > For obvious reasons, that's not the case with Lisp dialects despite their > superficial similarities, but I think that catches many neophytes off guard.

> I don't know. Doesn't most of the programmers program to a particular scheme > or lisp implementation(sbcl, racket, clozure, gambit, clojure)?

Common Lisp libraries seem to be getting much more portable across implementations, so within the CL dialect the language implementation is becoming less of an issue I think. And QuickLisp is one counter point to the OP -- it has broad community support.

</comment></comment></comment></comment><comment><USER7> I have a genuine fondness for lisp, but this article lost my interest pretty quickly with the thought experiment. "Adding object orientation to C" doesn't require "the programming chops of Bjarne Stroustrup"; you can write object- oriented code in unmodified C (indeed, there are people who do exactly that). Nor is C++ the only way to extend the language to add convenience to doing so. Objective-C, for example, takes a completely different and much simpler approach. C++ doesn't even satisfy the stated requirement of "keeping them backward-compatible with the original languages, modulo some edge cases", unless "some edge cases" means "large parts of the language" (semantics of storage class specifiers and type qualifiers, what is and isn't an lvalue, rules for implicit type conversion, ...)

From a certain perspective, these are silly little details, but if you don't understand the silly little details of the other languages you write about, why should I listen to what you have to say about the virtues of lisp?

<comment><USER8> On he other hand, I didn't really need the C/objects piece of technical evidence to support the "Lisp makes metaprogramming trivial in ways that other languages don't" argument. That one kind of stands on it's own, so I could move on to the rest of the article.

The article wasn't about Lisp as much as it was about Not Invented Here syndrome. As others have said, the social and organizational issues become the major obstacle when your working with the greybeards and technical wizards that make the actual CS + CE questions a breeze

</comment></comment><comment><USER9> I really wish people would stop citing the Paradox of Choice. The studies are not reproducible, and meta-analysis reveals extra choices have basically zero impact on consumers. We've apparently somehow learned to cope, which is probably why a chain of supermarkets specializing in choice-free shopping has yet to take off.

See Scheibehenne, B., Greifeneder, R. & Todd, P. M. (2010). Can There Ever be Too Many Options? A Meta-Analytic Review of Choice Overload. Journal of Consumer Research, 37, 409-425.

You can download it here: [http://www.scheibehenne.de/ScheibehenneGreifenederTodd2010.p...](http://www.scheibehenne.de/ScheibehenneGreifenederTodd2010.pdf)

<comment><USER10> > I really wish people would stop citing the Paradox of Choice.

Even if it were true, it's not as though there is no choice in other language communities.

What python web framework should I use? I can choose among several well- documented, supported, maintained systems; and if I need an extra library for a specialized task, there's a packaging system to install it (and it's probably well-maintained and documented, as well).

The times I've looked at lisp I just don't see that at all. Look here:

[http://stackoverflow.com/questions/540953/best-web- framework...](http://stackoverflow.com/questions/540953/best-web-framework-in- common-lisp)

Those frameworks are all either dead or pre-production-quality.

I'd like to like lisp, but I find that I'm a software engineer before a computer scientist. Things like a good extension mechanism, good documentation, a complete standard library, and a robust community matter more to me than a powerful macro system.

Clojure and racket may be exceptions. I'll probably try one of those out.

</comment></comment><comment><USER11> I find this very interesting. Really, there is a larger principle here: that in today's world, languages become popular, in part, by encouraging social connectedness, e.g., forums for solving problems, interoperability between different codebases, etc. The author's point, then, is that, perversely, one way to encourage social connectedness, is to be almost-but-not-quite powerful enough that one person can do everything alone.

I find a couple of misconceptions, though. The most glaring is the lack of distinction between conceiving an idea, and implementing it. This is best exemplified by the following:

> In a world where teams of talented academics were needed to write Haskell, > one man, Dr. Tarver wrote Qi all by his lonesome.

Teams of talented academics, building on the work of others going back decades, were required to _design_ Haskell. Once that design was done, anyone could copy it. Sure, Tarver implemented Qi all by himself, and the fact that he could is significant. But let's not talk as if Qi is based entirely on ideas that he made up himself without considering the work of others.

<comment><USER8> > In a world where teams of talented academics were needed to write Haskell, > one man, Dr. Tarver wrote Qi all by his lonesome.

I think you're right about how the author is making an invalid comparison, but I think his point still stands.

In order to make a good comparison, he would say the same things about Tarver and Qi, but he would have to say something along the lines of "Lisp has been extended in functional Haskell-y directions (Qi) and in object-y Smalltalk directions (CLOS). It would be very difficult to extend Haskell in as many dimensions as easily as it is to extend Lisp"

Not that you necessarily want functional languages to have Smalltalk flavors, but I think it was wrong to compare Tarver with the academics like you say. The plus for Lisp is that it makes implementation of language features easier, you still have to come up with them just like everybody else.

</comment></comment><comment><USER12> _Lisp is so powerful that problems which are technical issues in other programming languages are social issues in Lisp._

Here's my take on it: Social issues will swamp the technical power of any language.

Corollary: Virtuous cycles in the social dimension will augment the technical power of any language by an order of magnitude.

The over-arching principle: A programming language community is as much a social artifact as it is a technical one. You have to get both sides right to succeed.

<comment><USER13> "Corollary: Virtuous cycles in the social dimension will augment the technical power of any language by an order of magnitude."

To wit: Java, Go, C++,....

<comment><USER14> It's interesting to note that most of the Java language design was specifically targeted at the social aspect of writing software.

<comment><USER15> But only that of certain social circles. For example, it fails miserably (imho) as a "hacker's language". I suspect the social and technical aspects of a language are inextricably linked.

</comment></comment></comment></comment><comment><USER16> TL,DR: repeats old misconceptions.

Task: go to the Apple Macintosh App Store. Download Clozure CL. Get Quicklisp. Get libraries. Start hacking. Connect via #lisp, reddit/lisp, the CLozure CL mailing list. Put your stuff on Github, make it available via Quicklisp.

<http://ccl.clozure.com/> <http://www.quicklisp.org/>

Have fun.

<comment><USER17> Just took a look at QuickLisp and that's a big improvement over the last time I looked at Common Lisp. On the other hand, there's a couple of points to make.

1) While quick lisp does have an amazing array of packages, there's still some simple, yet glaring deficiencies. For instance, there's no package to talk over a serial port. If I go to Google, the top link is a stack overflow post with some code on how to do that on Windows. The next few posts links are either people being told to use the FFI or raw writing to /dev/stty with the unix command line being used to set the tty parameters.

Comparatively, the first link Google returns for python is for PySerial, which will handle all the serial port settings on its own.

I was originally going to use this as an example of contrasting documentation, since I assumed that both languages would at least have a serial library.

2) If I want to send an e-mail, quicklisp offers cl-smtp and smtp4cl, while python mostly just offers smtplib. On the other hand, the documentation for smtplib (<http://docs.python.org/library/smtplib.html>) is readily available, while cl-smtp is limited to the (admittedly clear) README file.

\---

I happen to love the lisp aesthetic (though I'll admit to preferring scheme over CL). Still, the main thrust of the article is that Lisp is cursed with a disorganized array of unsupported, poorly documented, incomplete solutions. QuickLisp has only solved the disorganized part of that. If there's a bug in smtplib, I can feel pretty secure that it will get fixed. Honestly, I bet I'd have the same luck with cl-smtp, but what about smtp4cl?

I don't believe that it's a curse and I do think that it can be solved. However, this is a cultural problem in the lisp community and ignoring it. To put it differently, if we'd had this discussion four years ago, someone would have brought up asdf and said that that solved all the problems. However, we now have QuickLisp because asdf wasn't solving all the problems. It's great and things are better than they were, but we're not done yet.

<comment><USER16> ASDF and Quicklisp are two different things. Quicklisp uses ASDF.

ASDF hasn't solved many problems. It was basically another system definition tool (with a different license). We had them before. What ASDF provided was that open source / free software used a common system definition.

Quicklisp OTOH provides a service. It uses ASDF. I provides library management and a collection of libraries.

The process over that to improve these libraries, make them better documented / more portable / rated / ... is something that happens over time.

Quicklisp does not solve all problems. It does not aim to. But it solves some.

<comment><USER17> I agree with you completely. QuickLisp does a damn fine job of solving some major problems. Honestly, looking through QuickLisp while writing up my post has made me consider moving from scheme back to CL for the first time in a long time.

My comment about asdf mostly comes from my experiences back in 2005 when I repeatedly heard that Common Lisp had NO problems and that asdf was so superior to CPAN or rubygems that there was no need to implement a new package system. In the same way, I often heard that we didn't have an issue with insufficient libraries, since UFFI (or was it CFFI?) has solved all of that. I wouldn't have been surprised if those same commentators would today declare that QuickLisp has solved everything.

However, those conversation that I had back in 2005 were not with you and I apologize for putting words in your mouth.

</comment></comment></comment></comment><comment><USER18> Clojure so far looks like a Lisp designed with at least some awareness of this curse. It has a strong "one obvious way to do it" flavour to me and I hope the devs will keep it this way.

<comment><USER19>
        Every second or third serious Lisp hacker will roll his
        own implementation of lazy evaluation, functional purity, arrows,
        pattern matching, type inferencing, and the rest.

Seems to describe clojure pretty well, tho I don't know about arrows, i haven't gotten that far into categ theory vs. real world implementations

<comment><USER20> I tend to disagree. Unified solutions exist on the level of the core language and libs for both lazy evaluation and (pragmatic) functional purity, and the recent discussion around logic programming and pattern dispatch implementation is a beautiful example of how some really smart people are working together towards a common solution, instead of everyone rolling their own.

</comment></comment></comment><comment><USER21> I find Lisp a bit unsettling because when you look at the code it's like you're looking at pure abstraction... there is a lack of semantic/symbolic content to latch on to and feel 'anchored.' Gives you the feeling that if you use Lisp, you'll have to be thinking _hard_ the whole time you're using it.

<comment><USER22> I'd be careful about drawing any conclusions from a first, second, or even tenth impression. That unsettling feeling may just be unfamiliarity. What you really want is a sense of what it would be like after you've developed a feel for it - admittedly something of a chicken-and-egg problem.

What used to feel like "pure abstraction" to me now feels like lightweight (if dense) code whose shape is determined by the problem rather than by arbitrary constraints and noise.

<comment><USER23> The standard image macro meme for newcomers to Lisp is this: <http://img264.imageshack.us/img264/1397/lispnd7.png> But I agree there's something more as you work with the language and start mastering macros, perhaps it's similar to the Tetris Effect, and the process takes you from frightful screams to delusions of grandeur back to solid practicality and programs that solve a problem. The process may take a while.

</comment></comment></comment><comment><USER24> I tried to write a Lisp application once. Couldn't figure out how to make something standalone that could be run from bash. Most of the websites and discussions I looked at around the issue suggested that one would be wrong for even wanting such a thing. Eventually did my project in python.

<comment><USER16> You could have read a manual (creating standalone applications is documented for each implementation) or asked other users.

SBCL:

<http://www.sbcl.org/manual/#Generating-Executables>

CLISP

<http://www.clisp.org/impnotes.html#image>

and so on...

<comment><USER13> SBCL: "This implementation is not as polished and painless as you might like:

"It corrupts the current Lisp image enough that the current process needs to be killed afterwards. This can be worked around by forking another process that saves the core.

"There is absolutely no binary compatibility of core images between different runtime support programs. Even runtimes built from the same sources at different times are treated as incompatible for this purpose.

"This isn't because we like it this way, but just because there don't seem to be good quick fixes for either limitation and no one has been sufficiently motivated to do lengthy fixes."

CLISP: "Memory images are not portable across different platforms (in contrast with platform-independent #P".fas" files). They are not even portable across linking sets: image saved using the full linking set cannot be used with the base runtime:

        $ clisp -K full -x '(EXT:SAVEINITMEM)'
        $ clisp -K base -M lispinit.mem

base/lisp.run: initialization file `lispinit.mem' was not created by this version of CLISP runtime"

These are the sorts of perennial problems common to image-based languages, specifically those that use "undump"-ish methods to create executables.

<comment><USER16> That dumping an image lets one quit the image dumped, that images are bound to certain versions of the runtime, etc. are inconvenient for users of images. It is a non-issue for creating an executable.

</comment></comment></comment></comment><comment><USER25> The linked article "The Bipolar Lisp Programmer" is brilliant: <http://www.lambdassociates.org/blog/bipolar.htm>

I don't know how correct it is about Lisp in specific, but he's definitely nailed a familiar type.

<comment><USER16> Mr. Tarver failed to see that this is not specific to Lisp.

</comment></comment><comment><USER26> > Lisp is so powerful that problems which are technical issues in other > programming languages are social issues in Lisp.

I think this is a rather stupid argument. The same way you could argue that a boat is a better means of transportation than an airplane. With the boat agreeing on a holiday destination is less of a social issue because it is limited by technical constraints anyway.

</comment><comment><USER27> I wonder though if this is an out of date concern because the last time Lisp was popular was before the proliferation of open source and tools like github. As a newbie Clojure programmer, I feel like I've already come across some very successful open source frameworks/libs (ex. Noir, Storm).

I do get concerned though how PL fads seem to move in circles, and would love to learn more why Lisp is experiencing a renaissance. What's changed?

<comment><USER16> Lisp had open source before you had it. The Lisp implementations were already shared during the 60s. They travelled by tape. The github of that time was the time-sharing system, where hundreds of users shared a computer and its storage: mainframes and large minicomputers.

See ITS:

<http://en.wikipedia.org/wiki/Incompatible_Timesharing_System>

The MIT in the 70s and 80s had LANs and file servers already. The networked Lisp Machines used common repositories. There weren't passwords. Different sites shared files via tapes and via the early ARPA net. Losing this when the MIT commercialized some of the technology inspired Richard Stallman to start the free software movement.

Lisp and AI users collected and shared a lot of software. See for example this repository with software from the 80s and early 90s:

<http://www.cs.cmu.edu/afs/cs/project/ai-repository/ai/0.html>

Sharing was done via FTP servers.

When Common Lisp was initially developed from 82-84, immediately open source implementations (with different licenses) were created: CMUCL, KCL, AKCL, WCL, CLISP, ... which can be traced to today's SBCL, ECL, CCL, ABCL and others.

</comment></comment><comment><USER28> Managers want employees to be fungible, so they hamper their employees. That points to a severe Principal-Agent problem. Why not ban programming altogether and make them parrot the venerable ITIL corpus?

The post is stunningly ignorant. Alan Kay points out that actual programming practice represents a tiny fraction of what is known. The answer isn't for managers to create Principal-Agent problems by dumbing down their employees, but hiring knowledgeable managers who recognize the abyss that separates the state-of-the art from industrial practice. Startups emerge from this gap in understanding.

</comment><comment><USER29> _Consider the case of Scheme, again. Since making Scheme object-oriented is so easy, many Scheme hackers have done so. More to the point, many individual Scheme hackers have done so. In the 1990s, this led to a veritable warehouse inventory list of object-oriented packages for the language._

It's funny that something quite similar can be said about today's arguably most popular and ubiquitous language: JavaScript. Each of MooTools, ExtJS, Prototype etc. sport their own model of OOP, with minor or even major differences. Yet it doesn't seem to be so big of an issue that it prevents cool stuff from being done in JS. For one, I don't think many people would claim that you _need_ some implementation of OOP (i.e. classes, inheritance 'n stuff) to effectively program in JS. The readily available mechanisms are perfectly sufficient to just start coding what you want to code and doesn't require "amending" the language first.

JavaScript code generally seem to be fine with that and happily proceed to create another batch of coolstuff.js. But according to the article, Lisp hackers have totally different mindset: they first "create a language" and only then proceed to use it to actually code stuff. (There is quote about giving man a Lisp...) If that's indeed true, I don't think it's really an issue of the Lisp itself, i.e. it's all-too-great power. After all you can just proceed into writing your _program_ rather than writing a _language_ first - like in JS. If Lisp coders fails to do that, I would say it's a problem of Lisp coders.

</comment><comment><USER30> Previous discussion from a year ago: <http://news.ycombinator.com/item?id=2450973>

<comment><USER31> I'm surprised. I wrote this essay a year ago and it's _still_ getting attention. I've received occasional upvotes for that post since I submitted it but I have no idea why it made it to the front page again.

</comment></comment><comment><USER32> This is bullshit. People adopt languages because interesting things are made in them. The most interest I've found in lisp has been Emacs, because it's an awesome editor. If more Emacs-level projects in lisp were out there I bet lisp would be more popular. Otherwise, this is just political bravado with no concrete aplication.

<comment><USER16> 'interesting' is a somewhat vague concept. You need either 'interesting for a lot of people' and/or 'easy enough for an implementor who would create such a thing'. It is also important that a programming language and its implementation is used by people who develop new stuff. Currently no large company supports Lisp for that - not Apple (they did that in the 80s), not Google, not SAP, not ... Sometimes they buy technology which has traces of Lisp. Google bought ITA software - they are a Lisp shop. Apple bought Siri, Siri had traces of Lisp in - the original research project was done at SRI, which assembled modules written in many languages - among them Lisp. But that's it.

When display-oriented text editors were developed, very early Lisp programmers implemented them in Lisp and even created engines which were portable for it (the Emacs C part which implements a simple Lisp runtime).

When a CAD company needed an extension language, they added a simple Lisp dialect written in C to their CAD system. Born was Autolisp for AutoCAD - <USER2> in millions of installations.

Today there are enough alternative languages around which can be easily embedded - for example Lua.

Common Lisp is slightly more difficult to embed. One either uses ECL (Embeddable Common Lisp) or a home-grown Common Lisp variant. Which for example Quicksilver ( <http://www.broadvision.com/en/quicksilver.php> ) or PTC's CREO Elements ( <http://www.ptc.com/product/creo-elements-direct> ) do.

You might never hear of the latter two - they are interesting applications - but not used by that many people.

There are interesting and unique applications written in Common Lisp - <USER3> their user domain is very specialized. In music composition you could use OpenMusic, PWGL and several others. In cognitive modelling (used for example to test user interfaces) ACT-R is used. In proving correctness of software something like ACL2 or PVS might be used.

But these are certainly not the interesting applications you have in mind, even though there were probably hundreds of interesting research projects done with something like ACT-R - but it is software for a narrow user group.

</comment></comment><comment><USER33> Ok to be honest I agree, but in a different way. The curse is when you have to go back from a Lisp variant to a crappy procedural language. It just makes you cry, even if it is really more productive than Lisp.</comment>


Open Source Project Management, Web Based Apps - <AUTHOR>

Hi...
Need opinions on the best Open Source/Web Based Project Mgmt apps..
our project needs:
 -User Login/Registration Access Control
 -Multiple Projects
 -Version Control
 -Doc/File Control
 -Issue Tracker
 -Ability To Search Docs/Files
 -Admin Function
 -File Checkin/Checkout
 -Ability to review files via web
 -
Reviewed a bunch of apps.. but now I'm curious as to what the group thinks...
The app/project that this system supports probably won't be open source.. so i can't use a proprietary app under the guis of creating an open source project..
thanks for your time on this!
tom <comment><USER2> I dig <http://www.redmine.org/> I think it hits most of your needs.</comment>


Show HN: Gains Supply – Discover the best new bodybuilding articles and products - <AUTHOR> http://gains.supply/ <comment><USER2> You might want to check your registration form. Users can't register at all, just sends back a generic "Internal Server Error" in your at-error div.

</comment><comment><USER3> Hello.

Are you doing any analysis on these, or these are just articles directly taken from the websites. Because it will be hard to differentiate good articles from the bad ones.

<comment><AUTHOR> No analysis yet. Just getting the ball rolling with feeds from selected blogs and youtube channels.

I'm hoping that, over time, the community will weed out the good articles from the bad.

</comment></comment><comment><USER2> You know what? I think this might actually be subtle HN-focused spam, but I'm upvoting anyways just because of the unique URL.

<comment><AUTHOR> I created Gains Supply because I'm interested in bodybuilding and I'd genuinely like to start a community that features and discusses helpful articles and products in that niche. I Hope posting it here doesn't come across too spammy, just looking for early users.

<comment><USER4> Feels a bit on the spammy side since there is no user activity to curate the list. Catch-22.</comment></comment></comment>


GrafX2 2.5 Released – ultimate 256-color painting program for pixel art - <AUTHOR> http://www.pouet.net/topic.php?post=542050 <comment><USER2> I am glad to see it for Haku and hope to see it ported to other platforms.

My favorite paint program was Electronic Arts Deluxe Paint series.

</comment><comment><AUTHOR>
         G R A F X  2
      "Pixels not Dead!"

Tonight I visited IRC, joined #grafx2 channel on Freenode and got "WOW!" effect[0] - _Adrien Destugues_ (aka ' _PulkoMandy_ ')[1], one of GrafX2's developers since 2007, told that _v2.5_ released[2] few hours ago, but he found one issue with " _make install_ " script and fixed it on next commit[3]. So, all just now ready for package maintainers ;-)

Source code hosted on Gitlab - [http://gitlub.com/GrafX2/grafx2](http://gitlub.com/GrafX2/grafx2)

Version history - [http://grafx2.chez.com/index.php?article4/version- history](http://grafx2.chez.com/index.php?article4/version-history)

Packaging status on Repology[4] show current state of "grafx2" package in repositories of different OS (Linux-based, BSD-based, etc.).

Soon links to all known binary builds will be collected on official site on " _Downloads_ "[5] page ;-)

There are many features for customizing[6]: keyboard shortcuts, skins, fonts, bookmarking folders, etc.

But AMAZING feature of GrafX2 is Lua-scripting and possibility to create addons![7]

One of most known free addons package is " _DB 's TOOLBOX_"[8] produced by _Richard Fhager_ (aka ' _DawnBringer_ ') - collection of many AWESOME Lua- scripts for different tasks. Latest version of package is " _DB 's TOOLBOX v1.4_"[9] and was released on _December of 2017_!

NOTE! Web-site now migrated to [http://grafx2.chez.com](http://grafx2.chez.com) (if you will try visit [http://grafx2.tk](http://grafx2.tk) it will automatically redirect you to current web-site).

Old wiki[10] still hosted on PulkoMandy's web-site.

P.S.: My screenshot taken under Linux - [http://i.imgur.com/FOSI7kq.png](http://i.imgur.com/FOSI7kq.png)

[0] [http://i.imgur.com/NHZC9Ge.png](http://i.imgur.com/NHZC9Ge.png)

[1] [http://www.pouet.net/user.php?who=20122](http://www.pouet.net/user.php?who=20122)

[2] [https://gitlab.com/GrafX2/grafX2/tags/v2.5](https://gitlab.com/GrafX2/grafX2/tags/v2.5)

[3] [https://gitlab.com/GrafX2/grafX2/commit/8e94f338dff72024ec4e...](https://gitlab.com/GrafX2/grafX2/commit/8e94f338dff72024ec4e1e1ecd15aa8271ff8317)

[4] [https://repology.org/metapackage/grafx2/versions](https://repology.org/metapackage/grafx2/versions)

[5] [http://grafx2.chez.com/index.php?static3/downloads](http://grafx2.chez.com/index.php?static3/downloads)

[6] [http://grafx2.chez.com/index.php?article12/customization](http://grafx2.chez.com/index.php?article12/customization)

[7] [http://pulkomandy.tk/projects/GrafX2/wiki/UserGuide/Lua](http://pulkomandy.tk/projects/GrafX2/wiki/UserGuide/Lua)

[8] [http://pixeljoint.com/forum/forum_posts.asp?TID=12854](http://pixeljoint.com/forum/forum_posts.asp?TID=12854)

[9] [http://pixeljoint.com/forum/forum_posts.asp?TID=26080](http://pixeljoint.com/forum/forum_posts.asp?TID=26080)

[10] [http://pulkomandy.tk/projects/GrafX2/wiki/UserGuide](http://pulkomandy.tk/projects/GrafX2/wiki/UserGuide)</comment>


Automakers Say You Don't Really Own Your Car - <AUTHOR> https://www.eff.org/deeplinks/2015/04/automakers-say-you-dont-really-own-your-car <comment><USER2> My honest opinion here is that almost everyone is completely missing a crucial point. Nearly all of the reasons given for locking people out of modifying their cars apply equally to cars without computers. Changing the odometer? It's far easier to do that on a car with a mechanical odometer. Making the vehicle non-emissions compliant? Nobody used the DMCA to argue that people shouldn't be allowed to remove their catalytic converters. All of this has been fought for far longer than computers have existed. People have been successfully fooled into thinking that this is a new situation, when technology is only being used to prop up an ancient ideology. Very frustrating indeed!

<comment><USER3> Of course this has nothing to do with lawsuits, fear of car modifications or emissions compliance. It is a businesses decision in order to establish new revenue streams where before there only was a single sale (and revenue) per product.

See all that data that is generated when people use the product? That could be mined, refined, and made into new products. All those computer screens in the car are suddenly new avenues to push advertisements. All those critical equipment are a avenue to sell repairs, where the producer has monopoly. And if nothing else, the computer inside the car can always be made into a platform.

Take a product, throw in some DRM, and voila, you can create revenue after sale. The DRM and the accompanying user agreement is the glue from which all that extra revenue can be made.

From a company perspective, I don't see how much of a choice they've got. A competitor can use that extra revenue to lower prices for which a consumer won't be able to assess when buying. Selling equal-looking products at higher prices normally spells doom, and regulations haven't even begun addressing the issue.

<comment><USER4> It's not only the data, but also the continued promotion of dealer service lock-ins.

There are many modern cars where (for example) the "service in XXX miles" indicator for oil changes can't be reset except by the access-restricted and very expensive factory service tool.

Many independent shops already have to buy reverse-engineered tools to allow them to service these cars and continue to stay in business. It's clear that automakers are very interested in abusing copyright laws to force a monopoly on after-sales service.

<comment><USER5> > very expensive factory service tool.

You can buy an ODB2 reader for ~$20 on amazon. If you are working on any car newer than 1990, an ODB2 reader is a standard tool in your drawer.

The real problem is, to change the headlights on my car, you have to remove the front wheels and part of the wheel well. If anything these shenanigans help independent shops. If they built cars to last and be maintainable, there would be a lot fewer independent shops.

<comment><USER4> An OBD2 reader doesn't work for proprietary diagnosis, only regulated/standardized emissions related issues.

The example I supplied (Service Now mileage indicator, not Check Engine Light) was a very specific one with Porsche in mind. Most post-2004 Porsches have no procedure to reset that indicator without using an official PIWIS ($13000 + subscription, if you can even get one) or reversed Durametric ($250 + illegal if automakers claim their software can't be reversed).

Another example of anti-competitive dealer software is "coding." Replacing the headlight control module in a BMW, for example, requires it be "coded" to the car's control systems. Many DIYers and independent shops use straight-up pirated BMW diagnostic tools, because again, the "blessed" way to do so costs thousands of dollars.

<comment><USER6> I'm gonna just be cynical and say that BMW just _wants_ it to be expensive to maintain a BMW. How else is it going to remain a Veblen good?

</comment></comment></comment></comment></comment></comment><comment><USER7> The core automaker message I got out of this is:

Automakers want to lock out consumers and unapproved mechanics from tinkering with vehicle software on the grounds that (1) they could purposefully or accidentally make the vehicle non-compliant with safety/emission standards, and (2) they could use the vehicle's computers to infringe copyright (presumably ripping streaming audio?), and (3) closed source = more difficult for malicious hacking of vehicles.

There are already laws in place to deter all of the outcomes of these actions. To deter the action that _might_ lead to unlawful action... sigh.

<comment><USER8> I bet it's primarily the fear of being sued.

If your cousin's friend changes the code for the ABS to "work better on gravel roads" and then you wreck, who's going to get sued? Not your cousin's friend - he's living in a van down by the river. The automaker is, because they're the ones with the money.

<comment><USER9> But how is this different than if I put in aftermarket braking pads and then I wreck? What if my cousin's friend installed them wrong?

Is the litigation risk any different with software rather than hardware?

<comment><USER10> it is much easier to look at an after market part and determine if it was cause of the failure because it is a physical object. Software and the state and sequence of events are much harder to look at and conclusively say "yes, this was the culprit".

It's hard for me to pick a side here. I want that freedom, but the auto makers have a compelling reason for wanting to stop it (getting sued, warranty issues, etc). I'm 60/40 on the automaker's side.

<comment><USER11> A variety of systems which _can_ be flashed with modified or entirely third- party firmware but usually shouldn't be have tamper flags that make detecting the modification easy, even if the system is restored to its factory configuration afterward. This could be a good solution for car makers, especially if laws were updated to limit their liability in such cases.

To be specific: car makers should not be liable for unsafe modifications made by third parties, even if they intentionally made the car easy to modify and did foresee that some people would make unsafe modifications. To subject the car maker to liability in the case of a modified car, the plaintiff should have to show by a preponderance of evidence that the modification did not cause the crash.

<comment><USER12> > the plaintiff should have to show by a preponderance of evidence that the > modification did not cause the crash.

I can see this going the opposite way too. E.g. the automaker says that they are not liable because the customer modified the audio system, even though it was the ABS that failed.

<comment><USER11> Sure, but they'd have a very uphill battle convincing a jury of that. This isn't "breaking seal voids warranty". This is "you, and you alone are responsible for the results of modifications you make".

</comment></comment></comment></comment></comment></comment></comment><comment><USER13> "Own" is such an overloaded term. What do you own when you own anything? It's almost always complicated! If you own a music album on compact disc then people say they own that album. But you aren't allowed to make copies of that disc. And you absolutely can't makes copies and then sell the copies. You can't even use that disc whenever and whereever you want. For example you can't play that disc through stadium speakers at a sporting event. Nor can you use host a concert and play parts of that album. You can't do it to mix with other music and you can't even play it directly.

So again I say, own is such an overloaded term. I wish people used it far less than they do.

<comment><USER14> "Own" is just clickbait here. They don't quote any automaker who says you don't own your car. They do quote automakers referring to "owners" as the people who paid for and drive the cars. There are other items I can own but cannot modify in certain ways, such as firearms.

<comment><USER15> Worth noting that it's illegal to modify a firearm in certain ways, but other ways are totally legal. Which relates back to the distinction between laws that prevent modification vs. laws that enforce safety standards. It's not OK to modify a semi-automatic rifle to be fully-automatic, the same way it's not OK to exploit security holes in your car computer's firmware. However, it's not OK to swap out your car computer's firmware entirely, but it is OK to swap out the barrel, upper, lower, or whatever on your weapon, provided it's certified for sale.

<comment><USER16> Great analogy.

</comment></comment></comment></comment><comment><USER17> You know, I'd be okay with that if I no longer had to pay property tax, insurance, maintenance, fuel and other costs on the vehicles I no longer owned and instead that burden fell to the automakers.

</comment><comment><USER18> Who is going to start publishing open source car firmware? I imagine that putting something together that would run some of the newer cars would actually be quite difficult. I'm guessing that writing enough software to just get a Tesla to turn on safely and pull out of the garage will be quite an undertaking.

I can see a huge benefit from having FOSS versions of car firmware in the future. It could be especially important if you don't agree with your manufacturers choice of ethics for automatic driving (See the AI Tunnel Problem).

[http://robohub.org/an-ethical-dilemma-when-robot-cars- must-k...](http://robohub.org/an-ethical-dilemma-when-robot-cars-must-kill- who-should-pick-the-victim/)

<comment><USER19> Probably never. The amount of software that your car runs will easily stretch into the millions of lines of code, it's incredibly complicated and the combined efforts of thousands of programmers.

Then, insurers wouldn't insure you on some software, which would mean that you'd be illegal to drive your car in many countries.

</comment></comment><comment><USER20> Hahaha, remember when we always made car analogies about how we could use or modify software?

[https://www.fsf.org/blogs/community/the-car- analogy](https://www.fsf.org/blogs/community/the-car-analogy)

They're no longer analogies! They're the literal truth! This is very sadly funny. :-( :-/ :-)

</comment><comment><USER14> When we have self-driving cars will we still expect to hack on the software? I really feel my pedestrian avoidance is too sensitive, let's tighten that up a little. And I want to win all four-way stops!

<comment><USER21> I think that you should be allowed to hack your self driving car. But you should have to submit the compiled code to the NHTSA and your insurance agent so that they can run it through a bunch of black box simulations to determine if it's street legal and how much to charge you per mile.

<comment><USER22> This sounds possible in theory, but difficult in practice.

Designing a test suite that catches all possible life-critical errors is near impossible. The cost of testing and certification will probably be quite high, well outside the reach of amateurs.

Just as we advise people not to write their own crypto (its easy to get wrong), I think the same will hold for safety critical software.

All that being said, I think it is very important that this software is open source.

<comment><USER23> I'd love for it to be open source (and I do believe that would be the safest for all), but you know as well as I do that's not the world we live in. The safety code is going to become a feature/price differentiator/trade secret that car companies live and die by.

</comment></comment></comment></comment><comment><USER24> Like you don't really own your iPhone? Yes, exactly like that.

<comment><USER25> Yep, we need legal rooting too.

<comment><USER26> It's legal to root your iPhone/etc.

However, the manufacturer is in no way obligated to make that easy or even possible.

<comment><USER27> Depends on how broadly you interpret "etc." For example, iPads are not legal to jailbreak. Also, while jailbreaking an iPhone is legal, performing a carrier unlock without the carrier's permission is illegal. (This is all for the US. Other jurisdictions may and certainly do vary.)

<comment><USER28> Do you actually own a carrier-locked phone though? It's not like a car that is owned by the bank for a few years until you pay it off, and then you get the title and keep driving it.

A phone you buy on a 2 year contract is yours at the end of the contract. Then you get a new phone and give the old one to whoever in your family needs a new one, or just put it on ebay for fifty bux and change.

</comment></comment></comment></comment></comment><comment><USER29> "They warn that owners with the freedom to inspect and modify code will be capable of violating a wide range of laws and harming themselves and others."

This argument is a bit silly, given how many laws can be broken and how much harm can be done by anyone behind the wheel of an automobile, regardless of how it has been modified.

<comment><USER30> Fear mongering is what it is. If average people who don't know how to read code can be frightened into submission, they can do whatever they want.

</comment></comment><comment><USER31> IMO, we should separate two things:

* Ability to modify firmware of your own car.

* Ability to inspect and review code in the car.

The first one is dangerous, imagine someone who wanted to improve ABS but didn't do testings, and this led to a crash. Or, if we consider, more intelligent self driving cars, possibilities for abuse, etc, are enormous.

The second one is discussable. On one hand, we want to make cars as safe as possible, and there's no better way for this, than inspecting code. On the other hand, the company wants to protect their intellectual properties from competitors.

</comment><comment><USER32> "Right to Repair" laws have been in the works (and opposed by the auto industry) for at least 15 years and recently passed by Massachusetts. One goal is to level the playing field between dealers and independent shops by forcing manufacturers to give up technical info, part of that being the interface with computer systems. I'm not sure if the law mentions software modification at all, but it sounds like a court battle waiting to happen.

[http://en.wikipedia.org/wiki/Motor_Vehicle_Owners%27_Right_t...](http://en.wikipedia.org/wiki/Motor_Vehicle_Owners%27_Right_to_Repair_Act)

</comment><comment><USER33> We don't have cars anymore; we have computers we ride in. […] So when I get into a car—a computer that I put my body into—with my hearing aid—a computer I put inside my body—I want to know that these technologies are not designed to keep secrets from me, or to prevent me from terminating processes on them that work against my interests.

Cory Doctorow, [http://boingboing.net/2012/01/10/lockdown.html](http://boingboing.net/2012/01/10/lockdown.html)

</comment><comment><USER34> Well, if they're interested in selling more cars, I'm in the market for a car that I can diagnose, repair and customize via a usb connection to my laptop.

There's an aversion to transparency in a lot of software stuff because you can't prevent people from stealing your hard-earned work, but in giving your customers more accessibility you'll have an immediate edge in the car market, which, after all, is how you make money.

</comment><comment><USER35> I generally agree with the EFF, I'd even say I'm a fan, but I disagree on this one.

TL;DR == "tough"

Regulations can be bad, they can stifle innovation, enforce inequality, maintain awful power structures, etc. But, they can also save lives. In America there are a million things you can't do because they infringe on the safety of others.

At an abstract level, an automobile is 3,000 lbs. of metal holding 10 gallons of gasoline that carries human beings through public spaces at up to ~70mph. It travels through neighborhoods where children live and play at up to 25mph. It's a mixture of chemical, mechanical, computing and electrical systems that an engineer needs about 10 years of study to be able to handle _after_ they get to engineering school. Even then they'll specialize.

Car enthusiasts simply don't have the skills to merit carte blanche access to mess around with cars that drive on public roads. In general, they probably don't even have the skills necessary to evaluate their skills which is what makes this so dangerous.

Tinkering with a mechanical system like your brakes is very different from tinkering with a computing system that through an electrical system is controlling the mechanical system that is your brakes. That's orders of magnitude of new complexity. Do you really think the average car-guy will understand the bugfix, written in optimized C or assembly, that accounts for how a certain transistor behaves above 200 degrees Fahrenheit?

To be clear, these laws aren't to protect anybody from their own stupidity, they protect the rest of us. If you _do_ have the skills to tinker at this level then you're free to use them in race cars that aren't street-legal.

<comment><USER36> The EFF isn't against regulations on cars. They're against companies using the DMCA to restrict access. There are no regulations - that's precisely the point of the article.

<comment><USER35> Can we just be honest about this? The EFF hates the DMCA and I think it's clouding their judgement. They need to separate their very good fight against the abuses of copyright law from this ridiculous fight to let people do stupid and dangerous things to their cars.

If they have a better tool than the DMCA to keep the average person from defeating safety features built in to their car, they should say it. But any system strong enough to ensure there's no dangerous code running in any cars on the road will be opposed by the EFF because it would be a whole new level of surveillance.

<comment><USER36> ... Did we read the same article? The EFF is arguing exactly that. They say that if the transportation authorities deem it necessary to regulate then fine. But they haven't. Abusing the DMCA instead is just stupid and wrong.

<comment><USER35> We did read the same article, but I don't think it was very consistent throughout. Their opening statement is this:

> EFF is fighting for vehicle owners' rights to inspect the code that runs > their vehicles and to repair and modify their vehicles, or have a mechanic > of their choice do the work.

So I see "inspect" as read access, "repair and modify" as write access and I think _what would we do if we had read-write access to our cars?_ Relly think about that one for a second.

I disagree with the "regulation will be enough" idea in the same way I understand the law regulates people from entering my house but I still lock my door.

Later in the article they go into why the DMCA is the wrong tool for the job and they're probably right, this shouldn't be done in the name of ending music piracy.

</comment></comment></comment></comment></comment><comment><USER37> Before you go down the path of "Would you want people altering the way their autonomous vehicle works?" consider that it's already too late. There is open source software for a variety of autonomous self-propelled robots, land vehicles, and aircraft.

Why hasn't a problem manifested already, when I can build a drone, download software for it, and tweak it all I want? It's because very few people do that. And vanishingly few do it will ill intent.

I'm sure that 15 years form now there will be a true crime show about someone who programmed their car to run over their spouse. (It's always the spouse.) But that shouldn't be an excuse to stifle the thousands of beneficial results from hacking automotive systems that will come about from people satisfying their curiosity about what's on the CAN bus.

</comment><comment><USER38> As much as I am pro-FOSS, don't vehicle manufacturers have a right to copyright protection too? Why should vehicle computers be somehow different from other computers, which we allow to run proprietary code?

I guess my point is that, even being a FOSS advocate and pro-DIY, I don't see why car makers should be compelled to hand over their code, unless of course they're already using GPLed or similar OSS code.

Troubleshooting diagrams would be reasonable to ask for, or perhaps some documentation of the protocols used. But demanding that a company release their source code because you essentially feel entitled to it is pushing the buck if you ask me.

</comment><comment><USER39> I recall that it's common to make one kind of processor, and deliberately cripple them to varying degrees to ensure you can sell to every price point without having to go through the extra expense of making a range of processors.

The analogy with car engines, I presume, is to make one kind of car engine, and to use the electronic control system to present a range of performances to the consumer market, without having to go to the expense of actually making different engines. Does this already happen, or is it yet to come?

<comment><USER11> It's not common yet. Usually, the higher-performance version has hardware differences involving either more expensive materials, a more expensive manufacturing process or greater mechanical complexity. I did notice a possible example though: the Volkswagen Crafter, a full-size van popular in Europe has 5-cylinder turbocharged diesel engines in several different power ratings. I'm fairly confident they're mechanically identical and just have different maximum boost settings for the turbocharger, though they _may_ have different sizes of turbocharger.

</comment></comment><comment><USER40> Is not that I don't like smart cars, the problem is that they allow a transfer of control from who's supposed to be the owner to institutions and hackers: [https://www.youtube.com/watch?v=3jstaBeXgAs](https://www.youtube.com/watch?v=3jstaBeXgAs)

Lets say that by a surreal act of good software engineering, you get rid of the hackers problem, what are the odds of getting rid of corruptible institutions?

</comment><comment><USER41> This applies as well to mobility devices like powerchairs and scooters and other things like motorized beds that change your position. Without the service manuals, it can be very hard to fix these.

</comment><comment><USER42> So do I get to bill them for parking fees on my property?

</comment><comment><USER43> Do cars actually run much software? I would think that most of the computing was done via firmware.

<comment><USER44> Firmware generally is software isn't it?

<comment><USER43> I think the downvoters are missing my point. By definition, firmware is read- only software, so I was asking sure what (potentially modifiable) software the EFF is referring to.

<comment><USER44> Is it?

I'm not saying it's not, I haven't even looked up a definition, but I do know I've written firmware update code before... I think the way the term gets used is probably a little blurry...

My car, for instance, is a bit old. It has some sort of ARM device in it running a proprietary GPS system. There is an update mechanism that can be triggered when you put a new DVD full of map data into the drive in the trunk. This updates the stuff that runs the ICE as well as the GPS. I would be very concerned if it had anything to do with engine-control I suppose.

<comment><USER43> Maybe I'm being myopic as far as the definition of firmware. I've never heard of a firmware update for a car, but if it's not happening already, it'll probably be part of the regularly scheduled maintenance in the future.

<comment><USER45> The term "firmware" originally referred to code that ran from nonvolatile memory, such as EPROMs. Originally these devices weren't electrically reprogrammable; you had to pull them off of the board, erase them with UV light, and burn your new code and data onto the chip with specialized equipment. Firmware was also commonly shipped on mask-programmed ROM chips that were cheaper than EPROMs but that couldn't be reprogrammed at all.

Essentially nothing like that is used anymore. Almost every programmable part is reprogrammable in-system unless someone takes extraordinary measures to prevent it from happening. That means that there is no longer any real distinction between "firmware" and "software," and there is no such thing as "read-only software," as you put it earlier. There is only "software" and "locked software."

This thread is all about who should own the keys to the lock.

</comment></comment></comment></comment></comment></comment><comment><USER46> And its titles and articles like this which prevent me from send a _dime_ to the EFF.

Automakers aren't trying to take ownership of my car away from me. This is linkbait... no, it's donationbait, and as long as the EFF keeps this up, they get nothing from me, and they should get nothing from you, either.

<comment><USER47> This is a little overly black and white in my opinion. Yes, the EFF is not flawless in their articles and writing. They have written questionable things before and I don't always agree with what they say. Regardless, they are a huge force for the rights of every day Americans and I think our rights would be tremendously eroded without them. This is why I donate.

<comment><USER46> The ACLU is a better/bigger force, I would argue.

The EFF actively misrepresents and _lies_ about issues to convince folks to give them money. It's just too blatant, and they represent themselves as technically savvy, so even if it's unintentional, I can't forgive them for those kinds of errors.

</comment></comment></comment><comment><USER48> I strongly disagree with the eff. Safety trumps all and there simply isn't a compelling need (that I can think of) that requires the need to tinker with the auto software. All of the "arguably restricts vehicle inspection, repair, and modification" is just a red herring.

"The reach of copyright law has expanded so far that it now threatens people's ability to repair their own cars and protect them against malware. Yesterday, EFF launched a legal campaign to fend off that threat."

Can't even think that I have read any stories (so far) about malware having an impact on auto operation. Hard to believe that opening up the software won't result in something bad happening either.

<comment><USER49> In the short term, they could easily use this to lock people out of being able to perform certain routine maintenance operations on their vehicles, forcing them to go to authorized dealers and paying exorbitant markups.

In the long term, tires, filters, and brake pads could become proprietary in the same way as Keurig's K-Cups are now, though I imagine with more complex DRM.

<comment><USER50> This already happens with other machines (washing ones). Only the dealers get access to a proprietary DRM software that updates a 4KB firmware. I bet that not for too long.

[http://www.scc-service.com](http://www.scc-service.com)</comment></comment></comment>


HN should have a "bookmark" option along with the "favorite" option - <AUTHOR> I don't always have time to read an entry but would like to get back to it later that day. <comment><USER2> Anything you upvote is saved to a private reading list. You can find the link in your profile.

<comment><AUTHOR> Yes but I want my upvote to mean something therefore I to read the article before hand.

<comment><USER2> It means it's interesting enough to dedicate later reading time. That's high praise!</comment></comment></comment>


The Simple Shapes of Startups - <AUTHOR> http://www.ashmaurya.com/2011/09/the-simple-shapes-of-startups/ <comment><USER2> I think this is the startup of a powerful representation for a startup. I think the cash should be able to go negative to represent draw downs from savings or outside investment. This reminded me of Richard Caro's "Cashflow Fingerprint" for startups see [http://blip.tv/science-to-profits/startup- cashflow-fingerpri...](http://blip.tv/science-to-profits/startup-cashflow- fingerprint-1344528) and work by Sal Virani and Mark Twum-Ampofo on a "Visual Language for Finance" [http://www.saintsal.com/2012/01/a-visual-language-for- financ...](http://www.saintsal.com/2012/01/a-visual-language-for-finance/) If you could represent the decision tree in advance (or at least develop an initial model) a tornado diagram (for example [http://smartorg.com/2011/10/tornado-diagram-resolving- confli...](http://smartorg.com/2011/10/tornado-diagram-resolving-conflict-and- confusion-with-objectivity-and-evidence/) ) would complement this visualization.</comment>


Here's Jarvis [video] - <AUTHOR> https://www.facebook.com/zuck/videos/vb.4/10103351034741311/?type=2&theater <comment><USER2> would have appreciated a real demo...

Per usual, the media will go crazy with this marketing/promoesque video, and ignore the actual state of the tech.

</comment><comment><USER3> This is a joke video right? I was sure it was while watching it, but the other comments here seem to imply this is a real thing.

<comment><USER4> He wrote about it yesterday and someone in the comments asked him for the video. Mark replied that he would upload the video.

</comment></comment><comment><USER5> I want an assistant than can do things I can't do. I'm perfectly capable of switching on the lights or making my own toasts or letting my parents in. What I really want is an assistant that can do my taxes or find a damn good leather repair shop to come and pick up my couch that needs repairing. (Not so easy when you're not fluent in the native language!)

</comment><comment><USER6> Vacuum the living room... Open the garage door... Mow the lawn... Switch TV to HBO... Compose an email with Jarvis...

There are a lot of things I'd like to have my personal assistant do, along with the proper connection to some real equipment. I hope this finally gets past being a gimmick. Maybe Zuckerberg will help to spawn the market.

</comment><comment><USER7> Here's the "real" demo [https://www.fastcompany.com/3066478/mind-and- machine/mark-zu...](https://www.fastcompany.com/3066478/mind-and-machine/mark- zuckerberg-jarvis)

</comment><comment><USER8> see also long text post yesterday: [https://www.facebook.com/notes/mark- zuckerberg/building-jarv...](https://www.facebook.com/notes/mark- zuckerberg/building-jarvis/10154361492931634), discussion here: [https://news.ycombinator.com/item?id=13212976](https://news.ycombinator.com/item?id=13212976)

</comment><comment><USER9> In a previous thread, I mentioned that Paul Bettany would be the best voice for this sort of system. That said, Morgan Freeman is a fine alternative.

</comment><comment><USER10> > In case it's not clear, this is meant to be a fun summary and not a live > demo. - Mark Zuckerberg

</comment><comment><USER11> Regardless of it being true or not, it still feels kind of a gimmick to have a "bot" like that.

</comment><comment><USER12> I've checked my calendar a couple times and nope, it's not April. This is also not on funnyordie.com so severely confused. The only possible real applications in this video are already done well by siri/google/alexa .. so he's either entering a well established market late or just talking about a pet project?

<comment><USER8> pet project, see [https://www.facebook.com/notes/mark-zuckerberg/building- jarv...](https://www.facebook.com/notes/mark-zuckerberg/building- jarvis/10154361492931634) ([https://news.ycombinator.com/item?id=13212976](https://news.ycombinator.com/item?id=13212976))

<comment><USER12> in that case very cool! Just wasn't sure if this was a quasi ad for some new service since the video was produced rather professionally

</comment></comment></comment><comment><USER13> Shame - I have no facebook account and can not view. Any other sources ?

<comment><USER14> Just get it with youtube-dl :)

<comment><USER13> thanks - worked.

</comment></comment></comment><comment><USER15> That was actually pretty funny and cute.

<comment><USER16> I found it silly and at times pretty creepy.

Citing His Dudeness, "Yeah, well, that's just, like, your opinion, man."</comment></comment>


The Extended Mind (1998) - <AUTHOR> http://consc.net/papers/extended.html <comment><USER2> For people who don't know, this is the most cited journal article in philosophy written after 1990.

</comment><comment><USER3> Interesting read. Reminds me of "The cognitive life of things"</comment>


Show HN: An algo based approach to beating the market - <AUTHOR> https://discord.gg/ry8VfcS <comment><AUTHOR> Many people don't believe you can time the market, or beat index fund investing. Statistically hedge fund managers struggle to beat index returns with all their custom tools as well and their large informational data-sets. Our algo based approach can grow portfolios using options trading and outperform the market.

This week, we have opened our Discord channels as all of our posting has been automated so now people can see the plans we get into, the time we get in and out.

We are currently in MTCH/DIS/LULU/HD and will look to get into AAPL tomorrow, if the plan requirements are met.

[http://plans.marketgodfathers.com/stockimages/9002466145cbd2...](http://plans.marketgodfathers.com/stockimages/9002466145cbd2c7e7e3851.20313503.jpg)

Our algo selects the best plans we can get into on a given day, then we curate those manually and generate trades to take. We put the same amount into each plan except the weekly trades have less invested into them.

I posted in the past about starting a service for my project and then another post to sign up and test-drive via a free trial, however, at that time it wasn't as detailed so it was hard to see what we were doing. With the channel open for the week, maybe longer, we hope people can see our results from July 03, 2018 until today.</comment>


Show HN: Widgetic for WordPress – Design and publish custom widgets in WordPress - <AUTHOR> https://wordpress.org/plugins/widgetic/screenshots/ <comment><AUTHOR> We decided to reveal the new Widgetic interface and branding in our first WordPress plugin. We look forward to any feedback, good or bad, that would help us improve the product.

</comment><comment><USER2> Does it work with any kind of theme?

<comment><AUTHOR> Indeed, it does. The widgets are completely responsive as you can see here: [https://www.facebook.com/widgetic/videos/vb.311160592370762/...](https://www.facebook.com/widgetic/videos/vb.311160592370762/539876952832457/?type=2&theater)

For those that prefer to embed a specific one in unspecific ways, we provide an API for that [http://docs.widgetic.com/#building-a-custom- editor](http://docs.widgetic.com/#building-a-custom-editor). But it's only for developers.

</comment></comment><comment><USER3> Very nice</comment>


Show HN: Soundslice v2 – Sheet music + guitar tab + real audio - <AUTHOR> http://www.soundslice.com/v2/auld-lang-syne/

<comment><AUTHOR> We've built a sheet-music rendering engine in JavaScript/HTML5. It syncs real audio with sheet music and is intended to be the best way to learn a song.

Here's a quick video demo I made: [http://www.youtube.com/watch?v=tq1go7Ld1Q4](http://www.youtube.com/watch?v=tq1go7Ld1Q4)

<comment><USER2> Very nice program.

Would be great to incorporate learning tracks like treehouse -

let the user decide what songs they want to learn - and keep track of how they are doing on their goals

</comment></comment><comment><USER3> I would like to point out that this is more awesome than it even looks. Try selecting a portion of the song, in the usual way with your cursor.

</comment><comment><USER4> Notezilla ([http://www.notezilla.io/library](http://www.notezilla.io/library)) is similar. It, too, plays real audio synced with visible and interactive sheet music, but it is for classical and pop music instead of guitar music. It doesn't support guitar tabs, and it has a smaller library, but everything in its library is free.

</comment><comment><USER5> This is incredible, it's amazing to see this all running in the browser.

One nag, I didn't actually know I could scrub on the tabs until I clicked - have you thought about adding a grey-like highlight on hover? Either with the same bar or highlighting the notes under the mouse?

</comment><comment><USER6> Incredible work guys. I signed up quite a while back and you have come a super long way! The site is looking great and the live sheet music is spectacular.

</comment><comment><USER7> This is awesome.

As someone trying to learn to play guitar, being able to loop and 4 measures at a time to play along with is incredibly useful.

</comment><comment><USER8> If you look closely while it loads: "Reticulating splines..." — best rendering messaging ever

</comment><comment><USER9> This is awesome. Great job on this. Love seeing music and computing intersect!

</comment><comment><USER10> This is one of the best products I've seen in a while. Mad props.

</comment><comment><USER11> This works shockingly well on iOS.</comment>


How GPS Can Prevent Tanker Truck Spills, Explosions - <AUTHOR> http://advice.cio.com/al_sacco/gps_to_help_keep_tanker_trucks_from_going_head_over_wheels A new GPS-based service will allows trucking companies to alert driver when they're speeding or the trucks are swaying too much. <comment><USER2> Here's a chance to share the best corporate euphemism I've ever heard:

Explosions = "unscheduled releases of energy"</comment>


Vim power panel with Drew Neil, Tim Pope, and Yehuda Katz - <AUTHOR> http://thechangelog.com/post/4557774334/episode-0-5-6-vim-with-drew-neil-tim-pope-and-yehuda-kat <comment><USER2> Regarding the "Plugins howto tutorial" that was requested on the show, I'd like to ask you guys to check out the Plugins chapter of my book and let me know your feedback - <http://www.swaroopch.com/notes/Vim_en:Plugins></comment>


ASAP: Automatic Smoothing for Attention Prioritization in Time Series - <AUTHOR> http://futuredata.stanford.edu/asap/ <comment><USER2> The examples they give are periodic so removing the periodicity is the big win, not removing the noise.

How did ASAP perform better than ARIMA and other similar algos should be the main question, not how does ASAP compare to nothing.

<comment><USER3> Isn't Arima used for forecasting? Pardon me I'm not very informed about it but how is Arima used for smoothing?

<comment><USER2> Various ARIMA methods are used to deseason data for forecasting, but yes a better more directly comparable example might have been methods like STAMP and STL.

</comment></comment></comment><comment><AUTHOR> Blog post with additional info on why this is useful:

[http://dawn.cs.stanford.edu/2017/08/07/asap/](http://dawn.cs.stanford.edu/2017/08/07/asap/)

</comment><comment><USER4> In short - is this a moving average with window range automatically tuned for optimum detail to smoothness ratio?

<comment><USER5> A moving window average is a poor digital filter in the frequency domain [0]. You can get better results with more control on which frequencies are removed by implementing a FIR or IIR (especially Butterworth) digital filter.

[0] [https://ptolemy.eecs.berkeley.edu/eecs20/week12/freqResponse...](https://ptolemy.eecs.berkeley.edu/eecs20/week12/freqResponseRA.html)

</comment></comment><comment><USER3> Is there a python implementation of it as well?

<comment><AUTHOR> [https://github.com/stanford- futuredata/ASAP/blob/master/ASAP...](https://github.com/stanford- futuredata/ASAP/blob/master/ASAP.py)

<comment><USER3> Just tried it. I was using the seasonal_decompose from statsmodel in python for a project. I have to say ASAP looks great!

<comment><AUTHOR> It really is a gem for analysis of time series data. I was lucky enough to watch Kexin's talk live @ Monitorama on ASAP. Really great stuff.

<comment><USER2> Does he explain how this is better than any other methods?

<comment><AUTHOR> I don't believe she did. She investigated the specific problem of helping users to identify deviations in time series by applying smoothing.

Here is a link to her presentation: [https://vimeo.com/221062931](https://vimeo.com/221062931)

It is pretty fascinating, I do recommend giving it a watch.

<comment><USER6> I upvoted the authors comment linking the Arxiv paper, that said, I think the presentation oversold the claim that smoothing is always a good thing to do. In particular, showing that excel, grafana, graphite etc, do not smooth by default, (apparently because it is a hard) looked like a low point of the talk, sorry. Smoothing has its uses but its hardly the panacea.

What is an appropriate smoothing is very context sensitive and I would like the consumer of the plots be in charge of that. Sometimes smoothing away the high frequencies or transients are exactly the wrong thing to do (for example, when you care about transient spikes)

I have seen more than enough damage done by plotting tools sneaking in a smoothing without informing the consumer. Especially so in the monitoring space. When the user expects raw plots it better be raw, and raw is a good default. Smoothening should be invoked explicitly.

<comment><USER7> Thanks for the comment. I strongly agree that smoothing is not always beneficial and that the users should be informed and have control of the amount of the smoothing that is being applied to their plots.

We developed ASAP with the intend to complement, instead of replacing the raw plots. We view ASAP more as a "smart default" \- if you were to expose a slide bar of different moving average window sizes that users could apply to their visualizations, where should a reasonable default be on that slide bar?

In addition, ASAP does not always choose to smooth the visualizations. In some cases (e.g. Figure C.1 in the arXiv paper) where the raw plots already have a few well-defined outlying regions and smoothing would only decrease the extent of such deviations, ASAP leaves the visualization unsmoothed.

<comment><USER6> That sounds very sensible.</comment></comment></comment></comment></comment></comment></comment></comment></comment>


UI Animation: Microinteraction for Macroresult - <AUTHOR> https://medium.com/@tubikstudio/ui-animation-microinteraction-for-macroresult-668cd9e71101 <comment><USER2> I think most of these are fun, and relatively harmless. And I think showing a spatial connection between states by having elements move is very useful.

However, the ones that involve new UI elements moving into place are all slightly too slow: almost all of them would get annoying to use once you were familiar with the app: you'd end up feeling like you had to wait before you could tap. Add an increasingly-behind-spec phone (don't they always seem to be?) and the delays would get truly aggravating.

</comment><comment><USER3> No. Please, no. No, no, no, no, no.

I want FAST user interfaces. I don't want more animations that chew up hundreds of milliseconds and give me that horrible feeling of swimming in syrup.

I know designers think this is brilliant and pretty and all, but as someone who makes heavy use of tablets, phones, laptops etc. doesn't want more crap. My iPhone feels slow and sluggish enough as it is.

If you want to spend your talent on something: figure out how to increase speed, precision and figure out how software gets better at understanding what the user wants.

<comment><USER4> maybe users want animated UIs

</comment></comment><comment><USER5> Can we ignore the article itself for a moment, and talk about the problem of website obesity? Those gifs clock in at over 100mb in total[0], and they have absolutely no reason to be.

[0] [http://i.imgur.com/SsurT3W.png](http://i.imgur.com/SsurT3W.png)

</comment><comment><USER6> The argument that this makes the user experience better is debatable. The argument that it's going to chew through my mobile data bandwidth, battery, and load times isn't.</comment>


Tell HN: Arch Linux logo copied, issue resolved - <AUTHOR>

This is a follow-up to http://news.ycombinator.com/item?id=648603.
From an update to their newsletter:
After this very article and the publicity it gained, the Arch Linux developer team received an unexpected e-mail from the operator of the company using our old logo. He has made a formal apology and has removed the logo from his website. The Arch Linux developer team considers the issue thereby resolved.
Apparently he received several threatening e-mails from members of our community. Honestly it was not our intention to motivate such actions. We know people tend to get out of hand sometimes when it comes to defending what they love, but for the future, please, that kind of behavior is not encouraged by any of us. Thanks for your support once more Arch Linux community. <comment><USER2> i write this at the risk of being downmodded (and i don't have enough karma!)

Why is this such a big issue? The only tangent I can draw to this is the story about the cop tazing the grandma("you didn't need to" , "oh i was following procedures")

It's not like another distribution stole this logo and used it to get traction based on Arch Linux? It's a small business owner who used it as a 'casual' download-and-use-it manner..and He used the logo for his Ace Driving school - which was clearly displayed on the car. It was not the case that He was a pirated software distributor taking advantage of the Arch Linux logo. He was a layman - oblivious to online copyrights. He saw it on the web,liked it and used it. simple from his point of view. I am sure he knew about copyrights and other issues - but related to 'paper' business.

There are bigger stories of people deliberately stealing photos/digital art. There was this one story about this big designer who downloaded a creative- design from an artist's flickr account for a new designer shirt. This artist only came to know of it when he visited this showroom to buy one. Then there are always stories of magazines/newspapers flicking photos from flickr without proper attribution. (i don't recall the links, nor am i going to spend time searching for them - atleast now)

I am not contending the fact that he didn't steal the logo or he didn't lie. He did both.

I also think, acts like 'threatening' is not what the hacker/foss community should resort to. It only alienates community from the layman.

<comment><AUTHOR> _i write this at the risk of being downmodded (and i don't have enough karma!)_

I actually think one of the drawbacks of the voting system used here is that it discourages the posting of controversial or unpopular opinions. (See <http://news.ycombinator.com/item?id=613071>)

</comment></comment><comment><USER3> > Apparently he received several threatening e-mails from members of our > community. Honestly it was not our intention to motivate such actions.

Seriously, what did they expect? It's pretty well known that if you bring an issue like that to the public eye there are always going to be idiots who take it further than is really necessary.</comment>


Ohaipuzzle - a somewhat tough puzzle. - <AUTHOR> http://www.ohaipuzzle.com/

<comment><USER2> That was a lot of fun. The second step is a lot more work than the first one.

</comment><comment><USER3> Solved.</comment>


Is 30 Too Old To Be An Entrepreneur? - <AUTHOR> http://www.instigatorblog.com/is-30-too-old-to-be-an-entrepreneur/2007/05/22/ <comment><USER2> This discussion has played itself out. If you're thinking of starting a business, do it. If you're over thirty, you certainly can't turn back the clock, and if you're in your twenties, there is plenty of evidence that it's doable. So go out and get started.

</comment><comment><USER3> Typical cause-and-effect confusion:

Wrong: If you start early you'll be successful.

Right: If you have what it takes to be successful you start early.

That is to say that people who are born with intelligence, entrepreneurial skills, and passion for business generally feel the urge to build businesses from their teen years and act on it the first chance they get.

If you have had that urge from an early age then you've probably already tried a few times. Not all startups succeed, so keep trying. Your age doesn't matter.

If not, then you're probably just excited because of all the recent hype and dreams of becoming rich. If that's the case, and you don't feel the passion then do yourself a favor and keep your day job.

</comment><comment><USER4> The idea that only twenty somethings have what it takes to be entrepreneurial is downright ridiculous. Yet it is an idea that keeps on popping up (recent nytimes article for example). The reason may simply be that there are more people in that age group starting companies. A larger starting pool results in a larger pool of success. But as is the case with any statistic it seems, people mistake it for truth. So in conclusion, no, 30+ is not too old to start a company. But if you want to use it as an excuse to sit on the sidelines, by all means, do so.

</comment><comment><USER5> This question keeps coming up, but nobody's provided a definitive answer. Could someone just tell me if I'm too old to be an entrepreneur? Then I can move forward with making sure my ethnicity, political leanings, religious beliefs, and hair length are right. As soon as everything checks out I want to start implementing my idea.

<comment><USER6> heh ! :)

</comment></comment><comment><USER7> Agreed, this topic is getting old. (Edit: no pun intended, seriously, I just noticed this!)

Still, I have a theory about all this...

The stats compiled by Valleywag are impressive, they show that almost all of the top 0.1% most gigantically successful companies were started by people in their 20s (Microsoft, Google, etc).

What they do not address is the age of people who start the other 99.9% of companies. I would agree that companies started by young people are more likely to be outlandishly successful (for a variety of reasons: creativity, time, etc) but I don't think that they are any more likely to start a very successful company. In fact, I would suggest that age makes it more likely that a company will be a success, though perhaps not a paradigm-busting breakout.

</comment><comment><USER8> Yes. If you are 30 or over you should give up now.</comment>


Let's Stop Saying B2B - <AUTHOR> http://www.chrisyin.com/2014/07/09/stop-saying-b2b

<comment><USER2> That's a great article, but I'd like to add that SMB / Enterprise isn't a strictly binary demaracation with clearly defined boundaries. It's more of an analog continuum where lumping a given company into one bucket or the other is somewhat probabilistic.

Eg, a 500 person company and a 32,000 person company are both over the stated threshold of250 employees for "SMB", but the 500 person company and the 32,000 person company may behave quite differently.

I think this article covers some related ground and may be of interest here:

[http://www.bothsidesofthetable.com/2009/09/16/most- startups-...](http://www.bothsidesofthetable.com/2009/09/16/most-startups- should-be-deer-hunters/)

</comment><comment><USER3> Has the author read Camels and Rubber Duckies[1]?

"The reason I bring this up is because software is priced three ways: free, cheap, and dear.

1\. Free. Open source, etc. Not relevant to the current discussion. Nothing to see here. Move along.

2\. Cheap. $10 - $1000, sold to a very large number of people at a low price without a salesforce. Most shrinkwrapped consumer and small business software falls into this category.

3\. Dear. $75,000 - $1,000,000, sold to a handful of rich big companies using a team of slick salespeople that do six months of intense PowerPoint just to get one goddamn sale. The Oracle model."

[1] [http://joelonsoftware.com/articles/CamelsandRubberDuckies.ht...](http://joelonsoftware.com/articles/CamelsandRubberDuckies.html)</comment>