Reverse Engineering for Beginners - <AUTHOR> http://beginners.re/ <comment><USER2> If you prefer video tutorials to a book, be sure to check out the Lena151 tutorials: [https://tuts4you.com/download.php?list.17](https://tuts4you.com/download.php?list.17)

If you want to practice your reverse engineering skills in a legal manner, check out crackmes.de: [http://crackmes.de/](http://crackmes.de/)

tuts4you also has a nice crackme/unpackme section.

<comment><USER3> I recently started a YouTube series on hacking. With a main focus on reverse engineering and memory corruption. I'm currently on episode 0x5 and I currently release them biweekly.

[https://www.youtube.com/playlist?list=PLhixgUqwRTjxglIswKp9m...](https://www.youtube.com/playlist?list=PLhixgUqwRTjxglIswKp9mpkfPNfHkzyeN)

I also record myself playing CTFs and I just created a video walkthrough of the pwnable 200 challenge from the 32c3 CTF: [https://www.youtube.com/watch?v=wLsckMfScOg](https://www.youtube.com/watch?v=wLsckMfScOg)

Maybe it helps somebody.

<comment><USER4> Good stuff. Consider posting in [https://www.reddit.com/r/ReverseEngineering/](https://www.reddit.com/r/ReverseEngineering/)

</comment></comment></comment><comment><USER5> I highly recommend downloading your router/modem firmware and having a look at it. Even running `strings` against it should be quite interesting.

If you're interested in unpacking a firmware then have a look at `binwalk` [1]. It might even work against your Blu-Ray player!

1: [http://binwalk.org](http://binwalk.org)

</comment><comment><USER6> Another way to learn is watch Charlie Miller reversing hardware presentations [https://youtu.be/_9ErnoLVxCA](https://youtu.be/_9ErnoLVxCA)

For example he notices a pattern, so assumes it must be a return after a function. From there he can reverse their proprietary battery controller

</comment><comment><USER7> What are the prerequisites? Knowledge of computer architecture A to almost Z?

<comment><USER8> Just a desire to learn. I gave this a quick glance, and it's reasonably complete in terms of foundation material.

It's not going to be difficult for people lacking some things to go and look them up in context.

The most important skill here is knowing what you don't know and the secondary skill of paying close attention to what you see happening.

One might want to explore electronics enough to use a scope, logic analyzer, etc...

This is a pretty great book, and I look forward to exploring it.

<comment><USER5> Having a goal helps too. I tried and failed to learn x86 assembly a number of times in 2015 and then decided to focus more on modem firmware analysis instead. Sure, it's a bit of a cop-out (I can get a lot further without looking at any assembly code) but I'm slowly coming back around to reverse engineering the long way around.

<comment><USER8> Oh it does indeed!

Well said, and agreed completely.

One way to get familiar with assembly is to get a development board that can run bare metal code. You could even start with something that isn't x86, but is assembly. Once you complete a driver, game, or some other project in assembly, learning another assembly becomes considerably easier.

There is a mindset involved. You can get it on a 6502, if you want to, but you have to have it in order to make any real sense of assembly language, IMHO.

I have my struggles with this too, but I find it always interesting and fascinating. Goes back to the days of cracking games and opening up licenses on simpler, smaller computers.

I also believe a number of us should maintain and share these skills. It's important for a lot of basic reasons, and those don't have to be piracy, or nefarious malware reasons. It may be as simple and benign as using something we own to do something we want it to do as opposed to what it was originally intended to do.

<comment><USER5> I've never quite been able to shake the feeling of being born in the wrong era. I didn't start learning programming til I was 12, and I jumped straight into higher level languages. While I'm thankful for StackOverflow, I've got a bookshelf full of things like Peter Norton's Guide to Assembly just waiting for a spare week or two.

<comment><USER8> I sometimes feel I missed things too. For me, it's a better era alignment in that I was writing low level code on the simpler machines. But, I did step away for quite a while doing manufacturing, CAD, and a lot of related things.

All of which were very interesting, but my real love is programming and circuits. So, now I'm back, making progress, loving it, but also feeling a bit out of place.

We are not alone, of that I am sure.

</comment></comment></comment></comment></comment></comment><comment><USER9> I like the French Cafe parable by Andrew Tridgell of Samba on the topic [https://www.samba.org/ftp/tridge/misc/french_cafe.txt](https://www.samba.org/ftp/tridge/misc/french_cafe.txt)

<comment><USER5> Isn't that more specific to protocol reversing?

</comment></comment><comment><USER10> Wow! This is a massive book! Here's my New Year's Resolution staring me in the face.

<comment><USER11> There's a lite version available on the same page.

</comment></comment><comment><USER11> I began reading this book yesterday. So far it's a good introduction to analysing and manipulating ASM.

You'll need a windows system though. I found that the GCC examples didn't match up with what I was seeing on my Debian VM.

<comment><USER12> Because of different compiler versions, maybe?

<comment><USER11> Turns out I was compiling to 64bit which changes the ASM.

I compiled to 32bit and then ran IDA-free version using WINE on OSX (Hopper's output was too different).

Output is now identical.</comment></comment></comment>


The Lisp Curse (2011) - <AUTHOR> http://www.winestockwebdesign.com/Essays/Lisp_Curse.html <comment><USER2> I used to read these kinds of articles with interest, back in my Common Lisp programming days. They would worry me. Back in the day, I would even sometimes participate in language advocacy discussions.

These days, I don't care at all — I just write great apps that work (fast). Some code runs on the JVM, some code runs in the browser, some runs in both places. I get to use an impressive set of libraries from at least three different ecosystems (Clojure/ClojureScript, Java, Javascript). I get to use fantastic languages with impressive concurrency support. I deliver applications which customers pay money for.

For me at least, Clojure made this kind of writing totally obsolete, in the span of several years.

<comment><USER3> You need to add something like python or ruby to your arsenal for quickly writing scripts that start up fast ;) or do you use nodejs for this?

<comment><USER2> Startup time is something of a red herring for me, kind of like "give me a single EXE or your language is useless" used to be in the Common Lisp world. I don't encounter this problem in practical use. But then, I don't use Clojure to write scripts that I then run hundreds of times from the shell (but why would you want to do that, rather than write a program that does what is needed to hundreds of files at once?).

</comment></comment></comment><comment><USER4> Lisp is programmable programming language, especially Common Lisp. It works as programmer amplifier. Better you are, more you benefit from it.

I challenge anyone to watch this lecture from Christian Schafmeister and say they are not impressed: [https://www.youtube.com/watch?v=8X69_42Mj-g](https://www.youtube.com/watch?v=8X69_42Mj-g) and [https://www.youtube.com/watch?v=0rSMt1pAlbE](https://www.youtube.com/watch?v=0rSMt1pAlbE)

<comment><USER5> What popular programs are written in Lisp?

<comment><USER6> The software I produce at work is Ruby. I don't know that it's popular -- but it is central to a large company's operations.

But I generate and validate that Ruby code with Common Lisp -- in other words, I write Lisp that writes correct, idiomatic Ruby.

I would be very surprised if I were the only person doing this.

<comment><USER7> Have you written about this somewhere? I've love to read more about it.

</comment></comment></comment></comment><comment><USER8> Replicating "pre-AI-winter" success is like trying to replicate "pre-dot-com" success, et cetera. The past is the past. Such things all depend not on technical reality but on what was the predominant belief among some non- technical decision makers. Old Lisp was funded by institutions. There were so many dialects because multiple institutions were actually developing Lisp using local talent. That required funds, and dispensation of funds requires that someone is rationalizing that dispensation based on some beliefs, and those beliefs are very distant from specific technical ideas like "multiple dispatch is a beneficial in OOP".

What remains is that the Lisp design contains numerous elements which are great ideas, which, if they are nicely implemented in their proper form, give you a great programming language.

That doesn't translate to being able to return to the time when you're showered with institutional money to just go wild hacking on whatever you like.

</comment><comment><USER9> I don't think there's much explanatory power here at all, actually.

Some of the most popular languages today, from a web development perspective at least, are JavaScript, Ruby, and Clojure.

One of them is an actual Lisp with full-blown macros and a lot of Emacs users.

The others are also extremely expressive, dynamic, and amenable to metaprogramming.

I don't think there's a single, simple, beautiful explanation for why Common Lisp isn't more widely used. Mostly it just has an undeserved bad reputation... partly because articles like this show up all the time, reinforcing the stigma of Lisp as a weird language for bipolar geniuses, or whatever.

<comment><USER10> I am a _big_ fan of Clojure, but you're definitely overstating its popularity relative to Javascript and Ruby. I would put at very least PHP, and Python ahead of it as well, and Java and C# probably see more web work done with them. Clojure is just not in the same league in terms of popularity as any of these.

<comment><USER9> It's still very possible to hire Clojure developers, people know about it and are willing to learn, it's got a good reputation, and so on.

</comment></comment></comment><comment><USER11> In 1988 I was an intern at HP Labs and my project was 50% Lisp and 50% C, the latter half dealing with time-critical IO and low-level routines crunching CAD tablet input.

At the end of a day working on the Lisp portion, which assembled sketched lines into a CAD model I went home happy and relaxed with a feeling of accomplishment. At the end of the C days I felt tense and slightly worried, thinking about ways of more cleverly detecting what the user was trying to sketch on the tablet.

In my 20+ years of programming I never returned to Lisp and I don't quite know why I don't miss it. I have a vague nostalgia for Lisp but I think modern programming languages give us enough tools to get our job done without feeling too much shame about abandoning the purity of Lisp.

Also, the proselytizing has not helped. I think the "Blub paradox" article embodies the mindset that was ultimately the nail in Lisp's coffin.

<comment><USER12> I had to Google the Blub Paradox ([https://en.wikipedia.org/wiki/Paul_Graham_%28computer_progra...](https://en.wikipedia.org/wiki/Paul_Graham_%28computer_programmer%29#The_Blub_paradox)) but I see what you mean. It's based on the idea that someone who disagrees with you about something can't be acting rationally, rather that they are somehow incapable of perceiving your wisdom. Sometimes that is the case, of course, but I don't think that explains why Lisp isn't the universal language that everyone writes everything in.

I have a lot of warm fuzzy feelings about Lisp as well, but a lot of Lisp advocacy has been of the "One True Language" variety as opposed to "right tools for the right job, and here's why Lisp might be the right tool for you". It doesn't affect my perception of Lisp, but it doesn't help market it either.

<comment><USER13> The name doesn't help at all. "Blub" has connotations of bumbling stupidity even without knowing what the "Blub Paradox" is.

</comment></comment></comment><comment><USER14> I read the article and thought a lot about it, but I'm not buying it. The acceptance problems for Lisp haven't been because it is "too powerful" or that lone wolf hackers won't work together.

The author makes an example of the many Object Oriented (OO) systems, but he performs some bait-and-switch there. Those many OO systems were for _Scheme_, not Common Lisp. And Scheme is intentionally a tiny Lisp. For a long time, Scheme was focused on being the smallest possible Lisp. Common Lisp on the other hand, while it briefly went through an OO experimentation period, really only has one OO system: CLOS.

Also, the whole Emacs line is off target too. What has that to do with the expressive power of the language? And why ignore the two extremely powerful commercial Common Lisp IDE's out there? So is the point that Common Lisp isn't successful because there isn't a better free IDE?

And the "lone wolf/80%" isn't doing it for me either. The Common Lisp specification was the work of many bright minds and is brilliant. And it stands in complete opposition to the situation the author attempts to describe.

I'm not saying that Lisp in general (Scheme, Common Lisp, and Clojure) has been successful, or that Common Lisp in particular has been. If the standard is mindshare and acceptance they have not been successful. There are histories and causes aplenty, but being too powerful is not one of them.

</comment><comment><USER15> I'm the author of this essay. This must be at least the third time that it has appeared on Hacker News. I'm starting to get sick of it, myself, but I keep it up because so many people like it (at the bottom of the page, you can see the translations; all done gratis by volunteers).

I wrote it during a period when I was especially fascinated with Lisp and got caught up in the theorizing to which the Lisp community can be prone. Nowadays, I freelance in front-end web development and doing Lisp hacking is something that I put on the back-burner.

<comment><USER3> so you just use javascript? I'm in that period of fascination, any practical advice? ;)

<comment><USER15> For now, yes. My life has taken some unexpected detours, these past few years, so I have to focus on work rather than inspiration.

<comment><USER16> Have you ever put (any, as in CL, Scheme etc.) Lisp into practice? I got the impression from the essay that you think that everything in a Lisp consists of macros, which is not the case.

</comment></comment></comment></comment><comment><USER17> A personal anecdote:

I stumbled on LISP and Scheme around the time I graduated from high school in 1991. I became interested in LISP from learning about classic AI research. I found a professor my first year in college who mentored me in an independent study of LISP. I then learned scheme doing a self-study with SICP.

Despite all of this, I've never done any paid work in LISP, and I've spent the majority of my career writing C. I can't write a LISP program from scratch from memory any more.

However, I've found that the ideas of functional programming and the concept of the read-eval-print loop have colored my understanding of software design in a really positive way. I remember when I learned TCL in the mid 90s it was immediately obvious that TCL is just LISP on strings (read-substitute-print). Lua is also very LISP-like, with tables instead of lists.

</comment><comment><USER18> Power is a weakness in a programming language, not a strength - some of the most interesting research languages today are not even Turing-complete. It's easy to add expressiveness to a clunky language; it's much harder to add limits to an expressive language that prevent expressing nonsense.

<comment><USER8> "Expressive power" and "computational power" aren't the same thing.

Turing's original Universal Machine (you know, the moving read/write head over an indefinitely long tape of symbols) is not expressive at all; a simple task like adding two integers on that machine requires a completely arcane, verbose piece of gobbledygook to be prepared on the tape, where you cannot tell at a glance which part of it is the program, and which is the integers to be added. It is less expressive than 4 + 4 in a calculator language that doesn't have loops.

Expressive power is, in its barest essence, the freedom to assign an arbitrary meaning, from some domain, to a new combination of symbols, such that every symbol in that combination refers to some entity in that domain only.

It behooves us to have a general-purpose language with as much expressive power as we can get our hands on.

It is not hard at all to add restrictions in domain languages created inside an expressive language. For instance if you make an x86-64 assembler in Lisp, it will be just as restricted as any other assembler; it will diagnose unrecognized opcodes, bad addressing modes, etc.

<comment><USER18> > For instance if you make an x86-64 assembler in Lisp, it will be just as > restricted as any other assembler; it will diagnose unrecognized opcodes, > bad addressing modes, etc.

But it won't enforce those things at compilation time in the type system, because it doesn't have one. You might have a macro that checks them, but it would be ad-hoc.

<comment><USER9> Another commenter already said that Common Lisp indeed does have a type system. It's possible to circumvent, but that's Lisp for you.

You can very easily write an assembler in Haskell that doesn't verify any of that stuff statically. Learning to do advanced kinds of static verification with Haskell's type system is actually rather difficult, and usually requires language extensions.

Using a macro that checks those things seems like it could be a very pragmatic way to provide safety. It might also let you verify properties that would be hard to figure out how to verify using only Haskell-style type checking.

Indeed, Haskell programmers often use QuickCheck to do ad-hoc verification of type class laws, for example, since they can't be proven in the type system.

<comment><USER18> > Learning to do advanced kinds of static verification with Haskell's type > system is actually rather difficult

Perhaps. But it benefits greatly from being a consistent way of doing things: everyone does their static verification the same way, because the language supports exactly one way of doing it.

> and usually requires language extensions.

Sometimes. But again at least those extensions are relatively standardized, rather than completely ad-hoc as a macro can be.

> Indeed, Haskell programmers often use QuickCheck to do ad-hoc verification > of type class laws, for example, since they can't be proven in the type > system.

Yeah, that's one of the reasons I'm excited about Idris. But even in your example, QuickCheck is again a standardized way of doing this.

<comment><USER9> Well, all you need to do in a macro to provide error checking is to assert or raise a condition when something is wrong. That's pretty standard.

In Haskell land, you can do wonderful things like Servant, the statically verified API server—but that kind of code is very advanced, and written by a shadowy cabal of type level wizards. I think there is less of a standardized way of doing this stuff than one might expect.

I'm not really sure what you mean by "standardized." Common Lisp is an actual ANSI standard... But you seem to be referring to the existence of common practices.

I'm not convinced that the problem you describe is actually a problem, and I'm not convinced that Haskell or Idris will end up being more successful in the mainstream than Lisp.

(I'm a huge fan of Haskell, Agda, and static/dependent typing, for the record.)

<comment><USER18> > Well, all you need to do in a macro to provide error checking is to assert > or raise a condition when something is wrong. That's pretty standard.

Sure, but the conditions that lead you to do that can be arbitrary Turing- complete code. IIRC in unextended Haskell what you can do at type-level is more restricted; certainly you're guided towards a particular way of structuring your constraints. That in turn makes it more practical for other tools to support your constrained sublanguage.

I think the future of programming lies in constrained (BWIM non-Turing- complete) languages and provably correct code. I guess we'll find out.

</comment></comment></comment></comment></comment></comment></comment><comment><USER19> previous discussions:

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

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

</comment><comment><USER20> For those that are interested, here's some livecoding streams of me developing and working in a Lisp I'm developing Sigil:

[https://www.livecoding.tv/burtonsamograd/videos/](https://www.livecoding.tv/burtonsamograd/videos/)

See the 'building a language' parts for actual lisp programming, the rest is JS webdev.

Sigil is a minimal lisp with only the basic primitives (cons, car, cdr, cond, null, atom, lambda and a few others) and macros. The project is an experiment in building a lisp from the axioms and seeing how far one can go without having to add to the underlying lisp implementation (which is in javascript).

</comment><comment><USER21> This is not the curse of LISP; it's the curse of compile-time macros. Any language extensible at compile time has this problem. C++ has it. (See Boost). Rust seems headed there. You can even do this with C macros.

There was, around 1990, a fad for "extensible languages".[1] It died, because the resulting code was so hard to read, with program-specific syntax for each program. Don't go back there.

[1] [http://www.cas.mcmaster.ca/sqrl/papers/SQRLreport47.pdf](http://www.cas.mcmaster.ca/sqrl/papers/SQRLreport47.pdf)

<comment><USER22> I really hope that extensible languages are the future. It is unfortunate that a majority of their users had no clue on how to properly extend the languages. It's about a time to fixe it.

> resulting code was so hard to read,

DSL code is the _easiest_ to read and maintain. No "general purpose" language would ever match this.

> with program-specific syntax for each program.

As if it's something bad.

> Don't go back there.

You failed to understand the entire concept.

<comment><USER23> > You failed to understand the entire concept.

I don't think so. As the article states, this is a social/community issue, if every application has it's own language and syntax that is a huge barrier for others coming to work on it. You might not care about that but most large pieces of software are not written by one person. Beyond that you come to issues of code and skill reuse. A lot of people dislike the expressibility of Go, but it's hard to write code that someone else can't easily come and read and understand.

<comment><USER22> > As the article states

The article is plain wrong.

> if every application has it's own language and syntax that is a huge barrier > for others coming to work on it

And this is quite obviously not true. A _well designed_ (note the emphasis!) DSL makes any app/problem domain/library/whatever much more accessible than any kind of a "general purpose" language can. Simply because DSL does not obscure the essence of the problem.

> Beyond that you come to issues of code

Code reuse with DSLs is way beyond anything the inferior languages can achieve. I witnessed cases where 30+ years old DSLs got revived by reimplementing them from scratch, immediately making an entire (huge) code base available on a new platform, with new tools and bells and whistles.

> and skill reuse.

One should never care about those pitiful "language" skills. They're worthless.

<comment><USER24> Your argument here seems to be that even if the majority of programmers find Lisp and all its derivatives to be difficult to read, we're wrong.

<comment><USER25> No, it's more of a No True Scotsman. People have written DSLs that are unreadable, but those DSLs weren't Well Designed(TM). So their failures don't count against DSLs, because only well designed DSLs count.

I think empirical evidence is that DSLs are easy to make not readable, especially as they evolve. Then again, that's true of almost everything, including assembly language programming, structured programming, object oriented programming, and functional programming (did I miss anything?).

</comment></comment></comment></comment></comment></comment><comment><USER26> There are many good points in this article and even the variety of Common Lisp implementations in existence attest to the author's point. It seems that everyone is rolling out their whole new CL implementation.

That said, even if it were true that the power of lisp turned out to be it's curse, one should be careful to generalize this way about _lisp hackers_ , _80% projects_ and lack of documentation. The language might tempt you to become the hacker portrayed in this article, but it certainly doesn't fight you should you want to follow best practices.

<comment><USER16> Having multiple implementations wasn't a problem for Java (Sun JDK, IcedTea, JRockit), noone thinks much of the different compilers available for the C family (GCC, CLANG, Microsoft C compiler, Intel's C compiler), consider Ruby with MRI, JRuby, or Python. I could go on.

Members of the Lisp family seem to be judged by a different standard. I don't know why that is.

My perspective: the implementations attest to good documentation and collaboration. SBCL by itself is an admirable artifact with extensive documentation that's been maintaned since 1999 (when it forked from CMUCL).

So what gives?

</comment></comment><comment><USER27> Reading this I wonder if the everybody rewrites everything is that much of an issue. The benefits of it-crowdsourcing capitalized through libraries isn't obvious to me. Some languages make it necessary to distribute the cost of libraries through groups. Maybe Lisp allows to skip that and go straight at the problem. I remember one article about a guy looking at a Graph library for Java. He found two, generic, typed, object and all that; they were more a problem than a solution. He made its own thing in Lisp and called it a day.

</comment><comment><USER28> I like it. It's a keeper. Also the argument is a bit overstated.

 _"...The moral of this story is that secondary and tertiary effects matter....Employers much prefer that workers be fungible, rather than maximally productive...[in regards to creating a larger framework] The reason why this doesn't happen is because of the Lisp Curse. Large numbers of Lisp hackers would have to cooperate with each other..."_

So here's what I see. I see a lot of frameworks and libraries composed by folks using other languages. Many of these, yes, are much more complete than one, totally-custom-made solution by some Lisp hacker. And yes, large numbers of people participate in creating and maintaining these larger frameworks and systems.

I also see large corporations _bleeding_ cash because they wanted silo'ed, fungible programmers. Got seven architectural tiers, each with its own framework? Hell, you're going to need seven extremely specialized programmers, kid. Time to get on the phone with the recruiter.

So they purchase these specialists. All the buzzwords match. The specialists sit down at the magic frameworks, the ones all the cool kids over the last two years have decided to support. Life is good. For about ten minutes. Then something is required that's not in the frameworks. Or the framework is broken under this one particular edge case.

Suddenly we need somebody who's general purpose again. Except -- and this is especially nice -- that's not the guy we hired. So seven layers of experts sit struggling with seven oddball issues. Googling Stack Overflow. Hacking the crap out of things. Making a total mess.

And at the end of the day, if we're lucky, something ships. Something with little problems here and there that requires seven different areas of expertise to figure out. Plan on maintenance being fun.

The next day version 2.0 of the framework on layer 5 ships. Now if you want maintenance programmers, for layer 5 they have to know both version 1.0 and 2.0

More complexity continues. It's fun for everybody.

Compare this to the guy who uses a standard language, decades-old libraries, hacks out a partial solution (but good enough to ship) in a few days and then moves on to something else. Now tell me that the framework guys have a better technology development model. I ain't believing it.

I'm not saying become a lone wolf and never work with folks. I'm saying that "working with folks" can completely kill any kind of value you're trying to create. Do it wisely.

</comment><comment><USER29> I wonder why there is all the anguish around why Lisp hasn't flourished, and seemingly less anguish around APL, or even Smalltalk. Is there a reason it engenders so much loyalty? Is it the idea that macros allow you to extend the language, and that seems like the pinnacle of the programming hierarchy? Could there be insight gleaned from looking at programming languages as a fad or style?

<comment><USER30> I think it is because, for a lot of people, Lisp is fun.

If Lisp flourishes, more people would get to use it at work.

Lisp not flourishing means less fun.

Also, when I've worked in Lisp it just seemed like the right way to do things. Everyone likes to do the right thing, so anguish results when you seem denied the opportunity to follow the path you feel is right.

That said, I think the author was right and the community issues and ease of building your own solutions will limit Lisp as a language family.

<comment><USER31> I can definitely subscribe to the idea that Lisp is fun. The application I have been writing (featureful chat application like Slack) has a server side completely written in Common Lisp by myself. Why do I work on it even though it's unlikely that it will ever draw anyone away from Slack?

Because it's fun.

Is it possible to do the same in another language? Sure, Slack is proof that it's possible. But would I have persisted in actually doing it without any hope of profit? No, because programming in other languages is a chore, and the only light at the end of that tunnel is the finished product.

With Lisp, the journey is a reward of its own.

Yes, I know the same thing has been said by Haskellers and others, but I doubt it was ever said by a C++ programmer.

</comment></comment></comment><comment><USER32> I think that Clojure mitigates these issues quite a bit for a couple reasons:

\- The core library is has enough built in that many questions are answered using built in solutions (e.g. what is done with objects elsewhere is very frequently done with maps and functions that operate on maps) \- The language designer (Rich Hickey) is very opinionated, and the language tends to attract people who agree.

There still are multiple choices when it comes to solving some problems (Om vs Reagent vs Rum vs etc.), but is that really that much different than other languages? Javascript has a million choices for the same domain.

</comment><comment><USER33> "BBM" == Brilliant Bipolar Mind. The acronym is used in "The Lisp Curse" citation of The Bipolar Lisp Programmer, but defined elsewhere in material not cited.

</comment><comment><USER34> People who care what other people think about the programming languages they use write essays like this.

The rest of us just shut up and hack some Lisp.

</comment><comment><USER35> The homoiconic thing is not all it is made up to be. That is, you can take (say) Java and parse it to an abstract syntax tree and the manipulate the tree.

Assuming you have a good toolbox of operators, working with that kind of AST is not much harder than working with s expressions. Maybe it is easier if you can build a general notation that can be generalized for multiple languages and also represent more ordinary data such as json formatted, relational, rdf, etc.

<comment><USER36> I couldn't disagree more. Working with that kind of AST is many orders of magnitude harder than Lisp macros. None of it is first class. You brush over it in your comment like writing a Java parser is trivial. My clojure parser returning the AST in its entirety is: (read-string (slurp "my-source.clj")). What does your Java one look like?

The proof that it is so much harder is that no one ever does it. Yet people do this all the time in Lisps. If its "not much harder" I'd expect to see more of it, but I don't, because it is just so much work.

Aside from parsing, what about templating. Yes, you can manipulate the AST once you have it, but what would templating AST look like? Would it look just like the Java code? With the syntax quote in clojure it looks very much like the output. How would you even begin to template syntax in your hypothetical Java implementation?

<comment><USER35> 1\. I am not writing a parser, one already exists and can be brought in about as easy as your code sample. 2\. I am translating the AST to rdf which lets me work on the AST with production rules 3\. If I wanted templates I would use templates. What I do do is start out with an abstract representation and then apply say 20 simple transformations that step by step fill in the details to get to code. Speed is OK because we have indexes, rete networks and other tricks. 4\. People are not doing it yet and this is why people are saying code reuse is hard, etc. 5\. The transformations are written in a sparql derived rule format that itself uses the transformation system to add features by composition.

<comment><USER36> I feel like you are being disingenuous. Do you have any experience with Lisp macros? Please enlighten me. Show me how you parse Java, into rdf, and then into AST in one line. And a link to this "already existing" parser would be great. Also, can you link me to some examples of this sparql derived rule format so I can compare.

<comment><USER35> See

[http://www.eclipse.org/articles/Article- JavaCodeManipulation...](http://www.eclipse.org/articles/Article- JavaCodeManipulation_AST/)

as for SPARQL derived rule format see

[http://spinrdf.org/](http://spinrdf.org/)

although we've done a bit to humanize the syntax and try to add back some of the features that were common in production rules engines back to the 1970s.

</comment></comment></comment></comment></comment><comment><USER37> I think this is not properly accounting for the difference between something that's 90% done, and something that is done. (Nothing is ever finished, of course, but you know what I mean.) As we all know, the difference between the two is not simply a gap of 10 percentage points. Far from it.

Teams of people were required to write Haskell and Dr Whatshisname tossed off Qi by himself. OK, but people use Haskell, does anyone use Qi? If not, then it's not a problem for Qi to be 90% done. And that's a lot easier to accomplish by oneself.

</comment><comment><USER38> A lot of thoughts about lisp; are written by zealots; who like to create the impression that they are playing with some kind of dangerous mind amplifying meta language; and if you start using it; you might accidentally unleash creatures from the id. But then you look at it; and find it is simply a programming language.

</comment><comment><USER32> Should add a (2011) to the title.

<comment><USER39> Added.

</comment></comment><comment><USER40> _" It's so damn hard to do anything with tweezers and glue that anything significant you do will be a real achievement. You want to document it. Also you're liable to need help in any C project of significant size; so you're liable to be social and work with others. You need to, just to get somewhere."_

Oh is it time already for another "C is for idiots" thread from Lisp supremacists again? If Lisp fanboiz were slightly less busy ridiculing the rest of the world over how stupid everyone else is, they might even have had some time to pay attention to silly things like performance and tooling. That might help the adoption a bit more than the supercilious rock throwing that is almost exclusively the tone of every single article/post from Lisp lovers.

<comment><USER41> C is the king of raw performance, there's no denying that. But for the vast majority of high-level, user-facing applications today it's a bad fit.

Clojure is more than fast enough for serious server side programming, often coming close to Java in performance with minimum amount of tuning needed in the average case. When you add multithreading into the mix, it's not even a contest; the amount of time you'll have to spend to make an idiomatic Java or C++ run both correctly and fast is gargantuan compared to a language where concurrency was built-in from the start.</comment></comment>


Step-By-Step Fundraising Tactics from an NYC Founder Who Raised $750M - <AUTHOR> http://firstround.com/review/step-by-step-fundraising-tactics-from-the-nyc-legend-who-raised-750m/ <comment><USER2> Not really a criticism, but this read a bit like a slimy dating guide. "Remember, like everyone else they want to feel wanted for more than their money". "Keep them all interested until you've made up your mind". "Subtly let them know that you're wanted by others".

On an unrelated note: I don't know why I can never contribute constructively on this site, but here I am.

<comment><USER3> Given that this was published by a VC and that the writer has been on both sides of the table, I think you're misreading it.

<comment><USER2> I wasn't really trying to imply it's bad advice or isn't ethical or anything. I get that the parallel I decided to draw does indeed somewhat imply that, but my intentions weren't as such. Just struck me as funny.

</comment></comment></comment><comment><USER4> > "When I plan to be raising in six months, I'm already out there, proactively > connecting with VCs, having coffees, making as many of them aware of my > company as possible," says Ryan. "The conversation is safer when I'm not > raising money."

Yeah, because so many of us can pick up the phone and have VC's go have coffee with us for no reason at all. <rolls eyes>

Starting off an article on fundraising with "Have a lot of rich friends" doesn't actually add credibility to the rest of the article.

<comment><USER5> I mean, being rich is by far the most important factor for success followed by having rich friends.

</comment></comment><comment><USER6> Does it strike me odd that CEOs and founders complain about fund raising? That's one of the most important parts of their job. And I don't see how having 20 VC pitch meetings lasting 30 minutes on average over the course of three months is exactly "hard" work. I'd expect nothing less, and perhaps even more. Or at least some kind of analytical approach to the process that is both reasoned and strategic as it is diligent. I'd assume after the first few presentations you'd pretty much have it down save for some specific research on the firm. If its a lot of e-mailing and paper/busy work, one can hire an assistant or PT contract staff to help.

This is the kind of work I'd relegate as a skill, but not a pure talent if that makes any sense. Some people are probably more natural than others but the skills required aren't worth staking your life on, and this is very much one of those things where all the value comes from experience and knowing the right people.

If people don't want to fundraise, the solution is simple: don't be a CEO or start a company.

<comment><USER7> > Does it strike me odd that CEOs and founders complain about fund raising? > That's one of the most important parts of their job.

> If people don't want to fundraise, the solution is simple: don't be a CEO or > start a company.

That has to be heavily qualified, as it applies to a _very small_ subset of CEOs and founders. Your last statement is radically off-base vs the reality of who starts most new companies in the US. The extreme majority, 99%, of all CEOs and founders in the US do not actively fund raise as part of their jobs. They have actual operating businesses that require their attention and pay for themselves with sales, or otherwise are bootstrapping on variations of self- funding. _Few_ start-ups in the US are backed by venture capitalists or involve VC fund raising.

~500,000 new businesses are started every month in the US. ~400k-500k new employer businesses are started each year. Less than 1% of all of those businesses are backed by venture capitalists.

</comment></comment><comment><USER8> Frankly, this seems like a great article pointing out exactly why the VC and startup space is such a male dominated area. So many clear male biases here (exude confidence, fake it until you make it, etc)

<comment><USER9> Are you saying non males don't have confidence and can't fake it until they make it?

<comment><USER10> I think they may be referencing a confidence gap[1]. 'Fake until you make it' seems like it's referring to imposters syndrome[2]. I haven't found any evidence that it's more prevalent in women than men. Anecdotally women's credentials & skills in tech are often more scrutinized than men which makes 'faking it' seem less possible.

1.[https://scholar.harvard.edu/files/sarsons/files/confidence_f...](https://scholar.harvard.edu/files/sarsons/files/confidence_final.pdf)

2.[http://www.paulineroseclance.com/pdf/ip_high_achieving_women...](http://www.paulineroseclance.com/pdf/ip_high_achieving_women.pdf)

</comment></comment></comment><comment><USER11> I deeply hope to never raise money in my life.

<comment><USER12> The wealthiest among all my investors (who are also self-made) never raised VC for their startups. All bootstrapped.

Too many founders pour their life into a project and end up making less than their investors do from the sale of their own company.

That said, if you can raise a lot for very little equity in a short time, it can be worth it.

<comment><USER13> This is the real secret of the VC industry. Bootstrapping is only harder at the beginning.

</comment></comment></comment><comment><USER14> One of the better fundraising guides out there for sure.

</comment><comment><USER15> This is a joke. "You basically start to believe your own bullshit after a while, and that's a good thing." How can this be taken as serious advice?

I hate this guy, and what this guy represents. I am not a bullshitter, and I will never be one. I'd rather not raise money and fail, than bullshit my way to IPO.

</comment><comment><USER16> Probably one of the best articles I have read about fund raising. It is much more tactical than the typical advice you see on this topic. First Round has a lot of fluff articles but this one is really worth reading.

</comment><comment><USER17> Bullshitology

<comment><USER18> Why?

<comment><USER19> the entire thing is a step by step guide how to bullshit people so you get cash; that's probably why

</comment></comment></comment><comment><USER19> so the name of the game is lie through your teeth, and learn about your opponent so you can lie better..

</comment><comment><USER20> Is this still applicable? I've been hearing seed funding is dramatically drying up.

</comment><comment><USER21> This was the best article I remember reading about the subject.

</comment><comment><USER22> Kevin Ryan, of DoubleClick, Gilt, Mongo DB, BusinessInsider, and Nomad Health.

Edit: fine, no snarky comments</comment>


Ask HN: Recommend a portable oscilloscope - <AUTHOR>

I find myself with a need for something like this:
http://www.seeedstudio.com/depot/micro-digital-storage-oscilloscopedso-nano-p-512.html
To give an idea of the kind of thing I need it for, the first thing I'm going to do with it is monitor the voltage over time at my car battery, as I suspect the alternator is not working as well as it should at idle revs. My simple multimeter won't do, as I have reason to believe the voltage isn't steady, and that's what interests me about it.
The DSO nano looks like it'd do the job, but I'm hesitant to buy one without asking opinions or seeing if anyone knows of any alternatives.
My need is for a relatively simple oscilloscope, ideally with more than one input channel (two would be fine). It's not for logic analysis work, and would need to be portable and battery powered (ideally, more or less hand held). Does anyone have experience with the DSO nano or an alternative device? <comment><USER2> Looks like you need more than just an oscilloscope - you need a trend recorder. The DSO Nano is a great for casual work, but if you have some electronics skill, you can easily build an attenuator to hook into your laptop's microphone or line-in (1 channel or 2 channel) jack and record the signal for trend analysis. You can also use an MP3 player with recording abilities as long as it records to a WAV file, not MP3 directly.

Take a look at these links: <http://www.ledametrix.com/oscope/index.html> <http://www.zelscope.com/>

And if you grow out of it, this is a very hackable, real oscilloscope for an affordable price: <http://www.dealextreme.com/details.dx/sku.30573>

Here is info on hacking the Rigol to make it a 100MHz scope: [http://mightyohm.com/blog/2010/03/rigol-ds1052e-50mhz- to-100...](http://mightyohm.com/blog/2010/03/rigol-ds1052e-50mhz-to-100mhz- scope-conversion/)

</comment><comment><USER3> If you're just looking for an advanced logic analyzer, <http://www.saleae.com/logic/> is relatively cheap and pretty awesome. Linux and Mac OS X versions of the software coming soon I believe. It also includes an SDK so it's awesome for programmers.

It's about the size of the new iPod Nano and comes with a carrying case to store the modular leads, and USB cable.

EDIT: Before people flame, yes this product is pretty different from the OP's link, however it might be somewhat what s/he's looking for.</comment>


Show HN: Coconut – Simple, elegant, Pythonic functional programming - <AUTHOR> http://evhub.github.io/coconut/ <comment><USER2> While this is gorgeous, I can't help but feel it's a bit disingenuous to call anything "Pythonic" and "functional" at the same time given Guido's take on the whole thing[0][1]... especially when you're actually extending the language to make it happen. ;)

[0]: [http://python-history.blogspot.com/2009/04/origins-of- python...](http://python-history.blogspot.com/2009/04/origins-of-pythons- functional-features.html)

[1]: [http://xahlee.info/perl- python/python_3000.html](http://xahlee.info/perl-python/python_3000.html)

<comment><USER3> Thanks! And that's a very good point. The idea of "Pythonic" as a guiding principle, however, is just to try to make the new functional additions look as Python-y as possible. Case-in-point: Coconut uses the plain english keyword "match" and an indented block for pattern-matching instead of trying to introduce new symbols or syntax.</comment></comment>


SpaceX Rocket Lands Safely on a Ship at Sea for the First Time - <AUTHOR> http://www.npr.org/sections/thetwo-way/2016/04/08/473572033/spacex-rocket-lands-safely-on-a-ship-at-sea-for-the-first-time?utm_source=facebook.com&utm_medium=social&utm_campaign=npr&utm_term=nprnews&utm_content=20160408 <comment><USER2> Lots of earlier dicussion: [https://news.ycombinator.com/item?id=11457964](https://news.ycombinator.com/item?id=11457964)</comment>


Ask HN: Would you give $5 to a wikibook project about github? - <AUTHOR>

I would, for one. <comment><AUTHOR> <http://www.wikibooks.org/>

<http://www.github.com/>

EDIT: ok, <http://progit.org/book/index.html>

As the more general question: How does a unified docs project sit with the open source community?

</comment><comment><USER2> Could you clarify what you mean? You'd like to write a book about GitHub?

<comment><AUTHOR> Sorry for the delay, and no I am not soliciting. I mean I would like to read one, preferably a really good workflow/usage introduction and let's say adequate detail to reproduce all components/processes of an example application.

Who would offer some donation or commit to contributing to great documentation projects? What are some great OS documentation projects? I am getting tired of too many decentralized, semi-contemporary search results while trying to learn new tools.</comment></comment>


How to Lead Without Saying a Word  - <AUTHOR> http://blogs.hbr.org/cs/2010/05/how_to_lead_without_saying_a_w.html?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed:+harvardbusiness+(HBR.org)

<comment><USER2> Seems like pretty straight forward stuff, be approachable, listen to others first, don't be a hot head.</comment>


A Pentagon-funded contest spawned many of today's self-driving startups - <AUTHOR> https://www.bloomberg.com/news/features/2017-10-30/it-s-been-10-years-since-robots-proved-they-could-drive <comment><USER2> Keeping up with Darpa's challenges is a good way to see into the future a couple of their current projects:

1) A machine-learning competition to overcome scarcity in the radio frequency which is INSANELY fascinating and, if they pull it off, hugely impactful -> [https://spectrumcollaborationchallenge.com](https://spectrumcollaborationchallenge.com)

2) A program to build technology to drive "swarm sprint" exercises to inform tactics and technologies for large groups of unmanned air and ground robots in urban environments. Yes, like how do we build a collaborative air drone army.

And PS they are having a hacker fest in the bay in a couple of weeks, registration is closed but bet you can get in if you email via - [https://darpahackfest.com](https://darpahackfest.com)

<comment><USER3> The technologies that will be developed in #2 will be absolutely, unquestionably used by governments to repress their own people.

<comment><USER4> > _The technologies that will be developed in #2 will be absolutely, > unquestionably used by governments to repress their own people_

One can go to the dawn of self-driving cars, the Internet, really any potentially game-changing technology, and throw this out. It's an inconsequential assertion that provokes no follow-on thought. Just emotion.

Graduating this seed from FUD to a chain of critical thought involves asking how the technology in question might evolve detrimentally and what we can do, today and specifically, preferably in a technical capacity, to mitigate that risk.

<comment><USER5> Anything that increases the destructive capacity of armed forces while lowering the manpower requirements is going to make it easier for politicians to misuse those armed forces.

Most obvious example would be the Vietnam disaster. It was eventually shut down because of "bring our boys home". Not because of international reputation, human rights violations or the capability to win or lose the war.

Another example would be how Germany used mechanized forces and air power in the start of WWII as force multipliers. Without sophisticated war machines, attacking France and Great Britain would have been suicidal. Simply because they combined matched German population.

The best bet to mitigate such technology? In those examples it was probably MANPAD that killed helicopter cavalry after Vietnam war. And evolutionary steps of Bazooka helped to keep west Europe from soviet tank invasion during cold war. Those specific inventions increased the manpower requirement while adding relatively small and very specific firepower advantage.

<comment><USER4> > _Anything that increases the destructive capacity of armed forces while > lowering the manpower requirements is going to make it easier for > politicians to misuse those armed forces_

Anything that (a) improves peoples' lives and (b) has a logistical dependency, _e.g._ requires or becomes better with electricity, an Internet connection, package delivery, _et cetera_ , improves the standing of a centralized power. This will be true as long as those logistical dependencies are subject to economies of scale.

Leaving society in the 18th century, before electricity, antibiotics or daily disposable contact lenses, wasn't easy. But you'd have to give up fewer luxuries to do that then that you would today because _there are more luxuries today_.

This is why saying "this will be used for evil things that centralized powers do" is so inane. It's a corollary of economic progress.

<comment><USER5> Well yeah.

Except the thing is that geopolitics is the dictating form of politics. Everything else comes after that.

Let's say US government needs lots of manpower to stay as global hegemon. Then say that there is culture in US where people will gladly "defend the land of the free". Now if you mimic a degree of freedom, you get that manpower relatively easily.

Then you can innovate things that connect to the grid as much as you want. As long as the DoD needs grunts, they will give you civil rights and freedom simply because they have to. They probably would do that most of the time because they want to. But given enough time, you will see clusters of bad apples to get office.

It's kinda ironic that US has to be "free" and "powerfull" compared to the enemies. If China opens up their internet bit more, US citizens will get net neutrality without fighting. Also if China produces weapons that take away the technological edge or US, then America needs more manpower to the armed forces. That would lessen political polarization, corruption etc. Nothing unites like common enemy. Except capable common enemy.

</comment></comment></comment></comment></comment></comment><comment><USER6> It certainly seems to validate the strategy of "grand challenges" to focus research. One could argue that the X prize helped spawn today's commercial space companies. So does this mean a good way for benevolent billionaires to improve the world would be to sponsor things like this? Certainly Gate's sponsoring the toilets prize was influential in bringing out better sanitation ideas.

I wonder if anyone would sponsor a prize for an 'off grid' sustainable living space. People create slums and homeless encampments out of a variety of cast off materials, is there a way to create housing for people which would be safer and enhance their quality of life without also creating a public burden? Perhaps that is a pipe dream but it is something I wonder about.

<comment><USER7> >One could argue that the X prize helped spawn today's commercial space companies.

That'd be a stretch. The Ansari X Prize led to a bunch of companies pursuing a goal with little commercial value and few designs with orbital aspirations. The winner led to a costly, dead-end design that has still yet to fly again for suborbital tourism, killed four people along the way, and will never service orbit. The rest of the companies are either dead or vaporware.

That said, I'm generally in favor of prize-based challenges to spur development at lower cost, as long as you aren't forced to set a goal that's entirely tangential to what you _want_ out of industry. Newt Gingrich is a notable supporter of the idea, but I'm not aware of any other prominent politicians who support it.

<comment><USER8> Sanders proposed a prize system for pharmaceuticals. It's an interesting alternative to patents for rewarding innovation in that space particularly, which is entirely patent dependent.

[https://www.govtrack.us/congress/bills/113/s627/text](https://www.govtrack.us/congress/bills/113/s627/text)

</comment></comment></comment><comment><USER9> I would argue that the 2004 DARPA challenge was a failure with the best car, Sandstorm, only going 7 miles before getting stuck on a rock. That led to a do-over in 2005 that was really the first success.

[https://en.wikipedia.org/wiki/DARPA_Grand_Challenge#2004_Gra...](https://en.wikipedia.org/wiki/DARPA_Grand_Challenge#2004_Grand_Challenge)

<comment><USER10> I would argue that no one who has commented in this thread so far has actually read the article.

<comment><USER11> Ha, yes it's especially obvious in this case since the HN-chosen title is opposite the general flow of the article.

I think people would be more likely to read the bulk of articles if they actually followed the inverted pyramid structure. Instead, nearly every one begins with a meandering human-interest story to draw the reader in.

Whatever happened to those proposals to annotate the web?

</comment></comment></comment><comment><USER12> The DARPA grand challenges were an important step for autonomy, by demonstrating basic capabilities and bringing attention and industry funding to the field, but overhyping the expertise gained there may have held the field back over the years. The hardest part of building a self-driving car has proven to be robust perception (processing sensor data to create a very accurate representation of the dynamic environment), which is an aspect that was not heavily emphasized in the challenges: for instance, the winning entry in 2005 had $500K worth of Lidar on it, and the cars were given a GPS map, which allows very accurate localization with yet another expensive sensor (differential GPS). By all accounts I'm aware of, the perception software involved in the challenges was rudimentary, and a lot of the effort was spent on mechanical engineering and path planning. Most importantly, robustness cannot be demonstrated in a one-off competition. Building robust perception is a hard AI problem, and the expertise required to tackle this aspect is orthogonal to the robotics aspects demonstrated in the challenges (which are also obviously very important).

<comment><USER13> I think this graph from the article supports its thesis pretty well: [https://assets.bwbx.io/images/users/iqjWHBFdfxIU/iUXzVqS5lbv...](https://assets.bwbx.io/images/users/iqjWHBFdfxIU/iUXzVqS5lbvg/v9/-1x-1.png)

And that thesis is not, obviously, that the most important problems, or even any problems, were solved by the DARPA challenges.

> Building robust perception is a hard AI problem,

Oh, I predict, now and here, that something like the following will be posted to HN in 2025 at the latest: "Yes, it's great that my Tesla Model Z lets me browse the internet while commuting, But lets not pretend that this is AI. It's just basic statistics. Also, I really like cozy warmth of Tesla's new line of coal-powered vehicles."

</comment></comment><comment><USER14> There was a great "Nova" episode on the Grand Challenge [1].

[1] [http://www.pbs.org/wgbh/nova/darpa/about.html](http://www.pbs.org/wgbh/nova/darpa/about.html)

</comment><comment><USER15> It was 13 years from the Wright Flyer to the first commercial fixed-wing aircraft. And that was still very dangerous. Jet engines (which really introduced the safety we are used to in airlines) took 50 years.

<comment><USER16> Jet travel brings improved speed and comfort, not really improved safety. Prop planes, as a technology, are _very_ safe. It is a lot easier to land a prop with a failed engine or another part -- due to is low speed one can land small props with a high chance of no injuries on unprepared surfaces such as grass fields. For jets, if you have a failed engine and no landing strip you are likely toast (although there are some well publicized exceptions).

The great flight safety numbers of modern jet travel are due to the fact that commercial traffic is heavily regulated end to end, from production to operation, licensing and maintenance. None of this is specific to jet travel, it is just that speed and comfort pushed props mostly out of the business.

<comment><USER17> It is very counter-intuitive, but speed increases safety in an aircraft type both as a function of hours and as a function of miles. This is an empirical fact that's true for both military and civilian aircraft, I was looking for the US Air Force chart on this, but couldn't seem to find it. Not to discount other factors, but the OP is correct that speed increases safety. Maybe someone with more Google skills can find this chart.

<comment><USER18> Speed + altitude combine to give you options, options are what makes an in- flight issue survivable.

</comment></comment></comment></comment><comment><USER19> Ahhh DARPA, that state controlled, taxpayer funded, centrally planned bedrock of free market capitalism.

<comment><USER20> Even if the government entity is taxpayer funded and centrally planned, this is a competition structured like a market. They set out a bid (the winning amount for the goal) and people can compete however they see fit and spend what they want.

Similarly, the Army doing RFPs to buy a bunch of toilets is still a free market to compete in as a toilet supplier.

<comment><USER19> Didn't say it wasn't "like a market" in some ways. But DARPA is very much not free market capitalism. It is state capitalism. Silicon Valley is the product of massive government investment.

</comment></comment></comment><comment><USER21> 27 years. The first famous "proof of concept" autonomous driving is Navlab (Thorpe, 1990). (Are there any prior projects?)

<comment><USER22> A little more than that.

Navlab 1 was built in 1986 using a Chevrolet panel van.[2] The van had 5 racks of computer hardware, including 3 Sun workstations, video hardware and GPS receiver, and a Warp supercomputer.[2] The vehicle suffered from software limitations and was not fully functional until the late 80s, when it achieved its top speed of 20 mph (32 km/h).[2] [https://en.wikipedia.org/wiki/Navlab](https://en.wikipedia.org/wiki/Navlab)

<comment><USER23> The Warp supercomputer is interesting [0] as it's apparently a 'systolic array' computer. Never heard of that architecture before...?

0\. [https://en.wikipedia.org/wiki/WARP_(systolic_array)](https://en.wikipedia.org/wiki/WARP_\(systolic_array\))

</comment></comment></comment><comment><USER24> Proving that one (or something) can drive is a far cry from proving that one can safely drive in a wide variety of changing conditions around other drivers. I would however argue that many people don't actually possess the latter ability, and I think 'robots' will get there before we as a species do.

</comment><comment><USER25> Putting what everyone is saying more abstractly; solving a constraint satisfaction problem in a nice and closed domain should not make us surprised that it isn't as quick to deal with when lifted to an unbounded and messy space.

</comment><comment><USER26> It was common lore in CS grad school that there were self driving cars, funded by DARPA, driving around the CMU campus back in the 90s.

It was not as easy to look things up. I am glad this story is being told, but I'd love to know about the history and the early days.

<comment><USER27> There was one at CMU back in the 1980s, the NavLab. Autonomous vehicle with a crew of five. Three racks of workstations. Really, really slow.[1]

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

<comment><USER18> Compared to the cars in the background it is doing just fine speed wise!

</comment></comment></comment><comment><USER28> StartUp's most recent podcast episode is related:

[https://gimletmedia.com/episode/grand-challenge- season-6-epi...](https://gimletmedia.com/episode/grand-challenge- season-6-episode-7/)

</comment><comment><USER13> This video of the 2007 Urban Challenge has some excellent footage and questionable fashion choices: [https://www.youtube.com/watch?v=-xibwwNVLgg](https://www.youtube.com/watch?v=-xibwwNVLgg)

(I'd also like to mention my appreciation for Bloomberg for not only publishing such articles as this, but also for actually linking to other interesting content not published by them)

Edit: Another find down the youtube rabbit hole: [https://youtu.be/DkdESqML41g?t=3h47m30s](https://youtu.be/DkdESqML41g?t=3h47m30s) has 9 hours(!) of slow-motion robot tragedies.

</comment><comment><USER29> Always-connected self-driving vehicles in many ways seem like something that would be a dream come true for the government and intelligence/law enforcement agencies (not to mention the advertising companies currently developing some of those vehicles).

</comment><comment><USER30> I was just telling someone about this the other day. In college at UF, I produced dozens of video segments on engineering student projects, and the DARPA challenge was among the biggest deals, and that was now a decade ago. It wasn't on anybody's radars (so to speak). It's funny how even a little bit of progress suddenly flipped the concept into the popular imagination.

</comment><comment><USER31> In 2007 (when the first iPhone was released), it had been (at least) 15 years since "phones proved they could run apps" [1]. Knowing a limited version of something is possible doesn't tell you a lot about the road to commercialisation and widespread acceptance.

[1] [https://en.wikipedia.org/wiki/Smartphone#cite_ref- schneidawi...](https://en.wikipedia.org/wiki/Smartphone#cite_ref- schneidawind_8-0)

<comment><USER32> And proving that something is possible is far from proving that it is actually safe. 15 years after kittyhawk aircraft were widespread and common, but still deathtraps by our modern standards.</comment></comment>


A Frog That's a Living, Breathing Pac-Man - <AUTHOR> http://www.nytimes.com/2014/08/25/science/a-frog-thats-a-living-breathing-pac-man.html?ref=science

<comment><USER2> OK, interesting article and all, but what in the world did that have at all to do with Pac-Man?

I mean, the article even comes straight out and says the frog doesn't move a lot. Pac-Man literally _cannot willfully stop moving_.

It's like if they did an experiment about canine jaw strength with the researcher's dog named Jabberwock, and the article's title was "This dog is a real-life Jabberwock!"</comment>


My Must-Have iOS Apps, 2015 Edition - <AUTHOR> https://www.macstories.net/roundups/my-must-have-ios-apps-2015-edition/ <comment><USER2> The most interesting takeaway from this list for me was the revelation that developers can use iTunes affiliate links to reduce Apple's cut of their App Store revenue from 30% to 23% for certain purchases.[1] The affiliate gets a 7% commission for every purchase made within 24 hours on the same device from which the link was accessed.

(A cynic might think that could have been relevant to the decision to include as many as 50 apps on this "must-have" list.)

[1] [https://www.macstories.net/tutorials/a-comprehensive- guide-t...](https://www.macstories.net/tutorials/a-comprehensive-guide-to-the- itunes-affiliate-program/)

<comment><USER3> Regarding the 30% cut: iTunes gift cards are often available at a 15-20% discount, further reducing Apple's cut. That doesn't help the developer, but is an implicit marketing cost Apple is eating. Suppose the buyer used a 20% discounted gift card and is buying through an affiliate link, Apple operates at around 3% for that sale while the developer still gets 70% from the full price ... and most likely, the retail channel wants a cut from selling the gift cards as well.

</comment></comment><comment><USER4> I am not a heavy iPad/tablet user. Scrolling through the list made me think the author might benefit from a laptop/tablet hybrid as a lot of apps are for automation/desktop environment that laptop OS already provides.</comment>