I meant that variables, once bound, cannot be unbound and then rebound. My point was that since a variable can first be unbound, and later bound, I don't really see the point to making them "unbound-then-bind-once" instead of "bind-anytime".
I understand why data structures are immutable, though that's annoying. I can sort of understand why one might want to make them "bind-once", where the compiler never allows a variable to be unbound. I don't understand why they can have an unbound state, and then be bound, but not later re-bound.
Democrats: Keep porn and violence away from kids. And adults too. Don't fucking swear. Think of the children! At least we're not as bad as...
Republicans: Don't marry another man (or woman). The Internet will die unless Comcast can throttle BitTorrent. Think of the fetuses! (Until they're born, then fry 'em all.)
And that's a very narrow range, from someone who never does as much political research as I should. At least Obama has actually said (or hinted?) that he is in favor of net neutrality...
A commonly mentioned benefit of web apps is portability, but this isn't really true either because of the variety (and inconsistency) of web browsers.
However, many browsers are portable themselves, and it is possible to make a cross-browser toolkit.
What I think is a better approach is something like the solution we see with Qt, where you write your program once, then compile it for different platforms, and it looks native every time.
Except that if you're going to compile it for every platform, then everyone who builds such an app will compile it for the platform they need, and ignore the platforms they don't. Web apps, being interpreted, are more automatically portable.
And these are not the only advantages.
They're slow, crappy, and often insecure.
Slow -- not significantly slower than a desktop app, as far as the user knows. Very few apps actually need to be faster than a web app.
Crappy and often insecure -- well, many of them, I suppose. That's not the fault of the platform. It is possible to build excellent, secure web apps, as Gmail proves. (If you didn't know, https://mail.google.com/)
Two of us run Linux, two of us run OS X, and two of us run Windows. On OS X, one uses vim and one uses TextMate; on Windows, one uses Visual Studio and one uses Eclipse; on Linux, one is a tester, and I use Kate.
While I'm at it, two of us use the Dvorak keyboard layout.
To force us all to use one platform, and one environment, would be to drop our productivity severely for the learning curve, and permanently as we all work on a platform that doesn't as closely match the way we work.
Now, forcing one language/framework, I can understand -- we mostly use Rails, and pretty much entirely Ruby. But what would be the point of forcing one dev environment?
Is it so that they could easily give my laptop to someone else, or give me a different machine? We basically get a budget with which to pick out our own hardware. This laptop is mine but for a technicality: if I ever leave, they'll take it back and reformat it for the next person.
I agree with many of the other sentiments here -- programmers should not be moved from project to project. But depending on the projects, it may be at least as difficult to learn the new project as it is to learn a new language/framework.
But unless you've made an exceedingly poor choice of language/framework, you should still be able to pick (mostly) your own dev tools.
I'd definately go with perforce for a large scale project - if only for the relatively pain free merging....
Given that a merge is the most frequent operation performed by a distributed VCS, I'd say Git probably has an edge there, or no one would put up with it.
How many "nodes" are you going to run on the same machine?
If the only problem is lack of SMP support, I'll run as many as I have CPUs. Or fewer, given that the target app doesn't need resources.
Each ruby process consumes a great quantity of resources, the elimination of that resource drain is the entire purpose behind Erlang's tiny-stack microthreads
Ruby 1.9 has "fibers". (Disclaimer: I haven't read anything beyond that they exist.)
You've created a dead-simple message queue based on delivery of messages to a thread-owned linked-list.
That's the implementation, right. I'm doing the simplest thing that can possibly work, and I'm trying to spec out the API as much as possible in the meantime.
Erlang implements externally scheduled pattern-based actor message delivery
I actually have no idea what that means. Trying to deconstruct...
"Pattern-based" -- I figure that most often, the patterns are used to fork based on the "type" of message received, where "type" is explicitly stated in the message. Given that, I'm simply sending arbitrary method calls and branching that way. If people want to do something more advanced, they can implement method_missing, or have the method itself branch based on whatever.
"actor" -- from Wikipedia:
in response to a message that it receives, an actor can make local decisions, create more actors, send more messages, and determine how to respond to the next message received.
Sounds like exactly what I've created; an object attached to a thread. The difference is, mine uses OO primitives, and I like Ruby syntax, whereas Erlang uses functional primitives, and I don't like Erlang syntax.
One key element of these implementations is that they do NOT consume a thread per actor.
That's, again, an implementation detail. I'm building the simplest thing that can possibly work, and I'm also trying to write specs -- where I can, I'm trying to make it the least predictable that will meet the spec.
Once that's done, I can tune the implementation. I don't believe Ruby will forever be incapable of doing proper concurrency; Python actually likes the GIL, whereas Ruby seems to be doing it for the benefit of C extensions. Therefore, any non-C implementation (JRuby, IronRuby), or any alternative implementations (Rubinius), won't be so constrained.
If you skip the "message passing" step and go straight to RPC, you wind up with something that ignores the complexity of the network -- the network fails, messages get lost, dropped, or ignored.
Which causes an exception to be raised, just as with message passing in Erlang. (Again, correct me if I'm missing something.)
Given this ignorance of the medium, RPC interfaces assume synchronous message delivery and response, which then precludes asynchronous delivery and response.
Asynchronous delivery is reasonably possible -- in fact, for the system I'm building, it's the default. Synchronicity is easy, because I want to make the easy things easy, but it requires an additional method call -- for example:
object.method # some intermediate object object.method.now # actual result object.method.then{...} # callback
you need to version your objects (or upgrade your entire network in lockstep)
True of protocols, also. (Keep in mind, calling any method on a DRb "proxy object" will result in a message being sent to the other end, where the real object resides.)
It's an error to conflate messages with objects
Actually, objects are components of the message here. The message is a method call.
I read it, you're just missing the point. JRuby has no microthreads and isn't Ruby. I could say that IronPython provides t
How is this different than Erlang's PIDs, other than being syntactically cleaner?
Sending a local process a message is the same as sending a remote process a message.
Yep. Got that, as demonstrated above. The fact that Ruby uses method_missing to accomplish this is an implementation detail.
The message and protocol formats are well-defined, such that one can implement an Erlang "node" in any language
DRb is perhaps not as well-defined -- I think most Rubyists would rather speak an appropriate protocol, rather than a language-specific RPC.
And yes, Erlang's RPC is language-specific -- it supports the features needed to run Erlang programs. Implementations in other languages doesn't make it natural to the other language.
You mean one of the some of the most complex pieces of code in Erlang -- the software that manages a supervision tree of processes, handling failure across the local system as well as remote nodes?
Yeah. I'm not sure if I want to duplicate that, or find something simpler, though I still don't see it as incredibly complex. The trick is to make it simpler for the end-user (application programmer) -- I'm not convinced Erlang does that.
So no concurrency.
Congrats for not reading. Allow me to summarize for your short attention span: JRuby.
Then please stop commenting on these systems
Why should I?
This is Slashdot. If you want more intelligent comments, educate me or mod me down.
An ideal interface is one that a novice can just sit down to and automatically "know" how to use it.
Wrong. That makes it discoverable, perhaps even intuitive -- but it is not always desirable.
For me, the ideal interface is one which requires training on the order of no more than a few days (I won't take a month-long course in Vim) -- and, of course, it should be productive enough, and used enough, to pay for the learning curve.
So for me, the ideal file-management UI is a Unix commandline, because I'm faster there than anywhere else, and I already learned it out of curiosity.
The way people automatically "know" how to use a comb or automatically "know" how to drive a car (even if they aren't good at it).
Neither is true.
We know how to drive a car because we've ridden in cars our whole lives, and we've watched our parents do it. And there's still a dozen things you don't necessarily know -- like how to shift gears, or make a turn signal.
A comb is even moreso -- if you saw a comb, having never had it demonstrated to you before, how would you know it had anything at all to do with hair, let alone how to use it?
So, you know how to use your GUI because you learned how to use similar GUIs before. No UI would ever meet your criteria without also being similar to something the user has used before -- and given that every user is coming from a different background, there is no universal standard for "good" or "bad" UIs.
The best we could do is follow a majority vote -- which means the worth of a UI is based on how close it is to Windows.
You wrote a SMP-capable micro-stack green thread scheduler in Ruby, over the weekend?
Nope. I used the existing Thread API. It is theoretically, but not actually, SMP-capable. It should be portable to JRuby, which uses Java threads.
What I did was port the message-passing to a Ruby paradigm -- so, much simpler than it sounds. Essentially, I wrote a proxy for objects -- every method call to such an object stacks up in a queue, and is sent (in the object's thread).
It's not so much a direct port of Erlang as a mapping of what I found valuable in the Erlang philosophy. A class can be written with almost no thought to concurrency, and then used concurrently.
It supports transparent multi-node messaging?
No, Ruby supports that on its own, with DRb.
What I haven't figured out is the exception handling.
If you pulled this off in Ruby, which doesn't even -support- native threads
Ruby 1.9, which does. Unfortunately, it takes a page out of Python and uses a global interpreter lock, so only one Ruby bytecode can be executing at a time -- but again, I believe JRuby does real (actually concurrent) threads.
Or, more likely, you're just another know-it-all shithead who implemented 1% of the solution to a problem you don't even understand, and are now trumpeting it on the blogowww-twittersphere.
That's exactly why I'm not -- no blog, no big announcements until it's done.
Furthermore, it is actually pretty systematic, once you get over those initial differences. It is a poor programmer who cannot master both worlds.
I've written a decent amount of Erlang. I can do it.
Point is, why would I want to?
That's simply wrong. Dynamic code upgrade still works, native or not. It's the unloading of older native code from memory that is not being done (this is safe, but could be a memory leak in a very long running server).
Ah, you're right.
I do consider it a fairly severe deficiency that you get to choose between interpreted bytecode and a memory leak.
Well, good luck, and see you in 20 years.
Done, in Ruby. Took a weekend. I'm polishing it now.
Actually, there are quite a few good reasons for this, largely around the complete elimination of mutexing and locks.
...What? No, the elimination of mutexing and locks is made possible by a shared-nothing architecture.
Oooooh, a language is faulty because it has a syntax with which you are not familiar.
Hey, I mentioned Ruby. I don't mind LISP, either.
The point is not that the language is unfamiliar, the point is that it's inconsistent (and unfamiliar) for no good reason. I use English, but I could make a lot of the same criticisms about it.
They're just lists of numbers;
In that case, the argument becomes, "Erlang has very poor text-processing, if any at all."
If Erlang has text-processing functions that are designed to operate on these "lists of numbers", then yeah, it's pretty much going to be ASCII. And how are Erlang source files read? Could be "neither ASCII nor Latin1" if you like, but they can't be Unicode unless the parser is actually Unicode-aware.
As I understand it, you should look at variables in functional programming languages like Erlang more like those in a mathematical formula; such programs can be proven correct a lot easier, and since variables are effectively immutable
All of this is based on the premise that Erlang is a functional language. It's not purely-functional, and I just don't see the point of doing it half-assedly. Erlang is effectively an imperative language dressed up like a functional language.
And they're not immutable -- they can be unbound. As I understand it, this unboundedness is detected at runtime, not compiletime. If it was detected at compiletime, you'd have a valid point.
it facilitates forking the line of execution in a way that would not be possible without all kinds of semaphores and other concurrency stuff
Except that's not how Erlang does concurrency. It does concurrency with explicit "processes" (green threads) and message-passing.
Now, it does make these very easy, and you can get it to distribute processes among a few real OS threads (one per core) -- so it's still very cool. But you're thinking of languages like Haskell, which can be automagically threaded. Erlang is manually threaded, it's just much easier to think in threads (or "processes") -- they're effectively a language feature.
1. Invariable variables. This appears to have been done for no reason other than the designer's preference. In fact, it's not strictly true -- variables can be unbound, and later bound. They just can't be re-bound once bound.
2. Weird syntax. Why, exactly, are there three different kinds of (required) line endings? It seems as though the syntax is designed to be as different from C as possible, while maintaining at least as many quirks. Moreso, even -- when constructing normal, trivial programs, you're going to hit most language features head-on and at their worst. Where's my 'print "hello\n"' that works most other places?
I don't believe the important features of Erlang are mutually-exclusive with the sane syntax of, say, Ruby or Python.
3. Not Unicode-ready. Strings are defined as ASCII -- maybe latin1. But there's no direct unicode support in the language -- if you're lucky, there are functions you can pipe it through.
There are other things I haven't mentioned, mostly implementation-specific -- things like the fact that function-reloading cannot be done when you natively-compile (with hipe) for extra speed. My plan is to take the features I actually like from Erlang and implement them elsewhere, in a language I can actually stomach for its real tasks.
it's easier for most people to fudge through something they vaguely remember doing by pictures than it is for them to memorize a set of arcane terminal they vaguely remember.
I've found that the documentation is such that I only need a vague memory of the terminal, just as I only need a vague memory of the GUI. Obviously, YMMV.
That said, while I find the terminal is more productive, I also find that many GUIs are much more discoverable than their CLI counterparts, and that the learning curve is far less.
Truecrypt is mighty close but portability is a killer for any enterprise to manage.
This is WTF #1.
Under what circumstances would the encrypted volume need to be accessed from an OS other than the primary one for the laptop? For that matter, under what circumstances would an "enterprise" not standardize on an OS?
If you're going to say "recovery", that implies the laptop isn't being backed up, which is a WTF on its own.
With Truecrypt hopefully you have a copy of the master key so you should be fine. With encrypted LVM solutions things can get all kinds of hairy though.
With LuKS, you can use a fair number of keys with an encrypted volume -- either keyfiles or passphrases. So if you need a master key, that's easily possible.
I wish Truecrypt supported fingerprint authentication.
This is WTF #2.
A fingerprint is completely useless here. Remember that a copy of your fingerprint must be stored somewhere in the laptop to compare against, and that a fingerprint can never scan twice. It can therefore not be used as a key -- the best you could do is a boolean check.
As in: if (fingerprints_match) { unlock_stuff(); }
As in, all an attacker needs to do is use their non-keyprinted version of Truecrypt.
Right now it looks like Computrace's LoJack for Laptops is still the best option for enterprise deployment.
This is WTF #3.
LoJack is, what, a 10-line cron job? And from a quick Google, I see nothing about crypto, only about erasing after the fact.
In other words, all an attacker needs to do if they want to sell the laptop is wipe the drive. All they need to do if they want to get the data is image the drive, and work without a network connection. Crypto will at least protect against the latter attack.
That is exactly the proprietaryness holding it back. Were Flash a completely open standard, with competing open source implementations, Apple could just build their own version. As it is, they have to deal with Adobe.
And it disproves your point -- the iPhone is, indeed, used by people other than greasy GNU hippies. Therefore, people other than greasy GNU hippies are affected by Flash being proprietary.
Some people might say I'm comparing apples to oranges, but Apples dont' cost 17,000 times more than oranges.
Granted, your numbers may not be entirely accurate, but the whole texting thing is out of control. The mobile world is also a fair example of what could happen to the rest of the Internet, if net neutrality is not maintained -- anyone looking forward to 10c/email?
Alright, I realize it makes me a dirty hippie that I don't like Flash (and don't always even have it installed), but I'm about to go on a road trip. I've been looking for interesting, educational videos to download, but this one would at least force me to muck about in Firebug.
At the very least, provide a download link! I've signed up to Vimeo and Sribd just to get their download links.
Seriously, I'm looking at the spec, and at a first glance, I don't see any kind of clause that I thought was there before -- the clause which says that this spec may not be used to implement a player.
If it really is entirely open, that's great news for Gnash and friends!
Slashdot Mirror
I'm sorry, that sentence really wasn't clear...
I meant that variables, once bound, cannot be unbound and then rebound. My point was that since a variable can first be unbound, and later bound, I don't really see the point to making them "unbound-then-bind-once" instead of "bind-anytime".
I understand why data structures are immutable, though that's annoying. I can sort of understand why one might want to make them "bind-once", where the compiler never allows a variable to be unbound. I don't understand why they can have an unbound state, and then be bound, but not later re-bound.
"Jump the shark" has jumped the shark?
Democrats: Keep porn and violence away from kids. And adults too. Don't fucking swear. Think of the children! At least we're not as bad as...
Republicans: Don't marry another man (or woman). The Internet will die unless Comcast can throttle BitTorrent. Think of the fetuses! (Until they're born, then fry 'em all.)
And that's a very narrow range, from someone who never does as much political research as I should. At least Obama has actually said (or hinted?) that he is in favor of net neutrality...
A commonly mentioned benefit of web apps is portability, but this isn't really true either because of the variety (and inconsistency) of web browsers.
However, many browsers are portable themselves, and it is possible to make a cross-browser toolkit.
What I think is a better approach is something like the solution we see with Qt, where you write your program once, then compile it for different platforms, and it looks native every time.
Except that if you're going to compile it for every platform, then everyone who builds such an app will compile it for the platform they need, and ignore the platforms they don't. Web apps, being interpreted, are more automatically portable.
And these are not the only advantages.
They're slow, crappy, and often insecure.
Slow -- not significantly slower than a desktop app, as far as the user knows. Very few apps actually need to be faster than a web app.
Crappy and often insecure -- well, many of them, I suppose. That's not the fault of the platform. It is possible to build excellent, secure web apps, as Gmail proves. (If you didn't know, https://mail.google.com/)
Two of us run Linux, two of us run OS X, and two of us run Windows. On OS X, one uses vim and one uses TextMate; on Windows, one uses Visual Studio and one uses Eclipse; on Linux, one is a tester, and I use Kate.
While I'm at it, two of us use the Dvorak keyboard layout.
To force us all to use one platform, and one environment, would be to drop our productivity severely for the learning curve, and permanently as we all work on a platform that doesn't as closely match the way we work.
Now, forcing one language/framework, I can understand -- we mostly use Rails, and pretty much entirely Ruby. But what would be the point of forcing one dev environment?
Is it so that they could easily give my laptop to someone else, or give me a different machine? We basically get a budget with which to pick out our own hardware. This laptop is mine but for a technicality: if I ever leave, they'll take it back and reformat it for the next person.
I agree with many of the other sentiments here -- programmers should not be moved from project to project. But depending on the projects, it may be at least as difficult to learn the new project as it is to learn a new language/framework.
But unless you've made an exceedingly poor choice of language/framework, you should still be able to pick (mostly) your own dev tools.
I'd definately go with perforce for a large scale project - if only for the relatively pain free merging....
Given that a merge is the most frequent operation performed by a distributed VCS, I'd say Git probably has an edge there, or no one would put up with it.
Erlang's a pure functional language
Erlang is a vaguely functional language. Haskell is a pure functional language.
How many "nodes" are you going to run on the same machine?
If the only problem is lack of SMP support, I'll run as many as I have CPUs. Or fewer, given that the target app doesn't need resources.
Each ruby process consumes a great quantity of resources, the elimination of that resource drain is the entire purpose behind Erlang's tiny-stack microthreads
Ruby 1.9 has "fibers". (Disclaimer: I haven't read anything beyond that they exist.)
You've created a dead-simple message queue based on delivery of messages to a thread-owned linked-list.
That's the implementation, right. I'm doing the simplest thing that can possibly work, and I'm trying to spec out the API as much as possible in the meantime.
Erlang implements externally scheduled pattern-based actor message delivery
I actually have no idea what that means. Trying to deconstruct...
"Pattern-based" -- I figure that most often, the patterns are used to fork based on the "type" of message received, where "type" is explicitly stated in the message. Given that, I'm simply sending arbitrary method calls and branching that way. If people want to do something more advanced, they can implement method_missing, or have the method itself branch based on whatever.
"actor" -- from Wikipedia:
in response to a message that it receives, an actor can make local decisions, create more actors, send more messages, and determine how to respond to the next message received.
Sounds like exactly what I've created; an object attached to a thread. The difference is, mine uses OO primitives, and I like Ruby syntax, whereas Erlang uses functional primitives, and I don't like Erlang syntax.
One key element of these implementations is that they do NOT consume a thread per actor.
That's, again, an implementation detail. I'm building the simplest thing that can possibly work, and I'm also trying to write specs -- where I can, I'm trying to make it the least predictable that will meet the spec.
Once that's done, I can tune the implementation. I don't believe Ruby will forever be incapable of doing proper concurrency; Python actually likes the GIL, whereas Ruby seems to be doing it for the benefit of C extensions. Therefore, any non-C implementation (JRuby, IronRuby), or any alternative implementations (Rubinius), won't be so constrained.
If you skip the "message passing" step and go straight to RPC, you wind up with something that ignores the complexity of the network -- the network fails, messages get lost, dropped, or ignored.
Which causes an exception to be raised, just as with message passing in Erlang. (Again, correct me if I'm missing something.)
Given this ignorance of the medium, RPC interfaces assume synchronous message delivery and response, which then precludes asynchronous delivery and response.
Asynchronous delivery is reasonably possible -- in fact, for the system I'm building, it's the default. Synchronicity is easy, because I want to make the easy things easy, but it requires an additional method call -- for example:
you need to version your objects (or upgrade your entire network in lockstep)
True of protocols, also. (Keep in mind, calling any method on a DRb "proxy object" will result in a message being sent to the other end, where the real object resides.)
It's an error to conflate messages with objects
Actually, objects are components of the message here. The message is a method call.
I read it, you're just missing the point. JRuby has no microthreads and isn't Ruby. I could say that IronPython provides t
Your class can't be used concurrently, because Ruby is not actually SMP-capable.
But JRuby is.
I should note that, in a simple test, Erlang got about three times slower when I enabled SMP mode.
It can't be used on multiple systems, because the messaging can't be used across nodes.
Except it can, with DRb. Which also provides sloppy SMP support -- just run two nodes on the same machine.
Single-machine, non-concurrency queue-based message passing systems are what we usually call "linked lists".
Erm, what? I know what a linked list is, and I don't see the comparison.
DRb is just another RPC implementation.
...and Erlang's RPC isn't?
In erlang, processes and (immutable) messages are first class entities, whether they're operating locally or remotely.
Again, I have to go, "huh?"
DRb allows objects to be created and "passed" between the machines. I could do:
remote_object = DRB::whatever :arg1, :arg2 ...
remote_object.some_method
How is this different than Erlang's PIDs, other than being syntactically cleaner?
Sending a local process a message is the same as sending a remote process a message.
Yep. Got that, as demonstrated above. The fact that Ruby uses method_missing to accomplish this is an implementation detail.
The message and protocol formats are well-defined, such that one can implement an Erlang "node" in any language
DRb is perhaps not as well-defined -- I think most Rubyists would rather speak an appropriate protocol, rather than a language-specific RPC.
And yes, Erlang's RPC is language-specific -- it supports the features needed to run Erlang programs. Implementations in other languages doesn't make it natural to the other language.
You mean one of the some of the most complex pieces of code in Erlang -- the software that manages a supervision tree of processes, handling failure across the local system as well as remote nodes?
Yeah. I'm not sure if I want to duplicate that, or find something simpler, though I still don't see it as incredibly complex. The trick is to make it simpler for the end-user (application programmer) -- I'm not convinced Erlang does that.
So no concurrency.
Congrats for not reading. Allow me to summarize for your short attention span: JRuby.
Then please stop commenting on these systems
Why should I?
This is Slashdot. If you want more intelligent comments, educate me or mod me down.
An ideal interface is one that a novice can just sit down to and automatically "know" how to use it.
Wrong. That makes it discoverable, perhaps even intuitive -- but it is not always desirable.
For me, the ideal interface is one which requires training on the order of no more than a few days (I won't take a month-long course in Vim) -- and, of course, it should be productive enough, and used enough, to pay for the learning curve.
So for me, the ideal file-management UI is a Unix commandline, because I'm faster there than anywhere else, and I already learned it out of curiosity.
The way people automatically "know" how to use a comb or automatically "know" how to drive a car (even if they aren't good at it).
Neither is true.
We know how to drive a car because we've ridden in cars our whole lives, and we've watched our parents do it. And there's still a dozen things you don't necessarily know -- like how to shift gears, or make a turn signal.
A comb is even moreso -- if you saw a comb, having never had it demonstrated to you before, how would you know it had anything at all to do with hair, let alone how to use it?
So, you know how to use your GUI because you learned how to use similar GUIs before. No UI would ever meet your criteria without also being similar to something the user has used before -- and given that every user is coming from a different background, there is no universal standard for "good" or "bad" UIs.
The best we could do is follow a majority vote -- which means the worth of a UI is based on how close it is to Windows.
OH come on this is bullshit.
Which seems to be your way of saying "exactly right."
Even lisp and scheme aren't "purely functional"
Right. Haskell is.
You wrote a SMP-capable micro-stack green thread scheduler in Ruby, over the weekend?
Nope. I used the existing Thread API. It is theoretically, but not actually, SMP-capable. It should be portable to JRuby, which uses Java threads.
What I did was port the message-passing to a Ruby paradigm -- so, much simpler than it sounds. Essentially, I wrote a proxy for objects -- every method call to such an object stacks up in a queue, and is sent (in the object's thread).
It's not so much a direct port of Erlang as a mapping of what I found valuable in the Erlang philosophy. A class can be written with almost no thought to concurrency, and then used concurrently.
It supports transparent multi-node messaging?
No, Ruby supports that on its own, with DRb.
What I haven't figured out is the exception handling.
If you pulled this off in Ruby, which doesn't even -support- native threads
Ruby 1.9, which does. Unfortunately, it takes a page out of Python and uses a global interpreter lock, so only one Ruby bytecode can be executing at a time -- but again, I believe JRuby does real (actually concurrent) threads.
Or, more likely, you're just another know-it-all shithead who implemented 1% of the solution to a problem you don't even understand, and are now trumpeting it on the blogowww-twittersphere.
That's exactly why I'm not -- no blog, no big announcements until it's done.
Furthermore, it is actually pretty systematic, once you get over those initial differences. It is a poor programmer who cannot master both worlds.
I've written a decent amount of Erlang. I can do it.
Point is, why would I want to?
That's simply wrong. Dynamic code upgrade still works, native or not. It's the unloading of older native code from memory that is not being done (this is safe, but could be a memory leak in a very long running server).
Ah, you're right.
I do consider it a fairly severe deficiency that you get to choose between interpreted bytecode and a memory leak.
Well, good luck, and see you in 20 years.
Done, in Ruby. Took a weekend. I'm polishing it now.
Actually, there are quite a few good reasons for this, largely around the complete elimination of mutexing and locks.
...What? No, the elimination of mutexing and locks is made possible by a shared-nothing architecture.
Oooooh, a language is faulty because it has a syntax with which you are not familiar.
Hey, I mentioned Ruby. I don't mind LISP, either.
The point is not that the language is unfamiliar, the point is that it's inconsistent (and unfamiliar) for no good reason. I use English, but I could make a lot of the same criticisms about it.
They're just lists of numbers;
In that case, the argument becomes, "Erlang has very poor text-processing, if any at all."
If Erlang has text-processing functions that are designed to operate on these "lists of numbers", then yeah, it's pretty much going to be ASCII. And how are Erlang source files read? Could be "neither ASCII nor Latin1" if you like, but they can't be Unicode unless the parser is actually Unicode-aware.
As I understand it, you should look at variables in functional programming languages like Erlang more like those in a mathematical formula; such programs can be proven correct a lot easier, and since variables are effectively immutable
All of this is based on the premise that Erlang is a functional language. It's not purely-functional, and I just don't see the point of doing it half-assedly. Erlang is effectively an imperative language dressed up like a functional language.
And they're not immutable -- they can be unbound. As I understand it, this unboundedness is detected at runtime, not compiletime. If it was detected at compiletime, you'd have a valid point.
it facilitates forking the line of execution in a way that would not be possible without all kinds of semaphores and other concurrency stuff
Except that's not how Erlang does concurrency. It does concurrency with explicit "processes" (green threads) and message-passing.
Now, it does make these very easy, and you can get it to distribute processes among a few real OS threads (one per core) -- so it's still very cool. But you're thinking of languages like Haskell, which can be automagically threaded. Erlang is manually threaded, it's just much easier to think in threads (or "processes") -- they're effectively a language feature.
1. Invariable variables.
This appears to have been done for no reason other than the designer's preference. In fact, it's not strictly true -- variables can be unbound, and later bound. They just can't be re-bound once bound.
2. Weird syntax.
Why, exactly, are there three different kinds of (required) line endings? It seems as though the syntax is designed to be as different from C as possible, while maintaining at least as many quirks. Moreso, even -- when constructing normal, trivial programs, you're going to hit most language features head-on and at their worst. Where's my 'print "hello\n"' that works most other places?
I don't believe the important features of Erlang are mutually-exclusive with the sane syntax of, say, Ruby or Python.
3. Not Unicode-ready.
Strings are defined as ASCII -- maybe latin1. But there's no direct unicode support in the language -- if you're lucky, there are functions you can pipe it through.
There are other things I haven't mentioned, mostly implementation-specific -- things like the fact that function-reloading cannot be done when you natively-compile (with hipe) for extra speed. My plan is to take the features I actually like from Erlang and implement them elsewhere, in a language I can actually stomach for its real tasks.
it's easier for most people to fudge through something they vaguely remember doing by pictures than it is for them to memorize a set of arcane terminal they vaguely remember.
I've found that the documentation is such that I only need a vague memory of the terminal, just as I only need a vague memory of the GUI. Obviously, YMMV.
That said, while I find the terminal is more productive, I also find that many GUIs are much more discoverable than their CLI counterparts, and that the learning curve is far less.
Truecrypt is mighty close but portability is a killer for any enterprise to manage.
This is WTF #1.
Under what circumstances would the encrypted volume need to be accessed from an OS other than the primary one for the laptop? For that matter, under what circumstances would an "enterprise" not standardize on an OS?
If you're going to say "recovery", that implies the laptop isn't being backed up, which is a WTF on its own.
With Truecrypt hopefully you have a copy of the master key so you should be fine. With encrypted LVM solutions things can get all kinds of hairy though.
With LuKS, you can use a fair number of keys with an encrypted volume -- either keyfiles or passphrases. So if you need a master key, that's easily possible.
I wish Truecrypt supported fingerprint authentication.
This is WTF #2.
A fingerprint is completely useless here. Remember that a copy of your fingerprint must be stored somewhere in the laptop to compare against, and that a fingerprint can never scan twice. It can therefore not be used as a key -- the best you could do is a boolean check.
As in: if (fingerprints_match) { unlock_stuff(); }
As in, all an attacker needs to do is use their non-keyprinted version of Truecrypt.
Right now it looks like Computrace's LoJack for Laptops is still the best option for enterprise deployment.
This is WTF #3.
LoJack is, what, a 10-line cron job? And from a quick Google, I see nothing about crypto, only about erasing after the fact.
In other words, all an attacker needs to do if they want to sell the laptop is wipe the drive. All they need to do if they want to get the data is image the drive, and work without a network connection. Crypto will at least protect against the latter attack.
Let me seal it for you:
It's a REST server in a DSL.
I didn't expect having to spell this out...
That is exactly the proprietaryness holding it back. Were Flash a completely open standard, with competing open source implementations, Apple could just build their own version. As it is, they have to deal with Adobe.
And it disproves your point -- the iPhone is, indeed, used by people other than greasy GNU hippies. Therefore, people other than greasy GNU hippies are affected by Flash being proprietary.
Once they have the name of the instance, they also know who launched it -- after all, they are billing someone.
I like the suggestion to charge a large fee to the credit card they have on file, but what about simply banning the account in question?
Some people might say I'm comparing apples to oranges, but Apples dont' cost 17,000 times more than oranges.
Granted, your numbers may not be entirely accurate, but the whole texting thing is out of control. The mobile world is also a fair example of what could happen to the rest of the Internet, if net neutrality is not maintained -- anyone looking forward to 10c/email?
That would actually be really helpful -- have some sort of certification for PC repair that doesn't suck (read: not MSCE).
Alright, I realize it makes me a dirty hippie that I don't like Flash (and don't always even have it installed), but I'm about to go on a road trip. I've been looking for interesting, educational videos to download, but this one would at least force me to muck about in Firebug.
At the very least, provide a download link! I've signed up to Vimeo and Sribd just to get their download links.
When did this happen?
Seriously, I'm looking at the spec, and at a first glance, I don't see any kind of clause that I thought was there before -- the clause which says that this spec may not be used to implement a player.
If it really is entirely open, that's great news for Gnash and friends!