I think I've been misunderstanding something here, and your posts have cleared this up for me. (So, thank you!)
For some reason (and believe me, it seems stunningly obvious to me now), I was under the impression that loading a load of functions into memory would somehow not only affect startup, but also the speed of programs after startup. (ik, ik) I think I've sidetracked myself from my original goal of discussing ways of getting rid of typical '#include'-esque boilerplate.
Though my argument about already-optimal small programs (which have a large workload) might apply to compiler optimisations, it has little to do with autoloading.
I think autoloading would become useful if startup time were pushed up to anything more than a second -- after that, I think most people (that is, I) get quite angry!
Again: thanks for clearing this up for me.
Moving on from autoloading: how are name collisions dealt with in Arc? The only thing I can think of is the old elisp "prefix all yer functions with the package name" ideology. (So the functions of the string library would be called `string-foo`, `string-bar-baz-qux`, etc.) This'd be important, given that (one way or another) ALL THE FUNKSHUNZ are loaded.
Just to clarify: when you say 'all the code the system knows about', do you mean user code and the standard libraries, or just the user code?
From what I can see, you have to install (npm's equivalent of) the standard libraries you want in to the node_modules dir. (So it's not much of a win over the boilerplate import code.)
However, I'm interested in how you'd have implicit importing of user code -- at first glance, all the code under it seems a decent way to go.
Not even a whole library -- just the specific functions that you're using. (Think of all those times you've done `import math` just for the bloody sqrt!)
If (when!) Arc becomes the 100 Year Language that we all want it to become, it's various libraries will become rich and numerous.
On the one hand, I don't want my .arc files filled with boilerplate code to load the libraries I want; on the other, I don't want a huge number of functions to be loaded that I won't actually use.
I feel that autoloading is the perfect compromise: granted, the 'autoload pointers' will have to be loaded (by default and automatically -- otherwise that's just more boilerplate) -- but this yields far less overhead than loading the actual functions.
For big programs, pg's dead right: far more of the speed will come from optimising the program -- however, for small, sysadmin-type programs, where your program is so small that your algorithm is already optimal, but the actual problem is quite large (e.g. a gargantuan directory structure), the speed comes from a tight language. (And you'll write far more of these microprograms in your lifetime than big, optimisable programs.)
Please don't get me wrong: I agree with you wholeheartedly that there should be a profiler in Arc, and that this should be used to optimise Arc --
Actually I was wrong in saying that in the installation folder it worked. In the installation folder it succeeded in loading the "news.arc" file, and failed at runtime. While in the other folder that failed, because in that folder I already tried with anarki and created some news/bans and this is why it failed to load: the diskvar didn't work. However the problem wasn't in diskvar: it was in "file-exists" which should return the name of the file in case of true: because of this when I just modified "diskvar" it still gave me the contract violation error, I think because the arc code relies on the fact that file-exists returns true. I changed in "lang/arc/3.1/main" the line "(def file-exists (x) (tnil (file-exists? x)))" in "(def file-exists (x) (if (file-exists? x) x nil))". Now I successfully run the news!
Notice the "(iflet ,gf (file-exists ,file)". It expexts file-exists to return the name of the file if it exists. file-exists doesn't, it returns t if files exists, so here is the cause of "error: open-input-file: contract violation expected: path-string? given: 't ".
It looks to me like the confusion in that SO post is because Javascript does something sneaky in order to support several syntaxes that mean the same thing. Tcl has no syntax. Braces aren't used to delimit blocks and denote dictionaries. They're just used as an escaping mechanism, period. Once you know the language, it is always clear how the interpreter will treat your data.
About the holy grail quote... I should say it's not about __finding__ such a language, more like it's about __searching__ for such a language. Which involves constantly looking at different ones.
Those criticisms of tcl are true in the sense that yes, everything is a string, but unfounded in the sense that so what? Values are stored as strings so that they can be passed around as data and used immediately as code. But if you pass "5" to a command that needs to use it as an int, a conversion will take place, and the int value will be stored along with the string representation. The most recently used type of a variable is kept as the primary representation for efficiency (basically caching).
Here is a link to some docs about the tcl macro system, written by its author: http://wiki.tcl.tk/11155
From a practical perspective, I agree with what you say about "Past a point, languages don't matter. At some point you have to build stuff with the languages you know." Programming is about building stuff that works and is useful, and no matter how much theory you know, at some point you just have to sit down and type.
My motivation for evaluating and comparing the relative merits of languages is that programming, for me, is so much more fun when using certain languages. It's not about finding some holy grail of PL. It's about finding a language that is powerful and will pretty much let me do whatever I want.
I completely agree with your point about learning languages to keep learning languages. Even though I consider tcl to be more fun to program in than forth, my time writing forth code was extremely valuable to the way I think about programming.
I really like that analogy to bears.
Edit: The tclers wiki, to which I linked above, contains a massive amount of information on the language, programming in general, and many other topics, the likes of which I've never seen concentrated as well in another programming community.
What's the benefit of running vim-slime as opposed to just an arc repl from the command line? I've been doing that w/ the same vim/tmux setup you mentioned. I enjoy it.
Edit: I see that you can execute code from the vim window. That is a nice feature. Anything else significant?
I read the link you suggested in my previous post about defvar, and I see that it can be used to set dynamic behavior when a variable is referenced (??). Is this the correct interpretation, and what might be some uses of that?
Wow great post, thanks for the reply. I didn't know eval was always executed at global scope, and I was not thinking about the ht variable being executed multiple times at different scope, so thanks for pointing that out. The rest of your explanation about how to get it working is very clear and I will be a better arc hacker for it!
The occasion for this macro is an object system built around closures and hash tables. I will post more about it when I've made more progress.
The issue was network (firewall) related. I simply
destroyed the firewall (it's on VM so am not concerned about security on this one). On ubuntu that amounted to removing the IPtable rules.
Am looking forward to putting this behind Nginx and seeing how that goes.
Thanks for sticking with me kinnard. It's very much appreciated. Have a great week.
I was using defvar where I should have been using =. But the idea in my post was just to store the result of (prompt) in the variable x, which is meant to be a string.
And yes, now that I am moving past the experimental phase of my script, I will be running things in batch mode.
Also, from an outside perspective, I think your idea for a "Arc for Scheme" primer would be a great idea. The Little Schemer is widely recommended, so it could potentially result in more people finding their way into Arc.
Right. I created one in Ruby not too long ago. Then I decided I wanted to see it in the browser, so I used something called Opal to convert my Ruby code to JS. Then I built up the necessary html/css.
