Ask HN: Is Facebook Graph API ready for production use? - <AUTHOR>

Have been looking at the Facebook Graph API and having some major problems. A lot of the API documentation appears to be wrong (the first example on http://developers.facebook.com/docs/api doesn't generate the JSON it says it should) and some of the code generators generate code that just doesn't work (http://developers.facebook.com/docs/reference/plugins/like-box).<p>Have hacked around and managed to get things working but unsure if I should use in production - would appreciate any thoughts & experiences. <comment><USER2> Currently Facebook broke all APIs, either Graph API, Old RESTful APIs and FQL.

I don't know the frontend part. My company uses Facebook's javascript library and we are switching to the new Javascript SDK.

One of the big bugs in Facebook backend is here <http://bugs.developers.facebook.com/show_bug.cgi?id=9758></comment>


You want fries with that?  Or, Software is Hard - <AUTHOR> http://blog.alieniloquent.com/2010/01/27/you-would-like-fries-with-that/

<comment><USER2> Mathematicians never complain that "this crusty-ass math is over _thirty years old!_ " Or writers: "OMG, English is really old. Can't I use something newer like Esperanto?"

<comment><USER3> Well, they would if we stopped using functions. Functions are relatively new as mathematics goes, and mathematicians would complain if they had to read Newton's original formulation of calculus.

</comment></comment><comment><USER4> Is it my imagination, or does this article suddenly stop just before getting to the meat of its argument?

<comment><USER5> I was quite curious what modern languages the author was referring to, wondering if I had missed some magical language boat that left without me.

</comment></comment><comment><USER2> Software is mathematics: <http://www.groklaw.net/article.php?story=20091111151305785></comment>


No bribery needed to go to George Mason, a university of strivers, not schemers - <AUTHOR> https://www.washingtonpost.com/local/no-bribery-needed-to-go-to-george-mason-a-university-of-strivers-not-schemers/2019/03/14/823c9e30-463c-11e9-90f0-0ccfeec87a61_story.html <comment><USER2> George Mason University seems to have been home to many climate deniers. [https://www.desmogblog.com/george-mason- university](https://www.desmogblog.com/george-mason-university), [https://www.desmogblog.com/global-warming-denier- database](https://www.desmogblog.com/global-warming-denier-database), and so forth. The same folks seem to have been involved as pro-tobacco and pro- vaping. George Mason may be a university of strivers, but some of the strivers appear to be rather slimy.</comment>


UChicago to Commercialize Hoffmann's Generalized Software Optimization Framework - <AUTHOR> https://news.crunchbase.com/news/learn-observe-control-uchicago-commercialize-generalized-software-optimization-framework/ <comment><USER2> Scientific American reported on this in 2011 [1]. But the application seemed much more limited than how it's being described in this Crunchbase piece. Has the technology advanced that much or is the latest reporting off?

[1] [http://www.cs.virginia.edu/~robins/World_Changing_Ideas_Dece...](http://www.cs.virginia.edu/~robins/World_Changing_Ideas_December_2011.pdf)

<comment><USER3> It's advanced quite a bit, and the article references some of the latest advancements[1] just published.

[1] [https://people.cs.uchicago.edu/~hankhoffmann/autoconf.pdf](https://people.cs.uchicago.edu/~hankhoffmann/autoconf.pdf)

edit: disclaimer - I'm working with the University & Dr. Hoffmann on this, but have also replicated (some) of the results in earlier papers.

</comment></comment><comment><USER4> > In a complex system with many layers of subsystems, having [Optimization > Framework]s all the way down the stack would make the whole system run more > efficiently.

Pretty extraordinary claim. Does the law of diminishing returns somehow not apply here?</comment>


REPL Driven Design - <AUTHOR> http://blog.cleancoder.com/uncle-bob/2020/05/27/ReplDrivenDesign.html <comment><USER2> Bob Martin is myopic in his view of software, in a way that I think is harmful to teams and the industry.

It is my experience that good software comes from teams working together well, teams that are in some sort of harmony with each other AND the system they are building/using. They understand it and each other. Good software is not derived from a singular technique.

I do like test-first approaches when I can, I like SOLID. I probably agree with Bob on a lot, actually. I think they are good techniques to employ.

However, it has not been uncommon in my career to find people (and myself) getting dogmatic about these things and arguing over them. There are half baked attempts to change everything to an Entity. There are flaky test suites with a lot of mocks because someone is hot on TDD, but does not have the bandwidth to maintain the suite for the whole team.

This blogicle is another example. As pointed out by other posters, REPL driven development can fold VERY well into a test driven workflow. However, that's not enough, he's actively saying it's not as good and you need to do The One True technique.

<comment><USER3> I think Bob is a very insightful person and has great intuition and probably more experience than any of us. Sure he has certain bias towards certain things; who doesn't really?

Saying that his posts are harmful is a bit of a stretch.

<comment><USER4> _I think Bob is a very insightful person and has great intuition and probably more experience than any of us._

Why on earth would you think that?

 _Saying that his posts are harmful is a bit of a stretch._

Mentor your first few people who keep defending rookie mistakes with "But Uncle Bob said..." and you might change your mind about that.

Bob Martin says some sensible things, but he also says some things that are at best debatable and at worst outright contradicted by the evidence base, and he says all of them with great conviction and presumed authority so that his target audience can't tell the difference. That alone makes him dangerous as a source of advice.

</comment></comment></comment><comment><USER5> There's no reason for this, and it bothers me enough that I'm doing something about it.

A (series of) REPL commands is just a test, where acceptance and rejection is manual: we look at the output, and keep changing the code until we get what we want.

At which point, we should be able to say to the REPL: yes, this result is correct, this is a test, and it's now called "Thing does what I want when I give it X and Y".

The runtime then saves this as a test, and will run it automatically when you ask it to. If there's a regression, it will boot back up into the interactive REPL so you can inspect it and fix it.

I've been writing a REPL. Turns out that's a lot of work, but I'm getting to the point where I can add this feature, which is the last one I really want to add before I go public with this thing.

<comment><USER6> The trouble is that for the repl "test" to be reproducible, you don't just need to store the relevant commands and result, but the full state/history of the repl. Since the point of a repl is to explore and experiment, it seems like your tests would end up with a lot of noise in them... but perhaps there are ways to get around this? I agree the concept of quickly converting repl sessions to tests is very compelling.

<comment><USER5> yes, there's a lot to it!

I store the complete repl history, complete with results and session metadata, in a database.

Pruning a session's history down to only what's needed is a manual process, true, and laying the groundwork to provide that feature has been the main yak shave.

<comment><USER7> > ...manual process, true

Before I get to my _real_ comment, I guess a fair criticism of it would be "Well, where in the [development process] hierarchy do you actually want to live?", which I guess is a longer discussion, but as a developer, you can't become battle-hardened without going to battle. So we can nod to Carl Sagan[0] and say "I made this from scratch", and know there's value in that. At least occasionally running your REPLs by hand and taking the actual trip, instead of just wanting the destination. It may not be tenable as a full-time production development strategy, but that doesn't mean it's worthless.

[0] [https://youtu.be/7s664NsLeFM](https://youtu.be/7s664NsLeFM)

</comment></comment></comment></comment><comment><USER8> Just to be fair, I don't think many practiononers of REPL-driven design would consider it a replacement for tests. It's an alternative workflow to TDD, yes, but the idea is that you still write comprehensive tests, they're just usually at a higher more system-y level than the ones you get from TDD.

<comment><USER9> Yeah I agree. It almost feels like he's making the argument in bad faith, but maybe he's actually unaware of the way in which you can back-fill tests?

<comment><USER10> It does come off very strangely dichotomic. As though REPL driven means no tests and bad practices, whereas TDD means tests and good practices?

As an idea, maybe we could do... both? Explore at the REPL, and then commit to tests and clean up once you've solidified your approach (i.e. how most Clojurists likely operate).

<comment><USER11> I think TDD purists seem to see no point in unit tests that are not written before the code. That is, if the unit tests were not used to drive the design and implementation of the code under test, they are useless. I find a lot of value in the test driven approach, but this purist view does not make sense to me. I sometimes, or often, write the code first (being able to do so in a repl in languages that support that is even better), when I find it easier to think through the problem in terms of implementation rather than expected output. Sometimes I will then comment out the code and begin writing tests and re- writing the code to pass them. I think that's what he should have done here; he could have benefited from playing around in the repl, but reduced his fear of refactoring later on by having the tests.

</comment></comment></comment></comment><comment> phoe-krk This is a PEBKAC, not a problem with REPL-driven development. He had all the test bodies written as input in the REPL, he had all the test results printed as output in the REPL. Why didn't he turn these into unit tests as he programmed?

That's a simple lack of foresight on the programmer's side that is then blamed on the tools that were used.

</comment><comment><USER12> _Clean Code_ was one of the first books I read professionally, and I'm glad I did. Since then, I've formed the opinion that "Uncle Bob" sometimes (as in this case) takes helpful ideas a bit too far. But I'm still open to correction.

Does anyone know of an open source codebase he's written or been a major contributor to? I know he writes a lot _about_ clean code, but I've never seen production code from him.

<comment><USER13> Clean Code is extremely overrated and it's hard to get justifications for the recommendations anymore.

Pretty sure he hasn't written prod code in over a decade.

<comment><USER14> Yes, especially where he goes completely overboard creating extremely small functions. Most of them are, like, 2 lines....

The general point that code should be clean is a good point to make. Writing a whole book about it seems a bit much.

<comment><USER13> >Yes, especially where he goes completely overboard creating extremely small functions. Most of them are, like, 2 lines....

Yup which is why we have millions of npm packages that do literally one thing.

<comment><USER15> Two completely different things. A npm package is a module of code. A function is... A function. Having a lot of small functions is helpful as it builds up a vocabulary in the codebase, so instead of having to understand every single line each time you come across it, you can extract the meaning into a name.

What the npm ecosystem is doing is a completely different thing.

<comment><USER16> >so instead of having to understand every single line each time you come across it, you can extract the meaning into a name.

Until you really have to understand what is going on, like when you need to fix a bug or refactor. Then suddenly you to deal with the overhead of holding the branches of 20 levels of indirection in your working memory.

Also, this assumes the people you're working with are _great_ at naming things. Which, from my experience, is almost no one.

<comment><USER15> In general, we have higher-level programming languages so we can do just this, hide the complexity under indirection. It's basically the purpose of the languages we tend to use today, otherwise we would all be still using assembly.

Your job as a programmer is being able to walk this ladder of indirection up and down until you find what you seek and fix/add/remove whatever.

You'll always be dealing with way more than 20 levels of indirection when programming, even with a "hello world" program. If adding two more levels of indirection makes your mental model break down, you might consider upgrading your environment/workflow a bit to support this.

Regarding naming I agree with you. Good names are really, really, really hard to come up with. Entire books have been written on how to name things. Doesn't excuse us from trying though, the only way we can get better is by doing.

</comment></comment></comment></comment></comment></comment></comment><comment><USER17> This feels like a straw man. Or maybe a false dichotomy. I think it's entirely possible to ensure code is testable before writing the test. It's also not unusual to tinker in a repl before encoding the functionality as a test. Pretty let down by this post.

</comment><comment><USER9> His argument feels like a straw man. You can and should fill in a few tests after you confirm something in the REPL. Maybe Clojure folks don't do that, but Ruby and Elixir devs often do. I would imagine he's familiar with that approach.

<comment><USER18> Clojure folks do that. Don't know about all of them, but lots of them do. You even have emacs cider shortcuts to run tests from a live repl.

<comment><USER19> I literally wrote code in .clj files and then my editor can slurp that up and barf it into a repl. There was never a point where I was writing something that "only existed in the repl" such that I couldn't just put it in a unit test if it needed formalized.

The usual workflow was something like

        (comment

           ;; experiments go here
           (defn add [a b]
             (+ a b))

           (= 2 (add 1 1))
           (= 3 (add 1 2))
           (= 99 (add 9 90))

        )

Once you have what you want, you move the code out of the comment block. Whether you move it into a library or a test file is just dependent on the type of thing you're moving. Functions moved into library code. The samples that proved the happy paths (or unhappy paths) would go into test files using `clojure.test/is` (and typically a direct copy/paste).

</comment></comment></comment><comment><USER20> This was the programming model I learned on the lisp machine and Common Lisp: define a few datastructures and some operations on them, explore them with some live data, and expand. All iteratively at the REPL.

A few years later a friend referred to this dismissively as "Programming by successive approximation."

There is a lot of truth to this, but the distinction isn't as sharp as it sounds: you still have to think ahead, and as you explore and expand you've typically always got something working, some test cases and invariants, and typically you have the benefit of working on live data.

Even though I do most of my work in compiled C++, my work model isn't that different.

<comment><USER21> You can use ROOT (or cling standalone) as a C++ REPL if you want to. It works surprisingly well, at least until you segfault it.

<comment><USER20> Thanks! ROOT itself looks interesting too.

</comment></comment></comment><comment><USER22> Is this just the equivalent of saying "Hey, REPLs are nice when you're trying to figure something out", but spouted off as some deep programming wisdom?

Like, folks... REPLs are really nice when you want to figure out how a function or module or whatever works. Then yeah... you can take that knowledge you gained and apply it to your work.

Like.. how is this a deep profound revelation for folks?

</comment><comment><USER23> I think there's a big distinction in the general developer population between:

a) Knowing both how to effectively write tests & how to effectively use a REPL.

and:

b) Knowing only how to bang around in a REPL enough to use it as a crutch to avoid writing any tests.

<comment><USER24> When you say "use a REPL", do you mean something like CIDER/SLIME, or do you mean something like ipython/irb? I do REPL (that is: CIDER) driven development all the time, and most of my experiments turn into tests quite naturally.

<comment><USER25> The distinction is a bit artificial. I agree that Python's REPL is underpowered when compared with SLIME. But it's trivial to write up a bit of Python code in an editor, and just 'reload(modname)' or 'exec(file(...).read())' from the REPL. Emacs' python-mode (like many other editors) also supports "evaluate this expression / line / block" to make this process simpler. YMMV, but my Common Lisp development really doesn't look very different from my Python work.

<comment><USER24> Even if we stipulate that's true[ _], saying you could do it in non-Lisps doesn 't detract from the observation that virtually nobody actually does it, while both groups still call it "REPL".

[_] I really don't think it is: reload(mod) comes with way more caveats than C-c C-k in CIDER.

<comment><USER25> How could you possibly know that "virtually nobody actually does it"? I have no reason to believe that I'm a special snowflake. 'reload' and 'exec' exist for these very purposes, and have been around since Python immemorial (well, at least since I started using Python 20 years ago). As for the 'caveats': if you're using 'reload' in your development process -- yes, you should take a few moments to read the documentation first, as you should with anything else. It isn't magic, and its behaviour is well explained.

You're making far too much of the distinction between different kinds of REPL. As Peter Norvig put it [1], as long as you have a "development process that allows for rapid development with continuous improvement", minor distinctions between languages [such as quibbles over how 'reload' works] really don't matter that much.

Squeeze all the power out of the tools that you use, and get things done -- ultimately that's all that matters. Religious wars like these were tiresome in the era of the Smug Lisp Weenie, and they haven't improved with age.

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

<comment><USER24> I made a distinction between CIDER/SLIME (which I think is what most Lisp users think of when they hear REPL-driven development) and ipython/irb/iex..., which I think is what most Python/Ruby/Elixir/... programmers call "REPL" in REPL-driven development. This distinction is important, because much of the criticism in these threads has been around how you translate REPL-developed code into saved-in-files code. If I'm using, say, Jupyter Notebook, I'd say: yes, that's exactly an issue I've had and can immediately identify -- but with my CIDER "REPL-driven" flow, that's not an issue at all. You don't need to declare superiority of one to observe that they are different. I am pointing out one highly contextualized advantage, yes, but I did not anoint CIDER the One True Way. There are advantages to Jupyter Notebooks compared to REPL- driven development too. I think calling my commentary a "religious war" is unnecessarily inflammatory.

You ask how I could know that: I have used Python for a similar amount of time as you, and have been a Fellow of the PSF for about a decade. During that time I've attended dozens of PyCons across the world. My wife is the Executive Director of the PSF, so I've been the second person in and the penultimate one out for most of those PyCon USes, including the post-conference sprints. Previously, I was the Freenode group contact for and one of the most active contributors to #python. I've worked with a lot more Python programmers than most, and typically meeting them where _they are_: either pairing next to them or over IRC. People from all over the world and different experience levels and backgrounds. People who lived and breathed Emacs and are definitely aware of how SLIME/inferior processes work. I can't recall a single instance where someone said "eval this in a REPL" and the other party did that by calling reload() or exec from an editor. The vast majority of times someone mentioned reload(), it's been someone who built a long-lived process like an IRC bot, with hot code reloading via reload(), being confused that reload() "didn't work" because they kept seeing the old behavior. YMMV. This is all anecdata, sure, but I observe that IPython 5 casually broke inferior-shell compatibility and somehow that made it to release. It's possible that there are huge swathes of people who do write their own "trivial" reload()/exec integration, but that feels like the stronger claim to me than "there may be confusion here between what users of these languages typically mean when they say REPL".

I want to make sure I understand your argument correctly. Starting with the strongest form of the argument: are you saying you believe most Python/... programmers think "REPL" means "something involving reload" and not, say, ipython? I assume we can agree that seems silly, but perhaps not: and I think that's closest to directly refuting my claim. Unless I'm misreading your comment: I'm saying "different groups use this term to mean different things", and your comment is "come on they are practically the same" (ok, fine, we can disagree!) and "you can do reload()!" (sure, but I didn't say it's impossible, I said that's not what people generally mean). So, perhaps a weaker version of your argument: you're saying you think some nontrivial amount of Python users use a reload/exec-based editor integration? Enough that "REPL" is not suddenly a confusing term? So, something like what, 20%, 10% of users?

<comment><USER25> Fair point about my religious-war comment, and I apologize. I was probably deserving of the Smug Lisp Weenie label at one point in my career, and for whatever irrational reason your comment sparked those memories. (For what it's worth, while I don't use Clojure any more (and stopped before the CIDER days) I'm fairly familiar with the language -- I was even a core contributor for a brief shining moment. (I think my contribution was the :as clause in (use) statements. The old (use) clauses used to be horrendously long. No doubt that my code has been replaced 10 times over by now.)) At any rate, it was foolish of me to try suppressing a religious war by inciting one.

As for my argument, I think it was in two points. First was to challenge what evidence you had to support your claims. From your reply, I'm confident from that you're speaking from knowledge of many developers' experiences. Perhaps I am more of a special snowflake than I realized.

As for the second point, I'm basically restating Norvig's argument, as I think it's a good one. I'm not terribly concerned about distinctions between different REPL-ish tools. I do take your point that the distinctions can muddy conversation, e.g. when trying to relate experiences of (say) Jupyter users vs. `python-mode` users -- or worse, Lisp vs. Python.

But to paraphrase (co-opt?) Norvig, I think these are second-order differences. Important enough in a few contexts, but distracting in most. My thesis is simple: everyone should experience interactive programming, and should ideally incorporate it into their development process, because it makes development faster and more effective. Whether that means Jupyter, CIDER, SLIME, ghci, etc. is a local decision, based on where you're at and what your community is; I don't think "REPL" in particular is a special shibboleth of the Enlightened. The difference between the Java/C++/Rust set and the Python/Ruby/CL/Clojure set is far greater than any minor differences we might have within the interactive camp, and "internal" disagreements in front of the unindoctrinated tend to distract from the greater good, IMO.

Any way that we can help new developers to experience interactive programming is a positive step. Personally I think _that 's_ the first-order problem, and I think our collective, repeated failure to recognize that is a source of much pointless and religious argument. Perhaps that's why this conversation reminded me of those wasted days, and why I responded with more aggression than I should have.

<comment><USER24> Apology accepted: I completely understand why a reasonable person could infer those things, especially since I'm hardly a neutral party given that I founded a Clojure nonprofit--"partisan" would be an entirely fair assumption :-)

I also happily stipulate that non-Lisps not working that way is largely praxis and not some fundamental language deficiency, and definitely strongly agree that interactive programming is a powerful tool we should get into more hands.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER26> Bob Martin, who is quite opinionated, has been brutally wrong about some things. For example, there was a TDD attempt to solve Sudoku that failed. Uncle Bob was following this, and said of the failure "At least he had the courage to post his failure".

More interesting would be a correct solution, which was posted by Peter Norvig. The approach he uses is drastically different that anything TDD is likely to get for you.

TDD isn't going to find solutions to hard problems beyond bowling.

There is a stark contrast between agile development and actual software engineering. Agile works where the customer and the developer don't really know what is being developed.

And as much as he has lectured about software development, I don't get the feeling that he has actually developed a substantial quantity of serious software.

In one of his clean coder books, he argues that Java is not object oriented. Unclear if that is a widely-held opinion. If you look for serious high-quality software, they are not agile. Such as the software for the space shuttle, or qmail, or other formally-verified software.

I have a friend who worked with him and it was sort of Uncle Bob's way or the highway.

</comment><comment><USER27> This is sort of like how I develop using Jupyter notebooks. Write code in the notebook until I get a function / component correct. Copy it into a module. Restart the kernel and import the module. Rinse and repeat.

<comment><USER28> Yup, a notebook is a REPL with better scrollback + the ability to take notes alongside your code.

<comment><USER29> Except unlike a REPL, all your code is still there so that you eventually find yourself in an unreproducible state that on the surface looks reproducible. Referencing variables that don't exist in the notebook (only to be caught when run by someone else), cells that need to be executed out of order, etc. The problems go on and on. People sometimes go days or weeks without restarting their notebook and the amount of "shadow" state is remarkable.

I think notebooks are useful (though only for exploratory analysis), but there has to be a better way.

<comment><USER30> Part of the problem is discipline and avoiding anti-patterns. It's unfortunate that Jupyter encourages this kind of inconsistency to creep in, leaving it up to the analyst to maintain top-to-bottom "runnability".

</comment></comment></comment></comment><comment><USER31> That's the similar to the issue I have with coding in (Jupyter) Notebooks. It _feels_ productive, but it discourages modularity.

<comment><USER32> Not sure it really discourages modular code. I usually write code modularly in Notebooks as well, but not sure how this is for most people.

<comment><USER33> I suspect the problem is less that it discourages than that it does not encourage.

Which gets back to the posted article. REPL-driven development permitted him to feel confident without doing his usual process, it didn't _discourage_ decoupling, but it didn't _encourage_ decoupling either. TDD, to be done well, almost requires decoupling your code to make it more testable.

The same may (I'm not sure I agree, but I've never used Jupyter notebooks) be true of using notebook-styled development approaches and modularity. If the workflow permits relatively easy (and mostly safe) development without encouraging modularity, then it's incumbent on the developer to bring that discipline into the workflow.

<comment><USER31> And unfortunately, most of the new crop of programmers don't have that discipline. I tell them to write tests and they eyeroll when they think I'm not looking.

</comment></comment></comment></comment><comment><USER34> I rarely use REPL driven development, however in my limited experience using it, it only makes integration testing faster, not unit testing.

I used this methodology with a Slack bot, because doing integration testing with Slack is annoying when I'm not directly testing the Slack communication portion.

For example: [https://github.com/cjsaylor/chessbot/blob/master/cmd/repl/ma...](https://github.com/cjsaylor/chessbot/blob/master/cmd/repl/main.go)

Edit: It seems like there are a lot of comments surrounding him "abandoning" TDD. Not only did he not do that, he literally says in the conclusion of the article that he would not recommend doing it.

<comment><USER15> What languages have you tried REPL driven development with? As far as I know, Golang doesn't have a REPL that is connected with your editor so you can evaluate inline code and Golang is not made for REPL driven development either, so you have bunch of implicit state and you can't overwrite function definitions at runtime either.

I think you need to have a language (or structure your particular program in a way) that is really made with live-coding in mind for it to actually give you any benefits, like Smalltalk or Clojure and similar. Otherwise it's just adding another step to reach the real program you're running.

Edit: using your example as an example here, hope you don't mind. A program made with REPL driven development would have way less code in the main function, in order for you to test the code outside with your REPL. The `StoreGame` function would accept a data-store + the argument you have now, so at development-time, you can pass it arbitrary stores. And similar changes.

<comment><USER34> I don't mind the criticism at all. I don't use it often enough to claim expertise. Fair points about my usage.

You can still get proper editor support with Golang (even though it isn't designed for it). I've done so here with VSCode working with a "remote" delve session: [https://github.com/cjsaylor/chessbot/blob/11e1059aa77fed84d2...](https://github.com/cjsaylor/chessbot/blob/11e1059aa77fed84d20f03ce2cad06bb87e313da/.vscode/launch.json#L7-L18)

<comment><USER15> Thanks :)

My point being, if you wanted to execute the following code: [https://github.com/cjsaylor/chessbot/blob/11e1059aa77fed84d2...](https://github.com/cjsaylor/chessbot/blob/11e1059aa77fed84d20f03ce2cad06bb87e313da/cmd/repl/main.go#L128-L132)

You probably wouldn't be able to, without restructuring how you're handling your state that is being used there. A REPL driven made program usually is made that the runtime carries the state and exposes it, so you could just select that part and run it, and see the output of it.

I'm guessing delve is more like a traditional debugger that steps through each line, rather than an REPL, correct?

<comment><USER34> Correct, but it does allow you to modify values in memory, so you could do the branching and state changes as you go. I admit I could have made that flow more "editable" from the debugger/REPL, however it did serve its purpose in terms of prototyping ideas before I integrated them into the real thing. I also do use it to debug weird state things of issues reported to me, which I do mess with the values at runtime with Delve to simulate.

I may be misunderstanding the "true" REPL development here, but I think the points laid out by the article seems to match my experience to a degree.

<comment><USER15> That's interesting, didn't know that! Thanks for sharing. I don't think there is anything that is more "true" than something else, it's just varying degree of personal productivity and in the end we all work very differently, so one size does not fit all. I'm glad you're sharing your thoughts with me and seems to be similar to the REPL environment I'm running myself.

<comment><USER34> I looked into this subject a bit more deeply in regards to Go, and you are right. Go doesn't have a REPL built in, and most of the implemented REPLs only work off of stdin. So, the Clojure style of REPL development is not as straight-forward in Go. However, it does seem like one of the userland REPLs could be adapted to work with an editor (like vscode) if the input source wasn't locked to stdin.

It seems like a ripe target for an opensource library to accomplish this. I may explore this later on when I have more time to devote.

</comment></comment></comment></comment></comment></comment></comment><comment><USER35> Some people really can't stop making up new terms.

<comment><USER36> Some people really can't stop discovering new concepts?

</comment></comment><comment><USER37> You still write tests in any non-trivial Clojure codebase, and you still probably do REPL-based development for some parts of that project.

And if you're doing both of those things above, then you almost certainly run some or all of your tests WHILE doing REPL-based development from your always- on REPL. In fact, that's one of the best ways since you don't suffer the JVM startup cost.

</comment><comment><USER38> Im not sure I agree with the conclusion.

Why not compose with the repl, then write tests at the end?

The common fear hear is that "you be motivated to write the test, or the test will be less good"

For motivation I never found it to be a big issue, and for the quality of the test, writing it after often produces better results. You get more time to think about _what and how_ you want to test

</comment><comment><USER39> Using a REPL has been critical for me to develop any meaningful software (more than tests and more than types). I always wanted to be able to take a portion of my REPL history and transform it into a test, instead of basically rewriting it (lazy, I know).

</comment><comment><USER40> > So I've learned my lesson. REPL driven development feels easier and faster > than TDD; but it is not. Next time, it's back to TDD for me.

 _In the long run_ it's not faster. However, the feature he was using REPL driven development for did ship faster. That's a valid tradeoff to make, as long as you're doing it consciously.

</comment><comment><USER41> What's the difference? And why does executing commands (even if you're actively developing the code they execute) in a terminal need a new name?

Isn't this just... _using_ a computer?

I don't know; maybe I missed something.

<comment><USER42> It needs a name so that we can have this discussion and compare and contrast different methodologies.

For example

* Compile run debug. You write some code potentially with tests. Run it and either poke it manually or run tests to see what it did. If it didn't do what was expected you either edit it, write some more tests, add print statements, add break points or whatever and try again.

You are forced to create all state in one go and pay one complete edit build debug cycle for each thing you want to modify in isolation. This could be 30 seconds or hours.

* Minimal interactive development. You mostly write code as above but gain the ability to poke individual functions or pieces of functionality in order to aid your understanding when things don't work correctly. You write tests eventually or not.

* Repl driven development. You mostly write and interact with a live environment either by actually typing the code in a repl or writing it into a source code file and hitting a shortcut to evaluate as you make changes redefining it piece by piece in terms of the rest of the code and the state you have built up by prior evaluations. This persistent state and the ability to redefine parts of it are what separates it from writing some python and occasionally opening up ipython to poke the code.

</comment></comment><comment><USER43> I always have a REPL open when I am hacking. iPython is a great replacement for the vanilla Python one, and Pry is great for Ruby.

Being able to poke and prod at a system is priceless for debugging and introspection.

</comment><comment><USER44> Literally an anti-hacker. Not sure why his writings get upvotes here

</comment><comment><USER45> Do both? Lot of manual and automated testings?

</comment><comment><USER46> It's not REPL-driven design, it's REPL-driven development. You don't design by driving a REPL, that would be stupid. It seems Bob has lots of misconception and is blaming his poor design on the REPL. Haven't read such a hollow article in a while.

<comment><USER26> I agree with hollow.

But TDD is not design either, in my opinion.</comment></comment>


Google Private Key Compromise - <AUTHOR> https://twitter.com/ecctls/status/980607899188842496 <comment><AUTHOR> It isn't real [https://medium.com/@ECCTLS/how-to-sign-with-googles- private-...](https://medium.com/@ECCTLS/how-to-sign-with-googles-private- key-5b8e99abcdb3)</comment>


iPhone Is Already Made in America - <AUTHOR> https://www.bloomberg.com/opinion/articles/2019-06-12/apple-s-iphones-are-already-made-in-u-s-not-china <comment><USER2> "It wouldn't take much for Apple Inc. to have U.S.-sold iPhones made outside China."

Like it wouldn't take much to move TV manufacturing back to the USA in the 90s. But that did not happen. I think there is one TV maker in the US left but the vast majority is made elsewhere and there is "nothing special" about the ones made here.</comment>


Show HN: GitHub special files and paths (README, LICENSE, .github, /docs, etc.) - <AUTHOR> https://github.com/joelparkerhenderson/github_special_files_and_paths <comment><AUTHOR> Summary of GitHub special files and paths:

README LICENSING CONTRIBUTING CODE_OF_CONDUCT etc.

/.github /docs /ISSUE_TEMPLATE /PULL_REQUEST_TEMPLATE etc.

<comment><USER2> > LICENSING

What about LICENSE and COPYING ?</comment></comment>


You wake up lighter than when you went to sleep. Here's the data - <AUTHOR> https://medium.com/@OmadaHealth/just-breathe-255b744ca06b#.apah7peyu <comment><USER2> Nice experiment and data, happy to read this. The general idea is right, but some of the technical explanations are wrong.

> _The fat from our food gets stored in our bodies as a compound called > triglyceride. What's triglyceride, you ask?_

Actually, most of what we call fat are just triglycerides, there are many kind of it, it's a family of molecules:[https://en.wikipedia.org/wiki/Triglyceride](https://en.wikipedia.org/wiki/Triglyceride) . (And some of the food is stored in other forms, like glycogen: [https://en.wikipedia.org/wiki/Glycogen](https://en.wikipedia.org/wiki/Glycogen) )

> _Indeed, more googling suggests we release somewhere around 20 mg of water > and 36 mg of carbon dioxide per exhalation. [...] we breathe out about a > pound of the stuff formerly known as dinner (and lunch, and breakfast, and > snacks) while we sleep!_

Actually, part of that mass comes from the oxygen in the air, that is used to burn the food, so that part has to be discounted. (I guess it's something like 75% of the mass from the food and 25% of the mass from the oxygen of the air, but I have to make the calculations carefully to be sure.)

</comment><comment><USER3> Of course you do. When we sleep, we break chemical bonds, releasing energy. We burn like candles.

Well, actually this happens at all times, but it's most dramatic when we're not eating. And hopefully that's what's going on while most of us are asleep.

<comment><USER4> Yes, but releasing energy through chemical bonds is not the phenomenology of losing weight. It's all about particles in, particles out.</comment></comment>


DHS warns of 'strong concerns' that Chinese-made drones are stealing data - <AUTHOR> https://www.cnn.com/2019/05/20/politics/dhs-chinese-drone-warning/index.html <comment><USER2> Sounds like a great weekend project for a bored hacker: Buy a Chinese drone, run a packet capture, see what it tries to send and where. For bonus points, put a logic analyzer on the PCB, dump the ROM, try to isolate the code that's doing the sending and reverse engineer it.</comment>


The HARC First Year Report - <AUTHOR> https://harc.ycr.org/reports/ <comment><USER2> It is my understanding that HARC has stopped funding Victor's [1] and Hart's [2] research.

Is that accurate? Have other groups in the list suffered from the same fate? If so, how does that fit within HARC's long term research strategy? These sort of initiatives rarely bear fruits in a single year.

[1] [http://elevr.com/elevr-leaving-ycr/](http://elevr.com/elevr-leaving-ycr/)

[2] I was at Dynamic Land earlier this week, and they said they were closing down for the winter, actively looking for funding, and not reopening if they cannot provide said funding.

<comment><USER3> I'm struggling to see how why Dynamic Land would be no longer be funded by HARC. Doesn't it fit the HARC goal of: "HARC's mission is to ensure human wisdom exceeds human power, by inventing and freely sharing ideas and technology that allow all humans to see further and understand more deeply."[1] pretty well?

Maybe HARC is just a year-long thing? If so Bret/Dynamic Land team can you please put up a Patreon account and let us fund you. I will gladly give money to you as it is the most human form of computing I have ever seen and would like progress on it to continue.

[1] [https://blog.ycombinator.com/harc/](https://blog.ycombinator.com/harc/)

</comment></comment><comment><USER4> Realtalk/Dynamicland is fascinating to me, though there's something about it which I haven't been able to get over, which is: how can it provide the kind of generality we're used to in computing without giving some set of re- combinable primitives? In other words, something like pixels where the primitive thing is simple and easy to configure algorithmically, and yet the range of configurations is vast enough to represent a large fraction of human imagination.

I love 'being in the world' as opposed to sitting statically at a desk—but I would need something that could give me the similar feeling of vast possibilities when I consider what I'd like to build next.

I wonder if some kind of re-combinable primitives for representation are part of the plan, or if it's an explicit aim of the project to avoid them—a kind of stance against abstraction, reduction, and uniformity. That's part of why it's so fascinating to me: I can't see a general enough system being built without that—but if it were to succeed, I'm fairly confident it would be one of the most interesting systems I'd ever encountered :)

Edit: I should add: this is from what little I actually know about it. I've just seen a few few videos, read the blurb from the article, and read another article on the laser socks project which talked some about Realtalk.

<comment><USER5> Highly recommend Bret's 2 talks for context:

[1] Seeing Spaces: [https://www.youtube.com/watch?v=klTjiXjqHrQ](https://www.youtube.com/watch?v=klTjiXjqHrQ) [2] Humane Representation of Thought: [https://www.youtube.com/watch?v=agOdP2Bmieg&t=1913s](https://www.youtube.com/watch?v=agOdP2Bmieg&t=1913s)

<comment><USER4> I saw them both a while back, and reviewed the poster for Seeing Spaces just now. However, I haven't been unable to find anything that addresses the issue I brought up.

I agree very much with most of the general principles Victor talks about (you can see my own extensive work on making program behavior visible here[0] for example)—but when it comes to the space concept, I have difficulty finding something _concrete_ about how the space would be used beneficially. I get the flavor of this idea that your workspace should be 'extension of your body', but at this point, years after becoming familiar with it, I'd like to get more concrete on the subject. Dynamicland/Realtalk certainly are more concrete—but my thoughts on it are reflected in my first comment.

[0] [http://symbolflux.com/projects/avd](http://symbolflux.com/projects/avd)

<comment><USER6> visit and donate. they need help.

it's foolish to speculate on the possibilities of a new medium on this extraordinarily limited medium. i can't even embed images here.

<comment><USER4> I'm pursuing similar lines myself, and am only able to work in spare moments due to lack of funds, so I'm in no position to donate.

> it's foolish to speculate on the possibilities of a new medium on this > extraordinarily limited medium

I'll be happy to be shown otherwise, but I haven't yet found any counter- example to the idea that the 'verbal medium' is sufficient to describe any principle. So my original question still remains: is there some principle which would allow them to achieve similar generality to traditional computing without using some kind of re-combinable primitives?

Edit: to be more specific: without that, how could this ever compete with AR? People could build their own spatially interesting, room-scale workspaces without having to find physical materials to build every application out of. The fact that it can deal with actual physical things has an appeal to it, but I can't see any way of escaping the tradeoff of a massive loss in generality.

<comment><USER7> > how could this ever compete with AR?

"How could the written word ever compete with pictograms?" It's a different medium with real benefits and tradeoffs. Right now for you it's all theoretical, but one day hopefully you'll be able to see for yourself if the medium has the time to grow, breathe, expand, and develop. Funding Dynamicland means that we as a species have the option of seeing how that medium might work if it was allowed to flourish.

<comment><USER4> We'll, I wish you guys luck and sincerely hope this removes some desk time from my life :)

</comment></comment></comment></comment></comment></comment></comment><comment><USER8> Looks like Bret Victor's paragraph was removed from the page? It still talks about "6 principal investigators" but lists 5.

<comment><USER5> Oh weird, maybe it's temporary? That's odd, it was just there a few hours ago.

<comment><USER9> Doesn't seem like an accident to me.

Here's the archive of the page before the edits: [https://web.archive.org/web/20171026233121/https://harc.ycr....](https://web.archive.org/web/20171026233121/https://harc.ycr.org/reports/)

<comment><USER10> Thanks for the link. In that paragraph (the one that was removed), there are two links to Bret's website and both of those are now 404 as well... what's going on?

[http://worrydream.com/HypercardInTheWorld/videos.html](http://worrydream.com/HypercardInTheWorld/videos.html)

[http://worrydream.com/oatmeal/realtalk-tech- teaser-2017-02-2...](http://worrydream.com/oatmeal/realtalk-tech- teaser-2017-02-25.mov)

<comment><USER7> I assume Bret just didn't want the work to be shown without context yet.

</comment></comment></comment></comment></comment><comment><USER11> Why did Vi Hart (the first PI listed) leave HARC? She posted a youtube video just this week asking for funding through patreon.

<comment><USER12> It was the Elevr team (four people) who lost funding. [http://elevr.com/elevr- leaving-ycr/](http://elevr.com/elevr-leaving-ycr/) Vi said they could continue for $15,000 per month but couldn't find any backers.

<comment><USER13> Interesting. Is there anything more to the story? Why were they accepted into HARC, and then let go after such a short period? Has this happened to other people funded by HARC as well?

</comment></comment></comment><comment><USER14> Where is Bret Victor?

> Here are year-end reports from HARC's six Principal Investigators.

Only 5 are listed...

<comment><USER15> That's weird. He was there before.

</comment></comment><comment><USER16> The Dynamicland Twitter account has a bunch of fascinating demos of their work so far: [https://twitter.com/Dynamicland1](https://twitter.com/Dynamicland1)

</comment><comment><USER17> Just a note that there is an unclosed quotation mark in the "physics" link in Vi Hart's section, causing it to not show and it also breaks the "hyperbolic space" link.

Incredible work from an incredible team! Not sure why Bret Victor's section disappeared.

<comment><USER18> Thanks!

</comment></comment><comment><USER19> If there is one common theme. Its "visual programming" ;)

<comment><USER3> While I know so many programmers are vehemently opposed to "visual programming" I wonder if we can make programming multimodal. Such as a programming language that supports both visual and text modes, where both are first class citizens to the language. This would allow us to use visual tools to see macrostructure; a place where text falls short. But still let us have our tools for the micro-editing that is modern programming. I know some work has been done in this area: [http://ravichugh.github.io/sketch-n- sketch/](http://ravichugh.github.io/sketch-n-sketch/).

<comment><USER7> > While I know so many programmers are vehemently opposed to "visual > programming" I wonder if we can make programming multimodal.

"Visual programming" so far as been about visualizing program's static structure. Scratch and Labview do this, and this has some advantages, especially for beginners. But there's never been much advantage in understanding program behavior from seeing its structure, and I think tools for understanding program behavior are probably the most effective way of making all programming better. See my project Flowsheets for some experiments in this space: [https://www.youtube.com/watch?v=y1Ca5czOY7Q](https://www.youtube.com/watch?v=y1Ca5czOY7Q)

</comment></comment></comment><comment><USER20> Wow. Bret Victor's stuff is so incredibly human, and so incredibly useful. I want it!

</comment><comment><USER21> Where is the cat videos website guy who was researching "new types of cities?"

<comment><USER22> He runs the show, so he doesn't need to submit any reports</comment></comment>


Freemium Model for Lawyers - <AUTHOR> http://www.metamorphblog.com/2010/01/dear-startup-lawyers-please-blog.html

<comment><USER3> This a very insightful piece, as I learned from experience when I began a while back to add useful content for startups to my firm's website. We are a smaller, boutique firm but have been doing startups for a long time in Silicon Valley. The giving away of "a little bit of your brain power" (as the author puts it) has done nothing but pay dividends.

The only quibble I would have is with the author's emphasis on this being an ideal way for young, unestablished lawyers to make a mark. This is a field in which much is gained by experience, and the expertise to be shared by a brand new or relatively inexperienced lawyer in this field is likely to be somewhat abstract and academic (e.g., what are stock options?) versus strategic and practical (e.g., what are optimum uses of stock options for startups in different stages?). Founders get sleepy-eyed reading abstract discussions of law but are very alert to practical discussions affecting their vital interests (e.g., on this site, I once posted a simple piece on "what it means to own x% of a company" and got thousands of visitors to my site).

For lawyers with some years of big firm experience, though, this is an excellent way to promote any new practices they might establish.

It would also be great if large firms used this method as well but the key to it all is being open and approachable and such firms tend to be somewhat closed. Maybe they will open up with time and a changing environment. Moreover, it is perceived to be inherently risky to "give away" your valuable techniques as a law firm and lawyers acting in large groups (such as are found in the large-firm partnerships), being cautious by nature, tend to set up lots of obstacles for any individual lawyer in the firm trying to share expertise in this way - in essence, everything goes through committees, which usually stifle such attempts.

In any event, this piece offers prescient insights about this subject.

<comment><USER4> Grellas, as usual, makes some excellent points. In my experience, businesses are very well served in securing legal services from a sharp, seasoned attorney.

</comment></comment><comment><AUTHOR> Thanks! I've spent the last week lawyer shopping for my startup SpeakerText (<http://speakertext.com>) and ran into a couple young, ex-Gunderson Dettimer lawyers who had started their own firm. They already had >5 years each under their belt and new what they were talking about. We had margaritas last night and even though I went with Wilson Sonsini, this was essentially the advice I gave them. More lawyers should do it, if you ask me.

<comment><USER5> So you told them to go blog about their practice and then went with the most established law firm for venture capital there is?

I think what people are missing here is the huge difference between interesting blog posts for founders etc and the real reason why everyone goes to Wilson Sonsini et al - because they have the reputation of being the best. Any VC guy will probably stick with the default option - #1 firm on reputation, because you just trust them to do the best possible job - <USER2> of taking risks with an upstart, who writes nice blog posts but where you have no clue to the quality of their work.

You can't "fail often, fail early" with legal documents. If you make just one important mistake, there are huge consequences. That's an important reason why people select for reputations on the legal market.

<comment><AUTHOR> True. But how do they become established and make a name for themselves quickly? I'd say starting a blog, fostering a community and doing it well is probably your best bet.</comment></comment></comment>


Quicksort is the new Hello World - <AUTHOR> http://blog.rmontanaro.com/2010/12/11/quicksort-is-the-new-hello-world/ <comment><USER2> This article is misguided.

Hello World serves two (and only two!) purposes:

        1. It's traditional
        2. It lets you check everything is working

It _isn't_ a way to evaluate or compare languages. How could it be? It only uses a very small fraction of the language. Note that the Hello World for C is rather long and inelegant. But C itself is definitely an elegant language. So its predictive power is poor.

QuickSort is neither traditional nor something a beginning programmer could use to check everything is working. Therefore it is not a substitute for Hello World.

\- - -

If you want to get a feel for a language with one code snippet, allow me to introduce the Trabb-Pardo Knuth algorithm:

        In their 1977 work "The Early Development of Programming Languages",
        Trabb Pardo and Knuth introduced a trivial program which involved
        arrays, indexing, mathematical functions, subroutines, I/O,
        conditionals and iteration. They then wrote implementations of the
        algorithm in several early programming languages to show how such
        concepts were expressed.

[http://en.wikipedia.org/wiki/Trabb_Pardo%E2%80%93Knuth_algor...](http://en.wikipedia.org/wiki/Trabb_Pardo%E2%80%93Knuth_algorithm)

        ask for 11 numbers to be read into a sequence S
        reverse sequence S
        for each item in sequence S
            do an operation
            if result overflows
                alert user
            else
                print result

</comment><comment><USER3> Hello world is valid for checking that you have everything installed properly and it's the fastest way to make sure you get the most basic syntax of the program.

It's not like the first thing you're going to do is write out all of quicksort to see if it's easy. You're going to fiddle with numbers an arrays a bit first, particularly if your language has some kind of interactive console. In fact, I wouldn't be surprised if the first thing you do in the language is actually 1+2.

There's quite a bit of syntax you need to learn before quicksort becomes a relevant test.

If you're looking for a good language to build a quick website backend in you probably don't even care about that, you'll care more about having nice ways of passing information around and checking that it has a decent inbuilt sort method.

</comment><comment> T-R I don't think "Hello World" will ever cease to be useful for the simple task of making sure everything's installed and operating correctly. Quicksort is certainly beautifully concise in Haskell, but it's not in all languages, and I want a low probability of errors when I'm just getting things up and running for the first time.

</comment><comment><USER4> For a veteran programmer learning a new language like Haskell, I agree completely.

For a novice programmer learning their first language, they probably don't understand the quicksort algo and probably have no concept of arrays or any data structure. Visually displaying "Hello World" is very simple and teaches you two basic parts of a language: \- Syntax \- Printing stuff

On another note, someone learning HTML for the first time will have no reason to do quicksort.

<comment><USER5> I don't believe HTML is Turing complete, and thus it's difficult to argue that it is indeed a language for computing.

</comment></comment><comment><USER6>
        qsort :: Ord a => [a] -> [a]
        qsort []     = []
        qsort (p:xs) = qsort lesser ++ [p] ++ qsort greater
            where
                    lesser = filter (< p) xs
                    greater = filter (>= p) xs

I know nothing about Haskell but I don't think this code implements the original quicksort algorithm which sorts the input in-place. Moreover the two- pass of filter over the list and the concatenations cause unnecessary overhead. Thus, even if the sample code is simple and elegant, a real-world implementation would surely be a bit longer than the given example.

<comment><USER7> Ok, I am still learning Haskell, but I thought I would try to fix the above so that there is only one filter pass:

        qsort :: Ord a => [a] -> [a]
        qsort []     = []
        qsort [x]    = [x]
        qsort (p:xs) = qsort lesser ++ [p] ++ qsort greater
            where
                (lesser, greater) = foldl split ([],[]) xs
            where
                split (left, right) x = if x<p then (left:x, right), else (left, right:x)

Does this work?

<comment><USER6> I had to look up what the `:' operator does and it adds an element to the beginning of the list. So the last line should be

        split (left, right) x = if x<p then (x:left, right), else (left, x:right)

</comment></comment></comment><comment><USER8> Although this version is very simple, concatenating and creating lists at runtime ruins performance (and it takes extra memory). Please make it a good example by doing a version of Quicksort with in-place partition.

<comment><USER9> That's actually a nice nab for functional programmers. They run around all the time telling how nice their language of choice is, showing off quicksort in three lines of code.

But please don't have the audacity of pointing out that original quicksort was supposed to be an _efficient_ in place sort, not a mental exercise in beauty of a language. Then you get a Haskell version that is in place, and supposedly fast. It's about 10 lines longer than the C version, uses Monads, ST, recursion, "unsafeRead/Write", "rscan", "lscan", "swap", "sloop", etc., all together about 20 concepts, built-in functions, etc.

Also, of course, if it really should be fast, you have to use several compiler hints and macros to make it type specialize and all. Obviously.

The C version is shorter, uses nothing but array accesses, do/while, if, int comparisons, and recursion. If you want to explain the C version to a novice programmer, it will maybe take you half a day. The _inplace_ Haskell version? Uhhh, yeah.

I can't help it, but things like these leave me with the impression of Haskell being a theoretically really nice language whose utility in actually getting things done seems somewhat questionable.

</comment></comment><comment><USER10> I still write and run Hello World in languages I am well versed in when I start working in a new environment, purely as a sanity check. In many cases it is the simplest starting point to ensure you have a working environment.

As far as familiarizing myself with a new language, I usually write a Hello World, then add some variables, and some functions or whatever is relevant, and just focus on the syntax of the language, or in the case of a platform or framework, take a look at building trivial components.

Not a language, but a platform example: I recently explored ExpressJS (If you're not familiar, its a framework for node.js web apps.) and my workflow was: Make a hello world server, Add a few routes and a static handler, Add some views, Add some middleware, Build it into a basic blog. (Because it's always a blog first, right?)

The whole process was quite quick and gave me a very strong jumping point for ExpressJS. Implementing quicksort or something similar as my first crack would probably have been pretty useless. So for me its all about context; I tend to start at Hello World and quickly grow something simple, but relevant to the language or platform.

</comment><comment><USER11> Yet another article that completely misses the point. The point of "Hello World" is to show a noob how to fire up the editor, compile, and see something happen.

And btw, here's the answer in F#:

      let rec qsort = function
           | [] -> []
           | x::xs -> let smaller,larger = List.partition (fun y -> y<=x) xs
                      qsort smaller @ [x] @ qsort larger

<comment><USER12> This looks like yet another Haskell "variant." From what I can tell this sort does not occur in place and thus would not make a particularly good quicksort. Memory use, number of accesses per element, etc. This style of programming is more suitable for heapsort or maybe mergesort.

<comment><USER13> You can't exactly sort "in place" in functional languages like F#/Haskell... at least trivially.

</comment></comment></comment><comment><USER14> I think I'm not alone when saying that the first thing I write in a new language I learn is some sort of project that requires a good understanding of the language's function-call model, of its object model, of a few specifics (strings, regices, data structures, arithmetic [depending on what I find interesting]), and that requires me to use some part of the standard library not readily available or to decompose my code into multiple files (or both). This helps me understand better what I'm doing, what I like about the language and what I don't. Examples of such projects include IRC bots, Lisp Interpreters, twitter clients, etc. (The one exception is Haskell, where I haven't gotten far enough to understand Monads well so I just wrote a completely functional RPN calculator).

</comment><comment><USER15> I'm proficient in Hello World in 24 languages. And now you say my knowledge is obsolete?

</comment><comment><USER16> tl; dr, but a quick note: the presented algorithm takes the first element as the pivot element p:

       qsort (p:xs) = ...

This is not recommended as it results in worst-case behavior on sorted input lists. (Another commentor correctly pointed out that it requires extra memory for the intermediate lists, too.)

<comment><USER17> It is just a toy implementation. If we're going to worry about practicals, then it's not recommended to use your own general purpose sorting implementations _at all_. For general purpose sorting, the standard library "always" has the best implementation.

<comment><USER18> Except it is also the canonical look-how-awesome-Haskell-is example that keeps getting trotted out all the time. Why aren't there more canonical examples of Haskell being both simple and awesome as well as fast and correct?

</comment></comment></comment><comment><USER19> Hello World is there to validate that you can setup, compile and run a program in your new language of choice. Complicating that process by trying to write something non-trivial defeats the purpose of the exercise. I call BS on this article.

</comment><comment><USER20> Someone already pointed out that you try out "Hello World" to see if everything is working correctly. Anyway, the author fails to make the distinction between _is_ and _ought to be_ , it's sloppy.

</comment><comment><USER21> This test gives an extreme advantage to lazy functional languages that they don't enjoy in any realistic context.

Trying to come up with a single test that is good turns out to be surprisingly hard. In modern languages I'm looking for the ability to do clean functional code, stateful object code, async programming, a solid module system, and a type system that doesn't get in my way. I really can't imagine a single 5 line program that would encapsulate all of these areas.

</comment><comment><USER22> The only way to learn a new programming language is by writing programs in it. The first program to write is the same for all languages:

 _Print the words_

        hello, world

This is a bug hurdle; to leap over it you have to be able to create the program text somewhere, compile it successfully, load it, run it, and find out where your output went. With these mechanical details mastered, everything else is comparatively easy.

 _The C Programming Language [Kernighan, Ritchie]_

</comment><comment><USER23> It is like fizzbuzz/binary search in that most people think they can write it and they get it wrong.

Quicksort requires careful selection of pivots, and is unstable. (Many scripting languages (perl, python) are opting for stable sorts)

Check out Bentley&McIllroy's Engineering Quick Sort for a guide about the problems implementing a production ready quicksort.

If you're going to teach them something easy, simple and relatively hard to implement badly, teach them merge sort.

Then teach them adaptive merge sort.

<comment><USER12> I would rather teach them:

1) how to write a program that guesses a number you thought of by doing binary search.

2) solve 2-queens

3) solve n-queens

4) solve knapsacking or some other combinatorial problem requiring memoization or DP. Of course, I wouldn't tell them any of those buzzwords that are meant to scare them away from just hacking on it.

Their mind will be blown regardless of the language they used and they'll get a feel for O() without even opening Cormen.

</comment></comment><comment><USER24> After I write my "Hello World!" program I usually graduate to writing a tictactoe game. Tictactoe has enough stuff to learn the basics of most languages.

</comment><comment><USER25> I think your point is valid and of course interesting for programmers, but KR's "Hello, world!" is still relevant for students and novices. Maybe reading/writing on a file would be more useful nowadays, since it does not demand knowledge of algorithms.

<comment><USER26> A large part of the value of a hello world is to check that you've actually installed the language correctly and can compile/run code. Printing hello world is just the simplest way of proving it.

</comment></comment><comment><USER27> QuickSort is still a very small problem that is not going to show much about the language.

Gosu's example code does a good job at covering a lot of aspects in ~50 lines of code:

<http://gosu-lang.org/intro.shtml>

</comment><comment><USER28> I usually implement a tic-tac-toe game as my first project when learning a new language. Tic-tac-toe, properly implemented, will give you a pretty good tour of a language. But with that said, Hello world, still serves it purpose.

<comment><USER12> This is a great example of making something that is challenging for a novice, yet not so challenging they give up. The reward is much higher than watching some numbers show up in the correct order and you tend to cover more of the language (2D array or your own abstraction of such, I/O, control flow, etc.).

</comment></comment><comment><USER29> "For every complex problem, there is an answer that is clear, simple-- and wrong."

<comment><USER12> Beautiful. We really need more cynicism on HN.

</comment></comment><comment><USER30> Do we all agree to teach from quicksort, to complete newbies of programming, while most experienced people had hard time to understand? Or simply just read this thread and imagine if you are just 12.

</comment><comment><USER31> Sadly, many programmers don't understand how quicksort works. This makes it somewhat unsuitable to be a hello-world.

</comment><comment><USER32> I think something simpler would be a better Hello World equivalent. The first program I generally write in any functional language (usually as a sanity check) is one to calculate the factorial of a number.</comment>


Show HN: API for price notifications for ecommerce products - <AUTHOR> https://semantics3.com/products/push?hn=1

<comment><USER2> We're doing an AMA over at Reddit as well: [http://www.reddit.com/r/ecommerce/comments/35zpxh/xpost_from...](http://www.reddit.com/r/ecommerce/comments/35zpxh/xpost_from_rapi_were_doing_an_ama_on_our_new/)

</comment><comment><USER3> This looks really interesting. What does this use as the source for product data?

<comment><USER4> Hey! Semantics3 has always had a solid database of products and pricing information which we keep constantly updated across various retailers. The Push API is just another interface to that database.

</comment></comment><comment><USER5> what do you mean by "high frequency"?

<comment><USER6> The products will be checked frequently for price updates, which means a price change will be detected sooner as well.</comment></comment>


Could have Facebook stopped OpenSocial by allowing Google to invest? - <AUTHOR>

I don't personally think they had the power to stop Google, and I don't think Google would have done it anyways.  But if they did have a chance, I really think they should have tried in order to get bigger faster and keep their walled garden as long as they could.<p>That being said, I am happy that OpenSocial is not stopped, its definitely better for everyone. <comment><USER2> Had they allowed Google to invest, Google would probably not have proceed to support OpenSocial so quickly. They would have protected their investment into FB. Don't be fooled by Google's PR.. they do play tough. If you want to see how Google operates similarly to how MS operates, go back and do some googling on how they threatened StumbleUpon guys. They basically told them that unless they allow them to buy them (instead of eBay), they will destroy them by adding StumbleUpon-like features to their toolbar.

<comment><AUTHOR> Thats interesting about stumbleUpon, but what happened when they eventually got bought out with eBay? what was Google's move?

But I do agree, if Google had invested in FB they would have probably not pushed for OpenSocial so aggressively and so quickly. But I think they would have eventually done it, meaning they would not have been stopped by FB.

I think there is a lot more to get out of OpenSocial. If they can reach out to the whole web instead of one network they can probably do a lot more and target a lot more people. As they said it themselves, they look at the web as a platform instead of one site on it as the only platform.

So far with OpenSocial they have Myspace, Bebo, Orkut, Friendster, SixApart and +++ which is almost = to the web. This is not a bad deal compared to one site that is mostly about what it could be in the future rather than what it is actually right now (which is not much compared to Myspace, and definitely nothing close to all these sites combined.)

</comment></comment><comment><USER3> facebook in last 3 years gone from a milion dollar valuation to 15 billion.

Google has its grudge against Facebook, microsoft has invested and created a high valuation and facebook potentially launching a ad service with better user preference knowledge than its old adsense platform

facebook is growing and has a mindshare of top 16-30 year olds, the youth whom every advertiser targets.

Facebook app development is not easy, no ajax, fancy UI for now, but as a innovator and a great developers dveloping facebook and facebook apps they can overcome those.

if google had to team with up everybody to compete against facebook and facebook application developers then facebook has been able to achieve what it intended to.

but over time expect opensocial to add other API besides current widgetting capabilities as they dont want to look like a cheap imitation.

also I suspect google would be writing some intermediate code for interfacing developer apps with other opensocial sites.

most of this communication would be via REST and JSON

for developers and development companies like ours we would put our bets on apps/sites which give us better revenues and development oppurtunities. we would continue with facebook apps and may port some to opensocial if demand exists

<comment><AUTHOR> here is an interesting video about the politics behind Google's OpenSocial <http://news.ycombinator.com/item?id=76383>

</comment></comment><comment><AUTHOR> Further, many Facebook applications are not able to take advantage form the Facebook platform now. The platform paid off well for the early adopters and also for the most popular apps, but the majority of applications on Facebook are not seeing much return from the site. Whereas, through OpenSocial they are now able to reach out to a much larger audience, that is also a lot more diversified with a lot more itnerests.

On top of all these it is a lot easier to develop for OpenSocial as it is for Facebook, since you can merely use HTML and Javascript to do so, instead of learning the FBML (facebook markup language). Although it should be noted that in order for a developer to do more customized stuff, they will need to work with the APIs of those sites that have one, this way they can take total advantage of the underlying websites.</comment>


Gmail Sidesteps the App Store - <AUTHOR> http://www.technologyreview.com/communications/22424/ Junior at Duke University; co-creator of Twitter app StrawPoll (@strawpoll). <comment><USER2> It's much harder to get people to buy access to a website than it is to buy an app. Plus, the transaction won't be as smooth as it is with apps, so I don't think Apple has anything to worry about. Besides, I think Apple would love to see fewer free apps in their store, so the more that move over to HTML, the better from their perspective.

</comment><comment><USER3> Also the Google web-based apps are not as nippy as apps written for the iPhone. The sidestepping has a cost.</comment>


'Like Git, but for Data' - <AUTHOR> https://dev.to/lukefeeney/git-for-data-a-terminusdb-technical-paper-i4p <comment><AUTHOR> Tl;dr The use of advanced CI/CD workflows for databases has not been practical due to the lack of tool-chain support. TerminusDB makes possible collaborative CI/CD type operations in the universe of data management. TerminusDB provides a practical tool for enabling branch, merge, rollback, and the various automated and manual testing regimes which are facilitated on a transactional database management system.</comment>


Notes on RSI for Developers Who Don't Have It (Yet) - <AUTHOR> https://www.swyx.io/writing/rsi-tips <comment><USER3> An ergo mouse is listed under "Expensive/Extreme Recommendations." The one I use, the VerticalMouse, is $90. For anyone in a first-world country, $90 - <USER2> even $200 or $300 - seems incredibly cheap if it makes any impact at all on RSI - especially when your income requires typing.

Regarding actual recommendations, I'd start with a Kinesis Freestyle or similar split+movable keyboard (potentially tented) and a vertical mouse or trackpad. Basically, your wrists shouldn't need to bend up/down or angle in/out to type or mouse. I'd consider this the bare minimum (not extreme) if you've experienced wrist/hand pain.

<comment><AUTHOR> thanks, I will rearrange. still working on this list.</comment></comment>