Slashdot Mirror
Nim Programming Language Gaining Traction
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.
When that comes out - I'm buying it regardless of whether or not I actually need to learn or use the language.
It's hard to believe that's how Micronians are made. Why don't we see it right now by having you both kiss one another?
Or because some people don't want another variant of C++, like Rust.
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.
I lurk on the Nim IRC channel sometimes. The toxicity there is unbelievable.
Look at these recent IRC logs, for example.
We see insults like:
And there's lots of unnecessary sarcasm:
Then there's lunacy and quasi-psychotic ranting and rambling:
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.
Nim Programming Language, 20+ years.
That's going on the resume!
What, you don't normally indent your C, C++, Java, C#, JavaScript or Perl code? You just left-justify every line? Is that why you're so against indentation?
...because people don't like the idea of a language that turns something they should be doing anyway, code indentation, into a syntactic requirement.
Short-sighted of them
Disinfect the GNU General Public Virus!
After seeing that first link I was left wondering what other colors can be applied to the text windows.
I am Slashdot. Are you Slashdot as well?
I love the fact that this compiles to a binary linked to standard C library and how fast it is, but I'm in ass deep with Numpy and Pandas.
And the code distribution problem is not that big of a deal. If I'm actually sharing code, 9 times out of 10, the other person has Python on their system because they are doing similar work.
Anyway,when/if Nim matures more, I'll probably make the jump.
Or because they don't want to cope with C++ even though they can. Because C++ is like the BDSM of programming languages.
Because it's harder to do one-liners and code templates when the physical layout is significant. At least, that's one argument. Me, I love Python.
Get thee glass eyes, and, like a scurvy politician, seem to see things thou dost not.--King Lear
There's no Wikipedia page on this language. Just an external link in the disamb page.
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.
And now they have their own programming language?
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
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)
I am Slashdot. Are you Slashdot as well?
Nim is just yet another statically-typed GC language with an unsafe escape hatch. I can get the same thing (and much better syntax) with Java and JNI or C# and P/Invoke. Yawn.
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.
And suddenly C++ became much more interesting...
You know, Yet Another Programming Language will not make you a better programmer....
I've seen people buy the 'best' musical instruments thinking it will help them play better, it doesn't. Know what does? Practice,experience,time...
Please stop making new programming languages....its silly and embarassing....just take some time, pick one and LEARN the craft.
Do the Developers developers developers chicken dance.
sed -e 's/Chuck Norris/Rajnikant/g' joke > fact
I've always thought that was the point.
Do you really think that is more readable? If I were looking quickly or from a little bit of distance, I would think those are two statements, not a nested one. In fact when I used to code in C I would put braces around the inner loop AND indent it, to be explicit. Maybe that's why I don't mind python at all, and in fact love it.
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.
I've decided to stop wasting my time responding to AC trolls/sockpuppets... so if you want a response from me... login.
Yes, and then I hit C-M-\ and it's all pretty again.
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.
What we need more of is science!
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.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
(not parent) My editor auto-(re-)indents the code following the blocks that I define unambiguously with { }. I can also cut/copy/paste working code between different nesting levels and it will still work, as-is, immediately, and the editor can re-indent them later so they look good. So when experimenting and refactoring code between spaghetti-code, loops, and functions, I don't lose time making sure the code is properly illuminated by a monastic scribe just to see if it works.
It's also possible to paste code and lose all formatting in any web forum comment box, and it will still compile and work (and the human reading a snippet of code botched by the forum can also understand it, which is not even the case in an unformatted python code where all the structure is lost)
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 rules, not because of them. You've spent so many years defending that absurd design decision that you've convinced yourself that it's actually good.
Oh, BTW, with a sensibly designed language, just about every editor out there can format code properly with a single keystroke. The only possible argument in favor of Pythons implicit blocks, forcing idiots to indent their code, is essentially meaningless.
Required reading for internet skeptics
> 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 strukture is for both: compiler and human. And while there should be a tight correspondence between the channels (my editor helps in that), I enjoy tweaking the indentation from time to time to make a point towards the human reader.
> You just left-justify every line? Is that why you're so against indentation?
Nice red herring you have there.
for y in range(height):
for x in range(width):
code here
er,
for (y,x) in itertools.product(range(height),range(width)):
things
"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 proc.
It's like MS releasing an operating system without a start menu.
It's incredibly annoying, completely unnecessary and not that difficult to implement.
DBA's do not appreciate having to remove your stupid escape characters rather than simply copying and pasting the query you wrote.
Work Safe Porn
The compiler for it is written in Swift. Pass it on!
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...
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.
"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.
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.
"The agriculture ministry is not in charge of Gundam" - Japanese ministry official.
"End" just reminds me too much of BASIC and Visual BASIC.
That is a bad argument.
Basic languages also have infix notation for expressions, that doesn't mean that it is bad and should be avoided in languages. (Although it makes things a bit unclear since the precedence is implicit.)
My response to that is: if you need to indent that much or you have that much code in an indent then you are doing something wrong.
most likely you can break out the complicated or log code into another method. That has the added benefit of being able to give the next guy a chance of understanding what the code was supposed to do. There's less variables to keep straight of and the method name should give a hint what is trying to be accomplished.
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.
All hope abandon ye who enter here.
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...
In Soviet Washington the swamp drains you.
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.
--
"It is now safe to switch off your computer."
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 to do.
someday, maybe guido will come to his senses. if/when that happens, a lot of us will breathe a sigh of relief. and then, posted code on blogs, emailed code, etc, will still be runnable without GUESSING what the source was before the formatter destroyed it.
--
"It is now safe to switch off your computer."
THIS is a strawman. It's not like syntax doesn't interfere with you in other languages (often in terrible ways). But of course you're so used to those things in the other language that you'd rather not learn the annoyances of another language, huh? Saying it was just about the "onerous burden" of not typing a couple of braces is also mental. You're going to argue that writing a couple of unnecessary braces is a better approach than relying on the indentation you're already supposed to be doing instead? Python may have its flaws, but the general idea you're rallying against isn't one of them.
To create c code?
Python has multi-line strings. I know that fact won't change your mind, but it might help you look less ignorant.
What we need more of is science!
You are confused. Hint: "fact" != "subjective opinion".
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
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)
Oh god oh god, please don't do that. Not indenting the inner loop here is horrifically unreadable.
Yes, because people who care about that generally release their source code.
CLI paste? paste.pr0.tips!
Your examples are not convincing. Clueless posters will always mess things up, including omitting necessary braces. Python makes this neither worse nor better.
As to static typing, that is a tool to help beginners. It is not a requirement for a good language at all, as its absence also has rather strong advantages. If you want/need static typing, do not use Python. Really.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
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.
...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. :)
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 trouble before it even gets started.
So you think hammers are trivial ?
http://s1.cdn.autoevolution.co...
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?
It's Greenspun's 10th Rule applied to Python. Nothing here that hasn't been in Common Lisp for decades.
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.
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.
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, 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.
NB: The message above might reflect my opinion right now, but not necessarily tomorrow or next year.
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.
The instances of "bad code" in Python is minuscule compared to other languages. With Perl and Javascript being on the other end of the spectrum. Saying "Python too has bad code so its the same" is misleading. Python programs not only learn a language, they also learn one standard of coding in becoming proficient in the language. With C/Java/C++/Perl/Pascal/COBOL/Ruby, folks learn & develop various standards of coding on their own and at different companies.
Each reviewer now has to learn that new standard to figure out what the coder is doing. I have said "it's a BS design restriction" for one project written in one language multiple times. Cause each developer due to their various backgrounds choose a different design for their coding.
Having the language coercing people into using a single style is not a positive aspect of that language. Christ, that same line of reasoning is what managed to turn golang's syntax ruleset into the absolute feces it is today.
Then you don't gave 1 standard - you have 2.
-- Knowledge is power. -- Francis Bacon
But python has support for that already! You can use whatever delimeter you want! Watch:
for i in range (20):
#{
print i
#}
See how easy it is to implement curly braces for code blocks in python? It's amazing how much support python has for the syntax of other languages!
Yet Another Programming Language.
Same shit, different syntax.
And now, some HR idiot is looking for someone with 5 years experience in it.
Haha, here you all complain that Java is too fluffy, 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.
All hope abandon ye who enter here.
Note that the problems you mention are about Python, not about Nim. Essentially you care about runtime problems because you mixed some spaces or whatever. Since Nim is a compiler the indentation is checked just like you would with C or Java at the compilation phase. You can fuck up braces with indentation too and *think* the code is doing something while the compiler disagrees.
The gains you have are much less typing and clutter free code for readability. But if readability is your concern, you could troll then with Nim supporting macros... programmers who don't know better than C/C++ always hate macros.
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."
In C, for example, there are multiple ways to place braces. In fact, there's even a lengthy Wikipedia page on that very subject.
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.
can someone explain to a non programmer, as you look back over the last 20 years or so, what is the real cost/benefit of new languages
I mean, i read constantly of hip new languages; but there is a cost that no one seems to talk about, eg you need new libraries, maintenance of a new language. etc
are we, the users really that much better off ?
am i, a user, really getting more for my dollar from all these new languages ?
as a user, i care about cost/performance; curly braces, indents, static typing - totally irrelevant
Fifty shades of C++
C++, Rust, etc. Are there Fifty Shades of C++ yet?
Calm down... what I'm wondering here is if in part the point is to use obscure languages. What if the issue is not some new feature of the language but rather the fact that no one really uses it? Maybe it is a job security thing? Maybe it is a way for a company under contract to keep a client using them? If I code a program for a company in some weird language and they contractually own the source code they're still going to be more inclined to contract with me again because they can't find another developer that can use that code.
Are you worried about coming up with a good idea and then having your client contract with some cheap development house out of India or something? Code it in a language that no one else understands and they won't be able to do that.
What is more, it is the sort of thing that some clients are going to miss. They might slyly note that they're not obligated to use you for patches and updates for the program going forward. The significance of coding it in a weird language might slip by them. And thus you or your company gains leverage going forward.
Whether this is the primary reason people like these weird languages, you have to admit that you'd have more leverage to compel clients to use you in the future to maintain and add to those programs since it will be harder for them to replace you then if you used a more popular language.
Outside of this issue, I'm actually having a hard time grasping why there is such a profusion of languages when most of them do the same thing. Yes, they've some advantages over each other but that is more a way of saying they're different from each other then saying they're actually better. Conditionally, pretty much anything can be better then anything else. I mean, a bathing suit is better for taking a dip in the pool then a heavy down coat... but if I were walking through the snow I'd rather have the coat. Neither one is really better then the other. They're just conditionally superior.
I've decided to stop wasting my time responding to AC trolls/sockpuppets... so if you want a response from me... login.
You're going to argue that writing a couple of unnecessary braces is a better approach than relying on the indentation you're already supposed to be doing instead?
Yes. Relying on indentation sucks. For instance, if you have a tool that combines user code with generated code, it is much easier for that tool to throw in some braces, than it is to generate the correct indention. Indentation also sucks if you combine code from different users (like a code snippet you find on-line). Indentation also sucks if you have a combination of tabs and spaces. I agree that's bad practice, but sometimes it happens, and you may not be aware of it.
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.
>Syntax is not fluff.
Yes, because line numbers and nests of angled brackets in type declarations and such are far superior to moving away from a specific language's outdated syntax, rather than clinging to it because we're too old/lazy to learn a new one. A LOT of syntax is fluff, and is only necessary because the language in question was designed to require it.
>It should give me, the developer, the choice - not take it away from me.
Programmers are far too quick to use empty arguments like this in order to bolster their personal preferences about coding style. Removing the ability to screw things up is NOT a bad thing, especially in a language that isn't pretending to give you all the choice in the world to begin with (ie, a scripting language). Python may not have entirely succeeded in that goal, but I would much rather use a language that tries to standardize how people solve common problems then a language where simply moving from team to team in a company might result in me having to relearn how to program in that language.
But does that mean I'm going to poo-poo those languages or try to pretend they're inferior? No, that's my personal preference. Those languages aren't trying to "help me screw up" any more than Python is taking away your choice. It's not like C lets you change which brackets do what, does it?
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.
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.
...hammers don't need any training or lengthy experience to develop decent skills to use.
Oh, but that's such an easy mistake to make; have a look at just how many kinds of hammers there are and think again. Yes, anybody can take a cheap hammer and knock in nail, although even that is not as simple to do well. To the untrained eye a hammer is just a lump of iron on a stick, perhaps, but using a simple tool requires much more skill than using a complicated, automatic gadget. Which is why amateur DIYers go and buy electric tools, where the professional will often buy simple, yet surprisingly expensive manual tools.
Never do this, in face, always also include the braces for the outer loop as well as indenting the inner loop. Unless you want people to hate you.
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)
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 free at home.
Regardless, my primary point (and Guido's, in Python) is that braces lead to a variety of defensible styles. We all have our preferences, but there's really no way to determine which is "best".
Also, for the record, I should mention that Python allows indentation to be any consistent level, with hard tabs counting as 8 spaces. Though it's seemingly contary to the aforementioned principle, that one can be filed under "practicality beats purity."
Tim Peters once said explained such contradictions with something like "the key to any successful philosophy is to allow yourself enough wiggle room to do what you really wanted to do in the first place." [wink]
Wow.
Removing the ability to screw things up is NOT a bad thing
Can you please elaborate how use of whitespaces for defining control flow is "removing the ability to screw things up"?
If nothing else, use of the invisible characters for something as important as control flow is actively helping "the ability to screw things up".
But does that mean I'm going to poo-poo those languages or try to pretend they're inferior?
The problem is, Python is inferior. Because it provides less tools to its developers.
It's not like C lets you change which brackets do what, does it?
But C does have at least some brackets.
It does have clear visual clues and delimiters in its syntax.
All hope abandon ye who enter here.
echo 'int main(){printf("hello\n");}'|gcc -xc -&&./a.out
Nope, you don't need the spaces.
A successful API design takes a mixture of software design and pedagogy.
but nothing for the main market
If your blog "engine" can't handle a simple pre-formatted code block without tabs, you're doing things wrong. A lot of blogging tools out there seem destined for the barely literate, where a few paragraphs of text and a few pictures is the pinnacle of expressiveness. It's too bad that those tools mess up Python, but they mess up C/C++ and everything else equally badly: it becomes an unreadable mess.
Given that a space cannot be re-configured to mean something else, as opposed to tabs, I simply stopped using tabs for indentation long ago. Any decent editor knows how to deal with indentation without a 1:1 mapping between the Tab key and the TAB ASCII control code. So, I really don't see a problem.
A successful API design takes a mixture of software design and pedagogy.
I play an instrument. I now play a lot better, because I practice a lot more, because the instrument I bought two years ago is a joy to play and listen to compared to the one I had before.
Different people prefer different instruments, just as different people prefer different languages. Your plea to stop creating/using new ones sounds suspiciously like the argument that everything has already been invented.
Computer languages must evolve or we'll never get holodecks (and I guess future programming languages will rely on an artificial intelligence that does most of the leg work for you and you just customize upon assumptions made from your descriptions)
But there does seem to be rather a lot nowadays. There's some time saving features in some, others are structured to minimize bugs and all that.
Isn't all that matters the program that's produced? What's Nim or Rust or any of these new languages going to save you? 5% of your time?
That's great for business, assuming you save more money than it costs you to switch within a time-frame that doesn't damage the future of the business.
But until new languages have truly evolved past minor improvements and syntactic sugar (at least cutting development time in half without sacrificing one bit of functionality) isn't your time best spent on perfecting the use of an existing language? developing and improving the software you intend to create?
I've been developing a game engine using Object Pascal (FPC) for many years (the latest versions of the language blow all over Nim by the way and does what Nim is trying to do already)
I'd of had a far easier time re-writing in C++ so I could make use of existing libraries. I'd of had an easier time (but sacrificing performance) had I re-written in a garbage collecting language.
But had I done that, I'd now be working on a quarter of an engine rather than a full one and the end result would be no better.
If everybody switched over to new languages the moment they came out, we'd all still be in serial consoles battling 90's security bugs.
If nobody switched to new languages we'd probably have the EMH by now.
Languages must evolve but unless it's a game changing advancement (like object orientation over functional etc) these new languages only serve to split skill sets and hold back progress.
I guess I don't get it, there are some people that seem to flutter from one language to the next. Sure, it's neat that so many people are experimenting with new ideas, but I'm not really willing to build a big project around a new language that has no standardization nor offers any radically different programming methodology than the current languages I use. I view languages like Python, Rust, Ruby, Lua, etc as good platforms to write throw away programs.
Python has proven to me several times that it is willing to break old programs with new releases of its environment, which is good on them because they shouldn't stagnate but I also don't want to write anything big in it that has to be ported every 18 months either. Pretty much all of these new languages, which are still maturing, are like this. Java being the big exception of a language that quickly stabilized, likely due to the heavy corporate backing and the original intentions for the environment to be both feature packed and cross platform.
“Common sense is not so common.” — Voltaire
> 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.
Or the "over" in two-way communication. I strongly despise terminators, but they are necessary at times. Nevertheless, one gets tired of the constant "over" this, "over"that... curly brackets are not so bad compared to "begin"/"end", but it annoys me they are hard to align: either they go on separate lines by themselves or we must make an exception on the first line (and last), using spaces instead of tabs to account for one position taken by the curly bracket.
That alone justifies the creation of a special editor which takes care of that. But then someone realizes visual indentation is enough to convey code structure. That's where Python shines. Of course, some people need the punctuation (or the "over" marker as I see it).
Once, before I knew Python, I have seen some folding editor which fold 2D text blocks, allowing a kind of color delimiting of a single block (otherwise delimited by e.g. curly brackets).
Normal punctuation is actually OK, because it conveys something which can't be read otherwise -- like pause indicated by a comma; or the enumeration described with a semicolon.
In code properly indented it's redundant, though. And for being redundant it becomes annoying. Things are not simple as they should/can be. Wanna use curly brackets? Then don't indent.
Wanna make one-liners? Why? To save space? To have less Lines of Code? How many characters make one line up? I'd like to have 50 characters lines, for easier reading... there goes the one-liner down the drain.
If one disregards correct indentation to format code, say, like concrete poetry, all immediately visible structure is lost, a collapsing (folding) module editor becomes less comprehensible. Unless one really wants obfuscation, I wonder what tortuous thought process might want not to see logic structure.
I'm still only hearing "I think this, therefore it's true". You've clearly never dealt with substantial codebases in Python and a brace-delimited language, or you would realize that Python DOES actually encourage better and more standardized coding. But I know it's futile to actually try to convince you of anything, because you've made your choice.
You're not even able to see anymore that forcing brackets is like forcing whitespace - you're just used to its problems and don't want to care about them as much - like having pointlessly variable (and often very poorly) formatted code, instead of the issues with whitespace-delimited code.
Next you'll probably just tell me to use a linter (as if it makes a difference when and how you lint your code) or that some people have a tougher time reading whitespace-delimited code, therefore it's inferior (as though people with other disorders don't exist who prefer white-delimited code).
> Indentation also sucks if you have a combination of tabs and spaces. I agree that's bad practice, but sometimes it happens, and you may not be aware of it.
Get a better editor. 'Tab' is short for 'tabulate', ie make into a table. Source code is not a table (except RPG) and there should be no tab characters. The editor should convert the tab key into the correct number of space characters. It should also highlight tab characters in existing files, with colour for preference.
Join the illiterati before its too late!
Sent from my ASR33 using ASCII
Managers have more people since they now have an offshore database centre of excellence. Clueful developers end up doing more work.
Cos debugging already tested code is an expensive waste of time.
Sent from my ASR33 using ASCII
Types matter -- pretending they don't will not change the fact that they actually do matter. Are you telling me that a Python function defined as:
def foo(a, b,c)
""" Returns an int
a is an int, b is a char, a c is a float"""
Will somehow be magically valid if the caller expects a List, and is passing String/Float/Dictionary for a/b/c ? Why in the name of all things "Best Practices" would you NOT want to define the types of the parameters function declarations?
I've been programming for well over 20 years, and it has always been the exception (not the rule) where you'd use a void* or Object or 'def' instead of specifying the type.
I like the way you think! lets go into business together, you write in BrainF*** and I'll kidnap their dog!
As opposed to the situations where block structured code gets its indentation garbled and you can't tell which block a "}" or "end" is associated with.
I am becoming gerund, destroyer of verbs.
You don't need braces but some sort of block delimiter is really the only way to go. For example Lua and Ruby don't use curly braces, just "end" at the end of a block and this is fine.
I know Python but only use it what I absolutely have to solely because of the significance of white space in a programming language (WTF?).
For a really fun time: use both Spaces and Tabs in your indention characters.
Python pisses me off like makefiles did -- white space should NOT affect the semantic meaning.
Or, whitespace should not matter like it doesn't matter in the vast majority of programming languages.
which already has that.
Ruby is Python's less constrained cousin.
The supposed advantages Python gives to readability (forced whitespace), is FAR outweighed by the uncountable man-years of losses since Python doesn't allow the coder to specify input & return Types.
Python's approach is to force you to indent to avoid writing the horrible code you just wrote.
It limits expressiveness for no reason other than dogma.
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:
It must have been something you assimilated. . . .
How many companies deal in proprietary widgets that force you to buy their licensed products or the thing doesn't work.
If the big corporations can think that way then why can't the small development houses or independent contractors?
And where does the big company tell you that "you can only use our licensed products" in their advertising? No where. You ask the salesperson and they'll say "well, we just want to make sure you get the highest quality so we ensure only our validated products are used."
Ever used an ink jet printer or any product from apple? Why would they be the only people trying that tactic.
And the problem with kidnapping someone's dog is that is illegal. Writing in brainf** however is completely legal. Which means if someone writes in brainf** they're not a criminal. And you if you kidnap their dog then you are a criminal.
It helps if your business practices don't break the law. And its even more advantageous when you can find out ways to violate the spirit of a law without actually breaking a law. Ask the investment banking world about that. They're geniuses at finding new ways to do everything they're not supposed to do by doing it a slightly different way. And the smart ones walk away with lots of money not because they did a good thing or came up with a good service but found a new way to break the law without going to jail.
And why would they be the only ones to think that way?
Explain why you'd code in a non-standard language for marginal gains? There are huge advantages in using a standardized language. Use some weird language that five people know how to code in and you're FUCKED if you have a falling out or the weasels decide to start raking you over the coals. What are you going to do? Code the whole thing from scratch?
The IRS still has programs written in COBOL that they've been using since LBJ. I know of many major companies that still use DOS databases and various dos programs that were custom made for them practically a generation ago.
What do you think happens when they go searching for someone to patch one of these dinosaurs? They quickly realize that its cheaper to pay a programmer that knows the code to patch the existing code then it is to hire someone to write the whole thing from scratch in a new language.
Which is how programs stay in effect from LBJ to today. That's just legacy code. But you can get the same effect instantly by just using an odd language now. Bingo... customer for life. You can't be too greedy about it. But you have some additional job security. It is very unlikely that someone is going to walk in off the street or cold call them and have the resources on hand to fix their problem. They'll have to engage in a long search and who knows how effective that will be. Or they can just work with the person they know... just easier.
Instantly no competition.
I've decided to stop wasting my time responding to AC trolls/sockpuppets... so if you want a response from me... login.
Is the altar on which mediocre programmers worship.
Managers love it because it makes people easily replaceable, like cogs in a machine.
Python programmers make for good cogs.
Your examples are not convincing. Clueless posters will always mess things up, including omitting necessary braces. Python makes this neither worse nor better.
Yes, but it's quite possible that the code won't parse correctly w/o the braces (or with extra braces), where improperly indented Python probably will, and just execute incorrectly. I'd rather have a parse/compile error than run-time error or, more likely, improper execution with no error. Sure, examples can be made either way, but missing/extra braces *can* be detected by the parser. Missing/extra white-space, not so much.
Regardless of whether one (dis)likes white-space delimited blocking, it's main driving force is the ego of the language developer who has declared it "more elegant" than braces, even though the syntax offers absolutely no enhanced benefit.
It must have been something you assimilated. . . .
Types certainly matter, and Python has types. Yes, feeding the wrong type into a function probably won't work. It'll raise an exception and you'll see a traceback that helps you to fix your code.
If you want to check the types that are supplied to a function, you can do it with assertions. You can even go further and check the things going in have the properties you want. Type checks are a crude form of precondition. A function that expects a tuple will probably work with a list. A function that works with an iterable can accept a whole load of types without all the constipation of an explicitly coded interface to declare for all of them.
If you want the type errors picked up before you execute the code, you might be in luck. You could use the assertions, although I don't know of any tools that do this. There's also a convention for type specifications in docstrings. And official support for function annotations:
https://www.python.org/dev/pep...
None of which addresses static typing as such, which says that after assigning an integer to a variable, you shouldn't be able to reassign it as a float.
There are, still, real advantages to static typing and languages that give you those benefits with type inference, so you don't have to put type declarations all over the place. There are also languages with better generics than void * in C or Object in Java. (C++ and Java are even two of them). Mixing the good features of Python with a good static typing system would certainly be a good thing.
Oh, and I've been programming for a good deal longer than 20 years. I can appreciate different languages for working in different ways.
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.
Code correctness that relies on how far one has "gravitated" in their coding style and/or whether people agree on and/or adhere to those styles is the issue. All your brace-delimited examples work the same. White-space delimited variations won't.
It must have been something you assimilated. . . .
Nicer? When I look at that, my first assumption is that there were additional lines after the y loop that somehow got erased. If I was reviewing this code, I would tell the developer to fix the indentation before checking it in, regardless of language.
> It is appears to be sort of a religious issue for the language creator and some of his followers.
Whereas your diatribe appears to be a religious issue with a different god. If you don't like Python then just don't use it, nobody cares, no one is trying to force it on you. No one is going to rip your braces from you.
Here is a positive: if you recall the AT&T bug of the 90's that affected a million+ customers, the bug ocurred because the indentation levels of some "if" statements lied. That is, the indentation level made the code appear it flowed in one path, but the actual syntax parsed to make control flow in the other path.
If the software had an automatic means of preventing the code from compiling if the indentation didn't match the meaning, the bug could have been avoided. Python actually *does* have that feature.
What utility is there that tells me what the types are for this function:
def foo(a,b,c)
if the author of that function does not support any (AND all) types for input parameters a, b & c -- then the language has a serious design flaw. How is a function author even to indicate what the valid types are?
I have no issue with python as a scripting language -- using it for long running server processes on long lived projects (with high turnover) is where I take issue.
I agree with you, it was a joke, not sarcasm. It's a common tactic although with old systems in banks and government institutions it's often more about avoiding downtime than nefarious plots by developers. Such things definitely do happen though, I know for a fact my previous employers do it all the time. I'm the one that suggested it. Yes it's immoral, no we didn't care - I've got mouths to feed and they've got sports cars to buy.
> 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 to do.
Feel free to scatter your Python code with appropriate #begin #end lines to suit you needs.
if ( something ): #begin
do stuff
#end
or whatever style you prefer.
The whole point of Python is that, for the most part, there is only one way of doing something. That makes it more understandable to all those who do it that one way. If you prefer begins and ends or braces in a multitude of variations then use a different language.
> a lot of us will breathe a sigh of relief.
Please erase all Python programs, libraries and documents from your computer and then the rest of us will breathe a sigh of relief.
Oh this is just a load of.
On C/C++/Java code you can always run an formatter, and reformat it to your reading pleasure.
Ever wondered why there is no such tools for Python?
And I have seen enough of the crappy Python code too. It looks different from the C-like languages, but the shitty OOP is a shitty OOP in any OO language.
Different syntax is not a solution to any problem.
All hope abandon ye who enter here.
All the Python I've seen used an escape character rather than the """ which is a pretty silly way of doing it. But at least it can be done.
C# uses @"
But no, it won't change my mind because forced indentation is a non-starter. It's just an aggravation that doesn't add anything.
Work Safe Porn
> I prefer to have a visual marker that block is closed. You know, like a dot at the end of the sentence
Then stick with COBOL.
Wow, you must be a treasure to work with (or even live with). Yes, preference and insight equals "bizarre obsession". :-P
> Indentation gets goofed up all the time.
I have programmed extensively in Python for more than a decade and never have indentation 'goofed up'. Perhaps you need a better text editor.
Python's like a beer that only fits in one bottle size.
first, poe's law. ;)
beyond that, I'm well aware of it and I don't especially blame you. Customers that hire developers to do special contracts are frequently two faced in negotiations. The developer will bend over backwards to get the contract and then after they've given away the best bits as an inducement the client will change their mind and go with someone else... taking your contribution with them. Writing a contract that will stop them from doing that and worse getting them to sign such a thing is very hard. Easier to exploit their ignorance to hold them to a provision of the contract they didn't even know was there.
People can say what they like about that, but I feel it is reasonable so long as you're not greedy about it. As they say "you can be a pig but you can't be a hog." You take enough that you can run your business without going into the poor house and as much as possible try to make sure they don't notice what you've done or why you did it.
One of the things great about this practice is that it is deniable. It isn't obvious why you did it.
I've decided to stop wasting my time responding to AC trolls/sockpuppets... so if you want a response from me... login.
Wel, by definition, if something is copyrighted it's "released," you have to publish something in order to obtain a copyright.
Maybe everybody having their own idiosyncratic language isn't a copyright thing, but it's a pretty standard business tactic for vendors, for everyone from IBM to Apple. IBM or Control Data were happy to give you source code with their distribution, because they were pretty satisfied that you'd never be able to run the code on anything but their gear.
Nowadays shops like Microsoft or Google just create incompatible extensions to Java to keep people targeting their runtime infrastructure. Or Apple just up and creates a Rust clone (an arguably much improved one, but still pretty redolent of the original).
Don't blame me, I voted for Baltar.
Araq SHOULD have named it YASLDJ: Yet Another Shit Language Du Jour.
Except that never actually happens, because there's always enough information there to determine the meaning of the code. The process of restoring sensible indentation can even be automated.
If you have programmed for 20 years and are unaware of how the type system of Python works or do not understand its advantages, then you have been asleep at the wheel for 20 years. Really, have a look at the respective literature before you comment on thing you are obviously absolutely clueless about.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
> But the Gnu Prurient Loonies insist: taking away your choices is good for you!
I am not sure what choices have been removed from you. You can still use C or COBOL or Pascal or whatever other choice you want.
It seems to me that it is you trying to remove other programmers' choice of working with Pythonic code.
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.
The bottom line is that both static and dynamic typing both have significant advantages and their place. There was some mass-confusion maybe 15 years ago, where many people thought static typing and static type-safety was the only way to go, but fortunately saner minds prevailed.
That there are obviously people that after "20 years of programming" have not moved beyond the level of beginners where type systems are concerned just shows that there are a lot of really, really incompetent "programmers" out there. Even a little experience with functional or logic programming languages with dynamic typing demonstrate the advantages very clearly. Modern scripting languages like Python or Ruby use concepts from functional, imperative and OO languages to great advantage. They do require a certain level of skill and insight though.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
At some point there will be a book released titled "Secrets of Nim" and who ever makes it will get sued into oblivion.
Stop using big words you do not understand. There is far, far more to type systems than your broken and narrow view.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
In Python, a string that starts with "'" must be ended with the same "'". You can also start with '"' and it must end with '"'. Or any three-character combination of single or double quotes.
Captcha is 'educator'
If you can't stand it, you must be new
I disagree on both points. First, directly posting compilable code is always difficult, that is why you attach it as ASCII. And second, after having done real work in Python, I find the brace-less style easier to read, easier to write and clearer because it is more compact. (And while we are at it, I have done real work in > 20 different languages of various language types, so I have a bit of an intuition whether one is harder to use or not...)
That you do not like it is not the fault of the Python creator. Simply do not use it, but absolute statements about it being "wrong" or "false" or "offers absolutely no enhanced benefit" just demonstrates a problem on your side, not on the side of what you criticize.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
I intend to "fix" it because I'm tired of arguing ... not because it's a particularly good idea
Sounds like responsiveness, if araq had an easily expressed reason not to have it, he would have continued arguing.
Looks like a readable python variant.
Religion is what happens when nature strikes and groupthink goes wrong.
Looks like Ruby, just uglier
While I am no fan of "index by 1", I think it's only fair to point out that the above is not true with a compiled language.
I've fallen off your lawn, and I can't get up.
By the way, what is python's way of handling grouped statements like these
Generator expressions or itertools:
for y,x in ((y,x) for y in range(height) for x in range(width)):
# your code here
from itertools import product
for y,x in product(range(height), range(width)):
# your code here
Never happens to me, and I write a lot of Python (though, on-topic, Nim looks fascinating.)
Of course, the reason it never happens to me is that my editor of choice displays tabs as (dimly, colored) visible entitles, thusly:
<-->
That's for a four-column tab, which is what I always use.
I would *like* it if my editor showed an indent level as a vertical bar, with a number prepended to the left indicating the indent level -- 1, 2... n -- I think that'd be very nice for when you page over lots of code. (Maybe I should hack on my editor... hmmm)
I'm a happy user of c, and perfectly comfortable with curly braces (I even wrote a magazine article on c bracing style way back when) but frankly, Python's way is better. Less to type, less to look at, faster to code, perfectly clear as to what's going on at all times. Presuming you use an editor that makes indentation visible. And why would you not?
I've fallen off your lawn, and I can't get up.
If I "cluelessly" copy/paste some C into a blog and post it, the curly braces are not going to magically disappear. Indentation may magically disappear. That's the difference TheGratefulNet was pointing out.
No. That's not an "accident"; that's a coding error. It doesn't mean the language is lacking; it means your coding skills are lacking.
Do it right, and you won't have problems. If you think doing it wrong is the fault of the language, then you are very sadly mistaken.
I've fallen off your lawn, and I can't get up.
Bull, dynamic typing is the tool to help beginners that have no idea what they are working with. A good language allows the mixture of BOTH. Mainly because statically typed variable are insanely faster and easier to optimize allowing the executing code to bypass type checking. Static typing also allows library writers to force people using it, to pass in correct data (i.e. telling a function that a parameter is coming in as an integer, allows it to fail at compilation time when a string is passed in, rather than wait until the function is actually execute during run time)
Python allows arbitrary indention within bracket expressions, and you can start an inline bracket expression everywhere an expression is allowed. The only limitation is that statments and blocks must follow the intenditon, the following code is fine:
def f():
matrix = Matrix(
1.0, 1.0, 1.0,
1.0, 1.0, 1.0,
1.0, 1.0, 1.0
)
two = (
1 +
1
)
# there is no need to indent to the block level either:
myList = [
listItem1,
listItem2,
listItem3
];
No. It limits expressiveness so that we can all read each other's code without having to refactor the whole bloody mess. It does what c coding standards within an organization do, only it does it for everyone who writes in the language. Which is bloody awesome.
And it does so in an extremely efficient way, coding--character-wise.
Would you like reading c code where the style used was totally random? One line, the braces are all there, next block looks like K&R, next block looks wide open, next block some other way... of course not. That's bloody chaos. Well, just as it is an advantage to keep to one consistent style for you, for an organization -- so it is if *everyone* keeps to the same style. Less chaos; more and better comprehension.
Every objection to Python's whitespace mechanism I have ever heard boils down to one or both of two things: Get a better editor, and/or learn to program instead of pretending the language should have been designed to help you cope with your inability to adapt.
The very fact that someone -- anyone, never mind the legions of someones in this case -- can code very well with Python, and you can't, tells you only one thing: Your skills are inferior to theirs. Any protestations otherwise are simply one form or another of making excuses for limitations you refuse to address.
Also: One of the primary skills of any good programmer is to take the advantages of any language they are working in and leverage them to make things easier, better, faster, more efficient. If you can't do that, then you are (considerably) more limited than someone who can. In the case of consistent indentation, the advantages are quite obvious; your job as a programmer is to recognize them, grab them by the neck, and make them your love slaves. Not whine about it.
For instance, much as I despise perl's use of weird characters to mean things, I bloody well use them to my advantage anyway. Because when I write in perl, the language is my bitch. Not the other way around.
I've fallen off your lawn, and I can't get up.
(And while we are at it, I have done real work in > 20 different languages of various language types, so I have a bit of an intuition whether one is harder to use or not...)
Careful Grasshopper. I have 30+ years as a Unix system programmer/admin and Unix/Windows software developer on - literally - just about every type of system there is from PCs to Cray supercomputers and probably have more programming experience than you, in more languages. I've worked at NASA, The New York Times and, presently, a large defense contractor - all in both research and production environments.
That aside, you haven't countered my points at all. Sure, perhaps you find Python easier to read, write and clearer because it's more compact (that last point is extremely debatable). Those are all good points, but you haven't (and can't) offer any argument that white-space block delimiting offers any actual enhanced programming benefit over brace and other delimited languages. There are, in fact, are many, many posts in this thread alone demonstrating clear and practical problems with Python indenting.
And, in point of fact, the Python and Nim language developers have specifically stated that their languages use the off-side rule because they believe it to be "more elegant", so I can blame them for not thinking beyond that to more practical issues. Issues that apparently plague real people, doing real work, in diverse environments that would not and/or are not issues in brace/other delimited languages.
Don't let your love for the language blind you to its problems or shortcomings.
It must have been something you assimilated. . . .
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 claiming you're a lousy programmer. As do many similar arguments, such as thinking types are required because you "might" call a function wrong, or use a variable in some stupid way. If you call the function wrong, or misuse a variable, you are failing as a programmer. Do it right. Problem solved.
Back in the day, when we were writing in assembler more often than not, you'd have been laughed out of the building if you complained that the assembler should "know" what it was looking at beyond the most simple atomic architecture-related constructs. The fact is, as a decent programmer, you should know what you're looking at, and what you are doing at all times. If you don't -- the problem is 100%, entirely, beginning-to-end -- yours. You need improvement. You should seek it. Your failings will lead to bugs. Not the language's failings -- yours.
I've fallen off your lawn, and I can't get up.
I have programmed extensively in Python for more than a decade and never have indentation 'goofed up'.
My guess is that you work in a team of one. If you exchange or merge code from multiple people, then you will often struggle with whitespace issues. I help out with an after school program that teaches kids to program. The newbies use Scratch, but after a year they use Python. This mostly works well, but the kids often have whitespace issues, both individually, and when sharing code.
Settings that change language semantics? God no. A line of code should have exactly one meaning no matter what context it is written in. How the hell can I understand code written by other developers if I have to keep checking for settings like this?
09F91102 no, 455FE104 nope, F190A1E8 uh-uh, 7A5F8A09 that's not it, C87294CE no. Ah! 452F6E403CDF10714E41DFAA257D313F.
Settings that change language semantics? God no. A line of code should have exactly one meaning no matter what context it is written in. How the hell can I understand code written by other developers if I have to keep checking for settings like this?
I know, right? But I kid you not: Strong Spaces
[ I got modded "Funny" for that, but hope that's just because "Scary" isn't an option. ]
It must have been something you assimilated. . . .
Indeed, and if you need to add more dimensions, there is the itertools.product function, which is the true Python way of solving more complex problems.
for (x,y, z) in itertools.product(range(width), range(height), range(depth)):
code here
With the added bonus that its values don't actually have to be ranges, but can be any kind of iterators.
Agree, I'm not particularly proud but I suspect that such 'tactics' are commonplace and I think it's kinda sad that honest and noble people engaged in business often fail or end up at the bottom of the pile simply because they do the right thing. I've been 'pushed out' of businesses in the past for standing my ground when it comes to issues of morality and even law - and that was fine at the time because nobody depended on me. Now I'm left with little choice but to go with the flow unless I want those that rely on me to pay the price for the sake of my pride. From covering up data breeches to knowingly shipping faulty products - I and I suspect many people here have seen everything from the questionable to the downright illegal happen frequently. Not even giants like Google pay their tax, don't be evil? more like don't get caught being evil.
So how do you "remember to indent your code right" when you're trying to mix Python code provided with a developer with Python code generated by a code generator?
> In Python, a string that starts with "'" must be ended with the same "'".
Or you can use 3 apostrophes. '''Hello'''
> You can also start with '"' and it must end with '"'. Or any three-character combination of single or double quotes.
Completely false:
>>> print '"'hello'"'
File "", line 1
print '"'hello'"'
^
SyntaxError: invalid syntax
Anonymous functions are syntactic sugar. They have no programming value of their own.
I disagree with your claim that syntactic sugar is valueless. Calling a function in an argument to another function (f(g(x))) is also syntactic sugar, as instead you could require assigning the value to a local variable. The same is true of expanding tuples on the left side of an assignment (a, b = f(c)) or even putting more than one operator in an expression ((x + y) * z). The with and for statements are equivalent to various combinations of while and try. Without syntactic sugar, we would all be programming in assembly language.
Yet another zealot who think's he's discovered the One True Way, whereas all he's really accomplished is that he's easily replaced, which is what companies love.
(And btw, all these other languages are partly inferior because they didn't adopt Python's genius significant whitespace. Most language designers must be stupid to miss that!)
Are you insane or just so clueless about Python that you're making things up as you go along? Of COURSE you don't often need a formatter in Python; that's the entire point! And what about pylint or PythonTidy? Or are you going to pretend that nobody uses those next when they deviated a bit in the ways Python allows?
In fact you have yet to make a single cogent argument that doesn't boil down to THIS IS MY RELIGION, AND BRACES ARE THE ONE TRUE SYNTAX. To whit:
>Language is a tool. It should give me, the developer, the choice - not take it away from me.
>Python is inferior. Because it provides less tools to its developers.
You say this, but you have yet to prove how braces are magically a "tool" compared to whitespace, nor how whitespace is "less of a choice" than having to use braces? How do either of these things make Python inferior to C, which requires ten times as much code to say the same thing a single line of Python does, or requires entire frameworks to turn it into a C-syntaxed variant of Python anyway? Not in any substantial way that you run into in the real world - you can contrive examples, and pretend that one error happens more often than another, but neither of those things are good enough to convince me because I have years of experience with many other coders and projects (in both languages) telling me otherwise.
>If nothing else, use of the invisible characters for something as important as control flow is actively helping "the ability to screw things up".
How does it add any more to the ability to screw things up than not enforcing whitespace? I'm not telling you one is better than the other, just that I have no idea why whitespace is so much worse, given the constraints and syntax of each language. And yet, I can pick random Python apps online and they all seem consistently similar and readable to me, but every other C application is a bit different or has style issues up the wazoo. Why is that? It's not that my years of experience have left me deficient, it's that one language does some things more clearly, because that's what it was designed to do. Is it perfect? No. But is it "worse" for the types of programs it's meant to work with? Hell no. You can disagree if you wish, but you'll have to do a lot better than this to convince me of anything.
> Or, whitespace should not matter like it doesn't matter in the vast majority of programming languages.
Just use those other languages then. No one cares if you don't use Python.
Didn't Python 3 finally disallow mixing spaces and tabs for indentation by default? Should have done that from the start.
They finally disallowed that in v3 ... shame so many are sticking to the previous one.
Making it more difficult for modern coders to quickly compose SQL queries could be considered a valuable feature ...
This deserves a 5, but since AC posts are no longer welcomed here, I guess only ACs will value your contribution. Congrats on the insight.
> The supposed advantages Python gives to readability (forced whitespace), is FAR outweighed by the uncountable man-years of losses since Python doesn't allow the coder to specify input & return Types.
Your assertion is false. I haven't lost anything due to input and return types. In any case you could use decorators or assertions if that were important.
One could equally claim that Java and C++ lost uncountable years due to having to write every possible combinations of parameters and returns as overloads.
If Python lost you time then don't use it.
Nim is so new that it does not even have a wikipedia entry. Can you really use it in production???
oh, and it would not really hurt if you did have static data types.
The Cython language is exactly this: a superset of Python with static type declarations.
I think that's a nice way of saying "Oberon".
sub f{($f)=@_;print"$f(q{$f});";}f(q{sub f{($f)=@_;print"$f(q{$f});";}f});
> Those are all good points, but you haven't (and can't) offer any argument that white-space block delimiting offers any actual enhanced programming benefit over brace and other delimited languages.
Whether there are benefits of using white-space or delimiters is irrelevant. If you don't like Python then don't use it. I find that having me (and anyone reading my code) and the compiler understanding the code the same way is useful.
> There are, in fact, are many, many posts in this thread alone demonstrating clear and practical problems with Python indenting.
No. Wrong. There are many posts whining that they don't like it, probably because they want to use different styles, and probably different from each other too. Many of the posts that you see as 'practical problems' actually make incorrect statements about the language. Many of the 'problems' are most likely related to what their editor is doing: inserting tab characters, reformatting, or other.
If you think that's an issue this discussion is over and really no point in having it. Python defines a coding standard so that all read, write, and understand the same. If you think that is a weakness, well I hope I don't ever need to review your version of what ever language you choose.
I prefer to have a visual marker that block is closed. You know, like a dot at the end of the sentence.
Or, you know, like indentation.
I like Python and use it regularly to automate builds, indents make the source easy to read but replacing block markers with indents was not a good idea since it make it easy for statements to fall outside the intended block.
And did you exchange a walk on part in the war for a lead role in a cage? - Pink Floyd.
And if the indenting is, somehow, lost or messed up, your program logic is toast. Not so with other languages. So, yes, relying solely on white space for correct program logic is a potential weakness. It's mind boggling that you can see, or admit, this little fact.
In a perfect world you're correct and it shouldn't be an issue, but the world isn't perfect. The strong Python coding standard means nothing after this simple vi command: 1,$s/^ *//
It must have been something you assimilated. . . .
Except it doesn't complain when you have a mismatch.
It's actually trivial to generate Python code that way, if all you care about is syntactic correctness (rather than, say, preservation of whitespace) - you simply translate indentation into virtual "brackets" (which is pretty much implicit in AST form - and you do want to work with an AST for any kind of reliable codegen, anyway), splice your code in, then translate it back.
If you want to preserve the original indentation, it's just a little bit harder, but not much. Basically, you just need to remember the whitespace information on your AST nodes. Then, when you reconstitute the code from the AST, you can do so with character-for-character precision.
(Source: personal experience. I work on a Python IDE that has to deal with lots of that kind of stuff for e.g. implementation of refactoring. Once we had our whitespace-preserving AST, the rest was and remains easy.)
The generator ought to take care of such things, if it's written well (i.e. it actually understands the language it generates). Indenting code properly isn't really any harder than putting the right number of braces in the output.
with a sensibly designed language, just about every editor out there can format code properly with a single keystroke. The only possible argument in favor of Pythons implicit blocks, forcing idiots to indent their code, is essentially meaningless.
Exactly, I'm a big fan of Python, despite the idiotic indent syntax. Really, who doesn't indent their code, and why should the rest of us be inconvenienced because of the very few unique snowflakes that have to be forced into indenting their code? It's a perfect example of the "cure is worse than the disease".
And did you exchange a walk on part in the war for a lead role in a cage? - Pink Floyd.
(Source: personal experience. I work on a Python IDE that has to deal with lots of that kind of stuff for e.g. implementation of refactoring. Once we had our whitespace-preserving AST, the rest was and remains easy.)
You have different use case, which is 100% controlled code. IOW, you can rely on the original indentation to create the AST.
My use case is:
{user-start-code}
{generated-code}
{user-finish-code}
where "user-*-code" is an arbitrary user supplied string.
If the user start/finish code is just a function call, then it is all fine.
But if the user code is "if something:{CR}{TAB}aaaa", then the user intent simply can't be made clear from the Python's syntax: (A) is it "if (something) { aaaa }" or (B) it is "if (something) { aaaa" (and the closing "bracket" is in the finish code).
I've spent few hours tinkering, but there is simply no way to tell A from B definitively in the Python's syntax.
P.S. It is a sort of preprocessor, which allows to mix plain text with an arbitrary language. In generated output, the plain text is simply replaced with the print statements.
All hope abandon ye who enter here.
Ah, I see what you mean now.
Yes, in a case like that - for templating languages and such - you really do want the explicit block terminator. And that's what people do to Python in similar circumstances - just add it. Have a look at Bottle's SimpleTemplate engine - you might actually be able to reuse that directly as it's very lightweight, and it's generic and bare-bones enough to not really be tied to HTML in any way.
Your 30+ years are nice. I have the same.
The reason I have not countered any of you point is that you have not made any. You just stated "I do not like this, hence it is broken". Pretty unsophisticated. I have answered to that "Well, I like it, hence your opinion is not universal", and no, I am not blinded by anything.
All I hear is you whining that you cannot cope. Then don't and go somewhere else. Not all people have your limitations.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
Blocks that are normally indented now have to be closed explicitly with an end keyword.
I see what they did there.
Highly un-Python-ic: a new keyword to close the if/for/etc statements.
But it is a confirmation of my own conclusion that with the vanilla Python syntax that is impossible to accomplish.
Python support for me wasn't as important. I simply wanted to see and compare use of different languages in such context. And see whether a generic, language-neutral preprocessor makes any sense. (Here it is, btw.)
All hope abandon ye who enter here.
If my employer would try to force me using something like Whitesmith style, I would not only quit but sue him for harassment and damages to my brain and visual cortex.
Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
I agree, without types I have to read the code or comments to figure out the types of input/ouput types of a function. But Nim requires input and output types for functions.
Just like in Pascal, which never grew on me.
C's syntax is just so homely.
Bash scripts and C++ should be enough for everyone. The rest is just pointless baggage..
+1 for nim .
I'll see your personal experience and raise you mine. I've been indenting code since my FORTRAN-77 days. I've been a professional python programmer for about 6 years now. I've been using emacs for perhaps 30 years. Even with all that experience and tooling, and a desire to write well structured code, I hate, hate, hate python's model of using indentation to denote block scope. Love the language as a whole, hate this feature. I've never gotten used to it, even with emacs doing most of the work.
My fellow co-works give me flak for writing like this:
foobar= foo + bar
While they write like this:
foobar = foo + bar
Personally when reading other peoples code I don't mind either, I don't go around their code removing the spaces, but I am so used to writing without the space before the equal sign that even if I am trying to write code in their standard I sometimes forget. They say they can see which parts of the code was written by me just because of that little quirk. That quirk would not be lost in Python, but granted, it removes the other developer quirk:
function() {
versus:
function()
{
We considered implementing syntax coding standards, but honestly I do not think they help all that much so we never ended up using any. And really, individual coding styles are sometimes useful, if I see a code with the curly braces in the following line and I have a problem with that code I know exactly who to talk to without needing to check git.
I first learned to program in Pascal, in which that statement would be like this:
foobar:= foo + bar
versus := foo + bar
foobar
Since pascal has two characters for the attribution operation it looks odd with the space before it.
Ahah! suddenly the reason for getting more women in IT is clear.
You are a moron. A truly fucked-up, head-up-the-ass-into-his-colon idiot. And you're stupid.
1) It may not be my blog "engine".
2) Fixing messed up formatting of any C-based language is a keystroke away, so we don't have to waste time making sure some random blog or forum software won't mess it up when it's copy and pasted on any of several OS's or desktop environments.
Using your brain instead of the computer is stupid. That's why we invented computers: to automate and remove the drudgery of manual/mental labor.
I guarantee that same anal pedant saw this page, went to wikipedia just to make sure the article was deleted, lock, protected, closed for being off topic, it's all the same, wikipedia deletionists and stackoverflow morons.
Suddenly, everyone goes back to statically typed language again.
Wait... You work in a language that gives you a choice of how to enclose code blocks? What language is that?
this signature has been removed due to a DMCA takedown notice
All it takes is one little const buried somewhere and you are running the malware code as part of the compiling without being aware of it! What a great feature - for an utopic world where everyone is nice.
If you wish, even C:
#define BEGIN {
#define END }
And C++ has some of that already built-in.
All hope abandon ye who enter here.
You sound very closed minded. You confuse "not coding to your exact personal style" with "not a good coder". There's too much of that mentality lately, so I probably wouldn't choose to work for you anyway.
Touché. I guess I wasn't clear. #define lets you change which symbol you use to enclose code blocks. But when you said your language should give you a choice, I thought you meant "a choice between using indentation and using block enclosing symbols."
this signature has been removed due to a DMCA takedown notice
I don't think that the shortcomings of broken blog engines are supposed to influence programming language design.
If I have to copy-paste something from a blog into an editor, then run autoformat on it, I might just pass on. Frankly said, people with shit worth posting know how to manage their formatting. If a post is so broken as to be unreadable, it's most likely useless code anyway.
A successful API design takes a mixture of software design and pedagogy.
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!
You transmit a message over a communication channel that corrupts the message, and then you blame the message for being corrupted.
You formatted your post in disagreement with your opinion. Here, FTFY:Pythonpissesmeofflikemakefilesdid--whitespaceshouldNOTaffectthesemanticmeaning.
Your reports must be fantastic without all those indented bullet points...
Finally, nobody counts spaces... that's why Tab characters were invented.
if it's written well (i.e. it actually understands the language it generates)
Parsing arbitrary user-written code is more involved than generating code. When you generate code, you deal only with a subset of the language that your generator emits. When you parse code, you have to deal with essentially the entire language.
Indenting code properly isn't really any harder than putting the right number of braces in the output.
To indent the inner block properly, a code generator has to parse the inner block in order to see where the open parentheses, multiline quotations, etc. are.
Thanks for that link to PEP 3107, which brings some of the static-typed capability to the Python language. However, it appears to only be applicable to Python 3.0+. My target distribution is RHEL/CentOS 6.6, which ships with python 2.6.6 -- so scripts using that language feature will not execute there.
$ python
Python 2.6.6 (r266:84292, Nov 21 2013, 10:50:32)
[GCC 4.4.7 20120313 (Red Hat 4.4.7-4)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> def foo(a: int):
File "", line 1
def foo(a: int):
^
SyntaxError: invalid syntax
>>>
# yum provides "*/python3"
No Matches found
Mixing the good features of Python with a good static typing system would certainly be a good thing.
Well said. Ideally Python would've had these features earlier -- better late than never I guess. This capability is such a fundamental shift that it would help if people qualify which Python version they are talking about when discussing that language's features.
Finally, nobody counts spaces... that's why Tab characters were invented.
Wrong. Per Python's PEP-8 guidelines you are supposed to use spaces and not tabs for the whitespace. A language mis-feature that is trying to be "fixed" with best-practices documentation of standards.
You can read it yourself at: https://www.python.org/dev/peps/pep-0008/
Unfortunately that URL gives HTTP 503 errors (no doubt the backend is implemented in python).
You had me until corporate taxes.
Tax policy actually makes no sense at all. The income tax itself is problematic. And it is especially problematic when you tax a business twice.
If corporations paid taxes the way that individuals paid taxes that would mean 60 percent or so of the corporate income would go to the government and then from that remaining 40 percent you'd pay out dividends or invest in further corporate growth etc. It doesn't work.
Which is why corporate income tax tends to be very very very low. Everyone understands that the whole double taxation concept is a stupid one.
That said, the income tax system is itself problematic. Worse is the estate tax or as it is better known the "death tax" which is the reason corporations have taken over. Corporations pay no death tax. A family business has to sell off half their value every generation just to pay the estate tax. It is ruinous.
There are a lot of aspects of the taxation system that are simply stupid.
The US Federal government used to fund itself almost entirely with a tariff. The issue is controversial but there are some really nice features of that tax. One, it is very easy to collect and very simple. Two, tax fraud is smuggling and smuggling is tax fraud. And that means the IRS etc has a great interest under such a system to control the borders otherwise they'll lose revenue to smuggling. That means the borders are policed and the US Federal government will care deeply about what crosses the border because that is how they get paid. You'll note that the modern US government says they can't police the US borders. Do you believe that? Really? If that was how they generated the revenue that kept the lights on, they would probably find out how to do it.
Here you'll point out quite sensibly that the Feds couldn't possibly fund all the things they do with a straight tariff and that is quite right. However, practically everything they couldn't fund with that either shouldn't exist or should be done by the states. And the states have another good tax which is the property tax.
I've decided to stop wasting my time responding to AC trolls/sockpuppets... so if you want a response from me... login.
I would like to propose a moratorium on comments of the form, "I manage a team and would never hire you." They add nothing to the discussion and only lead to useless dick waving competitions. ("Oh yeah? Well, I'm president of a Fortune 137 company and *I* wouldn't hire *you*!" "Oh yeah? I'd never accept an offer from your crappy company and you couldn't afford me anyway! Neener neener!" "Oh yeah? [etc]")
I have been frequenting the #nim IRC channel for several months now, and I have to say that the posted conversion snippets are not at all representative. There are usually way over a hundred developers present in the channel, many of which are highly experienced and professional software engineers in various fields. The senior staff in particular is extremely friendly and helpful, and as a newcomer with lots of beginner questions I immediately felt welcome. I have witnessed many enlightening discussions about compiler design and general software architecture, not just covering Nim, but also many other programming languages and academic research projects. I also cannot approve of the criticism against Araq, the main driving force behind the language. He engages with users on a daily basis on IRC, the forums and GitHub, and is considering their opinions in the design of language or standard library features. Quite frankly, this is one of the things that I find particularly interesting about the development of Nim, because I feel that I can actually participate in the language design. The statement that Araq made with regard to implementing something because he is "tired of arguing" was certainly made out of frustration from dealing with certain users who possibly lack the depth of understanding, the professionalism and the patience that it takes to get things right. I am not aware of any single language feature that was put in place because of laziness or as a shortcut. The language still needs a lot of work, but the potential is evident. It is actually quite remarkable what a few folks have been able to put together in their free time, and I love working with Nim already. I'm curious who posted the chat snippets above. They seem to cover only three users having a heated argument, and I wouldn't be surprised if the poster was one of them.
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.
Ironically most "programmers" like it. Having the indentation forced upon the programmer does not in any way bring to my mind the word "flexible", so you're probably onto something with your statement being more accurate than you intended.
I'm a minority race. Save your vitriol for white people.
I disagree on both points. First, directly posting compilable code is always difficult, that is why you attach it as ASCII. And second, after having done real work in Python, I find the brace-less style easier to read, easier to write and clearer because it is more compact. (And while we are at it, I have done real work in > 20 different languages of various language types, so I have a bit of an intuition whether one is harder to use or not...)
Only 20? No wonder you like python ;-) FWIW, I've done real work in python too.
That you do not like it is not the fault of the Python creator. Simply do not use it, but absolute statements about it being "wrong" or "false" or "offers absolutely no enhanced benefit" just demonstrates a problem on your side, not on the side of what you criticize.
Actually parent posters all had points - the whitespace is just one of the ambiguities present in python code. The sloppy handling of the dictionary up the call stack results in scope changing when variable positions on a line change. Just like the whitespace issue, it causes the program top run without apparent problems but silently corrupt data.
I'm a minority race. Save your vitriol for white people.
Settings that change language semantics? God no. A line of code should have exactly one meaning no matter what context it is written in.
Python doesn't have this and yet that doesn't seem to have affected its popularity at all.
I'm a minority race. Save your vitriol for white people.
If the software had an automatic means of preventing the code from compiling if the indentation didn't match the meaning, the bug could have been avoided. Python actually *does* have that feature.
All languages with braces have had that feature from long before python. You can run the code through indent, you idiot.
I'm a minority race. Save your vitriol for white people.
If you think that's an issue this discussion is over and really no point in having it. Python defines a coding standard so that all read, write, and understand the same. If you think that is a weakness, well I hope I don't ever need to review your version of what ever language you choose.
Of course it's a weakness - in any language with delimiters (such as braces) you can easily run a script to indent it the way you like. With python you don't have the option to do so. This language feature is so difficult that no AI exists which will take your munged up python program (say, all on one line) and restore it to the original. The braces version is so simple that no AI is even needed - see the indent program.
I'm a minority race. Save your vitriol for white people.
Python's entire objective is the human reader.
If that were true python would not have invisible scoping rules that silently lose data. I'd rather have a program crash, but python is designed to silently lose data if you mistype a variable name or if you type it correctly too. The scope in python changes depending on the RHS and the LHS variables - their scopes are not predictable without reading through the program above if you change the sides they are on.
I'm a minority race. Save your vitriol for white people.
Just in time for the Obfuscated NIM contest!
First, thank you for your polite tone; uncommon here, that already makes you 50% right off the bat. To tell you the truth I have my quibbles about Python (the C-like syntax) but the indentation idea is too dear to me to let the discussion pass by.
Now, I suppose this is the content to which you refer:
| Citation:
|
| Tabs or Spaces?
| Spaces are the preferred indentation method.
| Tabs should be used solely to remain consistent with code that is already indented with tabs.
| Python 3 disallows mixing the use of tabs and spaces for indentation.
| Python 2 code indented with a mixture of tabs and spaces should be converted to using spaces exclusively.
| When invoking the Python 2 command line interpreter with the -t option, it issues warnings about code that illegally mixes tabs and spaces. When using -tt these warnings become errors. These options are highly recommended!
|
This is from a PEP or "Python Enhancement Proposals". SInce I'm not in the Python world (yet...) it's hard for me to tell what is already being practiced and what remains at the idea stage. Actually, that is described earlier in text as "Meta-PEPs (PEPs about PEPs or Processes)". Whatever that might mean, I believe it is even more vague.
On a practical approach, some editors (Vim, for example), can be set to use spaces instead of physical tabs -- one can even select how many spaces. The discussion becomes then somewhat moot, IMHO.
But I understand your point, and stand corrected about it. I see how someone using individual spaces might come to find that annoying (I have friends who do that and it annoys me to even see it). Thanks, again. I suppose that makes you 100% right.
That notwithstanding, the central question here, as I understood, is mandating a logic structure by indentation in code versus allowing free text flow.
That is akin to the discussion about good coding style which already has generated tons of lines in threads about taste issues. And in the end, for practical reasons (e.g. maintainability), some style is mandated -- and Python code is no different.
I also understand that, on certain occasions, it's useful to have a special indentation -- for instance, to better convey the workings of an algorithm. I don't know how to solve that without abandoning the very useful resource that is having logic blocks delimited by indentation. Maybe I should start to code in Python to be able to present some useful suggestion.
What I can say now is: use a pre-processor, do what you want and make it spit out Python.
Question to those in academia:
Is it true that most students who get a masters in computer science create their own programming language as part of their studies?
227-3517
Like a Python developer, you didn't actually read or comprehend the actual article.
I you actually understood the article, you would discover that it was a joke, really. What the analysis breaks the tokens down amounts to object/byte code. Yes, the authors of that article managed to discover difference between source code and byte code.
Parsing arbitrary user-written code is more involved than generating code. When you generate code, you deal only with a subset of the language that your generator emits. When you parse code, you have to deal with essentially the entire language.
Sure, but parsing only has to be implemented once, and then everyone can use it.
And, coincidentally, Python contains its own parser in the standard library.
You raise very good points, I was referring to the scandal of companies like Amazon and Google using loopholes here in the United Kingdom to avoid paying the majority of what they owe in tax by shifting profits made in this country to other countries. But that said, I do see the importance of keeping business tax low especially given the points you raise (although the UK has one of the most favourable tax systems in the world for businesses and many companies and rich individuals are still choosing to cheat the system) Our western economy being based on the concept of continual growth it's reasonable to accept government claims that a higher tax on business would have a knock on effect that would harm individual households in the long term. It would be nice to see more transparency in such things and less closed door deals with our freely elected officials. Anyway I digress - Nim doesn't look bad but it's very hard to quantify the development efficiency of languages compared to others without long term use in business and for that to happen some early adopters have to take risks. It seems like a big ask. Are you yourself or anybody else aware of methodologies that can be used to quantify the (developmental) efficiency of a language? With so many factors - learning curve, error rates related to syntax possibilities/restrictions etc it seems very difficult to cast anything other than a 'gut feeling'
Well, I believe your VAT is paid by people that buy things there and your sales taxes should also be paid. Whether they owe you income taxes on top of that is debatable.
Lets say I am a company in the US and you call me up on the phone from England and order whatever it is I sell... I work out the import fees, and see to it that you pay sales tax... do I owe your government income tax as well? I don't think I do.
Now you might say "but amazon has warehouses and people that work for them in the UK which makes that part of it a UK company"... and to that I'd point out that they pay property taxes, fuel taxes, their employees pay income tax, and there are all sorts of taxes and fees that that portion of the company pays. So I don't think it is reasonable on top of that to ask for an income tax when the shareholders are already paying that.
Again, the income tax as applied to corporations doesn't make a lot of sense. Again... everyone knows it. Which is why no one tries to rake companies too hard over the coals for it. Its a dumb tax.
And there are a lot of dumb taxes. A lot of the economic problems we're suffering in the US and in Europe are the result of dumb taxes. A lot of the reason we lost so much business to china is because their taxes are a lot less dumb. The wage differences are relevant as well sometimes but it is mostly a matter of pointless regulation that forces companies to employ huge numbers of people just to fill out government documents that no one reads.
Did you ever see the movie Office Space? Remember how their bosses were obsessed with TPS reports to such an extent that they were more important then any work that actually got done? Well, our governments are doing the same thing.
In the average US hospital the upper THREE flours of the hospital are filled with accountants, lawyers, and various people that process hospital paper work. All of that has to be paid for by the patients and the insurance companies and the government via the subsidies. It is a huge waste of time and money. SOME paper work does need to be done but it should be what is needed and nothing more because every bit you require beyond that simply makes everything more expensive.
The US companies set up in Ireland because the Irish were willing to have reasonable tax policies in return for getting a lot of jobs.
Any country not willing to do that is going to lose jobs to countries that do.
Choose carefully.
I've decided to stop wasting my time responding to AC trolls/sockpuppets... so if you want a response from me... login.
I see, well you clearly have a much better grasp of the issues than I do. Much of what I know about tax evasion in this country is from political debates and (biased?) media stories. :) thanks!
It does seem unfair especially given far more money was used to bail out private banks than could be clawed back by forcing companies to adhere to UK law and other countries seem to do just fine without needing such additional taxes.
I appreciate you taking the time to discuss this and explain your stance but I'd be doing you a disservice without learning more. I'll do some more research before venturing the topic again
At the end of the day, you want to make sure your taxes are not so high that you lose more business by raising the taxes then you gained in additional revenue.
What is more, when you make complex taxes that only apply in certain circumstances and not in other then you encourage people to do things in just such a way that they don't pay those taxes. Often this just requires filling out some paper work to declare one thing or another under some provision of some law rather then another. And all of that legal and financial finesse costs money because you have to hire people that know how to play the game then pay them to play it for you.
In the end, it mostly just hurts small businesses and medium sized businesses that can't thread the needle. And that is in many cases the point. Kills competition which allows established companies to operate largely unopposed because no one can handle the paperwork required to eliminate the taxes AND run the company at the same time from scratch.
In any case... good day to you.
I've decided to stop wasting my time responding to AC trolls/sockpuppets... so if you want a response from me... login.
Coincidentally, I did pursue the lawsuit idea when I was first hired, but I wasn't able to find a lawyer who would take the case. [sigh]
Actually, although I hated the Whitesmiths style at first and had a lot of trouble reading it, I was eventually able to adapt. Ironically, once I realized that it was similar to Python except with (seemingly) unnecessary braces, it became easy for me to read.
You can get use to any style that's applied consistently, and I eventually found a certain kind of clunky beauty in my employer's prescribed style. The entire organization uses it very consistently, which turns out to be more important than the fact that the style itself is basically dopey. Of course, the term "dopey" is subjective, but in this case I define it as meaning "non-minimal and not similar to any of the several established industry standards." It certainly qualifies under that definition.
Really, all there are are limitations on your side. You want/need simple, go program BASIC, not some tool you are not equipped to handle.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
Really, all there are are limitations on your side. You want/need simple, go program BASIC, not some tool you are not equipped to handle.
Python *is* being sold as the simpler option, and indeed it is becoming more popular with the non-programmer programmer (weekend crowd) than it is with the professional developer.
I'm a minority race. Save your vitriol for white people.
Well there are two coding/brace styles that hurt my eyes and one is that with W. And the other one is where the opening brace is on its own empty line. Actually that is the same with that W guy. Does not matter how it is indented.
I doubt I ever could adjust to that, but luckily everyone I met the recent 15 - 20 years used the same style. Perhaps because Java introduced a good style, see below.
That is basically K&R style with the opening brace of the function on the line of the function header.
There are even worth styles, just found the Rattliff style, oh my gosh :-/
And yes, I would not work in a shop that had an absurd coding style for braces ... I would make mistakes and I hate making mistakes.
Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
You've hit the proverbial nail on the head it seems. Succinct and I can't fault your assessment. It troubles me that I saw so little regarding an issue that is very much at the heart of our next election. You've given me much to think about - good day to you also.
Interesting use case. I would say less common, but there are more students learning a programming language than pros using it; also, Python seems to be considered good for teaching thus making it a bigger problem.
In spite of others claiming a language should be apt to being edited with any editor, IMHO we must consider the ability of an editor program to insert a piece of code starting at, say, column 20 and keep indentation relative to that column. Otherwise, the source code will be messed up, no matter what language you choose.
People give little importance to this fact, it seems, and are perfectly content that C-code -- because it has curly brackets -- still compiles OK, even if in a degenerated format. But is this really ok? Does that contribute to comprehension and learning? Do we want beginners to give less importance to code tidiness?
As long as it works, one can always discount some points for messy out-of-style code, I suppose. But since now we know there could be a tool which automatically adjusts code on-the-fly to be perfectly indented all the time, do we really want to punish students for not doing menial tasks? Of all occasions, in a Programming class? Not a great idea, me thinks.
I myself had this Sappeur Language quite a bit before Rust.
Now, if you would like to leave my lawn...
For crybabies there are GCs. Grownups can clean up their shite themselves. Immediately and incrementally. I dont distribute shit around the house until I literally cannot do a step without hitting a shitty pampers.
Instead I incrementally go to the loo and immediately get rid of the stuff. I also use a wastebasket instead of randomly dropping dirt onto the floor. Immediately when there is waste.
Enforcing whitespace in the language weakens it.
Add in the sad decision to not make everything an expression in Python and you have a weaker language with zero benefit to go along with the enforced whitespace.
Guido is almost as stupid Rasmus.
Python used to not have any scoping at all which is why you have all those redundant self self self self self....
If you're at all curious, you can look into Warren Buffet's corporate empire. The man has built his entire corporate structure around not paying taxes. And yet he's generally thought well of by the tax and spend crowd.
For one thing he owns insurance companies. Insurance companies pay no capital gains taxes. Those taxes you pay when you buy a thing then sell a thing at a profit. Such as buying and selling stocks or bonds. By doing that buying and selling through his insurance companies he avoids that tax entirely.
The next thing he likes to do is buy to own rather then to sell. On longer term investments he'll just own a thing rather then buying and selling from it. When he wants to draw money from it, he'll borrow against its value. The interest rate for a secured loan is tiny. We're talking about a fraction of a percent. Compare that the tax if that money were income. What is more, debts are tax deductible. So not only does he not pay tax on the income from things he does not sell but he can actually use the profits to offset taxes he cannot avoid.
Then he owns various charities etc which allows him to throw big parties for his friends etc and deduct those expenses from other taxes owed.
And those are just the three main ways I know of that he is going out of his way to not pay taxes. His whole empire is based on the notion of not paying them.
And that is only possible because the taxes are complicated. If the taxes were simple then you wouldn't be able to avoid them. The problem with simple taxes is the same as the advantage. And many people like people to pay more and some to pay less. The result is that the poor generally pay nothing. The rich pay pretty much whatever they want to pay. And the middle class gets shafted because they have enough money to be taxed without the sophistication to game the system.
And who does all that benefit? Politicians mostly. They get to tell the numerous poor that they're sticking it to the man. They get to give a knowing wink to the elites that know where all the loopholes are... and the dump saps in the middle don't even realize what is going on.
Only way people in the middle are helped is if the job market is protected and the taxes are kept simple. The more regulations you create, the more small businesses get shut out of existence which is the primary means for people to raise themselves up in a capitalist society. You do it by making your own business. What is more, the largest employer in practically every economy is small business. They are the primary mechanism for social and economic mobility and the primary employer of everyone. And yet... the least powerful in any congress or parliament in the world.
I've decided to stop wasting my time responding to AC trolls/sockpuppets... so if you want a response from me... login.
It's poor style to not indent the inner for, because C family languages do allow one line for-statements, which the body is replaced by a single semi-colon. Someone skimming over the code could easily interpret it as such.
Most human behaviour can be explained in terms of identity.
I doubt that's the problem. GP is welcome to correct me, but I rather suspect it's his brain switching from one mode to other.
Confucius say, "Find worm in apple - bad. Find half a worm - worse."
And you have to face in a specific direction to drink it.
Confucius say, "Find worm in apple - bad. Find half a worm - worse."
That's strategic choice. He's referring to tactical choice.
Confucius say, "Find worm in apple - bad. Find half a worm - worse."
In the latter case you just put a new {/begin/do when you enter a control level and a }/end/done when you leave it. In the former you need to keep a count in a variable.
Confucius say, "Find worm in apple - bad. Find half a worm - worse."
True, but both are so trivial that the difference is largely irrelevant.
(and in practice, most generators try to produce indented code anyway, so that it can actually be read and understood - which you'll want to do when you're writing it)