Show HN: Empathize – manage user conversations easily - <AUTHOR> https://getempathize.com/?utm_source=hn <comment><USER2> I like the UI and the design. The tool feels well integrated. However I'm not sure of the added value. What's the difference compared to the invite I send out directly from Google Calendar?

BTW, if you'd like to get some more free UX feedback, please feel free to visit our UX community platform at [https://usability.testing.exchange](https://usability.testing.exchange)

<comment><USER3> Can you and Kaj stop mentioning your website whenever you comment? It's the 7th time in the last day and and feels like you only take time to give feedback in order to be able to add a link (provides value for yourself).

<comment><USER4> Hi, sorry about that, we shouldn't do like above.

You're correct that so far we've been commenting when the person we reply to, can get more feedback about his/her stuff, at usability-testing-exchange (UTX). And, in cases when we've posted _lots_ of helpful feedback, and also a link to UTX, then people have appreciated it, said thanks or upvoted, and some of them went to UTX, helped others over at UTX, and got even more feedback back him/herlself.

In this particular case, though, the actual feedback is brief — about the same length as the "see UTX" line. And I understand that that doesn't feel good.

I think we should write lots of more more helpful feedback, than the text occupied by the "see UTX" line. Look at my other reply (with feedback to OP) on this page for example.

About providing value (which maybe we didn't do so much this time): The purpose is to 1) help the people we reply to, so they can improve their websites & software. And 2) to slightly slightly improve the quality of the ShowHN submissions (feedback —> impovements, better submissions), which I would think is good for the readers here at HN. And 3) making people aware that UTX exists.

So this is supposed to be good for everyone: 1) people who posts ShowHN:s, 2) for the readers here at ShowHN, and 3) for us/me.

However in this case, as mentioned, the "see UTX" line seems a bit distracting and promotional, because the actual feedback is so brief. We shouldn't do like that in the future.

* * *

Sorry @dpandya (original poster) for this off-topic discussion from your point of view. Anyway I guess you're interested in feedback about your service? (Since that is one of the points with ShowHN, right.) — I gave Emphasize a try, and left feedback in another comment here.

</comment></comment></comment><comment><USER4> Ok Emphathize seems like something that could possibly be useful to me, I'm trying to do a startup, and I'm planning to contact some people who signed up for some software I'm developing, but then abandoned it. So I think I'm your target audience.

First: This doesn't tell me much: "Schedule customer conversations with ease." The next line though, makes me intrigued :-) (i.e. _" Everyone says you should talk to your customers. Our software makes it painless."_)

What about a shorter & simpler headline like "Talk with your customers. Our software helps you do that."

"See a sample email" — good idea, I wonder how to write such emais in a good way. I click "Get sample email", before scrolling down & reading more.

Ok here's the email I got.

        David from Empathize wants to speak to you!
        We would love to hear what you think about our product over a 30 minute phone call.

To be honest, my reaction to this is "Gaahhh! They think I have 30 minutes of my time to spare, to help them? Never going to happen."

From my perspective, as someone who gets this email, if you want me to _work_ for you for 30 minutes, you need to provide some compensation. Like $30. Or giving me your service for free for 6 months.

Anyway I click "Pick time" to test what'll happen ...

About the "Please select a time" page:

Which time zone? 12:00PM could be 02:00 AM to me, for all I know :-)

I feel slightly frustrated because the schedule seems adjusted for what's good for _you_ , not for what's a good time for _me_ (I now being the one who will give feedback to the company). If you really want my feedback, then you should let me pick any time I want 24 o'clock, and then adjust your schedule.

(If you pay me $$$$ then it's OK though if I need to adjust to your schedule.)

UX problem: After selecting a time, I clicked `[ > ]` instead of Submit, and didn't immediately undrestand what then happened.

I think: 1) Change from just `[ > ]` to `[ > next day ]` to make it clear what those buttons do. And 2) Make the submit button look more like a button, instead of like a footer, by making it narrower, maybe 2-3x as wide as the Submit text (but not as wide as the page).

Ok I click Submit. And see the text "Please complete all items above". What? Ok ... after a while I understand I need to fill in my phone number...

...Somehow make it more obvious that I need to type my phone number above. Hmm, interesting that I totally didn't see the phone number input. In retrospect, it looks as if it ought to be easy to notice.

...Maybe the problem is that everything is in bright gray — looks like not- importrant-secondary-stuff. Instead, what grabbed my attention was the large calendar in the middle, and that's where I started.

Ok I got to "Thanks! The call has been scheduled."

I'm looking now in my Google Calendar, but don't see any appointment there yet. Of course, since I haven't signed up. I suppose maybe only the company's staff will get their calendars updated.

\---

I look at "How it works", and find: "We automatically handle giftcards ..." — how do you do that?

To me that seems like crucial for getting someone to answer a phone call. What about including a gift card, in the "Get sample email" demo?

I look at "What makes us special", and "Email templates that work" — I would want to see some of those email templates; I'll be sending similar emails myself soon some day.

I would want the option to give _money_ as "thanks" to the customer, not only a gift card.

Curious about pricing.

From what I've seen this far, of Emphatize, I'd actually prefer writing my own emails, and asking for feedback _in text_ via email instead — I'm thinking people might have time to reply with an email to an email ... but not for a 30 min phone call. Also, if I get feedback in text, I can just copy-paste it into a todo document (rather than having to listen to a phone call and take notes myself).

Can I ask how did you come up with the idea to build Emphathize?

Have you validated that a talk-with-your-customers service is something companies are actually looking for? What if maybe they (like me) prefer asking for & getting feedback via mail instead? Or maybe they use some customer- relationships-management system that already has get-feedback functionality built-in?

Maybe there are more "Talk with your customers" stuff that you can expand Emphatize to include? The concept of a company that helps other companies talk with their customers, seems like something that could actually work. But I'm hesitant right now about if the service you provide, is enough, for companies to get interseted.

What about contacting some different companies / startups, and talking with them about how they do when talking with their customers, and what they might need / want from you? Then maybe good to first read the available-for-free- online chapters in this book: [http://www.startupwerkboek.nl/startupcenter/Momtest.pdf](http://www.startupwerkboek.nl/startupcenter/Momtest.pdf) (The Mom Test). It's about finding out if people are truly & honestly interested in the things one wants to build. —Maybe you'll come up with more useful features, or re-focus completely to something else.

Best wishes anyway.

<comment><USER4> More details about this: _" I would want the option to give money as "thanks" to the customer, not only a gift card."_ – the most valuable people to get feedback from, are the ones who _abandoned_ the service?

They are not likely to be interested in a gift card, ... they don't want to use the service any more, right.

But if you pay them money, then they might have time for a phone call with you.

Or, if you send them an email, and ask what problems they found with the service — _and_ tell them that the reason you're asking is that you want to fix the problems. So that maybe some day in the future, the service will be sth they will want to use. That can also motivate them. (But, I think, not enough for scheduling a phone call. Only to write a brief email back to you.)</comment></comment>


The Startup Dragon - <AUTHOR> http://wesleytansey.com/the-startup-dragon/ <comment><USER2> While I agree with your sense of how valuable your time is, (really in any endeavor, not just startup life), I disagree with the implication that just doing more, quickly, will help you slay or avoid the startup dragon.

It is often the case in my own life that one or two days of solid, no-stress thought time can save many weeks, sometimes months of effort.

I think it can be particularly hard to take this time when you're cashflow negative, in the press, and the clock is ticking.. That is precisely when you most need to take that time, of course. :)

</comment><comment><USER3> Tansey is a great commenter/submitter and I respect his opinion, and I also mean no disrespect to the people working on LLL, but honestly the reason I wouldn't use a tool like this is because I don't think it is useful.

Look at the screenshots. <https://www.leanlaunchlab.com/#screenshot-canvas>

"Key activities: Write code. Meet entrepreneurs. "

"Cost structure: Employees. Rent"

These are obvious. These arn't things that need to be written down in a planning app. A 10 minute smoke break and it should be in your head for good. Then a month later they are in an accounting app or spreadsheet with hard figures on them.

Then there is an internal blog with commenters talking about learnings and whether or not angel funded startups have board meetings. Common, do people really needs this?

It's starting to feel like everyone talking about "lean startups" is just trying to "play business" instead of making an awesome product that solves a real problem and hustling hard[1] charging people as much as they can for it. The whole thing reeks of MBA BS.

[1] (read: meeting clients, split testing, funnel marketing, optimizing adwords, etc. not writing internal blog posts about how you feel things are going)

</comment><comment><AUTHOR> Fun article to write. I crowdsourced all those images on Mechanical Turk in about an hour. Best $2 I ever spent! :)

<comment><USER4> Nice one. And that's awesome. Do you have the mturk job writeup? Curious to see how the description matches the actuals.

<comment><AUTHOR> I didn't save them. They were something along the lines of:

"Draw a man in a cave being chased by a fire-breathing dragon. He is desperately trying to remove a bunch of stones that are blocking his path. A fairy and a forklift just appeared beside him."

I can only hope that I made the turkers laugh a little bit when they saw that. :)

<comment><USER4> Cool. Yeah, my favorite part of turk is using it for more creative jobs like this, had to ask. You should make this a habit with your blog posts - I'd read every post, just to see how a turker interprets your startup experiences.

<comment><AUTHOR> I actually am planning on doing that! I had an idea for one today that I'll probably post later next week.

</comment></comment></comment></comment></comment><comment><USER5> Personally, when ever my back is against a pile of rocks is when I decide to try out the forklift. When ever I have a pile of schlep that I've been doing manually (or when I see that I will have to do it manually) I usually opt for the forklift if I can see it will reduce that schlep and net me some time.

The payoff can't be a thin margin either. If doing it manually vs learning a tool will save me a few hours total, It's not worth it. However if writing a script will save me days on end in the long run I'll think about it.

</comment><comment><USER6> Read Four Steps To The Epiphany. Steve describes exactly what you're writing about, pretty much even the dragon:

"The hero's journey is an apt way to think of startups. ... Obstacles, hardships and disaster lie ahead... It tests their stamina, agility, and the limits of courage.

Most entrepreneurs feel their journey is unique. Yet what Campbell perceived about the mythological hero's journey is true of startups as well: however dissimilar the stories may be in detail, their outline is always the same. Most entrepreneurs travel down the startup path without a roadmap and believe that no model or template could apply to their new venture. They are wrong. For the path of a startup is well worn, and well understood."

</comment><comment><USER7> Lets take the analogy a bit further. Lets say you've now determined that unless you move the rocks faster by finding a better way to move them, there just isn't enough time to move the rocks before the dragon gets you. To continue to do what you're doing, knowing you will fail without getting better is pretty foolish now. To me that's the one of the essentials of lean. Having the adaptability to learn and the recognition of when that time is necessary and crucial.

Sure there are tons of Lean and Agile tools out there that waste more time than they save. Where a whiteboard will do a better job and do it faster and cheaper. I agree many of these tools should have the stamp "Cargo Cult" on their landing page (caveat: I've never used LLL, but I love the lean canvas, it's just that pen and paper is good enough for me). I'll even go so far as to say that I think the market for "tools" exists at least in part for people who are not interested in really learning, but want to follow a step-by-step road map through the product development processes. This is clearly wrong and a colossal mistake. How can anyone honestly learn from the product development process if they are just following the prompts?

So while I think you've probably made the right decision, your analogy makes me wonder if you've done it for the wrong reasons.

</comment><comment><USER8> This is where having lots of experience comes in play. It's possible to hire lots of people, someone to operate the forklift, a geologist to evaluate the stones, a physicist to plot flight paths for the stones, etc.... but each hire will slow your startup down. Work with someone who has done a startup before, or get mentoring from that person. This will teach you to use the right tools at the right time before you end up in such a pinch.

</comment><comment><USER9> I kind of stopped using LLL as a tool because initially it was really horrendous and frankly, convinced me that release early is not as smart. I checked it out recently, it is much better... still, whole idea about canvas is that I can draw it on paper, I kind of like that. I might use LLL, but not as primary tool for sure.

</comment><comment><USER10> I'm not in a startup and I know nothing about LLL but I do know this: if you're firefighting and say that you don't have time to draw breath, and that you don't have time to learn the right way to get things back onto track, then that means STOP! Reassess where you're going because you're heading for a crash. Take some time out to get things in perspective and take the time to do it right. Cut back a bit on those tasks that seemed so essential but perhaps you could afford to skip them for a week or two.

</comment><comment><USER11> upvote for the drawings</comment>


Why apples CEO met with valve games - <AUTHOR> http://www.cultofmac.com/160760/why-apple-ceo-tim-cook-met-with-valve-exclusive/

<comment><USER2> Interesting, but it's very hard to imagine Apple being MORE open than Microsoft or Sony with their consoles.

</comment><comment><USER3> no official statement or anything like that. the website does not look very trustworthy. the "why" they post is pretty much what everyone else is speculating too.</comment>


Ko – A concurrent, immutable, functional language - <AUTHOR> https://github.com/kocircuit/kocircuit <comment><USER2> There is not a single example in the README. I checked the step-by-step guide, but it starts with installation and documentation instructions, then imports, and I don't know yet how the language feels like. Ok, let's check that handbook then. Computation model, type system, ...

Please, I just want to see a program with a dozen lines of code to see what it looks like. Of course, more extended examples with the intended usage would also be very welcomed.

I eventually found this: [https://github.com/kocircuit/kocircuit/blob/master/lessons/e...](https://github.com/kocircuit/kocircuit/blob/master/lessons/examples/helloworld.ko) but I think it should be much easier to arrive there.

<comment><USER3> The law for making a new language: always include examples up front.

<comment><USER4> For anything _you want other people to use_ really

</comment></comment></comment><comment><USER5> I can't be the only one who's annoyed by language writers introducing arbitrary uncommon syntax apparently just for the sake of doing something new?

Lua's great little language but writing ~= instead of != is simply annoying. In this "Ko" language, it looks like they do returns with a colon, as in "return: x" \-- why??? I won't even go into Rust picking up Perl's bad habit of looking like line noise with all the ASCII sigil usage in advanced code.

Also, any language which doesn't have a "hello world" example in its front page is doomed. Even such a wide-spread language as Python has code snippets practically first thing on its web page! This is not by accident!

<comment> alan-crowe I wonder why they preferred ~= over =/= ?

I would sympathize with using =/= for "not equal" because it is ASCII art for the traditional mathematical notation of using an equal sign with a line through it. Though it might be better just to permit carefully selected unicode characters such as [https://www.fileformat.info/info/unicode/char/2260/index.htm](https://www.fileformat.info/info/unicode/char/2260/index.htm)

=/= is disappointing as art because it is too wide, but it has obvious mnemonic power.

Would you object to =/= as "arbitrary uncommon syntax" because it is poor art? Does its mnemonic power save it from the criticism of being "new for the sake of new"

<comment><USER6> MATLAB also uses ~= but I am not certain that is where Lua got it from. (The paper on the history of Lua does not say...)

</comment></comment></comment><comment><USER7> I don't want to be "that guy", but a small sample in the README would be nice. Tough to tell if I'll like a language if I can't even see it without traversing through the docs.

</comment><comment><USER8> But what's its type discipline? H/M polymorphism? Overloading? Subtyping?

How is it evaluating? Eager? Lazy?

What values are supported? Records? What flavor? Modules?

<comment><USER9> You may find the Ko Handbook useful, as much of this is addressed there:

[https://kocircuit.github.io/language/](https://kocircuit.github.io/language/)

</comment></comment><comment><USER10> I love the generic function aspect of this, where there aren't necessarily specific inputs or outputs. This will make code reusable by factors. A simple use being not needing to define both `toRadians` and `toDegrees`, just definite the relationship. But I believe this can be taken to the point of getting backpropagation for free once forward propagation is defined in neural networks.

Not to steal any thunder, but I've been prototyping a language very built on this idea.

[https://git.kyleperik.com/kyle/judo](https://git.kyleperik.com/kyle/judo)

<comment><USER11> I could be jumping to an incorrect conclusion, but I think you are misreading the description of Ko's genericity. It doesn't mean that inputs and outputs are not distinguished. It just means that arguments and return values aren't explicitly typed. The kind of Prolog-style unification you are talking about is something different.

<comment><USER10> You're right. This sentence and the general syntax of the language mislead me

> Genericity means that functions do not have to declare argument and return > value types, which makes them highly reusable.

Thanks for being kind about pointing out my massive presupposition

</comment></comment></comment><comment><USER12> Is this a research language? I don't understand how this offers anything beyond what already exists.

I'm also suspicious of the fact that it's implemented in Go. I would think that someone who knew functional programming well enough to create a new language would implement the language in Haskell or OCaml or even Standard ML.

Also the type system looks pretty bad. No algebraic data types.

<comment><USER13> What a bizarre criticism. Most of the newer popular functional languages aren't implemented in those, but rather Java, and for the same reason given in the readme for Go.

<comment><USER14> > Most of the newer popular functional languages aren't implemented in those, > but rather Java

Well, that's not entirely correct. I assume you mean they run on the JVM? Language like scala are actually written IN scala. The only thing that is in java is the interpreter but the entire compiler is scala.

<comment><USER13> True enough for Scala, but Clojure has plenty of Java code.

<comment><USER15> OTOH clojure script is completely written in clojurescript

</comment></comment></comment></comment></comment><comment><USER16> I just want to say that "Ko" is an excellent name for a deadlock-free language written in Go. Kudos.

<comment><USER17> Ha! I didn't even notice, thanks for the hint.

</comment></comment><comment><USER18> Found the examples: [https://github.com/kocircuit/kocircuit/tree/master/lessons/e...](https://github.com/kocircuit/kocircuit/tree/master/lessons/examples)

</comment><comment><USER19> This is interesting. I see it has an interpreter, but it's unclear at a glance whether "interpreted" is the default production mode of the language or if the interpreter is available to facilitate a repl or smething.

Skimming some of the .ko files, I like that it seems readable and familiar (even if there are some oddities). No matter how much time I spend with Haskell and OCaml, I always spend conscious effort trying to mentally parse the source code.

</comment><comment><USER20> This reminds me a lot of a library I wrote called Factfold ([https://github.com/notduncansmith/factfold](https://github.com/notduncansmith/factfold)).

Something I noticed while working on it is that the declarative style is not always the most comfortable way to describe things, and well-written imperative code is declarative in its own way. Somewhere in most useful programs, it helps to have the imperative escape hatch until you can support the best declarative expression.

</comment><comment><USER21> Interesting.

Random observations in no particular order:

\- The simple assignment syntax _looks_ somewhat procedural and is easy to read in small hunks at a time, but is still functional. I like this. This meshes well with the very real limits of how the human brain can parse things.

\- I wish there were type declarations. There's a type system, but it seems to be _all_ inference. Type declarations just at the function inputs and outputs (and leaving it pure inference in the middle) would promote readability when you've got no compiler in hand and are just eyeballing the pure text, in my opinion.

\- I'm surprised by the inclusion of a system of nonlocal returns (panic/recover). It still looks _relatively_ functional, but A) boy that's not an area where the word "relatively" is comfortable to use and B) I shudder to think what the inferred types will tend to explode into when using this feature (an Either of an Either of an Either of a ...?) in a nontrivial program (and the examples don't really shed light on that either, due to the "all inference" model leaving us with no plain text declarations of types in sight).

\- I haven't seen any examples yet of what happens and how you're supposed to resolve it when the type inference can't quite figure it out. There seem to be some examples of doing explicit casts which seems to be a workaround for this, but I don't see it discussed very clearly.

\- The quick and easy syntax for returning new record/structure types seems nice. Though I'm again a tad worried that the range of types I could end up producing would get pretty large.

\- The syntax holistically seems to keep things from "drifting to the right", which seems to be a common readability cramp that emerges in many functional languages. Nice.

\- Using the term "Variety" for roughly "closure" is... very nonobvious to me. But I shouldn't nitpick on terminology. (And for what it's worth, I read the protobuf that Ko uses internally to define its types of types before anything else, and so maybe I'd be less surprised if I had encountered it from from the docs and lessons first.)

Caveat: these are all "hot takes" from the couple dozen minutes of digging I've done so far. I might be reading some things wrong or have missed some documentation, so take these comments with a grain of salt and do your own looking as well.

Overall, this seems neat, but simultaneously leaves me a little worried that I'd be able to too easily write things in which the type inference finds something that compiles, but isn't the type that I would've declared.

I'd be really interested to see what this shapes up like if combined with some system for explicit type declaration. Gluing Ko together with a serial data schema like Protobuf and using Ko for "migrations" seems like it could be a really useful combination, for example.

<comment><USER22> Yes, type declarations are _documentation_ , and tell me about as much, or more, about a function than its name, when reading e.g. Haskell code. They are a necessary usability feature.

</comment></comment><comment><USER23> Would it be possible to have a small hello world example in the README?

</comment><comment><USER24> Couldn't find it easily, but what model are they using to make this dead-lock free as they advertise? I've seen a number of languages try to accomplish this same goal but usually with a huge caveat on what kinds of programs are allowed, or by randomly killing threads when a dead-lock is detected.

<comment><USER25> If you understand why a purely functional language like Haskell rocks at parallelism without worrying about deadlocks, then: same answer here.

I'll agree this isn't ready yet to be the first example of functional parallelism in someone's life, but I'm pretty excited to play with this computational model.

<comment><USER24> Even with Haskell you can still have deadlocks [1]. They give you the tools to write code that you can prove won't have them, but restricting the kinds of programs you can write. But it's an opt-in thing, it's not a promise of the language that you can't do it. Rust is trying to do a similar thing, but it's still also possible to write yourself into a corner with deadlocks if you work against the feature.

Another language I saw recently that has this promise was Pony which uses an actor and message passing model to try to accomplish this but it doesn't actually prevent you from hitting the case, instead it'll just kill a random actor until the deadlock is gone [2]. This can work but it needs to be up front that you MUST write your software to be ready to be killed at any time and continue to function.

It's really an impossible situation to completely "solve", given that doing so would require a solution to the halting problem. So it's always a fun place for me to start looking at any new language if they talk about locks and dead- locks. So far I think Haskell and Rust (and probably other ML family) have the best balance being struck since you can opt in to statically proving this if you restrict those parts of your program but you're not required to do so by the language itself.

[1] [https://www.fpcomplete.com/blog/2018/05/pinpointing- deadlock...](https://www.fpcomplete.com/blog/2018/05/pinpointing-deadlocks-in- haskell) [2] [https://news.ycombinator.com/item?id=9485333](https://news.ycombinator.com/item?id=9485333)

</comment></comment></comment><comment><USER26> Hot takes, as someone else says:

[https://github.com/kocircuit/kocircuit/blob/master/lessons/1...](https://github.com/kocircuit/kocircuit/blob/master/lessons/1-basics/1-files- packages-imports.md) : You might want to consider using Go syntax whenever it is not a problem. 'import "package" as foo' rather than 'import foo "package"' is just pointless change, unless there's more to the "as" statement later.

[https://github.com/kocircuit/kocircuit/blob/master/lessons/1...](https://github.com/kocircuit/kocircuit/blob/master/lessons/1-basics/3-arguments.md) : Whoa, I have to type the name of all the arguments I want to use to every function on every invocation? That's a level of noise I'm not interested in. In [https://github.com/kocircuit/kocircuit/blob/master/lessons/1...](https://github.com/kocircuit/kocircuit/blob/master/lessons/1-basics/4-default- arguments.md) it is claimed this is necessary to support default arguments, but see Python's function argument invocations. (And be sure you see _all_ of it; for instance, it is little known that you can:

        >>> def f(x):
        ...     return x * 2
        ...
        >>> f(x = 2)
        4

that is, even a positional parameter can be passed by name if you insist.)

Coming back after reading on, I see you let Eq and Sum and such get by without argument names. Generally a language should not reserve privileges for itself that it does not grant to its users without a really good reason.

[https://github.com/kocircuit/kocircuit/blob/master/lessons/1...](https://github.com/kocircuit/kocircuit/blob/master/lessons/1-basics/4-default- arguments.md) : I literally have no idea how you are using the word "monadic" in this section; it is neither the proper mathematical term, nor the very close Haskell term, nor any subsequent misunderstanding I've ever seen of the Haskell term ported into other languages, nor can I particularly connect it to the philosophical meaning, nor do I (glancing ahead) see any other documentation for it. My search was not exhaustive, but taking such liberties with a term like that sets off a lot of flags for me.

[https://github.com/kocircuit/kocircuit/blob/master/lessons/1...](https://github.com/kocircuit/kocircuit/blob/master/lessons/1-basics/5-intermediate- steps.md) : This is, IMHO, a rather dirty hack around trying to copy the way pure Haskell code can implement definitions without much concern for order, while at the same time having side effects in the code. That "DoubleGreeting" on the bottom is getting really ugly (and I mean in terms of the semantics of what is being represented there, not the surface syntax layer), and it's still in the sample code, where things should be looking artifically fake-pretty because the real-world hasn't intruded yet. It's a solution to a problem that shouldn't have been introduced in the first place.

[https://github.com/kocircuit/kocircuit/blob/master/lessons/3...](https://github.com/kocircuit/kocircuit/blob/master/lessons/3-types- and-values/6-structures.md) : I expect "repeated assignment" will be difficult to follow with nested structures. Also, what happens if I move yearOfBirth below the repeated "occupations"? My point here is not that there isn't an answer; it's that I can come up with 3 or 4, which is the real problem.

[https://github.com/kocircuit/kocircuit/blob/master/lessons/3...](https://github.com/kocircuit/kocircuit/blob/master/lessons/3-types- and-values/7-varieties.md) : Variety is a bad name for this concept. It's too close to the well-defined "variant" term and causes serious concept clash in my head. "Function object" or something, maybe. "Closure" might work, haven't studied it closely enough to be sure.

[https://github.com/kocircuit/kocircuit/blob/master/lessons/3...](https://github.com/kocircuit/kocircuit/blob/master/lessons/3-types- and-values/7-varieties.md) : This appears to mean that the "null" value is forced into all types, which makes this, surprisingly, even worse than Go itself on this front, which at least has a few types of values that can't be null.

[https://github.com/kocircuit/kocircuit/blob/master/lessons/3...](https://github.com/kocircuit/kocircuit/blob/master/lessons/3-types- and-values/9-equality-and-hashing.md) : At scale, you can't provide a generic hashing function. It's appealing, but it really can't be done. At best you can provide an interface. Don't even provide a default implementation. Java has had a long history of problems with that.

General comment: Using the functions for flow control is OK, but combining that with arbitrarily-reorderable function argument parameters is crazy. Anyone who writes If(else: ..., when: ..., then: ...) is just insane anyhow, so don't even allow it in the syntax/grammar, because it _will_ happen. It seems to me you basically have an imperative language trying to look functional, while I see little to nothing "functional" about it, and you'd be better off just being an imperative language and take advantage of structured programming's implicit control flow <-> source code layout correspondence. You're paying the price for some things you're not successfully taking advantage of.

[https://github.com/kocircuit/kocircuit/blob/master/lessons/5...](https://github.com/kocircuit/kocircuit/blob/master/lessons/5-debugging- and-logging/1-logging-with-show.md) : Re: arg0, arg1, arg2, etc., another solution to a problem that should simply have not been introduced.

My summation is that even in the examples, I'm seeing a lot of little quibbles stack up and become some big problems, and that's before I'm trying to actually code in this. I'd suggest some more thinking about the language's goals, and ensuring that every feature is in harmony with that goal and everything not necessary for it has been cut, because that is not where this language is right now.

</comment><comment><USER27> What's the main advantage of Ko over Go and Pony[1]? I never coded in any of them, but looks interesting.

[1] [https://www.ponylang.io/discover/](https://www.ponylang.io/discover/)

</comment><comment><USER28> Is this like Haxe?

</comment><comment><USER29> .ko is already used for kernel objects :(

<comment><USER30> Many file extensions are in multiple use. There's only so many two or three letter permutations.

<comment><USER31> File extensions aren't limited to 3 characters these days.

</comment></comment></comment><comment><USER32> Y.A.U.L.

</comment><comment><USER33> "Active development" but the last commit was two months ago...</comment>


IPhone vs. Android Re-sale Values - <AUTHOR> http://danielmiessler.com/blog/another-data-point-in-the-iphone-vs-android-debate-re-sale-values

<comment><USER2> Market forces. This just proves people are more willing to pay of an iPhone for whatever reason, compared to a Droid phone. Arguing the reason is X (quality or it being the better phone) is pretty useless based on this data.

</comment><comment><USER3> Thanks for the research! I'll be looking into the used Android market very seriously.</comment>