China orders N.K. firms to close down within 120 days - <AUTHOR> http://english.yonhapnews.co.kr/northkorea/2017/09/28/0401000000AEN20170928012000315.html <comment><USER2> This makes me nervous and I fear that Kim Jung Un will have to do something big in order to save face. I hope we make him feel that he has a non-violent way to posture for his people as that's really what this is all about: posturing.

<comment><USER3> Honestly I don't get this sentiment. NK isn't some rationalistic actor. The NK problem can never ever be solved by diplomatic resolve. This goes beyond mere saving face, or diplomacy. This is simply about maintaining and expanding power. That is sometimes you need to be confrontational. Sometimes you need to stop being Chamberlain, and start being Churchill. Preferably before it's too late.

What else is their development of nuclear arms about? NK is a signatory of the NPT. They broke their promise. They've broken their promise multiple times. What they're looking for isn't a resolution to their situation, if anything they want to prolong it as long as possible. What they actually want is to win, and emerge "victorious" in the face of US "oppression".

Personally I think while China's interests are in maintaining a peaceful region, we must be wary of the relationship between NK and China. As there is a possibility of another game being played. Perhaps China wants to annex NK.

<comment><USER4> > NK isn't some rationalistic actor.

The way they're behaving is quite rational. They looked at what happened to Gaddafi and Saddam, as well as how the new administration is seeking to tear down the Iran deal, and came to the conclusion that the US/West could not be trusted to honor a nuclear disarment deal long term.

This means a credible nuclear deterrent is the only way to ensure the regime's survival.

Lest people think I'm engaging in apologetics, what they're doing to keep in power is reprehensible. But they're not mad men looking for a symbolic "win" at the cost of suicide.

<comment><USER5> > They looked at what happened to Gaddafi and Saddam, as well as how the new > administration is seeking to tear down the Iran deal, and came to the > conclusion that the US/West could not be trusted to honor a nuclear > disarment deal long term.

I believe that NK was untrustworthy long before the events you cite. They didn't reach a rational conclusion. They always were belligerant, untrustworthy, lying bullies.

<comment><USER6> > They always were belligerant, untrustworthy, lying bullies.

And US policy towards Korea has been something else?

<comment><USER7> South Korea seems to be doing just fine, and the US seems to be honest about the contempt with which it views the North Korean regime, so I don't really see the purpose of the equivocation you're trying to set, here.

<comment><USER6> I'm not trying to equivocate I'm trying to point out the a-historicism of throwing our hands in the air and saying "well I guess there's just no reasoning with them!"

The reason our diplomatic options are so poor now is because we have constantly failed to deliver our end of the bargain when it comes to nonproliferation in North Korea, see the Agreed Framework. Saying that they're "just crazy bullies" has always been a stupid over simplification that gets us nowhere closer to not blowing each other up.

> and the US seems to be honest about the contempt with which it views the > North Korean regime

And DPRK is not? What are you even talking about? The DPRK literally uses inflammatory rhetoric about the USA all the time.

</comment></comment></comment></comment></comment></comment></comment><comment><USER8> Related BBC article with more information: www.bbc.com/news/world- asia-41431057

<comment><USER9> Thanks, this has a bit more substance to it than the original link.

</comment></comment><comment><USER10> Will it really be enforceable though? It seems relatively easy for firms in China to change names, create shells, etc

If China can't effectively police their own fly-by-night domestic firms from doing by things like selling industrial salts as fake table salt, how likely is it they'll be able to shut down NK oriented firms, or even be aggressively inclined to investigate and enforce this order? That is, perhaps this is mostly for show to comply on paper with UN resolutions.

<comment><USER11> The enforcement of regulations in China is frighteningly efficient and effective, _while the issue at hand is foremost in the minds of leaders_. The government insists on retaining personal control over the country, and weakens the country's autonomous systems, which means it must spend some of a limited amount of attention to address any given issue. The moment the Eye of Sauron turns to look at a particular problem, everything immediately falls into order. The moment it turns away to something else, everyone gets up to their old shenanigans. It's the trade-off of retaining personal control.

In this case, these NK firms will certainly be a topic of focus, and likely remain so for quite a while.

<comment><USER12> On getting back to their old shenanigans, this is such a deeply rooted concept in China that it inspired a phrase that has remained in common use for 700 years. "Heaven is high and the emperor is far away" [https://en.wikipedia.org/wiki/Tian_gao,_Huangdi_yuan](https://en.wikipedia.org/wiki/Tian_gao,_Huangdi_yuan)

<comment><USER13> This concept was also expressed in that Whitey Bulgar movie, Black Mass.

>Remember Johnny, if no one sees it, its like it never even happened.

</comment></comment></comment></comment><comment><USER14> It seems like KJU needs an enemy to stay in power to justify his rule, so he can't back down on his nuclear program. But now the options are narrowing even more for him, and if he abdicated it doesn't have anywhere to go. So he may just force a war...

<comment><USER15> In any war he'd be destroyed.

NK has to balance on the knife edge between being threatening enough to get concessions but not so much other countries give up and ignore them (or level them).

KJU doesn't seem to know how to walk that line, and didn't have enough time to learn it from his father.

I'd say 'we're getting close to the end' but no one who has ever made that prediction has been right. It's too unique (especially with Trump now) to be able to get a good guess.

<comment><USER16> War? Please describe a scenario where Seoul doesn't get obliterated in the first 30 minutes of fireworks starting.

If the DPRK doesn't achieve victory within 72 hours then yes of course they will be flattened, but nonetheless a DPRK victory is within the realm of possibility. Seoul may be reduced to a smoking heap, 20M dead and 10M having emigrated, and it will be a Pyrrhic victory, but it could be a victory nonetheless.

<comment><USER17> Most North Korean artillery can't reach beyond the northern suburbs of Seoul.

It would cause mass casualties but by no means would the metropolis be 'obliterated'. There certainly wouldn't be 20 million dead unless everyone within the Greater Seoul area rushed north and threw themselves into the beaten-zone.

Assuming, of course, that the artillery troops follow their orders to fire.

<comment><USER18> I have a hard time believing that the artillery would ever get the chance. There's maybe ten square miles where they could place artillery to successfully bombard Seoul. The entire area could easily be destroyed or remotely turned into a minefield by a cruise missile salvo or judicious application of artillery fire from a handful of batteries. I can't imagine there aren't plans in place to handle this concern very rapidly should tensions rise to that point.

Even assuming that there isn't a concentrated effort to destroy these emplacements quickly, it seems the amount of damage they could cause would be fairly limited by operational constraints[1]

[1] [http://nationalinterest.org/blog/the-buzz/could-north- korea-...](http://nationalinterest.org/blog/the-buzz/could-north-korea- annihilate-seoul-its-artillery-20345?page=2)

<comment><USER19> There are plans, yes. Lots of artillery, but it's aging, and as was pointed out earlier, the number of pieces they possess that can actually reach Seoul (the 203mm Koksan) is not very great.

As soon as they open fire, the counter-battery game begins. You can be sure the allies have photographed and analyzed every strip of dirt along the DMZ, looking for prepared positions so they can anticipate where the guns are and where they'd move to after a salvo. They'd be tracking the rounds as they come in and plotting where it originated from. 72 hours is a good estimate for how long that artillery battle would last; same estimate I've seen elsewhere.

But the concern of casualties are not necessarily from shells impacting, but the panic and disruption in order that comes from it. NK can cause enormous hardship just by flinging a few shells. They can hide many of their batteries and string out the battle by revealing pieces on day 3, 4, etc,. Even if they get destroyed, and even if they only get a few shells off, you'll have a news report saying shells are still falling on Seoul, and it will be a tremendous morale hit.

But the window is closing on how well the NK artillery will continue to be a credible threat, hence the rush for nuclear weapons.

<comment><USER20> There would be no day 3 or 4. The US knowns in detail every inch of the DMZ and the NK side. The US counter-battery is the best in the world. Every NK gun that fires would be bracket and destroyed in the 1st 30 minutes. After they are gone any other mapped location would be hit for good measure. The ROK Army and the US Army would start to roll right over the DMZ in the 1st hour. The Air Force and Army attack helicopters would wreck any armor the NK have very very quickly. The NK Army around the DMZ will collapse in the 1st day.

The only real issue we would have to worry about is NK using a nuke on Seoul or Tokyo. That is the major issue and it is why NK will never give up on their weapons. It is the only effect threat they have.

The US planners have sorted out the conventional war issues a long time ago. It is figuring out how to be 100% sure to remove the Nukes from the equation that has stopped us from just stepping on Kim like a roach and he knows that. That is the reason for the Nukes.

<comment><USER19> I'd sure like to believe you're right. While I have every reason to believe the allies would prevail, I'm also wary of overly optimistic timelines.

Let's hope it doesn't come to that.

<comment><USER20> I hope so too. For the most part people do not understand just how over powered the US military is compared to the rest of the world. The worlds largest Air Force is the USAF, the world 2nd largest Air Forces the US Army.

The surgical dismantling of the air defenses around Baghdad in the 1st gulf war was a complete and udder-shock to the Russians. It was the 3rd largest and sophistcated in the world. We removed it in 48 hours for almost no loss. That was with 1980 tech where you needed someone to hold the lasers on target.

We could have ended the 2nd Iraq war and Afganistain in a few months if the military was under the same rules of engagement as WW2. However the destruction and civilian death would be appalling. If there is a war started by NK it is very likely the military would not have the constrains placed on it like Iraq or Afganistain. It would most likely look like WW2. Think Dresden.

The job of the military is to kill people and break things. When they are told to win without the limits we place on them now it would be terrifying.

PS. I know people will ask. Let's say you are in a city and there are baddies in a building shooting at you. Right now because of constrains to civilian damage, you get the fun job of attacking the location to clear them out with your squad. It sucks and someone on your team is likely to get wounded. If the limits are removed, you call in a fire mission, building is removed from planet, move on to next one. That is what a war with NK would look like. Are we evil for doing this? I am not sure. I believe that fighting this way will end a conflict much quicker over all and in the long term be better for all those involved.

</comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER21> I've been wary about the Chinese gov's honesty after the economic reparations after THAAD deployment in Korea. (NK made nukes, so US deployed THAAD to defend against NK nukes, and PRC gov. got angry for some defense-only 'weapon')

Moreover, the Chinese gov. has been sending NK refugees back to NK, even though it knows those people won't end well.

But anyway, +1 for Chinese gov. on this stance - I guess this might be a start for a morally better China, a real Big Man country.

<comment><USER22> > NK nukes, and PRC gov. got angry for some defense-only 'weapon'

This "defense-only" weapon upsets the decade-old nuclear balance of M.A.D. because the THAAD radar is sensitivity and location weaken China's nuclear retaliatory ability.

<comment><USER21> then the Chinese gov. should have forced NK to give up its nukes in the first place. It can, but didn't, so US and Korea have the reason to deploy THAAD.

Chinese gov. should explain why it let NK have nukes before blaming 'power balance'

</comment></comment></comment><comment><USER23> Question, will this have a noticeable impact on the N.K. economy or is it more of an inconvenience?

<comment><USER24> I don't know about the economy at large, but this will certainly be more than an inconvenience to many of the Kim family's wealthy and influential friends.

<comment><USER25> This is borderline off-topic, maybe a bit naive even, but I can't help but ask as I'm genuinely curious and don't know.

What do the 'wealthy' look like in NK? Is there an upper class of non- relatives and, if so, via what means -- government ties (business or personal)? What do they do on a daily basis, for work, fun, etc? It just seems to isolated, and perhaps that's my internet adoration speaking -- but is there a class of wealth in NK, what does it look like, how does it come to be?

And I'm honestly curious: if there is a wealthy class, what do they do for fun/enjoyment/entertainment purposes -- and how will this impact that?

<comment><USER26> I was watching a portion of Michael Malice with Joe Rogan[0]. Michael wrote "Dear Reader: The Unauthorized Autobiography of Kim Jong Il". He actually mentions the upper class in NK.

It's over 2 and a half hours long, but I like Rogan's interviews they go by pretty fast.

[0]: [https://www.youtube.com/watch?v=5B_idqiEoUE](https://www.youtube.com/watch?v=5B_idqiEoUE)

</comment></comment></comment></comment><comment><USER27> Most of his behavior is junk behavior and can be ignored. Obviously, if he does something harmful, that should not be ignored, but most everything else can and should be. Give him no response that he can use to put in front of his people; Nothing he can use to spin to show how powerful he is. Ignore it. Take the control away from him.

But always keep an eye out for him doing something even remotely good and praise him for that. Send over food or whatever else his country may need. Reward the behavior you want to see. Ignore the behavior you don't.

</comment><comment><USER28> Not long ago I was shown this:

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

Interview of 2 ex-NorthKorean. It's informative (not much pathos or sensationalism even considering the context)

</comment><comment><USER29> I won't believe that China is actually serious about reining in North Korea until they stop all imports from North Korea.

</comment><comment><USER30> Historically Korea had been a loyal vassal state of China for thousands of year. China had defended Korea against various barbarians from Mongolia plateau, Japan(multiple times) and America more recently.

The reason NK still exists is not USA's mercy or NK's nuke, it's because it's neighboring with China & Russia. Same thing applies to Vietnam.</comment>


If not SICP, then what? Maybe HTDP? - <AUTHOR> http://stevenrosenberg.net/blog/programming/lisp/2018_0226_if_not_sicp_then_what <comment><USER3> "that make me jump through intellectual hoops made of mathematics"

There is actually surprisingly little mathematics in SICP. What is does have are mechanisms that are then analysed and modelled, after which the mental model is adapted so it can be turned into computational model that is a faithful representation.

Some of the presented mechanisms are mathematical in nature, but you don't need a mathematical background any more than you need an economics background to write, say, a banking application.

"make it hard for me to learn the actual programming."

Depends on if you see "actual programming" as the mental discipline of correctly representing a part of the real world into a computational model.

If you see "actual programming" as typing in characters on a screen until they compile, then ship them and get absurd amounts of money for it, then sure, SICP might not be for you.

"without going too deep into the quirks of a single programming language"

SICP is not about scheme, has never been about scheme, will never be about scheme.

You will not emerge a "God of the Lisps" from SICP. It might, however, clue you in about what's actually happening when programming, in _any_ language of choice.

<comment><USER4> I agree with everything you say. Just want to add that SICP had a context: it was designed to be an introductory computer science course designed for university engineering students (including CS), almost all of whom take calulus in their first year, if not earlier. This was probably a valid assumption back in the day, but clearly there is a more diverse audience now.

Anyway, I absolutely agree SICP was never about Scheme per se, or even functional programming. Scheme is nice as a teaching tool because, as Sussman likes to say, you can teach everything you need students to know about the language in one lecture. (Not even all of Scheme, mind you, just what you'd use in a 1-semester course, which back when I took 6.001 meant R4RS minus macros and continuations.) There's certainly always been pressure to use more "practical" languages. But back in those days, there weren't the options there are now. Any derivative of C, especially C++, would end up being as much about the language as about programming concepts, if not more.

I think the thing about SICP is that while it makes some minimum demands about mathematical background, it makes a lot of demands about intellectual maturity. It took me years to appreciate many of the points it makes -- as I got more experience, different parts of the book start to resonate. On the other hand it's stayed relevant all these years, at least for me personally.

<comment><USER5> Indeed, the context reflects the origins of CS departments. They are always were part of physics school and later electrical engineering.

All the famous CS people over say 60 started in physics or EE.

<comment> dan-robertson This might be true in America but in Europe it is common for the CS department to have been an offshoot of the mathematics department.

<comment><USER4> In the US you find both. More commonly CS came from electrical engineering, but you do find some departments that started as part of mathematics. In any case, as other commenters said, early "computer scientists" often came from physics, math, electrical engineering, etc. (Abelson & Sussman themselves had PhDs in mathematics.)

</comment></comment></comment></comment></comment><comment><USER6> I think programmers reaction to the mathematics in SICP is completely hysterical - in the sense of hysteria, not comedy. For example, the author- professors who wrote HTDP, quoted at length in this article complain about using 'complex domain knowledge' and the author of the blog post does as well, but the running example used is _literally arithmetic_. In particular:

Section 2.1 starts by building a data type of rational numbers, then extends it to interval arithmetic In section 2.4 this is extended to Complex numbers, which also adds the complication of multiple representations of a data type (rectangular vs polar). In section 2.5 these are unified with a generic arithmetic package. Which is finally extended to operate on symbolic polynomials, creating a symbolic algebra system.

So you can see, the authors complain about 'domain knowledge', but the example was surely chosen precisely because everyone _already_ understands these relationships so well! It's a relatively nontrivial example, technically simple but structurally complex, that everyone already understands intuitively, so that you can get right to work thinking about data abstraction techniques - and in this example we go all the way from introducing the notion of an 'abstraction barrier' for the first time, to data-directed programming & message passing!

\-----

The other mathematical section is 2.3, which is the infamous calculus section. Again the reaction is completely over the top - there's no 'deep dive', you don't need a 'solid foundation' in calculus, etc. The appearance of calculus is no more than implementing a couple of _symbolic transformations of data_ , and all 4 of the rules are provided for you. You don't actually _use_ calculus to do anything, so that if you don't know calculus, you can still write the program, it'll just be a bit more boring not knowing what it means. This section of the book is like 5 pages long, out of a 500 page book, but it's all we hear about...

<comment><USER7> "already understands these relationships so well"

Is that true for complex numbers?

<comment><USER6> Complex numbers as 'cyclic numbers' is not widely understood. What is understood is how they fit into the arithmetic 'hierarchy': how the real numbers embed into the real axis, and how the operational rules for addition and multiplication work. However SICP also asks us to implement the polar form of C to illustrate multiple representations of the same data type, so I have to admit that part might require some additional explanation for many students.

</comment></comment></comment><comment><USER8> Everyone on here is very excited about HTDP. You are mostly very smart people, and not representative of the typical CS student starting off. Many of you are driven and have rich STEM backgrounds that you draw upon. Therefore, I want to point out that there is no substantial evidence to prove most of the claims of "success" that the HTDP community claims, with regards to novice learners. There are certainly people who HTDP works amazingly for - I have met many brilliant folks who it resonates with. But I have met far more students who it does not work well for (I would describe them as having almost low-key PTSD from their CS1). The curriculum is too artificial and disjoint from the rest of their CS degree. I have met instructors who make it work fabulously, and their students apparently really buy into it. But overall, the claims that HTDP leads to better students is not proven by any literature I can find.

The closest thing I can find for good evidence is Fisler '14 [1], which did indeed suggest that HTDP teaches Functional Decomposition in such a way that CS1 students are better able to tackle short-but-complex problems by the end of their CS1. I find this work compelling, and I look forward to applying the ideas inherent to my own courses. However, in the decade-plus that HTDP has been around, I have not been able to find any long term studies that back up the slew of claims made about how we "should" teach CS1. Language and paradigm arguments in general have not really born out any evidence[2].

I'm not saying HTDP is bad or Python is good or C++ is ideal. I'm saying we don't know much about any of this stuff. Relying on theoretical arguments is dangerous when it comes to pedagogy. For every positive experience you can share about HTDP, I can share a negative experience. It's great if you found a curriculum that works for you. But be very, very careful about whether you believe that curriculum should work for everyone.

[1] [https://dl.acm.org/citation.cfm?id=2632346](https://dl.acm.org/citation.cfm?id=2632346)

[2] [https://www.researchgate.net/publication/329544316_Introduct...](https://www.researchgate.net/publication/329544316_Introductory_Programming_A_Systematic_Literature_Review)

<comment><USER9> _The curriculum is too artificial and disjoint from the rest of their CS degree._

That was my takeaway from CS61A at Berkeley. I thought that Scheme was incredibly elegant and I was disappointed that we never used it again. The profs sure were pleased with themselves at the end of CS61A and I imagined later that they thought their preferred outcome would have been that we pursued a PhD using Jikes. SICP was the text which everyone bought and no one (that I knew) read and I tried. We had no assigned readings; it simply meant to be worshiped. It comes up on HN but never in conversation. No one quotes SICP.

I'll look at HTDP.

<comment><USER10> As I remember it, the book SICP itself wasn't really the core of CS61A... the lectures and slides were, and they drew off the concepts in SICP. No one read the book, but we learned from the (fairly good) lectures and explanations of the concepts, and especially the projects of course.

Those concepts were and remain a foundation for how I think about programming—at the level of elegant structure and short modular thinking. Software engineering and architecture is something different, and has its own class (CS169) which was far more valuable and important for those skills at that higher level.

I dunno. It was a good foundation. I've looked through SICP and I still recognize the concepts, the lectures matched it fairly well. But you're right—no one read the book.

<comment><USER11> Are you guys talking about an older iteration of 61A? It doesn't really make sense to read SICP nowadays if the course is taught in Python.

<comment><USER10> Must be, I'm pretty old. :) Would have been 61A circa 2002.

</comment></comment></comment></comment></comment><comment><USER12> Hm. Not entirely sure what to think.

I find SICP to be a mind-blowing book - a truly enlightening experience. But not, perhaps, entirely suited for beginners. I first started reading it four years ago, just over two years after I had started to teach myself programming in high school. Although I already found it interesting and its functional programming approach did have a lasting impact on my programming style, I recall finding it somewhat too challenging on the whole and didn't get very far. Half a year ago I started it again and have been blown away by the elegance and fundamental importance of the concepts it presents (although I'm still not done yet). For one thing, I understand the foundation of OOP a lot better now than I ever did from reading Java books...

So if the author is saying that SICP is a bad programming textbook because it doesn't include a "How to build a webapp in 12 easy steps", well, he rather missed the point. But if he is arguing that it perhaps isn't the most suitable textbook for a first year CS student fresh out of high school - that is a fair criticism.

<comment><USER13> It is useful to consider the audience the book was written for: first-year students at MIT in the 1980s. That was a formidably bright and meticulously prepared group. Many of them already had some programming experience from high school.

It's not too surprising that a book tailored to such a crowd's particular needs is not particularly suited to other students, whether less bright, less prepared, or simply true beginners to programming.

<comment><USER14> Agreed. Fashion and perspective change with time, and the approach taken in SICP doesn't match up well with the cognitive impedence of 18 year olds today, some 40 years after the book was written.

Then, PCs were not yet integrated in university teaching. It was still common for students to sketch out new software in pseudocode on paper before sitting down at a terminal they'd waited hours to get access to. And of course, editors were crude, IDEs nonexistent, and the compile-run-edit cycle often took 15 minutes or longer.

Programming was more deliberate, involving absolutely no cutting and pasteing. Coding then was much closer to writing a proof, which goes a long way to explaining why SICP put more emphasis in principles, formality, and derivation than we do today.

</comment></comment></comment><comment><USER15>
        They may even come to the conclusion that programming is a
        shallow activity and that what truly matters is an
        understanding of domain knowledge

THE HORROR ;)

In all seriousness, IMO we'd have much better programs if developers spent more time thinking about domain knowledge and less time believing that "programming" in isolation is the important part.

<comment><USER16> We need both. Not enough domain knowledge and you end up with software that isn't a great fit for what it's trying to do, but without enough computer science and software engineering knowledge and we end up with all of these stupidly memory-and-cpu-hungry applications that are all the rage these days.

<comment><USER17> Clearly. If people want code written by people with a lot of domain knowledge but not a lot of software engineering experience, look at the code written by electronic engineers who just need to write a little software (typically for microcontrollers) to interact with the hardware, the true focus of their craft.

Some of the most horrendous, fragile, unmaintainable spaghetti code I've seen in my life was written by electronic engineers. And some of them were true masters of their crafts, it's not like they lacked the cognitive abilities to write good code, it's just that they didn't care at all, it just had to accomplish the function they needed. Meanwhile I'd see them spending a lot of time making sure things were routed nicely and PCBs looked nice.

<comment><USER16> That's a great example! Unfortunately.

<comment><USER18> As is scientific code.

</comment></comment></comment></comment></comment><comment><USER19> There are two models for CS education. One model is for students who want to learn the theories of computer science and be computer _scientists_ , and the other is for students who want to be programmers.

SICP is the foundation for people who want to be computer scientists. That's not everyone.

But from what I've found, all the top CS schools create computer scientists, and the other CS schools create programmers. While it's easy for a computer scientist to make the jump to programmer with just a little guidance, it's much harder to go the other way.

The world mostly needs programmers though, with just a reletively few computer scientists to come up with the new innovations. So it seems like everything is working out ok.

Although I'm really glad I got to learn the fundamentals of computer science with a SICP based intro class.

<comment><USER20> > While it's easy for a computer scientist to make the jump to programmer with > just a little guidance, it's much harder to go the other way.

I don't think it's actually that easy for a computer "scientist" to unlearn all the idealistic stuff that can actually be counter-productive in a real- world programming environment, particularly if they're enamored with languages like LISP or Haskell. These people easily get depressed in a "real" programming job.

Whether it's hard to go the other way doesn't really matter. There's no pressure to go the other way. The only healthy place for computer scientist types is academia, or maybe certain R&D positions. These are few and far between.

<comment><USER21> Rust is becoming very popular. What is Rust though, if not a strict (i.e., non-lazy) Haskell with different syntax, linear types, and less polymorphism? I think a CS type who loves Haskell will be right at home with Rust. Or modern C++. Just as a CS type who loves Lisp will also be able to make the move to Rust or modern C++. Java, maybe not so much :)

<comment><USER20> > Rust is becoming very popular.

For actual jobs? I don't see any evidence for that.

</comment></comment></comment></comment><comment><USER22> It's always interesting seeing the textbooks that are renowned by professors/people with prior knowledge, yet disliked by actual students. The Feynman Lectures on Physics is a pretty famous example (iirc, the actual course was received pretty negatively by students).

I wonder how many people have actually sat down with a bunch of students and done a real experiment with textbooks. It's quite easy to think that a textbook is good when you already understand the material. Only by getting feedback from real students can you truly figure out whether a textbook is good. It'd be interesting to do a course with two different textbooks and the exact same professor and compare feedback/results. Perhaps they could even take the same final exam. Preferably at an average university. One problem with using textbooks written by MIT professors (such as Artin, Strang, etc.) is that MIT students are far stronger than average and can generally skip certain elided steps that other students cannot.

<comment><USER23> > people with prior knowledge, yet disliked by actual students

This is the key!. I was about to say SICP was great then, yeah, I read it only when get interest in build compilers and after 20 years on the craft.

I think you need a progression on material:

1- Start with a highly practical book more alike build little experiments/programs

"Build a pacgam game" "Make a calculator", etc... ie, do a single pass for the minimal amount of info necessary to build a practical yet rewarding project.

2- Now the student have accomplished their first success, slowdown a little and put a small amount of theory here and there, but put focus on:

"Discipline and follow good practices" then re-do the projects right this time.

To build a analytic mindset move to:

3- How a computer think, using debuggers, disassembles, etc.

You get your hands dirty and see the magic behind the magic

And at the final step (is necessary to put some more steps before, just wanna get to the point):

4- Finish with a well round, deep and wide treaty about the field like SICP, so with some practique behind you can actually see what you have done and how it relate to the new info you are getting now.

Also, this will broad your horizons and open the appetite to get in the deep more.

\----

I think is to be like how is learn to cook. You start doing simple yet good dishes, without worry to learn first the theory. You move to more challenge, learn techniques tools and tricks of the trade. Finally, move to see the theory behind, round your mental framework and challenge yourself in come with exotic, new dishes...

<comment><USER22> That's very well put. I've actually really wanted a "cookbook" for compilers. Basically small, self contained lessons for writing a particular part of a compiler. I.e. here's how to write a typechecker, or how to write a garbage collector. The closest to that I've found is Crafting Interpreters. A lot of the compilers textbooks focus on the theory or general concepts, which is great, but I want to get my hands dirty. I'm not reading the book to learn the theory of compilers; I'm reading to book to write a compiler.

<comment><USER24> There is a great paper by Abdulaziz Ghuloum, An Incremental Approach to Compiler Construction, that is pretty much the cookbook you want: [http://scheme2006.cs.uchicago.edu/11-ghuloum.pdf](http://scheme2006.cs.uchicago.edu/11-ghuloum.pdf)

"We show that building a compiler can be as easy as building an interpreter. The compiler we construct accepts a large subset of the Scheme programming language and produces assembly code for the Intel x86 architecture, the dominant architecture of personal computing. The development of the compiler is broken into many small incremental steps. Every step yields a fully working compiler for a progressively expanding subset of Scheme. Every compiler step produces real assembly code that can be assembled then executed directly by the hardware."

There is also a work-in-progress effort to write a more extensive textbook that follows the same approach to teaching compiler development, using Racket instead of R5RS Scheme: [https://github.com/IUCompilerCourse/Essentials-of- Compilatio...](https://github.com/IUCompilerCourse/Essentials-of-Compilation)

<comment><USER25> I was recommended that paper by someone else. Just need to get around to reading it :)

The main roadblock I'm having right now is typechecking. I've implemented Hindley Milner in Haskell and played around with Turnstile, but I still don't know enough theory to invent my own type rules for an imperative language. Something like "Type Theory for the Working Programmer" would be excellent. I just got a copy of TaPL, so maybe I'll just use that.

</comment></comment></comment></comment></comment><comment><USER26> I can fully recommend HtDP for beginning programming - tried various options for my 11 year old. I needed it to involve very little help from me - <USER2> some scratch, mit50x, both which helped but did not spark and sustain interest.

Then we came across [https://www.edx.org/course/how-code-simple-data-ubcx- htc1x](https://www.edx.org/course/how-code-simple-data-ubcx-htc1x) \- love it and does not need any help from me :) planning to move on to [https://www.edx.org/course/how-code-complex-data-ubcx- htc2x](https://www.edx.org/course/how-code-complex-data-ubcx-htc2x) after that!

edit: corrected typos

<comment><USER27> Do you mean the online HarvardX CS50 course? I started it when MOOCs were first appearing, and it includes Scratch. It looked very enthusiastic and buzz-worthy to me (which can be very good for a lot of people). However, past students doing a music and dance routine on stage about how exciting it had been, and the first lectures concluding with announcements of pizza parties with Facebook recruiters was too much for me, in that I felt too old.

Alternatively, the MITx 6.002 course on Computational Thinking is also for undergraduate students, but it had a greater focus on programming being integral to the sciences and other fields. I don't recall the the curriculum exactly, but even though the course is an introductory one I think some of the concepts might be a little daunting for a young teenager.

In addition to the UBC courses, another introductory treatment that won't overwhelm to a committed young learner is the DartmouthX C Programming with Linux. One of the instructors, Petra Bonfert-Taylor, taught a very accessible introductory complex analysis course on Coursera, and seems especially interested in _first experiences_ students have with topics so that they are not discouraged. She has written a number of articles on teaching an introductions to new subjects.

<comment><USER26> my bad - yes, I meant the Harvard CS50 course. Thanks for MITx 6.002 and DartmouthX C Programming with Linux - The DarmouthX one would be a good second course if the interest still continues.

</comment></comment></comment><comment><USER28> The audience that SICP was written for seems to be basically a younger, roughly freshman-year Gerry Sussman, with all the advantages and disadvantages that entails.

I haven't done HtDP yet. I love _The Little Schemer_ [http://www.ccs.neu.edu/home/matthias/BTLS/](http://www.ccs.neu.edu/home/matthias/BTLS/) , but I can't recommend it unequivocally, mainly because I've found (somewhat to my surprise) that it's not accessible to all programming beginners without quite a lot of extra in-person tuition. (And I'm talking about the early chapters here, not chs. 7-10 or chs. 8-10.)

<comment><USER29> The book is written for freshmen at MIT, not your average high school grad. You're expected to have a solid foundation in calculus to get admitted to MIT.

This is what everyone seems to be forgetting.

<comment><USER30> Was that true in the early '80s, when SICP was presumably developed (it was first published in 1985).

I know that at Caltech in the early '80s, a majority of incoming students had not had calculus in high school. I would expect MIT to be similar.

<comment><USER31> 6.001 was a second semester course, all incoming students had already completed a semester in undergrad calc and physics.

[http://www.gigamonkeys.com/code-quarterly/2011/hal- abelson/](http://www.gigamonkeys.com/code-quarterly/2011/hal-abelson/) "There's a tremendous amount (of math) in this 6.001 book. That's partly because we were writing it for MIT. You want to talk about higher-order procedures, so the obvious thing you can do is you can express the idea of an integral. So that's an obstacle for lots of places. Remember, at MIT the context we were writing in is every person who took the course had just had a semester of calculus.

We actually did some versions for the Humanities faculty, where we didn't do that at all, and we effectively started with the data structure chapter and then talked about the ideas for how do you structure and manipulate data, and then do abstractions over that."

HtDP is similar to their other version, starting with data. Author of that book has a good talk about creating a compsci curriculum [https://youtu.be/5c0BvOlR5gs](https://youtu.be/5c0BvOlR5gs)

</comment></comment></comment></comment><comment><USER32> I think anyone reading the book with a determination to drop their intuitions in favor of the book's concepts will find it much easier going, and tremendously worthwhile.

I get why readers don't do that. There is very little written so well that it deserves that trust. Generally we have to step back from something and ask "what does that mean? how do I reframe that into something I can understand?" Because the material's models are too poorly thought out to be useful or too poorly communicated to be discovered. Trying to adopt such models is futile.

But for me, SICP is one of those rare books where I am better off trying to absorb its frameworks, rather than constantly trying to reframe the material into something I understand.

When I step back and _think_ the way the book suggests, the problems solve very quickly. When I try to get a solution from some combination of my intuitions and known tricks, I thrash about endlessly.

It is a very carefully written presentation of profound and important ideas, and deserves to be approached differently than the vast majority of books.

</comment><comment><USER33> Both SICP and HTDP are very good books. SICP has little more 'attitude' in it, but I think its neutral feature. If you want to learn programming as something between algorithms and programming languages, I suggest these four 'Lisp' books:

1\. SICP (Structure and Interpretation of Computer Programs)

2\. HTDP (How to Design Programs) [https://htdp.org](https://htdp.org)

3\. LiSP (Lisp in Small Pieces),

4\. PAIP (Paradigms of Artificial Intelligence Programming) [https://github.com/norvig/paip-lisp](https://github.com/norvig/paip-lisp)

SICP and HTDP are different but serve the same purpose. LiSP is about interpretation, semantics, and compilation. PAIP by Peter Norvig can seen as elementary programming book that uses classical AI as a subject. You learn both.

I don't know what to think about this, I haven't read it: SICM (Structure and Interpretation of Classical Mechanics)

<comment><AUTHOR> Which among these teach me functional paradigm through LISP the best? Or would you recommend some other book that uses a small language to gain a good grip over FP? Haskell, Scala and Clojure are intimidatingly big.

<comment><USER33> HtDP or none of them.

Functional paradigm has two flavors:

1\. Functions as first class objects in the language and enabling the functional style programming.

2\. Pure functional programming. Not a style, its functional programming.

IMHO learning the first kind helps relatively little when you want to learn second kind and vice versa.

Lisp is multi-paradigm language or "Lisp paradigm" language family. Because functions are first class objects it facilitate functional programming of the first kind. Some Lisps are geared towards using functional style more than others.

<comment><AUTHOR> So for second flavor, what would you recommend with focus on smallness of language?

<comment><USER33> I have no idea.

I have only read Thompson's Haskell: The Craft of Functional Programming and some old ML books I can't name. I have no idea if it's a good compared to other FP books.

<comment><AUTHOR> You were very helpful in this discussion. Thank you. :)

</comment></comment></comment></comment></comment></comment><comment><USER34> I have found that the best way of learning the HtDP approach to program design, at least for me (I find the book itself a bit dry), are the EdX "How to Code" free moocs [1] [2]. The instructor is fantastic. It completely changed the way I program and design.

If you like the approach and want to learn more, like, for instance, how to extend it to OO design, I list below links to several courses (most, except for the last one, offer enough material to complete them on your own, but I couldn't find any videos) at the university where HtDP's main author, Matthias Felleisen, is tenured (North Eastern). The courses are listed in the order in which they should be taken, and the rationale is explained by the professor in the paper "Developing Developers" [3]:

* CS 2500 - Fundamentals I [[https://course.ccs.neu.edu/cs2500/](https://course.ccs.neu.edu/cs2500/)]

* CS 2510 - Fundamentals II - Introduction to Class-based Program Design [[https://course.ccs.neu.edu/cs2510/index.html](https://course.ccs.neu.edu/cs2510/index.html)]

* CS 2800 - Logic and Computation [[https://course.ccs.neu.edu/cs2800/index.html](https://course.ccs.neu.edu/cs2800/index.html)]

* CS 3500 - Object Oriented Design - Spring 2018 (scaling up the 3 previous courses) [[https://course.ccs.neu.edu/cs3500/](https://course.ccs.neu.edu/cs3500/)]

* CS 4500 - Software Development [[http://www.ccs.neu.edu/home/matthias/4500-f18/index.html](http://www.ccs.neu.edu/home/matthias/4500-f18/index.html)]

[1] [https://www.edx.org/course/how-code-simple-data-ubcx- htc1x](https://www.edx.org/course/how-code-simple-data-ubcx-htc1x)

[2] [https://www.edx.org/course/how-code-complex-data-ubcx- htc2x](https://www.edx.org/course/how-code-complex-data-ubcx-htc2x)

[3] [http://felleisen.org/matthias/Thoughts/Developing_Developers...](http://felleisen.org/matthias/Thoughts/Developing_Developers.html)

<comment><AUTHOR> I happen to best learn through video lectures more than reading.

Thank you for your effort. I am starting with these.

<comment><USER31> Could try both, the book (HtDP) is more rigorous than those two MOOCs as they're meant just as an intro where you progress into many more courses (as part of the micromasters on software development) while the book is a full grounding in CS 101. Somebody correct me if wrong but I don't remember any big-O analysis in the MOOCs or the parsing XML chapter, traversing graphs, the content on fixed-size arithmetic, plus the 500 or so exercises the book has compared to the three or four at end of each unit in the MOOCs. For example the sierpinski triangle assignment in the MOOC is pretty straightforward, but in the book you also generate a fractal savannah tree using trigonometry functions that isn't so straight forward, but when you see how they do the generative steps in the book you get that 'eureka' moment learning about Bézier curves. [https://jeremykun.com/2013/05/11/bezier-curves-and- picasso/](https://jeremykun.com/2013/05/11/bezier-curves-and-picasso/)

<comment><USER34> Agreed. But I would still recommend those interested to start with the online courses. The reason is that they hammer in the core principles that underlie all of systematic program design, with plenty of hand holding and exercises, and spending the right amount of time on each new concept, which is a lot harder with the book alone. The instructor is so good that in 10 mins one will understand what would otherwise take more than one hour with the book, at least in my case. After completing the moocs one will have a rock solid foundation from which to tackle more ambitious problems, including the ones you mentioned. Only then would I open the book.

</comment></comment></comment></comment><comment><USER35> > If not SICP, then what? Maybe HTDP?

I can recommend "Concepts, Techniques, and Models of Computer Programming" (CTM or CTMCP).

Book's page: [https://www.info.ucl.ac.be/~pvr/book.html](https://www.info.ucl.ac.be/~pvr/book.html)

Quote from www.c2.com:

"Like SiCp, CTMCP is first and foremost a book on programming, not on Oz or Scheme or anything else. And if SiCp is the reigning king of such books, CTM is a worthy challenger to that particular throne."

<comment><USER16> I found CTM a harder book to read than SICP for some reason, so if the author finds SICP too much, then they probably won't like CTM. I personally thought SICP and CTM were both great books.

</comment></comment><comment><USER36> I haven't read HTDP and can't authoritatively comment on it /have no idea how it compares to SICP, but I found this statement pretty ridiculous:

> While SICP (yes, everybody uses the acronym) is considered a holy grail for > serious computer scientists, it's hella hard to figure out. For me, > programming "methods" that make me jump through intellectual hoops made of > mathematics make it hard for me to learn the actual /programming/.

I started learning how to program in high school using whatever resources I could find (my school didn't have any programming courses beyond an introduction to 1980s BASIC, so independent study was the only option), initially following the very nuts and bolts-oriented instruction in C++ Primer Plus (I arbitrarily chose this as a good intro textbook based on my limited understanding of what constituted 'real' programming versus BASIC). I spent the better part of of 2 years making unremarkable C++ programs that were little more than basic math and control flow mashed together with the C++ standard input/output libraries.

At some point, I happened upon SICP, and learned more about computer science and programming in six weeks than I had in all of my previous self-study. I hold that it was, and still is, a remarkably succinct and understandable introduction to the fundamental concepts that underlie computer science. Yes, math was involved, but I didn't need to learn anything beyond my basic high school algebra education to understand how that math translated into programs: SICP did an excellent job of explaining how programming related to that math. Most importantly, it was /fun/: working through SICP made me feel like I was learning a new way of thinking, not just learning how to translate something I already knew into computer language.

Other descriptions of HTDP suggest that it combines my painful slog through the nuts and bolts of programming (albeit more succinctly and less painfully) with SICP's math/CS elements, so it's probably a better textbook for tackling both at once. However, it's crucial that it does both: to focus only on "actual programming" as the author suggests is probably a surefire recipe to convince students that computer science is a dull field consisting solely of writing instructions for computers, with no thought whatsoever into what instructions make sense or why.

<comment><USER37> So you had two years of prior experience with languages like C++ before starting on SICP. That makes for a very different experience than a first introduction to programming.

</comment></comment><comment><USER38> A couple of historical clarifications to Sedgewick Wayne's points:

> [SICP] set the curriculum for "beginning" computer science

> All [examples and exercises] use complex domain knowledge. ... Some early > sections and the last two chapters cover topics from computer science ...

Why the square quotes around "beginning"? At the time the course, 6.001, was launched it was quite reasonable to assume that an MIT undergrad might arrive at the Institute never having previously used a computer, much less programmed one. This was truly an introductory class and while required for all EE and CS students, was intended for any undergraduate. The material in the examples all covered core subjects every student needs in oder to graduate, or else were computer science topics that should hardly shock someone taking a _computer science_ class.

Some of the other criticism is reasonable in light of the authors' desire for a slightly different approach. 6.001 was and is the basic introductory class and a CS student will take other classes which will address different aspects of program design and application. Choosing a different time of introduction for different objectives is hardly unreasonable.

(And I don't know why object-oriented programming is somehow thought to be in opposition to the principles of SCIP; the latter's heart is abstraction and composition which are the whole point of object-oriented thinking, right?)

<comment><USER39> All very interesting, but what do Sedgewick and Wayne have to do with any of this? Your first quote is from the post's author (Steven Rosenberg says the site header), and the second quote is from the authors of How To Design Programs (Felleisen, Findler, Flatt, Krishnamurthi).

<comment><USER38> Thanks for catching that. Unfortunately it's too late for me to edit my misattributions.

</comment></comment></comment><comment><USER40> I recommend "Concepts, Techniques and Models of Computer Programming" Van Roy and Haridi. While SICP is an enlightening read, much of what it discussed, looked to be methods that do not all mesh together into one overarching discipline or "science" of programming, which is what CTM aims to do(But admittedly it is a much harder book, and I am still only in the very early chapters). Important questions like how programming in the large is different from programming in the small, how some methods scale and how some do not, topics like these aren't perhaps handled by either of the books, if my memory serves right.

</comment><comment><USER41> I think it's worth pointing out why the author's of SICP themselves acknowledge why it was phased out.

Praphrasing, it essentially boils down to the kind of applications developpers of today are writing. People are now mostly slinging libraries they have a superficial understanding of together in a black-box style. So for most proprammers there's a lot of prodding and tinkering and this isn't a skill that SICP teaches.

disclaimer: I don't think I've imagined reading this however didn't bother looking for the reference.

<comment><USER12> If your CS degree aims to churn out programmers ready for industry, then a overview of the currently favoured libraries is indeed what you need to teach. If on the other hand, you want to produce actual computer scientists who know how to think for themselves, the SICP is what you're looking for. (And I would hope that an institution like MIT would choose the latter focus for its program.)

<comment><USER42> I tend to think the goal of a CS education is to form computer scientists. It's just that a lot of people (and articles) think it's about churning out programmers for the industry.

With such a mismatch of expectations, the resulting frustration on both sides is not surprising...

<comment><USER12> I like the German system: We have university CS courses, which tend to be more theoretical, but also universities of applied sciences as well vocational training in IT for the more practical approach.

</comment></comment></comment></comment><comment><USER43> During my time as a student I felt that the computer science department should have been split into two disticnt programs. The first program should have existed in the math department dealing with the theory and mathematics of computation. The other should have been in the engineering school and focused more on actual computers. Hardware, software, operating systems, working in a team, designing large systems, etc. I think I would have gotten much more out of that. Instead it seems many universities created "CS lite" programs in their business schools.

<comment><USER18> Do you realize how much mathematics goes on in the average engineering program?

</comment></comment><comment><USER44> Warning, anecdotes ahead:

I tried to read SICP after about 6 months to a year after learning my first language, and I couldn't get past the part where they turn a recursive function into a tail-call eliminated 'iterator' style recursive function. I understood what was going on, but I just couldn't grasp how to generalize it. Of course, I get it now; you just pass an extra variable in and use it like you would the `i` var in a for loop, but at the time I just couldn't grasp it.

I also had similar struggles with the early use of math problems as examples and other vaguely described algorithms.

Granted, my background is in Music, so I didn't have the domain knowledge that the author mentions, but programming is more about strategic and logical thinking, so I was perfectly able to do that even at an early stage.

I think MIT is right to think SICP is too much for a freshman. Hell, I was already graduated and applying for grad-school when I tried to read SICP and I still struggled.

</comment><comment><USER45> Brown University has a textbook and course called Programming and Programming Languages (PAPL) which is based on Pyret, their teaching language that combines concepts from Python and Scheme/SICP for teaching code and data abstraction.

Freely available here: [https://papl.cs.brown.edu/2018/](https://papl.cs.brown.edu/2018/)

More on the Pyret language here: [https://www.pyret.org](https://www.pyret.org)

</comment><comment><USER46> I'll add that some people from HTDP went onto create Pyret as a new experiment in education:

[https://www.pyret.org/](https://www.pyret.org/)

It's used in the Bootstrap program that teaches it to middle schoolers. Probably pretty easy to learn.

</comment><comment><USER47> I didn't find SICP good or bad, but utterly boring. In fact, so boring that I couldn't bring myself to finish even half of it in 3 separate tries.

Perhaps I should've read it as my first programming book, but that time's long past.

Anyone else had this problem? I'd gladly take tips on how to get over it, since I do honor classics and don't think I'm above them.

<comment><USER48> You're not alone. I forced myself to read through half the book before asking myself what was the point of solving essentially leetcode style problems using only tail-end recursion and glorified linked lists. At no point did I ever feel that the scheme language had any practical applications.

</comment></comment><comment><USER49> People are completely missing the point, even though this article includes the important quote.

In a 4-year Computer Science curriculum, SICP is not a perfect fit for the role it was being asked to play. HTDP was written with the goal of being a better fit in that specific role.

If you are self-taught or otherwise learning in a non-4-year CS program, this distinction is not applicable to you. SICP is great. HTDP is great. They are both great.

</comment><comment><USER50> When I started my Bachelor in Italy (Bologna) I had actually not enrolled yet to the degree, and I was instead following both Computer Science and Philosphy. My plan was to continue both of them, or to choose one. We had this first year programming course taught by a fairly younger teacher (39), Ms Busi: I was expecting not much from it because I thought it would be an introductory course on programming OOP stuff with Java, things that I had done fairly extensively during the high school program. Hower, on the first day, she explained us that we were going to use a language called "Scheme" and that our reference book was going to be freeily available (in general, courses in Italy often require expensive books - sometimes ones that you won't find on the internet since they are written by exactly your little-known professor and will be available in selected book shops of the city), the book was "How to Design Programs". She said that one of the goals of this choice was also to decrease the difference in levels between students: we would use a language nobody knew, and approach a paradigm that nobody knew, and this would have made her (interactive) lessons and the lab practice more interesting. I also remember how she said "the organization of this course is going to be simple: every day, you will come and I will write down a problem on the whiteboard, and we will find a solution. Then, we will find a better, more beautiful solution, and that's it". I could see she knew that this choice was going to upset people, so much that she tried to sweeten the pill by saying "this is how they teach programming at MIT".

Indeed, the course did upset people. I remember how people constantly complained how shitty this decision was, how "people in the 1st year engineering classes are doing real Java programming while we do this shit no employer asks for", some noted how the language was stupid, or in the best case just a toy, useless in "the real world". Thing got worse when some people realized that, contrary to their expectations, they did not know how to program, since they could not do eg. graph traversals once that was stripped of its OOP or Java-like envelope - "I will fail the year because of the bloody scheme!", they would say.

To me, instead, it was revelatory. We did indeed solve one problem per week, and although the problems were less sexy than the ones I was expecting (finding the max of a list is not the coolest thing in the world), promises were kept, and little by little I started appreciating how much you could express with so few lines or predefined functions, leveraging only on very few concepts (eg. recursion), it was different from the programming we had done in high school. It was also a big difference with the university classes of philosphy, where "assistant professors" (underpaid PhD [students]) will come to read you a book AND a comment to it, with very little intellectual work needed from either them or students. I quickly decided to follow only Computer Science. I became no black belt lisper or anything, but that style of programming, of looking at problems, software and the whole field certainly influenced me. I am currently enjoying my role at a FAANG company, and thinking about all of this made me want to write her an email to thank her, but the saddest thing is that I can't do it because right at the end of that academic year, Ms Busi actually died, unexpectedly, at the age of only 39. First year student of CS in Bologna now learn Python programming.

(this is her uni page if you are curious: [http://www.cs.unibo.it/~busi/](http://www.cs.unibo.it/~busi/))

<comment><USER51> Thank you for sharing this story. I'm sorry to hear about professor Busi.

My introduction to computer science was also HtDP and your experience mirrors mine exactly. The people who were the most upset about it were people with exposure to Java and C from high school. Now that I'm in industry, I find I have a better grasp on things like recursion compared to many of my colleagues.

</comment></comment><comment><USER52> This edition is an amazing improvement on the original ebook: [https://sicpebook.wordpress.com/](https://sicpebook.wordpress.com/)

What mathematics? Now that many states have legalized cannabis, SICP should be read while high in the middle of the night. Its nonstop commentary is profoundly amusing. I love for example the passage that presents tail- recursion as the natural form of iteration, and notes about other languages:

"As a consequence, these languages can describe iterative processes only by resorting to special-purpose "looping constructs" such as do, repeat, until, for, and while."

Of course they're right, and yes that's a mathematical view, but they put it so well. All replacement texts are unreadably dry.

</comment><comment><USER53> This quote makes my head hurt:

> "Instead of teaching some currently fashionable programming language" [...] > > "The approach emphasizes the systematic design of programs. Experience > shows that it works extremely well as a preparation for a course on object- > oriented programming."

As someone who gradually transitioned from "object-oriented programming" (or "place-oriented programming in general") with mutable data into largely functional systems with immutable data structures, I find this quote mind- boggling, especially coming from educators.

Moving to functional programming and immutable data structures is what allowed me to build and maintain systems at least an order of magnitude larger than before.

</comment><comment><USER54> SICP is not just a book. They are lectures you can freely watch on the Internet.

For me is one of the most interesting lectures I ever watched. Requires effort because it makes you think, and this is one of the great things about it.

Not for beginners? Yeah, like structural engineering, physics, biology,chemistry, writing, or anything worth something in life you need to work on it, have interest and abilities doing that if you want to become a professional.

Some people want to make University so easy that the title becomes worthless, like happened with University titles inflation in the UK.

</comment><comment><USER55> Working through SICP my main issue was the almost unbounded time commitment- like it will take you between a month to two years. I remember there was a trivial problem that took 5 minutes then apropos nothing the next problem bascially required you to invent the concept of numbers as functions in lambda calculus and required a two day diversion just to understand the answer. Even the best programmers I've known who've done it have said its been a multi month process and without a teacher its so easy to get bogged down.

<comment><USER56> This last week I took an in-person class where we covered almost all of the book: [https://dabeaz.com/SICP.html](https://dabeaz.com/SICP.html)

The instructor David Beazley very skillfully weeded out all the non-essential parts and added one amazing exercise where we implemented the lambda calculus and, funny enough, the ycombinator.

Highly recommend it for anyone who desires to learn this material, can't find the time, and is willing to pay $2500 for the experience.

<comment><USER32> link broken, gets 404

<comment><USER57> Try this. It works: [https://dabeaz.com](https://dabeaz.com)

<comment><USER57> Or this: [https://dabeaz.com/sicp.html](https://dabeaz.com/sicp.html)

</comment></comment></comment></comment></comment><comment><USER58> People who worked through HtDP: what are your impressions?

<comment><USER59> I liked it. My least favorite part wasn't the book itself but rather DrRacket. DrRacket's not bad, in fact it has some slick features, but I don't consider it great either. As an IDE it's good, but as a text editor it's poor. But then again my brain has been poisoned by Vim, DrRacket is _probably_ great for young students without preexisting biases like mine.

I've been using racket for almost all of my recreational programming for the past few years but I don't do it with DrRacket.

<comment><USER41> I will agree with you that any programming language that has the editor locked-in (thinking Mathematica) is simply not worth it's salt.

<comment><USER60> You're free to use Racket with any editor. DrRacket is just one IDE that you can use that is geared towards learners.

<comment><USER37> Isn't HTDP very DrRacket oriented though?

<comment><USER29> My first, first year CS course [1] was based on HTDP and used DrRacket extensively. I, on the other hand, did all my assignments in Emacs. Worked completely fine for me.

[1] [https://www.student.cs.uwaterloo.ca/~cs135/](https://www.student.cs.uwaterloo.ca/~cs135/)

</comment></comment></comment></comment></comment></comment><comment><USER61> I'll just mention [https://composingprograms.com](https://composingprograms.com) a take on sicp mostly in python. A bit of scheme is used in the latter half for doing meta circular evaluator.

</comment><comment><USER62> Another great but lesser known CS book is "The Functional Approach to Programming". It uses Caml (a predecessor of OCaml). Like SICP, it covers a wide range of CS topics, although it's probably not as accessible as HtDP.

</comment><comment><USER63> While this topic is being discussed, what books do folks like for Data Structures and Algorithms?

And importantly, can you contrast why you chose the one you like over others you've worked through?

</comment><comment><USER64> > If not SICP, then what? Maybe HTDP?

TAoCP should be enough for anybody

<comment><USER65> Not really the same thing, SICP is about the practice of programming and the effects of abstraction. TAOCP is more like a recipe book of algorithms.

<comment><USER66> So the answer is, one needs both.

</comment></comment></comment><comment><USER67> I suppose it depends on what people are trying to learn. Programming and computer science are very different things.

</comment><comment><USER68> If I try to access this site I get:

"Access denied. Your IP address is blacklisted. If you feel this is in error please contact your hosting provider's abuse department."

It could be my VPN, but still, not nice.

</comment><comment><USER57> I'm the author of the original blog post, and I wanted to say that SICP, as well as HtDP, and even a book like Robert Sedgewick's Computer Science ([https://www.amazon.com/Computer-Science-Interdisciplinary- Ro...](https://www.amazon.com/Computer-Science-Interdisciplinary-Robert- Sedgewick/dp/0134076427/)) are in a completely different category than more mainstream how-to-program books (like anything from O'Reilly, Manning, No Starch, Pragmatic Programmers) and even the other popular college texts like Y. Daniel Liang's Introduction to Java Programming and Data Structures ([https://www.amazon.com/Introduction-Programming- Structures-C...](https://www.amazon.com/Introduction-Programming-Structures- Comprehensive-Version/dp/0134670949/)) or the book in my intro class, Tony Gaddis' Starting Out with C++: Early Objects ([https://www.amazon.com/Starting-Out-Early- Objects-9th/dp/013...](https://www.amazon.com/Starting-Out-Early- Objects-9th/dp/0134400240/)).

Supposedly all of these books assume (or at least allow for) no background in programming, but I think the reality is that taking SICP or even HtDP into the intro class at a non-elite university or a community college would be a complete non-starter and/or abject failure.

What I'm trying to say is that there is a place for both of these approaches: A deep look into computer science, and the nuts and bolts of basic "get it done" programming.

Should both of these things happen in a single class, or series of classes? I think the answer is yes. But how to do that and not leave non-elite students back on the road is another matter.

I believe that the HtDP authors think that the "domain-specific knowledge" required of SICP was a barrier.

And I also understand how advanced CS students think that a class focused on how to manipulate strings, use loops, deal with variables of various types, and work with basic logic in the context of a specific computer language is NOT computer science.

But in my view, most students -- and all average students -- need to crawl quite a way, then walk, before they can run.

Even Sedgewick's Computer Science, which focuses on Java and has a wealth of great questions/assignments all along the way, could really be a barrier to students who aren't steeped in math and science. I learned some math while going through the book, but I didn't learn so much programming. Liang's approach might be too basic for someone who has already done years and years of programming but is way more approachable for those who have not.

My guess is that many professors tried SICP and had a very poor rate of success. I fully support a selective class that says, "this is very hard, but you will learn a lot and look at the world in a different way, and if you really want to understand computer science, this is the class for you."

But there also needs to be more of a gateway class for future programmers (not necessarily graduate-school-bound CS majors) that eases them into the world of writing code. Offering the basics and sneaking in some CS seems better than doing it the other way around.

In a way, it's like the difference between carpentry and architecture. You can teach people who want to build houses how to design them, but at some point they're going to have to get out a saw, hammer and nails and make something happen.

<comment><USER12> Thank you for this much more nuanced response. Your original post was very critical of SICP in a way that didn't seem to do it justice - I think that's what set of much of the debate in this thread. But if what you say in this comment is what you really meant, I fully agree with it.

<comment><USER57> I am writing from the perspective of someone who isn't a CS major and is trying to learn programming on my own. I am very interested in the CS aspects of programming but am finding it hard to learn it in an approachable and understandable way.

If an "ivory tower" approach is working, I'm on board, but I bet more people get value out of SICP after they have a lot of classes and experience under their belt and not the other way around.

<comment><USER57> Books like SICP are touted -- if not by the authors, then by those who got a lot out of them -- as the one true key to knowledge. I think we all gravitate toward that ideal, and we want one book to teach us everything, but reality is often more complicated, and one person's steak is another person's ... not steak.

</comment></comment></comment></comment><comment><USER69> On htdp.org: [https://htdp.org/2018-01-06/Book/part_prologue.html](https://htdp.org/2018-01-06/Book/part_prologue.html)

"If programming were just about numbers and arithmetic, it would be as boring as mathematics."

What's wrong with this author?

<comment><USER70> "Just kidding: mathematics is a fascinating subject, but you won't need much of it for now."

<comment><USER69> Thanks. It's on a sidebar and I didn't see that. Still, I don't think that's good humour.</comment></comment></comment>


Virgin Nuclear? Can Branson do to atomic energy what Musk did to space? - <AUTHOR> http://www.guardian.co.uk/environment/2012/jul/20/richard-branson-obama-nuclear-technology

<comment><AUTHOR> A follow-up of the very interesting Thorium story here:

<http://news.ycombinator.com/item?id=4912187></comment>


Minimalist Gmail (chrome extension) - <AUTHOR> https://chrome.google.com/webstore/detail/oddhbkghjoccbljmagcgoklbfdjeiinb

<comment><USER2> I was hoping it would make gmail look like the screenshots, but those are just screenshots of the configuration page. Basically, what this extension provides is dozens of check boxes. Each box, when checked, removes one small element (a button, toolbar, etc.) from your gmail. Sometimes it's not easy to tell what element a checkbox will remove. It's okay, but it's tedious and after my first pass I just ended up with a ridiculously bare gmail.com, so I uninstalled it.

<comment><USER3> It was easy for me. If you hover over the text label for each checkbox it pops up an image highlighting which page element(s) are affected.

<comment><USER2> I must have completely missed that. I still wish it just made my gmail look like its configuration page. ;)

</comment></comment></comment><comment><USER4> Protip: leave "Hide Ads" unchecked if you're using Rapportive. I installed this extension and scratched my head for a few days wondering where the Rapportive sidebar was.

(In general, I'm a big fan of Minimalist Gmail to get rid of all the clutter. Gmail has been around for ~7 years now, but I wonder why they still have the "Invite a Friend" panel.)

</comment><comment><USER5> Great addon, but I wonder how long it will be able to hide all of the advertisement elements.

Then again, Chrome allows AdBlock in its extension gallery.

<comment><USER6> I doubt google would change gmail because of this. Google would rather their developers work on things that will bring in more users than have them spend time trying to stop ad-hiding.

</comment></comment><comment><USER7> Kind of ironic, considering Gmail's beginnings.

</comment><comment><USER3> This is the best thing since sliced bread!</comment>


Apple and Facebook application development: A rush for fool's gold? - <AUTHOR> http://fernblog.com/home/2009/8/6/apple-and-facebook-application-development-a-rush-for-fools.html

<comment><USER2> When I think about building software, I think about the long term benefits of the software to humanity, or if I'm working for a particular company, the benefit to the organization.

So if I am going to spend my time developing something, I want it to never go away. Facebook will go away. The iPhone will go away. These are fads.

What people who think like I do often fail to understand, is that most of the world doesn't think like we do. They want money. They want popularity. Even if it is fleeting.

My question is: Where is the balance? Think about investing. If you have a 20 year vision and invest in those companies, you have to have 20 years of patience. Plus, how do you _know_ your vision of 20 years out is the correct one? How do you know how much vision you have? If you consistently think 5 years ahead of the masses, then buy companies that the masses will think are awesome in 5 years.

If you are 3 months ahead or one year ahead, then buy those kinds of companies.

It's the same with building applications. You are building applications ahead of time for a market that will want them by the time you are finished building it. For example, if you build a facebook app and that app is going to take 5 years to complete, well... facebook may be gone by then and you are wasting your time.

So what you are stuck with then, is building applications that don't take very long or are targetted toward a massive population with lots of investment and horsepower behind the app that can be built very quickly. Of course companies that can execute like this can make money building apps for one platform after another making money off the network effects within that platform. It's not just facebook, it's salesforce, quickbase, microsoft, java, oracle, php, the list really is endless...

So, to summarize, how do we determine how much vision we have? How do we determine how long it will take to build an app? How do we determine when the platform on which we build our apps will cease to exist -- if ever?

<comment><USER3> That isn't possible. You can't think long term in an industry that changes every month. You must strike while the iron is hot!

<comment><USER4> The truth lies in between.

You can think long-term while _also_ delivering software for a fly-by-night platform. You just have to understand the difference between an app or business model and various _instantiations_ of that app or business model.

Just because Garmin's software for the Palm OS is obsolete doesn't mean Garmin is obsolete. The iPhone OS was originally developed for the NeXT cube, before many HN readers were born. Microsoft Word was originally written for _Xenix_ systems, then ported to DOS, then the Mac, and finally ported to Windows. The obsolescence of the DEC PDP-7 didn't hurt the Unix platform. The fact that all of Electronic Arts' software is hopelessly obsolete within a handful of years hasn't stopped them from staying in business for decades.

There are apps being prototyped on Facebook and the iPhone today that will have decades of life on one platform or another.

</comment></comment></comment><comment><AUTHOR> I am the author of this blog post about Facebook and iPhone application development. Thank you all for your comments and thoughts. There are some excellent points raised here. Let me expand on my post in several ways, drawing on some of your comments.

Several HNers have suggested that my post misses the point that not all developers for Facebook and the Apple iPhone should be classified as new ventures. I agree, and I could have been more clear in my post. There are at least three types of developers: a) hobbyist/part-timers that are developing applications in their spare time; b) established firms that are porting existing applications over to Facebook or the iPhone for the purpose of expanded distribution or marketing; and c) new ventures that have been founded to develop Facebook and iPhone applications. My post speaks most directly to this last type, new ventures founded to primarily focus on Facebook or iPhone application development. These are the firms that are depending on generating enough revenue from their Facebook or iPhone applications to support and grow a software business. Given the current economics of the Apple App Store (and probably the Facebook platform) I think the outlook is bleak for most of these firms. Of course the outlook would improve if customers' willingness to pay for applications increased, if paid application downloads increased, or if application revenue was augmented through other sources, such as advertising or in-application purchases.

Several HNers have questioned the scenario analysis. The analysis is admittedly rough, as noted in my post. I based the analysis on several assumptions, most of which were informed by publicly available information; e.g., the July 14 Apple Press release, App Store revenue allocation, the App Store top selling application lists, etc. Some of the assumptions are rough educated guesses: the percentage of apps that are free versus paid (I assumed 50%, which is a very generous assumption) and the eventual concentration of the market (10 firms controlling 25% of the market). I believe the scenario I presented is plausible in view of current information. Of course there are many variables to consider and the landscape is evolving quickly, so the scenario I presented might miss the mark considerably. For instance, as noted above, application downloads might increase significantly, willingness to pay might increase, etc. Despite this uncertainty, I believe the analysis is informative because it shows how the current economics of the App Store can not possibly support anywhere close to 100,000 developers, or even 10,000, unless a vast majority of these developers are hobbyists or establish firms not relying on these applications for revenue generation. Furthermore it suggests that very few, if any, new ventures dedicated to iPhone application development will realize the top line revenues that will satisfy a professional investor. In the scenario I presented just 0.01% (i.e., 10/100,000, or one hundredth of a percent) of current developers participating in the iPhone developer program will realize $10-15 million in annual revenues. This is striking given the number of venture capitalists that are financing companies dedicated towards iPhone (and Facebook) application development. Admittedly, venture capitalists will fund the more competent ventures that have a higher chance of success, but what VC would have guessed that the top free and paid applications would include iFart, the Moron Test, and Mirror Free.

Let me be clear that I think there are opportunities in these markets. However, I believe that given the very low barriers to entry combined with the economics suggest that the fluid phase may persist for an extended period of time and the shakeout might be particularly harsh to new ventures. PJ suggested that it's a mistake to build an application for a potentially ephemeral platform such as the iPhone or Facebook. I agree. It seems that the new ventures most likely to succeed over the long-term are those that develop excellent software that are platform agnostic. Does iFart and Mirror Free fit this model? I don't think so.

</comment><comment><USER5> Several posters have taken it as a given that software ought to live for a long, long time. That's a philosophy worth considering, but many people just want to make money.

If you lived in Atlanta during the '96 Olympics, you might have rented out your house for $10K for the month. That's a great "business" even though you know it will fail a month from now. However, you would not be rational to note that rents are now $10K/month and buy up a bunch of houses using that rent as a long-term factor in your business plan.

There's nothing necessarily wrong with building iFart, etc. But, it's absurd to pretend that revenues for fads like these will continue. I am reminded of an article I read about the business of opening up trendy nightclubs. The experienced owners think that it's impossible for a club to remain trendy for more than two or three years. So, they open them but build a business plan that doesn't anticipate long-term revenue with the expectation that they'll build their next one while the current one is still doing well.

Note that I believe Facebook/iPhone apps can be a great extension or component of a long-term business model, but that model can't be predicated on the continued popularity of those platforms alone.

<comment><USER6> I agree.

I think mostly people on HN are interested in making apps that provide real value to users and business for the long term.

Some people just want to get 2 months pay for 1 month's work and make they an iFart app or whatever to achieve that. It's not a long term bet but it makes more than being employed - for some people that is all the care about.

Also, the OP talks about companies being founded but I would guess in most cases Facebook and iPhone apps are people side projects made in their bedrooms or instead of doing consulting work. Those people are realistic and don't expect it to last, it's just a way to make money in the short term, they'd leave if there was more money to be made elsewhere and will probably leave anyway as the race to the bottom plays out.

</comment></comment><comment><USER7> This is meaningless and misses a golden opportunity to compare and contrast the two platforms. Instead it just throws out a bunch of gibberish numbers and compares apples to oranges, states that it's comparing apples to oranges, then continues on with the comparison.

Most "internet" businesses fail. Most restaurants fail. That doesn't mean anyone who starts a pizza place is in a rush for fool's gold.

The problem is that most people do things half-assed and cluelessly. Even most entrepreneurs. It's simply meaningless to count everyone who worked full time on a Facebook app as an attempt at anything.

<comment><USER8> Well given that the blub paradox extends to business-savvy as well, I think it's reasonable to throw some rough numbers out there for prospective entrants into the market to have some idea what they're getting into.

However I agree with you that it's ridiculous to dismiss the market based purely on these numbers. First you would have to compare to other markets you could develop software in. You have to factor the entrenchment of market leaders in those segments, and also how each of the relative markets are growing or shrinking. Finally--and this is the thing that is keeping me out of iPhone development--you have to factor in the risks of developing on a closed platform with strict and arbitrary entrance requirements and how those things may change in the future.

Both Apple and Facebook have the ability to rip the floor right out from under your profitable app. Personally I think they are both great platforms, but I would not limit myself to them unless I was just trying to do a quick flip. In terms of long term value I would want those apps to be tied to some valuable backend service or open web technology that would not completely kill the business if Apple decides to kill my app.

</comment></comment><comment><USER9> _"The 1-2% that succeed can expect an upside of around $10-20 million in annual revenues. This isn't quite a lottery, but it's depressingly close."_

A lottery ticket costs $1 and isn't worth it. A 1% chance to "win" $10 million would arguably be worth $100,000. I wouldn't say it's close. (And that's not even counting that this is annual revenue.)

<comment><USER9> "Winning" iPhone/Facebook: 1 in 100. $10M _per_ year.

Winning Mega Millions Jackpot: 1 in 175,711,536. $12M _paid over_ 26 years (<http://en.wikipedia.org/wiki/Mega_Millions>)

</comment></comment><comment><USER10> I've commented before on the false number of developers that Facebook recites: <http://news.ycombinator.com/item?id=687796>

Considering he's using their numbers for his calculations, the entire premise might fall apart.

"Another intellectually dishonest number I hear Facebook recite is the number of developers. They get this number from the number of people who have installed the developer application. In the first year of the platform, that was 400,000. I know numerous friends who know nothing about programming that installed the developer application in that first week because they didn't know what they were doing. They recite this figure as if hundreds of thousands of people have devoted their lives to making Facebook applications. Sorry to burst someone's bubble, but it just ain't so."

<comment><USER11> Yeah. 900,000 developers isn't even remotely credible.

</comment></comment><comment><USER12> No it's not fool's gold, startups are generating millions in revenue from both. They are simply a reflection of a globalized market place, you're competing with developers in under developed countries. What's fool's gold to you, is riches to them.

Don't mistaken AppStore or Fb for anything more than a distribution platform. Hopefully Apple and Facebook will address the growing problem of app-overload so quality can bubble to the top, but it's not their fault you're facing more competition. And for all the faults — they've both solved a lot of really big problems and continue to drive innovation.

Yes it's hard and frustrating at times. But, building a value-driven business takes years of dedication. 37signals, amazon, apple, ms, gary v, digg, flickr, fb, are not over-night successes. Put down Fast Company and pickup Forbes once in a while.

</comment><comment><USER13> I really think this article is missing the point of many iPhone and FB apps - expanding the interface into existing applications (hoping to increase customer usage/stickiness/retention) and customer acquisition through free and nearly free experiences.

The real question is, "Are there times when a platform specific application is the best move for your business?"

</comment><comment><USER14> So I gather that in a gold rush, all the money's in selling the shovels. Are there any common technical problems associated with these applications?

(I tried asking this question in its own thread, but it didn't get any traction: <http://news.ycombinator.com/item?id=747882>)

<comment><USER15> The shovel:gold rush analogy usually works well for most types of businesses, but it seems that most software (particularly on the web) is sold as a platform of some kind. The Unity engine, for example, seems like a really cool shovel that no one has bothered digging with.

<comment><USER3> Off topic, I am an indie game dev who's checked out Unity,played with it, and -- after the initial euphoria wore off -- don't see much difference between it (with ~3% market share) and Shockwave (with ~30% market share). What are your thoughts?

<comment><USER15> Now that most home computers have are powerful enough, I definitely think that 3D in the web browser will get more popular, and that a standard will emerge. Director/Shockwave has been around for a while, and naturally has been adopted by more users.

Unity is a lot more powerful, and includes a physics engine and shader support. I don't know how much Shockwave supports those things, if it does at all, but I'd imagine Unity is a lot more focused on advanced features. It's not the Source engine, but it's advanced enough to build stand alone and console games, with the web as one option for deployment. I think it boils down to how much users really want realistic physics and other high-end game features in a web game, and that's hard for me to say.

There's also Google's O3D, which is also very powerful. Right now, though, it seems to be just an experimental Google Labs project, and not a real product.

</comment></comment></comment></comment><comment><USER16> I think a lot of people are missing the big picture. I am very interested to know how many of the developers on the Facebook and iPhone platform are _new_ developers. Just look at all of the courses being offered at community colleges on iPhone development. I really believe that the iPhone might be producing a bunch of crap software in the short-run, but in the long run it's producing developers for the mac platform, which is way more important.

</comment><comment><USER17> It may be fool's gold but you gotta give the people what they want. If you don't try to compete you have a 0% chance of success. If you want to be a successful software developer/publisher you need to offer a product in the markets people are interested in. What chance is there of an app of comparable quality & depth to a $5 iPhone app being more successful on the DS/PSP? Windows shareware?

</comment><comment><USER18> Breaking news: There are a lot of iphone developers. A few will find financial success. Most will not. Follow me on Twitter to get more amazing insights.

<comment><USER19> This pithy bullshit comment is a disservice to the OP. He backs up his analysis with some interesting projected numbers and market research in other areas that experienced similar growth.

The post is worth reading.

<comment><USER18> Let's look at some of his "projected numbers" and "market research"

 _Assume 1,000 application developers are competing in this market, 1.5 billion applications are downloaded annually, consumers pay a price of 99 cents per application_

Only 1000 developers worldwide? How in the world do you arrive at that number?

1.5B apps/year? _All_ of them are paid? The vast majority of downloads today are free apps. Without even giving a nod to the free vs. paid split, I am left to wonder if the author has ever used the app store himself.

$0.99/app? Is that just because most apps today are $0.99?

Also, what about in-app purchases and other ways to monetize apps (advertising, perhaps?)

Sorry, the projected numbers are pulled out of thin air, and I see no "research" to speak of.

The only interesting part imo, was the attempt to compare the app market to the automobile industry, but then he says: "The barriers to entry for developing an iPhone or Facebook application are much lower than producing an automobile, both in terms of capital investment and technological uncertainty. It takes just a few hours or days to develop a new iPhone or Facebook application...", which basically renders the analogy hopeless (and shows an incredible lack of respect for the complexity of many apps.)

I'm left with the distinct impression the OP doesn't have a clue about this market.

<comment><USER20> >>1.5B apps/year? All of them are paid?

No, but the blog never said that.

The blog explictly says "Furthermore, assume that half of applications are given away for free,.... "

<comment><USER18> You're right. I stand corrected. (But on the other hand, the assumption that the free/paid split is 50/50 is ridiculous as well.)

It seems like he built an Excel spreadsheet, plugged in some different numbers for various assumptions, and then blogged about how the different inputs affected the outputs. I fail to see how this produces any meaningful new insight. It's basically just a first year MBA's homework assignment.</comment></comment></comment></comment></comment>


Facebook will launch group chatbots at F8 - <AUTHOR> https://techcrunch.com/2017/03/29/facebook-group-bots/ <comment><USER2> This looks like a hugely significant move. Bot makers like myself have struggled with use cases for single-user bots, as obviously a large % of these use cases were competing with apps/website.

Group bots will be immensely more relevant, in the same way that successful Slack apps often solve group problems more than individual problems.</comment>


Cierge – Email-based passwordless authentication service - <AUTHOR> https://github.com/pwdless/cierge <comment><AUTHOR> Hi there! Cierge is an OpenID Connect server that handles user signup, login, profiles, management, social logins, and more. Instead of storing passwords, Cirege uses magic links/codes and external logins to authenticate your users. You can find a good list of FAQs on our our GitHub page or try a demo here: [https://cierge.azurewebsites.net](https://cierge.azurewebsites.net)</comment>