Why is it not open source? I smell lock in.
100 karma · joined July 13, 2013
In the case of Erlang, for instance, it provides a built-in remote shell which allows one to connect to a running Erlang process, get multitude of information about the VM, loaded code, etc.
As long as there is a convenient way to maintain a running system, that same way can be used for hacking.
Those three have in common the trait that they support single language runtime: Erlang for Erlang on Xen, OCaml for MirageOS, and Haskell for HaLVM.
Statically typed languages like Haskell and Rust require the programmer to list all possible cases when matching on a value.
In Elixir macros are imported into local scope only when the user explicitly asks for it. Most libraries provide a `__using___` macro that can modify current scope.
For instance, `use ExUnit.Case` allows you to write tests like this
test "my test case" do
assert funcall() == "value"
end
require ExUnit.Case
ExUnit.Case.test "my test case" do
ExUnit.Assertions.assert funcall() == "value"
end
The consensus in the community right now is to not get carried away with macros and DSLs. Even if your library provides a DSL, it should be based on a functional API that is mostly usable without macros.
And lastly, remember that `use`, `require`, and `import` modify only the current lexical scope. I wrote this macro[1] that replaces the built-in `|>` operator with a version that prints its output to the console. You can `use PipeInspect` inside one function and only that function's body will get the overriden implementation of `|>`.
Cheers.
[1]: http://queue.acm.org/detail.cfm?id=2068896 [2]: http://static.rust-lang.org/doc/0.10/guide-macros.html
I would just like to add that in Elixir meta-programming does not always have to deal with macros.
For example, this program
somelist = ... # any kind of data,
# could be loaded from file
defmodule M do
for {name, value} <- somelist do
def lookup(unquote(name)), do: unquote(value)
end
end
While it is true that Erlang's parse transforms are more powerful by default, nothing would stop a willing heart from implementing token-level macros for Elixir. It would be a separate program that would parse source code before passing it on to the Elixir compiler.
But given the straightforwardness of code generation in Elixir (as exemplified by the code above), coming up with such a program might prove to be even easier for the user than dealing with parse transforms in Erlang. This is a speculation on my part, so it'd be curious to see if anyone goes in this direction in the future.
$ clang -v
clang version 3.3 (tags/RELEASE_33/final)
Target: x86_64-apple-darwin12.4.0
double pow(double);
LLVM bitcode Assembly
// a*a*a*a*a*a
%1 = fmul double %a, %a | movaps %xmm0, %xmm1
%2 = fmul double %1, %a | mulsd %xmm1, %xmm1
%3 = fmul double %2, %a | mulsd %xmm0, %xmm1
%4 = fmul double %3, %a | mulsd %xmm0, %xmm1
%5 = fmul double %4, %a | mulsd %xmm0, %xmm1
ret double %5 | mulsd %xmm0, %xmm1
| movaps %xmm1, %xmm0
// a*a*a*a*a*a -ffast-math
%1 = fmul fast double %a, %a | mulsd %xmm0, %xmm0
%2 = fmul fast double %1, %1 | movaps %xmm0, %xmm1
%3 = fmul fast double %1, %2 | mulsd %xmm1, %xmm1
ret double %3 | mulsd %xmm0, %xmm1
| movaps %xmm1, %xmm0
// (a*a*a)*(a*a*a)
%1 = fmul fast double %a, %a | movaps %xmm0, %xmm1
%2 = fmul fast double %1, %a | mulsd %xmm0, %xmm0
%3 = fmul fast double %2, %2 | mulsd %xmm1, %xmm0
ret double %3 | mulsd %xmm0, %xmm0Seriously, I didn't even try to read the text on the page because its overall mood implies the text is not important at all.
This site simply looks like someone's homework rather than an info site for a conference.
I think we've had enough of those in the past decade. Each one has something new to offer, but at the same time it disperses attention of the programmer crowd and so less effort is put into each language's development.
I think we need to experiment more with single-purpose languages. I'm not saying DSLs because those are mostly embedded syntactic constructs in existing languages. By single-purpose I mean an independent language (not just new syntax, but semantics as well, and possibly new runtime) that does one thing and does it well.
I believe such a language will have much more luck in becoming the single good enough solution for a particular problem (any problem it chooses to address, but only that one). There is really no hope for any general-purpose language to be a good fit for the whole wide spectrum of problems modern computing needs to solve.
Let's analyze the classical problem. After you pick a door, one of the remaining two doors is opened.
With more doors (say, 11), it wouldn't make for an interesting show if you opened 9 more doors after the first one. A more reasonable approach would be to open one additional door and let the player choose to switch or stay with their choice each time. But that would only complicate the explanation, of course.
Let's dissect the 11-door case. We will do the following: the player picks a door, then the host a) opens one other door; b) opens 50% of the remaining doors; c) leaves one door closed.
IMO, the (a) case is the closest generalization of the original problem. You have a 1/11 chance to pick the car door on your first try. Then, one other door is opened, and if you switch to another random door, the best case probability of you getting the car is 10/11 * 1/9 = 10/99. This number is slightly bigger than 1/11.
In the (b) case you get a better result when switching, but to me that just looks like adding artificial bias. Obviously, the (c) case looks best because you've removed so much choice by leaving only one other door closed. Adding more doors does one thing: improves the probability of switching. That's good if this is what you're aiming for. But this turns it into a completely different problem.
So, you can see that the result depends on what you want to get. If you try to stay faithful to the original problem statement, adding more doors actually makes the benefit of switching less obvious.
In summary, I'm convinced that 3 is not an accidental number in the original problem statement. Whoever came up with it, they knew how to remove space for speculation by providing the only reasonable thing to do: open 1 door (or 50% of the doors) and leave 1 other door closed.
In the classical problem with 3 doors, if you pick a door with a car, the host will only open 1 other door.
In your demo, if I use 40 doors and pick one, the host opens all other doors but one. Why?
If the one of those 40 I pick has a car, will the host open all remaining doors? That doesn't seem to be the case for the 3-door variant.
It's just an advertisement like any other. I'm sure the people responsible for the content of the FAQ know their target audience, so they know the wording will work for those whose attention they care about.
It is good that we, technical people, understand how completely worthless those words are. It begs for the "citation needed" label.
The question for me is this: do ordinary people (non-programmers in this case) really believe in most of the things ads tell them?
[1]: https://groups.google.com/d/msg/docker-dev/OcpLrYti64Q/Ue6vP... [2]: https://groups.google.com/d/msg/docker-user/4acVRnOd9Dw/RZRc...
If it's a mockup editor, then it should be easy to customize from JS to make anything useful from the mockup.
If it's a site builder, better add support for templates, so that one would then be able to drag and drop data (e.g. json) onto the canvas and bind it to a template to automatically populate a whole set of elements at once.
P.S. No matter how slick your UI is, if it's not programmable, it's not useful.
As long as you don't leak panics outside of your package, it's OK to use them for non-local error returns.