"Hello World" in Dart, compiled to JavaScript - <AUTHOR> https://gist.github.com/1277224 <comment><USER2> As me1000 (Randy Luecke) says Dart is not meant for hello world. If you run this through closure-compiler it's reduced to 2000 lines which is nothing next to Underscore, jQuery, Dojo, etc.

We all know the benefits of offloading code to a well known and well tested library or framework, especially if you're writing an app that is thousands of lines anyway. How is this contentious at the end of 2011 unless you're just hating Dart for the sake of it?

I haven't looked into the language yet and unless you haven't either let's all refrain from judgements based on this silly metric alone. Circle jerks and knee-jerk reactions are for Reddit, not HN.

Don't get me started on the whining about math performance. Reminds me of dinosaurs whining about how assembly is better than C is better than Java is better than.... There is more to software development than math. Crazy, new fangled, inefficient languages eat the lunch of older languages every single time. You have to be insane to pull out that gem. If math is your bottleneck then don't use Dart, if you know that math is your bottleneck then you shouldn't have to be told this! Sorry for the rant but half of the complaints I've read about Dart are utterly ridiculous, and speculative to boot.

<comment><USER3> ..and here's the jsperf for the --optimize'd hello world vs. vanilla JS - <http://jsperf.com/dart-hello-world-test-with-optimize/2>. 17k vs. 4M for me

<comment><USER2> Got any useful benchmarks? Nobody is wondering which language to write their next "hello world" app in.

Just for the record I'm not saying Dart is amazing and everyone should use it, all I'm saying is that we should evaluate it objectively. If raw speed is your bottleneck then why are you wasting time evaluating Dart? Nobody is forcing anyone to use it, you can ignore it and move on with your day.

<comment><USER3> Dart won't be supported ubiquitously any time soon (if ever) which is why there'll always be a Dart->JS compiler. Why not just stick with vanilla JS or Harmony/ES6? I'd benchmark some bigger apps but they don't exist yet

</comment></comment></comment></comment><comment><USER4> So the joke is that a prototype of a whole separate language has to include its runtime in its cross-compiled output? Did people... think this wouldn't be the case? Do they think that Javascript is not thousands of lines of C/C++ lurking in your browser?

Good joke guys, but I don't think you realize which way the punchline is pointing...

It sort of amazes me that people are being so hard on Dart, given that they should be grasping for _any chance_ to leave the warty and dated pile of compromises that is Javascript behind. Even the javascript community seems to tacitly admit that Javascript is a bit of diamond amongst a whole lot of dross; hence CoffeeScript and books like "Javascript: The Good Parts".

<comment><USER5> Amen. The "me too" culture that's going on w/r/t Dart is really disappointing.

Google: "Hey everyone, let's make the browser better by switching to something that smells less like garbage than javascript."

Community: "You forgot a semi-colon!"

Shameful.

<comment><USER6> Sorry but it's been more like

Google: Hey everyone, we have decided the future, here it is, get used to it.

Community: Maybe you should get behind Harmony instead of secretly building replacements to the building blocks of the web and issuing them by imperial decree.

<comment><USER5> There was an internal memo. They're going to push it. Why do you have to "buck the man" in order to feel like you're in control of your tools? Why does it need to be repeated that everyone has a choice?

If Dart grows and solves some of the junk I have to deal with in the JS ecosystem, I will use it. We'd all be fools not to.

<comment><USER6> Wouldn't happen to be a Flash dev would you?

I do not want the core technologies on which the web is built owned or controlled by any one company. No matter how you look at it Dart is not a standard, it's not controlled or directed by any open body and its development is not public.

It took a goddamn decade to break Microsoft's endless attempts to own core web technology, if you're happy with another company doing it just because you think they're a 'nice' company you're the fool.

There is a large, public and active effort to solve many of the issues JS has, it's called Harmony. Maybe you should get involved with that instead of jumping on a proprietary bandwagon.

<comment><USER7> "Dart is not a standard, it's not controlled or directed by any open body"

You say that like it is a bad thing. I don't think it is.

Standardizing technologies is great once they are mature and are already accepted as the obvious de-facto standard, but trying to push real change through standards bodies results in exactly the sort of morass that JavaScript has been stuck in and which makes Dart a refreshing attempt at change.

Yeah, yeah, the great new version of JavaScript will be here next year, same as it has been going to be here next year for the past 10 years.

When it comes to making real progress you almost always need to buck the standards and drag the world kicking and screaming into a better future and then let the standards bodies figure out how to fit things in to their world later on. I'm continually shocked there are so many people in this industry that don't see this even though the proof for it is everywhere.

I'm not sure Dart really is the better future we need in a client-side language as there is still a ton more work to be done (the technology is far less baked than I expected it would be, even though it is only a preview release), but I applaud Google for trying and I'd suggest other players trying to sabotage their efforts should redirect their own efforts into something even better than Dart. Win on the merits of the technology, not on slavish devotion to existing standards. With increased competition everybody wins, especially if everyone uses an OSS model as permissive as Google is with Dart, and maintains JavaScript as a legacy lingua franca.

<comment><USER8> > exactly the sort of morass that JavaScript has been > stuck in

You mean the one where some large corporations are doing what they can to keep it from improving?

Seriously, Google has been sabotaging all sorts of JavaScript improvements by flat-out refusing to implement them.

So in fact the "other players" _are_ directing their effort to something they perceive as better than Dart: Harmony.

As for the rest, what will "win" is not necessarily going to be based on the merits of the technology but on the strength of single-vendor tie-ins, in the usual way....

<comment><USER7> JavaScript was stuck in the mud before Chrome or V8 even existed. Before Google, Microsoft and Yahoo got the blame.

Regardless of who the actors are that are most currently gumming up the works, all of this just proves the point that standard bodies are not an effective tool for actually creating useful technology.

<comment><USER8> There was all sort of innovation in JavaScript going on at the time; still is.

As you note, getting the innovation into a standard is the hard part, when some of the parties to the standards process don't actually want the language to improve...

But Google claiming this is a problem for JavaScript while it is one of those exact parties is just hypocritical.

</comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER9> This is called "a runtime". A bunch of things that have to be loaded on the target machine for use by a compiled program. Just about every compiler works this way, whether the output is machine code or JavaScript. It is possible to not emit or load the parts of the runtime which will not be used by a given program, but that's difficult and in many cases even impossible.

I am not a web programmer, and I don't use JS and don't plan to use Dart, but I am flabbergasted that a bunch of techies are going wild and posting facepalm pictures over a perfectly normal technical situation. Maybe Google will pare down the runtime in the future, maybe they will figure out a way to exclude parts of it which are not needed, but right now they are just making the default technical choice that just about all compilers make. This is a non- story. Compile "Hello world" into an executable, and see how many kilobytes it takes on most architectures, despite the object file being a few bytes. Geez.

<comment><USER10> In general it's true that you can't avoid the runtime, but in this case I think people's expectations are colored by CoffeeScript, which offers (for many) a more productive environment than vanilla JavaScript, with no runtime at all. Since Dart is a CoffeeScript competitor in the "languages that compile to JS" space, this is a legitimate disadvantage. Dart may well have so many advantages over CS that this becomes a non-issue in practice, but we shouldn't pretend this isn't a story at all.

<comment><USER9> I agree that it's perfectly legitimate to discuss the runtime needed for Dart, and point out that it's a disadvantage that it is needed at all, or to criticize the runtime, or whatever.

What shocks me is that people who are supposed to be techies are pointing their fingers at the runtime and making monkey noises, because they apparently have never seen a language runtime or heard of the concept. Dart did not compile "Hello, world" to 17000 lines of code; most of that code has nothing to do with the specific program. And that's the usual situation for compilers, although some specific compilers can avoid that (e.g. CoffeeScript, which is a close mapping of its target architecture).

<comment><USER11> The reason we are making monkey noises and pointing fingers is because we expected a better JavaScript, not a Java that compiles to JavaScript. We already have that. It's called GWT and this is just GWT 2.0 with a pretty name.

<comment><USER12> There's already a GWT 2.0; this is more like GWT 9.0. And as someone who has done a lot of work in GWT (and JS, and CS), I can see a lot of potential in Dart. GWT is superior to javascript/coffeescript for a certain set of problems (mostly fat-client-type webapps); a major upgrade to the language and tooling would be welcome.

</comment></comment></comment></comment></comment><comment><USER13> Funny. But to be fair, a Hello World in C compiles to a 27k binary. Yeah yeah, optimize this, leave out that and you can get it smaller. Still doesn't change the fact that Hello World is not the target use-case for either C or Dart. Dart is intended for very large applications (compared to JS), so the additional weight for includes isn't that big of a deal.

It also doesn't change the fact that Dart sucks. For other reasons though.

<comment> wes-exp On 32-bit Linux GCC, C hello world comes out to only 7 KB. Without optimization.

<comment><USER14> Just as a datapoint (I did this test before seeing the comment), in 32-bit cygwin a hello world written in C compiled to 12KB. In C++, it compiled to 497KB.

</comment></comment></comment><comment><USER15> I'll repeat what I said in the GitHub thread:

There's this interesting tool called Google Closure Compiler. It does dead code elimination. <https://gist.github.com/1277285>

Notice that this source is now 2000 lines of _pretty printed_ JS. Given that anything interesting these days uses jQuery or Underscore.js clientside, and similar things serverside, this amount of JS for even Hello World is standard fare.

EDIT: To be clear, I don't really give two hoots about Dart ... yet. I use ClojureScript and since ClojureScript ships with a similarly rich API / data structure set, Google Closure Compiler is essential to keeping code size down.

<comment><USER16> I'm sorry, but 2,300 lines of code is in no way acceptable as a "dead code"-eliminated Hello World program. Not by a longshot.

<comment><USER17> If all you use javascript for is console.log("Hello World"); then v8 will seem unnecessarily large too.

If all you do is one DOM transformation then jquery will seem huge compared to just doing it by hand (probably hundreds or thousands of lines of code vs 3).

I guess at this point I'm just repeating the OP, but this is simply in no way demonstrative of Dart. It can at best serve as a learning tool of the internals (and perhaps there are valid criticisms once you look at those), but any conclusion on code size is very flawed from this one example.

<comment><USER18> jQuery is huge compared to doing it by hand, and I actually chose against jQuery for a web service targeted at mobile phones.

However, in the case of jQuery the productivity / KB ratio is freakishly huge.

I fail to see how that will be the case for a new programming language. Javascript is already fast and still improving in bounds and leaps. It is also finally possible to write correct cross-browser code with the help of jQuery and CoffeeScript. It is a true standard.

What can Dart really provide that Javascript cannot?

Refactoring tools? Some people would like that, but it still won't be bullet proof (as I understand the static types in Dart are optional), and there's nothing worse that a tool on which you can't rely on (personally I hate the Intellisense attempts being made in IDEs for Ruby or Python).

What about speed? Well, Java/Quake2 was compiled to Javascript using GWT and it worked just fine -- what more could you want from a sandboxed environment? To me, these days big page load times either on my desktop or on my mobile are almost always related to bandwidth.

</comment></comment></comment></comment><comment><USER19> I compiled that code with the google closure compiler. I used advanced optimisations for dead code removal.

The result is 94% smaller - 32k, or 9k gzipped. A 32k overhead could be absorbed by most large web applications without being noticed.

[http://closure- compiler.appspot.com/code/jscd4ddca10c0a518fc...](http://closure- compiler.appspot.com/code/jscd4ddca10c0a518fcb6ea6f56676ef790/default.js)

</comment><comment><USER20> same code in coffeescript (@ preceding testMain makes it a static method and it looks like print in Dart converts to console.log)

        class HelloCoffeeTest
          @testMain: ->
            console.log "Hello, Coffee!"

        HelloCoffeeTest.testMain()

resulting js

        var HelloCoffeeTest;
        HelloCoffeeTest = (function() {
          function HelloCoffeeTest() {}
          HelloCoffeeTest.testMain = function() {
            return console.log("Hello, Coffee!");
          };
          return HelloCoffeeTest;
        })();

        HelloCoffeeTest.testMain();

<comment><USER21> CoffeeScript is meant to be synaptic sugar on top of JS. Dart is a language with different semantics that happens to compile to JS. As such it includes a lot of runtime code. More appropriate examples would be Emscripten, Parenscript, or ClojureScript.

<comment><USER10> There _is_ a legitimate point here though. If I'm a developer working on a new project, and I'm dissatisfied with JavaScript, I have a couple of options. I could try Dart, which will cost me a significant amount of performance in all browsers that aren't Chrome, or I could go with CoffeeScript, which will have good performance in all browsers (including Chrome, since Chrome will be forced by the other browser manufacturers to keep its engine up-to-date). For me that'd be an easy choice, unless one of three things happens:

(1) Dart's performance is _so much_ better than that of JavaScript that it's worth sacrificing performance in every other browser to get hugely better performance in Chrome. That seems unlikely to me, but maybe it's possible.

(2) Chrome ends up with 90%+ market share, so it doesn't matter that I'm bad in all the other browsers. But I can't see this happening as long as e.g. iOS is around and relevant.

(3) I have the resources to write both a Dart version for Chrome and a CoffeeScript version for older browsers. At this point, Google has strictly made my life harder than it would have been otherwise.

I do want to give Dart a fair shake, but I'm having a hard time seeing how it could realistically succeed.

<comment><USER15> Anything happening in a client browser will involve a significant amount of IO - querying / modifying DOM and remote requests. I don't think that choosing Dart over CoffeeScript is going to make much of a difference for most applications.

See Objective-J / Cappuccino which chose to eat the very real overhead messaging in order to gain expressiveness. How many JS apps are as responsive / elegant as 280 North Slides?

<comment><USER10> I'm referring mainly to the page load time increase, which is important, especially on mobile. (Given what I've seen of the generated code, I suspect runtime performance will be affected too, but I haven't tested, so I can't say for sure.) This is why people create microframeworks—the page load time improvement with e.g. zepto over jQuery is not insignificant.

</comment></comment></comment></comment></comment><comment><USER22> I don't understand why Dart is supposed to be good, someone please explain it to me like I'm an eight-year-old

<comment><USER23> It's not right now. It's a lousy CoffeeScript. The thing that makes dart good is that it could, some day, have it's own runtime. Also, the language is being designed by the team that did v8. So I'd imagine they plan to build support into chrome at some point.

<comment><USER21> I agree CoffeeScript has nicer syntax, but it retains all of Javascript's semantic warts. Whatever quibbles you might have about Dart's syntax (it's young yet!) it's semantics are much nicer than Javascript.

<comment><USER10> Well, except for the unsound covariant generics, the lack of an arguments object, and the implicit downcasts, and so on...

<comment><USER21> Hint: Dart is a dynamically typed language. The covariant generics and the implicit downcasts are there on purpose.

The lack of an arguments object is a feature not a bug. A rest argument like in Lisp is much better for optimization. The design isn't done yet given that Dart has optional arguments a rest argument would fit in.

</comment></comment></comment></comment></comment><comment><USER24> This reminds me of the very early days of C++ were people would use the size of a compiled "Hello World" to argue their point. C++ targets a completely different domain from JS where the size of the runtime etc. is somewhat important and it makes sense to think about this.

I always thought that JS had this culture of "it works and is fast enough for most users" attached to it, so I'm curious what is so different here? Every JS application nowadays comes with tons of framework code already. Does it make a big difference if you carry around a (non-minified) 17000 lines runtime?

Of course, if you argue about elegance, none of this matters.

</comment><comment><USER25> While this is hilarious, it's exactly fair. Dart is still in a very early tech preview, and they clearly haven't optimised code generation yet.

Right now, it's probably designed to be run through something like Closure Compiler, which removes dead code and minimizes the output.

</comment><comment><USER26> Oooooooo. So it's Javascript except with a highly constraining layer of blub on top of it. I'll go back to learning coffeescript then...

<comment><USER27> I'd say the gist demonstrates that it's _not_ Javascript. What you see is the entire runtime, compiled to naive js.

If anything, Coffeescript is "just" js with syntactic sugar. Not that there is anything wrong with that.

<comment><USER20> that's a really interesting comment. where exactly is the line drawn between "just syntactic sugar" and "a different language"?

Here we have two ways of expressing code, coffeescript and dart. Both are syntactically quite different from js, both offer features not found in js, both encourage you to write code differently to how you would in js and both compile to plain js.

<comment><USER27> > where exactly is the line

Not that I have an aswer to that, but I have the impression Coffeescript was designed specifically to compile 1:1 to matching js.

A lot of the distinction seems to depend on the local culture of the language. I've seen a lot of lispers talking about their new "language", where they add some minor feature to scheme.

<comment><USER20> _...Coffeescript was designed specifically to compile 1:1 to matching js_

possibly initially, but there's a lot of constructs in coffeescript that aren't in js eg existential operator

        solipsism = true if mind? and not world?

compiles to

        var solipsism;
        if ((typeof mind !== "undefined" && mind !== null) && !(typeof world !== "undefined" && world !== null)) {
          solipsism = true;
        }

see also splats <http://jashkenas.github.com/coffee-script/#splats>, function binding and comprehensions over collections eg

        eat food for food in ['toast', 'cheese', 'wine']

</comment></comment></comment></comment></comment><comment><USER28> So this includes the full Dart runtime library compiled to JS, and people make a big deal out of it being a long listing.

</comment><comment><USER29> It's official now: Dart is meant as a practical joke to show why Javascript needs to be replaced by something sane like a bytecode VM.

Either that, or I don't want to surf this internet anymore.

<comment><USER30> "Javascript needs to be replaced by something sane" really? You should read what the goals are for Dart.

</comment></comment><comment><USER31> I think the problem of Dart and Google's many strategies in web application developer tool area is the belief that the current state of web app development is in a very serious terminal illness that requires chemotherapy, with a complete change of how we do things, while many others - notably the CoffeeScript camp - have shown that we are still essentially in good shape and all we need is some herbal tea to help the immune system. I am not discounting the value of the bold move of Google, but I am very disappointed to see a big negligence of the good parts of JavaScript and other dynamic languages and a blind copy of Java (mis)features. I have not seen Google contributing to the common and popular JavaScript frameworks like jQuery (and Microsoft did... what a strange world). Maybe it's NIH syndrome at play.

</comment><comment><USER32> They obviously embed into the emitted javascript the whole Dart runtime. Whether it is needed or not.

</comment><comment><USER33> Wait, is this an indictment of Dart? Or of Javascript?

<comment><USER34> I thought it was an indictment of ridiculous comparisons...

<comment><USER4> As you gaze into this thread, it gazes into you.

</comment></comment></comment><comment><USER35> This comparison is asinine at best. The runtime is bound to be bigger. And remember DART eventually will have the runtime included in Chrome and hopefully other browsers. The way things are going in the browser world, all people might actually care about is Chrome and if there is a wonderful IDE support which comes with strongly typed languages, there is a real shot at this becoming a standard.

</comment><comment><USER36> I wonder if the only speed benefits that the Dart VM gives would be able to be beaten out by a smart compiler. I know this is early for the cross-compilation code (it doesn't trim out anything it doesn't need here), but I hope this isn't what is ultimately used in that comparison.

<comment><USER19> As I understand it, dart isn't trying to be a faster javascript. Its trying to be a better GWT.

Many googlers I've spoken to firmly believe that you need a strongly typed, OO language with good tooling to be able to develop any large application. They believe web apps are no exception.

Google has worked hard adding types to javascript with the closure compiler. But, there are limits to what you can achieve using javascript.

Comfortable programming in the large is the main value proposition of Dart. Expect to see good developer tools, debuggers, profilers and server-side runtime environments for Dart appearing over the next few years.

(Disclaimer: I don't share this view)

<comment><USER37> _dart isn't trying to be a faster javascript._

It isn't trying to be a javascript, but it's certainly trying to be faster. Performance features prominently in every statement of their design goals. Not only that, but performance in all modern browsers - i.e. including the ones they don't control and won't ship with a Dart VM. I don't see how they can possibly pull that off. Can anybody?

</comment></comment></comment><comment><USER5> The comments on this thread are a disgrace. Read more.

</comment><comment><USER38> I'm noticing all those functions being defined with ever increasing argument counts. I'm sure Google will optimise the output one day, as soon as they learn about arguments.length.

</comment><comment><USER39> Google Dart was designed to build large scale web applications, yet all their demos and example code only includes small applications. That still require quite a lot of code to build.

I don't see any profit of building a application in dart, if you have to create more code your self than you would with a regular HTML5 based application.

As this "Hello World" demo shows, the only thing It's good at is creating bloat and this will probably stay this way until native parsers are implemented.

</comment><comment><USER40> Wow. Reminds me of GWT...

<comment><USER41> you say that like GWT is somehow bad!

I think GWT is a great piece of tech. To be honest, google has way too much NiH syndrome, even internally...

<comment><USER42> I still have trouble understanding how anyone can take something like GWT seriously.

Whole books could be written about everything that is wrong with GWT, but here is one post that barely scratches the surface: [http://ryandoherty.net/2007/04/29/why-google-web-toolkit- rot...](http://ryandoherty.net/2007/04/29/why-google-web-toolkit-rots-your- brain/)

</comment></comment></comment><comment><USER43> I prefer coffescript <https://gist.github.com/1277567>

</comment><comment><USER44> If Microsoft had suggested this, they would be persecuted and beat into submission.

<comment><USER45> Today yes. In 1995 it would get 95% market share.

<comment><USER44> Heh, true that.

</comment></comment></comment><comment><USER46> So, something that lets people who don't understand JavaScript "compile" some other language into JavaScript, is horribly inefficient. Wow, what a surprise.

<comment><USER47> Do you mean to imply that the point of Dart is to be an easier to understand Javascript?

<comment><USER46> Not at all. I'm saying if you want to make web apps that use JavaScript, write JavaScript.

</comment></comment></comment><comment><USER48> People got just as pissed off as this over the amount of code Fructose (my Ruby-PHP compiler) outputted for Hello World.

Looks like most here don't know how compilers work.

</comment><comment><USER49> I haven't seen such a neatly formatted piece of JavaScript code in a long time.

</comment><comment><USER50> so fuckin what

</comment><comment><USER51> I can't believe that a gist somehow turned into a 4chan thread. I found that infinitely more horrifying than the fact that a hello-world program nearly crashed my browser through sheer size.

<comment><USER52> This is not going to be your century :-D

</comment></comment><comment><USER53> ewwwww</comment>


Stop Screwing Around and Focus, Will Ya? - <AUTHOR> http://www.gobignetwork.com/wil/2007/5/3/stop-screwing-around-and-focus-will-ya/10145/view.aspx <comment><USER2> From the title I sincerely thought that the article will talk about the relation between entrepreneurship and promiscuity.</comment>


Inexpensive chip-based device may transform spectrometry - <AUTHOR> http://news.mit.edu/2018/inexpensive-chip-device-spectrometry-1023 <comment><USER2> I help design spectrometers. Every once in a while, a new idea for a mini spectrometer floats across my desk. Many of the ideas are based on silicon IC fabrication technologies or micromachining.

The drawback is the same in every case: The sheer amount of light that can pass through the optics of a spectrometer depends on its size. This in turn affects what signal-to-noise ratio can be realized.

These devices are certainly interesting, and performance is relative to requirements, so a novel application could make use of whatever sensitivity is made available by a particular device. But a tiny spectrometer isn't likely to be a drop-in replacement for a big one unless the big one is overkill for its application.

Still, I read these articles with interest, because my "size matters" rule is somewhat ad hoc, and there might be a factor that I'm overlooking.

<comment><USER3> Maybe you can help me with this... I want to measure the quality of light in my home and office. CRI seems to be the right metric, and it seems that the cheapest option is a $2000 (Sekonic) hand-held device. Are there cheaper options? I don't need much precision, just enough info to understand that these lightbulbs over here are much better than those other lightbulbs over there.

I am puzzled as to why it has to be so expensive. I would think one can put a prism, project the light over the surface of a black-and-white CCD sensor and measure the light intensity along the length, giving a reasonably good idea of how much energy is deposited into each wavelength range. I feel like one of these can be made for $20 in parts?

<comment><USER4> You can get a plastic DSLR camera body cap for less than 50 cents each (ebay from China). This cap goes where the lens would attach the camera when you don't have a lens on. Sometimes I cut a hole in the center of a cap and make really hacky camera "lenses" for fun. You could put a prism on the outside of a cap.

You would then need to calibrate your new spectra-cam on something with a known radiation (usually just find a good blackbody radiator.) You can't just convert to black and white without calibration because the RGB sensors on the camera are going to have their own sensitivity to different wavelengths. This would be an awesome project!

\--

I write firmware for high end professional LED lights, and have a $3K spectrometer on my desk. Here are things I've learned:

1\. CRI is simply a bad formula to judge light quality overall and gives almost meaningless results at lower color temperature levels.

2\. There are lots of fantastic python modules for working with spectrograph and light data.

3\. One awful thing cheap LED lights do is blink slowly to control their voltage. This is at least as bad a poor CRI for aggravating your eyes. (Sometimes you can see this just by using slow motion video on your phone)

<comment><USER5> Interesting detail. On this, though:

>One awful thing cheap LED lights do is blink slowly to control their voltage

I assume you're talking about PWM. That's not just to be cheap. It's the only real way to control brightness.

<comment><USER4> (Sorry, I meant to say that I hate cheap LED lights that blink slowly to control their _brightness_.)

Blinking the LED on/off to control its brightness with a PWM is definitely not the only way to control output. And if you are controlling by blinking, PWM is still the bottom of the pile in ways to blink, from a quality of light point of view.

<comment><USER6> What other ways are there? Nobody is going to want to dissipate heat in a linear element somewhere, are they?

I guess that because LEDs are actually so efficient, that isn't such a bad idea as it sounds at first.

<comment><USER7> A constant current source does not have to be linear, one can use a switchmode powersupply with current regulation. Then the current though the LED flows in a continuous manner.

<comment><USER8> Switch-mode regulators don't pulse?

How wrong am I to think that a capacitor after the PWM-regulator would give a reasonably good approximation of a constant voltage?

<comment><USER7> Sure they pulse/switch, but that is into/from the inductor/capacitor used as intermediate energy storage, not through the load (LED). At the output a constant voltage is seen (plus some ripple).

A capacitor on PWM output will give a decent approximation, _if_ it is big enough. For large LEDs this can be very costly (relative to other parts in system). Though the inductor in a switching converter is also a big cost driver.

Both for the capacitor, inductor and wrt to human perception increasing switching frequency helps. So that is what modern designs focus on normally.

A challenging aspect of LEDs is their nonlinear voltage versus current characteristic. A small change in voltage gives a very large change in current, and thus in output power. The characteristic is temperature dependent and has per device variation. Hence LED drivers are usually constant-current sources, ie they measure and attempt to regulate the current.

</comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER9> This is cool, a while back when I used to do fruit sorting machines, we used a spectrometer for working out the sugar content of fruit.

Nothing quite like setting up the machine to siphon off the biggest sweetest peach you can find at one of the largest peach farms in the world. best. peach. ever. :)

</comment><comment><USER10> If you are wanting an inexpensive spectrometer, then Public Labs has instructions on how to build one using an old DVD as a diffraction grating [https://publiclab.org/wiki/spectrometry](https://publiclab.org/wiki/spectrometry)

I got a kit as a present and really enjoyed it.

<comment><USER11> It depends on what you want this spectrometer to do. Public Lab spectrometer is interesting and cheap, but the performance is very very limited.

If you need something better you can search eBay for used (scanning) monochromators. Next step is to check Ocean Optics or Hamamatsu catalogs: they have good line of products, but those are in 1000 USD+ range.

</comment></comment><comment><USER12> Open access Nature Communications paper : [https://www.nature.com/articles/s41467-018-06773-2](https://www.nature.com/articles/s41467-018-06773-2) High-performance and scalable on-chip digital Fourier transform spectroscopy

 _Here we demonstrate a transformative on-chip digital Fourier transform spectrometer that acquires high-resolution spectra via time-domain modulation of a reconfigurable Mach-Zehnder interferometer. The device, fabricated and packaged using industry-standard silicon photonics technology, claims the multiplex advantage to dramatically boost the signal-to-noise ratio and unprecedented scalability capable of addressing exponentially increasing numbers of spectral channels._

</comment><comment><USER13> FTIR devices seem to cost around 50000 right now, would this be something that would lower that cost?

FTIRs are definitely in demand with harm reduction groups both in cities and for drug testing at music festivals. If we could get these at lower costs it would honestly save lives.

<comment><USER14> How is FTIR used for drug testing? Is it used to test for contamination based on the spectrum profile?

<comment><USER11> Peaks of each chemical is unique so you can scan database of known chemicals and compare.

You can even measure the amounts of various chemicals in solution, but that would require complex calibration. In this case you are basically writing ML system that is trying to fit various peak heights/areas to amount of compound.</comment></comment></comment>


Show HN: Medius News – A news aggregator that optimizes for neutral sources - <AUTHOR> http://www.mediusnews.com <comment><USER2> There are a few "side effects" I like about this: I do most of my casual computing on a Raspberry Pi, and this site loads fast and scrolls fast. So even if that wasn't your goal, it does seem to be rpi friendly. Very simple and uniform, with an interface that still looks good when you zoom in to 1 article per row.

The lack of competing ad scripts is refreshing - hopefully if you try to monetize this, you find a way to keep it this snappy.

Feature request: Either a config screen or a simple (hamburger style?) menu on the side to expand/contract subject sections. For example, a non-sporty fellow might rather not see all the football coverage, and lots of folks here might prefer to expand the technology, health and science sections.

Got this bookmarked and looking forward to see where this project goes.

<comment><AUTHOR> Awesome to hear how well it performs on your Raspberry Pi! This is more of a side project/portfolio piece at the moment, so I don't see ads coming anytime soon.

Having a hamburger menu to quickly navigate/toggle sections is a great idea! I'll look into that more.</comment></comment>


Ask HN: what's the easiest way to implement login using x account? - <AUTHOR>

For example, what Stack Overflow is doing: http://stackoverflow.com/users/login
ClickPass (YC 07, http://clickpass.com/) was doing this, but their site says not to develop against them atm.
JanRain does it, but costs money (http://www.janrain.com/products/engage/get-janrain-engage).
Any open source implementations or other alternatives? <comment><USER2> Janrain seems really nice. I started using it for a site I was making, but had some issues with the Rails authlogic plugin for it (this was almost a year ago though). I never sorted out the problem after a lot of debugging, and then the project ended up on my back burner, where it still lies.

It seems like one can get away with the free plan pretty well. But the real issue is that now if either you or they have downtime, you have downtime. I assume they have some good HA practices, but one of the times that I was working on debugging the issue, I was getting 500s.

An open source version, especially one that could be easily used with any language, would be awesome.

It's possible that the best way to do that would be to essentially clone Janrain open-source-ly and write libraries for that clone. That way most of the work is being done in whatever language it's implemented in, and then to make it work in a new language, you'd just write a simple library integrating with its API, rather than rewriting the whole thing.

The advantage is that you'd host it yourself, and so you can take steps to ensure that it stays up. (And at the very least, it would be hosted in the same datacenter, so unless your hosted version of JanrainClone crashes, its downtime would mostly coincide with your own downtime.)

</comment><comment><USER3> JanRain has written open source libraries for OpenID: <http://www.janrain.com/openid-enabled>

Their free version of Engage is sufficient for basic authentication. As mentioned already, your authentication system will then rely on your site, Janrain's site, and also the 3rd party site that performs the actual authentication. If you just want to quickly get going, you can use their free version of Engage with the above caveats.

If you want to not rely upon JanRain, then you can use one of the OpenID libraries out there. Integration is "relatively" simple, it should take 1 day in most cases.

However, you may want more than OpenID (Hello, Facebook Connect and Twitter's OAuth). If that is the case, then you will have to add support for those sites as well.

It would be nice if there is an open source version of Engage, but there doesn't appear to me from my searching.

</comment><comment><USER4> I used JanRain for about 9 months, first using their basic and then upgraded to their paid $10 account. The service was great, and I didn't experience any issues with them. I would recommend them if you want to get something up fast.

I moved away from them because I wanted to use it in a Facebook application to generate user accounts on the site but this wasn't possible without upgrading further. Also, 99% of my users came from Facebook or Twitter and I just didn't need the other options.

</comment><comment><USER5> Just use JanRain basic account, it's free. The only thing is you're limited to 6 providers. Check out my blog about this free implementation....... [http://jamafriend.com/blogengine.web/post/Adding-OpenId- Logi...](http://jamafriend.com/blogengine.web/post/Adding-OpenId-Login-System- Through-RPX.aspx)

</comment><comment><USER6> free: <http://code.google.com/p/openid-selector/>

i think this is what stackoverflow uses

</comment><comment><USER7> <http://www.myonelogin.com/openID.html>

</comment><comment><USER8> +1 JanRain (they do have a free account, as others have pointed out)</comment>


23andme replies to the GAO: GAO Studies Science Non-Scientifically - <AUTHOR> http://spittoon.23andme.com/2010/07/23/gao-studies-science-non-scientifically/ <comment><USER2> First, let me say that I'm very much in favor of the direction that 23andMe is headed. Personalized genetic medicine _is_ the future. Generic small molecule treatments (and by generic, I mean that they're given to patients based on the disease and not based on the patient+disease profile) have pretty much hit their limit of efficacy and biologics are a lot like supersonic airliners: they'd be great in theory if there weren't so many problems with them in practice.

I also sympathise with the way that the GAO, the FDA, and a number of other groups that have been weighing in on this issue have been lumping together 23andMe with some of the less reputable players in this burgeoning industry.

That said, I still don't agree with what 23andMe is doing. I've nearly completed a Ph.D. in computational biochemistry and have been helping my wife with her thesis in cell signaling, and the only thing I can tell you about the information contained in a genetic profile that 23andMe provides you is that you can't really tell much, if anything, from the profile that 23andMe provides you. Even supposedly straight-forward genetics like the presumably Mendelian pattern of inheritance in CFTR SNPs can get complicated fast. For example: <http://www.ncbi.nlm.nih.gov/pubmed/14966131>

Of course, the real problem with 23andMe isn't with 23andMe but with the FDA. The FDA's job, first and foremost, is to keep people safe. _IT IS NOT THE FDA's CONCERN TO SEE NEW TREATMENTS DEVELOPED!_ The result of this is that the medical community and the pharmaceutical industry are caught in a bit of a catch-22. Everyone that I've spoken too (including past CSO's of large-name pharmaceutical companies) recognizes that including genetic profiling of patients in drug trials might reveal that different people benefit from some drugs more than others, and that this is linked to genetics. In fact, you can probably recognize this yourself: When you get a headache, what do you reach for? For me, Ibuprofen does the trick, but Acetaminophen (Paracetemol) does nothing. For my wife, it's the reverse. This is almost definitely linked to genetics.

The problem is that genetic profiling for drug trials is expensive and, get this, as of yet unproven to make a difference! Therefore, even if a pharmaceutical company went to the expense of including genetic profiling in their drug trial, the FDA would reject the results based on the fact that genetic profiling is unproven. So, nobody does genetic profiling. So you can't prove the usefulness of genetic profiling. etc.

Now, you might think that 23andMe has a chance of solving this issue, by allowing people to take control of their own genetic profiling, but I think they're actually doing more harm than good. Unless you are highly trained in genetics and keep up with recent literature, you're not going to know what to do with that profile. If you bring that profile to a doctor, they will pretty much have to disregard it without a second thought (see FDA argument above). Honestly, with the current state of medical research and pharmaceutical regulation, a 23andMe profile is worth the paper you printed it on. What's worse, the more doctors get pestered with people bringing in their own profiles, the less likely they are to pay heed to any of it, and the distraction that this causes the FDA, worrying about whether they should regulate 23andMe or not, prevents the root issue from being addressed.

I liken 23andMe to Quest Diagnostics. If you've visited a doctor recently, you're probably familiar with Quest. But when was the last time you went to Quest asking for a blood test without being prompted to do so by a physician? Honestly, you'd probably learn more on your own looking at the results of a cholesterol test or CBC than by perusing your own genetic profile. Until the U.S. (or, more likely these days, the E.U.) makes a major push for research into personalized genetic medicine, 23andMe will be little more than a novelty.

<comment><USER3> >Now, you might think that 23andMe has a chance of solving this issue, by allowing people to take control of their own genetic profiling, but I think they're actually doing more harm than good.

23andMe told me that I'm a carrier for phenylketonuria. That's useful information to me, and strictly factual. The other slight-increased-risk-of- this slight-increased-risk-of-that isn't all that useful, but who cares? They give you the odds. I can't imagine what more you'd expect from them than to present current research conclusions as unbiasedly as they can.

I think you have a mistaken impression about what their product does.

<comment><USER2> > 23andMe told me that I'm a carrier for phenylketonuria. That's useful > information to me, and strictly factual.

Quick! What's your chance of passing this on to your child? If you said that it depends on the genotype of your spouse, you win! If your spouse doesn't have phenylketonuria, what's the probability? If you said 1/4, your right!

Now, let's say you've met someone and convince them to get a genetic test, and they turn out to also be a carrier, what do you do? Do you risk the 1/4 chance? One of the really interesting things about the human genome project was that the scientists involved knew that these sorts of hard questions would come up, so they really emphasized the human and counseling aspect of the research, in addition to the hard science. These are the types of people who are upset that 23andMe has mostly undone what they were attempting to do by emphasizing a holistic approach to people understanding their own genetics.

Also, I just have to point out how ironic your example is. In fact, this information is rather useless. Phenylketonuria is a relatively easily managed disease, and all children born in the U.S. (and many other countries) are already tested at birth, paid for by the government who did the studies and decided this was a good test to do. You actually didn't learn anything you wouldn't have potentially found out anyway (and at no cost to you).

<comment><USER3> >One of the really interesting things about the human genome project was that the scientists involved knew that these sorts of hard questions would come up, so they really emphasized the human and counseling aspect of the research, in addition to the hard science.

How paternalistic of them. These questions are hard because they are personal, and not the sort of thing that should be regulated.

>Now, let's say you've met someone and convince them to get a genetic test, and they turn out to also be a carrier, what do you do? Do you risk the 1/4 chance?

That's my choice. Otherwise, it wouldn't have been. Though it isn't that important for phenylketonuria, it might have been a deal-breaker if I were a carrier of sickle-cell.

You're dancing around my point here. Some of the information they provide is iron-clad binary, and can be very useful. Most people may not get more out of it than slight increases or decreases in their relative risk, but some will find out things that are life-changing. The last time 23andMe came up, one HN commentator said that he found out that he was likely to be lactose-intolerant from it, so he changed his diet and it changed his life. He had lived with the symptoms for so long that he just assumed that was how life was supposed to be.

Here's what Sergei Brin got out of it: <http://too.blogspot.com/2008/09/lrrk2.html>

I don't understand your motivation for wanting to forcibly withhold this information from people.

</comment></comment></comment></comment><comment><USER4> I'm a 23andme customer (post-DNA day) and after seeing the DNA mixup[1] and watching the youtube video released by the subcommittee on hearings and oversite[2], I am becoming increasingly weary of consumer genetic testing.

I am glad to read that 23andme support regulation, because ultimately that is what should be required. Much like the regulation that HIPAA provides, DNA information should be federally protected and regulated.

[1] [http://www.switched.com/2010/06/08/23andmes-dna-mixup- leaves...](http://www.switched.com/2010/06/08/23andmes-dna-mixup- leaves-96-customers-with-wrong-test-results/) [2] <http://bit.ly/9MrBpe>

<comment><AUTHOR> I'd prefer to see Consumer Reports handle this instead of anything like the FDA.

I'm an adult; I can decide for myself what to make of the information I obtain.

<comment><USER5> _"I'd prefer to see Consumer Reports handle this instead of anything like the FDA. I'm an adult; I can decide for myself what to make of the information I obtain."_

I realize that this isn't going to be a popular opinion around these parts, but no, you can't. Smart as you may be, you're utterly ignorant when it comes to this stuff, and you haven't got a chance of beginning to understand the intricacies that go into interpreting the data that these companies are giving you. More importantly, you don't have _time_ to understand.

I have a Ph.D. in Biochemistry, and for the most part, I couldn't tell you whether the data in a 23andMe report is meaningful or utter garbage. I perhaps have enough knowledge to go out and _find_ the necessary papers, read and interpret them in light of the literature on genomic analysis, and evaluate risks...but I wouldn't begin to have the time to do it properly for all of the data in a given report. No offense, but you haven't got a prayer. These companies could be fabricating results whole-cloth, and you'd have no way of knowing it.

Most importantly, because there's no regulation of the methods used by these companies, neither you nor I have any way of knowing what methods they're using, whether the techniques are precise or accurate, or even if the labwork is done by skilled technicians in a sterile environment. Without these assurances, even if you _could_ understand the data, you would have no guarantee that the data was even gathered correctly.

There are some domains where expertise matters more than anything else, and no amount of brainpower makes up for the instincts provided by years of training and experience. This is one such area.

<comment><USER3> And for some reason you think this is different from any other field? I don't have a prayer when I walk into a car dealership of figuring out whether a car I'm thinking of buying will function properly. There are too many parts for me to conceivably understand. It's very complicated.

Thankfully, there are many experts and expert organizations that I trust to make this determination for me. I defer to their authority.

How is this any different? The market seems to handle this just fine.

<comment><USER2> > And for some reason you think this is different from any other field?

Yes, actually. If we must really flog a tortured analogy: This is not like going to your local mechanic friend and asking for car buying advice. It's more like this guy named Karl Benz comes and tells you he's got a great new invention called the internal combustion engine and you should definitely buy it. So you go to your friend the steam engine mechanic and ask him for advice. Sure, he understands the principles, maybe, but this is something completely new!

If you must appeal to authority, consider you have two experts in this thread telling you that even they think the topic is too complex to draw useful conclusions. If you don't trust random people on the internet (not that I blame you), then go to the source. From the article:

 _There are valid scientific reasons for different estimates from different companies, such as: companies employ slightly different statistical models for making risk estimates; companies establish different criteria for the inclusion of associations in their reports; new associations are being discovered at a faster rate than companies' development cycles; companies may test for an imperfectly overlapping set of genetic variants for reasons including the ability of different genotyping technologies to assay certain variants._

To be clear, this is not a case of Car and Driver favoring German engineering but JD Powers always skewing towards American manufacturers (completely contrived example, BTW). In this case the statistical models _are_ the science, not just some interpretation of the science. This field is young. Too young. This money and effort would be better spent on basic research.

> The market seems to handle this just fine.

No, the _market_ gives us homeopathy and snake-oil salesmen. Humans, especially when confronted with areas in which they are not knowledgeable, can be surprisingly irrational!

<comment><USER3> >To be clear, this is not a case of Car and Driver favoring German engineering but JD Powers always skewing towards American manufacturers (completely contrived example, BTW). In this case the statistical models are the science, not just some interpretation of the science.

Statistical models that are _far far_ more suspect drive decisions in areas of all our lives that have far more material effect than this.

>This field is young. Too young. This money and effort would be better spent on basic research.

Whose money? Mine? They aren't a non-profit.

>Humans, especially when confronted with areas in which they are not knowledgeable, can be surprisingly irrational!

Isn't that their right?

</comment></comment></comment></comment></comment></comment><comment><USER6> I definitely treated my 23andme profile as a piece of entertainment, and don't think people should take it too seriously. I found someone who may be a distant cousin, and a few interesting traits, so I'd consider it a slightly more informed (and similarly priced) palm reading.

I'm really glad I approached it like that, because I was one of the people who were in the DNA mixup. They told me I was a Tay-Sachs[1] carrier, which has a potentially vital impact on my relationship decisions (and was also a bit concerning given that neither of my parents are carriers). I'm really glad they caught and fixed it, and that I didn't take it seriously enough to lose sleep over the results.

[1] - <http://en.wikipedia.org/wiki/Tay%E2%80%93Sachs_disease>

</comment><comment><USER7> 23andme uses GWAS SNPs, about 1 million of them. You have a 3 billion base pair haploid genotype, so they sample ~1/3000 base pairs. What does this mean?

First, most of the SNPs are noncoding, found not in exons but in introns and intergenic space. Still, you can't dismiss these; some are causal for major gene expression changes (my lab has articles set to be published next week on this topic; more details then).

Second, the fact that you're only covering 1/3000 nucleotides tells you that there's no way you can fully specify someone's genetic risk with this data, ever. There is a debate in the community right now about whether common variants (which are on 23andme type chips) or rare variants contribute most of the genetic variability. I think it's clear that common variants are winning this game — but this is on a population level! On an individual level, I don't think I'd ever be comfortable telling someone their risk of X with just GWAS data. For the population, their rare/private mutation in Gene Y has little impact, perhaps, but for try telling that to the 5 people with the Gene Y mutation who will die by age 20. (Extreme hypothetical to try to drive home the broader point.)

Let's also not forget that phenotype is a computed expression of genotype+environment. If your genetic risk score from 23andme says you are at high risk of heart disease, yet your grandparents on both sides are 100 and healthy and your LDL-C is 60, should you really be concerned?

<comment><USER8> If you know somebody's medical history and 23andMe results, can you say more things about them at any given level of confidence than you could with just zis medical history?

<comment><USER7> Not really, at least not for cholesterol; not right now. [1] Hopefully in the next few years, yes. But genetic data, since our knowledge is limited, does not increase risk discrimination beyond family history. It does, modestly, increase risk classification.

 _Edit_ \- Link didn't work initially. I was not trying to just snarkily link to pubmed - I had a specific paper in mind. Sorry!

[1] <http://www.ncbi.nlm.nih.gov/pubmed/18354102>

</comment></comment></comment><comment><USER9> 23andme engage in infotainment with an additional helping of candidates disease thrown in for each and every one of their customers. GPs are already amongst the most overworked people on the planet, the last thing they need is a herd of people with waving print-outs they (the people) don't understand in support of yet another round of imaginary diseases.

It's the perfect product for the hypochondriac.</comment>


The Zimbu programming language - <AUTHOR> http://www.zimbu.org/ <comment><USER2> Simplicity is the most difficult thing to engineer. I think this is a good example of that.

There are so many symbols, special cases, if ands and buts. When do things get $? When do things get ;? When do things get capitalized?

Making words capitalized shouldn't be needed. If your language is being used and the syntax of the language encompases more of then the meaning you are attemping to convey then you've poorly designed the language.

I think python is a good example of how to be simple. There are (), :, and whitespace. You have if, elif, def, and class (I'm not counting pass). The syntax and semantics are simple (although I don't like the reliance of whitespace as a block segregation technique).

It's hard to see the logic under the language in Zimbu. In python the logic is the language. When you see really pythonic code, the code are just expressing the ideas in a simple way using the language's keywords is a way to make it even simpler. For example

       for account in database(outstanding_bill=True):
          print(account.name)

As you can see, there is a syntax to this but it reads the same way as the program is meant to run. "For every account found in database that has outstanding_bills print the account name". The syntax is part of the meaning in this. In Zimbu..... I think work needs to be done. I'm just not getting it I don't think.

<comment><USER3>
      > There are (), :, and whitespace. You have if, elif, def,
      > and class (I'm not counting pass).

I'm a big fan of Python, but I'm not sure what you're trying to say here. There are way, way more than four reserved words in Python (including ones like `False` which aren't immediately obvious as keywords due to the different capitalization). There are also way more symbols used than those you list: [] for lists/comprehensions, {} for dicts/sets, single/double asterisks for unpacking, @ for decorators, all the familiar symbolic bitwise operators that C has, \ for line continuations, ; for multiple statements on the same line, etc.

<comment><USER2> I meant to start. They may be pervasive throught the community but you don't need to know about them as you may not even see them for the first little while.

Decerators are something I am also not going to count as they aren't going to be the first thing, or even one of the most basic things, you will encounter. It's like counting "register" as a C keyword. It is buy you're likely to be able to go an entire lifetime without seeing it in a codebase.

In Python 2 True and False are not keywords. You can reassign their values. But I see what you mean and yes my list isn't comprehensive. It's an example.

The list would probably be more like (), {}, [], <, >, !, =, \, ',', :, ;, *, and @. For a basic programming experiance you you're probably not going to see or even care about a most of the nitty and gritty ones you describe in the contexts as you describe. You could even avoid using [] and {} by just writing "list()" and "dict()".

Basically I agree but again the point still stands. Python has far less clutter then what is demonstrated here. While python may have many really cool magic single-character operators most of them aren't really in your face. "!=" may be the most in your face one along side ":". In total the clutter is just not dumped all over your code or at least it doesn't seem like it is.

<comment><USER4> Sounds like what you want is clojure. Once you know what ()[]{}#'@ mean, you only need to basically understand the couple dozen "stdlib" functions and you're good to go.

<comment><USER5> Or a more pure, simpler LISP like a member of the Scheme family.

<comment><USER4> Academically sure, in the real world I think Clojure has more advantages in terms of tooling, evolution potential and community/ecosystem. Aside from the "nitty gritty" aspects related to being hosted on the jvm I find clj to be the superlative of simpleness.

</comment></comment></comment></comment></comment></comment><comment><USER6> The unbalanced brace is a disturbing choice. Why not go either full braces (C, Java) or full space significant (Python)?

Fully capitalized keywords make my carpal tunnel syndrome self recoil. Probably inspired from Modula 2 or BASIC?

At least I give the creator credit for picking a name that will be easy to search :-)

<comment><USER7> Really. I thought about that when I saw Ruby 10 years ago and didn't like to type end to close blocks. However

1\. Space { } are three characters like e n d and using the idiomatic do when needed is only one more character (and the editor types end for me)

2\. It looks better than an orphaned }

Other solutions:

1) Erlang has , instead of ; and . instead of } A long list of .s is not idiomatic (doesn't happen) but it would be pointless (pun intended) in a language where it does.

2) swallow the pill and use both braces.

Going the Python way (I suggest not using the : ) would be a radical change.

I also don't like the shouted COBOLish keywords. Were they necessary?

Thumbs up for the new regexp switch statement.

<comment><USER6> I prefer the braces over END not because of the character count but because my brain can't avoid reading "end" when I read the code, while closing braces don't cause a word to pronounced in my mind.

Also, just like you, I find that closing cascade of ENDs in nested statements is visual noise.

<comment><USER8> That is an interesting reason. It may seem small, but I think it is a perfectly valid point.

I'm of the opposite opinion, but for similar reasons. I type using the Dvorak layout, and typing curly braces is a bigger pain in the nipple than typing "end." For me, "end" also makes reading code blocks easier, because it looks like the end of a paragraph. In other words, the fact that it does read like a sentence makes it stand out more for me than curly-braces do; especially when coders, who obviously have no style, put the opening curly-brace on the same line as the function definition or control loop. Hehe.

I think it is interesting to contemplate the subjective aspects of languages and syntax preferences. Probably not productive, but interesting none the less.

<comment><USER7> Speaking of subjectivity,

        if (condition) {
          ...
        }

is the only readable option :-)

        if (condition)
        {
           ...
        }

drowns the code in a sea of (subjective) noise.

There are many other variants [https://en.wikipedia.org/wiki/Indent_style#Placement_of_brac...](https://en.wikipedia.org/wiki/Indent_style#Placement_of_braces) and wars have been fought over them. There are pros and cons for most of them. My tradeoff is the K&R style.

I think editors can automatically convert among styles nowadays. The only thing that matters is consistency.

</comment></comment></comment></comment></comment><comment><USER9> This is by Bram Moolenaar, author of Vim: [http://www.zimbu.org/Home/about- zimbu](http://www.zimbu.org/Home/about-zimbu)

<comment><USER10> ...Well, that explains its quirks.

</comment></comment><comment><USER11> With the orphaned closed curly braces and ALL CAPS keywords, it's like this language was created to make programmers twitch uncontrollably. The only thing he could do to make this more off-putting would be to mandate some kind of crazy double-tab indentation scheme. :-p

</comment><comment><USER12> The language does make a strong case for "code is read more than it is written", so it does make it easier/cleaner to quickly see the keywords, etc.

However, 2 improvements that could be made are:

1) being able to write the code as normal (if instead of IF, else instead of ELSE) and then using something like:

zu.fmt

To format the code (best of both worlds?)

2) Dropping the ending-brace. It will just lead to many errors that could otherwise be avoided

\---

Also, if you are interested in a similar language, maybe Nim might be worth a look:

[http://nim-lang.org/](http://nim-lang.org/)

<comment><USER10> Nim... urgh. It's a bit quirky, bit kind of nice.

The really ugly bit is the macro system: Nim macros are awful.

<comment><USER13> > The really ugly bit is the macro system: Nim macros are awful.

If I had a penny for every time I see you say that on HN... :)

In any case, I disagree with you. Nim macros are really easy to work with, the AST construction is a bit verbose but that can be easily remedied by writing functions which make the construction easier.

<comment><USER10> I _do_ say it a lot. But it _is_ true.

>that can be easily remedied by writing functions which make the construction easier.

That can only really go so far...

</comment></comment></comment></comment><comment><USER14> Someone else has already observed that the motivation pretty much exactly matches Nim's. However, if you just decide that you don't need a compile to C language, Go or even Haskell matches the criteria...

<comment><USER15> or rust

<comment><USER16> or Chicken Scheme (and many of its friends)

</comment></comment></comment><comment><USER17> How old is this? The pitch reads exactly like a description of the Nim language, and then it claims no such language exists..

<comment><USER18> Site activity on the bottom of the page goes back to February 12, 2009

</comment></comment><comment><USER19> I see someone misses BASIC's all-caps keywords.

<comment><USER20> It does make them easy to spot, though.

<comment><USER21> So does syntax highlighting. For me, typing with caps lock has always felt awkward and unnecessary.

</comment></comment></comment><comment><USER22> The previous discussion[1] made a good case for Lua.

Shipping Lua as a first-class alternative to VimL also happens to be the primary goal for Neovim in 2017.

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

</comment><comment><USER23> What bothers me most about this language isn't the orphaned braces, or the case sensitive keywords or any of the other quirky decisions.

What bothers me most is the monkey mascot. What relevance does a monkey have to this programming language? Is the idea that it's so simple a monkey could do it? Is the monkey Zimbu? It isn't explained anywhere, and I'm betting it's just some random animal they chose without any thought because it's cute.

At least the Go gopher makes a little bit of sense (GOpher). This monkey seems like a completely nonsensical choice though.

<comment><USER24> _What relevance does a monkey have to this programming language? Is the idea that it 's so simple a monkey could do it?_

Possibly:

[http://dilbert.com/search_results?terms=Zimbu+The+Monkey](http://dilbert.com/search_results?terms=Zimbu+The+Monkey)

</comment></comment><comment><USER25> The closing curly braces without opening ones make me go full OCD.

</comment><comment><USER26> As an aside, and from a non-CS person's perspective, what is the need for more programming languages? I find at least one new one every few days on HN. I've been learning Python since late 2015 and I find just mastering one language (and its libraries) overwhelming.

So, what is the incremental advantage to be gained by learning yet another new language?

</comment><comment><USER27> >> No existing language really meets these demands, so let's create a new one that does!

What about lazarus/fpc?

I could easily drop a memo on a form and start giving it highlighting rules. I could easily connect to postgres and bring up a form with a grid and export it to excel. The pascal language itself is simple and works on multiple platforms.

</comment><comment><USER28>
        Animal.C a = NEW() # a can only be an instance of Animal, not Fish.

LSP says, "wat?" ;)

Although that only seems to be mentioned in the "Highlights" section and not in the language specification, so it's unclear if it's implemented...

<comment><USER29> You have the same in Ada, where Animal denotes the exact type, and Animal'Class the class-wide type (type and any subtype).

[https://en.wikibooks.org/wiki/Ada_Programming/Object_Orienta...](https://en.wikibooks.org/wiki/Ada_Programming/Object_Orientation#Class- wide_and_specific_types)

<comment><USER28> The Ada variant seems to achieve a clearer goal: specify exactly where LSP / subtyping is desired, leaving the default behavior of un-decorated types alone. Explicit opt- _out_ as in Zimbu seems odd.

</comment></comment></comment><comment><USER6> Using capitalized keywords in order to make it easy to add keywords in the future reveals the author is probably not very familiar with the science of parsing. It's quite possible to introduce new keywords in future versions of the language and make sure your compiler won't choke simply because the word is being used as a variable name instead of an identifier.

</comment><comment><USER30> Why is IO a keyword?</comment>


The 100 Best Business Books of All Time - <AUTHOR> http://100bestbiz.com/more-on-the-100-best/ <comment><USER2> I think <http://www.netmba.com> is a good place to start

</comment><comment><USER3> I'm actually attempting to read all 100 in a year. I've read 13 in just under a month.

So far I've enjoyed everything. It's not that bad if you get rid of TV.

I would say that the summaries/reviews in the book are just that, short/quick summaries or brief reviews. I'm sure with some of the books it would suffice to just read the review in "100 best," but I've really enjoyed a good handful of them so far.

The actual book is a great supplement to reading them.

So far I've only hit one that bored me to death (Innovator's Dilemma)

For example - Chasing The Light - Amazing Book. A Whack on the Side of the Head - Loved it. Purple Cow - Classic.

<http://noahfleming.com/blog/100-business-books>

</comment><comment><USER4> Seems kind of light on the financial / accounting / capital allocation side of things.

Graham and Rockefeller's biographies do expose readers to these topics, but adding books like How to Read a Financial Report and the Accounting Game would be helpful to any entrepreneur.

<comment><USER5> Financial Intelligence is the best book we found for teaching managers (or anyone really) accounting without all the crazy talk of credits and debits. But I am going to definitely check out both of the titles you mention.

</comment></comment><comment><USER6> This isn't on the list, but I highly recommend reading 'The Leader Who Had No Title' by Robin Sharma. It's a leadership book that will keep you grounded while in pursuit of success/wealth.

Worth the read!

</comment><comment><USER7> Art of War? Anyone who posts an "of all time" list should be required to pick something at least a millenium old.

<comment><USER5> In The 100 Best, we recommend another 200 or so other books through sidebars and additional recommendations at the end of the summaries. Art of War appears on page 199 with The Price, The Origin of Species, and The Wealth of Nations. We kept the primary list to books that had been written in the last 100 years.

</comment></comment><comment><USER8> ok first of all 100 is a LOT. that will take you 4 years if you really work hard at reading all of those.

second, why isn't 4 steps to the epiphany on there?

<comment><USER9> That's why they made the book with summaries, so you can read the summaries and decide which books you want to read in full.

</comment></comment><comment><USER10> Where's Rework?

<comment><USER5> The book came out in 2009 and was written in 2007. Most books were at least five years ago. Our only exception was Made to Stick by Chip Heath and Dan Heath.</comment></comment>


Ask HN: Do you use windows for development? - <AUTHOR> Is it still part of your development workflow? <comment><USER2> Noooo!

Dev desktop runs Ubuntu, MacBook Pro with OS X when on the road. Deploy everything as WebApps on hosted servers/services on both AWS and Google Cloud.

Before cloud hosting, I used to roll-in servers running HP-UX and AIX into clients' data centers. My support costs were a tiny fraction of those of my competitors using Windows server, etc.

</comment><comment><USER3> Yes. I develop on both Ubuntu and Windows.

I mostly do Node.js and Android development so I can work exclusively in Linux but some of my customers install my software on Windows. Always good to see whether everything works on Windows.

<comment><AUTHOR> How do switch between both? Do you dual-boot or use VM or something similar?

</comment></comment><comment><USER4> Yes. I can iterate quickly. If the end product is embedded, I port it to Linux once I've got the algorithms working.

</comment><comment><USER5> Sadly yes. Too many apps still in old .net pre-core versions.</comment>