He seems to be operating under 3 main delusions (with a healthy dose of caste-related inferiority complex mixed in):
1. Confusion about the differences (or even the fact that they are different) between copyright, trademark, and patent. He copyrighted some software called "EMAIL", which anyone could do. That doesn't give him any ownership of the term "email" (as a trademark would), nor does it register him as the inventor in any way (as a patent would).
2. A belief that being (maybe) the first to name something X makes him the inventor of X. (At best, he could possibly be described as "one of the first to coin the term 'email'.")
3. A belief that naming something X subsequently defines what X is. Hence, he disregards all predecessors as "not X because they are not exactly the same as what I called X".
Over time, his caste-related inferiority complex seems to have evolved into a strong mistrust of recognised authority ("What does Vint Cerf know?") and then further into a conspiracy about the "military-industrial complex".
He seems more sadly deluded than an intentional charlatan.
Even though I don't like Go's explicit error handling, I think this is a very reasonable comment.
I don't like Go's explicit error handling because (1) I think it clutters up your main code path with error-handling logic, and (2) it forces you to always handle errors locally (even if that local code does not have the context to know how to handle the error) or return the error code through multiple layers of functions (back to where it can be handled).
That said, I completely agree that exceptions are also problematic. As you say, you can never really be sure of what exceptions can be thrown. Some languages have a "throw" keyword, in which you're meant to enumerate the list of possible exceptions; but of course, that's a headache to maintain, and is affected by inner code (such as library code) that might be completely out of your control or review. And when should the "throw" keyword be enforced, at compile time or runtime? And what should happen if the "throw" keyword's list of possible exceptions is violated?
Then of course there is the other problem with exceptions, the flip-side to being forced to handle an error locally: As your exception unwinds the stack, it might obliterate some local context that is needed to decide how to handle the error; or it might obliterate some local context that is needed to continue with your original task after the error has been handled!
I see C++'s `std::set_new_handler` function [0] as C++'s less-capable equivalent to Lisp condition handlers. But the function invoked by `std::set_new_handler` lacks the ability to assess local context to decide how to handle the problem.
EDIT: I would love to see a language like Nim incorporate something like Lisp's condition system. Nim already offers "procedural types" (function pointers) [1] and closures [2] to capture variables from the enclosing scope. Nim even offers "anonymous procs" [3], to avoid the need to define new error-handling functions everywhere.
> That said, I completely agree that exceptions are also problematic. As you say, you can never really be sure of what exceptions can be thrown. Some languages have a "throw" keyword, in which you're meant to enumerate the list of possible exceptions; but of course, that's a headache to maintain, and is affected by inner code (such as library code) that might be completely out of your control or review. And when should the "throw" keyword be enforced, at compile time or runtime? And what should happen if the "throw" keyword's list of possible exceptions is violated?
This is something that Nim offers via the `raises` pragma[1]. It is enforced at compile-time and in my experience works rather well.
Pizza Photo Editor is still early-stage -- we're still adding features and increasing the coverage of different object classes in our training data set -- but the core tech is there, and it does have an interactive web UI, so it's already fun to play with. :)
Looking at the example inputs & outputs for ObjectCropBot, it's evident that the challenge is not just detecting the object and clipping it approximately, but tracing a tight precise boundary around it. We've found that DNN/ConvNet-based approaches don't offer the necessary precision, so it's necessary to perform some pre- or post-processing using other Computer Vision techniques. At Object AI, we've developed an "object boundary deduction" pipeline that combines ConvNets with other tech. It's interesting that the blog post that you've linked to makes the same observation!
Wow, this is great! Maybe i'll shelf my efforts a bit , if your online photo editor is this good... I did Google around and find some of these GraphCut-esque refinement techniques, but have yet to find an easily usable one that gave you a good crop with just an outline or tap (or both) - kudos for making one!
As to the lack of precision of ObjectCropBot, I think a lot of that is due to it running based on DeepMask and not SharpMask; Facebook's insight to run the final low-res features back through increasingly less downsized images with sort of skip connections is a good one, and I'd bet the resolution of the results would be a lot better if I just hacked it to use that instead of DeepMask (I think the thing I linked just uses that, pretty much).
Yes, my startup Object AI uses Nim code in production. We have in-house implementations of machine learning, computer vision & image processing code in Nim, using a library called "Nim-Pymod" to integrate with Python's Numpy: https://github.com/jboy/nim-pymod
(As you can see, I was one of the authors of that library in a previous startup. We haven't worked on Nim-Pymod in a while, alas -- I've been focused on the new startup! -- but Nim-Pymod is sufficient for our needs right now.)
Our webserver main-loops are in Python; our number-crunching ML/CV/img-proc code is Python extension modules written in Nim.
As a C++ & Python programmer, I'm a huge fan of Nim, which to me combines the best of both languages (such as Python's clear, concise syntax & built-in collection types, with C++'s powerful generics & zero-cost abstractions), with some treats from other languages mixed in (such as Lisp-like macros and some Ruby-like syntax). I find Nim much more readable than C or C++, especially for Numpy integration. I also find Nim much more efficient to code in than C or C++ (in terms of programmer time).
And Nim is a very extensible language, which enables Nim-Pymod to be more than just a wrapper. For example:
1. Nim-Pymod uses Nim macros (which are like optionally-typed Lisp macros rather than text-munging C preprocessor macros) to auto-generate the C boilerplate functions around our Nim code to create Python extension modules.
2. Nim-Pymod provides statically-typed C++-like iterators to access the Numpy arrays; these iterators include automatic inline checks to catch the usual subtle array-access errors. Nim macros are themselves Nim code, which can be controlled via globals, which in turn can be set by compiler directives; by compiling the Nim code in "production" mode rather than "debug" mode after testing, we can switch off the slowest of these checks to get back to direct-access speed without needing to make any code changes. (And of course Nim's static typing catches type errors at compilation time regardless of the compilation mode.)
3. Nim exceptions have an informative stack trace like Python exceptions do, and Nim-Pymod converts Nim exceptions into Python exceptions at the interface, preserving the stack trace, meaning you have a Python stack trace all the way back to the exact location in your Nim code.
Earlier on in our development of Nim-Pymod, there were some occasional headaches with Nim due to its in-development status. Occasionally the Nim syntax would change slightly and that would break our code (boo). We've also debugged a few problems in the Nim standard library. I suppose these problems are an unfortunate consequence of Nim having a small set of core devs contributing their time (rather than being supported by Microsoft, Sun, Google or Mozilla). Fortunately, these problems seem to have stabilised by now.
The Nim standard library is reasonably large, somewhere between C++ STL (data structures & algos) & Python stdlib (task-specific functionality). I recall that the stdlib could use some standardisation for uniformity, but I haven't been watching it closely for the last year or so.
Being a hosted language (compiles to C/C++/Javascript) which are the biggest pains?
Is there any way to ensure type checking for the exposed interfaces in runtime? Let's say, exposing a function to the host language (C or Javascript) which accepts a String and then passing an integer in the host language.
Did you ever use the javascript backend? How is the experience having a shared code base among very different platforms?
How does interfacing to existing libraries look like? Any examples out there?
Does it really compile to C/C++ or just binary? If it compiles to code, then is it possible to write libraries for mobile platforms as well?
I've never used the JS backend or C++ backend, so I can only talk about the C backend.
With the C backend, the Nim code is transpiled to C code (surprisingly readable C code, as far as auto-generated C goes), which is then compiled to one of: a binary executable, a shared C library, or a static C library: https://nim-lang.org/docs/nimc.html#compiler-usage
If you want to see a shared C library produced by Nim, have a play with some of the examples provided with Nim-Pymod: https://github.com/jboy/nim-pymod/tree/master/examples
It auto-generates the appropriate Python C API boilerplate functions around your Nim functions, then compiles the whole thing as a shared C library, exposing the auto-generated functions in the shared library.
Regarding runtime type-checking: Again, I can only talk about the C backend. The type checking provided by shared or static C libraries will be whatever the C compiler enforces... I haven't tested whether (or how much) this can be violated.
Nim-Pymod does auto-generate the Python->C type-checking code for you, so you can't (for example) pass in a Python string when an int is expected by your Nim function.
I think the parent's point was about whether the AlphaGo AI can generalize to a different board size (as a human player presumably can) rather than about what is the normal Go board size, or what board sizes are easier or harder.
The parent was suggesting that while a human might possess a general understanding of Go, performing comparably regardless of board size ("The human would play on the same level"), the AlphaGo AI in contrast might drop significantly in capability on a board of different size. In effect, the AlphaGo AI might just be a very well-fitted (perhaps even overfitted) machine-learned algorithm on a 19x19 board, lacking a fundamental "understanding" of the game that could generalize to a different board size.
Hi Marcus, have you ever taken a look at Nim? It's quite similar to Swift in several respects, but it has a primarily Python-like syntax (including indentation by blocks rather than braces) with bits of Ruby & others mixed in.
At work, we use Python as our interpreted language & Nim as our fast, strongly-typed, compiled language. We created Nim-Pymod to enable Nim code to be compiled into Python modules: https://github.com/jboy/nim-pymod
There's also a web-framework in Nim called Jester, which describes itself as "a Sinatra-like web framework": https://github.com/dom96/jester
Embarrassing confession. I've looked at Nim before and don't want to use it because I think the crown is a ridiculous logo. Not being big on authority and not being big on people that think too highly of themselves, I'm suspicious of the entire project simply because of that poorly drawn crown.
Just in case anyone else is tired and drew a blank and needs to google that, the confusion was that of strong vs weak not dynamic vs static. Strong vs weak applies to explict vs implicit type changes. Dynamic vs static applies to run time or compile time type assignment.
1. Confusion about the differences (or even the fact that they are different) between copyright, trademark, and patent. He copyrighted some software called "EMAIL", which anyone could do. That doesn't give him any ownership of the term "email" (as a trademark would), nor does it register him as the inventor in any way (as a patent would).
2. A belief that being (maybe) the first to name something X makes him the inventor of X. (At best, he could possibly be described as "one of the first to coin the term 'email'.")
3. A belief that naming something X subsequently defines what X is. Hence, he disregards all predecessors as "not X because they are not exactly the same as what I called X".
Over time, his caste-related inferiority complex seems to have evolved into a strong mistrust of recognised authority ("What does Vint Cerf know?") and then further into a conspiracy about the "military-industrial complex".
He seems more sadly deluded than an intentional charlatan.