Julia: A fresh approach to numerical computing - <AUTHOR> http://arxiv.org/abs/1411.1607 <comment><USER3> I've been playing around with the Cxx library (currently only works with a source build of bleeding edge Julia) [https://github.com/Keno/Cxx.jl](https://github.com/Keno/Cxx.jl) It allows you to basically embed ordinary C++ code in Julia code, to interface with C++ libraries at runtime, and to slurp in entire .h files unmodified. (It also in theory allows a C++ REPL mode to be written, though such a thing does not exist for Julia yet.)

It makes very clever use of a really amazing new language feature in Julia 0.4, namely staged functions. At first it looked like it was manipulating C++ via strings sent to the Clang compiler at runtime, which sounded really slow and awful. But then it dawned on me how it really worked, and I was amazed.

I've actually convinced three or four of my colleagues (mathematicians) to work on building a computer algebra system with Julia that will interface to various packages such as Pari/GP, flint, Singular, possibly Gap. We meet weekly to discuss design and to try and work on an initial implementation.

The rate at which Julia is improving and the community is increasing is astonishing. We are at the stage where Julia is offering us language features we haven't even dreamed up a use for! And yet the language remains elegant and easy to learn.

<comment> one-more-minute For reference, a staged function is something sorta similar to a macro, except it lets you take advantage of Julia's inferred type info. Contrived (and wholly redundant) example:

      stagedfunction foo(x)
          if x == Int
              :(2x)
          else
              :x
          end
      end

      y = 1
      foo(y)  == 2
      y = 1.
      foo(y) == 1.0

Again, just like a macro, except that before `x` is quoted you work with the _type_ of y instead of the symbol `y`. This means you can do _even more_ crazy code specialisation, including on e.g. matrix dimensions or generating appropriate FFI calls based on arbitrary input types. It has zero overhead and you can use it just like a regular function.

Very cool, and I think people will do really interesting things with this (especially after mixing them with macros).

<comment><USER4> This sounds very similar to an approach called Lightweight Modular Staging (pioneered in Scala by the Oderski group - [http://scala- lms.github.io/](http://scala-lms.github.io/) and also in Lua - [http://terralang.org/](http://terralang.org/)). While this is great for specializing numeric code based on runtime invariants like dimensionality, I think people are finally looking at using the idea in other domains - <USER2> example, runtime generation of DSL code on a per instantiation basis. Imagine taking a high level SQL query, building the operator tree in a Julia DSL and optimizing that, and then JITing the entire thing taking into account low level storage details and the particular sets of operators and joins ([http://msr-waypoint.com/en-us/events/dcp2014/rompf.pdf](http://msr- waypoint.com/en-us/events/dcp2014/rompf.pdf)). This is very exciting to see in another typed language!

<comment><USER5> You mean like blaze in python?: [http://blaze.pydata.org/docs/v_0_6_5/index.html](http://blaze.pydata.org/docs/v_0_6_5/index.html)

<comment><USER4> Blaze has a bit of a broader focus than what I was talking about, since blaze mostly offloads the actual computation to a particular backend. But a combination of blaze and a custom lowering of the computation into machine code using numba would be similar (although without the type safety for guaranteeing that certain optimizations are possible)

<comment><USER5> I believe that the numba compilation is planned for the coming year.

</comment></comment></comment></comment></comment></comment><comment><USER3> From the article: " A pervasive idea that Julia wishes to shatter is that technical computing languages are "prototyping" languages and one must switch to C or Fortran for performance. The consequences to scientific computing have been more serious than many realize."

I think this provides a very succinct summary of the Julia paradigm at a very high level.

<comment><USER6> I'm trying to push haskell for that too. But the more decent tools and choices, the better for everyone. :-)

</comment></comment><comment><USER7> Despite having a very similar title, this is a rather different paper from [http://arxiv.org/abs/1209.5145](http://arxiv.org/abs/1209.5145). We had to upload a version of this paper for a grant application, but it's still somewhat in progress.

<comment><USER8> That's right. The purpose was to have twin papers - one for the Computer Science community focussed on language implementation, which is the earlier paper.

This paper focusses on motivating the design of Julia for the larger scientific community. Any comments will be incredibly valuable in improving the quality of the paper.

<comment><USER9> It's great to have a paper like this on the arXiv, I believe this is the right way to reach the scientific community.

Some ideas for improvements:

The package directory could be mentioned more prominently.

It's a bit tricky to select code in the PDF, not sure if much can be done about this?

<comment><USER8> I guess we can publish the IJulia notebooks with the examples and even just the code as plain .jl files.

</comment></comment></comment></comment><comment><USER10> What I would like to know before jumping in a new programming language is what it sucks at and how badly it sucks there.

Never in my life have I ever heard anyone say anything good about how wonderful it is language X is good at y which is what it was designed for. I have however heard plenty of people cursing languages for not doing something which they thought was an "obvious" thing for a language to do and X didn't.

<comment><USER3> This very much depends on what you want to do with it and what your background is. Here are some things that might bother you.

* Julia's approach to OOP is via multimethods, not the usual class/inheritance model. This might be annoying for people who don't want to learn how to be an effective programmer in the other paradigm.

* Julia's garbage collector is not generational/incremental and in some corner cases, GC can take 10 times longer than the actual function you are running (typically it is between 5% and 50%). This would make Julia unsuitable for HFT, real-time games, web browsers of the future and other real-time applications. (Edit: see Viral's post in the same thread. Incremental GC is in the works. This is genuinely my experience of Julia to date. No sooner do you need something, and someone competent is already working on it, if they haven't already done it!)

* Julia sucks at predicate dispatch. It doesn't have it. Granted, neither does any other language except Gap and one other I forgot. So if you are used to that feature, you would find Julia a step down. (Edit: yes of course Julia does not need/want predicate dispatch. It's just an illustration of something that could bother you if you were really, really used to something. I just happen to have colleagues who really are used to this.)

* Julia is tied to LLVM, so if you want to be on the CLR/DLR or JVM, you are out of luck.

* Julia currently doesn't have static compilation (I hear it is being actively worked on). This makes it more difficult to deploy binaries.

* Julia does not have Haskell-like separation of effects from pure functions. This might not appeal to type purists.

* Julia functions can fail at runtime where statically typed/compiled languages would pick up the errors at compile time.

* As popular as it is, Julia is still not in the top 50 programming languages by measure of usership.

* Julia's support of mutable C-style structs allocated on the stack, as opposed to pointers to heap allocated objects is still somewhat lacking. This creates some challenges in efficient C FFI in corner cases, especially in combination with GC.

* Julia doesn't have inheritance of data types (it is really a dual to a data focused language, which is sensible -- you typically have far more functions than data types in a program -- but it's still hard for traditional OOP users to get used to).

* The Julia abstract type system is somewhat linear, which makes it a little less flexible as far as contracts/interfaces are concerned, if you choose to implement things that way.

Of course Julia has so many features that make it worthwhile, that it is worth investigating for many projects. It has multimethods, (static) dependent typing, very easy and efficient C interface (soon C++ interface), C-like performance is possible, garbage-collection, macros, runtime console (REPL), great numerical features, Jit compilation, a good selection of libraries/packages, a package manager, profiling, various development tools, a good (highly intelligent and helpful) community.

<comment><USER11> * lack of threads: they do support multiple processes which can be useful for splitting up work for large computation, but not a substitute for threads

* module compilation is not cached, so if you use very many modules your start-up times can be slow

* error messages sometimes require some head scratching. For example, it's not uncommon to get an error that there's no available function convert(::SomeType, (Some, Args)) when there's no obvious convert() to be seen in the code in question. Occasionally the stack trace will be missing from errors, or there won't be a line number. Obviously this is improving quickly, but can be frustrating.

<comment><USER12> The first two are both WIP. Threading is [https://github.com/JuliaLang/julia/tree/threads](https://github.com/JuliaLang/julia/tree/threads) (although it hasn't been updated in a little while) and static compilation of modules is [https://github.com/JuliaLang/julia/pull/8745](https://github.com/JuliaLang/julia/pull/8745)

<comment><USER11> That's great to see. It's sometimes hard to keep up with everything that's going on. Incidentally I really got a kick out of the recent s/Uint/UInt/ rename ([https://github.com/JuliaLang/julia/issues/8905](https://github.com/JuliaLang/julia/issues/8905)). It took a day or so to propose and do it. To compare, java will probably never fix it's spelling oddities (for example int and Integer). Very refreshing to see fundamental things like that be fixed and so quickly!

<comment><USER7> Just to play devil's advocate about the Java capitalization, I suspect the difference between `int` and `Integer` is quite intentional: `int` is a "primitive", immutable value type, while `Integer` is a class. Since by convention, Java's classes are capitalized, while its primitives are spelled the way they are in C, there's some sense here.

</comment></comment></comment></comment></comment></comment><comment><USER13> For anyone in the Chicago area, Leah Hanson is giving a free Julia workshop next weekend (11/15):

[http://www.meetup.com/JuliaChicago/events/216950712/](http://www.meetup.com/JuliaChicago/events/216950712/)

Should be a great way to get introduced to the language and pose your nagging questions to a community expert.

<comment><USER14> Her blog is also a great resource to pick up some of the more useful parts of the language.

<comment><USER7> Not to mention her forthcoming O'Reilly book, "Learning Julia"!

</comment></comment></comment><comment><USER15> Yes, this paper, as the title suggests, was written perhaps for the community as a whole, but perhaps in particular for the numerical computing community. Most especially, there are many ideas in this paper that are entirely unfamiliar to that community, and this paper hopes to change that. Hope you enjoy the reading. (We probably will make some updates. The spelling fix of the title was already processed yesterday and will appear tomorrow or Monday.)

</comment><comment><USER16> I am a little weary of the hype around a language whose unique selling point is speed. Where else in Julia is there significant innovation versus Python? The latter seriously has it all when it comes to scientific computing, and if anybody is not already running vectorized numpy code, or trivially compiling critical for loops to c-like speed using Numba/Cython, then they're missing out on performance which has nothing to be ashamed of versus any of the newer kids on the block.

I have been weary of the Julia pitch which was basically "lets brew R, Python, and Matlab (all >20 years old with massive and unrivalled ecosystems and all serving their purposes very well, thank you) into one "new" language and put a nice logo on it". How is this language seriously the leap forward that one needs to abandon the current awesome toolsets, with all their battle tested libraries, other than a nebulous "speed" argument which in many cases, judging by the comments and my own experience in financial data matrix operations, is not even fully accurate? Ready to be persuaded otherwise if I can be shown that other than "speed" there are hefty reasons to move from Python and abandon the almost endless choice of richly varied tools that I have at my disposal already.

<comment> one-more-minute You should read the paper, but Julia's also a really nicely designed language in general. It's hard to communicate how great multiple dispatch + a powerful type system is without trying it out (though, again, the paper does a good job), but yeah, it really helps you get a lot of generality as well as performance. When you use Cython, you immediately lose that generality.

Then there's the really powerful metaprogramming capabilities, which are absent from the languages you've mentioned. I can't emphasise it enough: the paper this comment thread is about does a great job of explaining why these things are compelling.

Also, you may be interested in [1], an argument that language performance is valuable even if you don't need it yourself.

[1]: [https://medium.com/the-julia-language/performance-matters- mo...](https://medium.com/the-julia-language/performance-matters-more-than- you-think-a556e6cdcd10)

<comment><USER16> Compelling argument in your link about how performance for others allows for better libraries for everyone. I am still concerned that Julia does not go far enough in breaking the imperative programming mould, but I think it's disingenuous not to give it a serious try in more than trivial exercises. I have to say though that I have learned R, Python and Golang in the past 8 years and all of them are basically imperative (though R's vectorisation- everywhere is impressive - wish it was all just faster); I hope Julia will give me something dramatically more interesting. I say that because the LLVM has ushered in a period of radically easier language development, so we are likely to be spoiled for choice in the next 5 years. I hope Julia has done enough to put itself way out there in in terms of innovation to make the sizeable investment of time for myself and library developers, worthwhile. Altogether however I cannot be anything other than impressed with the dogged and convincing pitch that you and others are making for it, which somewhat lowers the risk of investing time in a dead end. And even if it doesn't work out all hunky, at least I'll know that Python will face serious competition, and that can only be good, even for Python.

<comment><USER5> How does the upcoming and even current numba+blaze power duo not allow library designers to easily write fast code?

<comment><USER16> Well that was the point of my original message. I am using numbapro and easily getting to c-speed with R-like vectorized convenience right now. It's why I question the "speed" argument as a non-argument when compared with Python. And I haven't even started using the cuda approach... You allude to another point though: Python is not standing still. Python and its environment is a mighty high mountain for Julia to climb if it's not going to move the game forward significantly so that its big ecosystem disadvantage is compensated. Julia cannot just do incremental improvement - it doesn't have enough momentum to make that a winning strategy. It needs to leapfrog to take on Python.

I should add one more point though. The post mentions Matlab 15 times and Python only 7. It's possible this whole Julia effort will be successful with the Matlab crowd which, up to now, has been watching with horrified fascination from the sidelines as open source ate its lunch.

<comment><USER5> Nice. Do you find yourself having to contort code to work with numbapro?

</comment></comment></comment></comment></comment></comment><comment><USER17> I've been using Julia for a few months and I love it! Being able to process arrays in a function as if it was a single variable is super awesome, and as a result my code uses far fewer for/while loops.

</comment><comment><USER18> Am I the only person not seeing the promised performance with Julia? As a concrete example I recently ported some non-trivial legacy matlab code I use at work to both python/numpy and Julia. The port was basically a straight port of matlab code making only the necessary syntax changes to make the code run. And much to my surprise Julia run twice as slow as Octave and 4 times as slow as python. Adding type annotations helped but I never got closer than 50% slower than Octave. In earlier test I've seen cases where Julia was literally 12 times slower than python/numexpr in real world code.

I really want to love Julia and everything I read about it makes me think it's the language for me, but every time I try to write non-toy code the performance is always worse than python.

<comment><USER19> > The port was basically a straight port of matlab code making only the > necessary syntax changes to make the code run.

Then it is not surprising at all that you do not get any speed benefit. I would expect a serious slowdown.

Idiomatic MATLAB and Numpy has lots of vectorized expressions because they are so crappy at loops. However, in vanilla Julia those vectorized expressions cannot be JIT'ed. Now if you were to write them out as explicit loops then JIT will take a stab at making things faster.

I do like the economy of words of vectorized expressions a whole lot, this is the reason why I am so excited about [https://github.com/lindahua/Devectorize.jl](https://github.com/lindahua/Devectorize.jl)

<comment><USER8> On vectorized code we are on par usually, but sometimes GC performance hurts. There is a patch for this in the works. Could you post the code snippets to julia-users mailing list?

</comment></comment></comment><comment><USER20> The biggest challenge I'm facing now is how to convince those around me to take the leap and step over to Julia. We have a wealth of legacy code in MATLAB, C++ and Fortran. I've seen the various methods to call these codes from Julia, but in the case of C++, it seems that only rudimentary support is provided.

My goal is to port a lot of my code to set up astrodynamics simulations. I've even created a placeholder Github repo for it [1]. Just have to find the right strategy to involve the dev in my existing projects and get my colleagues to chip in.

[1] [https://github.com/kartikkumar/Astro.jl](https://github.com/kartikkumar/Astro.jl)

</comment><comment><USER21> Nice paper guys. Any plan to get something peer-reviewed? It would be useful for motivating biologists.

Anyone interested in using Julia for bioinformatics is invited to contribute to, or follow the progress of, the BioJulia project: [https://github.com/BioJulia/Bio.jl](https://github.com/BioJulia/Bio.jl)

<comment><USER8> Yes, we do want to submit it to a SIAM journal. It does seem that we are already getting interesting feedback here. The BioJulia team will probably write a paper on Julia in Biology and publish in a related journal, just like Miles Lubin and Iain are doing with JuMP in the OR community.

<comment><USER21> Yup, we'll definitely do one for BioJulia - but we've got a way to go before we reach that stage :)

</comment></comment></comment><comment><USER22> Are there any mature visualization libraries for Julia yet? I'm pretty excited about this language, but I couldn't find any visualization tools that had good documentation.

<comment><USER7> Gadfly is an excellent ggplot2-style plotting package:

[http://gadflyjl.org](http://gadflyjl.org)

Winston is a most traditional plotting API:

[http://winston.readthedocs.org/en/latest/examples.html](http://winston.readthedocs.org/en/latest/examples.html)

You can also plot seamlessly via Python using PyPlot:

[https://github.com/stevengj/PyPlot.jl](https://github.com/stevengj/PyPlot.jl)

They are all quite well documented.

<comment><USER23> Still working my way through them myself. Useful examples working through docs would be useful. Most seem to presume a lot of knowledge of the libraries.

<comment><USER8> You are right - package documentation has some ways to go. Currently we don't yet have a mechanism to do `help()` on a package function, but we expect that to change in 0.4.

<comment><USER23> Would love to help in some way.

</comment></comment></comment></comment></comment><comment><USER24> The one based indexing pretty much kills the entire thing for me.

<comment><USER25> Then you are missing out on a wonderful programming tool for a very superficial reason. I wish indices were offsets like C and not indexes like Lua, but I'll deal with it for all the language gives.

</comment></comment><comment><USER26> anyone know where I can get a juliabox.org invite code?

<comment><USER8> Shoot me an email - firstname.lastname@example.com

<comment><USER20> Mind if I shoot you an email too for an invite?

<comment><USER8> Yes - happy to share codes with anyone. Also, we will be simplifying the invite system in the next few days so that JuliaBox will let you in without any code by default.

In the rare cases of a surge, such as an HN mention, it will auto-release account approvals as the surge subsides in a few hours. Once you do have access, you will continue to have access, even during surges. Basically, we are just trying to manage our compute budget better.

</comment></comment></comment></comment><comment><USER27> is it just me or is arxiv.org down? HN effect?

<comment><USER27> for anyone experiencing issues with arxiv.org, mirror: [http://uk.arxiv.org/abs/1411.1607](http://uk.arxiv.org/abs/1411.1607)</comment></comment>


Ask HN: What are things a programmer should do at least once? - <AUTHOR> Share things which any programmer ought to do at least once in the course of their career.<p>For e.g read book X or build Y from scratch, but also anything else that was very worthwhile / satisfying or like a rite of passage. <comment><USER2> Here's a list (I've thought about this often):

1\. Use your application. (Not the same as testing.)

2\. Adopt an apprentice programmer, teach them your seat, pass on the seat. Leave the seat.

3\. Program something for fun that is your own idea.

4\. Program something for someone else that is their idea.

5\. Sort the books/library.

6\. No books/library? Build books/library.

7\. Re-write the code from scratch, for the hell of it.

8\. Take over someone elses' project, finish it to the end users satisfaction.

9\. Give your project to someone else, in a state that they can do #8 easily.

10\. Build a list of positive observations over a period of X, where X is how long you think it might be fun to do so.

The accomplishment of a number of these actions have, in my opinion, resulted in some really great programmers and some really great software.

</comment><comment><USER3> Write a compiler. It gives you great insights into parsing/tokenizing, building syntax trees, implementing syntax and Symantec checks and code generation. Obviously, you would have to pick a toy language (typically a subset of a known programming language) and your generated code will be inefficient. Still, you would learn a lot.

<comment><USER4> I'd add writing compiler optimizations as well. Common subexpression elimination, dead code-elimination, copy propagation, register allocation to name a few.

</comment></comment><comment><USER5> The old chestnut, but valid: Learn, and get comfortable in, a functional language. The typical case being Lisp (often in conjunction with a readthrough of SICP), but if you have the stomach for it, Haskell (or languages of its lineage- ML, perhaps OCaml or Scala) offers the same functional "enlightenment", and the mysteries of strong type systems besides.

<comment><USER6> Rich Hickey's talks are top-notch and a great introduction to the pillars of functional programming.

One thing notably absent from those talks (and Clojure itself) is the power of a good type system. I think Elm is a good introduction to that, as well as a solid FP language with good docs and a helpful compiler, and putting the "transformation over stream of inputs" at the forefront of your program design. Looking into other FRP talks (specifically I think Netflix has one or more good ones) is a good idea as well.

</comment></comment><comment><USER7> Parse natural language (e.g. English) toward understanding it and responding. You will learn a great deal about ambiguity, the tradeoff between elegance/verbosity and the basics of information (sufficiency, necessity, ambiguity and excess). You'll also better appreciate the language itself, its basic patterns and the value and limits of grammar.

This will reveal the inevitability of verbal interfaces in computing devices (esp. mobile) and the difficulties therein.

It's then worth extending the effort another step, to introduce yourself to the statistical and numerical techniques used by natural language processing pros to keep up with the explosion in language in modern media: personal, social, and mass.

</comment><comment><USER8> Write a program with another peogrammer. Do it as many times as possible with as many people. Software is built in the mind. Understand other minds and you will understand software better.

</comment><comment><USER9> Read "Database Design for Mere Mortals".

Its one of the few books I keep buying and giving away.

</comment><comment><USER10> Ask why and understand the reasons for a feature so well that when you explain it back to the business user requesting it, they nod, say "exactly" and their eyes sparkle.

Then change how the feature works, or eliminate it, or address the business reasons using a completely different implementation and sell it to the same person in a way that has them enthusiastically agree and sign off on it.

</comment><comment><USER11> Manage a team.

Wasn't my cup of tea but at least I know what it is like on the dark side.

Only danger is after doing it for a year it was harder to ace the technical questions at interviews.

</comment><comment><USER12> Go to college parties.

<comment><USER13> Too late if you're out of college I'm afraid.

<comment><USER14> Not true, I've been to a couple of conference parties that were pretty much college parties with an average age of 30 instead of 20.

</comment></comment></comment><comment><USER15> Rewrite the same program at least five times, trying each time to improve it. You can use different languages.

</comment><comment><USER16> Supporting and extending other peoples code, however old the code is. Greenfield projects with new libraries and frameworks get all the limelight, yet you will learn a lot more by developing and supporting existing software in an organisation.</comment>


GRPC-Web: JavaScript client library that enables browser clients to access a gRPC server - <AUTHOR> https://github.com/grpc/grpc-web <comment><USER2> The link leads to 404, at least for me.

<comment><AUTHOR> Hello,

It is a private repository because it is still in beta.

You need to request an access through this form:

[https://goo.gl/G2bBZQ](https://goo.gl/G2bBZQ)

Très cordialement / Best Regards,

<comment><USER3> Then why post it here?

What does this repo do? Why would anyone want to request access with a description of what it is?</comment></comment></comment>


NL social network Hyves sold to media group, as EU networks feel the FB heat - <AUTHOR> http://eu.techcrunch.com/2010/11/01/dutch-social-network-hyves-sold-to-media-group-as-european-based-feel-the-facebook-heat/ <comment><USER2> Kind of inevitable I guess. The problem Hyves has is that there just isn't a compelling enough reason for most people to update Hyves after you've done everything you want to do on Facebook .. and these days there are VERY few people who are on Hyves and NOT on Facebook .. it was just duplication of effort.</comment>


Next Jump Acquires FlightCaster, The Flight Delay Prediction Engine - <AUTHOR> http://techcrunch.com/2011/01/10/next-jump-acquires-flightcaster-the-flight-delay-prediction-engine/ <comment><USER2> Congratulations!

How much? ;)

</comment><comment><USER3> Who cares if it was acquired if the price isn't disclosed. Congrats anyway</comment>


Show HN: IP-Api.io – Geolocation by IP - <AUTHOR> https://ip-api.io <comment><USER2> The pricing is a bit confusing:

€10/m for 100k queries €45/m for 300k queries

Can I just make 3 accounts and save €15/m?

<comment><USER3> Agreed, €25/m makes much more sense for that tier than 45. And to be honest why even have 3 tiers if for an additional 8% on the second tier you get 3.33x more anyways?

</comment></comment><comment><USER4> This looks really nice and the landing page is great. I love that they have code demos right there.

I currently use and love [https://ipdata.co/](https://ipdata.co/) which is very similar in terms of features and pricing so I see no compelling reason to move, but it's great to see more entrants into this space especially if it causes more innovation and data types to be added.

<comment><USER5> I just tried to get an API key at ipdata.co, but their onboarding could use some work: I registered, got some error, but still a verification email came. Clicked on the link, but now can't find a way to continue - either login or get a key some other way.

EDIT: nevermind, they send it through email..

</comment></comment><comment><USER6> If you're looking for an IP geolocation API you should also check us out at [https://ipinfo.io](https://ipinfo.io) \- we're free for up to 1k req/day, handle over 12 billion requests per month, and have been around for over 6 years. You can play with our data on our homepage, and for the free plan you don't even need a token, just `curl ipinfo.io`

We also have APIs to get IP ranges for companies, to get domains hosted on the same IP, and more. See [https://ipinfo.io/developers](https://ipinfo.io/developers)

</comment><comment><USER7> MaxMind is ridiculously cheap, and has solid public metrics on their own accuracy. What is this bringing to the table?

<comment><USER8> Does the default MaxMind GeoIP provide isProxy: false, isTorNode: false, isSpam: false, isSuspicious: false though?

<comment><USER9> No, but those kinds of flags are typically provided by DNSBL APIs.

<comment><USER10> Which dnsbl provide this data? Have been searching for it for a long time.

<comment><USER11> Here is a nice list of all sorts of dnsbl sources,

[http://multirbl.valli.org/lookup/22.214.171.124.html](http://multirbl.valli.org/lookup/22.214.171.124.html)

</comment></comment></comment></comment></comment><comment><USER12> > Free plan ‐ 12000 queries per month

That's nice. Maybe a free plan without an API key would be nice to try without registration.

Also you might want to integrate it to geocoder ip lookup: [https://github.com/alexreisner/geocoder](https://github.com/alexreisner/geocoder)

<comment><USER5> For the free plan the API key is probably needed to count how many requests you do. Free plan without entering a credit card on the other hand would be great. :)

</comment></comment><comment><USER13> We use IP-api.com and have unlimited queries for 15€/month. Worked pretty well for us

<comment><USER11> Just curious, do you have an estimate of average queries per month or day you are actually using at them?

<comment><USER13> We have around 2.1 mio queries per day, because we cache ip-loc data locally. otherwise it would be around 30-50 mio q/d

</comment></comment></comment><comment><USER14> I find monthly billing of usage based services to be very user unfriendly:

* I pay for 100,000 queries even though I made only 50,000.

* I need to upgrade as soon as my usage goes over the plan limit. And then, I need to remember to downgrade.

Be fair, charge by usage.

<comment><AUTHOR> Fair point. I'll check if such setup will work with Paddle.

</comment></comment><comment><USER15> How does tools like this work? Is it triangulated by pinging from different location?

<comment><USER16> From what I understand, which admittedly is not much, I believe it is actually a database lookup service that references sections of; or perhaps the whole IP that has been previously recorded as from country X.

I think countries themselves have ranges of IPs allocated to them, but again, not my area of expertise.

<comment><USER17> No, countries don't have ranges allocated to them. RIRs (ARIN, RIPE, AFNIC, APNIC) do, and then they distribute those blocks to LIRs (ISPs) in their coverage area. However, now with IPv4 block exhaustion, it's common to port old PI v4 address space across RIRs, or for RIRs to donate blocks to eachother, so there isn't any guarantee about address mapping to continents even.

You can always use `whois` on an IP address from a command line to get all the public records about it that you need. This will have information about the RIR, LIR, and potentially end-user of the block.

<comment><USER16> Ah I see, interesting, thanks!

</comment></comment></comment></comment><comment><USER18> How it works at backend? Where do you get all this info from? I am really curious.

</comment><comment><USER19> Well I hate to be the bearer of bad news but the capital of Wales is not London...

<comment><USER11> is_in_european_union: true,

that one is still correct? ;)

<comment><USER20> Nobody really know that. Could change any day.

</comment></comment></comment><comment><USER21> Off by 61 miles (Country and State are correct)

<comment><USER22> Completely off for me, it says "Venezuela" my IP is from France

</comment></comment><comment><USER23> Cool! The flag images don't seem to work.

<comment><AUTHOR> Thanks, fixed!</comment></comment>


Jaunt – A friendly Clojure fork - <AUTHOR> https://www.arrdem.com/2016/02/22/clojarr_-_a_friendly_clojure_fork/ <comment><USER2> About the namespace problem: I do a _lot_ of refactoring, and namespaces were never my problem, because the types of errors op is talking about could be handled by the test suite, and/or cider reloading. I really think I would _not_ want versioning of my namespaces - that would make a huge mess. So like many other ideas that sound good and pure and elegant at the first glance, I think this one would be an overly complex mess in practice.

BUT, there is a more important thing, and there I support the author: instead on pushing Rich (the author of Clojure) to include any shiny feature that someone thinks would be nice, and then complaining that Rich ignores the request, the OP forked Clojure and tries to prove that his ideas are better. I think Rich does quite well on keeping Clojure sane and useful. I have no doubt that he will include stuff that really proves to be better. But, 99% of stuff is better only while is on scratchpad, but turns out either irrelevant, or, even worse, outright horrible in practice.

That's why I think that everything that can be a library should be a library instead a part of clojure.core. Those things that could not be libraries (not many of those come to my mind) should first be proven in some sort of "experimental" clojure. clojure.core should stay as it is :)

<comment><USER3> > test suite

Re-running an entire test suite every time I make a tiny change to the code isn't viable.

> cider reloading

If only it didn't take forever! I really like Clojure _the language_ , but having to restart CIDER every time I want to make the REPL forget my old wrong definitions is killing me. Not resetting the REPL's state is also pretty bad: I might accidentally use an old definition that was supposed to be discarded. The difference in behavior between macros and normal code exacerbates this problem: when you redefine a function, all existing uses of the function now point to the new version; but when you redefine a macro, all existing code that was generated by macro expansion retains its old form. So reasoning about the effects of the old definitions still being there can get quite complicated. There ought to be some way to tell the REPL, in a single instruction: "Please forget that previous versions of my code ever existed. They're all wrong."

<comment><USER4> Restarting is different from reloading. Take a look at `clojure.tools.namespace.repl/refresh` - which in recent versions of CIDER is triggered with `cider-refresh`. It does what you're asking - blows away all the loaded namespaces and re-compiles them from source, synching up the running code environment with what's in your source files.

<comment><USER3> Thank you very much!

</comment></comment></comment></comment><comment><USER5> TL;DR: forking Clojure to fix namespaces.

> Because namespaces are mutable, even if I were to perform a rename > correctly, the old name is still present in the namespace.

First, ns-unmap your old name (a refactoring tool should do that for your, I guess). (edit: Clojure is a Lisp-1).

> What if we gave Namespaces and Vars version numbers? When a Namespace is re- > defined (the ns form is evaluated) then the Namespace's version is > incremented. When a def is evaluated, the version of the Var bound by the > def is set to be the version of the Namespace in which that Var exists.

Your environment could keep track of definitions and usages of your symbols (see for example slime-who-calls, etc.). That would be a good improvement for Clojure.

There is another problem: define namespace N, define variable N/x, using it in another namespace M, remove namspace N. Then, an old name x is referenced from M which does not exist in any namespace. Also, you redefine namespace N with a new x, and now old-x and new-x are different objects. I don't think version numbers would help you here.

I am just thinking aloud, but when remove-ns is called, you could re-parent orphaned names from that package to a global "orphans" table. When you intern a symbol in a namespace, first you try to see if you can recycle objects from "oprhans" based on their fully qualified name. So that new-x and old-x are in fact the same name object. Or, you just use a global map to store fully qualified names in the first place. Maybe the metadata attached to orphaned symbols should be cleared in this approach, to avoid keeping irrelevant data about a name when it is reused.

But again, you should be careful when you rename namespaces. Maybe the best answer is to simply be aware of the possible pitfalls.

<comment><USER6> > First, ns-unmap your old name (a refactoring tool should do that for your, I > guess).

clj-refactor has a cljr-rename-symbol function.

[https://github.com/clojure-emacs/clj-refactor.el](https://github.com/clojure- emacs/clj-refactor.el)

Here's a full list of its features:

[https://github.com/clojure-emacs/clj- refactor.el/wiki](https://github.com/clojure-emacs/clj-refactor.el/wiki)

</comment></comment><comment><USER7> Good initiative.

Clojure developement is driven by the needs of Rich/Datomic these days, it's understandable this might be frustating for users who wish clojure was more community driven, and exploring other areas.

I personally gave up on it because of this (I used to do clojure full time).

<comment><USER8> The real bummer is that Cognitect drives Clojure, and Cognitect's business is Clojure consulting. Now, if you look at some presentations about how Cognitect consults companies, you'll see that the advice often boils down to "don't use persistent data structures, use Java's", "don't use STM, use Java ConcurrentHashMap".

They stay in business by selling the cure to the poisonous snake oil they sell.

<comment><USER9> >> "don't use persistent data structures, use Java's" Love to see a reference for this.

<comment><USER10> Seconded, i find this plausible, but need to see a source.

<comment><USER8> Clojure at Boeing[0]

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

<comment><USER9> Can you link a quote or a point in that video? What does Boeing's use of Clojure have to do with Cognitect?

<comment><USER4> 21:40. He mentions in the video that they had a one-producer, one-consumer input queue that they originally implemented with clojure.lang.PersistentQueue. They engaged Cognitect for some code review/consulting, and Cognitect's advice was to use a regular Java ConcurrentLinkedQueue for this instead.

I think this particular example supports this "Cognitect snake oil" theory very poorly. I don't think PersistentQueue can be properly considered a first- class data structure in Clojure, as it doesn't even have a constructor function in clojure.core. The Clojure documentation, and the other writings of Rich Hickey and Cognitect don't encourage people to use this data structure. It exists, I think, for completeness and because there are some situations where it's appropriate, but unlike the core Clojure persistent data structures - maps, vectors, seqs, etc. - it's not designed as a general abstraction that covers the vast majority of general use cases.

Clojure is meant to be a practical language. It's hosted on the JVM and other platforms, and designed to make it is easy to use what those platforms provide. Where it's sensible to do so, Cognitect and other Clojure developers would certainly advocate using Java libraries to solve problems.

The other thing mentioned in the GP post was the idea of not using STM. This falls under the same umbrella. There are problems for which STM is the best solution, but there's a big space where something simpler is the right answer. In my observation, overuse of Clojure's STM is far more often the result of a developer impulse of "wow this is a cool looking feature, I want to try it" than any advocacy by Rich or Cognitect.

I also have some firsthand knowledge here, having been involved in a Cognitect engagement. I have some concerns about Cognitect as a result, but certainly nothing like this suggestion that Clojure is a real manifestation of the old fake Bjarne Stroustrup interview. [1]

[1] [https://www-users.cs.york.ac.uk/susan/joke/cpp.htm](https://www- users.cs.york.ac.uk/susan/joke/cpp.htm)

</comment></comment></comment></comment></comment></comment></comment><comment><USER11> On the topic of forking Clojure, I've had sort of an interest in writing a pure C version of the core of Clojure for a while; something with similar goals to Lua, namely that it would be self-sufficient, portable, and embeddable; a library first, much like Clojure is in Java. I guess it should be called Clocure if it ever came into existence. But honestly, I have no personal need for this, it's only something I like the idea of, and therefore I don't ever see myself actually writing it. (I guess I might use it for some small-ish scripts that I might otherwise go to Python or Ruby for. But I hardly write such small scripts anymore.) Either way, I still like the idea and will probably continue dreaming about it for a while to come.

That said, I have to second the other opinions in this thread, namely, that Jaunt is solving a problem in Clojure that already has other solutions. When I'm writing Clojure for work (I use it full time), I use Cider, and I often make use of C-c u, which is cider-unset, allowing me to make sure I remove a var from a namespace. That plus cider-reload gives me assurance that my namespace mutations are pretty reliable.

<comment><USER12> Have you seen Pixie? It meets many of the goals you describe:

[https://github.com/pixie-lang/pixie](https://github.com/pixie-lang/pixie)

<comment><USER7> It's cool, but abandonware sadly.

</comment></comment></comment><comment><USER9> This article is several months old, and the linked repo hasn't been updated in about two months.

<comment><USER13> The repo was updated 13 days ago.

<comment><USER9> yes, to bump a version number in a build script. the last meaningful change was 3 months ago.

</comment></comment></comment><comment><USER14> The author of this article started his first day on the job after University at Twitter today. Please send him your best wishes!

</comment><comment><USER15> Sounds like it fits within the "staged programming" model, which I think is a very interesting and relatively unexplored approach to adding some degree of dynamism into a statically typed language (which is not necessarily the goal here ...) It would be cool to have more of these systems reach the level where they are usable in commercial projects.

</comment><comment><USER16> Is "Jaunt" a reference to "The Stars My Destination" by Alfred Bester?</comment>


Freeciv founded 20 years ago today - <AUTHOR> http://play.freeciv.org/blog/2015/11/freeciv-founded-20-years-ago-today/ <comment><USER2> > The irony of it all is that last year when i had a couple of computer > science applying for a job, they told me that they had assignments of doing > bits and parts of a civilization clone at the university as part of the > studies, so i guess that the university got smarter in the meantime.

Yes, indeed. The Software Architecture course at Aarhus University (which is where the FreeCiv founders are from) now contains the HotCiv project: "This project develops a framework for defining strategy games similar to the classic computer game, Civilization." The lecturer, Henrik Bærbak, wrote a textbook for the course: [http://www.baerbak.com/description.html](http://www.baerbak.com/description.html)

<comment><USER3> FWIW I remember the book to be not very good.

</comment></comment><comment><AUTHOR> Hi everyone! Just a note that you can play Freeciv today at [https://play.freeciv.org](https://play.freeciv.org) \- source code here: [https://github.com/freeciv/freeciv-web](https://github.com/freeciv/freeciv- web)

We're always looking for more good developers!

<comment><USER4> I'm curious what are people working on in a 20 year old project? I only know young efforts like these. They mostly focus on getting anything close to the featureset of the original game. But I figure after 20 years that's not a problem with freeciv anymore, right?

<comment><AUTHOR> We have recently spent a significant amount of effort on making Freeciv playable in a browser. Porting the game to new platforms is a continous development effort. Freeciv-web is now playable in any HTML5 browser, but there are still many things to improve in the game.

</comment></comment></comment><comment><USER5> Dear God, I've been playing this for that long? Its just as bad as nethack. Okay, almost as bad as nethack. Goddamnit nethack, go away, I have work to do.

<comment><USER6> How can you say that during the yearly /dev/null tournament? :-)

</comment></comment><comment><USER7> News like this brings to mind a guys age...

</comment><comment><USER8> Thank God, in all that time, they've never been tempted to apply any graphic design talent to the project. The 'Win 95 Look' never goes out of style!

<comment><USER9> Those are vintage screenshots.

It appears to look like this nowadays: [https://play.freeciv.org/webclient/?action=new](https://play.freeciv.org/webclient/?action=new)

<comment><USER10> Still has a very vintage vibe to it; I'm not sure how favourably it compares with Civ II (1996)...

Some people appreciate retro looks, but everything from the sprite resolution to the colour palette feels like a nineties aesthetic.

<comment><USER11> Thanks, the Amplio used the original Civ2 sprite resolution and colour palette as a starting point. It seems to have hold up well.

There's also some layout logic at work. If you look at the way the units are aligned in the tileset you may notice that defensive units point right and offensive units point left.</comment></comment></comment></comment>


Microsoft Says It Will Continue Pursuit of TikTok - <AUTHOR> https://www.nytimes.com/2020/08/02/business/economy/trump-tiktok-china-national-security.html <comment><USER2> Link to MS announcement:

[https://blogs.microsoft.com/blog/2020/08/02/microsoft-to- con...](https://blogs.microsoft.com/blog/2020/08/02/microsoft-to-continue- discussions-on-potential-tiktok-purchase-in-the-united-states/)</comment>


Tesla is facing stiff competition in its plan to generate new revenue - <AUTHOR> http://www.businessinsider.com.au/r-tesla-faces-competition-for-customers-subsidies-2015-5/

<comment><USER2> After reading that article I don't see the 'stiff' competition that the clickbait title claims. It says 'Samsung SDI Co Ltd, LG Chem Ltd, Saft Groupe SA, and array of small companies' but it doesn't go into their actual offerings. The article only spoke of Tesla and a vague idea that there is competition with no actual proof. It did mention the state of Cali's initiative to subsidized green energy but without providing any substance.

I don't think Tesla has a lot of competition and that's why they released their patents. They need more minds focused on green technology because they aren't able to solve all the major issues.

Also, the only actual competition Tesla has in the current fossil energy market. They are trying to disrupt that market, they aren't cost competitive yet but they are getting there.

tldr; The article is a flame article with little to no substance about Tesla's competition. It lacks specifics.</comment>


Show HN: Kedo.io – Backend-As-A-Service for SMS First Companies - <AUTHOR>

We are building a backend-as-a-service to power your SMS-first service delivery. We take care of all technology with easy to use dashboard, multiple team members, payments & more. You can run your own Magic, GoButtler, HappyNow kinda service. We also integrate with Stripe and collect money on your behalf. With reporting, multiple team members and smart triggers built-in, you can focus on delivering the service not building a backend.
We are looking for some early adopters to help us test and polish the service.
Check us out at http://kedo.io <comment><USER2> Why do the links below 'You can use Kedo to build services like:' point to companies like Rdio and Reddit?

<comment><AUTHOR> Sorry, it has been fixed now.

</comment></comment><comment><USER3> You really should point to your URL directly.

<comment><USER4> [http://kedo.io](http://kedo.io) \--- for some reason, HN makes links in the original post unclickable</comment></comment>


YOLOv4: Optimal Speed and Accuracy of Object Detection - <AUTHOR> https://arxiv.org/abs/2004.10934 <comment><USER2> The original author of YOLO stopped working on it[1]. Alexey Bochkovskiy, aka AlexeyAB, created a fork on GitHub and wrote an extensive guide to customizing YOLO's network architecture, added new features, and has answered zillions of questions.

1: [https://twitter.com/pjreddie/status/1230524770350817280](https://twitter.com/pjreddie/status/1230524770350817280)

<comment><USER3> So the author goes, "wait, this actually causes more evil than good, I will not work on it any longer", and the other guy goes "don't worry, I will keep doing the evil for you!"

Sigh.

<comment><USER4> It's tricky thing... where do you draw the line? If someone works on the linux kernel, and someone uses the OS to do bad things.. should one stop?

Also consider that object detection has a lot of impact in positive ways as well. It doesn't seem so black and white.

<comment><USER5> I agree - but I imagine even personally it might be a hard thing to hear that something you created is being used to kill people, even with the knowledge that it is doing a lot of good.

I'm curious if this is something that some sort of modified license could help resolve. Do I have the option to license my software so that it can't be used in war?

<comment><USER6> Yes, but you need to be prepared to take it to court when someone uses your software in war.

<comment><USER7> and when the answer is "hey, it's GPL'd, here's our source download link, fuck off we're exactly following the rules"?

Licenses are not a viable solution to this sort of ethical quandry.

<comment><USER6> That answer should be unsatisfactory to the court, since it wasn't licensed under the GPL. The rules, in this case, say no use in war.

</comment></comment></comment></comment></comment></comment></comment><comment><USER8> And code on Github: [https://github.com/AlexeyAB/darknet](https://github.com/AlexeyAB/darknet)

PyTorch version: [https://github.com/Tianxiaomo/pytorch- YOLOv4](https://github.com/Tianxiaomo/pytorch-YOLOv4)

<comment><USER9> It's also in Ultralytics' repo which is very frequently updated.

[https://github.com/ultralytics/yolov3](https://github.com/ultralytics/yolov3)

</comment></comment><comment><USER10> I object to the use of the word "optimal" for a task like object detection; it feels counterproductive to claim that this is the "optimal" way of solving such a broad and complex problem. Great results, but their language needs some tempering.

<comment><USER11> EVERY 'good' thing starts out with 'good' intentions. And while it is small scale remains good. But as it scales up, it becomes evil. Even google, remember their motto? Now harvesting data like human bodies for its matrix. Even Facebook was a blast when it started, but now it's a merch store. Even the internet was beautiful when it started, now it's a sewer. It seems the only thing that can scale well without getting perverted is deep learning. But as long as humans are in that loop, it will fail. Cloud computing is a mistake. Bring back the pc, you know, 'personal computer'

<comment><USER12> These companies were always doing those things. Google always collected and connected information on you. Facebook was always using users content/data to experiment with. Cloud computing was always a mistake for most (pay more, get less control, get locked in). Deep learning opens up so many taboos our society is not ready to deal with them. As it scales it will open up more cans of worms.

</comment></comment></comment><comment><USER13> A video on YOLOv4 - Really informative. [https://www.youtube.com/watch?v=_JzOFWx1vZg](https://www.youtube.com/watch?v=_JzOFWx1vZg)

</comment><comment><USER14> I have had a lot of fun working with YOLO v3 for robotics applications, very excited to try these updates. Thanks to the authors for the updates and good documentation. Good object recognition is the backbone of a huge range of future applications, and YOLO has been a good option for a while.

</comment><comment><USER15> I'm a little skeptically of the Swish implementation after looking at Table 2.

Method | Top 1 | Top 5 No-op | 78% | 94% Swish | 64.5% | 86% Mish | 79% | 94.5%

Swish is the only value that decreases performance (and by a huge magnitude) but a very related methodology improves performance hummm...

</comment><comment><USER13> [https://medium.com/@riteshkanjee/yolov4-superior-faster- more...](https://medium.com/@riteshkanjee/yolov4-superior-faster-more- accurate-object-detection-7e8194bf1872)

Article on YoloV4</comment>


Mongo 2.6 Highlights - <AUTHOR> https://bugsnag.com/blog/mongo-2-6-highlights

<comment><USER2> What happened to v3 of Java driver? Abandoned?</comment>


Designing to Sell - <AUTHOR> http://zygote.egg-co.com/designing-to-sell/ <comment><USER2> This is a very well laid out entry. I wonder if you can apply similar principles to designing the homepage of a social application, where the user does not necessarily buy something, but still needs to be convinced about trying the product.

<comment><USER3> Sure they do. Instead of spending their money, they spend their time, and the two are interchangeable.

</comment></comment><comment><USER4> This is a good post, and presents a topic that is too often pushed to the wayside in web design.

One thing to consider is the path the user takes through your site. The examples in this post are all single-page examples, but often the AIDA process can be better achieved over a 2-3 page browsing experience, where the information is presented in an easy-to-understand sequence. Visitors don't necessarily read your pages top-to-bottom.

</comment><comment><USER5> Interesting, but our recent conversations about eBooks seemed to indicate that plain, non-graphical salesletters with a straightforward flow worked far better than "traditional" webshop layouts like these. I wonder if there's any comparison here -- does that format only work better for eBooks, or could these guys be making more money by cutting out the chimps?

</comment><comment><USER6> This post shows how you can implement the old direct mail sales letter as a web page. It does stay on the surface of direct marketing know-how, but it is a good introduction into the matter.

It shows the inner architecture of the sales letter (which is AIDA) and shows well, how this can be applied to the landing page, which I call conversion page.

If you like to get a taste of how one could go deeper into the direct mail tricks here, just google for example "bucket brigade". That should give a hint how said inner architecture of a landing page could made even more tricked out.

And one for the historians. Did you know that 37signals did just that as a service agency, improving conversion rates, prior to going into web services?</comment>


Why Aren't Top Journalists Rich?  - <AUTHOR> http://priceonomics.com/why-arent-top-journalists-rich/ <comment><USER2> The problem, as I see it, is that newspapers (print or online) operate very differently from other forms of media, like TV, radio and blogs, and make a very different product. Newspapers are the only media institutions that continually cover wide beats. They have a reporter in city hall whether or not something interesting is happening there, one in court, and one in Germany. This makes print reporters much more knowledgeable about their respective beats than other kinds of reporters, and that's why most breaking stories originate in newspapers. TV, on the other hands, is usually a secondary news collection organization. It often lets the newspapers break a story before covering it themselves. This means that they can afford to send a reporter to Germany only when something interesting is going on there.

Newspapers have been able to support this model because their customers buy a package. They pay the same price every day because they have to buy the entire paper, though they are likely interested interested in a different story each time. This means that when there's news in Iraq, people buy the paper for the Iraq story, and that day the Iraq reporter subsidizes the supreme court reporter.

But this model is a problem for online journalism, because revenue is generated only from the articles that are actually read, and obviously, a single article generates less revenue than a complete package.

Unfortunately, this would make it very hard to keep reporters on the ground that slowly get to know their beats and wait for something interesting to happen. Unless media comes up with a new way to support regular beat reporters, we will lose the most essential information-gathering mechanism we have, and the news will be even more controlled by PR than it is today (and even today a large portion of the news is spoon-fed to the few reporters left by PR firms).

<comment><USER3> What's probably more likely is that nebulous publications might fail, and instead people may follow many smaller niche online publications. You might read about tech news, supreme court rulings, and something happening in Germany from three different, unrelated sources, but ignore local news about things happening in Amsterdam. These would be run by people with an interest in a particular topic, perhaps as a hobby part time. Hobby bloggers are really quite common so it's not impossible to imagine this.

<comment><USER2> But each of these publications won't make enough to pay good reporters to do a good job. Hobby reporting is a nice idea, but as a former journalist I can tell you that it's very hard to do serious reporting in less than full-time.

</comment></comment></comment><comment><USER4> It looks like the top journalists are rich. The article says Anderson Cooper is making $10 million per year just from his show and Fareed Zakaria is commanding $75K per appearance.

The article says they don't count because they aren't print journalists. Isn't that like a orchestra violist asking why top musicians aren't rich, but then saying Justin Timberlake and Rihanna don't count because they aren't orchestra musicians?

It seems like the big money in journalism is in video, not print. Just like the big money in music is in pop, not classical.

I suspect this is because it is easier for the casual viewer to quickly notice the difference between two people on screen compared to two people's writing. Being easier to recognize makes it easier to gain a following.

<comment><USER5> But is Anderson Cooper making that money as a journalist or as a TV personality?

I don't mean to demean him by saying that, as I'm not very familiar with his background or his career. I would question, however, whether he is paid that much because of the journalism he does or because of his status as a TV star.

Maybe there's currently a large market for TV personalities who talk about things that are new but not a large market for actually discovering and distilling facts about our world. Maybe appearance, not content, is where the money and market is.

</comment></comment><comment><USER6> I just wish they focused on profits per employee as a metric, or really any actually meaningful metric besides gross revenues. You can make anything impacted by technology look bad by looking at only revenue.

The music industry revenues dropped by half between 2000 and 2010, however it doesn't talk at all about how much costs dropped in the same time period. More specifically, the cost per artist brought to market (album creation to distribution). As long as more music is being created and making to listeners, then market demand is being satiated, and that is all that matters.

<comment><USER7> Author of the post here. I don't have any metrics like those up my sleeve, but I would encourage you to check out the Pew survey i mentioned which (in reference to print and tv) finds that:

"Nearly one-third of the respondents (31%) have deserted a news outlet because it no longer provides the news and information they had grown accustomed to."

[http://stateofthemedia.org/](http://stateofthemedia.org/)

</comment></comment><comment><USER8> I always thought that the top ones were rich, they just made their money elsewhere, like books and TV. Am I wrong?

</comment><comment><USER9> _It's worth noting that op-ed writers are generally the most well-known journalists. [Their] picture is always printed, they write with a signature style, and papers advertise their faces and perspectives. Reporters, in contrast, write in an anonymous "this is news" tone fitting an institution that did not introduce bylines until the 1920s._

This suggests a solution: print journalists' photos with their articles, so they can be recognized and remembered more easily. I'd wager that some newspapers would fight such a change, but it might actually be in the paper's interest for their reporters become draws in their own right, much like op-ed writers or reviewers like Roger Ebert.

</comment><comment><USER10> > It's no secret that technology disrupted journalism's business model, and it > has yet to recover. What's puzzling is that the disruption seems to have > created lots of losers but no new winners within journalism.

And I stopped reading...

drudgereport.com (~1.3M a year [https://en.wikipedia.org/wiki/Matt_Drudge#Drudge_Report](https://en.wikipedia.org/wiki/Matt_Drudge#Drudge_Report))

<comment><USER11> I try not to stop reading too early. Drudge is not a journalist. Indeed, I have seen at least definition of "journalist" (a "reporter who writes for an editor") that was described in the source I saw it in as an explicit exclusion of Drudge from the ranks of journalists.

A blog post, "Blogs lead in critical thinking, but newspapers still matter,"

[http://www.dcscience.net/?p=6083](http://www.dcscience.net/?p=6083)

submitted to Hacker News earlier today to no discussion,

[https://news.ycombinator.com/item?id=5907627](https://news.ycombinator.com/item?id=5907627)

illustrates some of the reach that "traditional" journalism still has. The quality of professionally edited journalistic submissions to HN, as contrasted with the quality of many (although not all) blog posts submitted here, suggests that there is still a role for journalism in promoting more informed, more thoughtful discussion of issues we all care about.</comment></comment>


Tilt: Visualize your Web page in 3D - <AUTHOR> http://hacks.mozilla.org/2011/07/tilt-visualize-your-web-page-in-3d/

<comment><USER2> Lots of discussion from three weeks ago:

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


Show HN: Code in any language. With Anyone. Anywhere. - <AUTHOR> http://www.thecoderlab.com/

<comment><USER2> There are a number of other (albeit rudimentary, but equally free) collaborative coding sites out there. What does this offer that the others don't? Or is it not about features, but execution instead?

It's also been about 45 minutes since I signed up, and I haven't gotten an invite yet. I'm not necessarily inclined to believe that you're being hammered by requests, which suggests someone is just asleep at the wheel. If you're not really ready for users, by all means wait until that time and _then_ post here. My impression was that "Show HN" connotes readiness for us to kick the tires at least a bit.

I'm open to disagreement on that last point, but my understanding was that unfinished product showings generally evoked ire from users.

</comment><comment><USER3> Nice work. Sure, there are other options available, but I like the simplicity and ease of use of yours (judging by the video). Don't let the fact that there are other options available discourage you.

Why are you giving this away for free vs a SaaS model?

</comment><comment><USER4> The site doesn't really say much, how is this new?

There a are a lot of coding enviroments online with collaboration capabilities.</comment>