A german example (from http://de.wikipedia.org/wiki/Hapax_legomenon) is "Knabenmorgenblütenträume" from Goethe's "Prometheus". It is a wonderful example for how you can create new words in German by concatenating existing words:
The literal translation of this word is somthing like "A boy's morning dreams about blossoms", but the true meaning (according to some internet discussions: http://www.gutefrage.net/frage/was-sind-knabenmorgenbluetent... ) seems to be something unfinished: Every part of the word depicts something unfinished / young.
It seems to work much better in german, when they are joined and feel much more like a new word.
As for English allowing the same thing though with spaces, isn't concatenating words to join their meaning a feature of pretty much every language?
> isn't concatenating words to join their meaning a feature of pretty much every language?
No, and that's the point.
The fact that the grammar of the language allows strings of nouns to form compound nouns (e.g. a "River Steamboat Captain" feels natural to me) is unique and interesting, and shared by English. In Spanish, for example, you'd need prepositions/conjunctions to express that concept.
The fact that if you were to write this down, you'd leave out the spaces, is just a weird quirk of the written system, and independent of the language itself.
My favorite example of English's willingness to do noun-noun compounding and Spanish's corresponding unwillingness is on the Boston subway:
Passenger emergency intercom unit at end of car
Sistema de intercomunicación para pasajeros en caso de emergencia situado al extremo del tren
There are several things going on there that make the Spanish longer than the English, but one is the obligatory use of explicit prepositions relating the nouns to one another in Spanish. In English terms, the Spanish says
System of intercommunication for passengers in case of emergency situated at the end of the train
See also this list written up by John Cowan of some languages that do noun-noun compounding and what the implicit meanings of such compounds can be:
Well, the foreman Uncle Bob describes in his posts is the only person on the team with commit rights. He would review every commit (except those from team members he really trusts) and reject all commits that are not up to the standard.
In my opinion, this kind of foreman he wants to have would lead automatically to the dysfunctions I describe in my post - at least in some teams. And I think the risk is not worth it.
Come on, you spent $5 for an app. For a working app! This is a pretty low price. Actually, it's basically nothing. Of course you can't get support and are not entitled to feature requests at such a low price tag!
$5 is not cheap by app store standards. It's a fair price for an app in that class.
As to whether you're entitled to support or feature requests, you can make an argument both ways. One could generate some word of mouth by following up on (simple) feature requests.
In one of the apps, Fourier, the reviewers say that the horizontal frequency scale is off by a factor of 2 (but the frequency display elsewhere is accurate). That's a small thing to fix that hasn't been fixed since Apr 2012. I think that at a $5 price point, my expectation is that the app is updated with at least bug fixes of that variety.
"App Store standards" don't really work for valuable niche software. They can work for games that end up selling 10 million copies, but there's a reason why professional software with few users is usually priced between $500 and $100 000.
$5 is worth 3 minutes of developer time at common hourly contracting prices. If a developer receives and reads an email from a customer, they will probably end up with no profit. If they respond to it, let alone are adding new custom features, they are certainly losing money compared to working for someone else.
First, wow, I didn't expect any HN readers to actually know about, much less have bought, my work! Thanks.
Second, I understand your frustration. I love building things, and sometimes I wish I could do that full time, but grad school is a 70 hr/wk commitment for me.
If the app is not useful for you without the missing feature, Apple does allow returns. I'm not quite sure how it works, but I see a few returns a year on my reports.
Also, I've open-sourced the hardest part of the app, the audio managing aspect, as Novocaine (GitHub.com/alexbw/novocaine), and along with the great package NVDSP, anybody could replicate the basic functionality of my apps with a few weeks of learning and effort. It'd be great for the audio app ecosystem, too!
I'm also interested in hiring a part-time developer to help flesh out the top-requested features, if anybody has ObjC coding experience. That'd make many more updates possible.
I've used novocaine on a hackathon project. Very fun little library, thanks! It was 10,000 times easier than setting up the audio unit chain, etc. I had done it the old fashioned way for my first app but there was an incredible amount of error-prone boilerplate code when all I really wanted was a callback function to populate output buffers.
I like the overall design of the app, but I don't think the stock images fit well in there. It's just generic people, nothing I can relate to your app.
A little bit more text to explain what your product does would have helped me. I had to watch half of the video to really get it. I still don't know how your product is better than traditional monitoring, though. Unfortunately the tour does not really help me here (but I am a devops-noob): For example, what does this mean: "Snooze tries to fill the gap between cron mailing you and setting up and Icinga stack to monitor all the scheduled tasks in your network." I had to google "Icinga" to even understand what you mean. And the scenario you use before is very technical - Might be hard to read for a non-programmer.
If you did not know it yet, have a look at this post (and the linked info graphic): http://copyhackers.com/2013/04/long-copy/ - I would take this route for adding more text to the home page, if I were you.
Don't get me wrong, overall I like what you did here. I think this product would be useful for me if I ran a SAAS application. But you have not totally convinced me yet...
Yes, the stock photos are a really minor issue. But, if you can draw a little diagram that explains your service on a white board, I would prefer that to the lady who has nothing to do with your startup...
There is some truth in this article, but it also seems a little bit simplistic and/or watered down. It's not really about who owns the biggest computer, it's much more than that. Just access to processing power would not have made facebook and google big, so why should it work in the future?
Also, automation has been replacing traditional jobs for almost 200 years now, and we are mostly better off now then we were then. After some rough time always learned to profit from automation as a society. Maybe, as automation accelerates, the rough time won't stop anymore - like eternal september - but my bet is that we learn to cope with that too...
A very nice article, although I do not agree with everything in there. I guess you just can not be successful just by copying what others did. Especially not when you do not understand why you should do it or how it contributed to their success.
Somewhat offtopic: I do not work in the startup scene, but I have experience something similar a couple of times when traditional companies try to do agile. They see something that works very well for somebody, bring in a consultant (hopefully!) and start doing everything she says. Without really understanding it. But it's just rituals then, and the rituals alone don't work. That's called "cargo cult" or "scrum but" sometimes, though I have my problems with those words too (http://davidtanzer.net/scrum_but)...