Introducing the timechain – a DAC based on time-lock encryption - <AUTHOR> http://roberts.pm/timechain

<comment><USER2> Barring burst growth in _serial_ computing power (the way I understand, a time-lock cannot be broken faster by throwing more parallel cores at it), I think this will work great!

<comment><USER3> One of the nice things about my hash time-lock construction is that besides the general slowdown of serial computing power growth, speeding up SHA-256 has been _intensively_ incentivized by Bitcoin mining over the past 6 years in addition to crypto research interest in faster primitives; so it seems like one could have very high confidence that there will be no new breakthroughs in optimizing SHA-256 over the next few years.

(What's more concerning is questions about whether anyone would bother investing the computing power to unlock the crypto, since while it's bad if a time-lock can be opened early, it's also probably not good if it opens years late. For example, the original successive-squaring timelocks released back in the '90s are not going to open anywhere remotely on time because they didn't foresee the serial slowdown happening when it did and because I don't think anyone is trying to open them at all.)

</comment></comment><comment><USER4> I'm surprised there was no mention of Rivest's time-lock puzzles. They're a simple construction for time-lock puzzles that can be generated much more quickly than they can be solved.</comment>


TinyEMU, a RISC-V/i486 VM for Linux in the Browser - <AUTHOR> https://bellard.org/tinyemu/ <comment><USER2> Interestingly the VM seems to have internet access via a DigitalOcean instance:

> Access to Internet is possible inside the emulator. It uses the websocket > VPN offered by Benjamin Burns (see his blog[0]). The bandwidth is capped to > 40 kB/s and at most two connections are allowed per public IP address. > Please don't abuse the service.

[0] [http://www.benjamincburns.com/2013/11/10/jor1k-ethmac- suppor...](http://www.benjamincburns.com/2013/11/10/jor1k-ethmac-support.html)

<comment><USER3> Why do you even need the additional layer of redirection when most (port 80 tcp) traffic can be done straight from the browser?

<comment><USER2> Most port 80 TCP traffic _can 't_ be done straight from the browser. E.g. it won't let you write arbitrary headers.

Cross-domain requests won't work for the majority of sites.

And non-HTTP requests can't be done at all from the browser, it would be a pretty limited "network interface" if all it could do was call out to XMLHTTPRequest.

</comment></comment></comment><comment><USER4> This guy is also responsible for Qemu and FFMPEG. [https://bellard.org/](https://bellard.org/)

</comment><comment><USER5> I love the projects this person works on, usually full or close to full implementations in very small amounts of code.

The one I first learned about was Tiny C Compiler. It is discontinued now, but it is an about 100K compiler,linker,assembler that can compile many programs like the links browser. [https://bellard.org/tcc/](https://bellard.org/tcc/)

If that is too large, you can go with the project that inspired it, the Obfuscated Tiny C Compiler, a 2048 byte compiler that supports a subset of C. [https://bellard.org/otcc/](https://bellard.org/otcc/)

All these projects are great for learning from.

<comment><USER6> > It is discontinued now

TinyCC is still being developed: [https://repo.or.cz/w/tinycc.git](https://repo.or.cz/w/tinycc.git)

</comment></comment><comment><USER7> The fact that I was able just now to run an X session on a RISC-V VM & direct the Dillio browser to Google - I did not even know these things were possible today. Pretty excited.

</comment><comment><USER8> His online scientific calculator is great!

[http://numcalc.com/](http://numcalc.com/)

</comment><comment><USER6> I don't see anything about running this in the browser on that page. Is there a place to demo this somewhere?

<comment><USER5> The phrases "Can be used online" and "Javascript version running Linux and Windows 2000. " link to:

[https://bellard.org/jslinux/](https://bellard.org/jslinux/)

You can then click on the "Startup link" labeled "click here" for the OS and CPU architecture you want to try out.

</comment></comment><comment><USER9> For some reason x86 emulator is not open-source. If you download source, x86 is just stubbed out.

<comment><USER5> For the JSlinux one, from the wayback machine:

>In the technical notes, an archive is given which explains how to build the various binary images. The readable source code of the JS PC emulator itself is not yet available. At this point, any mirroring or redistribution of the code needs my explicit permission.

And you can find the stuff referred to here:

[http://web.archive.org/web/20141219111736/http://bellard.org...](http://web.archive.org/web/20141219111736/http://bellard.org/jslinux/tech.html)

\</comment></comment><comment>---

For tinyemu, my understanding is most of the code is in x86_machine.c , the actual cpu stuff is provided by kvm, the readme states:

>5) x86 emulator A small x86 emulator is included. It is not really an emulator because it uses the Linux KVM API to run the x86 code at near native performance.

> The x86 emulator uses the same set of VirtIO devices as the RISCV emulator > and is able to run many operating systems.

>The x86 emulator accepts a Linux kernel image (bzImage). No BIOS image is necessary.

> The x86 emulator comes from my JS/Linux project (2011) which was one of the > first emulator running Linux fully implemented in Javascript. It is provided > to allow easy access to the x86 images hosted at > [https://bellard.org/jslinux](https://bellard.org/jslinux)</comment>


Show HN: Automatically Index the Top 20 Cryptocurrencies by Market Cap - <AUTHOR> https://www.hodlbot.io <comment><USER2>
        I still don't trust HodlBot with my API Keys

That's really a major issue that should be your main focus. Can't wait to see the Electron app.

<comment><USER3> you can use [https://github.com/salimane/cryptodiversify](https://github.com/salimane/cryptodiversify) today and it is open source

<comment><AUTHOR> That's really funny. I went to the github repo and saw my words copied and pasted from my blog into the description.

I'm not upset though, I think this is actually pretty cool. Good job for putting this together. I'm happy with people using this if they want to run it locally.

</comment></comment></comment><comment><AUTHOR> _TLDR: Got sick of manually managing a cryptocurrency index, made an algo bot that automatically does it for you_

Over the Christmas break I realized I was spending close to 5 hours a month manually rebalancing my portfolio of ~20 cryptocurrencies weighted by market cap.

I got sick of that pretty quickly so I decided to make a bot that uses Binance's API to automatically handle that. For the memes, it's called HodlBot.

A few months later, I'm releasing the hosted version of the bot. Now anyone can put their trade-only API keys into HodlBot, and it will automatically trade into the top 20 cryptos. It will also handle monthly rebalancing automatically.

 _What does the algorithm do?_

The algorithm take the top 20 coins and assign each coin a % allocation based on their weighted market capitalization.

Then it caps every coin to be at most 10% of the total portfolio value. Anything above 10% gets redistributed to all the coins below by weighted market capitalization until the entire sum of the portfolio adds up to 100%.

 _What do I need to get started?_

       1.Binance Account

       2.Binance Trade-only API Keys

       3.$200 in cryptocurrencies

_How much are Binance transaction fees on rebalancing?_

I simulated monthly rebalancing on a 3 year period, and found that the average transaction fees were 0.26%.

This can be higher or lower based on how volatile the market is in the future. The theoretical max is 1.2% (if every coin in the top 20 turned over every month).

 _How much does it cost?_

For the first month it's $1. Afterwards it's $10 per month. No % fees.

 _How can I trust HodlBot with my API keys?_

We encrypt the keys on our end. Also we don't require withdrawal permissions, just trade-only.

 _I still don't trust HodlBot with my API Keys_

In the next month we're releasing a version of the app that never stores API keys server-side and only executes trades in the browser. After that, we'll be releasing an electron app so you can store your API keys on your local computer.

 _How is this different than projects like Crypto20?_

Users hold their own assets as opposed to a tokenized guarantee of some underlying assets. Tokenized assets like C20 often times trade above and below the net asset value of the assets they claim to hold. In my opinion, this adds a layer of speculation and complexity on top of the index that makes it marginally worse than holding the assets yourself.

 _How do I report tax on HodlBot trades?_

Export your Binance transactions as a csv. Plug it into a tool like cointracking.info and get a tax-friendly report.

 _More Info:_

I dig into the portfolio construction and share the algorithm in this blog I wrote here:

[https://medium.com/@AnthonytXie/hodlbot-cryptocurrency- inves...](https://medium.com/@AnthonytXie/hodlbot-cryptocurrency-investing-on- autopilot-dce2e4c9a7f7)</comment>


It's 2020, and I'm Still Getting Plain Text Credentials via Email - <AUTHOR> https://garrettyamada.com/its-2020-and-im-still-getting-plain-text-credentials-via-email/ <comment><USER2> Add to [https://plaintextoffenders.com/](https://plaintextoffenders.com/)</comment>


An Oral History of LimeWire - <AUTHOR> https://melmagazine.com/en-us/story/an-oral-history-of-limewire-the-little-app-that-changed-the-music-industry-forever <comment><USER2> I took the office pictures that somehow found their way into the article.

I thought LimeWire's efforts to build a music store were probably some of the less technically interesting things that went on there, and there's tons of interesting technical fodder, such as the P2P LimeWire update mechanism where the lead dev would sign an update, update his local LimeWire, join the network, and the update would spread virally. (and how they very nearly lost control of the network due to it) Or that LimeWire was ostensibly decentralized, but ran a set of centralized UDP host caches so that you could actually _find_ other peers when you joined the network.

<comment><USER3> > _Photos courtesy Rochelle DiRe_

I take you are not Mrs DiRe.

<comment><USER2> No, I don't remember specifically but I likely shared them with a bunch of people and after all we _were_ LimeWire...

</comment></comment></comment><comment><USER4> And everyone wonders why we illegally downloaded so much music back then...

From the article: _' The fact that users would "own" songs was the deal- breaker for a lot of the dinosaur record labels. I remember one meeting with a music label I won't name, where the exec in the room basically told us, "If you listen to a Madonna song, I want you to pay us for that privilege. You never own music, you simply buy a license to consume that music at that moment. Next year, when you want to listen to that same song, I want you to pay us again. Thirty years from now, when your grandchildren want to listen to that Madonna song, I want them to pay us. You will never own this music, you only buy a temporary right to listen to that music at that moment, nothing more."'_

</comment><comment><USER5> The case from 2010 would surely make for a fascinating retrospective today. I'd wager it hasn't aged well.

</comment><comment><USER6> Why was it LimeWire, and not KaZaA (which had supernodes), or AudioGalaxy (which used the browser as UI), or SoulSeek (which I used; and had an amazing community). Not to mention eDonkey/eMule/DCPP and a whole slew more, such as BitTorrent. Or how about Usenet?

</comment><comment><USER7> i would kill for that jacket

<comment><USER6> Nowadays you can design such online, by just uploading a picture or two. At least it is like that with t-shirts. Not sure about jackets specifically.

<comment><USER2> The jackets have the letters sewn on rather than printed on, but I think the person who ordered them just said "give me whatever green letters you have" which was why they weren't on brand, and also part of the charm.</comment></comment></comment>


A Shallow Introduction to the K Programming Language (2002) - <AUTHOR> https://web.archive.org/web/20070519112242/http://www.kuro5hin.org/story/2002/11/14/22741/791 <comment><USER3> Note this is about k2; the current production version is k4 (from 2006 or so), and the current prototype is k9/shakti (There was now k8 afaik - possibly to avoid k8s mixup? but there were k5, k6 and k7 protoypes).

Compared to k2, modern k9 adds a lot of atomic data type (integer bit sizes up to 128; 32 bit floats, time and date, uuids, ...); adds dictionaries as a first-class compound data type (K2 had extremely limited dictionaries); rolls the database into the langauge (k2 had it as a library+app), adds a lot of connectivity (web server and client including websockets), threads, various forms of multiprocessing

and drops the native GUI.

</comment><comment><USER4> > K also has a the concept of dependencies and triggers. They are used for > efficient, demand-based calculation of data and executing callback code > whenever a value is changes (this is how the timer system in K works). K > will keep track of out of date dependencies for you and only do the minimal > amount of work necessary to update values.

This seems powerful. Is "doing the minimal amount of work" provably true, or is this just a way of saying that it's usually fast?

For example, let's say that I have a list of numbers that I have sorted using bubble sort. Now I change one of the numbers. Would the update be O(log N)?

> K has a unique, declarative GUI subsystem that is based around the K tree > and triggers. It takes a minimal amount of work to put a GUI on your > application. K takes the approach that you show variables and changes made > to that variable on the screen are immediately reflected in the program > without any work by you.

This sounds like Svelte avant la lettre. I'm really curious how the updates are performed.

<comment><USER3> > This seems powerful. Is "doing the minimal amount of work" provably true, or > is this just a way of saying that it's usually fast?

It is powerful, it's not provably true (or even generally true ...)

"Dependencies" are Excel-style recomputation. The code c::a+b says (1) that c depends on the value of a and the value of b, and that (2) whenever you evaluate c, if 'a' or 'b' has changed since the last evaluation, you re- evaluate the expression and assign it to c; otherwise return the cached value. So, multiple changes to a or b will not trigger recomputation - only the eventual use of C; However, it's possible that 'a' is a vector of length 1,000,000 and so is b, and only one element in a was changed - K would still do a million addition operations.

"Triggers" work the other way arround: You used to set a trigger on 'a' by assigning a trigger function a..t:{[d,i] ...} which would receive as argument the post-assignment value 'd' and the indexes assigned 'i'; You could use these to do a minimal update of whatever logically depends on a; However, the triggers DO fire on every change unlike dependencies.

> For example, let's say that I have a list of numbers that I have sorted > using bubble sort. Now I change one of the numbers. Would the update be > O(log N)?

I think there is no way to guarantee O(log n) anyway in this case - change the first element to be in the middle - requires at least O(n) changes on either a sequential or singly/doubly linked list. But assuming you're talking about say, a heap structure - the answer would be "No" for a dependency, and "If you implement it yourself" for a trigger.

> This sounds like Svelte avant la lettre. I'm really curious how the updates > are performed.

Sort of. It was a native GUI, incredibly fast, and incredibly bare bones - <USER2> was eventually dropped because all the customers were making web front ends anyway.

Being a native GUI, I suspect (but don't know) it was using the triggers to mark damage regions and let the windowing system take over from there.

</comment></comment><comment><USER5> I had great feels just now when I looked at this page. I had forgotten kuro5hin and it came rushing back.

There were lots of good articles on that site...

<comment><AUTHOR> Weren't there? There really hasn't been as interesting a site since.

<comment><USER6> It was the best. RIP kuro5hin.

</comment></comment></comment><comment><USER7> K is the bee's knees! I'm convinced if we all just used k for all of our software, programming would be a much nicer endeavor. And as a corollary, programs would be a lot nicer, faster, and usable. The status quo of terrible performance, massive codebases, and staggering complexity is a sad, self- inflicted, and unnecessary state of affairs.

<comment><USER8> I'm an avid user of k myself, but let's not pretend that k doesn't posses numerous issues and questionable design decisions. As is, the language is well suited for some tasks (e.g. processing timeseries data) , but certainly not all. The lack of modules as a first class feature makes it difficult to design large k projects, and hurts the discoverability of community made modules. A related issue is that namespaces/contexts can't be nested. Another thing that always feels like a thorn in my side when I'm working with k is the type system. Dealing with enums and anymaps is a nightmare, and the dynamic type system with no type hints makes creating and using k APIs difficult. I could go on, but I'd rather not stay up enumerating what I believe the bad parts of k are.

I believe that the ideas in k can be built upon into something that would be more useful as a general purpose programming language, but for now most of the benefits that k has to offer come in the form of introducing developers to vector languages. The ease with which functions can be composed, projected, and applied to vectors and tables in k is remarkable. For this reason, and the many other benefits of k, I try to get my programmer friends to try it out. I honestly believe learning it makes one a better programmer.

<comment><AUTHOR> _The lack of modules as a first class feature [...] hurts the discoverability of community made modules. A related issue is that namespaces /contexts can't be nested. Another thing that always feels like a thorn in my side when I'm working with k is the type system._

All of these read more like benefits than drawbacks, speaking for myself.

<comment><USER9> How do you organize complex programs?

<comment><AUTHOR> Good question!

You're generally quick to ask questions in any threads of any APL variant, so I'll answer for both it and k:

Workspaces are the answer for APL. This one is generally more-agreeable to your average person.

Here's a quick explainer of them, from a now-dead implementation:

[http://www.microapl.com/apl/apl_concepts_chapter2.html](http://www.microapl.com/apl/apl_concepts_chapter2.html)

However, the mindset for k doesn't really align with 'complex programs': simplicity is generally more useful than complexity, and it's not like there's a difference in how much you can get done with either. Consider this two-page IM implementation:

[http://nsl.com/papers/instant.htm](http://nsl.com/papers/instant.htm)

Now, it's obviously just a silly demo, but in how many other languages could you get a graphical client and server in two pages of code? (Alternatively, in five lines but not graphical: [http://www.kparc.com/$/chat.k](http://www.kparc.com/$/chat.k) )

Or a graphical spreadsheet program in one:

[http://nsl.com/k/s/s.k](http://nsl.com/k/s/s.k)

I'm not trying to imply that these are particularly-complex programs, but I'd argue that in most cases, trying to organize programs more than what's obvious (generally a directory) just makes them more complex for no benefit. This goes for many languages, not just k.

Consider Apter's SLACK, a SASL-like (direct Haskell/Miranda precursor) functional (k) programming language, written in k:

[http://www.nsl.com/k/slack/](http://www.nsl.com/k/slack/)

You'll notice that it's pretty complex as far as these things go, but the organization of it is far less complex than most programs of a similar level of complexity. I'd argue that it actually works to the benefit of the reader, though I can see how you might disagree.

<comment><USER9> To be clear, I'm not sure I could ever call an inability to write complex programs a feature, but I do recognize that there are many useful languages with this property; Bash comes to mind. Thanks for the links, by the way; I am sure I'll get a kick out of them when I eventually do know how to read k ;)

<comment><AUTHOR> It's not an _inability_. It's just that there's no reason for complexity.

C++, for example, is a language built around managing complexity. k, on the other hand, is a language built around _avoiding_ complexity. SLACK is an actual language! It does all of the things you really need an actual language to do! And yet the implementation's not particularly complex.

bash isn't really at all similar; bash is actually _more_ like Swift or Javascript than k is like bash. bash is for _extremely_ complex programs: programs that are other programs taped together.

k takes the reverse position: there's absolutely no reason you should ever, ever, _ever_ create something complex if a simple solution will do.

If you can create a programming language, an operating system, a windowing system, a database that can handle millions of terabytes of data without flinching, etc. all without complexity, why would you opt for the more-complex solution?

Complexity kills manageability, clarity & fun. Simplicity allows you to do the same things, faster, and without sacrifices.

EDIT:

In some ways, you can consider this very similar to Chuck Moore's philosophy on programming, although taking a different approach to it. I'm paraphrasing here, so forgive me if I get the quote wrong, but something along the lines of 'FORTH will do anything you could possibly want, but it won't do everything'.

If you accept the premise that a language shouldn't be infinite, which isn't particularly controversial[1], it becomes much less of a leap to think, "Wait, why not allow the programmer to expand where they need, and just not throw in what they don't? It'll take less overall cognitive load!"

Now, that's why FORTH is pretty interesting as a language. k, on the other hand, doesn't really lend itself to being expanded (there are solutions to expanding the language itself; many people & companies do). However, it takes the same philosophy externally rather than internally: "We're not going to give you everything, we're going to give you a method of creating anything in a highly-efficient way."

An analogy that I think works fine: k is LEGO to your average programming language's pre-built kits of Lincoln Logs.

[1] This is why Lisp is dead (Common Lisp killed it) and C is still going strong, despite the former being great (except Common Lisp) and the latter being...highly-controversial, and why when a simple Lisp was released it blew up for quite a while despite absolute mismanagement (Clojure).</comment></comment></comment></comment></comment></comment></comment>


Tiny Docker Operating Systems - <AUTHOR> https://blog.docker.com/2015/03/tiny-docker-operating-systems/

<comment><USER2> Not mentioned in this blog post is CoreOS, one of the leading operating systems in this category.

I'm happy to see the variety of operating systems coming out lately.

<comment><USER3> CoreOS isn't intended to be the base image of a docker container, it's meant to be the host for docker containers.

<comment><USER4> Boot2Docker and RancherOS are also meant to be hosts for containers.

</comment></comment></comment><comment><USER5> OT: I really hate group blogs (more than one author) with byline at the bottom after the content.

The subject of the first sentence in the post is "I". I've no idea who this "I" is unless scrolling to the bottom.

Please place the byline below the title.

<comment><USER6> How do you feel about The Economist's publication style?

<comment><USER7> The Economist works hard at having a house writing style and a house viewpoint. You will never see "I" in an unsigned Economist article.

<comment><USER8> No, but you might see "This author..." sometimes instead. Economist does pretty well, but personality still seems into some of the non-editorials.

</comment></comment></comment></comment><comment><USER9> Not mentioned: [https://github.com/ibuildthecloud/only- docker](https://github.com/ibuildthecloud/only-docker)

(though it's more of an experiment than an OS)

<comment><USER10> I think that's what RacherOS does as well, which is interesting as they're claiming it's production ready! Only Docker seems neat, I'm loving all of these experiments.

<comment><USER11> The same guy (Darren aka "ibuildthecloud") is behind both projects. He is very prolific.

</comment></comment></comment><comment><USER12> I'm not quite up to speed here, but aren't these simple linux user lands, running on a normal Kernel, and not actually real OSes that provide a new set of APIs to interact with the system?

I see all these "DockerOS", "RancherOS", "CoreOS" things and at the end it is just a kernel and a set of programs that take over the init process in a certain way.

<comment><USER4> Careful or you may fall into the 'What is an OS' discussion. :)

They are all kernels and suites of tools, namely Docker and usually Busybox. The primary objective in all cases is to have a minimal OS host for Docker containers so they can drop the normal suite of tools.

</comment></comment><comment><USER13> Seems like guys that can cram chess programs into less than 1k would be great for this type of development.

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

</comment><comment><USER14> Text-only for those who can't load the page.

[http://webcache.googleusercontent.com/search?q=cache:eboGGnF...](http://webcache.googleusercontent.com/search?q=cache:eboGGnFGZ- UJ:https://blog.docker.com/2015/03/tiny-docker-operating- systems/&hl=en&gl=au&strip=1)</comment>


China is perfecting a new method for suppressing dissent on the internet - <AUTHOR> https://www.vox.com/world/2017/8/2/16019562/china-internet-freedom-dissent-twitter-facebook <comment><USER2> I skimmed the actual paper.

To summarize: 50c is massive scale social media astroturfing or 'reverse censorship' that spikes up to drown all negative news with positive news.

> We show that almost none of the Chinese government's 50c party posts engage > in debate or argument of any kind. They do not step up to defend the > government, its leaders, and their policies from criticism, no matter how > vitriolic; indeed, they seem to avoid controversial issues entirely. > Instead, most 50c posts are about cheerleading and positive discussions of > valence issues. We also detect a high level of coordination in the timing > and content in these posts. A theory consistent with these patterns is that > the strategic objective of the regime is to distract and redirect public > attention from discussions or events with collective action potential.

This is exactly how professional corporate PR works. Don't lie. Don't get stuck to negative issues. Control the narrative and and direct the discussion elsewhere.</comment>


Luna – Visual and textual functional programming language - <AUTHOR> http://www.luna-lang.org <comment><USER4> Hi guys! My name is Wojciech Danilo and I'm one of the founders of Luna. The timing for this news is a little unfortunate, because we are just before releasing Luna as an Open Source project! However, it's great time to answer some questions and give you a short update what has happened for the last couple months:

1\. We've raised a seed round of $1M, so we can safely focus on product development and shortly on community building! 2\. We've improved our core technologies to be much more robust, open and extensible, including:

\- We've re-written our graphical interface to be much more open and extensible (it was previously running on WebGL and now we base just on HTML, so it will be possible to attach any HTML-compatible controls / visualisations directly to nodes) \- We've implemented new, better type inferencer and updated Luna compiler in many ways. \- And much much more, but I don't want to uncover everything before the release, especially when it's around the corner :)

I would love to answer your questions, so If you've got any, just post it here and I'll do my best to cover it. Don't forget to singup for the list at [http://luna-lang.org](http://luna-lang.org). We'd love to collaborate with you during the upcoming release! :)

Cheers, Wojciech

<comment><USER5> When you're talking about building a community, I'm wondering how are you going to convince Data Scientists who are pretty much used to R and Python and not any functional programming language, try Luna? Any plans for it? Like a free course on Udemy or any mooc to take this to masses?

<comment><USER4> We are open to suggestions here. We know that Luna brings a great power to Data Scientists but there have to be a good way to show this power to them. I don't know currently what way would be the best and we've got a little time until we do it. For now, the first milestone for us is to build community around good programmers (including good programmers from the data science field) and later target less technical people. Any suggestions however, are very important to us!

<comment><USER6> I'd be interested in (and have some experience) in bridging Python with other (data-heavy) languages, which would let you pull in a lot of functionality as nodes in your graph, or expose your graph as functions in Python.

<comment><USER4> Great! I'd like to help make it happen. Please sign to our list and make sure you read mails from spam folder. Let's be in touch after the release, soon. Alternatively, just drop me a line at wojciech at luna-lang.org and let's stay in touch! :)

</comment></comment></comment></comment></comment><comment><USER7> Here is the snapshot from when this was submitted to HN about a year and a half ago: [http://archive.is/V2VwE](http://archive.is/V2VwE)

My question: what has changed? Has anyone addressed any of the fundamental questions that were posed last time this was submitted? Are there any concrete examples of how you might use this for general purpose programming?

<comment><USER8> That's more or less what I want to know. I've been subscribed to Luna for a while but I haven't received any updates or news about it whatsoever. The Twitter account is pretty dead. Even the images on the website seem pretty sketchy since I doubt many of the images are actually real or represent features of the editor. I've pretty much given up on this ever coming out.

<comment><USER4> We are alive! I'm really sorry for keeping you waiting for so long, we've been doing our best to make everything happen in the best possible form and I hope you will be happy with Luna after the release :) I'd be very thankful for any feedback after the release, it would help us much!

<comment><USER8> Thanks for chiming in! Hopefully it works out for you guys! :)

</comment></comment></comment></comment><comment><USER9> Super super cool project! As someone who does robotics, I'm super eager to try this, and to hopefully contribute to some open-source libraries for this.

A lot of work in robotics involves software that maps to this style well (functional-ish, where data is being pushed through computational pipelines / graphs), and I think this could be a killer development environment for things like control systems, sensor fusion software, image processing / computer vision, etc.

The fact that it is going to be open source, and already seems to have some nice support for things foreign libraries, profiling support, and well as visualizing of your data visually (that image processing graph example!) makes me think you are going to get a good response to this. I also think there are a lot of hobbyist type projects (RasPi level 'smart home' stuff, algorithmic art / music, SDR, anything you see on Make / Hack-A-Day) who would love a tool like this!

I'm very interested in checking this out, and in contributing packages / libraries if that will be supported. Hoping to get access to the alpha!

<comment><USER10> > A lot of work in robotics involves software that maps to this style well > (functional-ish, where data is being pushed through computational pipelines > / graphs), and I think this could be a killer development environment for > things like control systems, sensor fusion software, image processing / > computer vision, etc.

LabVIEW

<comment><USER9> yep, and I've used Labview (and Simulink, and other graphical editors) in the past for some of this.

Why I'm excited about this is: 1) It's open source, so we can extend it and hack on it as needed. Thos is probably the biggest reason. 2) The dual textual / graphical representation is really useful in cases where you might want to switch between the two, or one makes more sense than the other. You can do some with text in some the other tools, but the last time I tried, it felt like an after thought more than something expressly designed into the language. 3) It looks to be designed as a general programming language, focussing on having a good compiler, good tooling and a nice foreign function interface. My hope is that this means we can incorporate it into our existing code bases easier than labview, where it kind of wants to stand alone. As an example, perhaps I have a large existing codebase for my robot written in C++ with ROS. Perhaps I could use this to create a new ROS node that does my vision pipeline, by taking advantage of the fact it compiles down to native code, and has a foreign function interface designed in from the start. (Or maybe I'm dreaming, but my hope is it would be easier and more performant than doing the same in Labview!) 4) Did I mention open source :-)

<comment><USER4> We would do everything we can to support such use cases. In fact we believe in the same things TFortunato. I would like, however, to emphasize some things. After the first release, connecting to foreign languages on the lowest levels (like C++ foreign interface) will be possible but very hackish. Connecting using serialized data will be of course very easy. Moreover Luna's backend to compile to machine code needs still much love and this is our biggest milestone after the release. I'm writing it just to ensure that I will not "overpromise" anything, however the described use cases are very important for us and we will support them as much as we can. Again, feel free to help us and contribute :)

</comment></comment></comment></comment><comment><USER11> May want to remove from your "About Us" bio: "hates Java Script" \-- can't say I disagree, but you might alienate potential converts -- really should inject as much positivity as possible. Any negative messaging will do nothing but harm.

<comment><USER4> I prefer to alienate potential converts than convert JavaScripters! Just joking of course. It is hard to hide hate to a non-language treated as a super cool language. But you are right, I've never thought about it this way. I will change it, thank you!

<comment><USER12> in what way is javascript a non language? i write c, python and javascript- i dont see how one is any more of a language than another? you are baselessly pretentious

<comment><USER4> the_cat_kittles I did not wanted to hurt your feelings. Of course it is a language. By saying it is not I just wanted to express my strong anty-JS feelings, but they are of course very subjective :)

</comment></comment></comment></comment><comment><USER13> So in the past I have used two self-proclaimed "visual programming languages", Blueprints[1] and Max[2] and in both cases I found that it is actually harder to be productive while dealing with UI elements than it is to simply write code (as long as you have at least some rudimentary form of autocomplete I guess).

However I have to say that, based on the little I've seen, Luna's UI seems to be actually developer-friendly i.e. the UI elements go hand-in-hand with code rather than getting in the way, I think it's brilliant, sort of Jupyter Notebooks on steroids.

[1] [https://docs.unrealengine.com/latest/INT/Engine/Blueprints/](https://docs.unrealengine.com/latest/INT/Engine/Blueprints/)

[2] [https://cycling74.com/products/max](https://cycling74.com/products/max)

<comment><USER14> What is interesting here is that you can switch between code and visual representation. All luna code can be looked at in either mode.

Max does allow you to use JavaScript or Java and they are doing a lot right now with JavaScript interop/export.

<comment><USER13> Thanks for pointing me in that direction, I should have looked at the JS interop capabilities in Max.

</comment></comment></comment><comment><USER15> Very nice! I feel this space is under-developped. Luna reminds me a lot of Apple's Quartz Composer.

Visually representing anything complex is an immense challenge, but just like code is broken down into units (files/functions/whatever), a visual tool that can provide a fractal-like representation of a system would be awesome.

(I'm looking to dig deeper in this space for some pet projects.)

<comment><USER4> We feel the same way. As you have said, we use abstractions to hide complexity in text-based source files, like modules, functions etc. We do the same in the visual form. Every node in Luna is just a function, so you can "dig inside" it (by double clicking it) and see how it is defined. We hide complexity just by "collapsing" nodes together :)

</comment></comment><comment><USER16> I'd productize this more as the next level of "spreadsheet" than of "programming language". These kinds of visual programming things always seem to come out with lots of fanfare but then never get used for real work. The spreadsheet, however, is by nature reactive, relational, visual, impromptu, yada yada. But even though spreadsheet tech has added lots of functionality over the years, it's still essentially based on an old paper grid.

I could see a product like this challenging that old basis with something more modern. But it still has to do all the stuff regular spreadsheets can do too. And ensuring that it can, and in an intuitive fashion, should probably be the first priority.

<comment><USER17> Or start by doing enough of the stuff Excel can't do easily or at all and then grow into what you've described. For example: * Plot 3d (x,y,z) and 4d (x,y,z,time) graphs * Hook into data streams * Multi-user editing * JSON-like data structures beyond 2d row-column data structures * Improved output formatting

<comment><USER16> I'd be happy enough with floating sheets. To resolve those common things where you've got two different sections, like an analysis with a summary section below it. It's annoying because e.g. changing the column width on the top part also changes the column width on the independent thing below it. A tool that lets me put multiple independent sheets on the same page would be great. If the tool can be programmed to run image processing algorithms on the same page, that's fine too.

I'd view "IO" as almost equivalent to "Macro" in that instance. Though not quite. I'd like to be able to have e.g. $A$1 be a filename and $A$2 be the image in file $A$1, and that to be understood as a "pure" transform, even though under the hood it's got to open the file. So "application-scope purity" rather than process-scope purity.

</comment></comment></comment><comment><USER18> Interesting. I wonder if this is the future of not only reducing the barrier to entry to software engineering, but setting up a new tier of software engineer for the unskilled. Rather, would software have lower barrier to entry positions that are driven by piecing together software components like they would a factory job. I'm sure for most software a team is only necessary,but as software dominates our future, perhaps this is the bridge to unlocking more opportunities outside of a higher skilled tier of manual coding. I'm just talking off the top of my head, so I may be totally off base. Either way looks interesting, and that futuristic interface is sweet.

<comment><USER19> This is one of those things that always seems like it ought to be the future but for various reasons it doesn't take off. My high school computer class used a programming language called ProGraph[1] that looked a lot like this, but without the text representation, and it was neat but honestly it was _more_ tedious to both read and write anything of even moderate complexity than a pure textual form.

[1] [https://en.wikipedia.org/wiki/Prograph](https://en.wikipedia.org/wiki/Prograph)

<comment><USER18> For sure without the text representation, or manual code aspect a language would ultimately fail. I feel that languages that seek to "simplify" often oversimplify and leave those that require more granularity (most programmers) not to buy in. These languages can definitely offer a new paradigm on top of existing languages but it requires some fine control to get mind-share and ultimately take off. I'd say the real test of this, at least aligned with how I see it's future, is recruit not developers but non-devs and see how productive they can be in it, given they have a nice library of components to work from.

<comment><USER19> I fundamentally despise this concept of 'non-devs'. There's just a cyclical definition of non-devs as people who use non-dev tools and vice versa.

It's extremely common to dismiss tools used by certain classes of people as non-programmer tools because of who's using them. Look at Excel, which is basically a visual programming language that probably more people know how to program in than know C. But because your boss or your project manager or your sales rep uses it it gets dismissed.

Never mind that unlike these things that crop up every now and then people get real work done by programming their computer with it.

<comment><USER20> Excel's programmability is vastly underrated for some reason. It's easily one of the most high-level and successful languages ever, fulfilling a wide variety of roles for countless people, so simple that a child could use it, and so flexible that your boss probably does, too.

</comment></comment></comment></comment></comment><comment><USER21> Given the name, I would expect this to be related to or built on Lua. That doesn't appear to be the case. Is this echo accidental?

"Traditional software development is broken by design" is a pretty strong claim, but the only support is a bunch of over-broad anecdotal claims about what "always" happens. That's a bit offputting for some of us.

The phrase "Category Oriented Programming" is used like it's common vernacular, which I don't think it is. Is it related to Category Theory? The text seems to imply that the idea of mixing functional programming with message-sending objects is novel. It really isn't.

"Unmatched performance and safety". Yeah. You want to be careful about that claim. Going to need to see the independent evaluation results.

That said, for those who value diagrams highly, this looks interesting. I wonder at what level of complexity the abstractions start to leak.

</comment><comment><USER22> This is similar to Knime [0], which lets you build "workflows" visually, and allow you to write custom blocks with Python or Java. The main difference seems that you can represent the whole workflow in a human-readable (and writable) format.

[https://www.knime.org/example-workflows](https://www.knime.org/example- workflows)

</comment><comment><USER23> I find thinking visually to be quite limiting.

Although having a mixed textual representation is interesting. I sort of get this with the Moose platform in Pharo which I use for analysis based work. The most painful part of that though is interfacing with foreign systems. And maybe Smalltalk... not a bad language but I've been bitten by the Haskell/Lean/Idris bug. A seamless FFI experience as promised with this language coupled with a toolbox rivalling Moose would be interesting!

<comment><USER24> What is text itself but a visual representation of something complex? I repeat, text is intrinsically visual and just a restrictive form of the alternative which is diagramming. Is it a pure coincidence that the english alphabet happens to be the best primitive for representing programming concepts?

I believe that there is no coincidence. English is horrible at representing programming concepts. A limited set of characters, restricted left to right reading and line based structures... is this really the best way to program? Intuitively, things like recursion, data structures, processes, modularity and objects etc, etc, are better represented with diagrams... Wouldn't Circles and lines that can move diagonally across the 2D plane be better candidates as programming primitives?

It's hard to say really. Functional programming is in itself a restrictive form of imperative programming that gains power through restriction. It may very well be that English as a programming primitive gains the same type of power through restriction as well. Our brains have dedicated modules for processing language as well as dedicated modules for processing geometry, shapes and diagrams. Which module is better for programming?

Let's face it though, English as a programming primitive only became prevalent for historical reasons similar to how javascript (a shitty, shitty language) became prevalent. We like it partly because we're used to it.

There has got to be a better way.

<comment><USER23> Math.

When learning graph theory it can be quite useful at first. But once you start using set theory the graphical representation actually hides more information than it gives and intuition starts to get in the way of us discovering useful properties.

<comment><USER24> I think this visual stuff is perfect for functional (math based) programming as composed expressions aren't easily readable as english.

I find language to be better suited for imperative procedures. Think about it, I have a list of tasks, do I write that list in ordered English bullet points or do I draw a diagram?

<comment><USER23> I find simple math to be much more elegant and easier to comprehend then a jumbled visual diagram. It's much easier to understand a universal quantification in a standard notation than reasoning by visual analogies.

Programming languages tend to be a little less expressive and elegant. They're more complicated too. For reasons of course... but I don't think I'm going to be writing algorithms and data-structures in such a tedious notation as a diagram.

Graphics are good for some things but programming I don't think is one of them.

<comment><USER25> Some things look best in text and it's fine. However, "programming" is a very broad category, and definitely does not boil down only to algorithms and data structures. I'd even say that most programming tasks in the world right now are much less about complex algorithms and much more about everyday systems plumbing. Sure, at some point you'll need to fire a complicated linear algebra kind of algorithm, but before you get there, you need to get the data out from some source, do some reformatting, decide which algorithms to run and when and then send the results somewhere else. And for that, seeing what is happening with your data the moment you try a solution, and deciding the next step based on immediate feedback is great.

This is pretty much why we've gone with interchangeable representations instead of going "visual only". The choice of the proper tools / representations highly depends on the context, and we want to leave that for the programmer's decision.

</comment></comment></comment></comment></comment></comment><comment><USER26> One of the examples I saw you guys give on YouTube is how complex things are becoming, and you talked about the LOC of a modern car and this is a reason we need visual programming. On your website you also discuss the limitations of UML.

To design complex systems like a car, you really need to know not just the functionality and the type of information, but also the structure of the system. How do all of those systems on the car physically connect to result in the behavior.

It seems like your approach would be really powerful for data processing, since in that case I don't think the structure matters much. Have you thought about how this could be applied to a complex system where structure is extremely important?

</comment><comment><USER27> How do you envision version control/code reviews with Luna projects? Can diffs be explored at visual level or only source code level? If one developer moves nodes around without altering any logic are such changes tracked in the code repository?

<comment><USER25> For starters we've made sure to make git diffs as readable as possible. The visual data is kept at the end of text file (hidden when using our editor), usually in a single line. So if you just move nodes around, one line gets changed and it is clear what to ignore when scanning the diff, while making sure to retain the changes in the repository. For later stages, we envision much deeper integrated version control, including viewing git diffs in the visual editor.

<comment><USER28> This sounds bad. Any info in the text related to the visual representation will be unreadable i guess. Hiding such for diff review is helpful but not enough. Because in merge conflict resolution one may not have the luxury to neglect it.

</comment></comment></comment><comment><USER29> > _Traditional software development is broken by design_

Which is why Luna is entirely hosted within itself and needs a Luna implementation to bootstrap.

We wouldn't want to ask investors to believe in any traditional development after telling them it's broken.

</comment><comment><USER30> This idea will eventually work and be huge I think (I know visual programming languages already exist but a commonly used one to emerge). As someone who believes in metaprogramming and flexibility though I'm hoping for something dynamic, not a heavy mandatory type system that compiles to Haskell.

<comment><USER4> We believe in something very similar, there are some differences though. Luna type system is not dynamic BUT it is also not mandatory. Our whole standard library does NOT mention a single type - all are inferred by type system and you can, if you want, state them explicitly. To sum this up, we want Luna to be simple to use, intuitive, but have a strongly typed backbone with power similar to Haskell or Idris IF needed. Does it makes sense to you? :)

<comment><USER30> Thanks for your response and that does seem like a nice compromise, but it's still not perfect to me.

If the choice is <untyped>|<haskell>, it's better than just <haskell> but I'd love some <gradually typed, allows side effects>

Good luck with your project, looks pretty cool

</comment></comment></comment><comment><USER31> I like the idea of category-oriented programming. Would be interested to see a white paper on what that means.

<comment><USER25> This feature is a bit of a misnomer, as it immediately brings up discussions about category theory. That being said, the idea behind it is pretty simple, yet powerful. Our typechecker will be able to track the shape of data on a deeper level than usual types. Basically will be tracking the exact constructors used to construct data, not just types – something that is a huge pain in most existing typed languages. If you for example take Haskell, you can have a data type with multiple different constructors, and even though you may be certain that some of those are impossible to occur at some points in your program, it is difficult to express that certainty on typelevel – other than repacking to a different datatype, with less constructors, which then need to be named differently and need repacking even if you're just calling a function that expects a wider range of constructors, and thus is definitely safe. However, due to the amount of work with more foundational layers of the language, we've had to postpone implementing this feature until further down the line. It is coming at some point for sure, though :)

<comment><USER20> That sounds like a horribly leaky abstraction if you mean that you're literally going to statically track the call stack to attempt to verify invariants. Hopefully it's just a misunderstanding on my part.

</comment></comment></comment><comment><USER32> Is this related to the luna programming language experiment by TJ Holowaychuk?

[https://github.com/tj/luna](https://github.com/tj/luna)

<comment><USER33> There is also a framework by this name that is (was?) being developed by Asana.

Naming is hard in the global namespace!

<comment><USER34> Yeah it was - [https://news.ycombinator.com/item?id=2191800](https://news.ycombinator.com/item?id=2191800)

</comment></comment></comment><comment> a-nikolaev Looks like a lazy functional Python ) Very nice aesthetics of presentation.

There are a few things I am concerned, if you don't mind: I think that actually visualizing lazy computation can be quite a challenge, because of its on-demand nature. One might say that a lazily defined expression is computed (and should be visualized) where it's used, rather than where it's defined. There is a lot of substitutions going on under the hood, and computation is not as clearly localized as it would be in eager evaluation. Also, the tight binding between the code and the visualizations may limit your ability to optimize code for efficiency.

The True / False switch looks cool, but it feels like you are cheating here a little bit by using a boolean literal. Would it look equally nice if it's a function call or some complex expression that is possibly not known yet (as in a function definition)? I have a feeling that at the end of the day Luna may require a very complex visual language that is not easier than the textual alternatives.

But this is more like arbitrary concerns that will be hopefully clarified once you release the whole system. Thank you for your work.

Thumbs up for exploring these new alternative for writing code. I think, it may help us write better and safer programs in the future.

</comment><comment><USER35> Why implement a new language rather than a GUI on top of Idris, PureScript or similar?

(That aside, very excited!)

<comment><USER25> We needed to design everything from scratch to make sure the two representations are truly interchangeable. Every design decision in the textual language needs to be backed by its visual counterpart, and we found this way of thinking impossible with any other existing language. Then there is the problem of complexity of existing, typed, functional language. We aim to make things as simple as possible, while not sacrificing the power of types, in order to make the language accessible for a much broader audience. I'm super happy to hear that you like it, make sure to sign-up for our newsletter, so we can stay in touch once Luna is out :).

<comment><USER4> I would love to emphasize one of the thoughts from @kustosz reply: our main goal is to make Luna simple and intuitive yet very powerfull. We've got super cool type system on top of purely functional language, however we put our hearts to make the syntax (both visual as well as textual) very simple and intuitive. Neither of the mentioned solutions - Idris, PureScript nor Haskell, Erlang etc are "simple" and "intuitive" to use unless you are really good programmer.

<comment><USER36> I'm reading the Idris book now, and one cool thing there is guessing bits of implementation based on the type declarations (there written before implementation).

I imagine in a visual environment, being able to make useful suggestions on potential ways to use/combine different nodes/types would help as well as an auto-complete for the user's intent.

I'm actually also a bit reminded here of MS Excel Power Query, which also offered a GUI for data transformation, see e.g. [this pic]([https://blogs.office.com/wp- content/uploads/2015/07/6-update...](https://blogs.office.com/wp- content/uploads/2015/07/6-updates-in-Power-Query-for-Excel-5.png)).

I bring this up because I see you covered visualizing the steps, while they focused on showing the data (though after finishing a transformation the script could be generalized into a reusable function). I wonder if adding a dimension like that could be helpful for Luna as well.

If you target non-programmers, showing things as concrete as possible (e.g. their data transformed by whatever function they just pulled together) sounds like it might help make things even more accessible.

</comment></comment></comment></comment><comment><USER37> Just some minor critiques.

What is confusing to me is if the visualization actually running the code or is just static analysis of the code?

The reason I ask is if its running then what you have built is a language with an absolutely awesome visual REPL. If it is please say its a language with awesome visual REPL! A potential Excel for programmers killer. There are languages that tried to do this (Squeak, and Racket come to mind) but they were generally academic and more often for students/young adults (and not for businesses).

However you say whiteboard through out your marketing which makes me think brainstorming tools ala evernote, orgmode etc. I realize for VC they might prefer whiteboard.

Whiteboard to me is sharing and not really a tool. It means I have to register and create a profile when all I really want is a language with a powerful visual REPL. (again just my point of view on marketing).

<comment><USER25> Why don't we have both? And then some more. It is an awesome REPL with a bit of Excel feel. Runs the code whenever you change it and displays the results in real-time. It is also great for interactive data sources (like web services), where you get the results as soon as they appear upstream. The whiteboard part is super important too. Visual representation is great for design and brainstorming. Even more so, when it provides runtime feedback about your designs. And it gets even more important with collaboration. So at this point we've got a collaborative whiteboard that actually runs the computations. There is, however, one more part to the story. Neither whiteboard, nor a REPL are well suited for implementing the final, production software. We aim to blur the lines between the design and implementation phases, allowing to deploy whatever has just been "sketched".

</comment></comment><comment><USER38> I'd love to hear how this might be applied as a general debugger concept for CUDA and the likes. To a layman like me, CUDA's GDB debugging interface has always left a sour taste in my mouth due to the high amount of parallelism that simply can't be displayed through a debugger entailed to be used only on a single thread. I'd love to see someone working on (and I'm probably going to take a crack at it myself ;) ) not just using this interface as a language, but also as a debugging tool for other languages. Decomposition of CUDA (and other -- thinking Erlang right now especially) programs into bite-sized visualizations in order to program and debug would be invaluable for the space.

<comment><USER4> It would be supper cool to debug CUDA with Luna, but keep in mind there is a really long way until it will be possible. It is however very interesting path and I'm super curious where it could lead us to! I'm willing to support it as I can if you would like to try do it by yourself. You will be even able to cut off our backend and use the GUI for your purposes, however more interesting (and even probably also easier) way to do it will be to make some abstractions in backend and build the graph using provided by us backend server, its API and replacing only the interpreter / compiler plugins. To sum this up, a very interesting idea!

</comment></comment><comment><USER39> This. Looks. Awesome!

I literally cannot wait to try this out on some data processing/number crunching stuff!

The integrations with the likes of Python are super exciting as well - <USER2> plans (even remote ones) to do the same with Julia?

<comment><USER4> I'm glad you like it! :) I'm very curious about your feedback after using Luna, don't forget to keep in touch with us after the release!

We do not integrate with any language, because the visual representation is just a different syntax for Luna. In fact we keep both syntaxes - textual and visual with the same powers, so you can switch between them, but they are just syntaxes for the same language.

Integrating with Julia (or other lang) would be hard because the language has to be designed in such way that it will allow for such dual representation. We put an enormous effort to design Luna this way. However it will be possible to integrate Julia in such way, that some of the nodes would be written in Julia and then even allow to in-place expanding nodes to small text-editors to preview the code in place. It will however not be possible to translate Julias code to graph or vice versa.

</comment></comment><comment><USER40> Awesome, we need more visual programming languages coming out now. it's so impossible to convince a programmer who never experienced visual programming how useful/practical it can be.

I understand you are from a video processing background where visual programming is widely employed.. We are also building a visual programming platform, inspired from enterprise tools. Really interesting to see this domain evolve.

</comment><comment><USER41> This looks really beautiful: what's it written in?

Also, "Num in IO", nice. Now we wait for someone to write a "(Num in IO) in IO" action.

<comment><USER4> Hi! We write almost everything in Haskell. By the way, Num in IO in IO is completely ok function signature - it means that you have a function that uses IO to optain a function which will return a number while performing another IO action :) However it is completely ok in Luna for the end user to type it simpler, like `a :: Num` and the compiler will keep track of all "monad transformers" under the hood.

<comment><USER42> I think this is a really good idea -- many people, myself included, get really excited about Haskell and then are turned off by the complexity of monad transformers.

I would recommend that you focus on good error messages that explain monad- related errors in "user land" and not force them to either guess about what's wrong or suddenly learn all the stuff under the hood. It's a terrible experience and you see it in C++ with incomprehensible template errors or any kind of transpiled language like ClojureScript that gives you errors from the underlying implementation.

<comment><USER4> That is a very good point. We treat "monads" in a very special way in Luna - they have their own type section and we can analyse them and report errors much clearer than Haskell can for example. This does NOT mean that we limit them in any way. You are free to define your monads and convert them to ordinary types or back as you wish :) But we normally dont describe them as monads, just as "context", because it is easier to understand.

</comment></comment></comment></comment><comment><USER43> I haven't tested it yet but i mind if this is possible to make microservice with this ?

Like defining an port (like 80) an input (a json like {"example":0} make an operation an return a value by the same port and json.

It could be an nice way to include micro service into a larger eco system or make people collaborate using luna in larger project.

For python you may use hug or flask

That s an interesting idea btw

good job and good luck

</comment><comment><USER44> You say you have dependent types

OK, could you define this?

        data Eq : {a : Type} -> a -> a -> Type where
            Refl : Eq x x

        sym : {x : a} -> {y : a} -> Eq x y -> Eq y x
        sym Refl = Refl

        replace : {a : Type} -> {x : a} -> {y : a} -> {f : a -> Type} -> Eq x y -> f x -> f y
        replace Refl p = p

</comment><comment><USER45> Examples on the home page have broken indentation, or just a multi-level indentation that is confusing?

        class Point:
            x y z :: Int
          origin      = Point 0 0 0
          Point x y _ = origin
          print 'Origin XY coords are ($x,$y)'

(Why is `origin =` indented at all?)

<comment><USER4> You are right, all the last 3 lines should be aligned max to the left. We'll fix that soon on new website!

<comment><USER45> Another thing, this example wouldn't type check unless it is verifiably a list of non blank strings:

        print [s for s in lst if s.head != '_']

The section about dependent typing says `lst.head` would be a compile time error in some cases.

</comment></comment></comment><comment><USER46> Isn't it similar to what Eve tries to achieve? Well, what I like in overal, is an attitude and courage to introduce new technologies! I come from the Red language camp, which if I am not mistaken, is also being funded. So - <USER3> luck, guys :-)

<comment><USER47> Yeah, we have a lot of the same views about programming, but our focus isn't on data science. We can definitely agree that the practice of programming in the future won't look like it does today.

</comment></comment><comment><USER48> Wojciech, this is incredible! The combination of expressiveness, type safety, visual programming and API focus are pretty unique right now.

By the way, "Aggresive compile-time optimization" should be "Aggressive compile-time optimization".

</comment><comment><USER49> Where are the node positions stored?

<comment><USER25> We store them in a separate section in the source file, which is hidden by default when editing. So a bare .luna file is a readable text file, containing some metadata at the bottom, which is not shown when editing with our editor. This way we achieve clear representation and full portability of the source files.

<comment><USER49> Nice.

A few more questions:

Is does z-ordering just follow the painter's model?

As a user am I allowed to place two nodes at the same x/y coordinate?

As a user am I allowed to position nodes in a way that creates a visual ambiguity in the diagram (e.g., two or more perfectly overlapping edges among nodes)?

Edit: As a user am I allowed to place a node at an x/y that lies within the bbox of another node?

<comment><USER4> 1) it uses painters model 2) you are allowed to place in the same x/y, but we're looking for a way to indicate it to you. 3) you are able to place nodes so the edges overlap, but we also are looking for a way to indicate it to you.

Keep in mind, that point 2 and 3 does not happen during your workflow normally, so these are very rare situations. We want to support them just from the "purity" perspective, but they are very low on our priority list currently.

<comment><USER49> So in terms of git, Luna users won't be able to comprehend the visual z-order and positional changes by glancing at a diff. And those types of changes will come freely in the normal course of development.

That means that Luna requires some kind of visual diffing step to reach parity with the development flow of text-based languages. Otherwise developers will get comfortable interpreting metadata changes as noise. In specialized languages like Max/MSP that leads to spaghetti programs. In more general visual languages it could probably even lead to security issues if an overlap suggest a different visual data flow than the source code. (And judging by Pharmaceutical TV commercials, people blithely favor the visual over the written when there's a discrepancy.)

</comment></comment></comment></comment></comment><comment><USER50> I truly hope you will succeed in your mission. It looks like it could solve so many problems that I've come across as a result of confusion and miscommunication when people with a common understanding step away from the whiteboard and start coding. It can be so hard to align the implementation with the visual abstractions we so desperately need to communicate as humans.

</comment><comment><USER51> Cool concept - is there an open source repo of some kind which shows how a complex application (kitchen sink kind of app) is made?

<comment><USER4> Thank you! We will be releasing demos soon!

</comment></comment><comment><USER52> Are you guys going to release something describing your concept of "category oriented programming" any time soon?

<comment><USER4> We will try to cover it alongside the upcoming release! :)

</comment></comment><comment><USER53> If Luna is dependently typed, can it be used to do theorem proving, eg like Idris?

</comment><comment><USER54> I'm struck by the similarity to grasshopper. This seems to share many of the same features such as visual profiling, visual / textual representation, live previews etc... Has it inspired the design at all?

<comment><USER4> Grasshopper did not, but Houdini / Touch designer actually did.

</comment></comment><comment><USER28> I would like to subscribe to the news, but am afraid to use news-letter services. I suspect they sell the addresses to spammers. Would you please instead set up an atom feed or a primitive blog on Blogger?

</comment><comment><USER55> What is it compiled to? Does it target JVM, CLR, native code (if so what platforms?) What is it compiled with? LLVM ? GCC ? Custom compiler? What is the standard library like?

<comment><USER4> It targets few backends. Currently it runs on our VM, but we are working on targetting GHC's Haskell Core (which then compiles to LLVM IR). Luna's compiler is of course a custom compiler written in Haskell. Standard library looks cool!

Did I answered your questions? :)

<comment><USER56> >standard library looks cool

What does that even mean? No offense, but like I haven't seen any demos on your website and you are describing the std lib as cool? Not exactly confidence aspiring.

It looks interesting for sure and looks really fun to mess around with (frankly has a hobbyist high school programmer who likes systems programming, I don't see a whole lot of use for me :))

Good luck.

</comment></comment></comment><comment><USER57> I'm super interested in this project! I'd like to see how interop really works and how to get multiple data sources interconnected to produce amazing datasets.

<comment><USER4> Im happy to hear that. We do our best to realease it soon and I'd love to collaborate further with you then!

</comment></comment><comment><USER58> Any relationship to TJ H's repo, [http://github.com/tj/luna](http://github.com/tj/luna) ?

<comment><USER25> Other than name – none at all :)

</comment></comment><comment><USER46> Isn't it similar to what Eve is trying to achieve?

</comment><comment><USER59> What beautiful black magic programming even despite the fact that I hate flow chart programming like unreal and other game engines do.

</comment><comment><USER60> I'd like to see how the visual representation of larger non toy examples look. Looks like a very cool project !

<comment><USER4> hi! Each node "contains inside" graphs of nodes. You can literally select nodes and collapse them into one, new "function". This way you just raise the abstraction level, just like in textual-sources, however in the graphical environment it is just more pleasant to select nodes than re-factoring functions in text :)

</comment></comment><comment><USER61> so when's the ICO?

</comment><comment><USER62> Looks cool! Is the editing environment extensible enough to support an embedded neovim instance?

</comment><comment><USER63> It sounds like it wont compile to C or use LLVM, you have some kind of custom VM?

<comment><USER4> We are not going to compile to C, however we will to LLVM IR (not directly though). During the first release we will provide Luna interpreter (so yeah, some kind of custom VM). We are however already working on the backend that compiles Luna to Haskell's GHC Core ([https://ghc.haskell.org/trac/ghc/wiki/Commentary/Compiler/Co...](https://ghc.haskell.org/trac/ghc/wiki/Commentary/Compiler/CoreSynType)), which then gets different functional-programming related optimizations and translates to LLVM IR.

</comment></comment><comment><USER64> anyone try bubble.is? Love to get a comparison on how this is better / different.

</comment><comment><USER65> Pretty bad name, I thought it was a typo for Lua.

<comment><USER4> We use the name for a long time now and we love it, however I agree it could be confusing. We failed, however, to find a better one.

I've got a crazy idea here! I know that HN has some magical powers, so if you have any idea of a better name for a dual-representation, functional, visual language, we'd be more than happy to talk about it and change it before the release (after the release it would be too late)! :)

<comment><USER65> I mean, I don't care if you keep it as Luna. Just saying you're gonna have problems if you keep that name

<comment><USER4> I completely understand that, but we care about it very much and don't want to have problems with it. Because of that I asked about help with the naming :)

<comment><USER66> I'm a huge Lua fan and I got excited for a moment thinking it had any connection to it, then I was disappointed that it didn't, even if Luna does seem like a great piece of tech!

Here goes some suggestions: [https://en.wikipedia.org/wiki/Phoebe_(mythology)](https://en.wikipedia.org/wiki/Phoebe_\(mythology\)) [https://en.wikipedia.org/wiki/Zana](https://en.wikipedia.org/wiki/Zana) [https://en.wikipedia.org/wiki/Notus](https://en.wikipedia.org/wiki/Notus) [https://en.wikipedia.org/wiki/Jaci](https://en.wikipedia.org/wiki/Jaci)

</comment></comment></comment></comment></comment><comment><USER67> I like to see a language that's a simple subset of ruby for example but the OO is delegated to a graphical representation (boxes for classes, arrows for methods etc..)

<comment><USER4> I'm afraid Luna is not for you then! However, I strongly doubt that visualization of OO concepts will bring you a productive environment. I also believe that the combination of functional programming and visual paradigm is the way to go here :)

<comment><USER68> How do you do basic branching and loops?

<comment><USER4> Each node is a function, so if a node uses itself, you've got recursion (loop). Branching like if is just few edges going into a node and the result goes out :)</comment></comment></comment></comment>


An Analysis of Sprig's Facebook Ads - <AUTHOR> https://blog.mightysignal.com/the-sprig-egg-cdb788a60d57#.qivgyfify <comment><USER2> I'm curious what sorts of creative discussions happened around that egg. I'm guessing it involves something about conveying the freshness that they provide, and you don't get an egg like that on a regular restaurant delivery meal. It screams "this was prepared just now, just for you."

Since you guys tracked 8 ads, is there any deeper creative analysis that you've performed? Have you looked at what trackers their sites load or any of the URL params to dig into more campaign details?</comment>


OpenProject 8.0 released - <AUTHOR> https://www.openproject.org/openproject-8-0-release/ <comment><AUTHOR> I'm one of the core developers. I think we improved a lot in this release. No more textile but instead Markdown with a WYSIWYG editor for instance.

<comment><USER2> not really related to the project specifically and kind of a small nit pick, but I wish projects like these would add a one line description of what the project is/does at the start on their major announcements. Just sneak in the words "Open source collaborative project management software" somewhere in the opening paragraph and the whole announcement becomes a lot clearer for those of us who first hear about the project via links like this.

<comment><AUTHOR> Thanks for the feedback. That's a good point.</comment></comment></comment>


As a Founder, how do you handle administrative tasks? - <AUTHOR> http://blog.entryless.com/saas-accounting-make-the-switch-today/

<comment><AUTHOR> Are virtual assistants, automated accounting like mint, what services you use?</comment>


Electric Dump Truck Produces More Energy Than It Uses - <AUTHOR> https://hackaday.com/2019/08/22/electric-dump-truck-produces-more-energy-than-it-uses/ <comment><USER2> What a cool use of gravitational potential energy. It would be interesting to learn how much more energy is produced by the regenerative breaking system on the downhill and whether they use the excess to load the truck?</comment>


Ask HN: Dynamic memory/CPU provisioning for VMs? - <AUTHOR> When AWS EC2 (Elastic Compute Cloud) was launched, the young inexperienced me initially understood this was a service to hire virtual servers by the hour, but the price would vary (in an "Elastic" way) according to how much RAM or CPU resources you use.
To my disappointment, this was obviously not the case.
Now, 15 years of technological development later, would such a service be possible?
What is the closest service to a truly "elastic" VM instance to date? <comment><USER2> GCP e2 instances (that are like 30% cheaper) are closest match to what you are asking. These VMs run on overcommitted capacity and migrated to a different physical host seamlessly when the resources are reclaimed

Edit: e2 not n2 - [https://www.google.com/amp/s/cloudblog.withgoogle.com/produc...](https://www.google.com/amp/s/cloudblog.withgoogle.com/products/compute/google- compute-engine-gets-new-e2-vm-machine-types/amp/)

</comment><comment><USER3> For CPU you have hotplug and quota scheduling; for memory you have hotplug and ballooning.

But when you say "the price would vary according to how much RAM or CPU resources you use" you get into the real complexity: resource sharing. If your VM temporarily gives up some RAM, can another VM use that RAM? This is very hard to do, because the provider doesn't know when/if you'll want that RAM back. They don't want a physical server to get into a situation where the RAM demand is higher than the installed RAM because there is no good solution to that scenario. If you're running hundreds of "micro" VMs/containers on one server you can rely on statistical multiplexing and luck, but it doesn't really work for large workloads.

A provider called NearlyFreeSpeech has been charging based on "the use of one gigabyte of RAM for one minute, or the equivalent amount of CPU power" since even before EC2 existed AFAIK, but I suspect this complexity is more scary than attractive for most people. [https://www.nearlyfreespeech.net/services/hosting](https://www.nearlyfreespeech.net/services/hosting)

</comment><comment><USER4> Turns out to be a somewhat annoying problem at the VM level. Not impossible but complex enough that maybe higher-level solutions like functions are better.

Consider memory usage -- but operating systems (and some applications) are designed to grab all the memory they can, and use it for caching etc. So it's hard for the VM host to known when it can grab memory and stop billing the user for it.

But there is this idea called memory ballooning -- you have a little process running on the VM guest OS that grabs lots of memory, but is actually in cahoots with the host, and just tells the host -- "hey I got all this memory, you can take it back and use it somewhere else".

Okay, so doesn't ballooning solve the problem? There are a few problems with it -- you can't balloon when you need the memory, because it's not fast enough. So you have to balloon pro-actively. And you don't know how much to balloon, so you have to guess: do it wrong and the guest OS will start swapping, or it might activate its OOM killer and start killing processes.

So making memory usage follow the application is kinda sorta possible but comes with hairy problems. What about CPU? CPUs usage already follows the application so you could just measure and bill accordingly -- except that nothing is gained if memory doesn't also follow usage.

All in all it's way simpler to get towards this goal with clearly-defined higher level services like Lambda.

<comment><USER5> And even with Lambda you have to decide before. At least powertuning helps here a bit.

<comment><USER6> And keep in mind the premium price that follows cloud Functions as a Service. Unless you're running a very intermittent batch job with strict control and security policies, most traditional organisations really shouldn't need to build stuff out on this type of architecture model. If you ops and dev team is less than 5 people, maybe consider this to save on ops costs.. But I think it's fair to say for some orgs, this premium just isn't worth it. And they don't know it until they've been billed millions of dollars over years and finally a CFO/CTO is running cost-cutting programs.

<comment><USER5> The idea is that the Ops for a coparable architecture without FaaS is more expensive than just running FaaS and not having to pay or to talk to as many people.

</comment></comment></comment></comment><comment><USER7> [https://github.com/purpleidea/mgmt/](https://github.com/purpleidea/mgmt/) can dynamically add and remove vcpus to a running vm. Each change has sub-second precision, and a second [https://github.com/purpleidea/mgmt/](https://github.com/purpleidea/mgmt/) running in the vm can detect this and charge workloads accordingly if so desired.

There are videos of it happening, but no blog post yet.

</comment><comment><USER8> t3 instances on AWS have burst capacity charges if you choose unlimited. It's $0.05 per vCPU-hour, and is only charged if you exceed the accumulated burst capacity.

So running a t3 would allow you to pay for a baseline and then only pay for the CPU you end up needing beyond that baseline.

</comment><comment><USER9> Removing RAM from VMs turns out to be actually quite tricky - hot-unplug very rarely works because the OS tends to have allocated stuff all over so you don't have a nice large DIMM like quantity to unplug. Ballooning kind of works but it's more advisory, there's nothing to stop a guest gobbling that ram up again (and it has other issues). David Hildenbrand's Virtio-mem might help solve this; see: [https://www.youtube.com/watch?v=H65FDUDPu9s](https://www.youtube.com/watch?v=H65FDUDPu9s)

</comment><comment><USER10> Not for VMs but definitely for containers and functions (like AWS Lambda). You can configure them with soft and hard limits but also invocation counts and runtime.

Doing the same in a VM might be possible (the technologies exist) but it's often the task or workload that needs to be modified to support it and when you are already doing that a step to containers, functions or horizontal scaling is just as easy (or hard). Horizontal scaling based on load is pretty common (classic ASGs but also overcapacity cost bidding based scaling).

</comment><comment><USER11> It would be possible. Paying for CPU and memory was the business model of hundreds of data processing companies that ran mainframe batch jobs and time- sharing services on partitioned machines. Mainframe companies billed users by machine usage (with the machine on-site). This is obviously doable.

It raises some isolation concerns, however. To make this work, the host needs to know how much memory is allocated to a given tenant, and that's difficult without having access to the OS running inside the machine, which is easy with containers, but not so much with VMs. The tenant can turn off virtual CPU cores in the VM and the hypervisor can pick that signal up (at least in Linux) but I'm not sure it's possible right now to do the same to virtual memory modules. I'd love if AWS allowed me to do that because the boot process of some of my workloads is more CPU-bound than the rest of the machine's lifetime and having a bunch of extra cores at boot would do wonders. If, under memory pressure, I could "plug in" more virtual memory modules, it'd also be quite nice.

There could be a market opportunity, but whoever does it would need to beat the current incumbents in price or this would not fly. Also there would be some difficulty scaling up - all these extra CPUs and memory would need to come from somewhere and would necessarily fail (or need to trigger a live VM migration, which, IIRC, nobody does in cloud environments right now) if the host box's resources are fully allocated.

<comment><USER12> I have a related question: how can you know that a VM is being limited in terms of CPU power?

As an experiment I deployed several apps to Azure S1 tier and they appear to be good bit slower than running on a VM on our Dell R740 on-premises server.

<comment><USER13> Be aware, most cloud companies consider a 'core' to be a hyperthread.

When ARM released on AWS, it was a double punch because it has no hyperthreading on the chips so you get a full core at a cheaper price.

</comment></comment></comment><comment><USER14> Possible in vmware to add additional CPUs [https://blogs.vmware.com/performance/2019/12/cpu-hot-add- per...](https://blogs.vmware.com/performance/2019/12/cpu-hot-add-performance- vsphere67.html)

However we kind of moved on to disposable servers which can be scaled on demand. In which case you just add additional servers or adjust server type depending on requirements. Same with containers.

The need to add RAM or CPU to a running instance was from the time you used to have a singe long living instance serving an application.

</comment><comment><USER15> Yeah of course you can.

Simply allocate each vm one core for each hyperthread and record the CPU time used in total.

Nobody actually does this because it makes billing complicated. Both practically and for sales.

My guess is this would result in overall less revenue as well, AWS is for sure making lots of money selling the same cpu time to a dozen people not actually using it.

<comment><USER3> _AWS is for sure making lots of money selling the same cpu time to a dozen people not actually using it._

They "for sure" aren't; their prices are so high precisely because the resources are guaranteed (in most cases).

<comment><USER16> I agree with that. Amazon pretends to sell you "burstable" instances, but they know that most people are going to be bursting at the same time a day because most applications want low latency and host them close to their users, applications that are worth paying for are used by businesses, and business users use the app between 9-5 on weekdays. As a result, you don't get much bursting and the instances aren't much cheaper than non-burstable instances.

Good resource utilization will only happen when you have non-interactive tasks that can be scheduled to smooth the demand. When I worked at Google, this is something we had; plenty of people were willing to run their mapreduces overnight, and take advantage of the purchased interactive capacity that other services needed during the day. In the real world, I've never had anything like that. Users use our website during the day. Employees use the internal apps during the day. Developers send their code off to CI during the day. That means from 9-5 there isn't enough capacity (builds have to wait) and from 5-9 the computers are just sitting there bored. I don't see a way around it, even at cloud provider scale, just because so many users are like me. I might be willing to send CI builds off to some part of the world where it's nighttime -- if you'll give me the CPUs for free. Nobody appears to have written software to do this (maybe the big CI providers do this in the background; but I haven't noticed a lot of latency while ssh-ing to CircleCI jobs for example), so we sit here using computers very inefficiently.

Ultimately, computers are cheap enough that it doesn't matter. I have a 10 core workstation that sit idle most of the time. Having a fast build when I need one is nice; and the cost to have those cores sitting idle is minimal. I would be happy spending even more money on my workstation for that reason. I imagine people treat their servers the same way, and aren't tempted to tweak things because their workloads are interactive and autoscaling introduces latency.

</comment></comment></comment><comment><USER17> As far as memory goes your OS would normally gobble up as much ram as it can get for caching. You would have to go out of your way to make it memory-frugal so it could yield ram back to the hypervisor, and that could impact performance.

It's easier with CPUs where you can just yield back if there's no work.

</comment><comment><USER18> AWS's Aurora Serverless is charged for in this manner albeit with a minimum level.

</comment><comment><USER19> Your title implies dynamic hardware provisioning while the post is about pricing for use? Which is it?

<comment><USER20> I understand it to be about both. VMs can have CPUs and RAM added or removed while running as long as the kernel supports it. Linux supports it. I'm not aware of a service that sells this feature though

</comment></comment><comment><USER21> Use AWS Fargate or other lambda or other serverless technology.</comment>


Proof confirmed of 400-year-old fruit-stacking problem - <AUTHOR> http://www.newscientist.com/article/dn26041-proof-confirmed-of-400yearold-fruitstacking-problem.html#.U-pszCddXR0

<comment><USER2> [https://code.google.com/p/flyspeck/wiki/AnnouncingCompletion](https://code.google.com/p/flyspeck/wiki/AnnouncingCompletion)

 _August 10, 2014_ _We are pleased to announce the completion of the Flyspeck project, which has constructed a formal proof of the Kepler conjecture. The Kepler conjecture asserts that no packing of congruent balls in Euclidean 3-space has density greater than the face-centered cubic packing. It is the oldest problem in discrete geometry. The proof of the Kepler conjecture was first obtained by Ferguson and Hales in 1998. The proof relies on about 300 pages of text and on a large number of computer calculations. [...]_

I wonder if their proof process generated a certificate that would allow a single computer to verify their result in a reasonable amount of time?

<comment><USER3> Writing a formal proof in HOL Light is very much like writing a computer program. If the program run from start to finish without throwing errors, the proof is correct.

Writing a proof takes forever, because you have to take into account all possible corner cases etc, but I'd be surprised if running (hence: verifying) the entire Hale's proof would take more than a few minutes.

<comment><USER2> _I 'd be surprised if running (hence: verifying) the entire Hale's proof would take more than a few minutes._

I would have said the same thing before reading the announcement, but it says it took 5000 hours for some of the computations:

 _The term the_nonlinear_inequalities is defined as a conjection of several hundred nonlinear inequalities. The domains of these inequalities have been partitioned to create more than 23,000 inequalities. The verification of all nonlinear inequalities in HOL Light on the Microsoft Azure cloud took approximately 5000 processor-hours. Almost all verifications were made in parallel with 32 cores, hence the real time is about 5000 / 32 = 156.25 hours_

Would those computations have to be repeated by every verifier? Or is theresome kind of certificate that can be verified faster?

<comment><USER4> Indeed there is, [http://en.wikipedia.org/wiki/PCP_theorem](http://en.wikipedia.org/wiki/PCP_theorem)

<comment><USER2> I suppose I was unclear. I should have asked, is the file ready for me to download? (Not, "does such a certificate exist, in the platonic sense")

</comment></comment></comment></comment></comment><comment><USER5> Note that it was already known that FCC was the best _periodic_ packing (740‰ density); this was proven by Gauss. What was not known was whether there was a more efficient _aperiodic packing_ , such as those described in [http://en.wikipedia.org/wiki/Quasicrystal](http://en.wikipedia.org/wiki/Quasicrystal).

</comment><comment><USER6> There is a good popular math book about Kepler's Conjecture: "Kepler's Conjecture: How Some of the Greatest Minds in History Helped Solve One of the Oldest Math Problems in the World", by George Szpiro. I enjoyed it and recommend it if you want a historical perspective on this problem.

</comment><comment><USER7> I'm not saying that proof is bad or result isn't result enough, or that computer cannot help with math research — that would be ridiculous to say. But I strongly feel that all the news these days about results like this one are something that could be called either "overreaction" or "misunderstanding". Using computer to brute-force through hypothesis _might_ be useful, and works like Voevodsky's one are both cool and useful, but when something like that becomes overrated it seems kinda sad to me.

"Machines do the grunt work and leave humans free for deeper thinking", really? Let me put it this way: what is the most important thing about, say, Pythagorean theorem? From the engineer's point of view it could be ability to find the length of the side of right triangle given the other two or something like that. From the mathematical point of view the most important thing about that or any other theorem is its _proof_. It isn't actually that important that you cannot divide arbitrary angle by 3 equal parts using only compass and the ruler — the way how you prove it is what really matters.

So, once again, autoverifiers are wonderful and so on, but if someone thinks that writing incomprehensible, but _correct_ proofs is as fine as it gets — it's huge mistake to think so. Math is not about constructing and computing, it is about _understanding_ in the first place.

<comment><USER8> The four color theorem was proved by brute forcing every possible contradiction with a computer and finding that no contradiction existed. Therefore the four color theorem was proved to be true. Why is that a problem?

<comment><USER9> At the time, the problem was that most reviewers couldn't understand the code that produced the result, so they felt that they were accepting a result they couldn't meaningfully review or independently confirm.

A lesser issue was philosophical -- it didn't seem like mathematics was "supposed" to be conducted. This second issue has pretty much evaporated in the intervening years.

</comment></comment></comment><comment><USER10> The image on the sidebar is captioned "Oranges are not the only stacking fruit", which is ... interesting.

[http://en.wikipedia.org/wiki/Oranges_Are_Not_the_Only_Fruit](http://en.wikipedia.org/wiki/Oranges_Are_Not_the_Only_Fruit)

<comment><USER11> Interesting spot to plug a book. Is it any good? My book list has been shrinking the last few months.

<comment><USER10> I have no idea! I've never read it, but it has a memorable title. The weird allusion can't have been accidental, though it is pretty strange.

</comment></comment></comment><comment><USER12> The Dense Sphere Packings book can be downloaded here: [https://code.google.com/p/flyspeck/source/browse/trunk/keple...](https://code.google.com/p/flyspeck/source/browse/trunk/kepler_tex/DenseSpherePackings.pdf)

(for some reason the link in the flyspeck project home is dead)

</comment><comment><USER5> I was surprised that face-centered cubic was the winner; I would have thought hexagonal close-packed would be; but the Internet tells me they have identical density, which blows my mind.

<comment><USER13> If you were to sit down with a pile of beads and try to build a big HCP stack and a big FCC stack layer by layer, you'd quickly understand why the densities are the same. The bottom two layers (call them A and B) are identical between the two (without loss of generality), but you then have two distinct ways to proceed.

For HCP, you shift back and add a layer identical to A (that is, the beads of the third layer are directly above the beads of the first) and then repeat, making an ABABAB... pattern. For FCC, you shift to the one allowed position that is _not_ identical to A, making an ABCABC... pattern. (Fig. 1 of this Wikipedia article is at least a little useful for visualizing this: [http://en.wikipedia.org/wiki/Close- packing_of_equal_spheres](http://en.wikipedia.org/wiki/Close- packing_of_equal_spheres))

<comment><USER5> Moreso I think what throws me is that in your example, the FCC cubes are tilted. (i.e. if you build a FCC stack starting with a grid of squares rather than triangles, it's much more difficult to visualize where the closely-packed triangles lay.)

</comment></comment></comment><comment><USER14> What is the definition of "efficient" in this context?

<comment><USER5> Packing density (i.e. ratio of fruits/spheres volume to unit volume).

</comment></comment><comment><USER9> Quote: " ... this provides a foundation which ensures _the computer can check any series of logical statements to confirm they are true_." (emphasis added)

Not really. I wonder if the author of the linked article realizes that the Turing Halting Problem, and Gödel's incompleteness theorems, are deeply connected and prevent the claimed outcome as stated.

<comment><USER15> The quote pretty obviously is referring to checking a proof (series of logical statements) not an arbitrary logical statement. Compared to most reporting on technical subjects, this reporting was wonderful.

<comment><USER9> > The quote pretty obviously is referring to checking a proof (series of > logical statements) not an arbitrary logical statement.

Checking a series of logical statements, and generating a series of logical statements, are not fundamentally different with respect to the issue of undecidability.

> Compared to most reporting on technical subjects, this reporting was > wonderful.

Until I got to the passage I quoted, I agreed completely, and I agree in general in spite of it. It's one of those often-heard statements that make more experienced readers say, "Umm, wait, you really don't want to say it that way."

<comment><USER16> Checking a series of logical statements is just arithmetic.

Generating a series of logical statements is only hard because the formal statements are not generated axiomatically, they are sourced from ill- understood human creativity. Once a formalism is _defined_ it is trivial O(e^n) algorithm to generate all proofs of size n.

[http://math.stackexchange.com/questions/324867/automated- pro...](http://math.stackexchange.com/questions/324867/automated-proof- checking-machine)

<comment><USER5> To be fair, n may be arbitrarily large, hence the undecidability of logics in general. (Not disagreeing with you, just clarifying.)</comment></comment></comment></comment></comment>