<br><br><div class="gmail_quote">On Tue, May 24, 2011 at 5:56 PM, Parnell Springmeyer <span dir="ltr"><<a href="mailto:ixmatus@gmail.com">ixmatus@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">-----BEGIN PGP SIGNED MESSAGE-----<br>
Hash: SHA1<br>
<br>
</div>I really like the idea of packages - I'm not quite sure why everyone is<br>
against them... Even Racket has extended the syntax of Scheme to the<br>
point where they support packages and modules now; it's a very natural<br>
abstraction for the human mind IMHO.<br>
<br>
I would, personally, stop using (or fork) the language if I were forced<br>
to program connected to a DB. </blockquote><div><br>Why? Who cares how the data is stored - the requirements on storage<br>would be never-loose-anything fast latency access form any machine<br><br>I'd imaging a fast local db, that synced with some cloud storage and<br>
where you could work on-or off-line with periods of no net access.<br><br>If your machine were struck by lightening you should be ably to<br>resume on any other machine, possibly loosing a very small ammount of data. <br>
<br>I imagine a local copy of couchDB with off-site replicas would be ok for this.<br><br> </div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
If it were a local ets-like DB that<br>
started when the Erlang VM started, cool.</blockquote><div><br>Ets is too fast - we don't need to be ets fast :-)<br> </div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
 But not an over-the-internet<br>
type of thing, this is a particularly bad idea too because some<br>
applications really do need to be network efficient; if my language adds<br>
overhead to my network because it needs to request the definition of a<br>
function over the internet, that is A Bad Thing.<br></blockquote><div><br>It's a trade off - if you always store modified functions in the net the<br>most you can loose is one function. If you don't you might loose<br>
a lot of work if your machine suddenly disintegrates.<br><br>Umm let's think - in a good day I might write 500 lines of code<br>say 500 * 50 bytes in 86400 seconds that's 0.3 bits/second<br><br>I might look at ten times as much code - but I'd cache that locally.<br>
<br>/Joe<br><br> </div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<br>
I don't like the idea loading everything when the VM starts. I much<br>
prefer (and wish Erlang did it this way) the concept of calling an<br>
import statement. I like being able to see what packages, modules, and<br>
functions another module is referencing.<br>
<br>
Additionally this solves the issue of pre-loading the entire namespace<br>
when the VM starts; you only import when you /need/ it.<br>
<br>
I am intrigued, however, by the idea of type signatures and finding<br>
functions based on their metadata - cool idea.<br>
<br>
In practice though, I would really hate maintaining the metadata for<br>
every function I've wrote! I much rather group common functions into a<br>
module and then annotate the module with metadata.<br>
<div><div></div><div class="h5"><br>
Anthony Ramine <<a href="mailto:nox@dev-extend.eu">nox@dev-extend.eu</a>> writes:<br>
<br>
> Le 24 mai 2011 à 14:45, Joe Armstrong a écrit :<br>
><br>
>> On Tue, May 24, 2011 at 1:56 PM, Max Lapshin <<a href="mailto:max.lapshin@gmail.com">max.lapshin@gmail.com</a>> wrote:<br>
>> Very strange topic for me.<br>
>><br>
>> I'd like to know if there will be hierarchial modules in Erlang,<br>
>> because tree of packages is a rather good idea:<br>
>><br>
>> No it's not - this has been the subject of long and heated discussion and is<br>
>> why packages are NOT in Erlang - many people - myself included - dislike<br>
>> the idea of hierarchical namespaces. The *dot* in the name has no semantics<br>
>> it's just a separator. The name could equally well be encoders.mpg.erlyvideo<br>
>> or mpg.applications.erlvideo.encoder - there is no logical way to organise the<br>
>> package name and it does not scale -<br>
><br>
> packages are NOT in Erlang? Then the related code should be removed because<br>
> erl.lang.number:plus(1, 1) definitely works.<br>
><br>
> Also, I think the Haskell guys would disagree about packages not scaling.<br>
><br>
> --<br>
> Anthony Ramine<br>
> Dev:Extend<br>
> <a href="http://dev-extend.eu" target="_blank">http://dev-extend.eu</a><br>
><br>
><br>
><br>
><br>
</div></div><div class="im">> _______________________________________________<br>
> erlang-questions mailing list<br>
> <a href="mailto:erlang-questions@erlang.org">erlang-questions@erlang.org</a><br>
> <a href="http://erlang.org/mailman/listinfo/erlang-questions" target="_blank">http://erlang.org/mailman/listinfo/erlang-questions</a><br>
><br>
<br>
</div><div class="im">- --<br>
Parnell "ixmatus" Springmeyer (<a href="http://ixmat.us" target="_blank">http://ixmat.us</a>)<br>
-----BEGIN PGP SIGNATURE-----<br>
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)<br>
Comment: GPGTools - <a href="http://gpgtools.org" target="_blank">http://gpgtools.org</a><br>
<br>
</div>iQEcBAEBAgAGBQJN29UaAAoJEPvtlbpI1POLpSAH/ijpOgfq1F+AF140/aXZke6C<br>
EXrWaiFBOgna0lkKu4lmwusOebLbyoiPs9D9vstlVff7npZ4Zdw32fp9LRuBjwfY<br>
rgGesMBoUGNMtpzXuuduCH7CkZNCIrBXj8uvKOBlDxt5csOz8FCpxvKDOXZg/z0I<br>
bFMP0HTYj1pzC2ixk2RmlUdKdbMLCCriIU+n0R5f4lIEck1FcoDm233ZHv1Sv9QC<br>
9PlQ4kF91H/CavPAdD/JX4sDp6NRTCjV/VWCUzDTOyK/11/fl4R7nAB61TXzkVmz<br>
tv3y5z5RCkfjlatgvGSQ3d9vRbSn5fQneguxMX54JHI0WTEcWZ3xCQZZ8QKPuhY=<br>
=Faf+<br>
-----END PGP SIGNATURE-----<br>
<div><div></div><div class="h5">_______________________________________________<br>
erlang-questions mailing list<br>
<a href="mailto:erlang-questions@erlang.org">erlang-questions@erlang.org</a><br>
<a href="http://erlang.org/mailman/listinfo/erlang-questions" target="_blank">http://erlang.org/mailman/listinfo/erlang-questions</a><br>
</div></div></blockquote></div><br>