Ask HN: Programming Languages for Career - <AUTHOR> Context: I am a CS junior at a big prestigious university in the US, and I love Haskell and am planning on learning Lisp.
I learned C, C++, Python, and Java a while ago, but I haven't touched them in a year.
I am applying for internship next year (Google, Facebook, Palantir, etc.) for a big corporation experience, and am wondering whether I should catch up on those languages. (If I can avoid it, I would.)
I would be willing to code in a not-so-beautiful language for a summer to meet qualified engineers and build career capital (as in effective altruism).
On top of re-reading CLRS (which seems mandatory), should I prepare in any other way? Or should I work on my personal projects in Haskell/learn Lisp? <comment><USER2> I suspect that an internship offer from any of those companies will not be significantly based on detailed knowledge of any of those languages and I believe that there is no way that detailed knowledge of any one of those languages measured against the standard for detailed knowledge that applies at those companies is possible to attain in the next year. [1] Never mind detailed knowledge against that standard of all of them.

My advice:

1\. Keep moving forward. Interns programming Java at Facebook are expected to have knowledge of Java at the intern level.

2\. The programmer competency matrix [2] is a helpful way of understanding of general competency and general competency is likely to matter more in terms of hiring over the long term.

Good luck.

[1]: [http://norvig.com/21-days.html](http://norvig.com/21-days.html)

[2]: [http://sijinjoseph.com/programmer-competency- matrix/](http://sijinjoseph.com/programmer-competency-matrix/)

</comment><comment><USER3> From a career perspective, JavaScript has a pretty wide reach. Jobs range from designers that fiddle with JS to server-only NodeJS jobs and plenty in between. A demand for JavaScript devs writing mobile apps is growing with things like Facebook's ReactNative and there are decent desktop apps (VSCode, Atom, Slack) too, although it's not exactly a demand just yet.

Money is good too, here in Aus $600-$800 a day (or around $130-$160k a year) is the going rate for a decent developer with a few years under their belt.

</comment><comment><USER4> >I would be willing to code in a not-so-beautiful language for a summer

Career advice: don't be a primadonna.

Even actual literal primadonnas don't start out as primadonnas.</comment>


Implementing Exception#continue in Ruby - <AUTHOR> http://judofyr.net/posts/never-gonna-let-you-go.html

<comment><USER2> Just discovered this in my reader. Really neat.</comment>


The Trouble with Certificate Transparency - <AUTHOR> http://blog.okturtles.com/2014/09/the-trouble-with-certificate-transparency/

<comment><USER2> The point of CT is just to keep a log of every certificate issued. It's about transparency and little else.</comment>


Programmers:drugs - <AUTHOR> Dear programmers, what drugs do you take and have they improved, or diminished your coding abilities? <comment><USER3> LSD - Helped me understand a lot of the general thoughts behind Python, UNIX, LISP, etc on a deeper level

Ketamine - Similar to LSD, but helped blunt the effects of depression

Amphetamines - Helped me focus, improved my memory, increased productive hours

Weed and beer - Helped me relax and get into a creative mood. Great for socializing, too

<comment><USER4> The question itself is idiotic, as well as this answer. If you need drugs to understand the things you have mentioned, you should think about changing career and getting professional advice would help here. I do not understand this valley culture of drugs, hacking body things and all the related stuff. Before starting to "hack body" to understand "on deeper level", you should consider getting medical advice or if you really want to proceed further getting education in medical sciences would help. I always wonder what implications you all will have in a long term, but those people tend not to think about it at all.

</comment></comment><comment><USER5> _Caffeine_ makes me impatient and neurotic. So I drink non-caffeinated tea instead.

 _Sugar_ demolishes me. I'm useless on a sugar high. I compensate with fiber and fat so I can use the energy.

 _Alcohol_ , I hate how it makes me feel. Angry and uninterested in actual work. I only drink a beer or two when forced to socialize with drinkers.

I feel that the best code comes out when I'm mellow, but with just enough energy. Too much or too little usually leads to not wanting to do anything related to programming. I guess it's just about keeping things balanced.

</comment><comment><USER6> Alcohol - It helps me calm down after coding in javascript (ES5), which makes me angry at times . . .

</comment><comment><USER7> THC, LSD, Psilocin.

Take a dose and read Programming and Metaprogramming in the Human Biocomputer.

It will change your life.

</comment><comment><USER8> Weed - to refresh and reset my mind once in a while. I didn't find alcohol really good for improving coding abilities. Better avoid it. Cigarette - <USER2> keep you awake on deadlines and all. But, it's injurious nature to health made me quit it.

</comment><comment><USER9> Debugging node.js tends to make me feel like I'm tripping on acid. Does that count?

</comment><comment><USER10> Caffeine.

Both. It can help me get into "auto-pilot" which is either good when I am efficient or bad when I am procrastinating.

Sugar.

Bad. Hurts your attention span when you're on a "high" and hurts your motivation when you're on a "low."</comment>


QArt codes, the better way to put picture in a QR code - <AUTHOR> http://hackaday.com/2012/04/13/qart-codes-the-better-way-to-put-picture-in-a-qr-code/?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+hackaday%2FLgoM+%28Hack+a+Day%29 <comment><USER2> Russ Cox's original blog post about QArt: <http://research.swtch.com/qart>

Note: Russ Cox is also part of the Go team at Google and was in charge of building Code Search(RIP) and when it was shut down he released the core of the indexing engine: <http://code.google.com/p/codesearch/>

<comment><USER3> He also wrote RE2 [1] and has published a few articles on regular expression matching [2]. I highly recommend taking some time to look through his blog, he's got some great stuff there.

[1]: <http://code.google.com/p/re2/> [2]: <http://swtch.com/~rsc/regexp/>

</comment></comment><comment><USER4> This, as usual, is amazing. Russ is just ridiculous. I range between being deeply jealous of him and deeply impressed at the productivity and quality of his work :-)

/geek-gushing

</comment><comment><USER5> Other discussion: <https://news.ycombinator.com/item?id=3833850>

</comment><comment><USER6> I am trying to get this working on Windows - any ideas? I downloaded the Go build for windows (<https://code.google.com/p/go/downloads/list>) yet I have no idea how to build this app (QR.go)

<comment><USER7> I'm just using the web-ified version directly. It works very well.

<http://research.swtch.com/qr/draw>

</comment></comment><comment><USER8> Russ Cox must be a code name of the team working at Google on various projects?

<comment><USER2> He was just as insanely productive even before he joined Google, for a while he was both at Bell Labs (hacking on Plan 9, venti, and other things) and at MIT (hacking on vx32, the modern-C rewrite of the original Unix V6 kernel, etc.)

</comment></comment><comment><USER9> I'm surprised how quickly this ended up on HN. I submitted it to Hack a Day late last night (early morning?), and was surprised that Hack a Day got it online by the time I left the house.</comment>


Gradual Programming - <AUTHOR> http://willcrichton.net/notes/gradual-programming/ <comment><USER3>
        > A basic observation about the human programming process is
        > that it is incremental. No one writes the entirety of their
        > program in a single go, clicks compile + publish, and never
        > looks at the code again. Programming is a long slog of
        > trial and error, where the length of the trial and the
        > severity of the error depend heavily on the domain and the
        > tooling.

I don't know about others but I've done this quite a few times. When I have to write some code for a personal project of moderate size (10k LOC) I like to just sleep on it for a while, stay up very late, chug some coffee, and write the entire program. After that I click compile and run a few times, fix any variable names that I've undoutably misspelled, and then maybe 1 or 2 bugs. It's basically delaying starting a project until you have a perfect mental image of what that code needs to do, how it looks, and understand mentally every tradeoff you're making. I wish I could do this with larger code bases but unfortunately, from my own experience, planning time is exponentially related to the projected lines of code. A 5K to 10k LOC project usually takes me on the order of 2 weeks of thinking. If you go higher than that you're talking about months.

If you wanted to change the world of programming I would think of a way to abstractly describe dataflows in the vain of unix pipes. Define every part of the transforms you need to do on incoming data, where those responsibilities should be, and then link them together. Current abstraction methods are subpar: they require inherent complexity, are language specific, and are not easy to change after you've using them (unless you have adapters on every part of the code base which in it's own right becomes a mess).

<comment><USER4> Yeah, I'd call this the difference between "discovering how to program a thing" and "programming something you already understand".

Discovering as you go is totally fine, and dominates what I write. It's also very nearly your only option when learning something new. Sitting on millions of lines of code, integrating with dozens of other systems... you often simply don't know what you need to do up-front, so you iterate and explore until you do. Gradually tightening the constraints of the system fits this kind of thing _perfectly_ and I _love_ when it's easy to achieve. It gets you both a faster start and a safer finish.

In contrast, entirely agreed - I've written a few low-kLOC projects start-to- finish with basically no problems. But I knew exactly what I was going to do before I started actually coding. The (significant) time leading up to that was spent more-thoroughly understanding what and how I wanted to do, and at some point it all clicked in an "oh. so that's how. OK, might as well build it now" moment.

<comment><USER5> > It's also very nearly your only option when learning something new.

Also your only option when working with other developers.

<comment><USER4> Making it so this _isn 't_ true with multiple developers is one of the benefits of waterfall-style programming. Design an API up-front, divvy up work, build it. As long as the design is good and you don't do stupid shit, it's entirely possible to work in parallel without getting in each other's way.

But yes, it absolutely compounds the issues. Everyone involved has to thoroughly understand it all / their role in it, and getting to that point likely takes longer than discovering it as you go :)

</comment></comment></comment></comment><comment><USER6> I take _huge_ issues with this statement

> For a multitude of reasons, straight-line, sequential imperative code comes > more naturally to programmers than functional/declarative code in their > conceptual program model

On the contrary, I think most people are 'configured' to think declaratively and functionally. Many programmers on the other hand are somewhat mentally atypical in that they think quite imperatively. This leads them to pursue technical hobbies, like programming. However, we do a huge disservice to think that 'humans' are better at imperative stuff. In my experience, there's a significant subset of people that find declarative stuff significantly easier, but do not pursue programming when they take their first OOP course and are turned off.

For me at least, I played around a bit with programming when young, but it never clicked for me until i started exploring the declarative and functional languages. These just came way easier to me than everything else, and had I not been exposed to them, I doubt I would have continued in this as a profession.

<comment><USER7> You're right people's first thought tends to be declarative.

But the problem is, programming isn't about just putting down a first order encoding of your needs. It's about bridging the gap between that encoding and the libraries actually available to you.

That's where declarative programming becomes unintuitive to people. How do you bridge the gap between your declaration and the declarations provided by Rails/Vue/Webpack/etc? You need to somehow imagine the transformation that will get you there.

Imperative programs, on the other hand, always have a ready axis for decomposition: time. You break your program up into tiny time slices, and then work backwards to find procedures that that get you to the first one, then the second one, etc, until you hit the end of your program.

With declarative programs, you need to slice the program in an abstract space. In my experience it takes 6-12 months to get up to speed with a new declarative programming landscape like Rails or Ember.

<comment><USER8> Thanks. I've been following this sub-thread with interest. I have very little theoretical understanding of the differences between imperative and declarative (functional) paradigms.

I used this video to get a better understanding - I hope it helps others too:

[https://m.youtube.com/watch?v=sqV3pL5x8PI](https://m.youtube.com/watch?v=sqV3pL5x8PI)

</comment></comment></comment><comment><USER9> Gradual programming certainly strikes me as the future of programming. I see the end goal as being able to use a single, unified language for every application. Certain sections of a large codebase might need their own special jargon or abstractions; but that shouldn't necessitate a totally separate language and toolchain.

This fits real life: we can use English for casual gossip, highly specific technical documentation, and everything in between.

Another important dimension for gradual languages is difficulty: Languages with advanced verification capabilities (eg, Rust) would be much easier to pick up and get started with if you could trivially have sections of code where you didn't even need to know about the memory management features of Rust (it would be way easier to choose Rust as a primary language for a company without having to worry nearly as much about the new engineer onboarding cost).

Also, since he phrased this as an HCI problem: tooling strikes me as just as important as language design. A language that was gradual between some sort of highly constrained drag&drop interface and text-based programming would be great.

<comment><USER10> It seems to me that the languages we write programs in today are generally at the wrong level of abstraction in one way or another. Imagine if we wrote long-lived programs in a sort of lingua franca pseudocode, and then compilers competed with each other over the years to produce ever more efficient machine code from that well-established pseudocode. In this fantasy world, for example, Adobe Photoshop isn't written in C++. It's written in logic. They keep writing new features in logic-language, and at the same time their compiler team keeps working to make a better compiler that produces a better compilation target.

<comment><USER11> > Imagine if we wrote [..] in a sort of lingua franca pseudocode, and then > compilers competed with each other over the years to produce ever more > efficient machine code from that well-established pseudocode. In this > fantasy world [..]

This seems to, to an extent, describe SQL.

</comment></comment></comment><comment><USER12> The initial part of the article:

> Gradual programming is the programmer tracking the co-evolution of two > things: 1) the syntactic representation of the program, as expressed to the > computer via a programming language, and 2) a conceptual representation of > the program, inside the mind. In the beginning of the process, the > programmer starts with no syntax (an empty file) and usually a fuzzy idea of > how the final program should work. From this point, she takes small steps in > building components of the program until the final version is complete.

calls to mind things like the B-Method ([https://en.wikipedia.org/wiki/B-Method](https://en.wikipedia.org/wiki/B-Method)).

Here you first specify your program at a very high level in logic; then you _refine_ the model, still in logic, and proving that the refinement is valid; you iterate some more refinement steps, i.e., you gradually make parts more concrete by actually implementing individual operations; and at the end you have a complete, executable program. A program that, since you proved all the refinement relations as you progressed, is also formally verified against its spec.

Of course this is too much work for most domains, and many domains don't even have any useful notion of formal specs. Also, the _actual_ B system is a horrible thing with a horrible logic and horrible proof tools. But the general idea is appealing, for some things.

</comment><comment><USER13> Best I can tell, pretty much everything he describes is already part of Common Lisp. "Gradual Typing", for example has a long history in Lisp, and is pretty much the default way to write programs.

<comment><USER14> Not every optionally typed system is gradually typed. The purpose of gradual typing is to allow typed and untyped code to interact

(0) without destroying the safety guarantees of typed code,

(1) correctly assigning blame, if a runtime type error happens, to the specific untyped part of the program that causes the error.

Common Lisp's optional types don't quite fit the bill.

<comment><USER15>
       (check-type foo string)

Does: it asserts the type of the place and throws a (restartable) error, giving the user a chance to fix the problematic value rather than bailing. I guess they don't really solve (1), but the stack trace that arises is a start.

<comment><USER14> Stack traces contain a lot of information. Most of it is useless garbage. Yet at the same time sometimes stack traces don't contain the information you need. Making them even more useless garbage.

<comment><USER16> Hogwash. Stack traces in multi-threaded applications are much much more useful than just an exception name, or even just the site of the exception.

<comment><USER14> What I need is the proof that the program is correct. Bugs will show up as gaps or inconsistencies in the proof. But, in the absence of even an attempt at a proof, all I can do is throw the program to the dogs.

<comment><USER16> I've never yet had the luxury of working in a language that admitted formal proofs of correctness. Do you mean informal "proofs" like unit tests?

When a bug occurs (perhaps because your tests did not anticipate every edge case) how do you determine where the problem code is located without a stack trace?

I know that it doesn't usually point to the line of code that is problematic, but it usually gives you a starting point for your deductions...

<comment><USER14> > I've never yet had the luxury of working in a language that admitted formal > proofs of correctness.

You don't need much from your language, except for a formal semantics. But, even if your language of choice doesn't have one, you can stick to a subset of it that is easy to formalize: no first-class procedures (or things that can simulate them, such as dynamic method dispatch), no non-local control flow operators (e.g. raising and handling exceptions), no non-lexical variables, just statically dispatched procedures and structured control flow constructs (selection and repetition, i.e., pattern matching and recursion).

> When a bug occurs (perhaps because your tests did not anticipate every edge > case) how do you determine where the problem code is located without a stack > trace?

By reasoning about every statement's intended and actual preconditions and postconditions, i.e., predicates on the program's free variables. At some point, the intended and actual preconditions of a statement-postcondition pair won't agree. But this is unreasonably hard if you need to reconstruct these preconditions and postconditions completely from scratch.

<comment><USER16> I've never had the luxury of that much control over a codebase in the real world of work.

</comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER17> someone said "software is made of decisions". IMO this is _the_ problem. All those listed axises, and another dozen i could imagine (esp. moving away from machine and closer to reality), they all require decisions to be taken. Some of these decisions are predefined - from the language, OS, hardware, employment, audience, customer, tie-color, whatever. Other are obvious. But a lot are not even understandable unless one has been-there, done-that.

Most people do not want to make/take many decisions, especially for things they dont care (in that moment), so they go for something that has those predefined. As +/\- , usualy that something comes with lots of other extra decisions predefined too.. and the pain starts. Sooner of later u want full control of some aspect, and in order to get yoursefl free on that aspect, ... u have to either do horrible hacks, or re-make everything yourself. And there is the other extreme. Next time, u'll just start there. With No gravity defined - whatever that brings (like very long schedule. Or very loose language).

Usualy people take magnitude(s) fewer decisions-per-minute than what one needs in programming. Same for alternativity. Hence the difficulty of programming..

And yes, the all-or-nothing approach that is all-over software, has to be anathema-ed. For 30+ years, i have not seen anything good in it. i want to be able to choose-and-mix (which is, decide) by myself. And so do my new pupils.. And all the intermediate levels. Just the set of aspects, and details thereof, is very different for me and for them. Which calls for even greater graduality-flexibility-alternativity..

Myself, i have ended doing everything in python, for it stops/chains me the least, without getting too unstructured. Usualy making little "languages" for anything that i might, all on top of each other, "gradualy" changing the semantics; away from the language predefined, into the target domain. And, generating all else that cannot go this way.

have fun

</comment><comment><USER18> It's amazing it took so long to get here. Obviously less smart people like myself, figure this out on our own. My brain doesn't have a lot of processing power, and I always try to shorten the feedback loop between what I write and the response I get from the programme itself, instead of throwing myself in layers and layers of abstraction. But to me and I think many others, this is the only way. We have to make the language, and flow of the code conform more to the human intuition.

<comment><USER19> Actually I believe abstraction is a tool with the express purpose of limiting the amount of stuff you have to keep in your head. Abstraction lets you omit the nasty details, so you can work with a representation of the problem space that better fits in your brain cache.

</comment></comment><comment><USER20> FWIW, the implementation of Oil is following a "gradual" trajectory. It's amazing how long various "wrong" things were in the codebase!

I was already 8-9 months into coding with over 10K lines of code before I added ASDL schemas for the AST [1].

I believe this was a good thing, because I had running code from the start, and the only way to understand shell is over many months. It's impossible to just "think about it" and come up with the correct schema. The schema follows not just from understanding the language, butfrom the algorithms you need to implement on the language. [2]

So I see the value in both -- starting out with a very loose notion of types, then making it stricter.

I'm taking the next step now and am looking to make that detailed schema static rather than dynamic [3].

[1] Success with ASDL [http://www.oilshell.org/blog/2017/01/04.html](http://www.oilshell.org/blog/2017/01/04.html)

[2] From AST to Lossless Syntax Tree [http://www.oilshell.org/blog/2017/02/11.html](http://www.oilshell.org/blog/2017/02/11.html)

[3] Building Oil with the OPy Bytecode Compiler [http://www.oilshell.org/blog/2018/03/04.html](http://www.oilshell.org/blog/2018/03/04.html)

(copy of Reddit comment)

</comment><comment><USER21> I find F#'s type inference to be really nice. You feel like you are almost writing in a scripting language but whenever you mess something up it will tell you. And if you say, "No F# you are wrong!" F# always wins. And the ability to write small pieces of the code in F# interactive is tremendously useful. I find I like T-SQL for that same reason. I can write small programs scripting as I go and bring everything together in a bigger program all without having to worry about types too much. The tooling isn't quite as nice with T-SQL as it is with F# (granted C# blows F# away with its tooling, but F# is catching up slowly).

What's nice about T-SQL is that you can do a lot of your programming in it and then you generators to generate all your C# code (Query-First) and even your client side code (I'm working on a console app that will do that for me). But the tooling for this is not very mature. I don't understand why programmers don't embrace it wholesale. I feel like I'm always writing so much cruft in my day-to-day job and screaming at the computer that I could do what takes an hour in C# in 5 minutes in SQL.

SQL is a bit harder to learn at first. But the more you work with it the easier it gets. And it is much easier to understand since there isn't much to it, unless you are doing something really complex. But then, I don't know if C# is that much clearer.

I just wish the tooling were as nice for PostgreSQL as it is for SQL Server. I don't understand how you can pay $200 for a product that can't even figure out what fields my alias refers to.

</comment><comment><USER22> > Several of the axes mentioned (memory management, language specialization) > lack any documented attempts to systematize their treatment at the language > level.

This is not entirely true. The author of the Gradual Memory Management paper you cite is currently building [1] a systems programming language called Cone [2] that incorporates these mechanisms. Although much work remains to be done, the online reference documentation does go into some detail about the syntax and semantics for references, allocators and permissions.

[1] [http://github.com/jondgoodwin/cone](http://github.com/jondgoodwin/cone) [2] [http://cone.jondgoodwin.com](http://cone.jondgoodwin.com)

<comment><AUTHOR> Sorry Jon, I didn't mean to imply you haven't been making progress on your language. I was thinking moreso in terms of published research.

<comment><USER22> I appreciate the clarification, as I did not catch that from the context. I just assumed maybe you were not aware of my follow-up work with Cone.

I do think there are good research opportunities in these ideas, e.g.:

* Type theoretic work on formally proving the soundness of the mechanics (as a follow-on to the proof work done with Pony and Rust-belt).

* Cross-allocator comparative studies of performance and other factors (although many such studies have been conducted in the past, the fact that you can control for the language/runtime and even test hybrid memory management strategies would make a new study a worthy addition to prior work).

* Assessing the impact of borrowed references and lexical memory management on tracing GC's "generational hypothesis"

In your role at Stamford, perhaps you can inspire students to pursue such projects. My focus is devoted to real-world results, but I would be happy to offer support, if that would be of any help.

</comment></comment></comment><comment><USER23> Even though Perl6 isn't production ready yet, I'm surprised to see it not being mentioned in a group of languages with some gradual typing support as what I would subjectively consider idiomatic Perl6 takes advantage of quite a few things including gradual typing.

</comment><comment><USER24> I wonder where recursive programming fits into this.

For any newby programmer, recursive programming is a difficult concept to grasp. Then during an intermediate programmer's stage, you realize recursive programming's power and lean on it because of it's often theoretical beauty and often simple. As you advance more, you realize the computational disadvantages (exploding stack) and softer disadvantages (lack of readability).

Would "gradual" programming ban recursive programming?

</comment><comment><USER25> > no new big ideas since Prolog

Given that Prolog dates back to 1972, I wonder if spreadsheets count as a big new idea? How about programmer notebooks like Jupyter?

<comment><USER23> Mathematica has had pretty advanced programmer notebooks for something like 20 years i think. Jupyter definitely isn't new. The only new part would be a lot of languages (Python, Julia...etc) starting to use it.

</comment></comment><comment><USER26> No mention of [https://quorumlanguage.com/](https://quorumlanguage.com/) ?

</comment><comment><USER27> I'm surprised to disagree so thoroughly with someone who teaches a programming languages course at Stanford.

It's a problem of education, and business needs affecting education.

What do schools teach? Python? Java? C? A little lisp maybe? Javascript (oh god)?

Why? Why are we pretending those languages have anything at all to do with learning computer SCIENCE? More like job-training for big companies, so that graduates are 'job-ready' when they graduate.

You don't need studies, because users don't KNOW what's going to make their lives better, other than incrementally better. Imagine asking people who rode horses what they'd like to have improved in terms of transportation. Who in the world would say a car? A self driving car?

Cars require massive infrastructure investments. Programming language research and development requires serious investment, and serious collaboration. When people who don't do research, decide on allocation of funds, demand X number of papers published that rot behind paywalls, etc etc, why is anyone wondering why we're still using C for critical world-wide infrastructure?

For someone who expresses this far better than I can, watch a couple of videos of Alan Kay on youtube.

<comment><AUTHOR> I'm not sure why our two viewpoints have to be at odds. I wholeheartedly agree that improving education and encouraging students to focus more on understanding the fundamentals instead of the syntax is important. But our languages are still in need of improvement!

<comment><USER27> I went off on a rant rather than address your post, I'm sorry.

Let me try and do a better job this time around:

 _I believe, then, that viewing programming languages (PL) through a lens of human-computer interaction (HCI) is the most critical meta-problem in the field today. More than ever, we need surveys, interviews, user studies, sociologists, psychologists, and so on to provide data-driven hypotheses about the hard parts of programming._

I agree that tooling for programmers is awful - I disagree that it is because we haven't done studies. My point was that studies will absolutely not help, for anything but incremental improvements that hardly matter. I also don't think it's the most critical problem - I'd agree that it is the lowest hanging fruit, however.

Meaning, I think there can be significant improvements to programmer tooling, within the next 5 years, and I also think the problem again lies in funding, programmers not willing to pay for better tooling (lack of imagination) and lack of imagination of the big companies.

One glaring example of lack of imagination is our current state of using the internet - html/css/javascript in a web browser is a completely broken paradigm and yet, no big company has done anything to actually fix it, some spend millions of dollars each year to keep it going in fact! Thousands upon thousands of people have spent optimizing, writing libraries for, and using a fundamentally mediocre language. That does not give me much hope frankly.

I am being quite negative so let me propose what I think is the future of programming languages: a dependent type system language with incredible documentation, standard library and an ability to drop down into a language like rust, for pieces of code that need performance.

The current trend of Swift/Kotlin is imho a syntactic and minor improvement over Java/C#, and moving in the direction you've mentioned - I think object oriented programming, dynamic languages and mutable state by default, or even having to think of managing memory, are ideas that will only be used in niche circumstances 30-40 years from now. OO for UI, dynamic languages for what bash scripts are currently used for, managing memory via rust for performance critical apps.

This is all assuming we wake up and start reading scientific papers from 30-40 years ago and actually using those ideas, rather than cherry-picking ideas to glue onto a fundamentally broken existing paradigm.

One last thought - these are all thoughts of someone who's frankly quite uneducated. I'd love to know what people who actually design languages/compilers/proof assistants for a living think.

<comment><USER28> _no big company has done anything to actually fix it_

Sure they have. Google wrote Dart and tried to get others on board. Then asm.js arose, allowing other languages to be compiled and run reasonably efficiently. Nowadays there's some consensus around Webassembly.

Regarding HTML/CSS, canvas and WebGL both bypass them.

<comment><USER27> Everything you've mentioned completely misses the point - it is not just performance that stinks, it is not just javascript as a language that stinks - all these tools are incremental improvements that completely lack imagination.

It is the platform itself - meant to display static text content, being coerced into some frankenstein that requires never-ending libraries and tooling to do what desktop apps did 20 years ago.

It is hard to see any other world, so let me link you to a guy to whom it was obvious the web browsers stink decades ago.

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

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

<comment><USER28> I didn't miss the point, but I may have bungled mine.

Let me start by addressing Xanadu; you obviously get the web's folly, so I don't understand why you'd link to a criticism of the web that has been outdated for twenty years. Yes, as you point out, the web is a pile of hacks, but those hacks haven't been bolted on to add two-way links or transclusions, but - as you point out - to do what desktop apps do. Had Xanadu won over the web, someone would have created JavaScript and a bunch of hacks on top of that just the same.

A closer vision to what we've been trying to achieve is Alan Kay's, which said that browsers should have been essentially a basic layer - not an application - to run third-party code safely.

And in my opinion, webassembly and canvas+webgl are essentially that - <USER2> simple bytecode VM and two slim layers over core graphic APIs. Sure, you need some HTML to load them for historical reasons (although surely a "manifest" file format would rapidly arise to replace it), but they are essentially standalone and quite basic. All the layers of hacks are in HTML's advanced features, in CSS and in JS. Once you have applications that don't use those, you can build a browser which is just a very basic HTML parser tied to a bytecode VM.

</comment></comment></comment></comment></comment></comment><comment><USER29> > Is imperative programming more intuitive to people than functional > programming? If so, is it because it matches the way our brains are > configured, or because it's simply the most common form of programming?

(I think) It's not because of brains or abundance, it's because of the human language.

> How far should we go to match people's natural processes versus trying to > change the way people think about programming?

Economically, it is your time (of one person only) versus the time of potentially thousands of users. What do you think?

> How impactful are comments in understanding a program? Variable names? > Types? Control flow?

Ideally, I think, comments would not be contained in the source code, polluting the general vision of its structure, but would be placed outside, as documentation.

For variable names, as long as its meaning/use is made immediately clear on first sight, without needing to figure out its frequency pattern or see its declaration to figure it out (maybe placing it in a separate place from the code, again), the variable name shouldn't matter much (as long as its not purposefully unrelated or obscure).

I think it would be useful to have something like a "live documentation" in a REPL (commands like man commands documenting each part of the language (and program), each word an entry, non-sequentially accesible). That is something I would do if I were to design a programming language, a structure called a "dictionary" documenting each and every reserved/defined word in the environment.

<comment><USER30> > Ideally, I think, comments would not be contained in the source code, > polluting the general vision of its structure, but would be placed outside, > as documentation.

I believe Donald Knuth, who introduced Literate Programming, would disagree with this.

"According to Knuth, literate programming provides higher-quality programs, since it forces programmers to explicitly state the thoughts behind the program, making poorly thought-out design decisions more obvious. Knuth also claims that literate programming provides a first-rate documentation system, which is not an add-on, but is grown naturally in the process of exposition of one's thoughts during a program's creation."

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

[https://www-cs-faculty.stanford.edu/~knuth/lp.html](https://www-cs- faculty.stanford.edu/~knuth/lp.html)

I have not used full-fledged Literate Programming, but I find having part of documentation interleaved with code helps improve both and reduces cognitive load required to search for relevant documentation elsewhere.

<comment><USER31> I've done it a few times. I'm now firmly of the opinion that ideally the only language you should see in code is a programming language. If you can not express the intent clearly in the programming language, then you should work at it until you can. It's not always possible and I write comments when I have to. Some languages are not very expressive, either, which makes it difficult.

The main problems I've had with literate programming are:

\- It has a very high risk of being very slow going. If you have to change something, then you will often find that you need to change a lot of prose.

\- Because of the previous point, there is a tendency to do a lot of up front design and spike a lot of code to "get it right" before you commit to writing the prose. There's no particular problem with that except that it places a _very_ high cost on change. There is considerable incentive to accept a sub- optimal situation because changing it will be extremely expensive.

\- It is quite difficult to write prose in a reference style. Generally speaking, one is encouraged in literate programming to write your code in "presentation order". In other words, the order that you would discuss things. This is fantastic if someone is sitting down and reading your code from scratch. It makes it difficult to find the wheat in the chaff when you are debugging, though.

\- Because of that, I find that I'm more often reading the undocumented code rather than the documented code -- because once I understand what's going on it's far easier and faster to just read the source code. Jumping around between the generated code and the presented code is often frustrating.

Having said that, I've found that I really like programming in a literate style when I'm writing a blog post, or the like. Because I'm thinking more in prose than in code, it works extremely well.

My personal suspicion is that Knuth had great success using literate programming for TeX precisely because he was more concerned about describing algorithms for typesetting than he was about writing a great typesetting system. I love TeX (and I'm one of the few people who actually has considerable experience using TeX without LaTeX), but it is a horrible language that works exceptionally well. In many ways I think that it demonstrates the issues that I've had with literate programming.</comment></comment></comment>


Twitter Now Valued at $7 Billion - <AUTHOR> http://mashable.com/2011/07/05/twitter-7-billion/?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+Mashable+%28Mashable%29 <comment><USER2> Twitter continually impresses me, and I find myself using it more and more each day. Their biggest program is helping people understand that it can be a valuable resource and not just somewhere to post what their eating for lunch. I get my news from Twitter before I get it anywhere else.

</comment><comment><USER3> Why is any popular start up consistently valued way more than they actually are?</comment>


Guide to Sharing with Apple Photos - <AUTHOR> https://werkjohann.github.io/how-to-share-photos/ <comment><AUTHOR> Author here. Sharing the photos and videos you take on your iPhone is a lot more complicated than people might imagine. Chances are you've shared photos with someone and unknowingly made a compromise that you didn't intend to. After exhaustive testing of the various ways of sharing from the Apple Photos apps, I put together this flow chart so that people can make conscious choices about how they share photos.</comment>


Browser wars - <AUTHOR> https://en.wikipedia.org/wiki/Browser_wars <comment><USER2> I was trying to find IE somewhere: [https://upload.wikimedia.org/wikipedia/commons/thumb/e/e1/St...](https://upload.wikimedia.org/wikipedia/commons/thumb/e/e1/StatCounter- browser-ww-monthly-201707-201707-map.png/440px-StatCounter-browser-ww- monthly-201707-201707-map.png)

I probably need a magnifying glass or something...</comment>


Show HN: News Box from Owwly – list of early products and that's just beginning - <AUTHOR> https://owwly.com/news-box <comment><AUTHOR> Hello community,

I would like to introduce a new page on Owwly - News Box You can find here early startups and interesting tips on how to build successful products. We realized it's really hard for young startups to introduce to the tech world. Our mission is to help people promote their solutions at the very beginning, even when a tool has only landing page to gather email list.

And that's just beginning…

We would like to give an option to users to log in and participate in community growing.

The Goal - motivate startupers to add content which could bring a value (remarks from building a product, takeaways, what they learn, what works/ what's not, etc.)

Upsides to startupers: -building community around their product -knowledge exchange -free promotion

So keen to hear you're feedback about this idea. Do you think it could give you a value to use it from time to time? Would you like to share knowledge and be more visible in the tech world?

Piotr.</comment>


If your results are highly counterintuitive - <AUTHOR> http://su3su2u1.tumblr.com/post/114728408943/if-your-results-are-highly-counterintuitive <comment><USER2> ..then call the lab's publicist and get your paper out as quickly as possible.

This is where those "A Pepperoni Pizza per day prevents Cancer" headlines come from.

</comment><comment><USER3> Funny, in pure mathematics the opposite is true. Examples of intuition defying theorems include the Banach–Tarski paradox, cantor sets, uncountability of the reals, gabriel's horn, the list goes on.

<comment><USER4> Pretty much every great result in Physics had been counter-intuitive: Gravity, relativity, quantum mech, nuclear physics, semi-conductors, super conductors... I'd say every major advance is science destroyed some conventional wisdom and proved previous intuition wrong.

<comment><USER5> Yes, but "counter-intuitive" _means_ "probably wrong."

There are many great results that are counter-intuitive, but there are vastly more _completely stupid_ ideas that are counter-intuitive. Ask any academic about their green ink file.

 _Most new ideas are bad_. That doesn't mean "give them a serious look", but it does mean "though you probably won't get far with them."

<comment><USER6> What is a "green ink file"? Google isn't helping.

<comment><USER5> A British journalistic term for the frothing of lunatics; may or may not actually be written in green. [http://rationalwiki.org/wiki/Green_ink](http://rationalwiki.org/wiki/Green_ink) Academics tend to get a lot of correspondence from cranks, often enough to accumulate a collection.

</comment></comment></comment></comment></comment><comment><USER7> Its like author rediscovered Survivorship bias on his own :)

</comment><comment><USER8> To me, these examples vividly illustrate the limitations of working with observational data, and are an extension of the standard "correlation vs causation" problem.

I think the pertinent lesson here is that these are still very real problems in the world of "big data": just because you're map-reducing, and throwing around petabytes of data, what you can learn is still limited by the regime under which the data were collected.

</comment><comment><USER9> Interesting, I wonder if not the latest Spotify Insight is exactly a case of this: [https://insights.spotify.com/us/2015/04/22/music-taste- matur...](https://insights.spotify.com/us/2015/04/22/music-taste-matures-by- age-35-and-its-different-for-parents/#more-1476)

</comment><comment><USER10> Endogeneity is not unique to big data. If your results are counterintuitive, it could be because of endogeneity, or your data is just generally messed up, or more subtle statistical issues. Or maybe your analysis is right.

</comment><comment><USER11> This kind of thinking often promotes confirmation biases.

</comment><comment><USER12> For a counter-example, consider quantum mechanics.

<comment><USER13> "Intuitive" means "consistent with prior experience".

If that prior experience is using a prism in a box to take the spectrum of the sun or various kinds of electric lights, and then studying where the bright and dark bands come from? Or shining a laser pointer at a hair to see the diffraction pattern?

Well, playing with that stuff for fun means that a lot of the QM stuff doesn't seem nearly as bizarre as it's said to be.

But then, heavier-than-air flying machines were for a while considered _impossible_ , rather than merely counterintuitive. And now you can get kits to make small ones at the toy store.</comment></comment>


Time to panic - <AUTHOR> http://nickbruun.dk/2012/06/07/time-to-panic

<comment><USER2> I hope that by now everyone here is aware that this is ridiculous advice. Please, please, don't learn about cryptography in order to store passwords. And don't implement your own half baked scheme. Listen to the people who know more about it than you or I ever will, and then use _their_ software.

</comment><comment><USER3> Great post, Nick!

I really think this whole case is badly handle by LinkedIn - both in terms of storing the passwords and the PR when the leak was made.</comment>


Recent efforts in V8 and DevTools for Node.js - <AUTHOR> http://v8project.blogspot.com/2016/12/v8-nodejs.html <comment><USER2> > "Async/await will land in Node with the next V8 update."

You can actually try the async-await functionality with Node Current (7.2.1 as of this writing) by passing the flag --harmony-async-await:

        node --harmony-async-await app.js

It will be available without flags in the LTS release in March (that is in 3 months). Say goodbye to Callback Hell, the future of Node.js is looking pretty good.

<comment><USER3> Yes, but:

> However, Node v7 is based on V8 54, whose async/await implementation has > some bugs in it (including a nasty memory leak). I would not recommend using > --harmony-async-await in production until upgrading to V8 55; the easiest > way to achieve that would be to wait for Node 8.

[https://github.com/nodejs/promises/issues/4#issuecomment-254...](https://github.com/nodejs/promises/issues/4#issuecomment-254159118)

<comment><USER4> He did say to "try" it, you can use a flag. You should assume that any feature behind a flag should never be used in production.

Also, Node v7 will likely get a semver-minor update with V8 55. So, simply waiting for v7.3 or v7.4 should be sufficient and it will be enabled by default.

[https://github.com/nodejs/node/pull/9618#issuecomment-264641...](https://github.com/nodejs/node/pull/9618#issuecomment-264641321)

Those who are sticking with the LTS release for production will need to wait until April/May 2017. March is overly optimistic by the OP as the currently scheduled date is 2017-04-30.

[https://github.com/nodejs/LTS](https://github.com/nodejs/LTS)

<comment><USER2> I said March because I read it somewhere. A couple of months further, it's going to be worth the wait anyway. And yeah, flags are pretty much "try it" territory, not "use it in production" territory.

</comment></comment></comment></comment><comment><USER5> If you want to use chrome devtools without changing your version of node, I'd recommend this implementation of node + devtool that uses electron ([https://github.com/Jam3/devtool](https://github.com/Jam3/devtool)).

It literally changed my life. Thanks whoever is responsible for this project.

<comment><USER6> If you're already using a version of Node that supports debugging, is this any different or better?

<comment><USER5> Yes, this app launches a chrome devtools windows (as part of electron) and lets you inspect your code using the dev tools gui which I find much more productive than the text-based CLI debugger.

<comment><USER7> I believe the comparison was not with text-based debuggers, but with the more mainstream Node.js debugging options that also provide Blink or Chrome DevTools UIs:

1\. Node Inspector ([https://github.com/node-inspector/node- inspector](https://github.com/node-inspector/node-inspector)), the most prevalent Node.js debugging tool, at least until Node v6.3.0. And which also happens to be mentioned by Jam3/devtool in the Comparisons section.

2\. Built-in Chrome DevTools debugging support as of node v6.3.0 ([https://medium.com/@paul_irish/debugging-node-js- nightlies-w...](https://medium.com/@paul_irish/debugging-node-js-nightlies- with-chrome-devtools-7c4a1b95ae27#.knjnbsp6t)). Simply by running:

> node --inspect foo.js

<comment><USER5> Thanks for pointing these out. I tried using the --inspect flag like your article pointed out but I couldn't get it to work with Chrome 54.

I can't really give a compare and contrast between what I'm using and the --inspect flag. From the article, I feel like I'd like --inspect better if I could get it to work.

</comment></comment></comment></comment></comment><comment><USER8> I was confused when writing a NodeJs script last night which ES* features were supported in the node runtime I had installed (6.9.x).

This blog posts mentioned Node already fully supports ES6.

Is there a table anywhere that lists ES6/ES7 features and which nodejs version supports it natively?

I assume async/await (which I love and use from TypeScript) will only be available in Node 7.x and not 6.x.

The Node.js home-page makes node 7.x look scary unstable, is there any real- world caveats to using it?

<comment><USER9> You might find this useful. [http://node.green/](http://node.green/)

<comment><USER8> Yes!

I swear I googled for something like this and came up empty multiple times. Thanks!

</comment></comment></comment><comment><USER10> Well, v8 is no longer the only alternative. Now there's Chakra as well.

[https://github.com/nodejs/node-chakracore](https://github.com/nodejs/node- chakracore)

Many native modules are however v8 modules, not sure how that may work.

<comment><USER11> Are there any benefits at the moment?

Like, use V8 if you need X, use Chakra if you need Y etc.

<comment><USER12> Chakra supports 'time travelling debugging with reverse continue':

[https://blogs.windows.com/msedgedev/2016/11/29/node- chakraco...](https://blogs.windows.com/msedgedev/2016/11/29/node-chakracore- vm-neutrality/#UOcG8uW9JDikObLg.97)

</comment></comment></comment><comment><USER13> The number one thing Google could do to improve v8, IMO, is to give it an easy to use cross platform build system. CMake for example. V8 has repeatedly changed build systems. From SCons to Gyp and now to GN. All of these systems have been fraught with errors. Just try building the latest v8 on OSX, Windows and Linux. The SCons system was actually the most reliable. It may not have had all the fancy features of the newer build systems but it was much easier to reliably reproduce the builds.

The second biggest improvement would be to simplify the API. Using Contexts, Isolates, HandleScopes, etc. is complicated and causes the code to crash in unpredictable ways when you get it wrong. The API was built with Chrome's internals in mind and this shows.

<comment><USER14> On your remark on the enbedder api: work is underway to define an engine agnostic C api for node.js compiled addons. See [https://github.com/nodejs/vm](https://github.com/nodejs/vm)

<comment><USER13> That would be great. You should work _with_ the Chakra guys. I've created a engine agnostic API for C++ here: [https://github.com/CauldronDevelopmentLLC/cbang/tree/master/...](https://github.com/CauldronDevelopmentLLC/cbang/tree/master/src/cbang/js) It currently works with v8 and Chakra.

One of the key advantages of my API is that by using a "sink" interface it can be very efficient because the implementation calls the engine's API directly with out creating intermediate data. As I mentioned this is in C++ but it could easily be translated into a C API.

Let me know if you would like help with this.

</comment></comment></comment><comment><USER15> That all sounds great, but... modules. The biggest thing they could do is natively support ES6 modules.</comment>


Increasing MOOC completion rates - <AUTHOR> https://medium.com/p/a3a211a4a52f

<comment><AUTHOR> Would love some of your thoughts on the subject...</comment>


Metternich's strength in law - <AUTHOR> https://newcriterion.com/issues/2019/11/metternichs-strength-in-law <comment><USER2> What got you "convinced that Metternich would have been a Brexiteer"? The fact that Metternich didn't like empires seems hardly enough for such an important statement. What would Metternich have had to say about all the other negative consequences, like isolating a country, putting it at the mercy of another empire (USA), just to name a few? Brexit seems to be more like a revolution of the working class, something Metternich would have deeply distrusted.

</comment><comment><USER3> > "Siemann does not believe he ran a police state, not least because Austrian > cities, towns, and villages had no police forces."

In Austria the name of Metternich has been and still is synonymous to the police and surveillance state. (Comments on recent ambitions aimed at more intrusive policing and/or surveillance commonly run by the tag line "Metternich2.0".)</comment>


I'm leaving Facebook - <AUTHOR> https://thewavingcat.com/2017/12/16/im-leaving-facebook/ <comment><USER2> Saving clicks: the title should be read as "I'm no longer using Facebook", not "I no longer work for Facebook"

<comment><USER3> It would have been much more interesting to read a former Facebook employee's story about leaving the company rather than one of their billion users deciding to move on.

</comment></comment><comment><USER4> So brave.

<comment><USER5> "Again, this isn't a political statement. "

I totally thought it was a political statement. Stick it to the man and all that. It's this generation's Vietnam.

I'm sure there'll be another "why I'm leaving Facebook" post in a few minutes - there certainly seem to be a plague of them; perhaps one of the next few will be by someone with the bottle to do it for purely political reasons.

</comment></comment><comment><USER6> These posts about people leaving their jobs are so egocentric.

Who cares if some dude is leaving a big company.

<comment><USER7> Didn't even read the article, did you?

</comment></comment><comment><USER8> Seems very reasonable.

</comment><comment><USER9> see you soon on the other side, spacecowboy!

</comment><comment><USER10> Courage.

</comment><comment><USER11> "In order to verify your identity so we know it's really you trying to delete your account, please send a picture of your government ID.. and also some nudes." \- MZ</comment>


Driving a real car with a videogame controller - <AUTHOR> http://www.youtube.com/watch?v=nIRUavithF8

<comment><AUTHOR> Also, this:

<http://www.youtube.com/watch?v=2l9FsmhiMEY></comment>


The Asus ZenBook Pro UX550 Could Put the MacBook Pro to Shame - <AUTHOR> http://www.laptopmag.com/articles/asus-zenbook-pro-2017-specs-features <comment><USER2> The current Asus ZenBooks get a lot of love in Reddit recommendations: [http://laptopkarma.com/?brand=Asus](http://laptopkarma.com/?brand=Asus)

</comment><comment><USER3> It's not available for order yet but it sure compares favorably to Apples offering that's a year old and going to be replaced in two weeks!</comment>


How America Lost Faith in Expertise and Why That's a Giant Problem - <AUTHOR> https://www.foreignaffairs.com/articles/united-states/2017-02-13/how-america-lost-faith-expertise <comment><USER2> Also of interest: Tom Nichols, _The Death of Expertise: The Campaign against Established Knowledge and Why It Matters_ ([https://www.amazon.com/Death- Expertise-Campaign-Established-...](https://www.amazon.com/Death-Expertise- Campaign-Established-Knowledge/dp/0190469412))</comment>


Apple's Watch Is Smarter, but My Casio Keeps Getting the Job Done - <AUTHOR> https://www.nytimes.com/2019/08/23/business/apple-watch-iphone-casio.html <comment><USER2> About 5 years ago I bought probably the last watch I'd ever need. It's a solar powered Casio with timezones, and the normal 'digital watch' accoutrements. The little energy-saving details are fantastic. It has analog hands with a small digital screen. Why waste energy on backlighting when you can use glow in the dark paint that charges with the same light as the energy source? Too dark or too still? Turn off the screen until you move the watch. There was a time when it was in a drawer for a couple months while I was traveling, and when I got it out and put it in the sun, it fired right back up, and adjusted the time itself. I've seen it drop into a low charge maybe twice. It feels like it's meant to last forever, and I believe it's probably some of the best 50 bucks I've ever spent.

I've used a Fitbit and a couple friends have Apple watches, but the entire concept of charging an always connected timepiece just makes no sense to me.

<comment><USER3> How did it adjust its own time? I'm guessing GPS receiver?

<comment><USER4> Casio have a brand called WaveCeptor that picks up radio time signals transmitted from around the world; GPS is an enormous power-suck (receiver and processing) so using it for time is impractical on a low-power device.

</comment></comment></comment><comment><USER5> The Casio is from a time when there wasn't a clock staring at you every time you turn around. If the choice were Casio or nothing, I'd just stick with nothing. A time keeping device on my wrist solves no problems for me (except running, in which case the Garmin comes out). A Casio "gets the job done" in the same way a buggy whip still gets the job done: it's a job that kinda doesn't need doing anymore, at least for me.

If there were a wrist-worn device that can track my runs, open my garage door, turn on the lights, remind me to water the neighbor's plants tomorrow at noon, play me some music and...oh, what the hell, tell me the time, too...THEN we'd have something worth wearing on my wrist all day. Which is why I have an Apple Watch and not a Casio.

<comment><USER6> I've found that sometimes I want to know the time without pulling out my phone, had a citizen eco drive that was solar, loved the thing until it just created a rash on my wrist.

<comment><USER7> I think this is why I like my dumb watch. I already spend too much time on my phone and checking the time on it just triggers further procrastination.

</comment></comment></comment><comment><USER8> A relative of mine recently got an Apple Watch as a gift. He has since been transformed by it. The health/fitness reminders/achievements are huge motivators for him - he was fairly fit, but now he is in the best shape since I have known him. Im thinking of getting one too :-)

<comment><USER9> This is the same for me. I don't know what it is about it but when I get the notification that there's an award available for a certain holiday or season, I _have_ to get it. I don't really even share that I've gotten the award or tell people about it even though I should. Just the thought of not being able to do one of these challenges physically makes me so much more motivated to do every one of them. It's almost like I'm trying to prove to myself that I'm not out of shape. Once that got me hooked, then I got to where I wanted to close all my rings every day. Now, it's just something that isn't really an option for me anymore unless I absolutely can't (because I'm on a long plane flight or somehow otherwise incapacitated). I'm not in the best shape of my life but I'm in much better shape than I have been in a very long time.

It's so stupid but this watch plus my AirPods are kinda life changing. I swear I'm not being paid by Apple to say this, either. There are still some issues obviously but, on the whole, it would take a lot to get me to stop wearing this thing.

<comment><USER10> I too love the Apple Watch and the AirPods combination. Seems like the iPhone is becoming the computer and the watch is the new smart phone.

</comment></comment></comment><comment><USER11> All I want is another Pebble...such a shame how the company folded and "acquired" by Fitbit. I own a Versa and I can definitely see the similarity to the Pebble app but it's not quite there. I wish Fitbit will bring back the E-ink like screens.

</comment><comment><USER12> I own two classic watches and a Fitbit Versa. Personally, found notifications from the watch to be more distracting as a I try to escape my phone screen. Additionally, having all that health data may seem like a blessing, but for me it was just more worry in disguise. I'd constantly analyze the data, research anomalies, and maybe even give myself health anxiety all while my health was perfectly fine. Smart watches are certainly not for everyone!

<comment><USER13> I keep email notifications completely turned off, and only turn on app notifications for a few select apps.

</comment></comment><comment><USER14> I use my smartwatch(A fitbit versa) to tell me my heart's rough bpm, steps I walked, notifications from my phone, time and as a stopwatch. I could certainly take out my already 'obsolete' smartphone, but the wristwatch is a more convenient form.

That's it.

All I wanted is e-ink for longer battery life so that I can charge less, and bluetooth that actually fucking work.

I wasted so much time trying to troubleshoot bluetooth issues to sometime to no avail.

<comment><USER9> I used to be a huge fan of the FitBit. I've got multiple FitBits from multiple product lines (meaning I have more than 1 of the same device for multiple devices) and I have all the accessories that went with them (Aria scale, watches, etc.). Every single one of them has been replaced either under warranty or purchased specifically to replace another device that failed within the first six months of the 1-year warranty. The customer support has been pretty fair about replacing them and even replaced one that we admitted accidentally went through the washer because we had emailed about the same issue while it was in warranty still.

But... I'm over the regular hassle of everything just suddenly not working at all. On some of them it's the strap which is less of a deal. On others it's the display. On other things it's the motion sensing. On another it's the pairing and bluetooth. Everything is just such a headache that, cumulatively, I couldn't do it anymore. The fact that they also don't sync to anything except their own portal unless you pay for a third-party app to connect to it is another nail in the coffin.

Haven't so far and don't ever plan to go back to the FitBit world. Once this latest scale and tracker die, I'm out.

</comment></comment><comment><USER15> I recently went back to traditional watches because I was frustrated with being able to control notifications in a granular way.

Ultimately, I need the time, preferably in two time zones, and the date. I've got a GMT watch now and a Casio I use for when I'm working on the house of in the yard.

I like my Apple Watch for workout tracking, but that's the only mileage it gets these days.

<comment><USER9> What's your use case for the notifications? I took some time to pick which notifications get sent where and it helps me keep off social media and keeps me focused on what I'm doing. If it doesn't come to the watch, it's not important and if it comes to phone and watch, then it's not time-sensitive and I can respond whenever. If it just comes on the phone, then it's an alert for a game or something mindless that I only care about when I'm bored.

<comment><USER15> It's not so much a problem with the watch as it's not really in line with the way I want to interact with my watch.

As I've gotten busier, I prefer a pull model, not a push. I block off parts of my day and don't want to be disturbed. It became a hassle to police and that's okay.

I originally bought it to give me a better sense of my activity level. I now understand that and will continue to use it for workouts but it's just not interesting as an every day wear sorta thing.

<comment><USER9> Hmm... you can't set up Do Not Disturb to turn on during those times? I'm not trying to be argumentative, I'm just surprised because I've experienced the exact opposite. As I've gotten busier, the watch has helped me prioritize what contact is important and what's not. My wife, for example, can always contact me, even if I'm in DnD. No one else can, though.

</comment></comment></comment></comment><comment><USER16> The two features I probably find most valuable with my Apple Watch are that it's usually easier look at my wrist to see if I'm getting an important call rather than having to dig into my pocket, jacket, or bag to find the phone, and then I wake up 1.5 hours earlier than my wife and the vibrating alarm means I'm much less disruptive.

<comment><USER17> Question from a non-Apple watch user, but an interested prospective consumer: if you have to charge your watch at night, how do you use it to wake you up?

<comment><USER18> It charges very quickly, and I usually charge before bed, during shower, etc.

</comment></comment></comment><comment><USER19> I prefer my Hamilton Khaki. Never needs a new battery, and looks nice and clean. About the same price as an Apple watch for almost none of the functionality, but I really like the idea of a mechanism keeping almost perfect time, just powered by the movements of my arm.

<comment><USER20> Beautiful watch. On top of looking good, it will never be 'outdated'. Your average _insert here smartwatch_ will be outdated in 2 years as technology evolves.

<comment><USER21> I've a series 2 Apple Watch and it surprisingly still do its job well. I don't except much from it, and it even became better with time with new watchOS releases.

</comment></comment></comment><comment><USER10> I don't know what is the point here in comparing to a regular watch. Does the Casio allow one to leave the phone behind and pick up a call on watch and AirPods ? Does it slightly nudge if you have sitting too long in an hour?

Clearly Apple Watch is meant more for that.

<comment><USER22> >I don't know what is the point here in comparing to a regular watch.

The author is questioning the utility of doing all that bullshit from something strapped to his wrist.

>Clearly Apple Watch is meant more for that.

You don't say?

</comment></comment><comment><USER23> Bah, newfangled DIGITAL watch!? Kids these days... What's wrong with winding up your watch every now and then? And he even admits when it breaks he just throws it away and buys a new one! In MY day, watches were built to last for generations! Why did they have to fix what wasn't broke with all these electronics!

(looking forward to the day when I'm the one clinging to my old-fashioned Apple Watch, complaining about the kids with their wrist live-tattoos or eyeball implants or god knows what is coming)

<comment><USER24> Sir, disposable watches have been put together with rivets and spot welds since time immemorial.

</comment></comment><comment><USER25> There is so much to be said about mature technology.

I still carry and pen and paper everywhere I go smart phone be damned.

<comment><USER26> > SN76477

... Ah, you're a sound chip! I had one of those. The sweet memories of teenage electronics projects circa 1985...

<comment><USER25> Thanks for noticing!

</comment></comment></comment><comment><USER27> I've got the solar-powered Casio that synchronizes with WWV every night, and it is splendid. However, I have read that WWV is going QRT this year. Is that so? When?

<comment><USER28> Pedantically its WWVB, the LW digital code version, not WWV the SW station. WWV/H/B were at risk for defunding, but their funding was renewed.

</comment></comment><comment><USER29> I must admit I bought a F-91W just because it's the terrorist watch, but after wearing it a few times got sold and haven't taken it off.

I forgot the pleasure of wearing a simple watch.</comment>


At the Blackboard:  Kurt Vonnegut diagrams the shapes of stories (2005) - <AUTHOR> https://www.laphamsquarterly.org/arts-letters/blackboard <comment><USER2> In 2016 people analyzed a bunch of fiction and these trajectories showed up:

[https://arxiv.org/abs/1606.07772](https://arxiv.org/abs/1606.07772)

Articles about:

[https://www.technologyreview.com/s/601848/data-mining- reveal...](https://www.technologyreview.com/s/601848/data-mining-reveals-the- six-basic-emotional-arcs-of-storytelling/)

[https://www.theatlantic.com/technology/archive/2016/07/the-s...](https://www.theatlantic.com/technology/archive/2016/07/the- six-main-arcs-in-storytelling-identified-by-a-computer/490733/)

<comment><USER3> The arxiv paper holds a link to the hedonometer, where all books in Project Gutenberg have been mapped. [http://hedonometer.org/books/v3/1524/](http://hedonometer.org/books/v3/1524/)

<comment><USER4> I love the "per word happiness shift". I could totally see an ill-conceived startup offering a quantified self analysis tool... "with our handy all-day surveillance via your phone, we will analyze every word said by or to you and help you understand your per-word happiness shift!".

</comment></comment></comment><comment><USER5> I think some people are taking exactly the opposite from this talk than what Vonnegut intended.

It is not like Vonnegut have discovered stories have different dramatic curves. This was common knowledge at the time of Aristotle. The genres Tragedy and Comedy was _defined_ by the Greeks according to the curve of fortune: A tragedy was about bad things happening to good people (to put is succinctly) while comedy was the opposite.

So the curves of fortune have been fundamental for the understanding of drama since antiquity.

What Vonnegut is pointing out is that in Hamlet the change in fortune is actually not so clear-cut. It is often ambiguous if what happens is actually "good" or "bad". So you cant really plot it on such a curve. Hence his assertion that Shakespeare was a bad storyteller - at least according to simplified narrative models.

What he actually states is that real life is too ambiguous to plot on a god/bad curve, and that Hamlet is a masterpiece because it reflects this ambiguity.

He is _not_ condoning Heroes Journey or other cookie-cutter narrative models.

<comment><USER6> This is an excellent summary.

> I think some people are taking exactly the opposite from this talk than what > Vonnegut intended.

It's understandable though: Vonnegut spends more than half of the talk explaining the curves. When he comes to the really interesting point about Hamlet the connection to the first part is only loose. He only references _Cinderalla_ and _The Metamorphosis_.

And this is were my real gripe is: Of all the typical comedies and tragedies of the world he could have chosen any two to make his point. But he chose _The Metamorphosis_ which is one of the worst examples to support his point.

Sure, Gregor Samsa starts out in a bad position, but does he end worse? He doesn't seem to be concerned much about his death. Besides that everyone else in the novella ends up much better than in the beginning and the last chapter is certainly the brightest (warm sun and all).

</comment></comment><comment><USER7> There's an excellent video where he goes through these [0], worth a watch if you have the time.

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

</comment><comment><USER8> If you're interested in story structure, Dan Harmon (creator of Community, co- creator of Rick and Morty) wrote some great tutorials that you can read here: [http://channel101.wikia.com/wiki/Story_Structure_101:_Super_...](http://channel101.wikia.com/wiki/Story_Structure_101:_Super_Basic_Shit)

It's basically a distillation of Joseph Campbell, and it's really entertaining and informative.

</comment><comment><USER9> I remember reading about how older stories - Odyssey, creation myths, god myths - are a different "sort" of story than we have now, and miss notable elements such as twists. Mysteries weren't a thing.

And, that this was because these stories were primary told through oral tradition, so you would hear the same stories over and over again. So stories that weren't enjoyable when you knew what would happen either didn't get told, or didn't last.

Now, we experience most stories only once, so things like twists work.

Thought that was an interesting idea, and Vonnegut's take on primitive stories reminded me of it.

</comment><comment><USER10> I wonder if there's a decent correlation between the Vonnegut diagram of a movie's protagonist and the movie's box office. I'd guess that flat and monotonic downward curves are at a disadvantage, an upsloped ending an advantage. But you might be able to find interesting things about the number and intervals of minima and maxima, etc. It'd be interesting to look at the magnitude of the peaks and troughs too, but how would you calibrate the x axis across movies or between scenes?

If it works you could be as successful in Hollywood as Raffles, the barefoot executive.

<comment><USER5> Oh yeah, basically all successful manistream movies follows the same dramatic model with standardized plot points designated "inciting incident", "midpoint", "point of no return" and so on. You are not going to revolutionize Hollywood with this insight. See: [https://en.wikipedia.org/wiki/Three- act_structure](https://en.wikipedia.org/wiki/Three-act_structure)

I think Vonnegut is actually satirizing this and saying truth is more important than dramatic structure. Popular fiction tend to have very clear dramatic curves, but Vonnegut is saying real life is more ambiguous.

<comment><USER11> I am really amazed at how much we talk about that 3 act structure. Basically, it says, well, you have a beginning, and then a middle, and then the story ends. Not very helpful for writers, and it is not even descriptive.

If only it told you "well, your first third is the beginning, next third middle, last third ending", but no. Actually, the second act is usually twice longer than each other, as shown in the wikipedia article, and it is usually cut in two parts, as there is a huge event in the middle ("No, I am your father"-kind-of-event). OK, so, basically, you have 4 acts, right? Why not call it a 4-act structure? And you still don't know how to structure them.

OTOH, I like Lester Dent's famous master plot formula, written in the 30s for pulp fiction short stories: [https://www.paper- dragon.com/1939/dent.html](https://www.paper-dragon.com/1939/dent.html) . It is written for action-packed short stories, obviously, but describes pretty well the structure of most Hollywood successes, too. And it can help writers, well, write interesting stories (although it must be adapted, obviously, unless you are writing a "must defeat the villain" story).

<comment><USER12> > OK, so, basically, you have 4 acts, right? Why not call it a 4-act > structure?

Because there's a fairly concrete distinction between acts in stage plays, and that's how plays using the structure are tradition broken up (act divisions in film and novels are often more metaphor than concrete, so, yeah, without the stage precedent, it would make more sense to name it for the four parts, two of which are jammed together in the three-act model.)

> And you still don't know how to structure them.

Yes, you do; the general "shape" of the structure had been described in detail for a long time; the three-act structure isn't just "a beginning, middle, and end", it's a very particular shape (the Wikipedia page is a good brief description, but their are good sized books covering it in detail.)

> It is written for action-packed short stories, obviously, but describes > pretty well the structure of most Hollywood successes, too.

Not really; it's got a lot of genre and form specific but, though it's certainly not entirely useless outside of that focus. _The Writer 's Journey_ is better for describing the shape of Hollywood successes ( _Save the Cat_ does so even more precisely for recent ones, providing very close to a minute- by-minute breakdown.)

<comment><USER11> > Because there's a fairly concrete distinction between acts in stage plays, > and that's how plays using the structure are tradition broken up (act > divisions in film and novels are often more metaphor than concrete, so, > yeah, without the stage precedent, it would make more sense to name it for > the four parts, two of which are jammed together in the three-act model.)

I don't know, lots of classical works were written with more than 3 acts, for instance lots of works from Molière, Corneille or Shakespeare consist in 5 acts. The legend says back then acts were as long as the candles lighting the scene lasted, but I don't know if it's true. If it is, it's the old equivalent of five act structure in tv series, mandated by commercials' breaks: the number of acts is determined by external reasons, not narrative ones.

> Not really; it's got a lot of genre and form specific but, though it's > certainly not entirely useless outside of that focus. The Writer's Journey > is better for describing the shape of Hollywood successes (Save the Cat does > so even more precisely for recent ones, providing very close to a minute-by- > minute breakdown.)

Yeah, I forgot about those 2 (I wrote my comment in a hurry). They are way better examples, for sure.

</comment></comment></comment></comment></comment><comment><USER13> I have no clue what Vonnegut's speaking voice/manner is like, but I read this with Feynman's voice, and it worked very perfectly.

<comment><USER14> Here is a video version of it so you can hear! [https://www.youtube.com/watch?v=oP3c1h8v2ZQ](https://www.youtube.com/watch?v=oP3c1h8v2ZQ)

</comment></comment><comment><USER15> I had the great fortune of seeing him do this live, back in the last millennium. The best one had to be Kafka's "Metamorphosis".

<comment><USER16> I think that warrants a more detailed account of the story... do tell?

</comment></comment><comment><USER17> I highly recommend The Sirens of Titan by Kurt Vonnegut - little read compares to his other books but fantastic Sci Fi IMO.

<comment><USER18> I love that (well, and _Breakfast of Champions_ ) so much I could never get into his other novels much, because _they 're not them_. _Sirens_ was the first novel that I _really_ connected with. I've read it so many times. "It flung them like stones." Ha, come to think of it, I was in a band called _The Ghosts of Saturn_ , my brother was in one called CSI (ChronoSynclastic Infundibulum).. Isn't there supposed to be a movie coming out soon?

Once years ago I was in a 2nd hand bookshop in Sydney, and could hear a few staff members chatting excitedly in a back room. They were laughing over plot- points in _Sirens_! I listened for a long while, without revealing my presence. It was glorious. :-)

It just occurred to me to recommend to anyone who hasn't seen it the movie _Gentlemen Broncos_. I hadn't associated that and _Sirens_ before, but there are many similarities. It's totally sci-fi, totally hilarious, and has a kind of Vonnegutian sugar-coated melancholy too. 5 stars!

</comment></comment><comment><USER19> > I have just demonstrated to you that Shakespeare was as poor a storyteller > as any Arapaho.

What do the Arapaho have to do with any of this?

<comment><USER20> It's a callback to the section about "primitive peoples" and their supposedly flat stories.

</comment></comment><comment><USER21> I learned this in a creative writing workshop and now I can't never think of a story without these guidelines. Every story each time fits into one of those descriptions, even the things that I write somehow end up being a shape of a story as described by Vonnegut. I find it very helpful but at the same time exasperating.

</comment><comment><AUTHOR> An infographic version [http://www.mayaeilam.com/2012/01/01/the-shapes-of- stories-a-...](http://www.mayaeilam.com/2012/01/01/the-shapes-of-stories-a- kurt-vonnegut-infographic/)

</comment><comment><USER22> As an aside, I always thought that Polonius' advice to Leartes is excellent, and certainly did not read it the way Vonnegut implies.</comment>


The growing dissonance between two business models (SaaS and VC) - <AUTHOR> http://christophjanz.blogspot.com/2017/05/the-growing-dissonance-between-two.html <comment><USER2> I think a lot of VCs are hammers looking for nails. Seems like that they model reality as if anything under 100M is worthless. Because it won't IPO. But it seems to me like there's a huge opportunity to have a 50M business that buys 2 20M businesses and a few smaller businesses. You could still get there. Especially if you negotiated on the valuation in the early days. And kind of managed expectation with the enterpenuers early on.</comment>