Go Replace - simple and fast search and replace tool for command line - <AUTHOR> http://solovyov.net/en/2013/goreplace/

<comment><USER2>
        find ~/my/docs/ -type f -name '*.txt' -exec sed -i.bak 's/inheritance/composition/g' {} +

This will search all files ending in `.txt` and will exec `sed 's/inheritance/composition/g'` on it. Sed modifies files in-place and saves a backup file with .bak extension (-i.bak) and is called the minimum necessary times (-exec +).

My best advice to someone using the command line is to learn `find` + `xargs` or, even better, `find` + `parallel`.

<comment><USER3> Compare with "gr what-is-it -r here-you-go". I do not have to remember all that argument hell.

<comment><USER4> Well, one can write an one-line shell alias (or script) instead of reinventing the wheel by rewriting the whole thing anew in Go. (Which is certainly good as learning experience for Go, but the end result is easier to achieve with the shell)

<comment><AUTHOR> When you start adding coloring, nice output, .hg/.gitignore support, it becomes just a big mess. Been there, done that.

<comment><USER5> coloring is already supported by grep, .hg/.gitignore support is just a few lines

<comment><AUTHOR> Just do it then.

</comment></comment></comment></comment></comment></comment><comment><USER6> Okay, so what I learnt from this:

1\. You've imported droundy/goopt, wsxiaoys/terminal really easily. The first provides option-parsing, and the second provides helpers for emitting ANSI escape codes.

2\. Practically everything is overloaded. You can == to strcmp(), + to concatenate strings.

3\. path/filepath gives you some nice goodies for path manipulation. But you have to deal with the fallouts of making naive assumptions like whether or not to recurse symlinks (why isn't this a flag in filepath.Walk?). This has resulted in ugliness in your walkFunc callback.

4\. You have been able to abstract quite a bit without using Java-like factories, although your inconsistent error passing has me somewhat confused.

5\. Since it's so strongly typed and there are no raw pointers, it's not going to be hard to debug at all.

Overall, I'd say Go is an effective language. But not beautiful, or novel in the slightest. It resembles Algol-68 (yes, a 1968 language) quite strongly, and I don't think it will drive compiler technology. Their syntax is specifically engineered to be parseable quickly (and hence super-fast AOT compilation): what the final program looks like is secondary concern. I'm not sure I see the appeal.

[edit: clarified that the note on compiler technology was an opinion]

<comment><AUTHOR> > your inconsistent error passing has me somewhat confused.

That was my first somewhat big program in Go plus coming from Python made a bit of hustle here. I still believe exceptions to be much better than this error-returning. :\ Never learned to do it nicely. :\

> Overall, I'd say Go is an effective language. But not beautiful, or novel in > the slightest.

Yes, this is more or less my feelings nowadays. It's good for certain cases and if I ever need something fast, I'll use Go and not C.

> I'm not sure I see the appeal.

There is some. It's still much simpler than C (GC + stricter compiler), plus it has goroutines (not much in this app, though), plus interfaces are really wonderful (you don't need to declare that you implement interface, just implement it and you're done).

<comment><USER6> On C. C has been around for _much_ longer than Go, and a lot of people understand C inside out. The C ecosystem is fantastic: there are extremely good implementations of virtually everything that you can use to build a production-grade application.

On Go. It'll take time for a programmer to fully understand how to use a new language, and it'll be a long time before great implementations appear. If the language isn't that much of an improvement, why will an existing C programmer take the effort to learn it? Aren't the returns diminishing? Computers will only get faster, llvm will only improve (tooling + compile time + link time): in that respect, doesn't Go seem a bit short-sighted?

<comment><USER7> In the respect of existing C programmers, maybe. Having myself never mastered C because of its complexity, in a few months part-time effort starting from getting a book on Go I built a sophisticated website. In the respect of non-C programmers, Go is extremely useful.

<comment><USER8> C isn't any more difficult to understand, IMO. Obviously Go has the advantage of hindsight and an opportunity to go back on the trade-offs that were made for compiler efficiency before C was standardized. However, at it's core I think C is much more simple than Go and theoretically should be easier to understand.

I find GC to be a useful tool but have you ever looked into the implementation of one? Or have you run into a situation where it was necessary to reason about the performance characteristics of a GC in relation to some algorithm or tight main loop?

I don't find C's lack of GC any _more_ complex than GC. In fact I find it much more simple. It requires more discipline on the part of the programmer (and perhaps that is where the appeal of a GC comes from). Perhaps it's because I started programming with addressing memory and building up a mental model of how it works and have only encountered GC as a useful addition to my programming toolbox (instead of an always-present assumption).

As well, co-routine trampolining (which is what I assume the playful pun _go- routines_ are referring to... please correct me if I am wrong) isn't a very "simple" thing to understand either. At least they are not any more simple than threads so I don't understand how they make learning Go any more easy for non-C programmers (except perhaps exposure to co-routines in a language that already has them like Python).

I guess what I am saying is that you could have just as easily mastered as much C in those few months as you did Go.

<comment><USER6> I would argue that C is probably the easiest language to understand, if you know the basics of hardware. C is essentially portable assembly. The C standard is tiny, and the behaviors are very clearly defined. The challenge is not in understanding the language, but rather in honing the engineering discipline required to use it to write real-world programs.

It lacks a garbage collector because there was no concept of garbage collector when the language was created. A C program does not provide enough information for a good garbage collector: the best we can do is a conservative garbage collector, Boehm. The garbage collector adds to the running-cost to the program for the promise of automatic memory management. While the GC might run concurrently, any sort of relocation (for compacting) will require it to pause the entire program: these GC pauses can be fatal if your program is the Linux kernel or some high-frequency trading application. Even otherwise, it is important to remember that every GC introduces trade-offs; the "freedom" from manual memory management is only worth it if your GC is good.

When I'm not writing C, I like writing Ruby. I like that it's a beautiful evolving language packed with features. And for the little applications I'm writing, I don't care even if it takes a second longer. I like that I'm not being verbose about anything, and not manually managing memory. Writing something like Jekyll in C would be an absolute pain in the arse, and totally not worth it. Obviously, the lesson is: use the right tool for the right job.

The pthreads API can certainly be very intimidating, and it requires a lot of practice to master threading in C. I like that Go has taken the concept of coroutines from Lisp (Scheme's call/cc) and turned it into something called Gorountines in imperative land. Although it's nothing novel, I won't deny that it's a nice abstraction to work with while doing multi-threaded programming.

If we were to redo C from scratch today, I'd definitely bake in more safety features. Probably design a close garbage collected dialect. For better or worse, that's an entirely theoretical scenario: we have Go today, but I'm not sure where exactly it fits in:

1\. It obviously can't replace C in linux, git, zlib, ssh, openssl, libcurl, nginx, varnish, or anything as core.

2\. Since it doesn't have generics or any higher OO features, it can't displace C++ in chrome or llvm.

3\. When python, ruby, javascript are around, why will anyone want to use a strongly typed language for writing web applications? Okay, maybe some intensive web services like search.

Tools? The most popular Go repositories on GitHub are dotcloud/docker (software deployment tool), burke/zeus (Rails preloader) and ha/doozerd (a very specific kind of datastore).

Might be useful in Android development, but is everyone's stuck in a Dalvik swamp there.

<comment><AUTHOR> > Writing something like Jekyll in C would be an absolute pain in the arse, > and totally not worth it.

Well, here you go: <https://github.com/piranha/gostatic>

Wasn't pain in the ass, wasn't hard, works so much faster than Jekyll (or my previous engine, cyrax, which was in Python), that it's even funny.

</comment></comment></comment></comment></comment></comment></comment><comment><USER9> Nice! svn support would be useful (ignore .svn directories) and the -r option is easy to remember, but perhaps not so much in line with the already messy standard Unix options (-r or -R for recursive operation).

Note that specifically for Go source code, there is "go fix -r" for syntax/context-aware code replacement (see "godoc fix").

<comment><AUTHOR> In case of go fix `-r` does something absolutely unrelated.

To be honest, I was just lazy inventing a command line key and it's recursive by design, so it happened this way. Plus, as you say, it's easy to remember because of mnemonics.

I haven't touched svn repos in years, but yeah, that could be added. I know they exist, it just that I haven't felt the need to support them.

<comment><AUTHOR> Btw, it ignores .svn and a bit more common stuff if it doesn't find itself in a git or hg repo.

</comment></comment></comment><comment><USER10> I have to break out the manual every time I use sed. Or awk. If this works reliably without any edge cases, it'll be fab!

<comment><AUTHOR> It does for me. :) I partially did it because I was too tired of looking up sed's regexp syntax and was afraid I'm going to fuck up everything.

</comment></comment><comment><USER11> For x86 binaries:

go get github.com/piranha/goreplace

go install github.com/piranha/goreplace

is another way to get it if you have GO and GOPATH set up.

I personally aliased it to 'gor' in my zshrc as the git plugin already occupied the 'gr' (short for git remote).

<comment><AUTHOR> Ha-ha, I've got an issue asking to add some notes about conflict with oh-my- zsh alias. :) I hastily suggested `gp`, but it's already taken by same plugin, so I changed it to `gor` there, thanks for idea.

<comment><USER12> Is tab completion not enough?

<comment><AUTHOR> It's often is. But somehow people end up with 'git remote' aliased to 'gr', and I ask the same question. :) I use gr very often and so not have to tab complete is a plus.

</comment></comment></comment></comment><comment><USER13> I really like Facebook's codemod.py for stuff like that: <https://github.com/facebook/codemod>

It has something like automatic and manual modes, so you can check (and fix) every diff during the replacement

<comment><AUTHOR> Well you see... It's in Python, which breaks the deal for me (I despise slow startup). But interactive mode sounds interesting, that's something I'll consider implementing.

<comment><USER14> By slow startup do you mean 0.01s of wall time? This sounds more like a prejudice than a decision with a strong technical basis.

<comment><AUTHOR> By slow startup I mean that 0.1s is the fastest small Python program using optparse, os, sys, re will start up on my system (i7 2.0, ssd). Search and replace tool will be slower. I constantly get 0.02s-0.3s results from 'gr' on my small-to-medium repositories (up to ~80k sloc). 'ack' takes more than a second usually.

Also it was written when I had HDD (not SSD) and codebase was on an encrypted image. It made enormous difference to me.

<comment><USER15> btw, here is ag, which also looks .xignore files: <https://github.com/ggreer/the_silver_searcher>

<comment><AUTHOR> Yes, I've mentioned it in my post. :) It's nice, but it does not perform replaces. I could add .xignore support though.

</comment></comment></comment></comment></comment></comment><comment><USER16> This isn't working for me. I get:

        C:\Users\swah\docs>gr TEST
        panic: Given path should be anchored at /

        goroutine 1 [running]:
        main.NewIgnorer(0xc08005bcf0, 0x29, 0x0, 0x0, 0x140110, ...)
                /Users/piranha/dev/go/src/goreplace/ignore.go:32 +0xa4
        main.main()
                /Users/piranha/dev/go/src/goreplace/goreplace.go:62 +0x1b7

        goroutine 2 [runnable]:

[edit] New version is working!

<comment><AUTHOR> Should be fixed, can you download new version please?

<comment><USER16> Working! Do you use colors? They don't work the same in DOS, I believe. I'm seeing some escape sequences.

        ←[0;32;49mRS\terms.tex
        ←[0m←[1;39;49m←[0;33;49m25:←[0m   ←[0;39;43mOEM←[0m  &                                      \\ \hline

<comment><AUTHOR> Eh, it's not very easy to fix that unfortunately. I opened an issue and will try to work on this a bit, but then in a meanwhile... Maybe I can strip colors for outputting things on windows.

Edit: argh, outputting colors on windows means making system calls. Which means cgo and good-bye cross-compiling. I'll probably just strip all colors...

<comment><USER16> Hmm, yeah, actually codemod.py had the same issue and I changed it to use Python's colorama library.

<https://pypi.python.org/pypi/colorama>

</comment></comment></comment></comment></comment><comment><USER17> Wow, it's super fast AND the output looks great. Good job, piranha! Copied to /usr/bin, I will use this a lot.

<comment><USER18> If you're the only user on your box, you can just create ~/bin and some distributions will automatically add it to your personal PATH. That way you don't lose track of what you've copied into /usr/bin, leaving it to be maintained by packages.

<comment><USER14> you can also very easily add ~/bin to PATH in e.g. your .bashrc

</comment></comment></comment><comment><USER19> what's the rationale behind 'gr foo -r bar' instead of simply 'gr foo bar'?

<comment><AUTHOR> Just happened so, plus if you forgot to put quotes around argument you could easily end up with a lot of problems. :)

</comment></comment><comment><USER20> Are 32bit binaries coming? For the rest, great job!

<comment><AUTHOR> Here we go, links are in readme. They work for me on 64-bit OS X and 64-bit Linux and `file` reports they are indeed 32-bit, but I haven't tested them on real 32-bit OS (I don't have any ATM).</comment></comment>


Blackout your WordPress site on January 18th - <AUTHOR> https://github.com/chrisguitarguy/WP-SOPA-Blackout

<comment><USER2> If you have a site that is not exclusive to visitors from the USA you might want to write "United States of America" instead. And "US Congress" (I guess). America is two continents.

<comment><AUTHOR> Good call. Done!

</comment></comment><comment><USER3> Nice work, Chris! I particularly like your embedded calling functionality. Where did you get it from?

If anyone's looking something a bit more configurable, <https://wordpress.org/extend/plugins/sopa-blackout-plugin/> is another option. Disclaimer: I was involved in the creation of this plugin, along with Site5 and Ten-321.

</comment><comment><USER4> Would the login page also be affected by this plugin? If so, how would an admin login if he isn't already?

<comment><AUTHOR> Nope, it won't. `wp-login.php` is a static file (no URL rewriting), so your server should serve it up directly. Also, the plugin only includes the hooks/functions that do all the work when you aren't in the admin area.</comment></comment>


Sweet Twitter Alternative, looking for Alpha testers - <AUTHOR> http://sweet.io

<comment><USER2> I'm only curious about how "No embarrassing family posts" are prevented.

</comment><comment><USER3> "Care about privacy?"

BUT:

"No private accounts."

<comment><AUTHOR> Privacy like tracking you down all around the world, record every action you take,etc..

</comment></comment><comment><USER4> Looks promising!</comment>


Testing code is simple - <AUTHOR> http://th3james.github.io/blog/2013/09/25/testing-code-is-simple/ <comment><USER2> What I wish people had told me before about this article:

\- this article only deals with unit testing

\- it does not help you write more maintainable tests

For the record, I don't think (unit) testing is simple. Tests are, in my experience, the least maintainable and readable part of a codebase. You often end up with many lines of setting up complex business objects. And usually, the only help wrt to what the hell is being tested is the method name. And that's just unit tests. Integration tests are a major pain, and often even harder to understand and maintain.

<comment><USER3> Not to mention the fact that unit tests can only help with _verification_ \- i.e. that you have built the software to expectations and to catch regressions.

I would say that 90% of the grief I have experienced building applications is the validation part - _that you are actually building the right thing_.

<comment><USER4> I work in web consulting where we frequently take on a project from scratch (greenfield or otherwise) and ramp it up quickly in 6-18 months then hand off to the client who will likely maintain it for a year or two or three then redesign (nature of the projects, not a result of quality). My company is pushing for more and more sophisticated automated testing at the time that I'm starting to think that automated testing is costing us more effort than it's actually saving. Our bugs are, as you say, predominantly misunderstood requirements. The tests never catch them. Even with correctly understood requirements, unit tests frequently miss edge cases. Something that gets missed in so many of these process debates is that different kinds of work require different processes. If your job is to maintain a massive software product, then automated tests are probably your bread and butter. But for my line of work, they just ain't.

<comment><USER5> Software is not just development, there is also a maintenance perspective. If I have a bug report in a complex piece of code it's a lot easier for me to write a test that covers the use case and work from there then building, fireing up a test device, etc.

Or when refactoring a piece of code that renders UI, write some tests to verify a couple of common cases and then refactor. Run the tests and I'll know whether the output is the same.

<comment><USER4> I'm saying there's a curve measuring the time spent writing tests and the time the lifespan of the application. Think of like the rent vs buy debate. Tests are a the big downpayment you make hoping that it will pay off in the future. The kind of project my company does are rentals. Same reason we rarely do major refactors.

</comment></comment></comment></comment></comment><comment><USER6> Nope, there's no way around it. Tests are _not_ easy. But! Writing tests, learning from that, then improving your tests, which in turn help you design better software will make writing tests easier. And will help you write better code, in general.

Also, 99% of the time, the first test you are going to write in a job is for an existing piece of software. So it will definitely not be easy. But you will learn so much more about the software you are writing the test against rather than writing code in the edit-and-pray methodology.

I highly recommend reading [http://www.amazon.com/Growing-Object-Oriented- Software-Guide...](http://www.amazon.com/Growing-Object-Oriented-Software- Guided-Tests/dp/0321503627)

</comment><comment><USER7> "Test driven development is now widely recognised as 'a good thing'"

should probably be written

"Using test testing in development is now widely recognised as 'a good thing'"

There is controversy around specifically TDD and studies showing that it does no better than writing unit tests during or after development. For citation see the references at the end of the chapter on TDD in "Making Software: What Really Works, and Why We Believe It"

<comment><USER8> One reason why TDD is better than writing unit tests after development is because then the tests actually get written. Whereas, if you wait to write them after the code, they often get lost in the pressure to deliver the feature and/or move on to developing new features.

The other reason TDD is good is that it forces you to make modular code with limited functionality to make it easy to test. You can do that without TDD... but TDD forces you to think about it ahead of time, rather than writing a huge mess of code and then saying "well, this will be too hard to test, so we won't bother".

TDD isn't magic, it's more of a mental hack to get you to do the right thing. If you do the right thing anyway, then no, TDD won't help.

Note, I'm not a huge TDD guy. In fact, I usually write my code first. But I've done some TDD and I can definitely see the benefit, and I try to do it when I can.

</comment></comment><comment><USER9> I've done my share of testing. When you walk into a meeting with the most senior dev team in the (significantly sized) shop, ask a single question about an underlying assumption, and have development go back for another couple of weeks to take another whack at it, you realize -- as one example -- that "testing" is not simple.

If you're lucky, you're doing real QA, where an smart, knowledgeable, and independently minded QA analyst can discover and raise such concerns _before_ the work gets done.

"Testing" is a shithole because many (most?) shops don't give it much respect -- nor resources.

P.S. One of the shorter meetings of my life. 5 minutes, including the socializing. The technical part took maybe 2.

</comment><comment><USER10> I recently decided to become a proper developer and started looking into testing, I'm almost through with "Laravel Testing Decoded", a book by Jeffrey Way, it focuses on Laravel but contains a wealth of information relating to testing in general. The book has given me a lot more value than I got out of any other resource that covered testing. Highly recommended and only $20: [https://leanpub.com/laravel-testing-decoded](https://leanpub.com/laravel- testing-decoded)

</comment><comment><USER11> I worry that many developers write tests because it is "widely recognised as 'a good thing'" without knowing why. It's clearly important to know why, otherwise how do you know when you are getting better at it?

So, what is the purpose of unit tests?

<comment><USER8> unit tests make sure that what you _think_ the code does is what it is actually doing. This is great for catching corner cases that you might not always test in a live test... or testing code that isn't yet called in live use.

It also makes sure that if code changes, it's still functioning correctly. Aside from catching initial bugs, this is the biggest addition to maintainability of code.

I find unit tests to be incredibly liberating. Have you ever made changes to some parts of the code, but then worried you might have broken something? With unit tests, you can be confident that your change didn't break any expected behavior.

<comment><USER12> I'm not sure I agree with you here. Tests are still only as clever as the person writing them. This means it's rarely going to catch corner cases that the developer wasn't already aware of.

I think the real value of tests is exposing expected behavior to teammates, and then providing quick sanity checks against that expected behavior.

The biggest thing new developers miss about testing is that most times you're not writing tests for yourself, you're writing them as a courtesy to your teammates.

<comment><USER13> > it's rarely going to catch corner cases that the developer wasn't already > aware of

Learning to recognize potential edge cases and partition inputs to check as many input categories as possible is a skill learned through experience testing.

</comment></comment></comment></comment><comment><USER14> What I wish people had told me about testing:

* You write tests in accordance with a pattern:

1\. Arrange

2\. Act

3\. Assert

4\. Annihilate

If you annihilate your test data with configuration options, and you abstract your "arranging" into factories and custom methods, then every test you write should be exactly three lines. When I learned this it gave me a consistent mental framework to think about how to write good tests.

* Test the interface not the implementation:

This was an eye opening realization about what to test. If you haven't seen it yet, watch Sandi Metz' incredible RailsConf talk - [http://www.youtube.com/watch?v=URSWYvyc42M](http://www.youtube.com/watch?v=URSWYvyc42M) \- it's so good

* Stubs:

Stubs are exactly like the viruses' that we learned about in biology class. You load them up with a value then they literally latch onto a method and inject that value into it. When you're just starting out with testing, effective use of stubs can get you really far, and only when you start hitting the limits of practicality is when you need to think about bringing in something more complicated.

* Testing isn't easy per se, but it is definitely enjoyable if you focus on making it that way

* Cucumber is pretty stupid, don't waste your time with it

<comment><USER15> That video was excellent, thank you! Sandi Metz always comes up with great analogies that clear up the conceptual fog in my mind. Her book Practical Object Oriented Design in Ruby is a great read too.

</comment></comment><comment><USER16> May I also suggest an extended assert?

xassert(condition,value);

e.g., xassert(result==3,result);

When the assert fails, the value is also reported. Helps with the question, "So it's not 3. What is it?"

I started using xassert when working in embedded systems where there is no debugger, no stack trace. Knowing the value of the error is valuable.

retcode = some_os_function(blah,blah,blah); xassert(retcode==OS_SUCCESS,retcode); <\--- why did my call fail?

<comment><USER17> A common version is to have assertEquals(a, b), that will print out both a and b if they are not equal. Then add similar asserts for "not equal", "less than" and other relations.

</comment></comment><comment><USER18> This is a good example for a small scale isolated project with a small amount of complexity. If however you are writing an enterprise level, scalable application, with many business objects and tons of complexity, things get way harder.

For example: What do you do if your function has a call to a 3rd party webservice? You do a mock.

What do you do if you have 37 levels of state that are dependent on the objects you are receiving from the mock? Create 37 different business objects and verify that the output for each is correct.

This problem builds and gets bigger, harder, and more conceptually complex. So while it can be easy to get started, it is not by definition intrinsically easy.

However, it is well worth every minute spent. It makes refactoring and building up much much easier. It also leads a bread crumb of clues to figure out what the code is doing. It leads to better code stability, and far less regression.

<comment><USER19> I'm not criticizing your comment, just adding a little bit to it. You're totally right, there's a lot of complexity when you're testing complex features in a huge app.

Buuuuut, a huge complex app is probably not the right place to try learning any new technology. Do a few small things first, prototype something out, test it along the way. Then maybe something a little more complicated. Slowly expand your horizon of uncertainty.

That way you only need to focus on learning one thing at a time. The assert() call that OP suggested is exactly enough to start thinking about testing simple code; once you're doing well at it, you can start noticing repetition and opportunities for abstraction (and finding existing libraries that have these abstractions already done for you); then, you start doing testing on more complex code and start learning about mocks to facilitate testing there.

Some people do really well in a "big bang" kind of learning environment, but I definitely don't. For me, learning works best given: a rough map of where I'm trying to get (even just a mind map that gives me things to look up when I get stuck), and an opportunity to master each piece before expanding onto new topics.

<comment><USER18> I agree.

</comment></comment></comment><comment><USER20> I develop software in a research environment, turning PhD students code into production quality systems. I think there are a lot of developers out there who don't write tests, or only write tests because you're "supposed" to (as evidenced by the popularity of the Stack Overflow question "Is Unit Testing worth the effort?" [http://stackoverflow.com/questions/67299/is-unit-testing- wor...](http://stackoverflow.com/questions/67299/is-unit-testing-worth-the- effort)).

They don't see the benefit for themselves, but like proper documentation, it's mainly a courtesy to other developers.

What I wish I was told about testing is that if you modify your workflow, it benefits YOU as well as your colleagues. Without testing, trying out a feature means:

1\. Make changes. 2\. Restart application or server (possibly refreshing page). 3\. Go through a series of clicks or keystrokes. 4\. Didn't work? Go to step 1.

Steps 2 and 3 can take a lot of time, and you'll likely be doing it over and over again (boring!). With testing this becomes a 2 second cognition-free process, and even that can be automated with Grunt/gnotify notifications. The boring part of coding is now automated. With good coupling, you can quickly isolate your change/compile/run cycle to the part of the code you're working on.

Programmers already know the benefits that testing brings 6 months down the line when something breaks, but it's wishful thinking to expect people to think that far ahead (and smaller companies are often in a hurry to get something out the door before the money dries up). If you want intrinsic motivation to write tests, you learn how to work such that tests provide immediate benefit.

<comment><USER21> But testing doesn't eliminate 2 and 3. Testing only checks for bugs you've thought of. You still need to do manual tests of new features to catch bugs you didn't think of.

<comment><USER20> It doesn't eliminate them, but it minimises the effort of performing these steps. You are of course correct in saying that you need to do manual testing to discover issues that you never thought of, but this is a separate process (which should not usually be done by developers who are too entrenched in the inner workings of the system to see it with fresh eyes).

</comment></comment></comment><comment><USER22> I also always wondered why testing frameworks need all that stuff besides assert()?

In fact, in browser js you can even wire onerror to send error server to a server (eg google analytics) in production.

What's the point of all the fancy .isEqualTo etc!

<comment><USER23> Error messages. If the assertion framework knows what you're checking, it can provide a better message.

E.g., "assert(a == 3)": "Assertion failed."

vs.

"assertEquals(a, 3)": "Expected 3 but was X."

The fancy "spec" style ("a.should.be.equal.to(3)") is overkill, though, I'd agree. It adds complexity for dubious benefit.

<comment><USER22> Why can't it be

assert("a === 3", a, b)

And then it can say "a === 3 failed. (2, 4)"

<comment><USER24> It _can_ be, but both the test code _and_ the error messages from that are worse than with many existing testing frameworks to my eye, so I wouldn't _chose_ that over the existing alternatives.

<comment><USER22> how are they worse?

I don't want.to.sitThere.writingThis(kindOf, crap)

<comment><USER24> > how are they worse?

The code reads worse for a number of reasons:

:: you've written an equality, rather than truth, assertion named "assert" rather than "assertEquals".

:: you're writing what would be the code of a truth assertion as a string for the message test.

For the same role, most unit testing frameworks have an equality assertion / expectation assertion that serves essentially the same role but reads better.

> I don't want.to.sitThere.writingThis(kindOf, crap)

Then don't use spec-style frameworks. There's plenty of xUnit and similar style frameworks that use simple assertions (and, yeah, you can just use bare truth assertions all the time if you want, but you've usually got a handful of nice tools for common cases like equality assertions to go with them.)

<comment><USER22> Fine, how about this:

      function testCase() {
         // do some stuff
         assert(a>=b, 'less pictures than participants', a,  b);
         // do some stuff
         assert(cool.length, 'cool is empty');
      }

output:

      "testCase: less pictures than participants (3, 4)"
      "testCase: cool is empty"

easy, no?

<comment><USER24> If you want to write your own one-function test microframework on that model, feel free; I don't see any reason to prefer using it to existing frameworks, whether xUnit-style or spec-style.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER25> really not worth the read

</comment><comment><USER26> Testing is only simple if you work on simple code, does not work nearly as well for real time, embedded or low level code.

However, the beneficial side effects of TDD are much greater than just the verification aspects so I think more foundational work needs to be done on test frameworks for hard problems.

<comment><USER27> I respectfully beg to differ with your first statement. I TDD in embedded and low level code, well, always. There is a great work on this by Grenning, worth reading by anyone who wants to understand TDD better, whether it is for embedded C or any other type of application.

Test-Driven Development for Embedded C [http://pragprog.com/book/jgade/test- driven-development-for-e...](http://pragprog.com/book/jgade/test-driven- development-for-embedded-c)

<comment><USER26> I have that book and really like it. I have been trying to apply it to my embedded work. It's a great start but we need a lot more development in that area, including more active support from the big embedded tool vendors.

</comment></comment></comment><comment><USER28> I object to calling this "test-driven development." The test is not driving the development. This is merely "development, with some tests."

Let the tests actually shape your workflow, and then get back to me about how your development is "test-driven".

</comment><comment><USER29> I really think all languages should have "assert" and "assert_equal" methods right out of the box, built-in.

Not that they're not hard to write yourself of course.

</comment><comment><USER30> So he doesn't like Rspec because it's in the spec style...which if anything makes tests a bit more easy on the eye and makes it more human-readable? Ooook

</comment><comment><USER31> Hm. This is possibly the most simplistic conceivable form of unit testing. Granted, lots of testing takes this form but it's only the start.

<comment><USER32> My experience is that a simple "it works" test covers most of the potential bugs in the test subject, so I just write {method name}_itWorks and just call the method inside asserting whatever the method was supposed to do.

I only write more tests if there are important business rules (new employees should be created with "Pending" status), or to cover edge cases uncovered by QA.

</comment></comment><comment><USER33> this little article is pernicious. please do not start thinking this is proper testing. what he shows is a lame replacement for some manual browser testing.

theres no talk about clean states between tests. no concern about emulating data sources. etc.

this is what should be called half assed functional tests. not even unit tests as everyone here says.

man tests really are black magic around those parts...

</comment><comment><USER34> TTD FTW

<comment><USER35> You probably mean "Test-Driven-Development" or "TDD" for short.</comment></comment>


Apple's iTunes genius button seems pretty dumb to me - <AUTHOR> http://www.guardian.co.uk/media/2008/sep/14/apple.digitalmedia

<comment><USER2> Forget the sidebar part of Genius - where it does seem Apple's just out to promote their back-catalog - and focus on the Genius playlist feature (which doesn't try to push music on to you).

The Genius playlist feature works really well. I've been surprised how good it does, even with semi-obscure music - it's opened my eyes to a lot of music in my library that I've forgotten about, and about 80% of the time, the combinations are really good.

Now, it doesn't work so well on my girlfriend's 4GB library, and perhaps it's just because my library is 60GB and filled with lots of CDs from my youth from almost every genre, but the algorithm is good - it's not entirely some sort of scheme to get you buying more music.

</comment><comment><USER3> Since the feature's "accuracy" depends on data from many other iTunes users, it may take (a little) time before we see just how good it can be.

So I'm not surprised if it seems dumb right now, it would be fair to review it again in a month.</comment>


O'Reilly's "Programming Rust" by Jim Blandy Available for Kindle - <AUTHOR> https://www.amazon.com/Programming-Rust-Fast-Systems-Development-ebook/dp/B077NSY211/ <comment><USER2> I preordered the book back in September. Will I need to pay separately for the Kindle copy?</comment>


Show HN: Technet Blog – OpenFaaS on ACS (Kubernetes) - <AUTHOR> https://blogs.technet.microsoft.com/livedevopsinjapan/2017/09/19/open-faas-on-acs-kubernetes/ <comment><USER2> Did you wrote it? Were you involve in the project?

If not, next time please don't add the "Show HN" to the title. From [https://news.ycombinator.com/showhn.html](https://news.ycombinator.com/showhn.html)

> _What to Submit_

> _Show HN is for something you 've made that other people can play with. HN > users can try it out, give you feedback, and ask questions in the thread._

<comment><AUTHOR> Yes I am involved in the project and worked with them. Did you check before commenting?

<comment><USER2> Yes I checked, but it was not obvious. The author of the post is "Tsuyoshi Ushio", I guessed it was not you, and I didn't see anything similar to your username in the page.

<comment><AUTHOR> I'm the author of the project which is pretty clear if you click through to GitHub. We're working on many different integrations right now and the ACS one is an exciting one - feedback / testing helps.</comment></comment></comment></comment>


How a blacksmith learned to code - <AUTHOR> http://joshuakemp.blogspot.com/2013/11/how-blacksmith-learned-to-code-and-9.html <comment><AUTHOR> @sherr Thanks for the kind words and encouragement. I guess I should have clarified that by NO MEANS do I consider myself a Software Engineer, I am still VERY much a junior developer who has the awesome opportunity to get to work on an awesome development team at ZipList! I love getting to learn and be mentored by the senior developers at ZipList. I only wrote this article and blog to show others not to give into the naysayers and that regardless of your prior experience or education you CAN learn, and get hired even if you don't have a CS degree or any degree for that matter. Everyday I am SO excited to get the opportunity to really start to learn this wonderful craft at a great company....keep coding peeps, you can do it! :-)

<comment><USER2> I always say that everyone can (and should) learn to program -- but by that I usually just mean that you can't be considered computer literate without being able to make the computer automate work for you. For most people picking up a powerful editor possibly combined with a scripting language or two (shell+awk+grep, perl, python and/or ruby for instance -- and maybe throw in R, Mathematica or something for crunching numbers (even SQL -- it depends on what you need)).

It's still fascinating (and maybe a little sad, re: the state of programming) that you could end up earning 70k after a year of part-time(?) (hard!) self- study. Maybe even more sad that you (as I understand it) made less as a (presumably) proficient blacksmith.

All that said, we've got few blacksmiths in Norway, so if you want to switch back, consider migrating here ;-)

</comment></comment><comment><USER3> Frankly, I'd be more interested in "How a developer learned to forge metal."

<comment><USER4> I don't think there's a much of a story to write about it, but I decided I don't want to waste a life employed in IT after all (as someone who's been coding all his life), and wanted to learn something new. Eventually I chose metal work; now I'm learning welding and machining. I'm also hoping to learn something about casting and forging and stuff.

Coding will remain a hobby so that I may focus on what I love about it, and stay true to my principles & avoid making any compromises due to commercial pressure.

It wasn't an easy decision to make and I still feel horribly uncertain about my life and all tha. On the other hand, learning something completely different is very very refreshing, and inspiring.

<comment><USER5> I'm currently learning how to weld as well (full time program). There's definitely something very satisfying in learning how to build things with your hands.

<comment><USER4> Indeed. Thinking back what once got me into programming as a kid (and what still keeps me interested) was the idea that with a reasonably powerful computer and some skill & time, I could _create_ any software imaginable. It wasn't a special affection to software in particular, but to making things -- and computers made making things very accessible because once you had a computer, you had all the tools you needed.

Now the maker inside me must've realized that making physical objects we use and rely on all the time isn't impossible, and can indeed be quite accessible once you learn a few things and make some investments (or find a good hackerspace?).

I would recommend any coders out there who code out of the love of creation and the freedom that comes with it, to at least consider expanding their horizon and learning to manipulate more than just bits. It doesn't have to be metal, in fact with 3D printing and diy electronics you could end up with something really awesome. (But don't forget 3d-fad isn't the only way to deal with plastics; it can be machined too, for instance). Combined with your software knowledge, who knows what great new ideas a new skill might bring with it? It'll deepen the experience of _making_ for sure.

<comment><USER5> I started as a kid as well. One of the wonderful things about computers being self-contained learning environments is that there's such a wide range of possibilities for expressing your intellectual curiosities and ideas.

Now that I'm a bit older though, I am enjoying the physicality of working with my hands, producing something tangible and having something that can outlast me, instead of code that most likely will just last some years.

After I'm done with my welding training, I'd like to do at least some introductory machining classes. Perhaps even a furniture making course. I have to good fortune of living very close my community college, and as long as I can work part time as a developer (albeit at odd hours) I want to keep learning how to build things with my hands.

</comment></comment></comment></comment></comment><comment><USER6> I really liked this post, is full of good advice on how to implement big changes, like having small, bite-sized goals where performance is easy to evaluate. The networking part was very well done, forcing himself to engage the community, it puts him out there and provides positive value. And finally, building a very simple website for someone was a great idea, there's nothing like getting experience from a real world project. Joshua, congratulations!

<comment><USER7> Yes, small bite-sized goals is so important for keeping going in long-term discouraging projects - as let's face it, programming can be _infuriating_ and tedious! lukeprog calls the focus on small bite-sized goal "success spirals" [http://lesswrong.com/lw/58m/build_small_skills_in_the_right_...](http://lesswrong.com/lw/58m/build_small_skills_in_the_right_order/) and I think it's definitely important.

<comment><USER6> I just noticed your username, and I have to say _thank you_ for your detailed articles and specially for your melatonin study. It personally helped me in improving my sleeping habits when I was having a lot of stress-induced sleeping issues. Thanks again!

<comment><USER7> You're welcome. I think the melatonin suggestion is particularly valuable for HNers as we all tend to spend so many hours staring at bright white/blue lightbulbs called screens...

(I think my recently finished Redshift self-experiment will show this effect dramatically.)

</comment></comment></comment></comment><comment><USER8> I love this story (and have read his book), but this sure isn't happening in the Valley or San Francisco.

As someone who's a similar skill level to Josh and applied to tons of jobs here in the Valley, I've found that this is an isolated story on the other coast. In SV/SF you have 5/6 developer bootcamps cranking out developers each month applying for a handful of junior jobs. I'm sure the blogging helped, but I doubt any companies would have offered the same salary here (60-80k) when they could have had their pick of developers that just worked 80 hours a week for 12 weeks.

</comment><comment><USER9> I wonder if the knowledge transfers to bare-metal programming.

</comment><comment><USER10> As someone over 30 with two degrees and programming for 7 months now (JS and now Objective C), I found this story quite interesting. I mentioned my two degrees because they are worth about as much as his no degree. My masters was from Georgia Tech in city planning (land development) and got me decent jobs in real estate development until the Great Recession. Now, I am unemployable in my field because I am more nerd than marketing mouth-piece.

That said, it is a little disheartening to learn than I chose to learn technical skills (I love just learning about the differences between all the syntactically-similar C-based languages) only to be in the same stupid predicament of needing to rely on marketing and gimmicks to get a job.

Maybe if I did not live in the Hollywood of the programming world, that might not be the case but I do. It was a nice story nonetheless. I see he benefited from having friends who code to tell him exactly how to get the most out of his code 9 months. I spent three months doing a @"Code Year" += 2 at Codecademy --before --I formally even learned how to type (big mistake) and 6 months before I started commits to Github (bigger mistake?)... and I still have not been to a JS event. Not even Hacker Dojo.

Anyway, good for you for getting there. I will put down the text books and text editor and start networking...right after I finish this Objective C app.

</comment><comment><USER11> Fools, this is just marketing dressed up as an "inspiring story".

This guy sounds like a _self-help guru_ , he doesn't sound like a programmer. Oh look, there's a book he has written which is available on Amazon.

He also suggests Zed Shaw's Ruby tutorial a couple of paragraphs after mentioning Rails. What the hell is this guy smoking?

The road to success he describes is linear, with no branching points. A complete lack of flexibility or discovery, the exact opposite of learning programming.

</comment><comment><USER12> Fantastic show Joshua. Very useful post and I passed it along to some friends, who wanted to get into coding. To state an obvious and pervasive point, on why I would want to hire someone like Josh, is his persistence and hard work, which will be as important an asset as his coding skills (even more so, at current point where his coding skills are accretive).

A point to note - The one-month rails course is now 99$, as opposed to $49 you had paid.

</comment><comment><USER13> I read "month" as "day" and thought holy crap this guy is destroying it!

I only saw two sites he made in his resume(two including the blog itself) and I'm surprised that's all it takes for $70k job. A lot of it is probably due to strong self-promotion and initiative rather than raw programming prowess.

<comment><USER14> Salary is also strongly dependent on location and industry.

</comment></comment><comment><USER15> everybody is learning howto code but when will people learn how to solve hard problems. I would rather see people learning complex math and physics before learning how to code. creating various crud applications is not really that hard.

<comment><USER16> You're right, but making CRUD apps pays a lot better (and more quickly) than complex math/physics.

<comment><USER17> [http://xkcd.com/664/](http://xkcd.com/664/)

</comment></comment></comment><comment><USER18> This was an amazingly inspiring article. Thank you for writing it. It was astounding to see the degree to which you threw yourself in. Your points about marketing and joining meetups EARLY seemed especially insightful. And, you top it off with, "And then go build at least two awesome things that solve people's problems".

That is awesome. Well done!

</comment><comment><USER19> Congratulations Joshua. Great reading about your experience learning how to code, sticking at it and getting the job you wanted. Your post was short on details (I assume your book will have more) but still inspirational. Definitely good reading something positive like this at the weekend! Good luck.

</comment><comment><USER20> I'm an erstwhile (amateur) blacksmith, now a programmer. Funny to see the two together. Blacksmithing and programming are both areas where practitioners make their own tools. Compilers and tongs can be bootstrapped.

</comment><comment><USER21> So basically it was more how to market yourself and get a job to "learn how to code".

<comment><USER22> Actually that was pretty important advice and a huge part of the picture/story. You can learn through non-traditional pathways just fine, but if you want to turn that learning into a career you're going to have to know a lot more about marketing and put it into practice than someone who has taken the traditional route, with a familiar story, and traditional access to employment opportunities.

This could have easily been a story about someone who spent a year learning to code and reporting how it was a waste of time because no one wanted to hire them. I bet a lot of folks run into that and just don't bother to write about it or make it to the top of Hacker News. Marketing matters, and if you're going to put in 20 hours a week as an investment in yourself you better be thinking about how to get a return.

</comment></comment><comment><USER23> I've a friend who principally for a living shoots things - pigeons, rabbits, and other such pains-in-asses for farmers.

In the UK, there's a fairly complex framework as to where you can shoot, how much you can shoot, and when you can do it. To this end, he's developed, single-handedly, iOS and Android apps for hunters to manage such and record their kills, principally for compliance purposes but also for their own edification.

Either way, it's been fascinating watching him learn - his approach has been to learn on the go, and iterate. He's gone from hacked-together PHP obscenity to android/iOS APIs and frameworks in about two years.</comment>


Ask HN: Part Time Code Camps in Boston - <AUTHOR> I am interested in doing a code camp to potentially transition careers.
I live in Boston and work full time here, and I do not plan to quit my job.
What are some good options and do you think this will help me accomplish what I'm hoping to?
I'm hesitant because coding boot camp feels like the new mid-20s crisis thing to do. I don't want to be in the company of 20+ ppl who are like "I hear engineers make $xyz, I just need to learn how to do it so I can get a job at xyzStartUp", or essentially believe $10k-$20k on a code camp will buy them a new career.
BACKGROUND:
Visual art major at top lib arts school (grad. 2014) working in content strategy at a marketing technology company. I've also been doing design work for ~10 years, mostly print/identity, but no UI experience.
I have completed around 300 freeCodeCamp modules (Basic HTML and CSS, Basic JavaScript) and have familiarity with python as well. I'm fairly comfortable with basic concepts and do a lot of googling to solve specific problems.
GOAL:
I'm interested in a camp because I would like some structure, project based learning, more advanced, career applicable teaching, and most importantly mentorship from someone with professional experience (I don't always feel I'm learning principles/concepts when I solve a problem with an hour of google searching).
I don't know for sure that I want to be "a developer", but I do know that technology will likely be part of my career, and can bring ideas to life.
I'm hoping to come out of a program with the confidence to apply to product positions (PM, UI/UX, Visual Designer) without saying "yeah I have no portfolio of digital projects." <comment><USER2> I'm planning to do this too, and did my own research.

I'm probably going to go with the Launch School ([https://launchschool.com/](https://launchschool.com/)) because of its focus on giving you the foundational skills to learn any language (after learning Ruby from them). I may or may not decide to do the Capstone project.

It seems you're only interested in front-end, not full-stack, so I'm not sure they'd be a fit. But I will say that as a software PM knowing about the back- end is probably useful.

Just my two cents.

</comment><comment><USER3> This is a bit different, but you could also look into Harvard Extension</comment>


FBI, intel chiefs decry "deep cynicism" over cyber spying programs - <AUTHOR> http://arstechnica.com/tech-policy/2015/09/fbi-intel-chiefs-decry-deep-cynicism-over-cyber-spying-programs/

<comment><USER2> If they weren't going full cointelpro on people who are skeptical then I'm sure there would be plenty of people who support their missions... It should be common sense that irrational responses only promote further irrationality.

</comment><comment><USER3> The biggest threat to America right now is the gathering of data on individuals. This data has a life of it's own and can and will be used against us where there is money or political gain to be made.

</comment><comment><USER4> Spying programs are the swiss knife for intelligence. I was renting my spying softwares to some governments</comment>


Ziff Davis Linking Policy - <AUTHOR> http://www.ziffdavis.com/ziff-davis-linking-policy/

<comment><AUTHOR> For context Ziff Davis operates ExtremeTech.com, Geek.com, PCMag.com and a few other sites, and have long incorporated spamming HN as part of their online marketing strategy.

Almost every submission comes from their shill accounts.</comment>


The Famous Feynman Lectures on Physics: The New Online Edition (in HTML5) - <AUTHOR> http://www.openculture.com/2013/09/the-famous-feynman-lectures-on-physics-now-online-in-html5.html

<comment><USER2> The provided link is pure linkbait. Here's a link to the actual content:

[http://www.feynmanlectures.caltech.edu/I_toc.html](http://www.feynmanlectures.caltech.edu/I_toc.html)</comment>


Git implementation in 1k lines of Node.js - <AUTHOR> http://gitlet.maryrosecook.com/docs/gitlet.html <comment><USER2> Now this is high quality content, thanks for sharing!

This caught my eye too [https://maryrosecook.com/blog/post/little-lisp- interpreter](https://maryrosecook.com/blog/post/little-lisp-interpreter)

<comment><AUTHOR> Thank you too, the link about lisp interpreter is really good!</comment></comment>


ElectionGuard – A free open-source voting SDK - <AUTHOR> https://blogs.microsoft.com/on-the-issues/2019/05/06/protecting-democratic-elections-though-secure-verifiable-voting/ <comment> maze-le It may not be a popular opinion around here, but the best election guard is doing them with pen & paper.

<comment><USER2> It's a terrible idea. Paper-only elections are easily corrupted. The right answer is combining paper & electronic.

<comment><USER3> But tampering with a paper-only election requires physical interference and working across many different locations. It is much easier, if you have the talent, to break into an electronic election.

<comment><USER4> That's why you use both. Paper for tallying and electronic for auditing. I used to think electronics wouldn't help but now I'm starting to be convinced.

<comment><USER5> Tallying is only a problem if polling stations are overcrowded.

The simpler solution is to hire more counters. I can't imagine that'd be more expensive than developing custom hardware & software.

<comment><USER6> Also less expensive than transporting and deploying an enormous amount of computers and networking equipment on Election Day.

</comment></comment></comment></comment></comment></comment><comment><USER7> > The ElectionGuard SDK will be available through GitHub beginning this > summer. We encourage the election technology community to begin building > offerings based on this technology and expect early prototypes using > ElectionGuard will be ready for piloting during the 2020 elections in the > United States, with significant deployments for subsequent election cycles.

Where is the "we invite interested developers and groups to audit this code and try to build exploits" stage?

> recently received $10 million in funding from DARPA to build a demonstration > voting system

and maybe with a bounty reward program?

Then again, maybe because this is more of a reference implementation designed to be incorporated into other products (MIT license) maybe the only thing that matters is how the final implementation is done?

<comment><USER8> My understanding from previous articles is that the DARPA grant went to coming up with the architecture and spec, then vendors would do the actual implementation. This looks like middleware.

From this random coder's perspective, the architecture previously designed sounded good. Voting and tallying were two separate systems. A physical, user- decipherable, paper that the voter carries over connected the two (it sounded something between a QR code and scan-tron).

It's good to see an open source codebase that multiple vendors would implement against.

</comment></comment><comment><USER9> Love that there is more movement around solving this. Paper ballots DO NOT allow a voter to verify there vote was counted and is a huge issue with TRUST. Allowing users to verify their votes (however it happens) COULD have a big impact in voter participation.

Looking forward to seeing this movement keep advancing.

</comment><comment><USER10> There is one more problem with encrypted elections not yet listed here; the vote is secret for now but 5, 10 or 20 years later it will be easy to break.

This might mostly be a problem for those then powerful, if someone find out that they voted "wrong" long time ago, our trust in them will be reduced. Yet a way to do negative campaigning.

</comment><comment><USER11> Cool use of Hom encryption, but does nothing about disenfranchisement.

<comment><USER12> Gerrymandering, preference distortion through no proportional voting systems, Duverger's Law. I mean, I'm glad people are working on the problem-space of democracy, but I'd guess that other issues more greatly effect voter disenfranchisement and apathy.

<comment><USER13> The problem in 2016 wasn't that anyone "hacked" our election, it's that they hacked our electorate. Turns out that people's opinions are much easier to change than cast ballots.

</comment></comment></comment><comment><USER14> How does this compare to Scantegrity [1]?

[1] [https://en.wikipedia.org/wiki/Scantegrity](https://en.wikipedia.org/wiki/Scantegrity)

</comment><comment><USER15> Holy cow. This is like using inmates to process rape kits.</comment>


WikiWikiWeb - the original wiki [for hackers] - <AUTHOR> http://c2.com/cgi/wiki?WelcomeVisitors

<comment><USER2> Once a brilliant resource, now mostly a waste of space and time. About 10% of the pages are semi-worth reading, but good luck trying to find them. they're swamped by special interests, the winners being who shouts the loudest and longest.</comment>


British Airways faces record £183m fine for data breach - <AUTHOR> https://www.bbc.co.uk/news/business-48905907 <comment><USER2> This was technically first, the comments are on another submission which is on the international BBC news site:

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


What is Software Engineering? - <AUTHOR> https://research.swtch.com/vgo-eng <comment><USER2> If your life really depended on the ok outcome of the nxt program you wrote, you would make SURE it worked. You test, re-test, try alternatives and compare outcomes, run experiments about what happens under certain conditions. Then you take the level you've tested it at and release it saying that your system is capable of 1/10 what you tested it at. The application of the scientific method to the act of building stuff so that you really _know_ the outcome, at least within known bounds of uncertainty - thats engineering.

I'm sure this kind of work does go on throughout the world, but not in 95% of the software that gets written. Just like how engineers aren't involved in 95% of construction jobs, except when writing some guidelines 20 years ago. Most programmers are plumbers and brickmakers building houses, not engineers designing skyscrapers.

"When Roman engineers built a bridge, they had to stand under it while the first legion marched across. If programmers today worked under similar ground rules, they might well find themselves getting much more interested in Ada !" — Robert Dewar, President Ada Core Technologies.

<comment><USER3> > Most programmers are plumbers and brickmakers building houses, not engineers > designing skyscrapers.

Conversely, most mechanical engineers don't end up designing a new production motor, they design a door handle.

</comment></comment><comment><USER4> _> Software engineering is what happens to programming when you add time and other programmers._

To preface, I think there's room for a wide variety of meanings people assign to words and nobody has a monopoly on what "engineering" means. That said, I offer an alternative:

 _Software engineering = programming that accounts for real-world _constraints_ such as performance goals, technology limitations, monetary budgets._

Whether engineering a bridge or engineering a circuit board, they share a common theme of optimizing multiple constraints (materials, cost, maintenance, durability, etc).

An advantage of this view of engineering is that it can also be applied to _solo programming_. The single programmer weighs the _tradeoffs_ to a possible solution.

The other concept of _" add time and other programmers"_ that the blog author is talking about is also important but in my opinion, I'd prefer the industry find another catchy label for it. I've seen others call it "software factory design" instead of "software engineering". The "factory" of optimizing how multiple programmers work together is what books like Mythical Man Month, Peopleware, etc talk about.

To apply my concept of engineering (constraints) back to the Go language... let's say I interview a candidate and ask what his favorite language is and he says "Go". I then follow up and ask _" Ok, Go is good. What is Go not good for?"_ If he responds that he can't think of anything negative, _it means he can 't do engineering with Go_. Engineering means you know the stress weaknesses of concrete, or corrosion properties of steel, or the warts of programming languages. If the candidate then tries to answer with the universal _" well, good and bad programming can be done in any language"_, that's just a restatement of the Turing Tarpit[1] and you can't do effective _engineering_ with that view. Assembly, C/C++, Haskell, Lisp, Javascript all have weak points that work against particular engineering goals.

[1] [https://en.wikipedia.org/wiki/Turing_tarpit](https://en.wikipedia.org/wiki/Turing_tarpit)

<comment><USER5> > If he responds that he can't think of anything negative, it means he can't > do engineering with Go.

I have used this tactic for interviews for quite a while. Though working primarily with Java and the JVM, every good programmer already has a long list of complaints. Regardless of preferred languages, frameworks, etc, everyone should know when their tools are not sufficient. I never care what the answer is other than they are able to articulate an answer.

<comment><USER6> My ability to talk at length about what's wrong with a language corresponds directly with how well I know and love the language.

<comment><USER7> Yes - or how well I know and hate the language.

<comment><USER8> Only C++.

I simply don't know enough to make an intelligent argument about why, say, PHP is a bad idea. But I have used it, and I don't want to do it again.

</comment></comment></comment></comment></comment><comment><USER9> I had it at university and was thinking "Well, programming is just a start, software engineering is where the bacon is!" Whelp... I learned a bunch of UML and SE methods (Rational etc.) and thought I'd go back to programming.

Same went with all senior programmers I worked with, they all said "I was a programmer for the longest time! Now I want to become a software engineer!" Just to come out of a certification course and asking "That's it?!"

I think the core ideas and principles are right, but after you learned what can be done with code, like infrastructure etc. you don't want to meddle around with stuff that is so far away from code as these methods. It just slows things down too much.

The only thing I really liked were class and call diagrams to find out what's going on in legacy codebases.

<comment><USER10> > Same went with all senior programmers I worked with, they all said "I was a > programmer for the longest time! Now I want to become a software engineer!" > Just to come out of a certification course and asking "That's it?!"

Semi-relevant: [http://programming-motherfucker.com/](http://programming- motherfucker.com/)

</comment></comment><comment><USER11> I don't think that this post really explains much about how to judge the fitness of a feature for software engineering. From the article, `gofmt` supports automated tooling around source code, which is good for software engineering; but scattering import paths throughout the source tree instead of centralizing them in something like `package.json` obviously makes automated tooling around import paths _harder_ , so why aren't local import paths bad for software engineering?

The whole viewpoint seems to just add a sort of high-handed argument from authority to your typical subjective arguments over programming features.

<comment><USER12> I agree that it's not explained clearly.

One possible reason: import statements in source code can be analyzed regardless of which build system you're using. In the case of Go, there are at least two important build systems ("go build" and bazel), so analysis tools would need to support both.

On the other hand, if a package.json file were just as universally used as Go source code, it would effectively be part of the language.

</comment></comment><comment><USER13> The difference between programming and software engineering is the difference between cooking for yourself and cooking in a restaurant kitchen. Similar outcome, radically different methods.

<comment><USER14> To put it slightly differently: software engineering is about efficiently producing working programs at scale.

It's like chemistry and chemical engineering. Chemistry is about atoms and molecules, and about chemical reactions. Chemical engineering is about building and running chemical plants that efficiently produce the desired chemicals without blowing up.

Though I guess that's the difference between computer science and software engineering, not between programming and software engineering. Maybe in the chemical analogy, programming is pipe-fitting in the chemical plant.

</comment></comment><comment><USER15> I think software engineering, similar to other engineering disciplines, is applied computer science. It means taking the theory (algorithm, data structure, etc) and create a product (software) that does useful things in the real world.

This means the software have to perform functions needed by its users, under real world constraints (time, space, power, cost) while being sufficiently robust to handle noisy inputs and variances. This also means the user will play a large role in driving the evolution and direction of the software and that the scope of software engineering encompassing beyond the theory but to the entire lifecycle of he software product including development, deployment, support, and iterative improvement.

</comment><comment><USER16> Software engineering is a whole discipline with several stages, it is mostly technology agnostic for most of the process. There are even people who say that all technology choices are just implementation details, and I do believe the same if I need to think abstract and formulate/define the larger patterns in area domain to work at.

That was quite empty article... what's that? A sales pitch for the next article?

The only comment related to design was an _implementation detail_ : the Go modules are git urls. Even at speaking an implementation the article fails: the article does not comment the pros, cons, consequences, problems or typical pitfalls, and evolution in time of this decision; it even does not compare with any other existing choices out there.

I believe these kind of articles should not be part of HN since it just aims to exploit the audience.

Edit: format

</comment><comment><USER14> It seems to me that computer science is really not programming, but _thinking about_ programming. The problem is, it should _also_ be thinking about software engineering.

<comment><USER7> I think CS on its own can be so theoretical and perfect that it is only a part of software engineering. A software engineer who can program can also put that programming and CS to use within business constraints.

Hand a strong theoretical CS person a steaming pile of a project and ask for the smallest tweak and it will take forever - that is if their head doesn't explode or they decide to re-architect it. Task a good software engineer with the same thing and they will get the change done with the understanding that they also hate the steaming pile of a project, but it isn't worth any more time.

</comment></comment><comment><USER17> Software engineering is the art of learning to lie to the technically-ignorant around you to satisfy "business requirements."</comment>


Unusual Strategies for Fighting Dementia - <AUTHOR> https://www.nytimes.com/2018/08/22/world/europe/dementia-care-treatment-symptoms-signs.html <comment><AUTHOR> Anyone else read this? While there are still a lot of questions, the overall idea of stepping away from medication and into immersive environments as less invasive solutions is incredibly beautiful. I'd be really interested to see some data on success rates for those who were kept on best rest versus the active approach taken here. The focus seemed to be more on stimulation and sensory engagement. My mind started to drift into ways we could use technology not to change this process, but make it richer. Not going to lie, got emotional at that clip of "Helga Mathijssen-Maas, a care giver, dancing with Ietje Geelen to songs from the Dutch music director Andre Rieu in her room at the Vitalis Peppelrode care facility." It got me thinking about ways we help patients/peoples experience these moments better. Maybe its a project involving DSP or spatial sound? I don't really have the answer, just found it inspiring. Also very into that robotic seal! Wondering what others think.</comment>


Shape Up: Stop Running in Circles and Ship Work That Matters - <AUTHOR> https://basecamp.com/shapeup/webbook <comment><AUTHOR> I'm considering implementing part of this at work. It feels less ritualistic than scrum, and leaner for a small organization. The 'appetite' concept brings out the discussion of cost (time) vs (business) value. I feel this is often lost in scrum, where putting something on the backlog and estimating its size are often consecutive. Does HN have any experience with this framework?</comment>


Google's Jaw-Dropping Sponsored Post Campaign For Chrome - <AUTHOR> http://searchengineland.com/googles-jaw-dropping-sponsored-post-campaign-for-chrome-106348 <comment><USER2> Here's a hypothesis that is more generous to Google (I don't know the real reason): some Google campaign that pays per download of Chrome is prompting site owners to generate this low-quality content. It seems more plausible to me than Google paying directly for this, because it's a terrible marketing campaign.

There's an onclick handler on the link to the Chrome download site on the blog that is in the screenshot on that page. I can't figure out what it does, though I did see when I clicked on it that my browser hit some URLs containing the substring "googleadservices", "conversion", and the Chrome download URL.

<comment><USER3> That seems plausible. However, whatever the true reason is, the end result is that Google is paying people to generate junk content. That's not good for anyone.

<comment><USER4> _Google is paying people to generate junk content_

It seems silly to me to get mad at Google for paying, what, ten thousand dollars in affiliate payouts, incentivizing cruddy posts, when they simultaneously collect (and pay out) billions for the ubiquitous AdSense ads which you find on sites which, charitably, span a wide range in terms of content quality.

<comment><USER5> I think the problem isn't that they're doing both of those things at the same time. The problem, instead, is that the third thing they're doing at the same time is issuing guidelines, (hopefully?) backed by their ranking algorithm, written specifically to combat this type of behavior.

If it were a free-for-all, sure, no problem. But Google doesn't want other parties doing this. Doing it themselves puts them in a position that's a little difficult to explain.

</comment></comment></comment></comment><comment><USER6> This seems very un-Googley to me.

This doesn't mean the article is not correct, but I just can't believe Google would do this kind of grey-hat SEO... mostly, companies do this to outsmart Google. Why would Google be trying to outsmart its own search engine?

<comment><USER7> Note: I care little about SEO, and I can't tell you if Google is trying to outsmart their own search engine, or, if they are, whether I should care about it.

There is potential legal trouble for them if they were to tweak search results to favour their own properties - that's a pretty solid reason for using SEO tactics to outsmart their own search engine.

<comment><USER8> Are you a lawyer? would you explain how is it exactly that "tweaking search results" is illegal? because I've noticed that meme going around and I don't think it makes much sense, I'm not saying that they any "tweaking", but if they were to rank whatever they like however they like on their own free website how is that illegal?

<comment><USER9> They are the dominant player in a large market (online advertising). If they exploit the dominance of their product specifically to stifle competition, we have a Microsoft-esque situation where the question might have been "how exactly is integrating an additional piece of freely available software with our market-dominant operating system illegal?" Well, it was, and this might very well be as well.

<comment><USER8> I'm not talking about ads I'm talking about ranking, and not even that, as ranking links doesn't really strike me as the way of the future, I'm referring to when Google shows a map for a location query and flight prices and schedules for a flight query as these are also search results and they are more useful (and prettier) so not only do I find nothing wrong with it but I find it to be the right way to go.

Also regarding that antitrust meme the Microsoft comparison keep getting mention, I'm not really familiar with that case but as I see it, Windows you buy and you are stuck with, Google on the other hand is free to use or not as you please.

<comment><USER10> The "stickiness" of Microsoft's products had nothing to do with the anti-trust case, They were leveraging their dominance in one market to exploit another; the permanence of the product has nothing to do with the illegality of their actions.

<comment><USER11> Isn't that what Google exactly did whilst promoting Google Chrome? Any search for the string "browser" turns up a Chrome ad. Some would argue that this is relatively an anti-competitive stance.

</comment></comment></comment></comment></comment></comment></comment><comment><USER12> When I read: _These days, it's hard to know who to trust, but with the name Google, you know you are in good hands._ I get a stomach-ache. I wonder whether something like this might backfire to some extent, not counting the possible hypocrisy. When you have people writing phrases like that, it almost sounds condescending, like an awkward author's attempt to portray a simple, good-old-fashioned person. Except real, good-old-fashioned people don't actually talk and make decisions like that, and even if they're not familiar with Chrome, they're not going to be persuaded by that. If this is the quality of content from such an SEO campaign, I wonder if such endorsements only work against Chrome in the long run.

OTOH, if the SEO works, then maybe enough people switch to Chrome to justify the crappy endorsements.

</comment><comment><USER13> Wow, marketing people in this industry can be sooooo lame sometimes. What a terrible campaign.

Google Chrome is a very good product, and doesn't need to be associated with this type of approach. The product speaks for itself.

</comment><comment><USER14> To be honest, I fail to understand why Google needs to do this. Chrome is gaining market-share at a very high pace already. Are they targeting a specific group of people in this case, or is this some misdirected effort by a third party advertiser?

<comment><USER15> To answer the specific question about Chrome's growth being "high pace already":

Doing a lot more damage to IE would be good for everyone. Microsoft moves way to slowly and they keep dropping support for older OS's, and they refuse to support WebGL, for example.

IE10, while actually looking impressive, won't run on Vista. XP will have significant market share for at least another 5 years and it's limited to IE8.

In short, I'd like to see Firefox, Chrome, and Opera take another 30% away from Microsoft.

[Updated]

Clearly my comments aren't appreciated. Look at this chart.

<http://gs.statcounter.com/>

To put it bluntly, Microsoft isn't getting the sh*t kicked out of them fast enough. Post PC, the death spiral of IE, no one buying WinMo7. Sorry guys, some of us have waited a long time for this. :-)

<comment><USER16> _Microsoft moves way to slowly and they keep dropping support for older OS's_

Gee, I wonder why they move so slowly. Do you think it could have something to do with trying to support so many old OS's?

I mean, really. Your cake. You can't have it and eat it.

<comment><USER14> That argument would work unless the competitors were supporting the same old OS-versions too, plus (in most cases) at least two other platforms.

</comment></comment></comment></comment><comment><USER17> I'll be interested to see an explanation for this, but the title is a little on the sensational side. I would say that Google's sponsored post campaign is closer to mildly intriguing than "jaw-dropping."

</comment><comment><USER18> Looking at the most recent (at the moment, [http://searchengineland.com/googles-jaw-dropping- sponsored-p...](http://searchengineland.com/googles-jaw-dropping-sponsored- post-campaign-for-chrome-106348#comment-21563)) comment it looks like this is part of a video advertising campaign by Unruly. Apparently (according to Unruly) the video is theirs, but the surrounding text is supplied by the blogger and should use nofollow links.

</comment><comment><USER19> This was bound to happen in some fashion eventually--it would happen to any company. The question is what will Google do about it. If it's a mea culpa I feel just fine about it. If it's a "no comment" one can hardly ignore the fact that they've gone down the road of filtering your access to information for the worse by making it less open and therefore less informative.

Your move Google.

</comment><comment><USER20> Comments are jumping all over Google without a word from the company yet.

I believe Google deserves the benefit of the doubt.

</comment><comment><USER21> Google was banning blogs doing paid reviews from PayPerPost and others. Now they do it themselves...

</comment><comment><USER22> Conspiracy theory - perhaps someone other than Google is running this campaign in order to trigger Google's automatic censoring of the Chrome download page... Pretty stupid attempt if so as Google is not likely to censor its own pages (certainly not for 400 "bad" links), but spammers can be stupid.

</comment><comment><USER23> So the concern is that this impacts the ranking of Google Chrome in Google Search, and that the FTC is investigating Google for favoring its own content unfairly?

It makes sense in the context of travel websites (Expedia complaining about Google, for example), but I'm not sure about Google Chrome. It's been promoted on the front page of Google many times--so does Google really need the extra boost in its search results?

</comment><comment><USER24> IMO they want to possibly avoid anti-trust issues in future when Chrome becomes the dominant player.

"Look we are teh small guys using plain old paid link marketing"

</comment><comment> wes-exp Obligatory Steve Jobs reference:

Google's don't be evil mantra: "It's bullshit."

</comment><comment><USER25> <snark> Your winnings, sir. </snark>

</comment><comment><USER26> What an absolutely bullshit article, by a site that only exists to advise people in the fruitless zero sum game that is search engine marketing.

So theres a bunch of idiots out there that are gaming Google's paid campaigns, and Google is indirectly benefiting from it. Outrageous!!

Search Engine land should shut down and find another line of work, something that actually benefits society in the tiniest of ways.

</comment><comment><USER27> I switched to Chrome about a year ago for its performance, and now I'm about to go back to Safari for exactly the same reason. What happened to Chrome performance on OSX Lion? Why does it scroll like molasses?

<comment><USER28> What does this have to do with the article?

<comment><USER29> That comment was in the spirit of the original article I guess.</comment></comment></comment>


BabylonJS – A JavaScript framework for building 3D games with HTML 5 and WebGL - <AUTHOR> https://github.com/BabylonJS/Babylon.js

<comment><USER2> I think I'll probably need to ask forgiveness for asking this question in advance. But it really is a subject of genuine curiosity for me.

Is there a reason that someone would use a Javascript engine like Babylon, Three or PlayCanvas over... say... just using UDK or Unity to make a WebGL game ???

My knowledge of Javascript engines other than Three does not go deep... so it's entirely possible that this is a dumb question. I'm just wondering though.

EDIT: Sorry .. I meant "PlayCanvas". Corrected.

<comment><USER3> Unity still doesn't have great support for making pure 2d games of the Mario/Metroid/Castlevania variety and is awfully heavyweight compared to an HTML5 canvas.

That, and the accessibility of the API vs. having to download and work in an IDE that you'll eventually have to pay money for mean more JS games.

Phaser.io[1] is a fairly comprehensive JS engine that is totally free. It's used to make professional games that run across a variety of devices.

[1]: [http://phaser.io/](http://phaser.io/)

<comment><USER4> Unity 5.0 does now include full 2D support.

<comment><USER3> They added 2d support in 4.3 a couple of years ago, but it was still really clunky then. Like, you still had to texture wrap 3d objects behind the scenes and it made 2d GUIs painful to use with no native pixel measurements.

Is that fixed in 5.0?

<comment><USER5> Not familiar with the texture wrapping bit, but the UI is much better. A lot like NGUI without many of its pain points

</comment></comment></comment></comment></comment><comment><USER6> I found the playground much better to browse through.

[http://www.babylonjs-playground.com/](http://www.babylonjs-playground.com/)

<comment><USER7> Do the sound demos not work for anyone else in Firefox?

<comment><USER8> Firefox seems to have a lot of Web Audio bugs. I've already pinged one of the developer of the web audio stacks on Twitter. But I probably need to open a firebug request also.

Our Web Audio engine runs fine in Chrome & Spartan.</comment></comment></comment>


It's Ok For Founders To Cash In, But There Shouldn't Be Any Reason To Hide It - <AUTHOR> http://www.arcticstartup.com/2012/05/22/its-ok-for-founders-to-cash-in-but-there-shouldnt-be-any-reason-to-hide-it

<comment><USER2> Some people just don't want everyone in their social circle knowing they have 42 million dollars.</comment>


Water Margin: Searching for the sources of China's great rivers - <AUTHOR> http://www.laphamsquarterly.org/roundtable/water-margin <comment><USER2> > The impassioned searching for the source of the great rivers throughout > Chinese history seems almost to betray a hope that it will reveal the occult > wellspring of China itself, the fount of the country's spirit (qi)...

> The source of the Yangtze is disputed even now. An expedition in the 1970s > identified it as the Tuotuo, the "tearful" river in Qinghai, but several > years later it was assigned to the Damqu instead. There's ultimately > something arbitrary in conferring primacy on one of a river's several > headwater sources, but for the Yangtze the symbolic significance of this > choice is too strongly felt for the protagonists to brook any compromise.

I think this is the most salient point in the entire piece. It seems like we, as people, spend a lot of time trying to classify things that don't matter. Debating what the true source of a river seems like it could be mildly important, but it's not much more important than determining whether height or weight is the more important criteria for determining the worlds largest ball of twine.

Someone told me that the many of the confounding and illogical human behaviors can basically be understood as tribalism being expressed in a modern context. Ever since then I've seen tribalism everywhere. And not only are there tribes, but those tribes have sub-tribes.

One of the things I really like about the internet is that it can allow us to concentrate on things that we actually care about, rather than getting caught up on stupid things like where somebody lives, or what they look like. We still have our prejudices and tribes (VIM vs EMACS, Apple vs PC), happens, but when it comes down to it, he have an unprecedented ability to connect with other people and form positive communities that advance the world as a whole.

</comment><comment><USER3> The article's title is a sly joke, the 'water margin' is the land of outlaws (popular in martial arts novels and films), harking back to Shui Hu Zhuan[1] which is fairly well known in English from Pearl S. Buck's translation, _All Men Are Brothers_

1: [https://en.wikipedia.org/wiki/Water_Margin](https://en.wikipedia.org/wiki/Water_Margin)

<comment><USER4> Buck's translation is garbled, from what I've heard, but there's a thoroughly readable scholarly translation that came out relatively recently. I think it's by the same author who did the two-volume _Romance of the Three Kingdoms_ -- it certainly has the same cover style, and is hard to miss on Amazon.

<comment><USER5> The translation I read was by Sidney Shapiro, which was done in the 1980s.

</comment></comment></comment><comment><USER6> TLDR: Tibet via Yunnan, though the author is really just a guy trying to sell his new book, which is a history of China through the somewhat forced lens of water related trivia.</comment>


Free Online Subversion Training - <AUTHOR> http://www.wandisco.com/php/pr.php?rss=0&prdate=2010-04-13 The first course in the series, Branching and Merging in Subversion 1.6.9 will take place on Wednesday, April 21, 2010. This course will cover everything from branching and merging basics to best practices. The second course in the series, Introduction to Subversion for Developers will take place on Wednesday, May 5, 2010. Subversion's architecture and design principles will be covered and attendees will be introduced to using Subversion for software development. <comment><AUTHOR> The first course in the series, Branching and Merging in Subversion 1.6.9 will take place on Wednesday, April 21, 2010. This course will cover everything from branching and merging basics to best practices. The second course in the series, Introduction to Subversion for Developers will take place on Wednesday, May 5, 2010. Subversion's architecture and design principles will be covered and attendees will be introduced to using Subversion for software development.</comment>


Could Iran be the next country to legalise cannabis and opium? - <AUTHOR> https://theconversation.com/could-iran-be-the-next-country-to-legalise-cannabis-and-opium-49183 <comment><USER2> Iranian here, it is highly unlikely to happen.but right now something going on under the cities skin which is low enforcement mostly don't show any interest to arrest ordinary users of herbal drugs( for chemical and modern drug it is whole another story,for example X pills.they will find and arrest you.and if you are distributor they will executive you 100%).but they vigoursly arrest and track distributers even herbal drugs.

p.s. if you have questions I would be glad to answer.

<comment><USER3> Another ridiculous drug policy.

Opium is considerably more dangerous than Ecstasy (which was noted as being 'no worse than horseback riding' by the head of Britain's drug advisory board).

<comment><USER4> Habitual use of ecstasy seems to have significant effects on the seratonin in the brain. Furthermore, dopamine receptor burnout is a real thing. Do enough ecstasy and you'll have a harder time enjoying yourself.

</comment></comment></comment><comment><USER5> A shrewd move if they do; significantly reducing use of the death penalty would significantly improve Iran's standing on human rights which would likely pay significant diplomatic dividends at zero strategic cost.

</comment><comment><USER6> >The current regime already envisages the prescription of opium tincture to drug abusers registered at state addiction centres

It amazes me that that policy is not more widely adopted for opium / heroin. It stops addicts having to deal / steal to feed their habit and so the whole thing kind of dies out whereas otherwise it tends to grow exponentially. Seems a bit of a no brainer but it's only intermittently adopted. I see about 120 Americans a day are dying of heroin and going the prescription route would rapidly reduce that towards zero.

<comment><USER2> As I said in another comment I am from Iran.the thing you are talking about can have huge consequences for regime.(I mean really huge).if they do something like that it will have huge media attention in Iran.people will raise other demands.why not legalize alcoholic drinks?why government keep trying torture girls and boys who have sex outside of marriage in various way? All so many other question . I assure you.if regime agrees to something like that(which I don't think at all,there is no way absolutely). I assure you it is end of Islamic government.

</comment></comment><comment><USER7> I suspect Canada is the next country to legalize cannabis.

<comment><USER8> Doubt it. It might not happen until well in Trudeau's term if it happens at all.

They have to create a regulatory framework and all the provinces will want to handle it differently. Ontario government will probably be selling it themselves like they do alcohol and since there's no suppliers of cannabis globally then they'll have to create the infrastructure to cultivate it.

I expect a long drawn out process.

<comment><USER9> What would happen if one province (like BC) just legalized it, similar to Washington and Colorado? Would Trudeau stop it?

<comment><USER8> Provinces in Canada don't have that kind of power. Canadian federalism is considered incomplete and is therefore not like the US.

</comment></comment></comment></comment><comment><USER10> Interestingly, Iran is the only country in the world that allows its citizens to pay for someone to give up their kidney [https://en.m.wikipedia.org/wiki/Kidney_trade_in_Iran](https://en.m.wikipedia.org/wiki/Kidney_trade_in_Iran).

By some accounts it works rather well, see [http://www.econtalk.org/archives/2015/09/tina_rosenberg.html](http://www.econtalk.org/archives/2015/09/tina_rosenberg.html).

(It is true that they do allow other nationalities to pay for a kidney, however someone of their own nationality must give up the kidney, preventing at least some level of medical/tra splant tourism).

</comment><comment><USER11> Opium (afeem) is something that is very prevalent in rural parts Iran, Pakistan. Cannabis (ganja) is something that is available easily too. It about time it is legalized and controlled.

</comment><comment><USER12> Does the strictness of drugs law correlate with general political repression?

Some people suggest drugs are pushed by governments to pacify their populations, but I'm not aware of any governtments on the west's "bad-guy" list that take that approach. Would it actually work?

</comment><comment><USER13> Could there be a worse way to write a headline than starting it with "could?"

</comment><comment><USER14> The _next_ country? I'd bet good money against that proposition.

<comment><USER15> How much? What odds do you offer?

<comment><USER14> At 1:1 I'd bet every dollar I have.

<comment><USER15> I'd be more interested if you would give at least 20:1 odds against it.

In any case, you should heed the Kelly criterion ([https://en.wikipedia.org/wiki/Kelly_criterion](https://en.wikipedia.org/wiki/Kelly_criterion)).

<comment><USER14> I would still be pretty comfortable at 20:1, but I probably wouldn't bet very much since the payout is so small.

</comment></comment></comment></comment></comment><comment><USER16> A theocracy is easier to maintain if your populace is stoned.

<comment><USER17> Any citations or reading that supports this? I've always thought that cannabis lends itself to a freer thinking, it's often associated with more liberal attitudes.

<comment><USER15> I know plenty of stoned neonazis in Germany.</comment></comment></comment>