Despite the apparent lack of popularity, Groovy with the Grails framework is certainly better suited for web development than many (I would dare to say, most) of the programming languages listed above.
Of course, it also matters what kind of web development we are talking about. Is it web services or web applications? I think the requirements are quite different between the two.
After its leadership changed in 2005, Groovy was commandeered to be primarily a scripting language for Grails. A Ruby-like meta-object protocol was added to Groovy so Grails would be Rails-like. Groovy's never really broken free of this shackle, despite its failure around static typing and Android, or use for defining builds before Gradle 3.
> Take the Google homepage. It’s a one liner text field and two buttons. It weighs in at a whopping 1170 kilobytes! That’s more than a megabyte for what technically should not take more than a few hundred bytes.
The Google homepage does a lot more than that. Since it is one of the most important pages for Google, I think that the engineers over there know what they are doing.
I don't think it is a good example of bloat.
I second this! Tree Style Tab is one of the few addons that I cannot live without. Heck, it is one of the reasons why Firefox is my primary browser.
This feature should be made native and the original developer should be rewarded somehow for his efforts.
Public relations pioneer Edward Bernays refined the creation and use of press releases.
Propaganda was used by the United States, the United Kingdom, Germany and others to rally for domestic support and demonize enemies during the World Wars, which led to more sophisticated commercial publicity efforts as public relations talent entered the private sector. Most historians believe public relations became established first in the US by Ivy Lee or Edward Bernays (he felt this manipulation was necessary in society), then spread internationally. Many American companies with PR departments spread the practice to Europe when they created European subsidiaries as a result of the Marshall plan.
A timer for going to sleep would be awesome. Towards the end, the volumne should decrease slowly.
I think an alarm function for waking up would be a nice feature as well. You could set the sounds that you like and when the time comes it would slowly increase the volume over a perioad of 10-15 minutes. This way you could wake up slowly and naturally (forest + rain + thunder would work well as an alarm, for me at least).
Interesting! I wonder what drove their decision to use rational number representation.
Is it possible to turn this feature off and use floating point instead (for performance reasons, let's say)?
My favorite is Source Code Pro by Adobe [1]. I use it on Mac OS X and Ubuntu. On Windows I have to use Consolas, because SCP does not render well in gVim for Windows (at least not on my system).
Note that Source Code Pro does not have an Italic typeface yet. Italics are commonly used for source code comments and most editors will automatically emulate the shapes, often with poor results. Active development is currently being done in this direction [2].
Just a minor nitpick: you are probably referring to an oblique style, not italic. Italic style implies a calligraphic handwriting look-alike, and is way more common with serif typefaces. Oblique style is just glyphs tilted to right, and I think that's what you meant here. No offense intended, of course.
The glyphs can look completely different in italic. http://www.fffranziska.com/#sec_italics And after drawing the glyphs, manually checking and adjusting the kerning between every pair of glyphs takes a lot of time too.
You are right. From reading the comments on the issue [2], this seems to be the reason why it takes so long. Although I have now idea of how fonts are made, I think the work needs to be done for all currently available weights (7 different weights).
I like the idea of an intermediary step between textual programming and visual programming. However the author only discusses how the symbols are rendered. What about input methods? I can think of a few options: use keyboard shortcuts, use the mouse, implement some kind of modal editor (vim-like) or a use special keyboard (APL keyboard comes to mind)?
That's simple... to start a string literal, you type a ", and as you type the green box will continue to expand to contain what you're typing until you type another " to end the literal. This is, somehow, better...
Simply render "xxxx" differently and you are about done; e.g. render it as ˹xxxx˼ with some background highlight.
Incremental text input is a different problem. If you only have to deal with a batch renderer, then no change is needed; if you have an interactive IDE, you might want to complete the closing " so feedback remains sane.
I really wish Mono would gain more traction. C# (3.0 onwards) is one of the nicest programming languages I have worked with (despite its warts). I also heard a lot of good things about F#.
F# is a phenomenal language. Not that C# is bad (it's fantastic!), but the more I use F# the more I feel it's a superior language for most tasks. First-class .NET support is the real kicker, since you can do anything from DB interaction to writing MVC controllers. Integration with existing C# projects is seamless too, so it's really just a joy to work with.
It compares and contrasts C# and equivalent F# code for relatively simple, but common-in-the-real-world examples, while introducing some functional constructs. I'd also recommending reading the "Thinking Functionally" series.
After that I'd recommend skimming some of the topics on the F# wikibook:
It's the product of a little over 20 hours of development across two people new to the language (and thus has some warts...), so take it as a grain of sand. Uses MS Unit Testing framework for F# (available via NuGet).
F# will almost definitively help any C# code. Even if you use F# as a "better C#" you'll see improvements. Just removing excessive type annotations is a nice step up in clarity.
F#'s benefit will come as a bunch of tiny improvements, "programming in the small" as they call it. For instance:
let xs = [ while r.Read() do yield r.GetInt 0 ]
In C#, it's:
var xs = new List<int>();
while (r.Read()) { xs.Add(r.GetInt(0)); }
Or:
let f x =
let x = try int s with _ -> -1
x * 3
In C#, it's uglier. First because try... isn't an expression. Second, because you cannot shadow variables by rebinding them, so you always have to keep "old" vars around and in scope, and cannot reuse handy variable names:
SomeType x;
using(var db = new DB()) {
x = db.GetX()
}
Which is more annoying than it might seem. How much nicer is it to be able to create a new scope at any point in a function, and return a value out of it cleanly?
These are by no means a complete or even important showcase of C#'s lacking. Just a few quick thoughts off the top of my head. In general, every time I'm writing C# code, I keep realising how things would be much more concise if I was in F#.
None of them are killer features. Nor is pattern matching, assorted comprehensions, array slicing, binary literals, bytestrings, tuples, active patterns, records, type inference, immutability, shadowing, nested functions, custom operators, typechecked printf, type providers, workflows[1], sum types, agents, etc. etc.
But it sure all adds up.
Switching for a codebase might not be a wise move for many reasons. But writing new code doesn't have those excuses.
Actually workflows are the closest to a "killer" feature but C# took the most popular, async, and hard-coded it in.
All those words surely do sound impressive when you list them all together just like that. But you can remove at least pattern matching and records, as they are coming to C#. At least some of them is a matter of taste (e.g. nested functions , global inference and custom operators - the latter two can reduce readability IMHO) etc. For me however the killer feature of C# is ReSharper and other tooling. There is no point to argue, F# is a great language, but C# is a great one as well, no need to write code samples to misuse the language and make it look bad. I considered using F# for physics computations (to leverage the units of measure) but unfortunately it provides no solution for marking external types with them (which means I cannot integrate it with e.g. MonoGame). I still have a hope for finding a good use case for F#.
Pattern matching in C# would be a rather big departure and change. And then to match F#'s level of deconstruction, that'd be neat. C# can become F# if it wants, they just have to add in features. They've been hesitant to do so based on limitations of the compiler codebase, as well as fears that C# might get too difficult for mediocre programmers.
I'm not sure how new List<string> { "a", "b" } is more readable than new List<_> {"a", "b"), but hey, sure, if you want to argue type inference is bad, go for it. F# also lacks loop constructs like break/continue.
I don't feel I've misrepresented C# at all to make it look bad. I've written a lot of C# code and a fair amount of F# code. Line by line, char-by-char, expression-by-expression, F# is simply much less code. Those examples are just things off the top of my head, from real codebases.
C#'s alright, because the competition (like Java) is laughable. So in that sense, it's "great". In absolute terms, it doesn't measure up (and this isn't a secret, bit-by-bit C# adopts features F# proved out.)
Units-of-measurements are implemented via erasure, yes. How would you represent float<m> externally to make it available to common types, but without losing performance? The compiler consuming them would need to be aware of it. And at runtime, you certainly don't want extra overhead, and I don't think the CLR has any efficient way of exposing primitives with additional type info. It's an unfortunate tradeoff.
I've got a safaribooks online account, and found "Real World Functional Programming with examples in F# and C#" the most useful of the f# books I've read. The author has a blog, http://tomasp.net/ But I got something out of all of the books.
Are you or is anyone aware of how the F# support for monodevelop(Xamarin Studio) and mono is coming along? I've had good experiences making console and service projects in Xamarin(monodevelop) and would like to give F# a go.. But I just don't see chaining myself to the VisualStudio/Windows environment.
I disagree; C# is bad by comparison. I cannot think of a single reason to use C# over F#, can you? F# is essentially C# but with better defaults and much more easily extensible.
- Writing a WPF app in F# is a real pain (no partial classes, no nice MVVM framework support like Caliburn.Micro). C# is way better there.
- Accessing the DB is easier in C# (just select a nice micro-ORM), type providers do not always cut it.
- When using any kind of library that relies on anonymous types (e.g. Dapper for database access).
- Tooling is still not complete, not being able to create directories in F# project (!) from IDE level (and even if you edit .fsproj, it can be a bit buggy) is really annoying in both web and desktop apps.
- If you want to use some of object-oriented features e.g. co/contravariance in interfaces, protected access modifier.
- (admittedly, that does not happen often) no unsafe context/keyword
That being said, I agree that F# has a very sane set of defaults and I really like using F# for library work.
F# has unsafe capabilities. Look at NativePtr and friends. And since you can make operators, you can end up writing fairly concise code.
The rest of the real arguments are essentially "library support". Which is a good argument, but not really about the language itself. There's no reason that WPF, DB access, etc. can't be just as fine in F#.
(C#'s limitations, like no tuples, led high-profile projects like ASP.NET MVC to do dumb hacks like "pass in an object and we'll assume each field is a parameter". If C# had been more capable in the first place, they wouldn't have resorted to such hacks.)
All of the web's legacy languages are lame and not going anywhere - HTML, CSS, JS. At least WPF gives you some choice - C#, F#, VB. All without crap-trans-piling. The REST is not bad though.
I trialed F# a while back. Something I certainly noticed was not having as much help from the IDE (no resharper). The lambda notation also annoyed me (by comparison to C#). Yeah, I know it's no big deal and I understand the trade-offs being made.. but it still annoyed me. Pattern matching is one of the draw cards - but I see that is coming in C# soon.
Did you give F# Power Tools a go? It gives you a lot of what is missing out of the box. It's still not as great as C# IDE support, but for most things it gets the job done.
While this may come across as sour grapes, I find generally I need less IDE help in F#, since I'm not typing as much boilerplate. For instance, almost all type annotations are inferred (20:1 in my own empirical study), so there's a ton of code I simply don't need to type.
In general, I find writing in C#, I'm going to need 50-200% more code for "business logic" type code that doesn't particularly benefit from F#. That is, using F# as a better C#. And this is after C# hacked in async - before that, there's no comparison if you need async style code.
If C# added pattern matching, tuples, active patterns, type inference, everything-as-an-expression, nesting, more comprehensions, etc. etc., then yes, C# would be competitive. And with all the resources C# gets, the IDE would be far better than F#, sure.
This. F# is superior in every way. The constant stream of articles about C# 6.0 are getting ridiculous when .NET already has a language that is a natural successor.
C# is for legacy and large corporate red-tape-encumbered enterprise projects only, as far as I'm concerned.
C# is a stronger OO language than F#, if you prefer OOP over FP. It also has a lot of functional features that allow you to dip into FP when that is convenient. Not as great as Scala, but definitely a huge step up from Java.
What in particular do you mean by this? "Protected" accessibility, automatic mutual recursion for everything, nested classes -- and a few other edges? Is that enough to say C#'s a "stronger OO" language? Perhaps strictly speaking, as in, it has those few features more. But in practise?
But then what of C#, which lacks object expressions? Which forces you to declare a type, often an interface, just to implement a member or two?
Small potatoes. If I have an OO design, I'm not going to be able to use modules for that, or even structural typing. If you do a lot of class programming, F# doesn't make sense.
I don't think that's fair at all; F#'s integration with the .NET type system is one of its best features. I find that creating class types (and instances) in F# is usually easier than doing so in C#. And with object expressions, you can even program in an arguably purer object oriented style, declaring only interfaces but never concrete class types.
I'm not sure how this is relevant. F# handles creating classes just fine. It's come a long way from the OCaml crosscompiler that you might be remembering.
Usually it is C++ > Java > C# > VB.NET > .... in the Fortune 500 world set I work on.
Not to mention the C++ salary rates in High Performance Finance and High Performance Computing in general. I doubt any C# developer would get those rates.
Fortunately, F# does OO and procedural pretty well, so you shouldn't feel pressure to use a functional style if it doesn't fit.
I noticed that was something certain folks tended to do, they'd insist on creating an expression as a series of folds and maps, even if it had a very simple expression otherwise (as a list comprehension or simple for..in loop). Cast those cares aside, and write what is most useful for your use case.
Sometimes though, you do want break/goto/continue, although in most cases I think such code is better off in C or Rust.
For me, writing procedural OO code in F# always felt awkward and inconvenient. This is a problem because most of the .NET runtime was designed with procedural OO code in mind.
Mono is perceived as a second-class citizen in the Unix-like space. Java, its main competitor, integrates very seamlessly and has excellent runtime tooling support Mono doesn't rival. Mono may gain some traction in some niches, but the Unix-like ecosystem is exceedingly diverse, without any dominant tool. Mono could double its presence and still be barely detectable. It could displace some of Java, but that would not affect the majority of the space.
It's impossible (and foolish) to avoid C# if you develop for Windows, but I haven't written a single line of C# since 2004.
Beg to differ about Java integrating seamlessly - because Java manages its own memory, long running Java processes often need tweaking or their own VM to play nicely on a Unix machine. That's far from seamless.
