New Release Of Nim Borrows From Python, Rust, Go, and Lisp (fossbytes.com)

An anonymous reader writes: "Nim compiles and runs fast, delivers tiny executables on several platforms, and borrows great ideas from numerous other languages," according to InfoWorld. After six years, they write, Nim is finally "making a case as a mix of the best of many worlds: The compilation speed and cross-platform targeting of Go, the safe-by-default behaviors of Rust, the readability and ease of development of Python, and even the metaprogramming facilities of the Lisp family..."

Fossbytes adds that Nim's syntax "might remind you of Python as it uses indented code blocks and similar syntax at some occasions. Just like Rust and Go, it uses strong types and first class functions... Talking about the benchmarks, it's comparable to C. Nim compiler produces C code by default. With the help of different compiler back-ends, one can also get JavaScript, C++, or Objective-C.
There's an improved output system in the newest release, and both its compiler and library are MIT licensed. Share your thoughts and opinions in the comments. Is anybody excited about writing code in Nim?

Comments

Hey look!

[DontBeAMoran]

It's yet another hipster language that will be dead in a few months!

Re:Hey look!

[caseih]

Seeing as it's been around and alive for nearly 10 years, I'd say your prediction is not going to be true.

Re: Hey look!

[Anonymous Coward]

Yes, this is more a zombie from the last round of hipsterism

Re:Hey look!

[golodh]

At first I was a bit excited. Compiling a fancy high level language to C or C++? Sounds interesting, right?

Then I clicked through from the standard Slashdot post to the Infoworld article to see what was really going on.

Nothing good.

(1) The language is (after _10_ years of effort) in release version 0.16 (2) under the heading of "What it takes to get to 1.0" we get: "[...] Nim's biggest disadvantage right now is the relatively small community of users involved in its development -- an understandable drawback given its status as an independent work. Development is led by the language's creator, Andreas Rumpf, but it's not a full-time effort. Compiler bugs still pop up regularly. Even moderately old code examples may no longer be useful due to changes, and it can be hard to find out what those changes are without closely following the project's development. [...]"

Right. I've heard enough. Keep that crap and don't bother posting until you've got version 1.0 done.

I would be interested in a tool, not in yet another half-baked DIY project.

Re:Hey look!

[Anonymous Coward]

A langauge that no one import uses for anything of value. GREAT SUCCESS!!

Re:Hey look!

[Anonymous Coward]

There's a myriad of other things we'd be interested in, and we've got editors on Slashdot who go to infoworld, of all sites, to do their muckraking.

Infoworld is not worth your time. I've never seen a good article out of them, everything they do is clickbait.

Shows the direction Slashdot is going on.

Re:Hey look!

[GuB-42]

Ruby is 22 years old, and regularly someone will come out and say this language will take over the world. And despite a loyal user base, it never really took off. It had a bit of success with the ruby-on-rails framework but it didn't last.
Nim is a bit like that, except that it didn't even have the small success Ruby had.

Re:Hey look!

[Crashmarik]

I am still waiting for FORTH and SMALLTALK to rule the world.

Re: Hey look!

[Anonymous Coward]

Shhhh... don't reveal the Secrets of NIM

Re:Hey look!

[caseih]

Sure but that wasn't what the original poster was talking about. Whether or not it has a fraction of the success of Ruby, as long as someone somewhere wants to maintain it, it will live on.

Re:Hey look!

[MouseTheLuckyDog]

Not to mention Lisp, Eiffel and ADA.

Re:Hey look!

[MichaelSmith]

Ada was huge in aerospace but the last time I was there they were using this abominable ada to java source code translator.

Re:Hey look!

[Anonymous Coward]

People figured out it was easier to write a Rails-like framework in their language of choice than to learn Ruby. Game over.

Re: Hey look!

[jdschulteis]

Shhhh... don't reveal the Secrets of NIM

Rats, I really wanted to reveal the secrets...

Re:Hey look!

[Sarusa]

Ruby is a good example of the magpies in action - they hop from flavor of the year language to language to have something new on the resume and to get in while it's still fun and they can still be trendmakers.

Then they flocked off to whatever the new hotness was (I've lost track) and left it as 'That language you use for Rails'.

Python people just want to get their work done and have the code be maintainable, so it endures.

Nim is somewhat interesting, but even that article says that now the hard work starts - you need a library for /everything/.

Re:Hey look!

[jbolden]

They do. The object system from smalltalk is the basis of the one used in Objective-C, Java, Python, Ruby among others. Tablet oriented Oses like the dynapad are selling about a billion units a year in smartphones and tablets. The MVC design pattern is the standard for GUIs. And finally WYSIWYG is absolutely a standard in wordprocessing which has now many times over more popular than any other document construction system.In what possible sense doesn't smalltalk rule the world?

As for FORTH the influence is more on the hardware side. Most of the more sophisticated chips (or subsystems within chips) in your computer use a microcode compiler based on the ideas of FORTH. pdf is based on forth. HP RPL is based on forth and influenced a whole generation of programers early in teaching them how to construct dynamic systems out of small parts. I'm not sure if I'd say "rules the world" but "embedded itself into the DNA of computer science forever" is likely accurate.

Re:Hey look!

[ooloorie]

The object system from smalltalk is the basis of the one used in Objective-C, Java, Python, Ruby among others.

No, sorry, it's not.

Re: Hey look!

[Anonymous Coward]

*Slow clap*

Re: Hey look!

[dougdonovan]

its called a patent ...maybe not valid here.

Re: Hey look!

[dougdonovan]

im sorry but please dont dis on slashdot. thanks.

Re:Hey look!

[Santana]

Why wait? Take matters with your own hands and make Smalltalk great again.

Re:Hey look!

[Santana]

A trip to Wikipedia before posting is all you need to stop embarrassing yourself.

Re:Hey look!

[ooloorie]

A trip to Wikipedia before posting is all you need to stop embarrassing yourself.

I don't need to make a trip to Wikipedia, being familiar with the implementation of three of those languages.

Objective-C's object system is indeed based on Smalltalk's.

Java's is not at all: it lacks duck typing, uses interfaces, lacks many of Smalltalk's dynamic features, and has separate value types.

Python's object system is also very different, with its implementation of objects as hash tables, and its use of bound methods.

But, yeah, if you only have a superficial understanding of OOP and those languages, you might erroneously believe that their object systems are all very similar.

Re:Hey look!

[Santana]

You missed Ruby, which resemblances Smalltalk in many ways.

The original poster didn't say the object systems are similar, but that Smalltalk's object system is the basis of the one used in those languages. Java and Python did a poor job of course.

Re:Hey look!

[ooloorie]

The OP claimed (in context) that "Smalltalk rules the world". But the fact is that Smalltalk's object system has failed. The object systems that have succeeded are either considerably more efficient and statically typed (Java, C++) or considerably more flexible (Python).

Re:Hey look!

[Santana]

Java was successful not because of its object system but because it was C-like and free of charge at a time when Smalltalk was very expensive. C++ is a mess, I doubt its SIMULA inspired object system had anything to do with its success. Python was only the sane alternative to Perl.

Ruby and Objective-C are the closest to Smalltalk and are very successful because of that.

I don't understand how you can extrapolate that to say that Smalltalk's object system failed. Even more so when the OP's idea of ruling the world is not limited to how successful a language is due to its object system, but how influential it has been the last 30+ years.

We are still catching up with the past.

P. S. By the way, Java was so slow at the beginning that Sun Microsystems acquired Strongtalk (a statically typed Smalltalk) and the result of that was the HotSpot VM.

Re:Hey look!

[ooloorie]

Smalltalk has been influential, but some of its key ideas have failed. For example, its approach to software development (browsers, images) has largely failed. Its "everything is an object" approach has failed. Its syntax has failed. Object and type systems of major languages (Java, C#, C++, Python, JavaScript) are substantially different. Concurrency has gone in a different direction.

And we're not catching up with the past; Smalltalk has been mined for ideas to death and every idea in it has been tried multiple times. What hasn't caught on by now has failed for a reason.

Re:Hey look!

[BlackPignouf]

I've been using Ruby every day for more than 10 years, and I'm still learning new stuff every day.
It's possible to write beautiful, productive, readable and maintainable code with it.

Rails is a cool project, but what bothers me is that it changes a lot between versions, sometimes just for the sake of changing stuff. For many people, Rails is the only Ruby project they know, and this might be very confusing because so much "magic" happens behind the scene. 6 months later, this magic has been changed to something else.

My story is basically the opposite of what you described. I love Ruby, but I'm in the process of learning Python, just because it's so widely spread in academia and in the industry. I find the language kinda boring (almost FORTRAN like), but it sure gets the job done. It's simply incredible how many cool projects there are, and how much can be done just by importing 2 libraries and writing 5 lines of code. It's also pretty cool to ask a question about graph theory and have Ron Rivest (R from RSA) replies with a Pygame example.

To me, Ruby is like Italian : I find it expressive and beautiful, but it's not so useful outside of Italy. So I learn Spanish :)

Re:Hey look!

[Shane_Optima]

Seeing as it's been around and alive for nearly 10 years, I'd say your prediction is not going to be true.

Programming language death is an asymptotic affair.

Re:Hey look!

[Sarusa]

Yeah, Ruby is nice - the magpies were not its fault, or having its star hitched to Rails so tightly.

Re:Hey look!

[Anonymous Coward]

> Its "everything is an object" approach has failed.

If the "successful" alternative is Java's mixture of objects and primitive types, well, I can't say it's an improvement.

Whitespace takes the most space

[Anonymous Coward]

You can make the most advanced language with new programming paradigms and slashdotters will spend the entire discussion on tabs vs spaces and indents vs curly brackets ...

Re:Whitespace takes the most space

[johannesg]

What's there to discuss, then? What new thing does Nim bring to the table?

Show me some code that shows how Nim can do things better. It's more convincing than a list of bullet points anyway.

Re:Whitespace takes the most space

[Anonymous Coward]

Everyone knows programming languages achieved perfection in 1983. It's a scientific fact.

Re:Whitespace takes the most space

[Anonymous Coward]

There's nothing to discuss since any algorithm can be written in any turing complete language.

Re:Whitespace takes the most space

[Anonymous Coward]

What new thing does Nim bring to the table?

Nim is a blending of Turbo Pascal/Delphi's strong type system and Python's easy syntax for code inside functions/methods. So you get the quick development speed associated with Python along with high execution performance and type checking associated with Turbo Pascal/Delphi.

Show me some code that shows how Nim can do things better. It's more convincing than a list of bullet points anyway.

The code looks like Python code that runs at near-C speeds.

Re:Whitespace takes the most space

[Half-pint HAL]

Show me some code that shows how Nim can do things better. It's more convincing than a list of bullet points anyway.

Wrong question. The single most interesting idea I've seen in Nim isn't something you can see in a piece of code: it's how it aids the programmer in optimising code late. It's only the memory management system, but the idea is that you prototype your code with a garbage collector switched on, and once the code is working, and assuming you need the performance gain, you code up your own memory management routines tailored to your code.

It's an idea that seems logical, but is frustratingly uncommon, and is not normally an in-built feature of the language, but rather just a part of the dev workflow (for example: use a generic sort algorithm from a library during prototyping, then analyse the data you're working with in large-scale tests and select or code a more efficient implementation for your situation). The weakness in doing this manually is that it first means tying your codebase to a library, with its various quirks, and then potentially rewriting vast chunks of code to get it to work with a different library (and then there's the risk of cascading changes).

I think Nim's approach is a small step in the right direction, taking us towards logic first, optimisation later.

Re:Whitespace takes the most space

[johannesg]

There's nothing to discuss since any algorithm can be written in any turing complete language.

There's plenty to discuss, since the ease with which you can express yourself matters greatly in any practical sense. However, the progress we have actually made in this area is not nearly as impressive as one might hope - new languages mostly bring us the same thing, but with slightly different syntax. Real breakthroughs are very, very rare. Remember the 4GL initiative from Japan in the nineties? Still waiting for that killer language... The closest I've seen is the Wolfram language. Maybe that's the way forward: a massive support library and huge, online databases.

As for Turing machines... On a machine with finite memory, all states the machine can be in can be enumerated, and each state always leads deterministically to a single next state. Since the total number of states is finite (very large, but finite), this means that at some point it must either return to a previous state, or halt. If it returns to a previous state, it will then continue to loop forever (since each state deterministically leads to a single next state). Thus, if you have the capacity to track state changes for long enough, you will be able to determine if a program will halt or not.

And yet, there's Turing's proof. Why the discrepancy? Well, simple: a Turing machine has an infinite tape, and can therefore produce not a finite, but an infinite number of states. Any computer we have in the real world does not have infinite memory, and is therefore not a Turing machine. To be considered Turing-complete, a language must be able to simulate a Turing machine - and that's actually impossible, since it can never meet the "infinite tape" requirement. You might claim that "any algorithm can be expressed in any Turing complete language", but since we don't have any, that's really a moot point, and we would perhaps be wiser to focus on other aspects of the language rather than a theoretically impossible, and perhaps even undesirable feature.

Your move, AC ;-)

Re:Whitespace takes the most space

[Anonymous Coward]

Different AC here. A language can be considered Turing-complete even if the machines you can run it aren't universal machines.

Re:Whitespace takes the most space

[Anonymous Coward]

Remember the 4GL initiative from Japan in the nineties? Still waiting for that killer language...

Yet Another AC here. Their 5GL languages KL0 and KL1 have been released as open source for several years. Those are basically versions of Prolog to do low level programming, such as writing operating systems for parallel computers.

The main problem of the Japanese 5th Generation project was that their dedicated parallel hardware could not compete with clusters of cheap off-the-shelf hardware.

Different AC here. A language can be considered Turing-complete even if the machines you can run it aren't universal machines.

I was going to say the same thing.

Your move, AC ;-)

We are legion.

Re:Whitespace takes the most space

[K. S. Kyosuke]

And yet, there's Turing's proof. Why the discrepancy? Well, simple: a Turing machine has an infinite tape, and can therefore produce not a finite, but an infinite number of states. Any computer we have in the real world does not have infinite memory, and is therefore not a Turing machine.

A slight correction, perhaps: for practical purposes, and for algorithms that use memory bounded linearly in time, it's effectively infinite because we can just keep manufacturing it.

Re:Whitespace takes the most space

[murdocj]

doesn't sounds all that unique. Lots of languages let you muck with memory allocation. For example C++

Re:Whitespace takes the most space

[Anonymous Coward]

Perhaps because languages that waste lots of white space and/or require it specially formatted are a pain to work with?

Re:Whitespace takes the most space

[Anonymous Coward]

To be considered Turing-complete, a language must be able to simulate a Turing machine - and that's actually impossible, since it can never meet the "infinite tape" requirement. You might claim that "any algorithm can be expressed in any Turing complete language", but since we don't have any, that's really a moot point, and we would perhaps be wiser to focus on other aspects of the language rather than a theoretically impossible, and perhaps even undesirable feature.

I wonder how a comment with such a remarkable conceptual mistake can get the highest informative score, while the comments pointing out the mistake are ignored.

The Turing-completeness of a language is a property of the language, and has nothing to do with the machine where the language is used. Otherwise there would exist no Turing-complete language at all.

So, yes, there are definitely many Turing-complete languages. And no, they are not equivalent. Try to write an OS with this: https://en.wikipedia.org/wiki/Brainfuck .

Re:Whitespace takes the most space

[swillden]

To be considered Turing-complete, a language must be able to simulate a Turing machine - and that's actually impossible, since it can never meet the "infinite tape" requirement.

Languages are not machines. Languages have no memory limitations, and therefore have no trouble simulating a Turing machine.

The fact that we run code written in those languages on finite machines does not change the Turing-complete nature of the languages.

Re:Whitespace takes the most space

[MichaelSmith]

So its pascal without begin and end?

Re:Whitespace takes the most space

[Half-pint HAL]

doesn't sounds all that unique. Lots of languages let you muck with memory allocation. For example C++

But C++ doesn't have a garbage collector, and more generally most languages have [i]either[/i] implicit garbage collection [i]or[/i] explicit memory management -- Nim has both, allowing you to ignore memory management completely until you're ready to optimise -- that's a very useful thing. I'm no expert on languages, so I don't know which of the more advanced multi-paradigm languages have similar options -- but it's something that's still missing from mainstream languages.

Re:Whitespace takes the most space

[Sarusa]

By that logic, if I want a production script to copy some files around and test a few things I should code it up in C++ or ASM since all languages are technically equally suited for the task.

Re:Whitespace takes the most space

[Anonymous Coward]

But what is the value of an algorithm that you can't actually execute?

In the practical world, language efficiency actually matters and is a reasonable thing to discuss.

Re:Whitespace takes the most space

[Anonymous Coward]

Don't you understand? Theoretically there is nothing to discuss!

Re:Whitespace takes the most space

[swillden]

But what is the value of an algorithm that you can't actually execute?

In the practical world, language efficiency actually matters and is a reasonable thing to discuss.

Sure, that's true. But it has no bearing on the question of whether a language can accurately be called Turing Complete -- and Turing Completeness also matters, because it defines the class of algorithms that can be implemented in the language. What's the value of an algorithm that you can't implement because the language lacks the necessary expressive power? Except in very limited circumstances, Turing Completeness is a prerequisite. Without it, there's no point in discussing efficiency.

Re:Whitespace takes the most space

[jbolden]

FWIW Wolfram's language is a functional programming language. If you want to learn a very cool language that takes those ideas much much further I'd suggest Haskell.

Re:Whitespace takes the most space

[jbolden]

Mod parent up. Excellent short description about what Nim is bring to the table.

They took the worst part of Python

[Snotnose]

I prefer {} instead of tabs/spaces to define my code blocks. It's the only part of Python I don't like.

Re:They took the worst part of Python

[Anonymous Coward]

Making Python Great Again!

Re:They took the worst part of Python

[zalas]

Do you only use braces or do you indent as well?

Re:They took the worst part of Python

[Anonymous Coward]

This is also the only part of Python i still hate after 3years

Re:They took the worst part of Python

[caseih]

Interesting how personal preference plays into it. But it also sounds like you haven't spent any real time with Python. Because it doesn't take long to get past the whitespace syntax and get on with programming. For most Python programmers, the block syntax is one of the things they like the most. It's true that a bad copy and paste or accidentally deleting some spaces in the wrong place can break things badly and potentially lead to subtle bugs. But in practice, that doesn't seem to be a significant problem. The fact is you should be indenting consistently anyway, so braces and semicolons are superfluous, and ugly.

I find I can write several pages of Python code and often it runs the first time without issue, which was never the case with any of the other languages I worked with, including C++. Invariably I'd forget some closing brace somewhere and a semicolon. Compile errors on first run are almost expected with C-like languages.

Python's real gotchas emerge more from its dynamic nature than its syntax; dynamic typing is a two-edged sword. Test-driven development is pretty much required for large applications.

Nim of course is statically-typed and has some measure of compile-time safety.

Re:They took the worst part of Python

[Thanatiel]

That and the language (lack of) compatibility.

I wrote a project in 2.6 a while ago but a week before production I'm told that the machine would use 2.4
Imagine my surprise when I noticed that some keywords were working differently (something about the exception handling was looking like it was working, but breaking, I don't remember exactly what).

Now, if I want to use some scripting language to quickly so something (by opposition to do something fast) I use perl (cleanly) or bash.

(For the serious stuff I'm more an asm/C/C++/C# guy anyway.)

Re:They took the worst part of Python

[JustAnotherOldGuy]

I prefer {} instead of tabs/spaces to define my code blocks. It's the only part of Python I don't like.

Same here. I confess I like the "syntactical sugar" of curly braces. I think it improves readability by an order of magnitude. The whole deal with using whitespace as code block delimiters seems retarded to me.

Re:They took the worst part of Python

[JustAnotherOldGuy]

It's true that a bad copy and paste or accidentally deleting some spaces in the wrong place can break things badly and potentially lead to subtle bugs.

Well there's a ringing endorsement if I ever heard one.

Re:They took the worst part of Python

[Anonymous Coward]

I assume you don't bother with indentation at all, right? I mean, you have the brackets, and brackets without whitespace is more legible than whitespace without brackets...

Re:They took the worst part of Python

[Anonymous Coward]

And yet every one of your examples are full version differences, not point releases. I would expect differences like that when changing major versions, not minor.

Re:They took the worst part of Python

[Snotnose]

The problem is when you're tracking down a problem and want to comment out a block of code. With braces it's a simple "if(0){....}'. With whitespace you have to indent the block, which is error prone.

Re:They took the worst part of Python

[Anonymous Coward]

Ensuring reverse-compatibility is nice but ensuring future-compatibility is impossible. Of course if you used 2.6 features they won't be there in 2.4, are you blaming Python for that?

Re:They took the worst part of Python

[Anonymous Coward]

Well, how about that:

It will do *exactly* what it looks like it's doing at a first glance. I.e. it looks just the way it actually is.

Paren-and-brace-Languages can't say that. Nobody knows the parenthesis level without actually counting it from the very beginning - a slow and error-prone process.

What's that? You use indentation to keep yourself from needing to paren-count? That's what I thought. Python just does the obvious next step.

Re:They took the worst part of Python

[Anonymous Coward]

Try

  from __future__ import ...

Re:They took the worst part of Python

[fahrbot-bot]

For most Python programmers, the block syntax is one of the things they like the most. It's true that a bad copy and paste or accidentally deleting some spaces in the wrong place can break things badly and potentially lead to subtle bugs. But in practice, that doesn't seem to be a significant problem.

So it can either "break things badly and ... lead to subtle bugs" or it's "not a significant problem". As someone else said, "a ringing endorsement".

The fact is you should be indenting consistently anyway, so braces and semicolons are superfluous, and ugly.

Doesn't change the fact that the Python block syntax can cause serious problems and offers *no* actual benefit over using delimiters like {} and using delimiters solves the problems Python's syntax can cause. The simple fact is there's no need for this syntax in Python other than the whim and hubris of the language developer.

Re:They took the worst part of Python

[Waffle Iron]

How about select the block, then :s/^ /##

Re:They took the worst part of Python

[Half-pint HAL]

As I say every time this debate comes up: every code editor I use carries out parenthesis matching. There is no reason that indentation levels couldn't be automatically displayed based on the parenthesis data and rendered to screen based on the user's preferences. If people still want to be able to read the code in a plain text editor, then have the editor save a set number of spaces per indentation level. (2 maybe? 4?)

Re:They took the worst part of Python

[Anonymous Coward]

The fact is you should be indenting consistently anyway, so braces and semicolons are superfluous, and ugly.

There's a thing you should look into which will greatly aid your productivity and help you become a better software engineer. It's called an IDE. If you have to manually manage indentation in a bracketed language, you need better tools. In Python you must manually manage indentation because the IDE can't figure it out for you.

I find I can write several pages of Python code and often it runs the first time without issue, which was never the case with any of the other languages I worked with, including C++. Invariably I'd forget some closing brace somewhere and a semicolon. Compile errors on first run are almost expected with C-like languages.

Again, use an IDE. An IDE will indicate your errors while you're typing them so you can fix them before you even finish writing the line. You should never see compile-time error in a modern, statically typed language. Your Python code is just as buggy as your C++ code, you simply don't realize it. Changing languages doesn't magically improve your typing skills nor your programming skills.

Python's real gotchas emerge more from its dynamic nature than its syntax; dynamic typing is a two-edged sword.

Test-driven development is pretty much required for large applications.

No, you seem to be using it as a crutch to make up for poor language choices and lack of good tooling. TDD should be used to test features, pre-conditions, and post-conditions, not as a check against coding issues. It helps you improve design and protect product features when the code becomes legacy code. You can create large applications without it. If you can't then you're using the wrong tools/languages or your programmers are too inexperienced for the scale of your project. TDD will certainly aid in development, but it is by no means near-required.

There are definite pros to using Python, but you haven't listed any.

Re:They took the worst part of Python

[Half-pint HAL]

The fact is you should be indenting consistently anyway, so braces and semicolons are superfluous, and ugly.

How is Python's colon any less superfluous? Every block is preceded by a colon, and there is no situation where anything else can go in place of the colon. As far as I can see, the colon is 100% redundant within the syntax. (Excluding list syntax, naturally.)

Re: They took the worst part of Python

[Anonymous Coward]

The IDE probably handles his indentation for him, even when he copies and pastes some code from one place to another

Re:They took the worst part of Python

[Anonymous Coward]

The problem with using whitespace in Python is that it makes the language less powerful.

Everyone uses indentation, but only Python uses it to make the language weaker.

Plus, that fucking selfSELFself bullshit which only exists because Guido is a dumbfuck that didn't have ANY scoping in the language initially and then came up with "explicit is better than implicit" to excuse his idiocy and the Python cult drank that kool-aid. If you don't know what scope you are in at any given time you are a fucklenut. It is the most trivial thing in the world.

Fuck Python. It is the Java of dynamic languages.

Re:They took the worst part of Python

[caseih]

Like I said, this is rarely a problem in practice.

Re:They took the worst part of Python

[caseih]

You've obviously not used Python before. It's very easy to comment out a block of code and it doesn't require indenting anything, and it doesn't require an if (0) kludge. Your criticism and claim of being error-prone is not valid in this case. Python has a lot of gotchas and warts, but what you describe isn't one of them.

Re:They took the worst part of Python

[Anonymous Coward]

>There is no reason that indentation levels couldn't be automatically displayed based on the parenthesis data

Yeah, but nobody does that and even Apple and other huge companies have created horrible security bugs because they extended a branch of an "if" statement to two statements without adding the parens around the two statements that one would need then. Huh.

Meanwhile, you can just have the indentation signify blocks which is how every human alive understands it anyhow and which require no special editor support and no weird manual fixes by the person editing it.

>and rendered to screen based on the user's preferences.

Part of that feature is called "tabs". Strangely that's going out of fashion, replaced by multiple spaces where the user can't set their own size preference.

But I know what you mean. I'm more of a LISP person anyhow and I dislike programming languages where you can't directly see the AST as a tree. What is that? English literature?

>If people still want to be able to read the code in a plain text editor, then have the editor save a set number of spaces per indentation level. (2 maybe? 4?)

Just save a tab per indentation level and let the user decide how much that is.

Re:They took the worst part of Python

[Anonymous Coward]

Just do """

huge block here"""

Indentation within the """ block doesn't matter.

Re:They took the worst part of Python

[jaklode]

It is, it only exists to clarify: The next line begins a new block.

Re:They took the worst part of Python

[CrashNBrn]

Curly Braces can be highlight matched, whereas tabbed indentation cannot.

FOO()
  {
  BAR();
  }

Re:They took the worst part of Python

[Anonymous Coward]

In Python, the colon was added because of usability testers asking for it. Picture that: a programming language that actually cares about its users enough to make them do usability tests - and then listening to what the testers had to say. Python is one of the most liked languages for a reason.

That said, I would prefer if the colon wasn't there either.

Re:They took the worst part of Python

[murdocj]

I really don't like the modern tendency towards dropping syntactic markers like parens or braces. We aren't writing the Torah on lambskin, where every scrap is precious, we have as much space as we want to make the code legible. And if typing the braces is a measurable percentage of the time you spend coding, you aren't thinking enough.

Re:They took the worst part of Python

[MichaelSmith]

Working in C years back I had to fix some code from a guy who pasted 1500 lines from a different application into the middle of an if statement block. He didn't even have the decency to wrap a function definition around it. It was just splurged into the code. It seemed to work fine but even with the parenthesis matching function in nedit it was hard to work out what block I was in.

In that case python would break, because the compiler reads the nesting level the way humans read it.

Re:They took the worst part of Python

[MichaelSmith]

Having tried to code in coffeescript, which has indentation without the colon, I much prefer python.

Re:They took the worst part of Python

[Half-pint HAL]

>There is no reason that indentation levels couldn't be automatically displayed based on the parenthesis data

Yeah, but nobody does that and even Apple and other huge companies have created horrible security bugs because they extended a branch of an "if" statement to two statements without adding the parens around the two statements that one would need then. Huh.

Yes, but automatic indentation in the editor would have automatically highlighted the mistake, and the programmer could have fixed it immediately. Why are computer programmers such luddites? We try to fix other people's problems with technology, but insist that our jobs should be carried out using 1970s technology.

Meanwhile, you can just have the indentation signify blocks which is how every human alive understands it anyhow and which require no special editor support and no weird manual fixes by the person editing it.

Humans may not vary much, but computer screens do. Consider that the whole point of things like HTML is to abstract out formatting in order to allow the same content to be rendered on various devices, including print.

I really think it's time we started getting smarter with our coding environments. Customisable display doesn't just mean indentation levels. Maybe you want to see an argument list in one line: result = functioncall (size=1, number=2, somethingelse=3)

but maybe I want to see it tabulated, with the arguments lined up on individual lines, and both the parameter names and values lined up in two columns. Or maybe just the arguments on different lines, but within setting up columns.

These sorts of differences exist today as "programming style", even in Python (indentation is meaningless in continuation lines in Python). But because the style (rendering) is an integral part of the source code, the programmer is forced to adapt to the chosen style of the team, project or company they work with. This is inefficient and distracts the programmer from the main goal: writing the code.

I'm more efficient when the information is laid out in the way that I find clearest.

But even that may change with time and with what job I'm doing. Maybe I want to be able to "unfold" a single line into a tabulated form for closer examination, or "fold" a tabulated form into a single line to get the "bigger picture" of the code.

But what I shouldn't have to think about is how anyone else is going to see the source code.

Re:They took the worst part of Python

[Anonymous Coward]

> whereas tabbed indentation

There is your complete failure. While you should use the 'tab' key, your editor should be converting that into the appropriate number of spaces so that the source is _not_ 'tabbed'. You probably should also have the editor show visible tab characters so that you can eliminate entirely.

If you want to have 'tabbed indents' (rather than spaced indents) then please do not use Python.
 

Re:They took the worst part of Python

[Anonymous Coward]

Working in C years back I had to fix some code from a guy who pasted 1500 lines from a different application into the middle of an if statement block. He didn't even have the decency to wrap a function definition around it. It was just splurged into the code. [...]

I'm pretty sure the word you want is "splooged", not "splurged".

Re:They took the worst part of Python

[JustAnotherOldGuy]

Like I said, this is rarely a problem in practice.

In some languages it never happens at all, ever, which frankly seems like a good thing to me.

And why should it- it's called "whitepace" for a reason, and that generally means it shouldn't matter. Why should a missing (or extra) space crash your program?

If you like whitespace so much, why not program in it?

Whitespace: https://esolangs.org/wiki/Whitespace

Unispace: https://esolangs.org/wiki/Unispace

Re:They took the worst part of Python

[Dadoo]

Because it doesn't take long to get past the whitespace syntax and get on with programming.

Agreed. I really don't understand why everyone complains about whitespace, when Python's almost religious insistence on counting from 0 is much more difficult to get used to. I mean, i get why range(8) counts from 0 to 7, but range(1,8) counts from 1 to 7? That makes no sense at all.

Re:They took the worst part of Python

[jbolden]

I've used languages that are whitespace sensitive. Generally indention errors throw compile errors. Which means the benefit is code ends up properly indented. Moreover because the compiler enforces indention rules indention becomes somewhat standard in the language community aiding human readability. Humans see whitespace more easily than punctuation. Readability is a big actual benefit..

Re:They took the worst part of Python

[AuMatar]

It isn't personal preferences. Braces are completely superior, using indentation alone causes problems:

*Mixing of the two causes programs to perform differently, but the bug isn't visible. This once cost me 3 weeks to track down a bug where one line in 30K from a contractor used a tab instead of spaces. This isn't the only time I've seen it cause bugs, just the worse.

*Copy pasting from the web is nearly impossible.

*When editing other people's code you don't know what to use. I actually just copy paste the line above every time, its the only way to assure it uses the right thing.

This stupid concept has cost more time than any other language decisions I've ever dealt with.

Now you're going to say "if you just follow the style guide...". That's not an answer. If you just wrote code the right way there'd never be a memory issue in C++ either. If you want the style guide to be necessary, make everything other than the style guide a syntax error.

Python is completely unusable just due to this issue.

Re:They took the worst part of Python

[walterbyrd]

> The fact is you should be indenting consistently anyway, so braces and semicolons are superfluous, and ugly.

Why do python advocates always assume you have the luxury of exclusively working with your own code?

Re:They took the worst part of Python

[JustAnotherOldGuy]

I assume you don't bother with indentation at all, right?

You assume incorrectly.

I love indenting; it's near and dear to my heart. In fact sometimes all I do is indent without actually writing any code.

Re:They took the worst part of Python

[Anonymous Coward]

I comment out a block of python by turning it into a string.

Then again, I comment out a block of c by using #if 0 or /* */ depending on whether there are any block comments.

Re:They took the worst part of Python

[Tough Love]

it doesn't take long to get past the whitespace syntax and get on with programming

You might get past it, but it will never stop bothering you. One of the more spectacular blunders in language design, imho. Another one, also in the Python camp, is the brain-damaged aversion to efficient executables. It says a lot about the language that it succeeds in spite of those two remarkable displays of incompetence. But Perl, not to be undone, came up with "there's more than one way to confuse things".

Re:They took the worst part of Python

[Half-pint HAL]

I'm not saying it's a bad thing -- quite the opposite: redundancy is often a good thing. But the justification seems half-hearted, because it doesn't eliminate redundancy, so it's not about eliminating redundancy. It's a block_start token, even if some people choose to play semantics and claim it's part of the command syntax: a block is always preceded by a colon. I don't like the explicit start marker without the explicit end marker. Yes, start marker only does seem a little more like human language, but computer languages aren't human languages.

Re:They took the worst part of Python

[Anonymous Coward]

> It is, it only exists to clarify: The next line begins a new block.

Actually, it doesn't need a new line:

if (something): true_action()
else: false_action()

Re:They took the worst part of Python

[Coryoth]

Python is completely unusable just due to this issue.

Indeed, it is completely unusable which is why absolutely no one uses it, and there are no significant projects of any kind that use it as a language.

Re:They took the worst part of Python

[Anonymous Coward]

I initially chose ruby over python because I did not like the indenting.... 10 years later, and after using HAML / SLIM templates... I wish ruby used indenting like python. Still happy about choosing ruby over python as my "goto" language tho.

Re:They took the worst part of Python

[lars_stefan_axelsson]

Doesn't change the fact that the Python block syntax can cause serious problems and offers *no* actual benefit over using delimiters like {} and using delimiters solves the problems Python's syntax can cause.

Yes it does have a benefit. Since people actually read indentation and not braces, a brace in the wrong position, aka wrong indentation, leads to bugs as well. Enforcing what people actually read, instead of differentiating between a convention for humans (indentation) and syntactic rules for the compiler lessens those risks.

That's not to say that Python's choices are perfect, and that there aren't gotchas. But to say that it carries no benefit isn't true either.

Re:They took the worst part of Python

[Anonymous Coward]

Braces are much easier to get right.

Significant whitespace plus the superfluous colon is retardation.

Re:They took the worst part of Python

[Anonymous Coward]

minor versions vs major

derp

Re:They took the worst part of Python

[Anonymous Coward]

And why should it- it's called "whitepace" for a reason, and that generally means it shouldn't matter.

Yes, Python is different. That's not a bug, it's a feature.

But it also sounds like you haven't spent any real time with Python.

This.

I'm also just another old guy. Over the years I've been in several situations where I thought, "Oh no ... the language does that!". However, there have been 2 cases where I thought that & later (after working for months or years) found it was a *complete* non-issue for me ... and indeed had unexpected benefits.

Python's use of whitespace was one of these. In 4+ years of 50% python (& 50% C) I *never once* had an issue caused by whitespace. OTOH, the whitespace was a contributing factor to code-succinctness & clarity ... which was also especially useful when working in a team. (Oh, and none of the other team members reported any whitespace induced breakage either.)

[FWIW, the other occurrence was Objective-C's dynamic typing. Never a problem. Ironically ... as the C++ folks I worked with were complaining about Objective-C's typing ... when I moved to the C++ project we found we couldn't trust the compiler. Ah, those were the days... :-) ]

The toxic community worries me.

[Anonymous Coward]

I lurk on the Nim IRC channel sometimes. The toxicity there can be unbelievable.

Look at these IRC logs, for example.

We see insults like:

17:46:17 ldlework EXetoC: the problem is that you're just spouting weightless and thoughtless generalizations about how you can whimsically avoid BlaXpirit_'s problems with magical design

19:08:33 ldlework Your justification is piss.

19:10:07 Zuchto BlaXpirit_: because ldlework is being an ass to the person that, as far as I know, is doing just that

20:14:47 Zuchto ldlework: still being an ass, I would say that that makes any high ground you try and claim about being a "good internet citizen" pretty much null and void.

And there's lots of unnecessary sarcasm:

19:54:14 ldlework "Nim supports generics and inheritance but if you want to do OOP programming, Fuck You, Nim is really a functional language because we arbitrarilly limit the language to mirror limitations in F# (which show up for compltely unrelated reasons than in Nim)

Then there's lunacy and quasi-psychotic ranting and rambling:

19:58:39 Triplefox I like the modules as they are
19:58:51 ldlework Triplefox: we're not trying to change the module system per-say
19:59:06 ldlework And, great as long as they're sufficient for you, we should all shut up
19:59:19 BlaXpirit_ damn you're good at arguments
19:59:19 ldlework Let us remember to run by all our shortcomings with Nim through Triplefox first
19:59:47 ldlework BlaXpirit_: because the actual answer here is "Oh right, just wait until forward type declarations."
19:59:58 Triplefox Uh, so you want to bully?
20:00:17 ldlework If Araq had just said that instead of taking some high-brow self-contradicting position for which he can provide no direct argumentation against, then we both would have been satisfied long ago.
20:00:26 ldlework Because that's all that needed to be said about this problem.
20:02:57 ldlework Triplefox: Uh, so you just want to sqaush other people's conversations that have no effect or bearing on you by making a wierd obersvation that you don't suffer the same difficulty as others?
20:02:59 ldlework What?
20:03:56 Triplefox Your conversation consists of forcing someone to say they're wrong
20:04:06 ldlework Nope
20:04:08 ldlework There is a problem X
20:04:14 ldlework there is a sufficient solution Y
20:04:23 ldlework But Y is purportedly bad because X shouldn't be a problem at all
20:04:31 ldlework so instead of providing a solution to X
20:04:32 ldlework we say
20:04:34 ldlework You're wrong.
20:04:37 ldlework You're thinking wrong.
20:04:40 ldlework You're a bad programmer.
20:04:42 ldlework Read this article.
20:04:56 ldlework If there was a solution as nice as Y, that we were missing, everyone here would have provided it.
20:05:03 ldlework Instead of the hand waving and high-browing.
20:05:37 Triplefox Except that you're getting a change already
20:05:45 ldlework Triplefox: right, that was my point, that's Y
20:05:55 ldlework But we just had to pointout how people who need Y are terrible programmers
20:06:06 ldlework Because there is some hidden unspoken thing you could do instead of X that would alleviate it
20:06:16 ldlework Just it seems no one can actually produce what that altnerative is
20:06:38 ldlework So the discrepency between "Shutup and just write your software correctly" and the blinding abscence of a simple solution being reported into the channel, speaks volumes.
20:07:25 BlaXpirit_ this happens every time on this channel
20:07:30 ldlework Maybe next time we can just skip the bullshit
20:07:33 ldlework and talk about the engineering
20:07:37 Triplefox Well, did you actually present the problem that requires your solution in a way tha

Re:The toxic community worries me.

[Anonymous Coward]

freenode
  (the shittiest, least-free IRC network on the internet) full of toxic E-males

not worth your time

Re:The toxic community worries me.

[Anonymous Coward]

nim needs a code of conduct which only lets you in if you are a SJW.

Re:The toxic community worries me.

[Anonymous Coward]

Sound like you need to hang out at #safespace, snowflake.

Re: The toxic community worries me.

[Anonymous Coward]

Sounds like you need to go back under your bridge, troll.

Gratuitous bitching is nothing but a waste of time which is what the above logs show. Nim users appear to be the worst of all languages rolled into one group.

Re:The toxic community worries me.

[WaffleMonster]

I lurk on the Nim IRC channel sometimes. The toxicity there can be unbelievable.

I don't know any of the people who created any of the non-DSL languages I use every day. I don't know if they worship Natas and sport Hitler Mustaches or if they have some kind of oxymoron "tolerance" thing going on like the Rust heads. I don't know if they are into Satanic rituals while being employed by NSA as part of ongoing efforts to compromise all the worlds systems.

How can anyone take the language seriously when they have to put up with so much anger and rudeness from its community?

How can anyone seriously care? People select languages for RESULTS not social hour. The only thing I care about is technical merit.. whether NIM can deliver. I have never in my life heard of anyone contemplate criteria for selecting a language based on who said what in an IRC channel.

Re:The toxic community worries me.

[HiThere]

I've looked at Nim a couple of times, most recently earlier this month. I didn't get much beyond looking, as I need various libraries as well as the basic language, but it did look interesting. If you only need one or two external libraries it might be worth your while to look at it more deeply than I did.

But I really doubt that their code generation averages as fast as decently hand-crafted code. But it may well be a lot faster to write.

Re:The toxic community worries me.

[Anonymous Coward]

People select languages for RESULTS not social hour. The only thing I care about is technical merit.. whether NIM can deliver.

The ability to deliver professional-quality software depends very heavily on the authors being professional in general. People who have high standards for their own appearance, communications and conduct will almost always have higher standards for the quality of their work, too.

Maybe you missed it because you didn't actually read the GP's comment, but it contains this info -

Even the creator of the language says he makes language changes to avoid arguments, rather than because such changes improve the language:

19:04:02 Araq ldlework: I intend to "fix" it because I'm tired of arguing ... not because it's a particularly good idea

That makes it sound like changes to the Nim language and implementation aren't always being driven by technical merit. I don't want the development of a programming language I'm using being driven by how little the main developer feels like arguing, especially if the change is bad from a merit point of view.

If communication like that example from the project's leadership doesn't scare the hell out of you, well, perhaps you have no business writing software of any sort.

Re:The toxic community worries me.

[serviscope_minor]

How can anyone seriously care?

Because languages are not static. Their future depends on the development community.

As ugly as python

[Anonymous Coward]

no, thanks!

Excited about writing code in Nim?

[alvieboy]

Nim (*).

We are The Knights Who Say "Ni!".

(*) In Portuguese, "Nim" can be seen as a hybrid of "no" [Não], and "yes" [Sim]. Often used to express "I could, but I won't".

Re:Excited about writing code in Nim?

[Anonymous Coward]

Bullshit. Stop with these "well in some obscure language it means this..." posts. No one cares, and "nim" doesn't mean ANYTHING in Portuguese anyway.

Re:Excited about writing code in Nim?

[Anonymous Coward]

I lived in Portugal and Brazil for many decades each, and this is the first time I heard of "nim". Perhaps it's a regional expression? Anyway, it doesn't seem correct to say it's often used.

Re:Excited about writing code in Nim?

[Anonymous Coward]

How were the trannies in Brazil?

Re:Excited about writing code in Nim?

[alvieboy]

"and "nim" doesn't mean ANYTHING in Portuguese anyway."

It does. You are not Portuguese, otherwise you'd knew.

And, as a matter of fact, "Portuguese" is not an Obscure Language. It's the sixt more spoken language in the world.
Sorry about that.

Re:Excited about writing code in Nim?

[alvieboy]

If you are not a native, chances are you never heard it. Note that it's not an official Portuguese word.

Some references:

http://www.publico.pt/destaque...
http://invisiblehand.blogs.sap...
http://visao.sapo.pt/actualida...
http://www.jornaldenegocios.pt...

Re:Excited about writing code in Nim?

[Anonymous Coward]

No one give s a crap about your third world language. Nim isn't a word in Portuguese.

Myh language 'Anal'

[Anonymous Coward]

I use indents, braces and BEGIN and END so....

BEGIN
{

code here

}
END

I'm working on a new version of Anal called Anal++

Anyways, the language is designed to keep anal retentive developers arguing in nonsense meetings for years to come. "Oh no! Never put the curly braces and the BEGIN/END on the same line!"

"No, it's better to do so but indent 4 spaces and not a tab!"

"I STRONGLY disagree, you should never use tabs but SHOULD put the curly braces on the same line!"

"No no no! Indent AFTER the Begin but before the curly brace!!!!"

Re:Myh language 'Anal'

[Anonymous Coward]

Insert N2 : # # #

Re: Myh language 'Anal'

[Anonymous Coward]

Either style works, but having to put "code here" as the first line of every block of code seems a bit much.

Re:Myh language 'Anal'

[umghhh]

I like that.

Re:Myh language 'Anal'

[MichaelSmith]

Which should be solved with an editor which shows the programmer what they want to see, not what others have typed.

Re:Myh language 'Anal'

[Walter White]

Don't forget to end each statement with a semicolon ';', use two characters for assignment statements ':=', surround conditionals with parenthesis '()'.and follow with a colon ':'.

BEGIN
{

if(anal):
BEGIN
{
code := here;
}
END

}
END

Reminds me vaguely of Pascal with Python syntax

[caseih]

The example code I've seen from Nim reminds me a bit of Pascal. At least the use of the keywords proc and var. Glad they went with Python-style blocks instead of Pascal-style begin and end.

But nim does look like a nice language. The fact that it generates C code and compiles with a C compiler means that it could be integrated quite smoothly into projects using other languages.

Nim is on my list of languages to try some time if I ever need to write C-compatible code.

Nim is a great

[Anonymous Coward]

Nim is great but I strongly recommend anyone using it consider the Rod framework. It improves maintainability by changing any Nim program to one that prints "Write this program in a real language" on the screen I n a blinking neon marquee.

Readability?

[JustAnotherOldGuy]

"...the readability and ease of development of Python..."

I'll admit I'm not really a Python user, but I've seen lots of Python code and compared to other languages I've never considered Python to be very readable.

Re:Readability?

[HiThere]

The language that's easy to read is the one you know well. I've used Python enough to think that it's easier to read than C or often C++ code that does the same thing. C's problems is indirections via multiple levels of pointers and macros. With C++ it is just that the language as a whole is too large, and I only know parts of it well, though it can include C's problems as well (but it doesn't need to).

Re:Readability?

[JustAnotherOldGuy]

The language that's easy to read is the one you know well.

That may be, but I admit I find syntactic sugar like braces and semicolons help me significantly in visualizing the code blocks, functions, etc.

ok, fine. Enter the Nim-ja..

[Anonymous Coward]

my stance is horse...style! totally wild!
this aint no gam...boy, if you play me i will boost you! ...my politicalthrow stars...
ima genie in a bottle you gotta rub me the right way.
coletrain!coletrain!

yadda yadda, i used only the words i could remember of what i thought were the best errr most Prominent words of a garbled song (shitty distro) in shitty FM radio dialturn (shitty computer 486 sx80Mhz)) from 90's euphoria (no job living in parents basement).

But I call it Nim back then, what was called Hip yesterday is now Zef..fo'shizzle muh-nizzle.

FINALLY!

[Gravis Zero]

HAI 1.2
CAN HAS STDIO?
VISIBLE "I've been looking for something to outdo LOLCODE in terms of pointlessness. ;)"
KTHXBYE

Re:FINALLY!

[Anonymous Coward]

I never understood why the creators of LOLCODE picked the banal 'VISIBLE' keyword when they could have used 'IMSAYIN' or 'ISEZ'

Nim is an abstraction layer

[Anonymous Coward]

it abstracts itself.

One obvious improvement

[Bryan Ischo]

Just reading the docs, the first thing that pops out at me is that there is no need for a separate 'const' and 'let' keyword. They describe the difference as:

"The difference between let and const is: let introduces a variable that can not be re-assigned, const means "enforce compile time evaluation and put it into a data section":"

But the compiler can detect whether the expression on the right hand side of the let assignment is compile time constant, and "put it in the data section" if it is; no need for the programmer to have to make that decision.

Re:One obvious improvement

[Bryan Ischo]

Another critique: the 'discard' keyword is unnecessary. "Forgetting to use a return value" is not a bug vector in my experience. No reason to force the programmer to tell the compiler "yeah I really didn't mean to use the return value of the function I called".

Re:One obvious improvement

[Bryan Ischo]

Here's a big one: overloaded operators are terribad.

"The Nim library makes heavy use of overloading - one reason for this is that each operator like + is a just an overloaded proc. The parser lets you use operators in infix notation (a + b) or prefix notation (+ a). An infix operator always receives two arguments, a prefix operator always one. Postfix operators are not possible, because this would be ambiguous: does a @ @ b mean (a) @ (@b) or (a@) @ (b)? It always means (a) @ (@b), because there are no postfix operators in Nim."

One of the worst "features" of C++ is operator overloading. I don't care how concisely I can write a Matrix class with operators that "look like" real math operators applied to the types; if I can't read a program and know what operators might do because they could be overloaded, then the programming language is inherently very difficult to read, at least with confidence. In my opinion it's much better to have to provide functions to perform actions on types, with those functions naturally having names that describe what the action is. When "a + b" *could mean* "a and b are numbers which are being added together" or *could mean* "a and b are complex types and some completely arbitrary operation is being applied", the language has lost readability.

Just say NO to operator overloading!

Re:One obvious improvement

[Bryan Ischo]

Here's another unnecessary weakness:

"Parameters are constant in the procedure body. By default, their value cannot be changed because this allows the compiler to implement parameter passing in the most efficient way. If a mutable variable is needed inside the procedure, it has to be declared with var in the procedure body. Shadowing the parameter name is possible, and actually an idiom:"

Re-using parameters as variables is very useful for writing concise code. I see no reason to limit things in this way. If the compiler thinks it can do something clever to optimize parameters when they are not modified, then it can detect when parameters are not modified and just do it, without limiting the programmer.

And forcing programmers to shadow variable names to get around this limitation is just awful. Shadowing of variable names is dubious to begin with as it can lead to confusion when reading the code (you can easily lose track of the fact that there are two 'x' variables in scope, one shadowing the other), and a language "feature" that actually encourages this bad practice is awful.

Yeah I think I'm done reading about nim. My conclusion: it's designed by programmers without a whole lot of programming experience, who do not realize the more subtle design points that should be adhered to in language design. I don't need another language designed by novices.

Re:One obvious improvement

[Anonymous Coward]

Does your sentiment apply to other methods/functions as well?
I.e. having the capability to define both:
        string toString(double d);
        string toString(int i);

I really don't want to miss that. And operators are just a different syntax for function calls.

Re:One obvious improvement

[Anonymous Coward]

"Shadowing of variable names is dubious to begin with as it can lead to confusion when reading the code"

I'd say the same about re-assigning parameters.

Re:One obvious improvement

[Anonymous Coward]

Maybe you do want to miss that.
Method overloading can lead to problems when combined with inheritance (of the receiver or the argument) and type promotion/casting.

Been a long time since I read it, but I think Bertrand Meyer has a pretty good writeup.

Re:One obvious improvement

[Bryan Ischo]

I do like that kind of polymorphism because it allows the "same" operation to be applied to different types; however, readability becomes a bit more difficult because I have to know, in my head, all of the types of all arguments to a function call in order to know which form of the function is being called, if I am reading the code and trying to follow the flow to understand what the code is doing.

So it's a trade-off. To be honest, the number of times that I've really, really wanted that kind of polymorphism versus the number of times that it's just confused me, lead me to conclude that I'd prefer to live without it. doubleToString(), intToString() really isn't *that* much more to type ...

Re:One obvious improvement

[Bryan Ischo]

How so? There's only one name associated within the parameter internal to the function. So there's no ambiguity about which value is being assigned to.

I've *never* been confused about what it means to assign a value to an input parameter. Something like this is a common pattern and pretty useful:

function doSomething(a : String)
{
      if (a == "") {
          a = "some default";
    } // Now operate knowing that a is not empty
}

That kind of code has never confused me.

But thinking that an assignment is to the 'x' of some outer scope, when in fact I didn't realize that 'x' was re-declared within this scope and the assignment has no effect outside of this scope ... that's bitten me I don't know how many times. Especially for commonly used variable names like i, n, x ...

Re:One obvious improvement

[Bryan Ischo]

Someone modded my comment as "Troll". I cannot even fathom what would lead someone to do that. My comment was a critique on the language. WTF is trolling about discussing the characteristics of a programming language in a discussion forum about that programming language?

Re:One obvious improvement

[Dutch Gun]

Sorry, I can't disagree with you more about this.

As a videogame programmer, a significant amount of what I do is working with user-defined types like geometric vectors, matrices, quaternions, etc, all of which have well-defined operations that use mathematical notation, and it makes a big difference when I can write code in a natural and intuitive style. Just because someone could theoretically abuse a feature doesn't mean it's still not a useful feature. You could completely misname a function that adds two values to "multiply_two_values()", but why on earth would you do that? Are functions with arbitrary names a terrible idea then? It makes no more sense to blame operator overloading for similar imagined "shortcomings".

Even the whole "hidden" factor is less an issue than you'd imagine it to be. In most typical use cases I've seen, operators are overloaded on custom classes designed to work like native types. You're typically aware of when you're using these types, and so you're also aware that you're using overloaded operators. Let's also not forget that operator overloading makes things like C++ smart pointers look and work like native raw pointers, or allows us to use an index operator on a collection, or create a custom variant type which you can use just like native types without having to look up arbitrary method names.

More to the point, in two decades of professional C++ programming, do you know how many times this has actually been a problem for me in the real world? Zero. I've never seen an example of someone abusing operators in a ridiculous way like this in code I've actually used or worked on, but I've seen plenty of examples of when it made for much more intuitive and readable code. I see this brought up as an argument all the time, but I think the concern about this is vastly overblown based on my own personal experience.

Re:One obvious improvement

[Bryan Ischo]

Well I guess we've had different experiences then.

matrix.multiply(other) doesn't seem that much worse to me than matrix * other, and in my opinion is more self-documenting since I know that a function is being invoked. And have you tried to actually write coherent operator overloading for any class? My god it's ridiculous in C++; the syntax for doing so is awful and the number of niggly details you have to get right or leave yourself open to weird bugs that will only show up much later when someone else tries to do something that you didn't even think of ...

Also "smart pointers" is not a particularly good reason in C++ since it's just a memory management technique to get around C++'s lack of good memory management support.

Yeah. I'll take the "matrix.multiply" form. It's a little extra typing but in my opinion operator overloading is a fragile crutch that is ready to break at any moment and leave you flailing about on the floor.

Another point would be that the vast, vast majority of code being written is not video game inner loops. So languages that are optimized for video game inner loops are not really the most practically useful languages to the largest number of people.

Finally - if you want all of the "raw power" of C++ -- well we already have C++. Other languages do not need to duplicate those "features" that are really only useful in such a narrow domain. I mean you're not going to be writing your video game inner loops in Nim anyway, so why does Nim need a feature only useful in video game inner loops?

Re:One obvious improvement

[johannesg]

That old story again. You know what the + operator does? It adds two things together. How it does that is really none of your business.

You probably think that you know what happens when you write x + y. Well, you don't. It all depends on the type: if x and y are integer, an integer addition instruction is used. If they are floating point a floating point addition instruction is used. And if one is integer and the other floating point there is first a conversion, and then a floating point addition. If one is a pointer and the other an integer, there is a multiplication, an integer addition, and perhaps pointer normalisation (only on obscure architectures). So that simple '+' already means a lot of different things. Given you already have to deal with all that, I really don't see the problem for allowing addition for user-defined types as well, like BCD, or bignum, or complex, or matrix, or whatever.

Re:One obvious improvement

[Dutch Gun]

Well, don't sweat it too much. Every once in a while I get modded down by some special snowflake who somehow construes a reasonable difference in opinion as a personal insult. I see you also got a more typical "Overrated" on another post, which I translate as "I disagree with you and want to shut you up".

So anyhow, no, you shouldn't have been marked as a troll, even if you're completely and utterly wrong. ;-)

Re:One obvious improvement

[HiThere]

I've got to disagree...though not totally. ISTM that overloaded operators need to be marked, rather than eliminated. I once suggested that overloaded operators be enclosed in pipe chars, e.g. |+|, but nearly any mark would do. And this be only used for operators. I also wanted to allow alternative symbols, names, etc. to be used for operators, but there I ran into the precedence problem

Re:One obvious improvement

[Anonymous Coward]

let dosomething a =
    let a = 5 if a = 2 else a in
    # now operate knowing that a is not empty;;

Note that this doesn't modify the value of the original function parameter a.

I don't see the problem...

Re:One obvious improvement

[Bryan Ischo]

The ways that + can behave in C can be enumerated without knowing anything else about the program. But overloaded operators in C++ cannot be enumerated without knowing the types involved and doing an inspection on those types to see if the operator is overloaded.

It's a trade-off. Sure operator overloading allows some concise representations. But it's information hiding. That's not a trade-off that I think is wise to make. Other people obviously differ in their opinion.

Re:One obvious improvement

[Bryan Ischo]

That's only because of some weird syntactical rules of the functional language you are using in your example.

So in:

'let a = 5 if a = 2 else a'

the variable 'a' from that point on in the scope will I guess refer to this *new* 'a' introduced by the let expression, instead of the 'a' that was passed in? That's freaking confusing.

And the 'a' in the right hand side of the let expression is the function parameter 'a', not the 'a' being introduced in the left hand side of the let expression?

Sorry that's just obtuse.

Re:One obvious improvement

[Bryan Ischo]

"so why does Nim need a feature only useful in video game inner loops"

yeah that is a bit of a straw man, I admit. We never established that operator overloading is a feature only useful in video game inner loops.

But I will say that I think it's generally only useful in a narrow and small subset of programming problems: those for which mathematical constructs already exist and for which math operators are meaningful. Most people don't write code using quaternions and matrices. General control logic and data flow algorithms are far far more common.

The worst kind of overloading in C++ is overloading for things like brackets and parenthesis and dereference. You're taking an operator which implicitly only has meaning within the language, since these are not mathematical operators, and allowing the meaning to be changed. I can buy that in narrow circumstances there is value in overloading the math operators, but the rest of them, forget it. Way more rope than necessary to hang yourself and anyone else who is unfortunate enough to read your code.

Re:One obvious improvement

[serviscope_minor]

I strongly disagree.

The first mistake is not knowing C++ well. a+b means operator+(a,b). It's a function call with a funny syntax. No more, no less. Now we're on to function calls, nothing in your language stops someone from writing a function called add() which does something silly. Or sensible.

Why is it worse having a+b than add(a, b) when a and b are complex as per your example?

Re:One obvious improvement

[Anonymous Coward]

Re-using parameters as variables is very useful for writing concise code. I see no reason to limit things in this way.

The origin of the modifying-parameters-is-bad meme may be in javascript, where the parameters are available both via their names and as the 'arguments' array-like object, and taking advantage of that aliasing will ruin whatever poor-piss optimization the JIT engine is trying to do.

See here

And, btw, I don't think that 'writing concise code' is a priority in a python-like language (that enforces mandatory white-spaces and indentation)

Re:One obvious improvement

[Bryan Ischo]

a + b for complex types isn't really the trouble, since we know that the compiler can only accept that syntax if the + operator has been overloaded.

What's worse is overloading [] or -> and competely fooling the programmer who has no way of knowing, without exhaustively scanning all source files, whether or not those operators are doing something unusual.

Information hiding. It's bad.

Re:One obvious improvement

[brantondaveperson]

If you actually write code that does lots of math on vectors and matrices and so-forth, you might change your opinion. Added to which, the oft-trotted-out argument that '+' might be doing something other than adding due to overloading is moot, since the same can be said of a function called 'Add'.

Re:One obvious improvement

[serviscope_minor]

Nope that's no different.

a[b] means index(a, b). Information is no more hidden than if you have to look for index() versus looking for operator[]. Operators are not magic, they're just functions with an alternative syntax. If you have a problem where programmers are fooled because someone keeps committing an index() function to the repo which does something else entirely, the problem isn't overloading, it's that you're not doing code reviews properly.

Re:One obvious improvement

[Bryan Ischo]

The index() form makes it very clear that a function is being called.

Overloaded [] does not.

Pretty simple really.

The worse of all is overloaded ->, which is an operator which can normally be applied to a dereferenceable type, so you would really have no idea to even look for an overloaded operator to see if something unexpected is happening, versus [] which if you know the type is not a C style array, must be an overloaded operator.

In my experience, if there are bad paradigms available in the language, people will use them, even celebrating their ability to do something "clever" and obtuse, and eventually they will make their way into the code base. Very often it may not even be in your code base, that you have control of, but in some open source software that you have to read and understand.

Absolutely, the intelligent and rational use of language features is the responsibility of the programmer; but it's pragmatic to recognize that in a world of imperfect programmers, it's better to not have language features that generally lead to hard to understand code.

Re:One obvious improvement

[Bryan Ischo]

Yeah but at least with Add I know that a function is being called, whereas overloaded operators are exactly and specifically designed to make operations that have "normal" functionality pre-defined as part of the language, actually do something else, without any indication at the point of usage that this is occurring.

Sure if you are intimately familiar with the types involved you will not be caught off-guard very often. But "it doesn't usually bite you if you know what you're doing" is not a great argument for a language feature if you ask me.

I have written code with matrix math and I actually found it clearer to spell out what's going on more explicitly than to use overloaded operators. But that's a personal choice for sure.

Re:One obvious improvement

[serviscope_minor]

Overloaded [] does not.

Yeah it does. a[b] means operator[](a,b). It's a function in C++. Some forms are predefined, much like some forms of sqrt, min, and less are predefined, but it's a function nonetheless. C++ is NOT C and if you keep treating it as such, then you'll get confused by such things.

The worse of all is overloaded ->, which is an operator which can normally be applied to a dereferenceable type, so you would really have no idea to even look for an overloaded operator to see if something unexpected is happening,

Except that if you know C++, you know that -> can be overloaded, so you would never expect that user defined types could never be dereferenced. It's not only possibly, it's a really really common idiom. Your reasoning only really works if you assume C++ is really C, and apply all the rules you know from there to C++. It is not. Again, all a->b means is operator->(a, b), which is yet again a function call with a funny syntax.

In my experience, if there are bad paradigms available in the language, people will use them, even celebrating their ability to do something "clever" and obtuse, and

So? It's my experience that people will do stupid things with power tools, up to and including losing digits and limbs. I wouldn't however advocate that we should never use power tools because an awful lot would be vastly slower and more difficult without them. It's the same with powerful language features. You can do stupid stuff with powerful language features. If people are doing stupid stuff with those in your code base, then the problem is not the language, it's your processes. You can, after all, write awful code in any language.

Very often it may not even be in your code base, that you have control of, but in some open source software that you have to read and understand.

When C was popular, there was an awful lot of bad code in C. When C++ became popular, there was an awful lot of bad code in C++. When Java became popular, there was an awful lot of bad code in Java. Nowadays, there's a lot of bad code in all of those plus PHP, Python, Go and a whole host of others.

And on the flip side, there are shining examples of excellence in all of those.

Of course it would be facetious to claim that no language is either better or worse. However, I do dispute that having powerful features inherently makes the language worse. Features that allow you to write the same code more concisely and so with fewer bugs make languages better.

but it's pragmatic to recognize that in a world of imperfect programmers, it's better to not have language features that generally lead to hard to understand code.

Except I dispute that they make it harder to read. Having special syntax makes things easy to read, essentially (I think that's why LISP never took off). [] generally means "array access". And in C++ it works for builtin arrays, std::vectors and for various numeric array types, like Eigen. The thing is in all cases it means logically and semantically the same thing, so having it look the same is a huge advantage.

Poorly used, it makes things confusing, just like any other poorly named function. And that's why library writing is generally done by the experienced members of the community or team.

Re:One obvious improvement

[Anonymous Coward]

Dumbass assburgers is sperging.

Re:One obvious improvement

[Anonymous Coward]

you are truly a dumb fucklenut

Re:One obvious improvement

[Anonymous Coward]

What kind of ancient code editor are you using where you "have to know, in [your] head, all the types of all arguments to a function call in order to know which form of the function is being called"?

Modern code editors allow you to hover over function names to display some helpful information about them, such as what types of arguments it takes for the different forms available to choose from... or, worst case, there is usually a "Go To Declaration" button that will take you to the actual function itself so you can peruse at your leisure.

I swear... people will find anything to bitch about.

Re:One obvious improvement

[Anonymous Coward]

moron

how does this compare to D?

[ooloorie]

Nim sounds similar in its goals to D, another batch-compiled statically typed language with GC. The main difference is that Nim seems to innovate a lot syntactically. How do the languages compare otherwise?

Re:how does this compare to D?

[Anonymous Coward]

D has been developed by Walter Bright and Andrei Alexandrescu, two notable professional programmers with decades of experience each. Both are also very well known for being among the best C++ experts. Bright developed some of the earliest C and C++ compilers, for example.

From what I can tell based on GitHub profile pages, Nim has been developed by some teenagers and college students.

This probably explains why D is a sensible, consistent, practical and professional programming language meant for getting real work done, while Nim appears to be a hobbyist project developed by amateurs.

Re:how does this compare to D?

[K. S. Kyosuke]

Trollolololol! ;) Of course a bunch of C++ programmers would develop a new language that wouldn't shed its similarity to C++. That's how COBOL-brainwashed people came to come up with SQL.

Re:how does this compare to D?

[ooloorie]

Of course a bunch of C++ programmers would develop a new language that wouldn't shed its similarity to C++.

So, that still leaves open the questions...

What benefits does Nim derive from being syntactically different from C++?

And how does it functionally improve on D?

Unless there is a strong reason to deviate from it, I would like a new language to be as similar to C++ as possible.

Re:how does this compare to D?

[K. S. Kyosuke]

I don't know Nim at all, but there doesn't seem to be any sense in demanding that a new language resemble C++ as much as possible, consider how broken the whole C++ thing is (poor language interoperability unless everything is handled by the C++ compiler itself at compile time or unless half of C++ specification is re-implemented from scratch, baroque language semantics, the header+source model completely opposed to the principle of separate compilation, etc. etc.)

Re:how does this compare to D?

[ooloorie]

consider how broken the whole C++ thing is

So? We're not talking about "the whole C++ thing", we are simply talking about not gratuitously inventing new syntax so that the language feels familiar and is easier to learn. D and C# both retain much of the feel and syntax of C++ while having none of the problems you mention.

Nim breaks radically with existing syntax, and I don't see a good reason for it so far.

Re:how does this compare to D?

[Anonymous Coward]

If syntax is what trips you up then you have no business pretending to be a programmer.

Re:how does this compare to D?

[K. S. Kyosuke]

Didn't C++ gratuitously invent new syntax, too? Regardless, syntax is not all there is to a language. There even used to be a very snarky empiric observation/law regarding the relative frequency of topics in programming language discussions, with less meaningful things like syntax being discussed more frequently, although I don't recall the exact formulation of the observation.

Re:how does this compare to D?

[ooloorie]

Didn't C++ gratuitously invent new syntax, too?

C++ went out of its way to remain backwards compatible with C because that makes moving from C to C++ easier.

Nim, on the other hand, seems to go out of its way to be different from C/C++ syntax. I merely asked why, and it's becoming apparent that there is no reason; Nim developers simply felt like it.

Re:how does this compare to D?

[Anonymous Coward]

Why does it have to be similar to C++?

It is not like C++ is the mother of all languages.

If you mean similar as in "I only know C++ and anything else is scary", you have bigger issues to deal with.

C++ is not the end all be all ya know.

There are languages with much better typing(Ocaml), faster(C, Ocaml, Fortran and a few others) and much more sane and concise syntax(nearly every language save Java, PHP and ADA).

Re:how does this compare to D?

[Anonymous Coward]

Yet, C++ is not backward compatible.

BC means C++ is a superset of C, it is not. It is an intersection of C.

Parallel support?

[kwerle]

Looks like another language that does not thoroughly address parallel processing. With the mention of go, I was hoping for something like goroutines (one of the few things I like about the language) - but no. Doesn't look like it.

Re:Parallel support?

[LoneTech]

You'll want to take a look at Cray's Chapel programming language.

Good for Nim

[Anonymous Coward]

They should follow Rust's example and start being more inclusive to minorities. I suggest renaming the Nim package manager (nimble) to NAMBLA.

Secret of Nim

[Anonymous Coward]

Reminds me of the animated movie, Secret of Nimh.

Re: Trump at the national cathedral

[Anonymous Coward]

God is a programmer now. Here on the H1B visa program. Hope he is packing his bags...

noooooooo

[Anonymous Coward]

having python around wasn't enough .. there is more than one stupid indentation-is-syntax programming language around.
Fortunately it will disappear soon

Ac ouple of typos

[drainbramage]

In your reply you used "otherwise you'd knew" and "the sixt more spoken language".
I think you meant "otherwise you'd Gnu" and "the Sith more spoken language".

Re:Ac ouple of typos

[alvieboy]

Mods, please +1 parent :)

And there is indeed a typo: I should have written "The sixth most spoken language".

Strong typing - again

[Anonymous Coward]

Don't confuse strong typing with manifest, static typing.

Python is strongly typed and has first class functions.

The chief counterexample to the statement "Python is strongly typed" is that almost anything can be used in a boolean context.

Re:Strong typing - again

[K. S. Kyosuke]

The chief counterexample to the statement "Python is strongly typed" is that almost anything can be used in a boolean context.

Is it? I guess that's just a matter of interpretation, but to me, all it means is that Python has its own specific definition of truth and falsity. Many languages seem to have that.

Re: Trump at the national cathedral

[epyT-R]

What if God Trumped all of us... Combed one over all of us...

programming nim: fun; debugging nim?

[Monkius]

I found programming in nim fun; when I looked into runtime debugging nim, I wasn't very convinced I could actually use it for anything anytime soon.

Nobody really understands parallel processing

[Anonymous Coward]

Consider the comprehensive, supposedly mathematical approach that C++11 took in order to integrate a memory model that could provide strong support for parallel computing; guess what? It still provides a now provably incomplete definition, and it's so subtle that nobody really knows what the hell it's saying anyway!

Re:Nobody really understands parallel processing

[Anonymous Coward]

The same can be said about every feature of C++, they all just get it almost right, but not entirely right. It comes from a mixture between an unhealthy fixation on 0-cost implementations and a certain amount of incompetence/language inbreeding.

"... as it uses indented code blocks"

[Anonymous Coward]

that's enough of a fail to ignore it completely even if the rest of it isn't brainded.

Ruby

[jbolden]

Ruby is along with Python and Perl one of the big 3 scripting languages. It seems pretty stable at over 1% of programs according to TIOBE and is currently surging again to 2.5%: http://www.tiobe.com/tiobe-ind... . At this point obviously Python is in first place but I'd say Ruby is mostly tied with Perl for 2nd. How is that not success? Certainly it isn't a top 5 language but a consistent top 100 is a successful language.

As for nim I think I've only heard of it a few times so I'd agree that language ain't doing so hot yet.

Use case?

[manu0601]

Yet another language. What Nim is good for?

optional garbage collector?

[fringd]

There's a bit of handwaving in the introduction concerning the garbage collector. There's a compiler option to turn it off allowing you to manually manage memory, but what if libraries you're using aren't all written to manually clean up after themselves? It seems to me that one of two things will happen:

1. Not everybody in the community manually manages their memory, making the --gc=none option impossible to use in practice.
2. Everybody is required to manually manage their memory so that others can gc off, effectively making the memory management mandatory.

So unless there's something more to this it seems like it's really just punting the gc decision to the community and creating confusion and uncertainty.

Can anybody with more knowledge maybe clear this up?

I have to ask.

[Anonymous Coward]

Does this mean that enthusiasts for the language are "Nim nuts"?

Indented code blocks

[Anonymous Coward]

That's the worst part of python!