Readit NewsSo, no, they could not have written it in C.
On another note, has anyone here played with Groovy? I played it for a while, and I am not sure why there seems to be so much negativity about it.
http://web.archive.org/web/20060720091555/www.cabochon.com/~...
Groovy just seems pointless to me. It's taken too long to get anywhere, and I can't think any reason to use it over JRuby, Rhino or Scala. JRuby and Rhino have the benefit of being implementations of popular languages, basically getting years of experience, tooling, docs and code for free. Scala adds novel ideas not found in other JVM languages, and makes certain types of problems much easier than they would otherwise be. Groovy is a less powerful version of Ruby with a Java like syntax. It's awfully hard to get excited about that.
The problem with relying on magic is that you won't know what to do when it stops working.
I moved from PHP/PearDB to Java/Hibernate3.0 to Python/DBAPI, and found that Java was by far the most verbose. Even with Hibernate annotations, I was writing more than twice as much code for equivalent functionality.
Perhaps the difference is that you have business objects defined already, and so the cost of Hibernate is only the annotations? My PHP and Python programs keep the SQL and drop the objects, and so they end up with incredibly tiny data access layers.
SQL is optimized for writing data access queries extremely concisely, so I don't see how it could end up as more than 50% of the codebase, unless you're using an exceptionally verbose database library (JDBC certainly counts) or your codebase is exceptionally tiny.
This was an extreme case of course, and was mostly the result of bad design, but I haven't come across a database backed application that couldn't be trimmed down with some sort of SQL generator. SQL is fine for simple queries, but, for me at least, has always gotten unmanageable in the long term. Need to select, insert and update the same columns? Duplication. Conditionally group by or order by different fields? Duplication. Decide after the fact that you need to support multiple databases, or eager and lazy loading? There goes the weekend, and probably most of next week.
You could manage all of the above with some sort of home grown solution, but a good ORM just makes everything so painless. I was strongly anti-database for years, yet I now often find myself using ActiveRecord when a flat file would do, simply because ActiveRecord is easier.
Of course, that's just me. SQL and I were never a good fit, and I'm glad to be mostly rid of it, but I'm sure others have had different experiences.
Deleted Comment
One thing that bothers me in a lot of frameworks is the object wrapping of the database. I can't see much justification for this, it just seems to be adding a layer of complexity on top of a very clearly designed model. How much easier is it to use an object abstraction when you could just do SQL directly?
John.
It really depends on what you're doing, but I can't imagine why anyone would want to write SQL by hand. If you really want simplicity, don't use a database at all.
1) Nim's leadership is awful and has always been historically. Those in charge of managing the community are more interested in their personal reputation's and resumes than they are actually contributing working software to the language's ecosystem. Even the BDFL treats Nim like their own personal compiler R&D playground. There are so many broken features in Nim which never see the light of day or never get removed.
2) Continuing to expand on the point above, the Nim compiler has become insanely difficult to work on. As more and more half-baked features have been added to the language, the situation has only worsened. There are many would-be contributors who have come into the community only to leave completely frustrated or appalled by the lack of interest in improving the situation from those leading the community.
3) The development path is driven by leadership and not the community, and leadership has no plan. This was extremely evident last year when Araq and others were asked for a roadmap for Nim and they admitted to not having one, and basically wrote one up in a forum thread. Araq and dom96 and a few others, especially those who have been brave enough to actually deploy Nim code in production (looking at you status.im) tend to dictate what gets worked on or fixed. There is no coordination amongst folks working on initiatives. You can look at the `fusion` project, which was started by Nim's leadership, drew contributors in, and then was abandoned by leadership while maintainers were left on the hook to keep things afloat until they too dumped the project.
Things have gotten so bad, that a hard fork has been in development since last year, and many of the more senior community members or those who have been around for a bit have migrated there: https://github.com/nim-works/nimskull
Nim's community now consists of mostly new members or folks who weren't really active in it before, but maybe used Nim. Of course, the leadership remains in place, but there are only a handful of folks remaining that have been around for more than a year or two. Mostly those who bit the bullet on using Nim in production or built large projects with Nim and are stuck maintaining them.
My advice would be to look elsewhere.
I'm sure fusion could have been handled better, and for 2021 the roadmap was a bit hazy, but I can't think of any other big missteps. Araq, dom, PMunch, and other senior folks are in the forms helping people and answering questions every day, and my interactions with all of them has been very positive. The big post 1.0 feature was arc/orc, and that was very well communicated. Bugs are being fixed, useful new features are being added, and future plans are being discussed in the open.
And Nim itself is great. The "if it compiles, it works" factor is high, yet I almost never feel like the compiler is fighting me. Simple things are simple (I'm teaching it to a group of 12 year olds), it's incredibly flexible, it's fast, and it's suitable for almost any sort of problem. There's nothing else like it, and I expect I'd continue using it for at least a decade even if it switched into maintenance mode tomorrow. I think it will take at least that long for something better to come along.