Nim Programming Language Gaining Traction 520
An anonymous reader writes: Nim is a young, statically typed programming language that has been getting more attention recently. See these articles for an introduction: What is special about Nim?, What makes Nim practical? and How I Start: Nim. The language offers a syntax inspired by Python and Pascal, great performance and C interfacing, and powerful metaprogramming capabilities. The author of "Unix in Rust" just abandoned Rust in favor of Nim and some early-adopter companies are starting to use it as well.
The Secret of Nim (Score:5, Funny)
When that comes out - I'm buying it regardless of whether or not I actually need to learn or use the language.
Re:The Secret of Nim (Score:5, Insightful)
If I were to create a new language, I would not focus on creating the most beautiful syntax or the best built-in functionality. Instead, I would make damn sure it plays well with other languages and that it is trivial to use software packages already written. For example, R, Python, Java -- no one wants to recode the packages (machine learning algorithms, MPI, web automatisation) in yet another language.
Re:The Secret of Nim (Score:5, Interesting)
Nim looks syntactically a little bit like Kotlin [kotlinlang.org], which compiles to either JVM bytecode or JavaScript. If you compile to the JVM then you can not only use libraries written in Java, but also JavaScript, Python 2.x (via Jython), Ruby, Scala, C (via JNA), there's even a Haskell for the JVM called Frege.
The really neat trick, though, is that despite looking not much like Java at all, it compiles down to code that is binary compatible with Java and there is a Java-to-Kotlin rewriting tool, meaning you can convert existing Java codebases one file at a time whilst still having a fully compilable project. Thus you can not only leverage existing codebases written in many languages, but also slowly convert legacy codebases too.
Kotlin has some syntactic features that look similar to nim, like if being an expression not a statement, ranges, type inference, compile time inlining control, operator overloading, generics etc. Kotlin also has a a variety of features that focus on creating DSLs, but doesn't do it using a full blown macro system.
Nim has some things Kotlin doesn't and vice versa. I can write a more complete comparison (based on reading the docs) if anyone is interested. But the reason I mention it, is Kotlin's focus on interop with existing code.
Re:The Secret of Nim (Score:4, Interesting)
Yes, that has been a persistent problem for speeding up dynamic languages for years. You can make a better runtime but then can't provide the interpreter API used by the C extensions.
The Oracle Research JVM team has a totally crazy solution for this. They have implemented an extended version of HotSpot that is capable of actually JIT compiling interpreted source code of Ruby C extensions [chrisseaton.com] such that the end result is much faster than the Ruby interpreter using GCC compiled versions of those same extensions.
The whole blog post is worth a read, but to summarise, what they've built is capable of actually inlining C into Ruby and vice-versa at the compilation level. So for example if a C extension function returns an array of three elements using the C extension API and then Ruby code unpacks it, it can actually compile down to returning those values in registers because the code is inlined together and then compiled in the normal way. Additionally, interpreting the C source code means that the JVM garbage collectors can still compact the heap and do other things that traditionally you cannot do with C.
Graal/Truffle are unfortunately still research projects. This technology doesn't ship in the regular JVM yet and won't do so for some time. But it's an interesting glimpse at the future of high performance dynamic language runtimes.
Re:The Secret of Nim (Score:5, Informative)
The example you gave is just an example of API designers being stupid: You could call that -1 indexed, because there is a zeroth dimension (mathematically, it has the value of 1 (unitless)).
1-indexing has the problem of needing to subtract 1 from everything before it's useful for scaling, and much else. The 20th century is 1900...1999 inclusive because of 1-indexing. The year -0001 is also known as 2BC because of 1-indexing. And so on.
Anywhere your index is an offset (which is most indexes), it needs to be 0-indexed.
Re: (Score:3)
The 20th century is 1901...2000 inclusive because of 1-indexing.
Re: (Score:3)
SEE WHAT I MEAN?
Re: (Score:3)
Holy Fuck (Score:3, Funny)
Yet Another Programming Language.
Same shit, different syntax.
And now, some HR idiot is looking for someone with 5 years experience in it.
Scripting langs are like social media (Score:4, Interesting)
A new fad sweeps through the kiddies every 3-5 years. I guess everyone wants to be one the crest of the new wave so they all rush out to learn the newest one, hoping maybe they'll get to write the book or teach a bootcamp, after it gets advertised on Slashdot of course.
Re:Scripting langs are like social media (Score:4, Interesting)
I find the ones who rush to use the new stuff are the ones who never quite managed to make anything with the old ones. The grass is always greener but also they can blame their lack of progress on the tools.. obviously *this* time it'll be different, just once they've had the right training and given enough time.....
Its when I was offered a job to make a system cope with the customer's increased load that I realised how damaging this is - it was written in Erlang, Ruby and Scala.
Re: (Score:2)
Re:Scripting langs are like social media (Score:5, Insightful)
If you were one to write books and training, you might welcome fresh technologies.
+1 for cynicism, but I'll raise you 2:
The other reasons why people go for this are two-fold.
Bonus excuse: Since it's all new, nobody can tell at a glance that you're doing it wrong. :-)
Re: (Score:3)
Nim isn't a scripting language. It compiles to native binaries by default (with an intermediate conversion to C code) and doesn't depend on an interpreter or virtual machine at runtime.
Nim's community is very toxic. (Score:5, Informative)
I lurk on the Nim IRC channel sometimes. The toxicity there is unbelievable.
Look at these recent IRC logs [nim-lang.org], for example.
We see insults like:
And there's lots of unnecessary sarcasm:
Then there's lunacy and quasi-psychotic ranting and rambling:
Re: (Score:3)
Who cares? Do you want to use the language or chat with the community? Such people exist in most communities. AFAIK only one person, the creator of Nim (formerly Nimrod), Araq, is in charge of making all the decisions. He has also implemented most of the language and libraries.
Nim = Python code + Turbo Pascal type declarations.
Re:Nim's community is very toxic. (Score:5, Insightful)
Who cares? Do you want to use the language or chat with the community? Such people exist in most communities.
The problem with the toxicity is this:
19:04:02 Araq ldlework: I intend to "fix" it because I'm tired of arguing ... not because it's a particularly good idea
If solutions are being based on emotion and not what is correct, or best, then the language development is well and truly fucked.
Re: (Score:3, Insightful)
AFAIK only one person, the creator of Nim (formerly Nimrod), Araq, is in charge of making all the decisions. He has also implemented most of the language and libraries.
That's an excellent reason not to even consider using it at this point. Unless your idea of a good time is maintaining a dead programming language, you should wait until it already has a community and a fork before you even touch it.
Re: (Score:2)
People still use IRC?.... It's probably not the Nim community so much as the kind of blowhards that are still hanging out on IRC in 2015.
Did you not notice that one of those "blowhards" on the IRC channel was the language creator?
Re: (Score:3)
I lurk on the Nim IRC channel sometimes. The toxicity there is unbelievable.
Given that the language's name was initially Nimrod, I find those IRC logs quite apropos.
Re: Nim's community is very toxic. (Score:2)
Is that because it was named after a great hunter, or because it was named after the leader of the people that built the Tower of Babel - leading to the multitude of languages? Or are you going the Bugs Bunny route?
Re: (Score:2)
Is that because it was named after a great hunter, or because it was named after the leader of the people that built the Tower of Babel - leading to the multitude of languages? Or are you going the Bugs Bunny route?
Because it has been a well known slur for a long time. Bugs' use of it only reflects society.
Nim appears friendly enough, just avoid IRC (Score:5, Insightful)
IRC is just a bad medium for mature discussion to begin with (but forums suck in many other ways, so where does that leave us). The IRC channel for most *any* project is unnecessarily toxic. Just because Araq is on the IRC channel doesn't mean the whole project is polluted by the ramblings of one or two fans/hecklers/wannabe devs.
My view of Nim from the web pages presented in the summary, and the online docs is very different from your IRC-centric view. I've personally been very impressed with the quality of the documentation, tutorials, and papers I've read so far. I don't think I've seen as friendly and readable documentation for any project in a long time. Perhaps quality will drop as Nim becomes more popular and people concentrate on developing. But for a project that has seemingly come out of nowhere, this really impressed me. Not only is Araq apparently a decent programmer, he's also a good writer too.
Thank you to the submitter for submitting this. I had never heard of Nim before today. Adding it to my short list of very interesting new languages to follow.
Taste the rainbow (Score:2)
After seeing that first link I was left wondering what other colors can be applied to the text windows.
Re: (Score:2)
Second link, dammit
It's kinda strange (Score:4, Informative)
Re: (Score:2)
It's not notable because it doesn't have its own wikipedia page - it doesn't have a wikipedia page because it's not notable.
Every time Jimmy Wales begs for a donation I cite shit like this. Small minded editors with way too much time on their hands who delete stuff for the sake of their own egos.
The people's encyclopedia it ain't.
Re: (Score:2)
There's no Wikipedia page on this language. Just an external link in the disamb page.
Well come on then you slacker, you could have created a new Wikipedia page in the same time that you wrote your comment here.
On the other hand, it probably would have been reverted 5 minutes later for some obscure reason.
first the rats escape (Score:2)
Caveat Emptor (Score:5, Informative)
I was looking at the last link in TFS and in the comments to that link there was this little gem that should force you to take a large grain of salt before committing to a major Nim effort
Nim High Priority Issues [github.com]
Now, I am not familiar with how other, similar languages were at the same stage of development, but given things like this I would be putting Nim in the "Not ready for prime time YET" basket (which is also how I feel about Swift at the moment - there seems to be too many things in a state of flux right now)
So? (Score:5, Interesting)
Rust, on the other hand, is something genuinely new: it provides completely memory safety without a requiring a garbage collector at all. It's sad to seeing people switch from Rust to Nim: they're often too inexperienced to know what they're giving up, and I feel like they're seeking (syntactic) novelty, not a programming environment that's actually useful.
Re: (Score:2)
Rust sounds interesting. Got an overview-link?
Re: (Score:2)
http://www.rust-lang.org/ [rust-lang.org]
Re:So? (Score:4, Informative)
The only way to provide memory safety in a language without a garbage collector is to severely limit semantics. So, either the Rust designers are ignorant or the language is severely limited. In the case of Rust, Rust makes trivial memory allocation, the kind other languages simply optimize quietly for you, unnecessary complex, while failing to work in complex scenarios.
Rust is a badly designed language.
Re:So? (Score:5, Informative)
I think he spelled out why he thinks Rust is badly designed. I haven't reached a conclusion on Rust yet ,but I certainly wouldn't be so bold as to say it's well designed, at least not yet. At best you can say it's an open experiment.
First off, I'm not sure why you think RAII can't be done in a garbage collected language. For historical reasons C++ overloads the allocation of memory with the management of scoped resources hence the "resource acquisition is initialisation" name, but there's no reason that these tasks have to be joined together. Virtually all languages I know of have ways to do scoped resource management. Java has try-with-resources, C# has the using keyword, etc. The semantics are identical to RAII.
Secondly, I'm not sure what you mean with the statement about unsafe. Yes Rust requires you to mark unsafe regions of code with the unsafe keyword .... exactly like C#. Java has the sun.misc.Unsafe class that lets you do manual memory management and arbitrary unchecked memory reads/writes, albeit without any native language syntax. This doesn't seem like anything fundamental to Rust.
Now let's revisit silfen's criticism:
Rust has a very complex set of rules that you must satisfy to make a program compile. "Fighting the borrow checker" is actually a thing in Rust. In some cases, the obvious way of writing a function that would work in any other language violates the language rules and requires workarounds. So let's not argue about this point specifically - Rust is a complex language and the lifetime management intrudes into even the most basic of programs.
What about failing to work in complex scenarios? This one is arguable. Rust can express the semantics of any program, I do not believe there is any case where you cannot write a program in Rust that could be written in another language. So "failing to work" is perhaps a bit extreme. However it is undeniably true that for quite common design patterns the Rust lifetime/borrow checking infrastructure cannot apply and Rust programmers must either spend time thinking carefully about ownership design or fall back on the equivalent of reference counting smart pointers. My experience of reading online discussions is that Rust programmers tend to see this as a virtue and everyone else isn't quite so sure.
The argument for Rust would be far stronger if it had been designed, say, 15 years ago, when garbage collectors were still very primitive. The problem Rust faces is that the key selling point of its design, the one that is used to justify all this unusual complexity, is "you can avoid garbage collection". But if you're working on a platform with modern garbage collector designs like the JVM or (to a slightly lesser extent) the .NET CLR, many of the old disadvantages of GC have been optimised away with time. On a properly tuned GC pause times are now very short even with large heaps, and some GC's like Azul or the new Red Hat developed Shenandoah GC don't actually have any pause times at all .... even with 200-300 gigabyte heaps. Google's ART runtime has shown that you can implement a concurrent compacting garbage collector on phones and get responsiveness that's basically as good as the iPhone. At least I don't perceive any obvious responsiveness difference o
Re: (Score:3)
But in these C++ systems, ownership design is one of the most vexing issues and must be very carefully considered at all points, without any compiler support. The whole concept of threads and data ownership has exactly zero level built in conceptual support, and that sucks.
I suggest you look into C++11.
I wonder if this is a kind of copyright protection (Score:2)
I mean, if everyone writes their program in their own little language then its pretty god damn frustrating for a rival to steal it from them unless they either want to learn that language or rewrite the whole thing.
Ultimately, this might be the best copyright protection. Hard to steal what you can't understand.
Re: (Score:2)
Psssssssst! (Score:2, Funny)
The compiler for it is written in Swift. Pass it on!
Re:Psssssssst! (Score:4, Informative)
What, why is this garbage modded up? The Nim compiler is written in Nim.
https://github.com/Araq/Nim [github.com]
Another language that has a fatal flaw (Score:5, Insightful)
Scoping by invisible characters is bad enough but modifying operator precedence by invisible characters? Why do people think that using spaces, the invisible character, as syntactically meaningful characters is a good idea? For readers of English the space is only important to separate meaningful bits and now we have a language that you will need to count spaces to determine operator precedence?!?! Of course it always cooler to use binary progressions so the operator precedence feature uses sequences of 1, 2 4, and 8 spaces. I can only hope that the language is a joke as per it's original name, nimrod.
Maybe it would be useful if they dumped the space dependency, but after reading that I quit taking it seriously.
Re: (Score:2)
Because nobody's ever managed to do anything useful in Python...
Re:Another language that has a fatal flaw (Score:5, Informative)
Re: (Score:3)
The manual does not even hint at why the experimental strong spaces may be a good idea. As far as I can tell they are a way to confuse people.
People do not learn arithmetic that way for a very good reason. You can't write it down reliably. I would claim that anything you cannot write down or write as plain HTML (as we are in the interweb era) is sort of broken.
Re: (Score:3)
" 1 + 3 * 4 is still parsed as 1 + (3 * 4), but 1+3 * 4 is parsed as (1+3) * 4"
What. The. Fuck?
Not for everybody due to indentation (Score:5, Interesting)
nim, like python, requires strict indentation. That's not comfortable for some people. I, for one, have nystagmus and find it practically impossible to code in python. I suspect I'd have the same issues with nim.
Re: (Score:2, Informative)
Lately, authors of new languages do it more for mental masturbation than to produce anything useful. And one of the things that get them off, is seeing how many tokens they can remove while still being able to parse it.
Thats why so many new languages have python-like syntax.
Convincing support by early adopters (Score:5, Funny)
Somebody, who wrote a book an a language I've never heard of, has now switched to another new language. Whether he has an agile and flexible mind or simply is not particularly loyal to anything, I'm not impressed...
More attention? (Score:2)
...has been getting more attention recently...
Well, if it is a new language, by definition any attention it gets, no matter how little, is "more attention".
.
When the comparison is against zero, it does not take too much to have a 100% improvement. :)
a language with a gimmick (Score:2)
That's a useless gimmick: it can't work in general and either fails or limits the kind of correct code you can write, you don't always want these kinds of checks, and it must take a significant amount of effort on their part to maintain it. The fact that they highlight this at the top of the page suggests to me that they aren't focusing on the right things and that the language may be in tr
What's special about Nim? (Score:2)
Looks like (Score:3)
Looks like a readable python variant.
Re: (Score:2, Interesting)
That so many people dislike the Python indention model is not cause by it being bad, but by most "programmers" being rather clueless and inflexible. It does not take longer to get used to than the idiosyncrasies of other languages, and it does result in nicely indented code.
Re: (Score:2)
"It does not take longer to get used to than the idiosyncrasies of other languages, ..."
That is true.
"and it does result in nicely indented code."
Sure, 0.01% of the time. Bad programmers produce bad code in Python too and most would properly indent their code regardless.
The fact remains that it's a BS design restriction even though it isn't nearly as hard to cope with as some claim. This choice shouldn't be made again.
Re: (Score:2)
You are confused. Hint: "fact" != "subjective opinion".
Re:Such potential (Score:5, Insightful)
I just recently learned python (learned it from a top python core developer, though, if that counts any).
I like the language. almost all of it. BUT, the lack of curly braces was a huge mistake. indentation is fine. we all agree its needed.
here's where 'whitespace only' indenting messes up. ever see what blogs do when you try to post code? yeah. that. and its a reality, too. you will never be able to guarantee that posted code won't be 'changed' by some web formatter or email formatter!
twice in the last 2 months I've had to extract posted source (from clueless posters) and FIX their code since it did not run OOTB. I had to GUESS where things were supposed to be nested. its not obvious; if it was, you would be able to strip all spaces out and still be able to get the same meaning.
guido just did not think about this issue. its ok, he thought about most things, but I wish he'd man-up and admit that in THIS case, curlies are truly needed. keep the rest of the forced indenting, but ADD an open and close curly so that the meaning is crystal clear, even if mis-posted or mis-indented. plus, you would be able to re-format the source to your local google 2-space standard or the rest-of-world 4-space standard.
oh, and it would not really hurt if you did have static data types. there's huge value in:
int foo (int a, char b, float c);
if you just tell me you are sending a,b,c into a routine, there's a lot that I should know that you're not telling me. it was a shame to lose this. not sure the 'power' you gain is worth the loss of immediate documentation (in the code) by declaring the types of each var and having that var always (for its scope) be that data type.
Re: (Score:3)
I like the language. almost all of it. BUT, the lack of curly braces was a huge mistake. indentation is fine. we all agree its needed.
In addition, according to the Language Manual, Nim supports the directive "#! strongSpaces" to allow white space to affect operator precedence. An example from the manual:
#! strongSpaces
if foo+4 * 4 == 8 and b&c | 9 ++
bar:
echo ""
# is parsed as
if ((foo+4)*4 == 8) and (((b&c) | 9) ++ bar): echo ""
So with/without the directive:
So many invalid arguments (Score:3)
Your argument that your poor code is likely to operate in a poor manner is not a valid objection to Python's indentation. It merely condemns your abilities as a coder (and perhaps your ability to choose an appropriate editor as well, but I repeat myself.)
Write good code, no problem. Your argument simply boils down to you claimin
Re:Such potential (Score:5, Insightful)
Or because some people can't cope with another variation on C++.
They're just tools guys, all these languages coming out, its just like making slightly different style hammers, only hammers don't need any training or lengthy experience to develop decent skills to use.
Re: (Score:2, Funny)
Or because they don't want to cope with C++ even though they can. Because C++ is like the BDSM of programming languages.
Re: Such potential (Score:3, Funny)
And suddenly C++ became much more interesting...
Re: (Score:2)
So you think hammers are trivial ?
http://s1.cdn.autoevolution.co... [autoevolution.com]
Re:Such potential (Score:4, Insightful)
Why did you conveniently list only languages that use braces to delimit code blocks? The common "FIOC" complaints have never been about "muh braces", they're about making code blocks implied by indents rather than explicit. Braces are just one form of explicit block delimiters, but there are others. Ruby, for example, starts blocks implicitly with if, until, while, etc and ends them with "end". Despite not having braces, it's fine, because the blocks are explicit. The start or end of a block does not accidentally occur, where as this can happen all the time in python.
By the way, what is python's way of handling grouped statements like these:
Technically the inner for statement is within the outer for statement, but an annoying additional level of indentation can be avoided because the language doesn't require it. Besides, it looks nicer to the programmer. Even if you contest the need for this as two loops instead of one, just look at C#'s nested using statements, which are often on the same indent for simplicity.
Re:Such potential (Score:5, Insightful)
The second for loop should be indented. I have trouble believing that you really think the non-indented version is more readable, or conveys the algorithmic intent well. If you were applying for a job with my team and you made this argument, I would find it very difficult to hire you.
Alternate interpretation: nicely trolled. I bit.
Re: (Score:2, Interesting)
"End" just reminds me too much of BASIC and Visual BASIC.
Forcing indentation and not having multi-line strings (without the need for escape characters) are the two biggest oversights of these hipster languages. C# finally realized that SQL is a big part of modern coding and you need multi-line strings to make inline queries readable. Not every query needs to be a stored proc and you often need to write inline queries to do what you want for testing before you kick it over to the DBA to make it a stored pr
Re:Such potential (Score:5, Insightful)
Python has multi-line strings. I know that fact won't change your mind, but it might help you look less ignorant.
Re: (Score:2)
DBA's do not appreciate having to remove your stupid escape characters rather than simply copying and pasting the query you wrote.
what's the point of having a dba simply copypasting the queries you write?
Re:Such potential (Score:5, Insightful)
Thank you. The "why don't you like indentation?" argument is nothing but a ridiculous straw man...the issue is not the use of indentation to reflect structure (which, as you point out, Python actually interferes with in some cases...it gets worse with higher dimensional cases such as voxel maps), it's with the lack of properly delimited blocks. With blocks being implied by indentation, you lose an important visual anchor and cross-check of intent with the compiler, and what do you gain? Potential problems with tab characters, code truncation errors that are undetectable until you attempt to execute the code, huge headaches if you have to use code that has had its indentation broken...there are no positives here, unless the proponents are seriously objecting to the onerous burden of typing a few } characters or "end" keywords.
Indentation significance is a design flaw, and it's disappointing to see it repeated yet again...
Re: (Score:2)
If nim has that much going for it otherwise, we could always create a new language, nim++, which is just a front end to nim and translates { and } to proper indentation. (Assuming nim doesn't use { and } as tokens)
Re: Such potential (Score:4, Insightful)
In Python, that could easily have been one or more statements that were unintentionally made conditional or removed from the conditional, perhaps while adjusting the indentation of adjacent just-moved code so the interpreter would put it in the right block. Python's indentation significance doesn't improve things one bit. If you want a fix for this problem, make the end delimiter non-optional, which would make it much more difficult to accidentally put a statement in the wrong block.
And of course, the presence of delimiters does nothing to prevent a language from requiring indentation or producing warnings when it finds inconsistencies between indentation and delimiters.
Re: (Score:3, Insightful)
Oh god oh god, please don't do that. Not indenting the inner loop here is horrifically unreadable.
Re:Such potential (Score:5, Insightful)
Right... and I have seen this same code written in the following versions:
for (int y=0;yheight;++y) for(int x=0;xwidth;++x) code here
for (int y=0;yheight;++y) {
for(int x=0;xwidth;++x) code here
}
for (int y=0;yheight;++y) {
for(int x=0;xwidth;++x) {
code here
}
}
for (int y=0;yheight;++y)
{
for(int x=0;ywidth;++x)
{
code here
}
}
You ask C devs how they would write it, and you will see they spread out across the above. Of course this is an overly simple example.
Python folks will mostly gravitate to reactor451's version. Are there other versions? Yes, especially when you add in iterators and generators, but for even those, developers will gravitate to ONE version of it totally dependent on if they use that feature in their coding.
#Python 3.0+
for y in range(height):
for x in range(width):
code here.
And if this is too far in indentation, then the Pythonic way says that your code is already too complicated and this section of the code should really be delegated away in its own method.
Agree (Score:3, Insightful)
Re: (Score:3)
Implicit blocks are bad, for many reasons which I'm sure you've already heard. The problems don't just affect developers, mind you, but the language as well. They're the sole reason why anonymous functions in Python are so horribly crippled, for example.
The only reason Nim includes this retardation is that it's written by a guy convinced that the ridiculous mistake Guido made was actually a good idea. I get it: you like Python. Here's the thing, you like Python in spite of the ridiculous white space rule
Re: (Score:3, Insightful)
> What, you don't normally indent your C, C++, Java, C#, JavaScript or Perl code?
OK, I'll bite. Not the OP, but I'm against *forced* indentation too.
Programs have two target audiences: the compiler (I'll subsume interpreters here) and the human. Of those, the second one is the more important: a program must be written in a way that a human reader has a chance of convincing herself that it is doing the "right thing".
That's why I enjoy having different channels. The indentation is for a human. Syntactic st
Re:Such potential (Score:5, Informative)
OK, you can consider Python as a heavily standardized version of indentation. Python's entire objective is the human reader. It doesn't leave you and 10 other developers from "tweaking the indentation from time to time to make [their own] point toward the human reader". What people don't understand is that one's interpretation of what they write could be different from others. What one finds easier to understand, others find harder.
There have been countless times that I have read really good Java and C code and could start picking out which individual developers developed where. Do you know how much start up time is wasted in learning Dev1, Dev2's... DevXs' version of the C language? And if you touch C++... each dev has "minor versions" as they learn new ways of doing the same thing. And these code reviews are done in highly standardized environments with docs and comments. Still each developer gets their own unique version of a standardized language. And don't get me started on Perl or Ruby. There are no such things, there are just a ton of individual essays that the Perl and Ruby interpreters understand and execute.
With Python, there is still a lot of uniqueness among developers, but you really need to look for it at the higher levels. Like method & class relationships, program execution flows, or logic design. But at the low level of reading & understanding code from a team of developers, it is dead easy. There are slight variations, but not enough to need to learn that style of coding to help in the future. That is the benefit of Python, its a global coding standard that's built into the language itself. Something that development companies spend far too much money [re]implementing every year for their dev teams.
Now, I am not saying this is best or the way it should be done. Its just one standard where none really exist.
Re: (Score:2)
I've always thought that was the point.
Re: (Score:3)
Exactly. Imagine a brand of beer whose primary selling point was that it came in a bottle so small that you could drink an entire bottle in one gulp. Although that might be a nice novelty, the beers that come in a larger bottle probably are more enjoyable overall.
Re:Such potential (Score:5, Interesting)
As I have recently found out, that also affects the code generation.
It is hard to generate Python code, without actually analyzing what's precisely is being generated. If source is 100% generated - it is doable, relatively easy. But generally generated code also contains pieces of user code, which might/might not require its own indentation and also reindentation to make it proper part of the generated code.
If Python at least allowed optional block statement - curly brackets or begin/end or whatever. But nope. It is appears to be sort of a religious issue for the language creator and some of his followers.
I personally do not like Python for that reason. I prefer to have a visual marker that block is closed. You know, like a dot at the end of the sentence.
Re: (Score:3)
I agree. it needs the curlies (which WORK great in C and takes up at most 3 chars; 1 for the curlie and 1 for a space before and after. 3 extra bytes for intro and maybe 3 for exit. 6 bytes. big deal. you should 'waste' more space with comments and vertical/horizontal whitespace, just for readability, alone.
it should have been optional. require indentation, fine. but also ALLOW those of us who like seeing an 'open and close' semantic who is explicit (not just implied) would have been the right thing
Re: (Score:3)
it should have been optional
this could be easily added without breaking compatibility. you could even write a preprocessor, if it bothers you that much. it is indeed a big constraint with little or no benefit, but most python users seem not to mind, or even like it. many languages have made some of such arbitrary decisions that are purely idiosyncratic, usually pointless but defended with zeal. if the language has other values you simply live with it or hack your way around.
Re:Such potential (Score:5, Insightful)
I agree. it needs the curlies (which WORK great in C and takes up at most 3 chars; 1 for the curlie and 1 for a space before and after. 3 extra bytes for intro and maybe 3 for exit. 6 bytes. big deal. you should 'waste' more space with comments and vertical/horizontal whitespace, just for readability, alone.
Haha, here you all complain that Java is too fluffy [slashdot.org], but if a language reduces the fluff it is also not good?
In the case of Python, instead of intro/outro curled brackets or begin/end statements AND REDUNDANTLY indenting, using only one of the two was chosen. Why do it twice.
Re: (Score:3)
Haha, here you all complain that Java is too fluffy [slashdot.org], but if a language reduces the fluff it is also not good?
Oh this hipster coders.
Syntax is not fluff.
Wrappers for wrapper for adapters for wrappers - commonly found in the huge, so called "enterprise" software, is fluff.
In the case of Python, instead of intro/outro curled brackets or begin/end statements AND REDUNDANTLY indenting, using only one of the two was chosen. Why do it twice.
Language is a tool.
It should give me, the developer, the choice - not take it away from me.
Re:Such potential (Score:5, Insightful)
Python's block structure isn't about saving characters or about saving typing. It's about "There should be one-- and preferably only one --obvious way to do it." [python.org]
In C, for example, there are multiple ways to place braces. In fact, there's even a lengthy Wikipedia page on that very subject [wikipedia.org].
In my own case, I have always used the K&R style, but my employer requires the Whitesmiths style. I have a large base of code at home that I wrote and maintain in the K&R style, and it's hard to switch back and forth between the two on a daily basis [sigh].
Python's indentation is utterly Pythonic because it is compact, yet meaningful. It carries blocks to their logical conclusion. I started in Pascal with begin/end, then learned that braces were better in C, then learned that no braces were best in Python. QED.
Re: (Score:3)
In my own case, I have always used the K&R style, but my employer requires the Whitesmiths style. I have a large base of code at home that I wrote and maintain in the K&R style, and it's hard to switch back and forth between the two on a daily basis [sigh].
Then don't. Use your preferred style at work, and then convert it to your employer's preferred style with "indent" before checking it in.
Re: (Score:3)
I've used "indent" many times in the past, and although it's better than nothing, it isn't really a solution for this problem. You have to go fix numerous other small style issues. For example, my employer has a very detailed - though quite eclectic - style. So, indentation and other issues that "indent" can deal with are only a small part of the problem. Also, K&R is my preferredstyle (I personally think Whitesmiths is dopey, but YMMV.) I'll concede my artistic integrity for pay at work, but not for
Re: (Score:3)
Of course python does allow block delimiters. Just remember to indent your code right.
The delimiters are #{ and #} (should be put on their own line)
Re: Such potential (Score:3)
Except it doesn't complain when you have a mismatch.
Re:Such potential (Score:4, Informative)
Me, I love Python.
Me too. But in spite of the indentation, not because of it. Indentation gets goofed up all the time. For bracketed languages, you just run "auto-indent". For Python, you interrupt your train of thought for ten minutes while you debug the whitespace.
Re: (Score:2)
Re: (Score:3)
You'll be having interviews with companies you most likely won't want to work for.
Hasn't that been true since at least the turn of the century?
Re: (Score:2)
There are lots of ways to compile Python to C. You can just give your code a pyx extension and compile it with Cython, for example. If you want to distribute it to platforms without Python you'll have to use one of the static package makers as well.
Re: (Score:2)
But, you know, learning takes work and actual mental _flexibility_!!! I do not want to face my own insecurities by really learning something in-depth, I could find some of my limitations !
That said, I completely agree. The tool can stand in your way, and sometimes it can even prevent you from reaching your goal. It cannot help somebody incompetent to become competent. In my opinion all these new languages are just a symptom of most programmers being pretty incompetent and on the permanent lookout for some
Re: (Score:2)
I wouldn't claim to be a master, but I've been writing code for a while and like to think that I have a good grasp of the craft. I appreciate that you call it a craft, actually, because that word describes an intersection of pragmatism and art that I think well describes the activity.
In any case, I enjoy learning new programming languages. I've written Conway's Life in more languages than I can count off the top of my head, just because it's a fun way to try to express well-known algorithms in new forms and
Re: (Score:2)
to write anything more than trivial test apps, you have to be GOOD at the language. and debugging it. and its portability issues (usually).
so, while you are spending^Hwasting time learning a new language, the rest of us are busy making real things with tools that we have spent years mastering.
I can tell a fresher from an vet with this attitude. the fresher wants to do 'cool things' even if it does not really help ship better product, faster. they convince themselves that this new tool or language will d
Re: (Score:2)
> so, while you are spending^Hwasting time learning a new language, the rest of us are busy making real things with tools that we have spent years mastering.
Well, unlike some people, I'm capable of doing more than one thing in a day.
I'm also capable of making abstractions and applying things learned in one context to another context.
I'm not claiming these skills are useful to everyone, but they've certainly helped me hone my craft, and made me a more flexible programmer in whatever language my current pr
Re: (Score:3)
IMO, only lazy, inept, or noob programmers don't indent correctly. So if a language requires them to indent properly, they call it forced indentation because they usually don't indent correctly in other languages.
If I'm wrong, how many different ways can you indent the following code?
for x in range(1,10):
for y in range(1,10):
Re: (Score:2)
IMO, only lazy, inept, or noob programmers don't indent correctly. So if a language requires them to indent properly, they call it forced indentation because they usually don't indent correctly in other languages.
If I'm wrong, how many different ways can you indent the following code?
for x in range(1,10):
for y in range(1,10):
if someCondition:
result[x][y] = a[x][y] + b[x][y]
Read parent again.
The issue is this:
database.execute(
"SELECT col"
"FROM table"
"WHERE y"
);
Correct SQL indentation, allowed and easy in a sane language, impossible to do in a stupid language with forced indentation rules that only applies the language itself.
Re:A good language that'll get slammed... (Score:5, Informative)
Please stop, this is getting really tiresome. Python has multi-line strings without special escaping:
http://stackoverflow.com/quest... [stackoverflow.com]
You just look like an ignorant idiot with an axe to grind with this obsession over a non-existent problem.
Speaking of obsessions, Python programmers don't obsess over forced indentation. It's the people who violently dislike Python who keep harping on it.
Re: (Score:3)
Someone has some books and training courses to sell to language hipsters.