Nothing here is untrue, but from my perspective it's overstated. I don't use discord, but I visit the forum daily, follow most of the RFCs, and spend a lot of time coding in Nim (https://github.com/dsrw/enu). I really like Nim, mostly like its community, and think many more people should be using it.
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.
The compiler works until you stress the type system or try to take advantage of features that are experimental and then stay that way forever. How many iterations of concepts have we been through at this point? What happened to hot code reloading? Why do we have all these legacy GCs?
The point is the compiler has more and more cruft that makes it increasingly more complex and increasingly unreliable. It also makes it so that bugs are harder and harder to fix. Not to mention that it's basically impossible to track what is going on with the language at any given point in time because there is no roadmap or updated status. It also doesn't help that certain folks like to create ten GitHub issues and RFCs for every perceived slight in the language.
Once again, the problem boils down to a complete lack of leadership or interest in running the show - and instead of empowering the community to make that happen, leadership sits back and acts like everything is great and perfect and pats themselves on the back. When someone complains that it is not, leadership finds a way to defend itself and turn sentiment against the person complaining. It happens over and over again and it's why Nim isn't a success story like languages that actually have empowered communities and leaders that are interested in leading and not just collecting book revenues / making .io games, etc... while actively gatekeeping those who would like to get involved in making things better.
Viaweb was a cash strapped startup in a competitive market, who succeeded against odds because of their speed and agility. They were running on fumes when they were acquired. A longer development period would have certainly meant the death of the company.
Wow, that was a cool comment. I don't think I've ever agreed with and wanted to argue with a comment so much as that one. I sat there for about 30 seconds deciding whether to vote it up or down. Kudos! (note - that was totally sincere)
At first I thought you were leaving out their smarts and technology, but speed and agility were because of the smarts and tech. Then I thought I remembered pg saying they were going to close another round of funding when they got bought instead.
Stevey had a series of articles where he implemented Sokoban in a bunch of JVM languages, and Groovy did very poorly. I can't find a live version of the article, but here's archive.org's copy:
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.
One of Groovy's stated aims is that any .java file is also valid groovy. It's a strict superset in other words.
... which is, in a word, retarded. I like java, but, if you're gonna start over, please, oh, please, fix some of the things that need fixing but aren't getting fixed because of backward compatibility issues. You've got a blank slate, use it!
Rails has filters that can run before, after, or around some or all of your controller actions. This can be done on a per controller basis, or it can be application wide. In this case you'd probably define a "load_widgets" before_filter in your application controller, then set your view to display whichever widgets it had data for.
There are other pieces of this puzzle besides before_filter.
In Rails, you don't necessarily have to have a monolithic view. On more complex sites, you use fragments, called partials. Sidebars can be easily created by having a "shared" view directory full of partials. Further, there is a content_for helper in Rails views. Views render late; you can set an instance variable in the subviews that will affect what gets rendered in the layout. Trying to keep track of that can get hairy, so content_for abstracts that for you. Combined with the partials and the before_filter in the controllers, you can get a view to produce a number of things without having to resort to pulling DB info inside the views -- that reminds me too much of the bad old days of PHP.
In the logged-in users example, in what is normally in the sidebar, you use a render :partial => 'shared/users' if @users; then add a before_filter in the site-wide application layout to pull in the data if someone is logged in. A more complicated example is to render a "sidebar" partial, which renders more partials depending on some array of sidebars you want to display ... then use a before_filter to figure out what you want to populate the sidebars with. Any controller or actions can override or add to that sidebar array.
The main thing that sucks about this kind of organization is having the code scattered in a number of different files. This is where using an editor that knows the relationship between the files is important -- you can hit some key combination and jump between the different fragments without having to hunt them down in the file browser.
I think having that degree of modularity is a great thing (granted you have a good text editor). It makes it much easier to understand what's happening in the code and much easier to maintain it (and get someone new up to speed).
I was helping out on this one site built in PHP a while back where the code wasn't organized this way. It took me about a week to figure out where things were, which was a huge productivity drag for the other guys.
Unlike partials, embedded actions also let you define business logic to be
performed before the partial is included. That logic is encapsulated in the
already well understood metaphor of an action inside a controller.
lets you include an html fragment containing the top 10 songs into any of your
pages, regardless of which controller, action or view wants to do the including.
----
In other words, you call "embed_action" from within a view which will call the controller-action and embed whatever result is there. You still get the organizational benefit of MVC without the hassle of rolling your own partials.
As an additional note to what I was saying about partials, Rails 2.0 also has a concept of "partial layouts", allowing you to switch out the surrounding content of a partial.
The Rails magic is well defined though, and it's all documented. It doesn't simply 'stop working'. It's really nothing more than a set of conventions that happen to make certain things really convenient.
SQL is extremely verbose. During my previous life as a Java programmer I moved a project from raw SQL to the hibernate ORM, and removed 10,000 lines of code in the process. Using straight SQL, the data access code was more than 50% of the entire code base. Switching to an ORM got it below 10%.
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.
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 app had something like 200 different tables, with 20 to 50 columns in most tables. Update and insert statements were 5 - 10 lines long, and there were hundreds of the things. There was some JDBC cruft too, but the vast majority was SQL.
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.
Streamlining SQL code generation and mapping tables to objects are two entirely different feature sets in my opinion. 90 % of the reduction in code you're talking about stems from the former whereas 90 % of the complexity of ORMs stems from the latter. That's why I prefer a leaner toolset to interface with the database.
"We're past the days of using machines as amplifiers of our physical efforts. It's not enough to jam more features into code just so we can eliminate one more position on the assembly line. We're at a point where the machines can help amplify our imaginations."
The idea of software as art is hardly new, but it's nice to see a cool app get some formal recognition.
There were a recent post telling to put the e-mail address on the profile (click up right on your nickname after logging in). If not you'll receive no answer.
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.