I whole heartedly agree with you. HTML/XML should die. It really is an outdated transform which unfortunately, while appropriate 20 years ago, is not appropriate for what we do these days. I do hope that someday some of the big guns like google, apple etc take on the challenge of really re-writing the web.
And, actually, I think the bigger problems are the inconsistencies in the spec and the web browser compatibility nonsense that occurs.
In other words I'd rather have a single transform that's not HTML and does not have to support all the nonsensical, historical artifacts, while easily aligning itself with functional or other language paradigm.
That's interesting: so the more one attempts to create signal the more likely it becomes just noise.
If I were to use comments I think I would agree with having very few and making them fairly silent. Personally, though, I've abandoned comments all together. Aside from the fact that comments can easily become stale, old and even misleading, I do believe any effort put in to commenting is better spent making the code more readable or even creating unit tests as a means of telling the actual story.
All that said, I'm really strained for time plus I'm also the only one who reads my code!!!!
Thought I'd pitch this opportunity out to the arc language community. Datomic just released an alpha of their REST API. This provides a robust scalable data storage system for arc. And as an added benefit, since datomic allows you to run code within the database, arc also can use Clojure to fill in some of the feature gaps such as concurrency or even triggering functions that utilize java libraries.
Another really cool aspect, is that since datomic aggressively caches data locally, arc could treat the entire data storage system as a localized data structure accessible via HTTP. This provides immutable data structures with ACID transactions.
Sounds great. Datomic already packs a lot of great features, and from what I'm reading, Rich Hickey, Stuart Halloway and Co. are far from done yet. I'm watching this space very closely though I haven't dived in yet. Up to my gills in Clojure right now, which is proving to be a very enjoyable expedition. Arc was my first Lisp, and learning it made Clojure very approachable. Not a bad year this: learned Ruby, Arc and Clojure - and all three were great fun. Datomic's up next.
Yeah, I saw this on HN and it completely made my day. I've been using Datomic for a few months now and I'm really happy so far. It's just f#$%ing brilliant in my mind.
Looks like Rich Hickey is on a tear - which is great news for all of us! BTW, http://blackstag.com/ is very nifty too - thank you for all the stuff on Clojure.
I'm going to disagree here. I think language choice does matter.
In general I'll suggest you give consideration to the following:
1. Marketability
Do you want to learn a language that opens doors for work? Is this a criteria? If you do it might be worth surveying the job ads in your area and find languages that are marketable.
2. Libraries
Are you the kind of person who would rather leverage existing libraries that are ready to use or are you OK with building them from scratch if none exist? For example do your require databases connection libraries? auto-email-generation libraries? If you want to leverage libraries then I suggest you spend some time looking at your top 5 language options and see if you can find the some of the libraries you may want to use.
3. Platforms
Which platforms do you intend to target? Android devices? Apple iOS? Mac? Windows? Which for? server side only, client side too? Some of the options may not run on the platform you would like. Note that some languages will allow you to compile your client side code down to javascript which would allow you to target almost anything, but the trade off is that the source code can be seen by others. Is this ok? Or do you want your code to compile down to more closed source options such as what Objective-C would provide for iOS devices.
4. Documentation
Read some of the language documentation and get a feel on which option provides you with meaningful information. If you intend to leverage libraries maintained by the user community then I'll suggest you take a look at the communities documentation too. And read some language oriented blogs - maybe see if you can collect as many links as you can to compare the languages relative content and then judge the usefulness of them.
5. Community.
See if you can find forums or chat rooms then watch them for a little while. Are they full of harsh critics that would give no solace to newbies? or do you get a sense of helpful people showing consideration for differing views or varying capability sets.
6. Growth/Stagnation
Which of your language options has a growing body of work (both in the core language and the libraries). Is the community getting bigger or smaller? Rank them. Check to see how active the community is and note that having a larger and more active community can be the difference between regularly spending several hours in frustration while not getting anything done vs. having immediate and helpful answers that empower you to succeed.
This may be a lot of work, but I think the effort is worth it. It is an investment after all. Personally, after learning Arc, I chose to go with Clojure. If you're interested you can read my intro blog here: http://blackstag.com/blog.posting?id=5
I think it doesn't matter -- because newbie programmers can't yet make such judgements.
"This may be a lot of work.."
The problem isn't that it's a lot of work. Learning programming is a lot of work. The problem is that it's a lot of make-work much of the time. It's distracting the student from getting started. It's increasing the risk that (s)he'll lose interest and give up.
Forget community, forget growth rate, forget marketing. Just pick a language where you have a mentor to help you out when you get stuck. Then pick a little problem you care about, and figure out the minimum you have to study and understand to get it to work. As you gain experience, be open to learning about the internals of your tools. Don't plan to just use libraries; plan to (eventually) jump into the rabbithole, and learn how they've been built.
None of the languages you're likely to pick will be utterly without libraries. If you pick a language without the libraries to do what you want, your mentor will set you straight pretty quickly. And perhaps your initial project isn't too important; if so just switch to a different one better suited to your language.
Focusing on languages and libraries may cause you to forget that learning is an open-ended life-long process. The difference between 'learning programming' and 'learning java/lisp/blub' is the difference between an education and literacy: if you do it right you'll learn new languages and libraries easily, like a fish taking to water. But if you don't have the fundamentals you'll always program the way I swim. No libraries will save you.
Ok, well I'll still suggest that doing some research and stepping through the evaluation process can only improve your abilities. I also think that the process of researching, evaluating and spending time trying to make an informed decision would not lead to being closed minded, as you are suggesting... I think that might be a little far out there.
And while I agree that it could distract some people, I also think that picking a language with more road blocks and frustration points can do far more damage to a newbies enthusiasm/momentum than some initial research might otherwise cause.
Besides all that, IMHO, it seems to me he's looking for more guidance than what his brother already contributed, being "languages don't matter" (obviously this didn't settle his appetite to understand the options over getting started).
"..the process of researching, evaluating and spending time trying to make an informed decision would not lead to being closed minded.."
'Close minded' implies intolerance. Did I really seem to suggest that? I meant to imply ignorance. All that needs is lack of exposure (or inefficient exposure), not any conscious unwillingness to learn.
"..picking a language with more road blocks and frustration points can do far more damage to a newbies enthusiasm/momentum than some initial research might otherwise cause."
Yeah that is true. Everybody's going to eventually hit frustration points, and some positive associations at the outset can help reinforce a trajectory of persistence. But there's a lot more to the frustrations of programming than language.
Perhaps it's worth providing a blacklist of languages to avoid. I'm curious what would go on your blacklist; no modern language seems particularly egregious to my mind.
I was writing 'closed minded' thinking only in terms of not choosing to learn rather than any intolerance or stubbornness. Poor choice of words on my part - sorry about that.
I don't have a blacklist, but as a newbie, having hit the wall so many times with Arc as my first language I can't help but think I should have done some rudimentary research before I sunk the time and effort in that i did.
I still think Arc is a great first language choice, but setting the expectations prior to the investment would have limited the frustration for me. Of course even for me this was back in the day when you could hope the Arc language community might get ahead of the curve while you were learning and produce enough libraries to fill in some of the missing features like practical and robust database access. These days that would be crazy thinking, IMHO.
Sometimes getting off the ground isn't enough. I think it's better to get off the ground and get some momentum going too. Clojure would have done that for me, but at the time I believe arc was more popular / mature than Clojure.
As a note I still think Arc first then Clojure is an awesome path. With arc you can get up and running fast with a really well written tutorial. And as a bonus, because there's only a simple[1] set of features making up the core you do not have to deal with the extra complexities (such as immutability) right at the beginning. This lessens the burden. But, at the same time, I'm going to suggest that newbies treat arc like a learning language rather than something they can develop real world, deep applications with (Of course this is a general statement that can not account for each persons specific needs).
[1] simple may require a more in depth conversation here. i.e In application it may mean it's is really easy, but not actually very simple...all this is assuming you've followed Rich Hickey's 'Simple made Easy' campaign.
"I'm going to suggest that newbies treat arc like a learning language rather than something they can develop real world, deep applications with (Of course this is a general statement that can not account for each persons specific needs)."
Well, that's not entirely true... If you're talking about Arc 3.1, then of course it has a huge lack of libraries.
But Arc/Nu has access to most of Racket's libraries: for instance, "re.arc" just uses Racket's regexp support to implement regexp matching.
As another example, in an internal application I wrote in Arc, I had to parse XML. I used Racket's built-in XML parser which also has an option to use "X-Expressions" which is basically XML represented as S-expressions:
I have to say, even though I don't like Racket the language... Racket the infrastructure and libraries is top-notch. I suppose the same has been said about Java.
---
So, although I agree with you that Arc 3.1 is lacking, that's not necessarily true of forks like Anarki, ar, or Arc/Nu. And I think the only reason Arc 3.1 is lacking is because pg has been busy with non-Arc things.
That's one major benefit Clojure (and other languages) have over Arc: they're still being actively maintained.
---
I still agree with you in principle, though, that a language like Clojure, Python, or Ruby would be easier to get up and running, due to their larger community and wider availability of libraries. In particular, even though I haven't used it, Clojure looks like a very nice language, from the small bits and pieces I've seen.
I would too, even though I've come to dislike mutability. Ruby has the community, the libraries, and the features. It's also a fairly consistent and clean language overall. I'd rank it at roughly the same level as Arc, maybe a tiny bit higher.
Ruby syntax is quite consistent and clean, and its support for closures very handy. I really like it.
Clojure has a strong philosophical bias for immutability and a functional approach, but has a slightly higher overhead with its combination of Lisp and support for Java. I think it has a bright future, despite pg's view that the jvm isn't what the 100 year language will be built on. :)
"..'closed minded' thinking only in terms of not choosing to learn rather than any intolerance.."
Sorry, that was all I meant as well. Intolerance in the sense of 'intolerant of the pains required to learn programming'. There's no negative connotation to that sense, I think.
At the risk of going around in circles, I was referring to all the subconscious reasons people fail to get going with programming, rather than any conscious intolerance.
I actually wasn't thinking of arc at all. You can probably find better first languages (though having the compiler open in a split window is a unique selling point). But it doesn't seem worth optimizing beyond a point. Just pick one and keep going. The test of a first language is not whether you hate it after a while, but whether you keep programming in some language.
I'm focusing on Clojure now though I will keep an eye on Arc developments. Arc is really nice to play with but I agree that Clojure has the traction, even by the yardstick pg mentioned about what it'll take for a language to dominate (community, number of books, power of the language itself, etc.). It also has the whole Java library to support it, even though it has led to some uncomfortable syntax in some cases.
Additionally, I find Rich Hickey has given deep thought to his philosophy re programming and its challenges, and has applied it quite consistently over the years. There is a clear pattern in his approach to the development of Clojure and more recently to that of Datomic, with much of it coming out of the ideas he talked about years ago on the concept of simplicity.
"And while I agree that it could distract some people, I also think that picking a language with more road blocks and frustration points can do far more damage to a newbies enthusiasm/momentum than some initial research might otherwise cause."
That's a good point. Newbies can get turned off when things seem opaque.
"Just pick a language where you have a mentor to help you out when you get stuck."
Good point. In my experience you really need someone to open the door for you, even if only just. That's what draws you in. Once in, momentum takes care of many things, but if you don't get led in at this stage, you could give up easily. I lost a good number of years without such a mentor.
Option 4. Get the FFI working to access MySql and other more traditional database systems.
Some people had been working on the FFI interface, but so far I've yet to see anything that works. You can read my noob entry about this here: http://arclanguage.com/item?id=10839 and there were recent attempts by others as well.
Not surprising really. You could make the same argument with shorthand writing. While it's certainly not the most easily read form for the masses, it has one very important saving grace: For those that learn it, it's often the only way to keep up ... I mean who would you want taking dictation for you? Someone who has to interrupt you to slow down while they write long hand?
I think the lisps with less brackets (i.e. Clojure and arc, that I know of) strike the right balance between readability and efficiency. Racket on the other hand is terrible... I'd rather learn Java.
