Hacker Newsnew | comments | show | ask | jobs | submit | login

To be fair: That is actually #1 in the list.

-----


It's a commercial project, so yes, people are willing to pay to see it. They had more than a million visitors in 2009 [1].

[1] http://de.wikipedia.org/wiki/Miniatur_Wunderland (German language link)

-----


"Man builds" is not quite correct. The airport is part of the largest model railway in the world [1]. The thing is build by a rather large team with ten years worth of experience in building high-end models.

If you ever come to northern Germany, I absolutely recommend a visit!

[1] http://en.wikipedia.org/wiki/Miniatur_Wunderland

-----


Also check there Youtube channel. Here a nice movie explaining the takeoff/landing system: http://www.youtube.com/user/MiWuLaTV#p/a/5F525544A3296EEB/0/... (in German)

edit Wow, I did not realize the airplanes are not connected to the system. They can all run "free".

-----


Well... It was certainly built by man ;-)

-----


[deleted]

I might be in the minority, but I don't think that's a good reason to be misleading.

-----


It was an honest mistake. I did not realize that a team was involved in the building. I've seen stories about single guys building a yacht out of popsicle sticks, etc. and thought from the article that this was a single maker too. Sorry if the headline was misleading.

-----


Well, that sort of thing is why the guidelines here say to just copy the title of the page you are linking to unless absolutely neccessary.

-----


I'm thinking that the original title did include "Man Builds..." The URL still does...

http://www.news.com.au/travel/news/man-builds-worlds-largest...

-----


For what it's worth, I was referring to the attempt at a justification by the guy I was replying to. I thought I'd point that out for the record now that his comment has been deleted.

I didn't think you were being misleading.

-----


I think the downvotes (not from me - once a comment goes grey I tend to think the job is done for all but the most abusive comments) relate to the "I submitted this story and got no love" element (or maybe the smiley face).

We've all been there, and it adds nothing of value to the actual article or conversation to know it's a dupe, unless the previous one had a worthwhile discussion as well, in which case link to it.

-----


Haskell (GHC at least) has lightweight user-level threads, similar to Erlang.

-----


Please, please, pretty please: If you use charts, choose a sensible type of chart to illustrate your point.

A pie chart is simply wrong for representing a comparison of benchmark results. A bar chart would be the correct type, in this case.

-----


Agreed.

As if that weren't bad enough, the charts nor the article contain information about what's been tested. Is it the speed? The memory-usage? Something else?

The results themselves are pretty interesting though. Only thing I feel left out is Opera.

-----


Can you talk about the metric(s) by which they measure productivity? I would appreciate it.

-----


We're essentially a large consultancy who bills by the kousuu -- "unit of engineering labor", somewhat arbitrarily defined as "what we think one engineer should be able to do in a day". Projects are successful if we bill more than N * K * the average labor cost of producing one kousuu, where K is the number of kousuu and N is a constant representing overhead, profit, and the cost of sale.

Projects are sized based on a negotiation between us and the customer. It is then broken into parts, which are given their own kousuu value, via guesstimation by a senior engineer on the team. (You'll notice this process involves an awful lot of guesstimation. This tends to converge on reasonable numbers because guesstimation is happening among multiple actors who don't have an incentive to collude -- kinda-sorta like a market of players with imperfect knowledge can converge staggeringly quickly on a good guess of the intrinsic value of something.)

We then measure how many kousuu of work you complete for a particular project per day you report you are working on the project. That is currently our primary productivity measure, although we also track customer satisfaction, "claims" (a backchannel by which customers here get free work done to fix issues in the deliverable which are determined to be due to our mistakes), subjective quality assessments from the engineers, follow-on business from the same customer, and any value we can extract from the project for the company. (For example, in a 10 kousuu project if we manage to extract 2 kousuu worth of functionality that the customer paid for into our internal framework, then deploy that to seven customers and charge them each for it, we make out like bandits.)

Anyhow, we keep obsessive records of who does what and how long it took, so figuring out productivity is "just" a matter of dividing. (We only figured out the dividing trick recently. Hard to move a large organization from the way it typically does things, you know?)

-----


I think Clojure is not a simple language. The reason is, that you have to learn about 1) Lisp, 2) Clojure's approach to concurrency (immutable data structures + reference types) and 3) the JVM. These are all fairly complex systems on their own. The combination of them is what makes Clojure interesting, and, in my opinion, you can't leave one out and still have a great language.

Depending on your knowledge, this may make it a bad choice as a first language because it's so much to learn at once. You could be better off, to start by learning something more similar to what you already know (possibly Python/Django or Ruby/Rails for web programming).

That said, Clojure is learnable, of course. It may just take more time. If it feels right to you, then go for it. Enthusiasm about the tools will help your learning. And either way, it's not like you are making a mistake.

-----


Clojure's beauty is in that it _is_ simple. It's also a language where it's completely unnecessary to have to understand all the parts at once. I coded in it for 6 months and never used a single concurrency primitive.

That said, JVM stuff does present a challenge but not more than the various non-sensical annoyances I've experience with every programming language. Two other real difficulties is lazy-sequences and less than ideal error-reporting.

lazy-sequences is like learning pointers- tough and then you get it. error-reporting is a symptom of early days. This issue is offset somewhat by Clojure's FP sensibilities.

-----


Lazy-sequences may also help to prepare you for a completely lazy language.

-----


Thanks for your response. :)

Quick question: regarding learning about the JVM, are you aware of any good resources, especially any which look at it from a Clojure perspective?

-----


1) Lisp isn't exactly a complicated pattern to match (syntax is much more simple/readable than say, Java/Ruby). If you do a lot of macros there are difficult things involved, but then again, macros are an entire level of power greater than Ruby/Python.

2) You don't have to use the concurrency stuff if you are just learning programming. The whole point of STM is that it takes care of the concurrency and transactions for the programmer. This is like saying garbage collection is more difficult than hand allocating memory because the system that implements it is more complicated.

3) Huh? I mean, if you want to use Java libraries you have to learn a bit of the java idiom (.... camelCase), as well as the library that you want to use, but there is no demand that you become intimately acquainted with the JVM any more that you become intimately acquainted with the specific implementation details of python or ruby.

I'm not sure if your post is FUD or genuine ignorance of Clojure (or both).

-----


Could you elaborate, please? Or point me to a discussion of the issues with said functions? Thanks!

-----


If I recall correctly, `getContent` (and therefore `interact`) uses `unsafeInterleaveIO`, the most unsafe function of the whole Haskell library, while not satisfying all the condition it should satisfy.

More practically, `getContent` is evil because it locks the file it is reading for an unbounded amount of time: as long as it's content (the giant string representing the file), isn't either out of scope (and eventually garbage collected) or fully evaluated.

That can be a problem if you intent to open loads of files (you could hit the OS limit) or if you want to modify the file after reading part of it.

Lazy IO is therefore quite embarrassing. Several people are working at hopefully safer alternatives right now.

-----


They work by having input/output happen outside the IO monad. That breaks the abstraction -- which is impossible. You can't implement interact or getContents out of simpler functions, unless you use unsafeSomethingOrOtherIO.

-----


Do you have any references for that? I looked through some Haskell documentation and didn't see anything warning about those functions being unsafe (although there does seem to be an unsafeHGetContents in System.IO.Unsafe).

Is there's something I'm missing that says "hey, this function uses unsafePerformIO behind the scenes" or whatnot? Being not very experienced with Haskell I'm a little worried about library functions being unsafe without me realizing it.

-----


It's just getContents (and brother hGetContents).

Using getContents is fine for a quick way to slurp in a file, but it's like doing a read without checking for -1. Since haskell is lazy, figuring out why an underlying read failed can be fairly confusing.

If you think your program is doing IO and there's no IO type getting in the way, unsafePerformIO is lurking in the darkness.

-----


Well, I was confused because getContents seems to be of type "IO String": http://www.haskell.org/ghc/docs/latest/html/libraries/base/P...

I can see why a lazy input stream could make things opaque even in a completely type-safe program, though.

-----


The behavior of hGetContents is documented at http://www.haskell.org/ghc/docs/latest/html/libraries/base/S... .

If you write

    do h <- openFile "foo.txt" ReadMode
       x <- hGetContents h
       putStr x
you'll get different behavior than if you write

    do h <- openFile "foo.txt" ReadMode
       x <- hGetContents h
       hClose h
       putStr x
In the first example, you'll print out the contents of the file. In the latter, you'll print out nothing.

-----


Priceless! Thank you for making my day.

-----


I hope this will be included in future Shoes versions. Shoes is already awesome for making (portable!) retro-games. This will add another great deal of retro-ness. ;)

-----


He wrote it for Hackety Hack, which will be built on Shoes for its next version. Whether or not it's included in Shoes itself or just HH will remain to be seen, but I'd love to see it in the former.

-----

More

Guidelines | FAQ | Support | API | Lists | Bookmarklet | DMCA | Y Combinator | Apply | Contact

Search: