Nim

se-insensitivity... I have no problem with that because this way everyone can use his favorite notation. The only thing that strongly reject are strong spaces. That was a silly idea and should be removed instantly.

See: Command-query separation. Adhering to CQS, queries do not mutate arguments, and commands are expected to; hence, you need to know the specific contracts for commands and how they affect their arguments, but can rely on query arguments not changing. More generally, mutability of arguments is just one aspect of a contract; importantly, in order to be able to optimize or change the internal representation of an object, we may desire the option of having mutability of the concrete state even where the abstract state remains immutable (e.g. splay trees or self-organizing lists, arguments that have internal caches, etc.). Languages that force a knowledge of immutability of the concrete state at the call site can thus violate principles of modularity in that they limit how the implementation may change. Declarations of immutability of only the location of the variable at the call site (as with out/ref parameters in C#) are of even more limited value; while they guard against some clerical errors, it is not clear that this protection justifies the additional syntactic footprint. Back to Nim: The simple solution to ensure that a variable is not being modified by the callee, if you desire that, is to use a "let" rather than a "var" declaration. In fact, using "let" for values that you do not intend to change further and only use "var" variables where they are expected to be mutated throughout a procedure is already idiomatic Nim [1] and should guard against the majority of related clerical errors of this kind. [1] https://github.com/Araq/Nim/wiki/Style-Guide-for-Nim-Code

es (and clamp down on the verbosity) you will get something very-alike to python in spirit (+ static type system). This come again from the "obvious" "Pascal compilers ARE fast". They are fast, because, the syntax/language is made to be fast. In fact, most pascal compilers are 1-pass compilers. Is NOT a coincidence that this is the case: The creator of Pascal wrote one of the most influential papers about build your own compiler: https://en.wikipedia.org/wiki/Algorithms_%2B_Data_Structures... A modern take of it is presented in https://github.com/Araq/Nimrod This is why most people agree is easier to program in a dialect of pascal (like Delphi or FreePascal) than in C/C++, for the same kind of tasks. The clarity that bring the syntax could be a part of it (some of us believe) but in the end is that the language is more coherent. Is similar to "python vs ruby" where one is more "magical" than the other. C/C++/Perl/Javascript is more about "A millon ways, not well integrated, in how, maybe, depending on ???, to do stuff" versus Pascal/Python "A predictable, single/small ways to do stuff". Probably, GO is a spiritual sucessor in this area, where fast-compile times are enabled (obviously, among other things) because the language is simpler. That make it in contrast with Rust. This are some of the most superficial things. As like with any language, is better to spend some time using it to appreciate it more. I use it (Delphi) when I was a noob, and I can do stuff that was impossible to me to do in C/C++ (ie: C++ is more complex for the same). Where I read how do anything with them was full walls of code/mess, in Delphi I found more simpler ways. Spoiled badly, because the VCL was absolutely superior than the mess that MCF mean to do windows applications. And the the database libraries round around the ADO, DAO, .NET DataSet and that other stuff people still believe are good ideas... Ada put far more to the table. The main problem was the high cost, that made it out of reach for many. This was a serious trouble with other good languages, like smalltalk. ADA have a lot of the things modern C#/Java is doing now, with what GO, Eiffel and others give too. Still suffer from the "ADA is mainly a costly commercial compiler", but anyway... Modula, in the other hand, look great. Sadly not much exposure of it, and Delphi take the whole "Pascal space" to itself Delphi is amazing, but is the most tragic story of any language ever: Is like if the owners hate it with more passion than any. Is like the Firefly show: Doomed by the studio, but the fans love it to death!

depart: string, arrive: string]] = [(480, "8:00 a.m.", "10:16 a.m."), (583, "9:43 a.m.", "11:52 a.m."), (679, "11:19 a.m.", "1:31 p.m."), (767, "12:47 p.m.", "3:00 p.m."), (840, "2:00 p.m.", "4:08 p.m."), (945, "3:45 p.m.", "5:55 p.m."), (1140, "7:00 p.m.", "9:20 p.m."), (1305, "9:45 p.m.", "11:58 p.m.")] proc minutesSinceMidnight(hours: int = hours24, minutes: int = minutes24): int = hours * 60 + minutes proc cmpFlights(m = minutesSinceMidnight()): seq[int] = result = newSeq[int](flights.len) for i in 0 .. <flights.len: result[i] = abs(m - flights[i].since) proc getClosest(): int = for k,v in cmpFlights(): if v == cmpFlights().min: return k echo "Closest departure time is ", flights[getClosest()].depart, ", arriving at ", flights[getClosest()].arrive Statistics (on an x86_64 Intel Core2Quad Q9300): Lang Time [ms] Memory [KB] Compile Time [ms] Compressed Code [B] Nim 1400 1460 893 486 C++ 1478 2717 774 728 D 1518 2388 1614 669 Rust 1623 2632 6735 934 Java 1874 24428 812 778 OCaml 2384 4496 125 782 Go 3116 1664 596 618 Haskell 3329 5268 3002 1091 LuaJit 3857 2368 - 519 Lisp 8219 15876 1043 1007 Racket 8503 130284 24793 741 This language deserves your attention. [1]: http://goran.krampe.se/2014/10/20/i-missed-nim/ [2]: https://github.com/Araq/Nim/wiki/Nim-for-C-programmers